MDT

Deprecation of the OSVersion Property and What to Do About It

The Deployment Guys - Wed, 10/02/2013 - 19:53

The OSVersion variable is populated with a short string representing the version of the operating system (e.g. XP, Vista, Win7Client, 2008, etc.).  With MDT 2012, you may have noticed that when you deploy Window 8 that the value of the OSVersion variable gets set to “Other” instead of something like “Win8”.  This is because the MDT team has deprecated the OSVersion property.  The logic that set this property has not been updated for Windows 8 and will no longer be updated.  The team decided that using these string values in script logic leads to hidden bugs and unexpected behavior as new OS versions are released.  For example, code testing for a client OS that is Windows Vista or higher would require something like this using OSVersion:

If oEnvironment.Item("OSVersion") = "Vista" Or oEnvironment.Item("OSVersion") = "Win7Client" Then…

This would work until Windows 8 was released.  Then this would have to be updated with another OR with the Windows 8 value.  They now recommend using a variable called OSCurrentVersion which has a value of the OS major and minor version (e.g. 6.1 for Windows 7).  So the equivalent code using OSCurrentVersion would look like this and would continue to work as new operating systems are released:

If CSng(oEnvironment.Item("OSCurrentVersion")) > 6.0 And UCase(oEnvironment.Item("IsServerOS") = "FALSE" Then...

While I wholeheartedly agree with this reasoning, there is one instance where I like an easily recognized string for the OS version.  This is composite custom property called ModelOSArchAlias that I defined in my Model Alias post. which combines the ModelAlias, OSVersion, and Architecture properties.  These values are used to create Make and Model entries in the MDT database.  Using OSCurrentVersion instead of OSVersion would lead to ModelOSArchAlias values like ThinkPadT420_6.1_X64 instead of the more easily readable ThinkPadT420_Win7Client_X64.  Also, since Windows team seems to have developed an aversion to increasing the major version of Windows, I see it becoming easy to confuse which version you are referencing with an OSCurrentVersion of 6.0, 6.1, 6.2, or 6.3 (Windows Vista, 7, 8, and 8.1 respectively).

So to make it possible to use a short string representing the version of the operating system that is current, I’ve created a function called GetOSVersionTag that is essentially a copy of the ZTIGather.wsf code that sets OSVersion with some improvements and updated to set proper values for Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2.  I have placed this function in a class library script that I have been building up over the years called MDTLibHelperClasses.vbs.  This script is conceptually similar to ZTIUtility.vbs.  It can be referenced similarly in other MDT scripts and using the technique from my last post it can also be used as a User Exit script.  As I create new general purpose functions going forward, I will place them in future versions of this library as appropriate.

To use this function to create a custom variable called OSVersionTag and use that in ModelOSArchAlias, add MDTLibHelperClasses.vbs (and MDTExitInclude.vbs and ModelAliasExit.vbs from the two previous posts referenced earlier) to the Scripts folder of your Deployment Share or Configuration Manager MDT Files package and add the following to CustomSetting.ini (used during Gather in the newly deployed OS):

[Settings]
Priority=IncludeExitScripts, ModelAliasVars, Default
Properties=ExitScripts(*), OSVersionTag, ModelAlias, ModelOSArchAlias

[IncludeExitScripts]
UserExit=MDTExitInclude.vbs
ExitScripts001=#Include("MDTLibHelperClasses.vbs")#
ExitScripts002=#Include("ModelAliasExit.vbs")#

[ModelAliasVars]
OSVersionTag=#oHelperFunctions.GetOSVersionTag#
ModelAlias=#SetModelAlias()#
ModelOSArchAlias=%ModelAlias%_%OSVersionTag%_%Architecture%

 

 

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

Deprecation of the OSVersion Property and What to Do About It

The Deployment Guys - Wed, 10/02/2013 - 19:53

The OSVersion variable is populated with a short string representing the version of the operating system (e.g. XP, Vista, Win7Client, 2008, etc.).  With MDT 2012, you may have noticed that when you deploy Window 8 that the value of the OSVersion variable gets set to “Other” instead of something like “Win8”.  This is because the MDT team has deprecated the OSVersion property.  The logic that set this property has not been updated for Windows 8 and will no longer be updated.  The team decided that using these string values in script logic leads to hidden bugs and unexpected behavior as new OS versions are released.  For example, code testing for a client OS that is Windows Vista or higher would require something like this using OSVersion:

If oEnvironment.Item("OSVersion") = "Vista" Or oEnvironment.Item("OSVersion") = "Win7Client" Then…

This would work until Windows 8 was released.  Then this would have to be updated with another OR with the Windows 8 value.  They now recommend using a variable called OSCurrentVersion which has a value of the OS major and minor version (e.g. 6.1 for Windows 7).  So the equivalent code using OSCurrentVersion would look like this and would continue to work as new operating systems are released:

If oEnvironment.Item("OSCurrentVersion") > 6.0 And UCase(oEnvironment.Item("IsServerOS") = "FALSE" Then...

While I wholeheartedly agree with this reasoning, there is one instance where I like an easily recognized string for the OS version.  This is composite custom property called ModelOSArchAlias that I defined in my Model Alias post. which combines the ModelAlias, OSVersion, and Architecture properties.  These values are used to create Make and Model entries in the MDT database.  Using OSCurrentVersion instead of OSVersion would lead to ModelOSArchAlias values like ThinkPadT420_6.1_X64 instead of the more easily readable ThinkPadT420_Win7Client_X64.  Also, since Windows team seems to have developed an aversion to increasing the major version of Windows, I see it becoming easy to confuse which version you are referencing with an OSCurrentVersion of 6.0, 6.1, 6.2, or 6.3 (Windows Vista, 7, 8, and 8.1 respectively).

So to make it possible to use a short string representing the version of the operating system that is current, I’ve created a function called GetOSVersionTag that is essentially a copy of the ZTIGather.wsf code that sets OSVersion with some improvements and updated to set proper values for Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2.  I have placed this function in a class library script that I have been building up over the years called MDTLibHelperClasses.vbs.  This script is conceptually similar to ZTIUtility.vbs.  It can be referenced similarly in other MDT scripts and using the technique from my last post it can also be used as a User Exit script.  As I create new general purpose functions going forward, I will place them in future versions of this library as appropriate.

To use this function to create a custom variable called OSVersionTag and use that in ModelOSArchAlias, add MDTLibHelperClasses.vbs (and MDTExitInclude.vbs and ModelAliasExit.vbs from the two previous posts referenced earlier) to the Scripts folder of your Deployment Share or Configuration Manager MDT Files package and add the following to CustomSetting.ini (used during Gather in the newly deployed OS):

[Settings]
Priority=IncludeExitScripts, ModelAliasVars, Default
Properties=ExitScripts(*), OSVersionTag, ModelAlias, ModelOSArchAlias

[IncludeExitScripts]
UserExit=MDTExitInclude.vbs
ExitScripts001=#Include("MDTLibHelperClasses.vbs")#
ExitScripts002=#Include("ModelAliasExit.vbs")#

[ModelAliasVars]
OSVersionTag=#oHelperFunctions.GetOSVersionTag#
ModelAlias=#SetModelAlias()#
ModelOSArchAlias=%ModelAlias%_%OSVersionTag%_%Architecture%

 

 

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

OSD Machine Import and the GUID

Steve Rachui's Manageability blog - Wed, 10/02/2013 - 15:57
A common step in imaging through OSD, especially when unknown computer support is not in use for the environment, is to import a new machine record and then target image deployments to the imported machine. I was testing this a few days ago and came across...(read more)
Categories: MDT

OS Deployment Training on MDT2013/SCCM2012R2 – November 4-7, Stockholm, Sweden

The Deployment Bunny - Tue, 10/01/2013 - 04:46

(In Swedish)

Ville bara upplysa om att jag håller LAB på LabCenter den 4-7 November och denna gång är det nytt mtrl. Nu blir det SCCM 2012 R2, MDT 2013, ADK 8.1,  Windows Server 2012 R2, Windows 8.1, SCOR 2012 R2. Du kommer att lära dej LiteTouch och ZeroTouch (Du LAB:ar dock bara med det ena spåret), du lär dej dom viktiga grunderna för att sedan gå över till dynamiska utrullnings lösningar, vi kopplar in System Center Orchestrator mot slutet för att köra runbooks, WebServices, Databas hantering och allt det där som gör att man kan hantera och rulla ut enorma miljöer och ändå ha järnkoll på bitarna. Så om du håller på med detta och vill lära dej av mej som har sysslat med detta I många år, så är du välkommen http://www.labcenter.se/#lab=Deploying_Windows_using_MDT_2013_and_ConfigMgr_2012_R2

/mike


Categories: 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

Pages