MDT

Replicating Virtual Machines to Multiple Folders

Virtual PC Guy's WebLog - Thu, 09/26/2013 - 01:59

Hyper-V Replica allows you to configure where replicated virtual machines will be stored.  You can either choose to have all replicated virtual machines stored in a single location, or you can choose to specify a separate location for each primary server that is replicating to you.

But what if you need to have multiple virtual machines replicating from a single primary server, but stored on different drives?

This is what I needed to do for my home configuration.  It turns out that while the solution is not obvious, it is not that hard to do.  What you need to do is:

  1. Configure Hyper-V Replica to store the replicated virtual machines in one of the locations you will be using
  2. When you enable replication on a virtual machine that needs to be stored in a different location, choose to perform initial replication at a later point in time:
          
    This will mean that only the configuration file and some placeholder virtual hard disk files will be created at this stage (all of which are very small)
  3. Go to the replica server and find the virtual machine in question
  4. Choose to move the virtual machine
  5. Move the virtual machine storage to the location that you want for the replica
  6. Return to the primary server and choose to start initial replication
  7. This time choose to start replication immediately

When you are done you will have the virtual machine replicating to a unique location.

Cheers,
Ben

Categories: MDT

Mevade and Sefnit: Stealthy click fraud

Microsoft Deployment Toolkit Team Blog - Wed, 09/25/2013 - 21:30

​Recently Trojan:Win32/Mevade made news for being the first large botnet to use Tor to anonymize and hide its network traffic. Within a few weeks, starting mid-August, the number of directly connecting Tor users increased by almost 600 percent - from about 500,000 users per day to more than 3,000,000.

Last week we concluded, after further review, that Mevade and Sefnit are the same family and our detections for Mevade have now been moved to join the Sefnit family.

Win32/Sefnit is a well-known family which includes a component capable of performing click fraud. From our observations in the wild, this particular component disappeared near the end of 2011. In June 2013 we discovered a new click fraud component which we originally classified as Mevade.  

Despite its recent notoriety due to the Tor activity, there is still a bit of mystery around how the latest version of Sefnit is spreading and the monetization techniques it uses.

In this blog I’ll be going into a bit more detail on the new stealthy click fraud technique used and how it has contributed to Sefnit being largely undetected by AV vendors for the last couple of years. Additionally, we will discuss a few of the attack vectors used by the Sefnit authors to deliver the latest version of the malware.

Interestingly, TrendLabs now believe they have identified the online identities of the actors behind the threat.

An interconnected threat

The Sefnit threat is composed of multiple components dedicated to different tasks. Among the observed samples, we have identified three distinct components. Figure 1 illustrates what is known currently about how these components interconnect as well as their intended purpose. Figure 2 provides sample references.

Figure 1: The Sefnit malware structure

    Component Sha1 Subset Service Name Updater and Installer Service Trojan:Win32/Sefnit.AU 5451cfa12c9acfae6e91f7c13e4b946038bacef4 942860bedf408cc4c6a1831ef3744a3f9e68b375 “Adobe Flash Player Update Service” Click Fraud Service Trojan:Win32/Sefnit.AS 014ace48897e81052b9552a5a7ab04d00a8e5227 04bb63c3c71b4d033f49434f59a9225d08b4ea70 05a8fb5e61aad8be003a0ab461b39a86767fda23 0e246f6b95a9fd2d2a0c905be87074f5aadc7be0 0f8be849f287cf705ebc0409527fd06670438470 21bfcc14ac5abc6cb8b6fc802038e66ac4e24686 2d10aaf57c45bde69d8f52e23bdabc10a192da20 5d28316acb73e06a5f4c00858b3bf095cfe6b2bf 72d705af606df58aaaec3cc271f46d3d2e4c0499 7c5091177ea375eb3d1a4c4a2bbd5eb07a4cc5cc 8528769281709abd231a46f13ffdfaaa13232336 89c28f7203f9db0762d1c64e42422a5d89c6a83f a6b055df9ad3d374acaf2dfacded3ba88d20f5cd a7a41a0c6998f83839c5c6b58840b62a28714b17 a81b04724ab71e4a71e939204e476bb762adc506 bf4151bece1d94d8304df46b2598c14214d9834e c5af760e62f230ed0f55ff19d2c2215568e6a199 ccd1fa1bf48665270128700bc94043c5fec39984 “Trusted Installer”   “Bluetooth LE Services Control Protocol” Peer-to-peer File Seeding Service and More Trojan:Win32/Sefnit.AT Trojan:Win32/Sefnit.gen!D 1aba915c0f75432f788fa672a6c7798af5acc94e 5afaadfe20c4776d12001212dc579f5d3851852b 9378acb5a7b6368e07ac2953459be911a84686cc 9dbca75ff98d49bdd211a2a7c8cac506789d6d29 a1733ba81255104c91e916943bb96875bf39d4d9 a5dd1b1d6105a773d1bdbdf961d36be2bbc56de1 abbd69ddb25b1b95c944b8fdb9531963556ea666 b55051915a2cc1a58284679d7753b55cb11bd9b0 d149bb1c2a4767f538a3de4d72f0a5d21ae46165 d95eb268e489928ed3d4bad8f56c0aa9ba0f0160 e50aa43d2df250ec56c92b4efd8df83e440cb167 edc7a434f18424d73c1403a15ee417fbd59eea95 “Windows Internet Name Service” Software Bundlers Trojan:Win32/Sefnit.AU c5758309136cd1e7e804d2003dc5ca27ae743ac3 n/a   Figure 2: Known Trojan:Win32/Sefnit Components  

Sefnit’s stealthy new click fraud methodology

The new Sefnit click fraud method is a departure from the method previously used back in 2011. This new, stealthier methodology is believed to be largely responsible for Sefnit being able to evade AV vendor detection during the last couple of years.

The old version of Sefnit relied on click hijacking for performing click fraud. When an infected user was browsing the internet and clicked on a search engine result (such as from Google), sometimes the clicks would be hijacked to travel through advertising agencies to a similar webpage as the intended destination. These clicks are generally considered quite high-value and are hard to detect from an anti-fraud perspective.

Although this is very stealthy from an advertising agency anti-fraud data analytics perspective, it is not stealthy for the user whose click was hijacked. If detection was missing, some observant users would realize they did not land at the intended website, investigate the cause, and submit samples to antimalware researchers for detection. As a result this always brought attention to the malware.

In 2011, the Sefnit authors were observed to have stopped releasing new versions of the component responsible for this click hijacking and consequently were later believed to no longer be active in the wild. At the end of June 2013, we rediscovered Sefnit using a new click fraud strategy.

The Sefnit click fraud component is now structured as a proxy service based on the open-source 3proxy project. The botnet of Sefnit-hosted proxies are used to relay HTTP traffic to pretend to click on advertisements.

In this way, the new version of Sefnit exhibits no clear visible user symptoms to bring attention to the botnet. This allowed them to evade attention from antimalware researchers for a couple years. The figure below illustrates how the hosted 3proxy servers are used to relay Internet traffic through the botnet clients to perform a fake advertisement click.

Figure 3: The Sefnit botnet uses the hosted 3proxy servers to redirect internet traffic and perform fake advertisement clicks

A recorded example of this click fraud path is shown below by using the legitimate affiliate search engine mywebsearch.com to simulate a search for "cat" and fake a click on an advertisement provided by Google to defraud the advertiser Groupon.

Figure 4: The landing page for a click fraud instance

The end result is Groupon paying a small amount of money for this fake advertisement "click" to Google. Google takes a portion of the money and pays the rest out to the website hosting the advertisement – mywebsearch. The Sefnit authors likely signed up as an affiliate for mywebsearch, resulting in the Sefnit criminals then receiving a commission on the click.

Sefnit authors avoid raising red flags on their advertisement affiliate accounts by preceding each clickfraud incident with a large time-gap and simulated normal user Internet browsing behaviour.

From experience, the interval between click fraud incidents is once per multiple-day period or longer. If the trojan simulates fake advertisement clicks too quickly, the anti-fraud team within the advertising agency would be able to detect the fraud, cancel the payout to the affiliate, and return the money to the defrauded advertisers.

Delivery by File Scout

We have been able to identify some of the infection vectors for the new version of Sefnit. One of the prominent methods is an installer for an application called "File Scout." When this application is installed, it will also install Trojan:Win32/Sefnit silently in the background:

Figure 5:  File Scout installer that silently installs Trojan:Win32/Sefnit as the same time

The installed File Scout application is a tool that replaces the standard "Open with" dialog for unrecognized files with a new dialog:

Figure 6:  File Scout replacement for the "Open with" dialog

There is evidence suggesting that this File Scout application is developed by the Trojan:Win32/Sefnit developers. Specifically, it expects a similar format xml structure for the C&C-download and execute commands, both applications are distributed together, and the two applications were compiled 15 minutes apart with the same compiler.

Similarly, Trojan:Win32/Sefnit bears code similarity to some InstallBrain software bundler installers, such as the same string encryption algorithm and the same packer.

We have also seen Trojan:Win32/Sefnit spread through the eMule peer-to-peer file network.

Downloading and running files from any peer-to-peer network as well as downloading applications from untrusted sources puts you at a high risk of being infected by malware.

This latest version of Sefnit shows they are using multiple attack vectors, even going as far as writing their own bundler installers to achieve the maximum number of infections that make this type of clickfraud a financially viable exercise.

The authors have adapted their click fraud mechanisms in a way that takes user interaction out of the picture while maintaining the effectiveness. This removal of the user-interaction reliance in the click fraud methodology was a large factor in the Sefnit authors being able to stay out of the security-researchers' radars over the last couple of years.

Microsoft is working towards thwarting this type of crime as we describe in another blog, "Another way Microsoft is disrupting the malware ecosystem." The more computers we can protect, the less financially viable this type of malware becomes.

We will continue to monitor the family and keep detection in place to limit further fraud by the criminals.

Geoff McDonald

MMPC

 
Categories: MDT

Mevade and Sefnit: Stealthy click fraud

The USMT team blog - Wed, 09/25/2013 - 21:30

​Recently Trojan:Win32/Mevade made news for being the first large botnet to use Tor to anonymize and hide its network traffic. Within a few weeks, starting mid-August, the number of directly connecting Tor users increased by almost 600 percent - from about 500,000 users per day to more than 3,000,000.

Last week we concluded, after further review, that Mevade and Sefnit are the same family and our detections for Mevade have now been moved to join the Sefnit family.

Win32/Sefnit is a well-known family which includes a component capable of performing click fraud. From our observations in the wild, this particular component disappeared near the end of 2011. In June 2013 we discovered a new click fraud component which we originally classified as Mevade.  

Despite its recent notoriety due to the Tor activity, there is still a bit of mystery around how the latest version of Sefnit is spreading and the monetization techniques it uses.

In this blog I’ll be going into a bit more detail on the new stealthy click fraud technique used and how it has contributed to Sefnit being largely undetected by AV vendors for the last couple of years. Additionally, we will discuss a few of the attack vectors used by the Sefnit authors to deliver the latest version of the malware.

Interestingly, TrendLabs now believe they have identified the online identities of the actors behind the threat.

An interconnected threat

The Sefnit threat is composed of multiple components dedicated to different tasks. Among the observed samples, we have identified three distinct components. Figure 1 illustrates what is known currently about how these components interconnect as well as their intended purpose. Figure 2 provides sample references.

Figure 1: The Sefnit malware structure

    Component Sha1 Subset Service Name Updater and Installer Service Trojan:Win32/Sefnit.AU 5451cfa12c9acfae6e91f7c13e4b946038bacef4 942860bedf408cc4c6a1831ef3744a3f9e68b375 “Adobe Flash Player Update Service” Click Fraud Service Trojan:Win32/Sefnit.AS 014ace48897e81052b9552a5a7ab04d00a8e5227 04bb63c3c71b4d033f49434f59a9225d08b4ea70 05a8fb5e61aad8be003a0ab461b39a86767fda23 0e246f6b95a9fd2d2a0c905be87074f5aadc7be0 0f8be849f287cf705ebc0409527fd06670438470 21bfcc14ac5abc6cb8b6fc802038e66ac4e24686 2d10aaf57c45bde69d8f52e23bdabc10a192da20 5d28316acb73e06a5f4c00858b3bf095cfe6b2bf 72d705af606df58aaaec3cc271f46d3d2e4c0499 7c5091177ea375eb3d1a4c4a2bbd5eb07a4cc5cc 8528769281709abd231a46f13ffdfaaa13232336 89c28f7203f9db0762d1c64e42422a5d89c6a83f a6b055df9ad3d374acaf2dfacded3ba88d20f5cd a7a41a0c6998f83839c5c6b58840b62a28714b17 a81b04724ab71e4a71e939204e476bb762adc506 bf4151bece1d94d8304df46b2598c14214d9834e c5af760e62f230ed0f55ff19d2c2215568e6a199 ccd1fa1bf48665270128700bc94043c5fec39984 “Trusted Installer”   “Bluetooth LE Services Control Protocol” Peer-to-peer File Seeding Service and More Trojan:Win32/Sefnit.AT Trojan:Win32/Sefnit.gen!D 1aba915c0f75432f788fa672a6c7798af5acc94e 5afaadfe20c4776d12001212dc579f5d3851852b 9378acb5a7b6368e07ac2953459be911a84686cc 9dbca75ff98d49bdd211a2a7c8cac506789d6d29 a1733ba81255104c91e916943bb96875bf39d4d9 a5dd1b1d6105a773d1bdbdf961d36be2bbc56de1 abbd69ddb25b1b95c944b8fdb9531963556ea666 b55051915a2cc1a58284679d7753b55cb11bd9b0 d149bb1c2a4767f538a3de4d72f0a5d21ae46165 d95eb268e489928ed3d4bad8f56c0aa9ba0f0160 e50aa43d2df250ec56c92b4efd8df83e440cb167 edc7a434f18424d73c1403a15ee417fbd59eea95 “Windows Internet Name Service” Software Bundlers Trojan:Win32/Sefnit.AU c5758309136cd1e7e804d2003dc5ca27ae743ac3 n/a   Figure 2: Known Trojan:Win32/Sefnit Components  

Sefnit’s stealthy new click fraud methodology

The new Sefnit click fraud method is a departure from the method previously used back in 2011. This new, stealthier methodology is believed to be largely responsible for Sefnit being able to evade AV vendor detection during the last couple of years.

The old version of Sefnit relied on click hijacking for performing click fraud. When an infected user was browsing the internet and clicked on a search engine result (such as from Google), sometimes the clicks would be hijacked to travel through advertising agencies to a similar webpage as the intended destination. These clicks are generally considered quite high-value and are hard to detect from an anti-fraud perspective.

Although this is very stealthy from an advertising agency anti-fraud data analytics perspective, it is not stealthy for the user whose click was hijacked. If detection was missing, some observant users would realize they did not land at the intended website, investigate the cause, and submit samples to antimalware researchers for detection. As a result this always brought attention to the malware.

In 2011, the Sefnit authors were observed to have stopped releasing new versions of the component responsible for this click hijacking and consequently were later believed to no longer be active in the wild. At the end of June 2013, we rediscovered Sefnit using a new click fraud strategy.

The Sefnit click fraud component is now structured as a proxy service based on the open-source 3proxy project. The botnet of Sefnit-hosted proxies are used to relay HTTP traffic to pretend to click on advertisements.

In this way, the new version of Sefnit exhibits no clear visible user symptoms to bring attention to the botnet. This allowed them to evade attention from antimalware researchers for a couple years. The figure below illustrates how the hosted 3proxy servers are used to relay Internet traffic through the botnet clients to perform a fake advertisement click.

Figure 3: The Sefnit botnet uses the hosted 3proxy servers to redirect internet traffic and perform fake advertisement clicks

A recorded example of this click fraud path is shown below by using the legitimate affiliate search engine mywebsearch.com to simulate a search for "cat" and fake a click on an advertisement provided by Google to defraud the advertiser Groupon.

Figure 4: The landing page for a click fraud instance

The end result is Groupon paying a small amount of money for this fake advertisement "click" to Google. Google takes a portion of the money and pays the rest out to the website hosting the advertisement – mywebsearch. The Sefnit authors likely signed up as an affiliate for mywebsearch, resulting in the Sefnit criminals then receiving a commission on the click.

Sefnit authors avoid raising red flags on their advertisement affiliate accounts by preceding each clickfraud incident with a large time-gap and simulated normal user Internet browsing behaviour.

From experience, the interval between click fraud incidents is once per multiple-day period or longer. If the trojan simulates fake advertisement clicks too quickly, the anti-fraud team within the advertising agency would be able to detect the fraud, cancel the payout to the affiliate, and return the money to the defrauded advertisers.

Delivery by File Scout

We have been able to identify some of the infection vectors for the new version of Sefnit. One of the prominent methods is an installer for an application called "File Scout." When this application is installed, it will also install Trojan:Win32/Sefnit silently in the background:

Figure 5:  File Scout installer that silently installs Trojan:Win32/Sefnit as the same time

The installed File Scout application is a tool that replaces the standard "Open with" dialog for unrecognized files with a new dialog:

Figure 6:  File Scout replacement for the "Open with" dialog

There is evidence suggesting that this File Scout application is developed by the Trojan:Win32/Sefnit developers. Specifically, it expects a similar format xml structure for the C&C-download and execute commands, both applications are distributed together, and the two applications were compiled 15 minutes apart with the same compiler.

Similarly, Trojan:Win32/Sefnit bears code similarity to some InstallBrain software bundler installers, such as the same string encryption algorithm and the same packer.

We have also seen Trojan:Win32/Sefnit spread through the eMule peer-to-peer file network.

Downloading and running files from any peer-to-peer network as well as downloading applications from untrusted sources puts you at a high risk of being infected by malware.

This latest version of Sefnit shows they are using multiple attack vectors, even going as far as writing their own bundler installers to achieve the maximum number of infections that make this type of clickfraud a financially viable exercise.

The authors have adapted their click fraud mechanisms in a way that takes user interaction out of the picture while maintaining the effectiveness. This removal of the user-interaction reliance in the click fraud methodology was a large factor in the Sefnit authors being able to stay out of the security-researchers' radars over the last couple of years.

Microsoft is working towards thwarting this type of crime as we describe in another blog, "Another way Microsoft is disrupting the malware ecosystem." The more computers we can protect, the less financially viable this type of malware becomes.

We will continue to monitor the family and keep detection in place to limit further fraud by the criminals.

Geoff McDonald

MMPC

 
Categories: MDT

Mevade and Sefnit: Stealthy click fraud

​Recently Trojan:Win32/Mevade made news for being the first large botnet to use Tor to anonymize and hide its network traffic. Within a few weeks, starting mid-August, the number of directly connecting Tor users increased by almost 600 percent - from about 500,000 users per day to more than 3,000,000.

Last week we concluded, after further review, that Mevade and Sefnit are the same family and our detections for Mevade have now been moved to join the Sefnit family.

Win32/Sefnit is a well-known family which includes a component capable of performing click fraud. From our observations in the wild, this particular component disappeared near the end of 2011. In June 2013 we discovered a new click fraud component which we originally classified as Mevade.  

Despite its recent notoriety due to the Tor activity, there is still a bit of mystery around how the latest version of Sefnit is spreading and the monetization techniques it uses.

In this blog I’ll be going into a bit more detail on the new stealthy click fraud technique used and how it has contributed to Sefnit being largely undetected by AV vendors for the last couple of years. Additionally, we will discuss a few of the attack vectors used by the Sefnit authors to deliver the latest version of the malware.

Interestingly, TrendLabs now believe they have identified the online identities of the actors behind the threat.

An interconnected threat

The Sefnit threat is composed of multiple components dedicated to different tasks. Among the observed samples, we have identified three distinct components. Figure 1 illustrates what is known currently about how these components interconnect as well as their intended purpose. Figure 2 provides sample references.

Figure 1: The Sefnit malware structure

    Component Sha1 Subset Service Name Updater and Installer Service Trojan:Win32/Sefnit.AU 5451cfa12c9acfae6e91f7c13e4b946038bacef4 942860bedf408cc4c6a1831ef3744a3f9e68b375 “Adobe Flash Player Update Service” Click Fraud Service Trojan:Win32/Sefnit.AS 014ace48897e81052b9552a5a7ab04d00a8e5227 04bb63c3c71b4d033f49434f59a9225d08b4ea70 05a8fb5e61aad8be003a0ab461b39a86767fda23 0e246f6b95a9fd2d2a0c905be87074f5aadc7be0 0f8be849f287cf705ebc0409527fd06670438470 21bfcc14ac5abc6cb8b6fc802038e66ac4e24686 2d10aaf57c45bde69d8f52e23bdabc10a192da20 5d28316acb73e06a5f4c00858b3bf095cfe6b2bf 72d705af606df58aaaec3cc271f46d3d2e4c0499 7c5091177ea375eb3d1a4c4a2bbd5eb07a4cc5cc 8528769281709abd231a46f13ffdfaaa13232336 89c28f7203f9db0762d1c64e42422a5d89c6a83f a6b055df9ad3d374acaf2dfacded3ba88d20f5cd a7a41a0c6998f83839c5c6b58840b62a28714b17 a81b04724ab71e4a71e939204e476bb762adc506 bf4151bece1d94d8304df46b2598c14214d9834e c5af760e62f230ed0f55ff19d2c2215568e6a199 ccd1fa1bf48665270128700bc94043c5fec39984 “Trusted Installer”   “Bluetooth LE Services Control Protocol” Peer-to-peer File Seeding Service and More Trojan:Win32/Sefnit.AT Trojan:Win32/Sefnit.gen!D 1aba915c0f75432f788fa672a6c7798af5acc94e 5afaadfe20c4776d12001212dc579f5d3851852b 9378acb5a7b6368e07ac2953459be911a84686cc 9dbca75ff98d49bdd211a2a7c8cac506789d6d29 a1733ba81255104c91e916943bb96875bf39d4d9 a5dd1b1d6105a773d1bdbdf961d36be2bbc56de1 abbd69ddb25b1b95c944b8fdb9531963556ea666 b55051915a2cc1a58284679d7753b55cb11bd9b0 d149bb1c2a4767f538a3de4d72f0a5d21ae46165 d95eb268e489928ed3d4bad8f56c0aa9ba0f0160 e50aa43d2df250ec56c92b4efd8df83e440cb167 edc7a434f18424d73c1403a15ee417fbd59eea95 “Windows Internet Name Service” Software Bundlers Trojan:Win32/Sefnit.AU c5758309136cd1e7e804d2003dc5ca27ae743ac3 n/a   Figure 2: Known Trojan:Win32/Sefnit Components  

Sefnit’s stealthy new click fraud methodology

The new Sefnit click fraud method is a departure from the method previously used back in 2011. This new, stealthier methodology is believed to be largely responsible for Sefnit being able to evade AV vendor detection during the last couple of years.

The old version of Sefnit relied on click hijacking for performing click fraud. When an infected user was browsing the internet and clicked on a search engine result (such as from Google), sometimes the clicks would be hijacked to travel through advertising agencies to a similar webpage as the intended destination. These clicks are generally considered quite high-value and are hard to detect from an anti-fraud perspective.

Although this is very stealthy from an advertising agency anti-fraud data analytics perspective, it is not stealthy for the user whose click was hijacked. If detection was missing, some observant users would realize they did not land at the intended website, investigate the cause, and submit samples to antimalware researchers for detection. As a result this always brought attention to the malware.

In 2011, the Sefnit authors were observed to have stopped releasing new versions of the component responsible for this click hijacking and consequently were later believed to no longer be active in the wild. At the end of June 2013, we rediscovered Sefnit using a new click fraud strategy.

The Sefnit click fraud component is now structured as a proxy service based on the open-source 3proxy project. The botnet of Sefnit-hosted proxies are used to relay HTTP traffic to pretend to click on advertisements.

In this way, the new version of Sefnit exhibits no clear visible user symptoms to bring attention to the botnet. This allowed them to evade attention from antimalware researchers for a couple years. The figure below illustrates how the hosted 3proxy servers are used to relay Internet traffic through the botnet clients to perform a fake advertisement click.

Figure 3: The Sefnit botnet uses the hosted 3proxy servers to redirect internet traffic and perform fake advertisement clicks

A recorded example of this click fraud path is shown below by using the legitimate affiliate search engine mywebsearch.com to simulate a search for "cat" and fake a click on an advertisement provided by Google to defraud the advertiser Groupon.

Figure 4: The landing page for a click fraud instance

The end result is Groupon paying a small amount of money for this fake advertisement "click" to Google. Google takes a portion of the money and pays the rest out to the website hosting the advertisement – mywebsearch. The Sefnit authors likely signed up as an affiliate for mywebsearch, resulting in the Sefnit criminals then receiving a commission on the click.

Sefnit authors avoid raising red flags on their advertisement affiliate accounts by preceding each clickfraud incident with a large time-gap and simulated normal user Internet browsing behaviour.

From experience, the interval between click fraud incidents is once per multiple-day period or longer. If the trojan simulates fake advertisement clicks too quickly, the anti-fraud team within the advertising agency would be able to detect the fraud, cancel the payout to the affiliate, and return the money to the defrauded advertisers.

Delivery by File Scout

We have been able to identify some of the infection vectors for the new version of Sefnit. One of the prominent methods is an installer for an application called "File Scout." When this application is installed, it will also install Trojan:Win32/Sefnit silently in the background:

Figure 5:  File Scout installer that silently installs Trojan:Win32/Sefnit as the same time

The installed File Scout application is a tool that replaces the standard "Open with" dialog for unrecognized files with a new dialog:

Figure 6:  File Scout replacement for the "Open with" dialog

There is evidence suggesting that this File Scout application is developed by the Trojan:Win32/Sefnit developers. Specifically, it expects a similar format xml structure for the C&C-download and execute commands, both applications are distributed together, and the two applications were compiled 15 minutes apart with the same compiler.

Similarly, Trojan:Win32/Sefnit bears code similarity to some InstallBrain software bundler installers, such as the same string encryption algorithm and the same packer.

We have also seen Trojan:Win32/Sefnit spread through the eMule peer-to-peer file network.

Downloading and running files from any peer-to-peer network as well as downloading applications from untrusted sources puts you at a high risk of being infected by malware.

This latest version of Sefnit shows they are using multiple attack vectors, even going as far as writing their own bundler installers to achieve the maximum number of infections that make this type of clickfraud a financially viable exercise.

The authors have adapted their click fraud mechanisms in a way that takes user interaction out of the picture while maintaining the effectiveness. This removal of the user-interaction reliance in the click fraud methodology was a large factor in the Sefnit authors being able to stay out of the security-researchers' radars over the last couple of years.

Microsoft is working towards thwarting this type of crime as we describe in another blog, "Another way Microsoft is disrupting the malware ecosystem." The more computers we can protect, the less financially viable this type of malware becomes.

We will continue to monitor the family and keep detection in place to limit further fraud by the criminals.

Geoff McDonald

MMPC

 
Categories: MDT

Mevade and Sefnit: Stealthy click fraud

The Deployment Guys - Wed, 09/25/2013 - 21:30

​Recently Trojan:Win32/Mevade made news for being the first large botnet to use Tor to anonymize and hide its network traffic. Within a few weeks, starting mid-August, the number of directly connecting Tor users increased by almost 600 percent - from about 500,000 users per day to more than 3,000,000.

Last week we concluded, after further review, that Mevade and Sefnit are the same family and our detections for Mevade have now been moved to join the Sefnit family.

Win32/Sefnit is a well-known family which includes a component capable of performing click fraud. From our observations in the wild, this particular component disappeared near the end of 2011. In June 2013 we discovered a new click fraud component which we originally classified as Mevade.  

Despite its recent notoriety due to the Tor activity, there is still a bit of mystery around how the latest version of Sefnit is spreading and the monetization techniques it uses.

In this blog I’ll be going into a bit more detail on the new stealthy click fraud technique used and how it has contributed to Sefnit being largely undetected by AV vendors for the last couple of years. Additionally, we will discuss a few of the attack vectors used by the Sefnit authors to deliver the latest version of the malware.

Interestingly, TrendLabs now believe they have identified the online identities of the actors behind the threat.

An interconnected threat

The Sefnit threat is composed of multiple components dedicated to different tasks. Among the observed samples, we have identified three distinct components. Figure 1 illustrates what is known currently about how these components interconnect as well as their intended purpose. Figure 2 provides sample references.

Figure 1: The Sefnit malware structure

    Component Sha1 Subset Service Name Updater and Installer Service Trojan:Win32/Sefnit.AU 5451cfa12c9acfae6e91f7c13e4b946038bacef4 942860bedf408cc4c6a1831ef3744a3f9e68b375 “Adobe Flash Player Update Service” Click Fraud Service Trojan:Win32/Sefnit.AS 014ace48897e81052b9552a5a7ab04d00a8e5227 04bb63c3c71b4d033f49434f59a9225d08b4ea70 05a8fb5e61aad8be003a0ab461b39a86767fda23 0e246f6b95a9fd2d2a0c905be87074f5aadc7be0 0f8be849f287cf705ebc0409527fd06670438470 21bfcc14ac5abc6cb8b6fc802038e66ac4e24686 2d10aaf57c45bde69d8f52e23bdabc10a192da20 5d28316acb73e06a5f4c00858b3bf095cfe6b2bf 72d705af606df58aaaec3cc271f46d3d2e4c0499 7c5091177ea375eb3d1a4c4a2bbd5eb07a4cc5cc 8528769281709abd231a46f13ffdfaaa13232336 89c28f7203f9db0762d1c64e42422a5d89c6a83f a6b055df9ad3d374acaf2dfacded3ba88d20f5cd a7a41a0c6998f83839c5c6b58840b62a28714b17 a81b04724ab71e4a71e939204e476bb762adc506 bf4151bece1d94d8304df46b2598c14214d9834e c5af760e62f230ed0f55ff19d2c2215568e6a199 ccd1fa1bf48665270128700bc94043c5fec39984 “Trusted Installer”   “Bluetooth LE Services Control Protocol” Peer-to-peer File Seeding Service and More Trojan:Win32/Sefnit.AT Trojan:Win32/Sefnit.gen!D 1aba915c0f75432f788fa672a6c7798af5acc94e 5afaadfe20c4776d12001212dc579f5d3851852b 9378acb5a7b6368e07ac2953459be911a84686cc 9dbca75ff98d49bdd211a2a7c8cac506789d6d29 a1733ba81255104c91e916943bb96875bf39d4d9 a5dd1b1d6105a773d1bdbdf961d36be2bbc56de1 abbd69ddb25b1b95c944b8fdb9531963556ea666 b55051915a2cc1a58284679d7753b55cb11bd9b0 d149bb1c2a4767f538a3de4d72f0a5d21ae46165 d95eb268e489928ed3d4bad8f56c0aa9ba0f0160 e50aa43d2df250ec56c92b4efd8df83e440cb167 edc7a434f18424d73c1403a15ee417fbd59eea95 “Windows Internet Name Service” Software Bundlers Trojan:Win32/Sefnit.AU c5758309136cd1e7e804d2003dc5ca27ae743ac3 n/a   Figure 2: Known Trojan:Win32/Sefnit Components  

Sefnit’s stealthy new click fraud methodology

The new Sefnit click fraud method is a departure from the method previously used back in 2011. This new, stealthier methodology is believed to be largely responsible for Sefnit being able to evade AV vendor detection during the last couple of years.

The old version of Sefnit relied on click hijacking for performing click fraud. When an infected user was browsing the internet and clicked on a search engine result (such as from Google), sometimes the clicks would be hijacked to travel through advertising agencies to a similar webpage as the intended destination. These clicks are generally considered quite high-value and are hard to detect from an anti-fraud perspective.

Although this is very stealthy from an advertising agency anti-fraud data analytics perspective, it is not stealthy for the user whose click was hijacked. If detection was missing, some observant users would realize they did not land at the intended website, investigate the cause, and submit samples to antimalware researchers for detection. As a result this always brought attention to the malware.

In 2011, the Sefnit authors were observed to have stopped releasing new versions of the component responsible for this click hijacking and consequently were later believed to no longer be active in the wild. At the end of June 2013, we rediscovered Sefnit using a new click fraud strategy.

The Sefnit click fraud component is now structured as a proxy service based on the open-source 3proxy project. The botnet of Sefnit-hosted proxies are used to relay HTTP traffic to pretend to click on advertisements.

In this way, the new version of Sefnit exhibits no clear visible user symptoms to bring attention to the botnet. This allowed them to evade attention from antimalware researchers for a couple years. The figure below illustrates how the hosted 3proxy servers are used to relay Internet traffic through the botnet clients to perform a fake advertisement click.

Figure 3: The Sefnit botnet uses the hosted 3proxy servers to redirect internet traffic and perform fake advertisement clicks

A recorded example of this click fraud path is shown below by using the legitimate affiliate search engine mywebsearch.com to simulate a search for "cat" and fake a click on an advertisement provided by Google to defraud the advertiser Groupon.

Figure 4: The landing page for a click fraud instance

The end result is Groupon paying a small amount of money for this fake advertisement "click" to Google. Google takes a portion of the money and pays the rest out to the website hosting the advertisement – mywebsearch. The Sefnit authors likely signed up as an affiliate for mywebsearch, resulting in the Sefnit criminals then receiving a commission on the click.

Sefnit authors avoid raising red flags on their advertisement affiliate accounts by preceding each clickfraud incident with a large time-gap and simulated normal user Internet browsing behaviour.

From experience, the interval between click fraud incidents is once per multiple-day period or longer. If the trojan simulates fake advertisement clicks too quickly, the anti-fraud team within the advertising agency would be able to detect the fraud, cancel the payout to the affiliate, and return the money to the defrauded advertisers.

Delivery by File Scout

We have been able to identify some of the infection vectors for the new version of Sefnit. One of the prominent methods is an installer for an application called "File Scout." When this application is installed, it will also install Trojan:Win32/Sefnit silently in the background:

Figure 5:  File Scout installer that silently installs Trojan:Win32/Sefnit as the same time

The installed File Scout application is a tool that replaces the standard "Open with" dialog for unrecognized files with a new dialog:

Figure 6:  File Scout replacement for the "Open with" dialog

There is evidence suggesting that this File Scout application is developed by the Trojan:Win32/Sefnit developers. Specifically, it expects a similar format xml structure for the C&C-download and execute commands, both applications are distributed together, and the two applications were compiled 15 minutes apart with the same compiler.

Similarly, Trojan:Win32/Sefnit bears code similarity to some InstallBrain software bundler installers, such as the same string encryption algorithm and the same packer.

We have also seen Trojan:Win32/Sefnit spread through the eMule peer-to-peer file network.

Downloading and running files from any peer-to-peer network as well as downloading applications from untrusted sources puts you at a high risk of being infected by malware.

This latest version of Sefnit shows they are using multiple attack vectors, even going as far as writing their own bundler installers to achieve the maximum number of infections that make this type of clickfraud a financially viable exercise.

The authors have adapted their click fraud mechanisms in a way that takes user interaction out of the picture while maintaining the effectiveness. This removal of the user-interaction reliance in the click fraud methodology was a large factor in the Sefnit authors being able to stay out of the security-researchers' radars over the last couple of years.

Microsoft is working towards thwarting this type of crime as we describe in another blog, "Another way Microsoft is disrupting the malware ecosystem." The more computers we can protect, the less financially viable this type of malware becomes.

We will continue to monitor the family and keep detection in place to limit further fraud by the criminals.

Geoff McDonald

MMPC

 
Categories: MDT

System Center Community/MVP Update

Microsoft Deployment Toolkit Team Blog - Wed, 09/25/2013 - 17:05

As many of you have probably seen today, I have announced my resignation from Microsoft to go to a System Center partner company.  Friday will be my last official day at Microsoft, but I don’t plan on changing my personal level of commitment to the System Center community.  I’ll still be blogging, answering questions on forums, presenting at conferences, and working very closely with Microsoft on channeling the feedback I see on the community into building great solutions.

For me, this move is simply one of those situations where it was an opportunity for me to feed my inner entrepreneur and software developer.  System Center is alive and well.  Amazing things are happening and will continue to happen.  I’m excited to continue to be a part of the evolution of System Center, albeit in a different role.

I recently hired System Center MVP Christian Booth (@chbooth) to my team at Microsoft.  I am especially thankful today that he is filling my shoes.  He is an outstanding community contributor, extremely knowledgeable about System Center, and influential inside and out of Microsoft.  He has been and will continue to manage Microsoft’s relationship with the System Center Cloud and Datacenter Management MVPs and community at large.

Microsoft also has a phenomenal team of people sitting literally right next to Christian that are producing really great content around Windows Server and System Center on the Building Clouds blog.  Definitely check that out!

Microsoft is committed to community.  I’m committed to the community.  Not much really changes except for my email address.  I’ll see you out there!

Categories: MDT

System Center Community/MVP Update

The USMT team blog - Wed, 09/25/2013 - 17:05

As many of you have probably seen today, I have announced my resignation from Microsoft to go to a System Center partner company.  Friday will be my last official day at Microsoft, but I don’t plan on changing my personal level of commitment to the System Center community.  I’ll still be blogging, answering questions on forums, presenting at conferences, and working very closely with Microsoft on channeling the feedback I see on the community into building great solutions.

For me, this move is simply one of those situations where it was an opportunity for me to feed my inner entrepreneur and software developer.  System Center is alive and well.  Amazing things are happening and will continue to happen.  I’m excited to continue to be a part of the evolution of System Center, albeit in a different role.

I recently hired System Center MVP Christian Booth (@chbooth) to my team at Microsoft.  I am especially thankful today that he is filling my shoes.  He is an outstanding community contributor, extremely knowledgeable about System Center, and influential inside and out of Microsoft.  He has been and will continue to manage Microsoft’s relationship with the System Center Cloud and Datacenter Management MVPs and community at large.

Microsoft also has a phenomenal team of people sitting literally right next to Christian that are producing really great content around Windows Server and System Center on the Building Clouds blog.  Definitely check that out!

Microsoft is committed to community.  I’m committed to the community.  Not much really changes except for my email address.  I’ll see you out there!

Categories: MDT

System Center Community/MVP Update

As many of you have probably seen today, I have announced my resignation from Microsoft to go to a System Center partner company.  Friday will be my last official day at Microsoft, but I don’t plan on changing my personal level of commitment to the System Center community.  I’ll still be blogging, answering questions on forums, presenting at conferences, and working very closely with Microsoft on channeling the feedback I see on the community into building great solutions.

For me, this move is simply one of those situations where it was an opportunity for me to feed my inner entrepreneur and software developer.  System Center is alive and well.  Amazing things are happening and will continue to happen.  I’m excited to continue to be a part of the evolution of System Center, albeit in a different role.

I recently hired System Center MVP Christian Booth (@chbooth) to my team at Microsoft.  I am especially thankful today that he is filling my shoes.  He is an outstanding community contributor, extremely knowledgeable about System Center, and influential inside and out of Microsoft.  He has been and will continue to manage Microsoft’s relationship with the System Center Cloud and Datacenter Management MVPs and community at large.

Microsoft also has a phenomenal team of people sitting literally right next to Christian that are producing really great content around Windows Server and System Center on the Building Clouds blog.  Definitely check that out!

Microsoft is committed to community.  I’m committed to the community.  Not much really changes except for my email address.  I’ll see you out there!

Categories: MDT

System Center Community/MVP Update

The Deployment Guys - Wed, 09/25/2013 - 17:05

As many of you have probably seen today, I have announced my resignation from Microsoft to go to a System Center partner company.  Friday will be my last official day at Microsoft, but I don’t plan on changing my personal level of commitment to the System Center community.  I’ll still be blogging, answering questions on forums, presenting at conferences, and working very closely with Microsoft on channeling the feedback I see on the community into building great solutions.

For me, this move is simply one of those situations where it was an opportunity for me to feed my inner entrepreneur and software developer.  System Center is alive and well.  Amazing things are happening and will continue to happen.  I’m excited to continue to be a part of the evolution of System Center, albeit in a different role.

I recently hired System Center MVP Christian Booth (@chbooth) to my team at Microsoft.  I am especially thankful today that he is filling my shoes.  He is an outstanding community contributor, extremely knowledgeable about System Center, and influential inside and out of Microsoft.  He has been and will continue to manage Microsoft’s relationship with the System Center Cloud and Datacenter Management MVPs and community at large.

Microsoft also has a phenomenal team of people sitting literally right next to Christian that are producing really great content around Windows Server and System Center on the Building Clouds blog.  Definitely check that out!

Microsoft is committed to community.  I’m committed to the community.  Not much really changes except for my email address.  I’ll see you out there!

Categories: MDT

End of support for Java SE 6

Microsoft Deployment Toolkit Team Blog - Tue, 09/24/2013 - 18:20

​If you’re running Java SE 6, we have some news for you: Oracle stopped providing public updates to it after February 2013.

Enterprise customers will still have access to long term help through their support channels.

For everyone else, you should upgrade to Java SE 7 and remove Java SE 6 - remember Java doesn’t remove older versions by default. 

Malware exploiting vulnerabilities in Java isn’t new. We’ve written about Java vulnerabilities on this blog before. In fact, since July this year Exploit:Java/CVE-2013-2465 has been making the rounds and targeting Java SE 6.

Oracle has done a great job of releasing Java updates to patch these vulnerabilities.

However, Java SE 6 is about seven years old, and Java SE 7 was released more than two years ago. This means it’s time to think about alternatives for the aging version.

While we’re talking about end-of-support software - technical assistance for Windows XP will no longer be available from April 8, 2014.

This includes the updates that help protect your PC against security risks and malware. It’s a good time to think about installing Windows 8 on your PC.

 
Categories: MDT

End of support for Java SE 6

The USMT team blog - Tue, 09/24/2013 - 18:20

​If you’re running Java SE 6, we have some news for you: Oracle stopped providing public updates to it after February 2013.

Enterprise customers will still have access to long term help through their support channels.

For everyone else, you should upgrade to Java SE 7 and remove Java SE 6 - remember Java doesn’t remove older versions by default. 

Malware exploiting vulnerabilities in Java isn’t new. We’ve written about Java vulnerabilities on this blog before. In fact, since July this year Exploit:Java/CVE-2013-2465 has been making the rounds and targeting Java SE 6.

Oracle has done a great job of releasing Java updates to patch these vulnerabilities.

However, Java SE 6 is about seven years old, and Java SE 7 was released more than two years ago. This means it’s time to think about alternatives for the aging version.

While we’re talking about end-of-support software - technical assistance for Windows XP will no longer be available from April 8, 2014.

This includes the updates that help protect your PC against security risks and malware. It’s a good time to think about installing Windows 8 on your PC.

 
Categories: MDT

End of support for Java SE 6

​If you’re running Java SE 6, we have some news for you: Oracle stopped providing public updates to it after February 2013.

Enterprise customers will still have access to long term help through their support channels.

For everyone else, you should upgrade to Java SE 7 and remove Java SE 6 - remember Java doesn’t remove older versions by default. 

Malware exploiting vulnerabilities in Java isn’t new. We’ve written about Java vulnerabilities on this blog before. In fact, since July this year Exploit:Java/CVE-2013-2465 has been making the rounds and targeting Java SE 6.

Oracle has done a great job of releasing Java updates to patch these vulnerabilities.

However, Java SE 6 is about seven years old, and Java SE 7 was released more than two years ago. This means it’s time to think about alternatives for the aging version.

While we’re talking about end-of-support software - technical assistance for Windows XP will no longer be available from April 8, 2014.

This includes the updates that help protect your PC against security risks and malware. It’s a good time to think about installing Windows 8 on your PC.

 
Categories: MDT

End of support for Java SE 6

The Deployment Guys - Tue, 09/24/2013 - 18:20

​If you’re running Java SE 6, we have some news for you: Oracle stopped providing public updates to it after February 2013.

Enterprise customers will still have access to long term help through their support channels.

For everyone else, you should upgrade to Java SE 7 and remove Java SE 6 - remember Java doesn’t remove older versions by default. 

Malware exploiting vulnerabilities in Java isn’t new. We’ve written about Java vulnerabilities on this blog before. In fact, since July this year Exploit:Java/CVE-2013-2465 has been making the rounds and targeting Java SE 6.

Oracle has done a great job of releasing Java updates to patch these vulnerabilities.

However, Java SE 6 is about seven years old, and Java SE 7 was released more than two years ago. This means it’s time to think about alternatives for the aging version.

While we’re talking about end-of-support software - technical assistance for Windows XP will no longer be available from April 8, 2014.

This includes the updates that help protect your PC against security risks and malware. It’s a good time to think about installing Windows 8 on your PC.

 
Categories: MDT

Hyper-V Replica and Active Directory

Virtual PC Guy's WebLog - Mon, 09/23/2013 - 15:08

Continuing the story of how I am using Hyper-V Replica in my house – we arrive at the interesting discussion of Hyper-V Replica and Active Directory.  This first thing to point out is that if you are running Windows Server 2012 or later for your domain controllers, this is a fully supported configuration (official documentation here: http://technet.microsoft.com/en-us/library/dn250021.aspx). 

However, a question that I have received a couple of times now is “Should I use Hyper-V Replica or Active Directory replication?”

My answer to this question is usually “both!”.  Which is exactly what I do in my house.  I have two Hyper-V servers and two Active Directory virtual machine – each of which is being protected by Hyper-V Replica.

Why am I doing this?

Well, Active Directory replication provides me with automatic protection from downtime.  By keeping the two domain controllers running on different physical servers I can ensure that I always have domain services available, even in the event of hardware failure.  Adding Hyper-V Replica to this equation means that if I lose a physical computer – I do not have to go through the process of building a new domain controller.  I just failover to the replicated copy.  In this way, using both technologies gives me the best experience for handling a failure and for recovering from a failure.

Cheers,
Ben

Categories: MDT

The Coretech Software Update Management Tool

Coretech Blog » Kent Agerlund - Fri, 09/20/2013 - 07:45
As demonstrated @TechEd in Australia and New Zealand our latest free tool is the Software Update Management Tool. The sole purpose of the tool is to automate the creation of software update deployments. The benefits of using the tool are: All deployments will be using the same naming standard. the naming standard is WRK/SRV + […]
Categories: MDT

Planned or unplanned failover with Hyper-V Replica?

Virtual PC Guy's WebLog - Mon, 09/16/2013 - 16:37

As you hopefully know – I have been running Hyper-V Replica in my house for about a year now.  In this time I have had a couple of instances when I had to take a step back and ask myself if I wanted to do a planned or an unplanned failover of a virtual machine.

To bring everyone up-to-speed here:  planned failover of replicated virtual machine involves logging into the source computer, shutting down the virtual machine that you want to failover, and then selecting to perform a planned failover.  Hyper-V will ensure that the two virtual machines are completely in sync and will orchestrate the process in a way that ensures no data loss.  Unplanned failover is where you go to the recovery site and just power up the virtual machine, incurring some amount of data loss in the process.

At first glace, you would assume that you always wanted to do a planned failover if possible.  But in my experience there are times when a planned failover is possible, but an unplanned failover is preferable.

Let me explain with a real-life situation I had to deal with.

One morning as I am about to leave for work – my wife calls out to me and says that the Internet isn’t working.  I duck into my little server room and look around.  Sure enough one of my Hyper-V servers is off, and will not turn on.  5 minutes later I have confirmed that it is a failed power-supply, I have replaced the power-supply, and I am booting the server.

Now, the replacement power-supply that I grabbed is not server grade (it is an old desktop power-supply that I had sitting on a shelf).  So my initial thoughts were:

    1. I will boot the server off of this power-supply
    2. I will use Hyper-V replica to perform planned failovers of the virtual machines
    3. I will then leave the server (with no active virtual machines on it) running through the day.  If it fails, it is not the end of the world.
    4. I will grab a new power-supply today and install it tonight

As I started working on this plan – my head was starting to do some math.  All up this would not take long, probably 15 minutes – but I was already late for work.  Furthermore; the virtual machines had all been turned off since the power-supply failure had happened – so there really wasn’t any significant data that would not have been replicated.  Finally, all the virtual machines that had been on the failed physical server were largely stateless (firewall, VPN, etc…) my fileserver virtual machine had been on the other server.

Once I put all of these facts together I realized that I could just leave the failed server off and perform an unplanned failover on each of the virtual machines.  This would take under 5 minutes and I would be on my way.

Which was exactly what I did.

You may be wondering if this would cause problems when I tried to startup the failed Hyper-V server later in the day (with duplicate virtual machines and the like) but this is something that Hyper-V handles for you automatically.  When I did replace the power-supply and start up the physical computer, Hyper-V detected that the replica virtual machines were running and did not start the primary virtual machines.

I did have to go in and manually correct the replication relationship when I got all my hardware up and running – but using unplanned failover provided me exactly the functionality I needed, while minimizing the amount of time that I had to spend getting my virtual machines up and running.

Cheers,
Ben

Categories: MDT

Grabbing out-of-box drivers from a Windows 8 system

It seems like a common request:  I’ve got a brand new system, right out of the box from the OEM.  It has all the drivers on it that are needed.  So rather than find and download those same drivers from the OEM’s website, why can’t I just extract the drivers from OS that’s already on the system?

Well, you can – with some caveats described below.  I’ve never been a big fan of this approach due to those caveats, but it can work well in some scenarios.  It’s a little scary that people will download random utilities from random websites to do this though, especially when it’s so easy to do on Windows 8 and above using PowerShell.

So attached to this blog is a script for doing just that.  It’s really quite simple, as it leverages the “Get-WindowsDriver” PowerShell cmdlet to get the list of out-of-box drivers (which is what the cmdlet does by default).  The meat of it:

Get-WindowsDriver -online | % {
   $dir = Split-Path $_.OriginalFileName -Parent ;
   $subdir = Split-Path $dir -Leaf ;
   $driverDest = "$destination\$subdir";
   Write-Host "Copying $dir to $driverDest\$subdir" ;
   Copy-Item -Path $dir -Destination $driverDest -Recurse
}

(Don’t try to copy and paste this, unless you set the $destination variable manually.  The attached script is set up as a cmdlet and will prompt for that destination path, which should already exist.  The attached script also includes the required disclaimer that says this isn’t supported by Microsoft in any way.)

The logic is fairly simple:

  • For each out-of-box driver, get the original file name, which is the full path to the INF file in the driver repository folder, e.g. C:\Windows\System32\DriverStore\FileRepository\driverFolder\driver.inf. 
  • Chop the file name off of that to get the folder path, e.g. C:\Windows\System32\DriverStore\FileRepository\driverFolder. 
  • Chop the folder name from that path to use in the destination, e.g. driverFolder.
  • Copy from source to destination.

That’s it.  Give it a few minutes to run (the Get-WindowsDriver cmdlet will take a little while to execute as it sifts through all the drivers), then look at the destination folder you specified to see all the drivers.

Now for the caveats:

  • This assumes that all the files required for the driver and/or device are present in the driver folder.  While the core driver files should be there, any applets, control panels, shell extensions, etc. might not be.  So you might need to install the full OEM package to get complete functionality.  In some cases, the driver may not even work without this (e.g. Bluetooth, mobile broadband).
  • You might get more drivers than you really need.  For example, my laptop has over 100 out-of-box drivers.  Does it really need 100 drivers to work?  No, it only needs 6-7.  Some are older versions, some are for various USB devices that I’ve attached in the last year (printers, cameras, headsets, DisplayPort docks, etc.), some I have no idea where they came from.  So the cleaner the system is, the better.
  • You will probably get old versions.  The images that OEMs ship on new machines aren’t always kept up to date, so you might find that those original drivers have “issues” – some will get updated immediately from Windows Update, others will require updating from the OEM’s website anyway.  (I would definitely check for the latest video and network drivers regardless.)

Good luck.

Categories: MDT

Grabbing out-of-box drivers from a Windows 8 system

It seems like a common request:  I’ve got a brand new system, right out of the box from the OEM.  It has all the drivers on it that are needed.  So rather than find and download those same drivers from the OEM’s website, why can’t I just extract the drivers from OS that’s already on the system?

Well, you can – with some caveats described below.  I’ve never been a big fan of this approach due to those caveats, but it can work well in some scenarios.  It’s a little scary that people will download random utilities from random websites to do this though, especially when it’s so easy to do on Windows 8 and above using PowerShell.

So attached to this blog is a script for doing just that.  It’s really quite simple, as it leverages the “Get-WindowsDriver” PowerShell cmdlet to get the list of out-of-box drivers (which is what the cmdlet does by default).  The meat of it:

Get-WindowsDriver -online | % {
   $dir = Split-Path $_.OriginalFileName -Parent ;
   $subdir = Split-Path $dir -Leaf ;
   $driverDest = "$destination\$subdir";
   Write-Host "Copying $dir to $driverDest\$subdir" ;
   Copy-Item -Path $dir -Destination $driverDest -Recurse
}

(Don’t try to copy and paste this, unless you set the $destination variable manually.  The attached script is set up as a cmdlet and will prompt for that destination path, which should already exist.  The attached script also includes the required disclaimer that says this isn’t supported by Microsoft in any way.)

The logic is fairly simple:

  • For each out-of-box driver, get the original file name, which is the full path to the INF file in the driver repository folder, e.g. C:\Windows\System32\DriverStore\FileRepository\driverFolder\driver.inf. 
  • Chop the file name off of that to get the folder path, e.g. C:\Windows\System32\DriverStore\FileRepository\driverFolder. 
  • Chop the folder name from that path to use in the destination, e.g. driverFolder.
  • Copy from source to destination.

That’s it.  Give it a few minutes to run (the Get-WindowsDriver cmdlet will take a little while to execute as it sifts through all the drivers), then look at the destination folder you specified to see all the drivers.

Now for the caveats:

  • This assumes that all the files required for the driver and/or device are present in the driver folder.  While the core driver files should be there, any applets, control panels, shell extensions, etc. might not be.  So you might need to install the full OEM package to get complete functionality.  In some cases, the driver may not even work without this (e.g. Bluetooth, mobile broadband).
  • You might get more drivers than you really need.  For example, my laptop has over 100 out-of-box drivers.  Does it really need 100 drivers to work?  No, it only needs 6-7.  Some are older versions, some are for various USB devices that I’ve attached in the last year (printers, cameras, headsets, DisplayPort docks, etc.), some I have no idea where they came from.  So the cleaner the system is, the better.
  • You will probably get old versions.  The images that OEMs ship on new machines aren’t always kept up to date, so you might find that those original drivers have “issues” – some will get updated immediately from Windows Update, others will require updating from the OEM’s website anyway.  (I would definitely check for the latest video and network drivers regardless.)

Good luck.

Categories: MDT

Loading Scripts that Have VBScript Classes or that Don’t Have a UserExit Function as User Exit Scripts

The Deployment Guys - Fri, 09/13/2013 - 18:53

Most readers of this blog should be familiar with MDT User Exit scripts, as many of the posts provided them for many scenarios.  In case you are not, the MDT help file defines them this way:

“A user exit script is effectively a function library that can be called during the processing of the CustomSettings.ini file using the UserExit directive. A user exit script contains one or more functions that can be called during the process of the CustomSettings.ini file.”

User exit scripts are a great way to extend the Gather process. However, how ZTIGather.wsf actually process user exit scripts has implications for which scripts you can use as user exit scripts.

When ZTIGather.wsf finds a UserExit entry in a CustomSettings.ini section, it actually processes the user exit script twice, once at the beginning of the section processing and once at the end.  When it does this it first loads the contents of the user exit script file into a string variable, executes the loaded code in the global namespace of a script using the VBScript ExecuteGlobal statement, and then calls the UserExit function that is included in the script.

The UserExit function I usually include is similar to this and requires the function signature (set of parameters) shown below:

Function UserExit(sType, sWhen, sDetail, bSkip)
    oLogging.CreateEntry "USEREXIT:TestUserExit.vbs started: " & sType & " " & sWhen & " " & sDetail, LogTypeInfo
    UserExit = Success
End Function

The sType input parameter is always called with a value of "SECTION".  The sWhen input parameter is called with "BEFORE" at the beginning of section processing and "AFTER" at the end of section processing.  The sDetail input parameter is the CustomSettings.ini section name.  The bSkip parameter is a return parameter.  If bSkip is set to True in the UserExit function when it is called at the beginning of section processing, the rest of that section in CustomSettings.ini is skipped.

This behavior allows you to run different code at the beginning or end of section processing or skip section processing based on code run at the beginning of section processing like the trivial samples shown below.

Function UserExit(sType, sWhen, sDetail, bSkip)
    oLogging.CreateEntry "USEREXIT:TestUserExit.vbs started: " & sType & " " & sWhen & " " & sDetail, LogTypeInfo
    If sWhen = "BEFORE" Then oEnvironment.Item("WhenProperty") = "Before"
    If sWhen = "AFTER" Then oEnvironment.Item("WhenProperty") = "After"
    UserExit = Success
End Function

Function UserExit(sType, sWhen, sDetail, bSkip)
    oLogging.CreateEntry "USEREXIT:TestUserExit.vbs started: " & sType & " " & sWhen & " " & sDetail, LogTypeInfo
    If TestCondition = False Then bSkip = True
    UserExit = Success
End Function

While this functionality is interesting, I have never had any occasion where I needed to use it.  I only know one person who has put logic in a UserExit function, fellow Deployment Guy Dave Hornbaker.  So why did I bother explaining it to you?  Well, as I said earlier it has implications for which scripts you can use as user exit scripts.

The first is that any script you want to use as a user exit script must have a UserExit function.  Fellow Deployment Guy Dave Hornbaker once needed to use ZTIDiskUtility.vbs functions in one of his user exit scripts.  Now he could have either added a UserExit function to ZTIDiskUtility.vbs so it could be used as a user exit script directly as well or added a script tag to ZTIGather.wsf that referenced ZTIDiskUtility.vbs.  However, we generally recommend against modifying the scripts that ship with MDT unless it is absolutely necessary.  If you do, then you have to remember to redo those changes when applying an update to MDT.

The second is that the when a user exit script contains VBScript Classes, the second ExecuteGlobal of the contents at the end of section processing fails with a “name redefined” error.  This causes ZTIGather.wsf execution to fail.

To overcome both of these limitations, I created a user exit script (MDTExitInclude.vbs) with a function called Include that only loads the contents of a VBScript file into a string variable, executes the loaded code using the VBScript ExecuteGlobal statement, and only does this once.  So while this does not allow the little-used section processing control behavior I described above, this function essentially allows you to use any VBScript as a user exit script.

After adding MDTExitInclude.vbs to Scripts folder in the LTI Deployment Share or ConfigMgr MDT Toolkit package, modify CustomSetting.ini similar to the example below to load MDTExitInclude.vbs as a user exit script and then load another script using the Include function.  This sample loads a script named TestUserExit.vbs and make functions inside it available for use.

[Settings]
Priority=IncludeScript, Default
Properties=IncludeResult

[IncludeScript]
UserExit=IncludeExit.vbs
IncludeResult=#Include("TestUserExit.vbs")#

One other advantage of loading user exit scripts in this fashion is that it simplifies loading multiple scripts.  For example, I recently needed to load five user exit scripts for one deployment.  Normally this would require creating five sections in CustomSettings.ini since you can only have one UserExit directive per section.  Using MDTExitInclude.vbs you can load as many scripts as you want in a single section like this:

[Settings]
Priority=IncludeExitScripts, Default
Properties=ExitScripts(*)

[IncludeExitScripts]
UserExit=MDTExitInclude.vbs
ExitScripts001=#Include("MDTLibHelperClasses.vbs")#
ExitScripts002=#Include("ModelAliasExit.vbs")#
ExitScripts003=#Include("MDTConfigMgrFunctions.vbs")#
ExitScripts004=#Include("MDTExitGetCollectionAdvertsDeploys.vbs")#
ExitScripts005=#Include("MDTExitGetResourceAdvertsDeploys.vbs")#

This sample uses one “throw away” list item, ExitScripts, to execute the Include function for each script.  This avoids “Settings section bloat” by not requiring multiple entries in the Priority or Properties line for just loading multiple scripts.

 

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Categories: MDT

Loading Scripts that Have VBScript Classes or that Don’t Have a UserExit Function as User Exit Scripts

The Deployment Guys - Fri, 09/13/2013 - 18:53

Most readers of this blog should be familiar with MDT User Exit scripts, as many of the posts provided them for many scenarios.  In case you are not, the MDT help file defines them this way:

“A user exit script is effectively a function library that can be called during the processing of the CustomSettings.ini file using the UserExit directive. A user exit script contains one or more functions that can be called during the process of the CustomSettings.ini file.”

User exit scripts are a great way to extend the Gather process. However, how ZTIGather.wsf actually process user exit scripts has implications for which scripts you can use as user exit scripts.

When ZTIGather.wsf finds a UserExit entry in a CustomSettings.ini section, it actually processes the user exit script twice, once at the beginning of the section processing and once at the end.  When it does this it first loads the contents of the user exit script file into a string variable, executes the loaded code in the global namespace of a script using the VBScript ExecuteGlobal statement, and then calls the UserExit function that is included in the script.

The UserExit function I usually include is similar to this and requires the function signature (set of parameters) shown below:

Function UserExit(sType, sWhen, sDetail, bSkip)
    oLogging.CreateEntry "USEREXIT:TestUserExit.vbs started: " & sType & " " & sWhen & " " & sDetail, LogTypeInfo
    UserExit = Success
End Function

The sType input parameter is always called with a value of "SECTION".  The sWhen input parameter is called with "BEFORE" at the beginning of section processing and "AFTER" at the end of section processing.  The sDetail input parameter is the CustomSettings.ini section name.  The bSkip parameter is a return parameter.  If bSkip is set to True in the UserExit function when it is called at the beginning of section processing, the rest of that section in CustomSettings.ini is skipped.

This behavior allows you to run different code at the beginning or end of section processing or skip section processing based on code run at the beginning of section processing like the trivial samples shown below.

Function UserExit(sType, sWhen, sDetail, bSkip)
    oLogging.CreateEntry "USEREXIT:TestUserExit.vbs started: " & sType & " " & sWhen & " " & sDetail, LogTypeInfo
    If sWhen = "BEFORE" Then oEnvironment.Item("WhenProperty") = "Before"
    If sWhen = "AFTER" Then oEnvironment.Item("WhenProperty") = "After"
    UserExit = Success
End Function

Function UserExit(sType, sWhen, sDetail, bSkip)
    oLogging.CreateEntry "USEREXIT:TestUserExit.vbs started: " & sType & " " & sWhen & " " & sDetail, LogTypeInfo
    If TestCondition = False Then bSkip = True
    UserExit = Success
End Function

While this functionality is interesting, I have never had any occasion where I needed to use it.  I only know one person who has put logic in a UserExit function, fellow Deployment Guy Dave Hornbaker.  So why did I bother explaining it to you?  Well, as I said earlier it has implications for which scripts you can use as user exit scripts.

The first is that any script you want to use as a user exit script must have a UserExit function.  Fellow Deployment Guy Dave Hornbaker once needed to use ZTIDiskUtility.vbs functions in one of his user exit scripts.  Now he could have either added a UserExit function to ZTIDiskUtility.vbs so it could be used as a user exit script directly as well or added a script tag to ZTIGather.wsf that referenced ZTIDiskUtility.vbs.  However, we generally recommend against modifying the scripts that ship with MDT unless it is absolutely necessary.  If you do, then you have to remember to redo those changes when applying an update to MDT.

The second is that the when a user exit script contains VBScript Classes, the second ExecuteGlobal of the contents at the end of section processing fails with a “name redefined” error.  This causes ZTIGather.wsf execution to fail.

To overcome both of these limitations, I created a user exit script (MDTExitInclude.vbs) with a function called Include that only loads the contents of a VBScript file into a string variable, executes the loaded code using the VBScript ExecuteGlobal statement, and only does this once.  So while this does not allow the little-used section processing control behavior I described above, this function essentially allows you to use any VBScript as a user exit script.

After adding MDTExitInclude.vbs to Scripts folder in the LTI Deployment Share or ConfigMgr MDT Toolkit package, modify CustomSetting.ini similar to the example below to load MDTExitInclude.vbs as a user exit script and then load another script using the Include function.  This sample loads a script named TestUserExit.vbs and make functions inside it available for use.

[Settings]
Priority=IncludeScript, Default
Properties=IncludeResult

[IncludeScript]
UserExit=IncludeExit.vbs
IncludeResult=#Include("TestUserExit.vbs")#

One other advantage of loading user exit scripts in this fashion is that it simplifies loading multiple scripts.  For example, I recently needed to load five user exit scripts for one deployment.  Normally this would require creating five sections in CustomSettings.ini since you can only have one UserExit directive per section.  Using MDTExitInclude.vbs you can load as many scripts as you want in a single section like this:

[Settings]
Priority=IncludeExitScripts, Default
Properties=ExitScripts(*)

[IncludeExitScripts]
UserExit=MDTExitInclude.vbs
ExitScripts001=#Include("MDTLibHelperClasses.vbs")#
ExitScripts002=#Include("ModelAliasExit.vbs")#
ExitScripts003=#Include("MDTConfigMgrFunctions.vbs")#
ExitScripts004=#Include("MDTExitGetCollectionAdvertsDeploys.vbs")#
ExitScripts005=#Include("MDTExitGetResourceAdvertsDeploys.vbs")#

This sample uses one “throw away” list item, ExitScripts, to execute the Include function for each script.  This avoids “Settings section bloat” by not requiring multiple entries in the Priority or Properties line for just loading multiple scripts.

 

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Categories: MDT

Pages