MDT

Our commitment to Microsoft antimalware

The Deployment Guys - Wed, 10/09/2013 - 05:21

We are fully committed to protecting our consumer and business customers from malware. Our strong solutions provide the comprehensive defense needed against malicious code and attacks. Our support of antimalware partners helps in building a strong and diverse ecosystem to fight malware.

Over the past year, we’ve continued to make investments in our protection technologies:

  • We’ve created new methods to identify emerging threats earlier and defend against them faster. Although around 80 percent of the malware our customers encounter are known or proactively blocked threats, new threats emerge every day. We’ve developed early warning telemetry and faster signature delivery systems to respond to these threats.
  • We’ve focused our resources on activities that directly contribute to customer protection. We exist to serve and protect our customers, so our research and response efforts focus on real threats that affect customers. Today millions of customers have voluntarily opted to let their computers share telemetry data with us on encountered threats, helping us identify and prioritize new malware files. If you are interested in learning more about our approach, I encourage you to read my previous blog and check out this paper which details our outcomes. Our public monthly report shows our trends and the progress we’re seeing.
  • We share our telemetry and samples with the industry to collectively make all of us stronger against our true adversaries - the malware writers. Our commitment to collaboration and sharing programs for antivirus (AV) partners and AV testers is stronger than ever. Through these programs, we encourage the ecosystem to address real world threats that impact all customers.

The end result is that, over the past year, our investments have increased the protection quality we deliver to our customers. As of the middle of 2013, we’ve increased our protection quality – that means less incorrect detections and less misses - by a significant rate since we first started measuring these metrics in the last quarter of 2011.

We are proud of the protection capabilities we provide for well over 150 million computers worldwide with our real-time antimalware products. We believe in Microsoft antimalware products and strongly recommend them to our customers, to our friends, and to our families.

Dennis Batchelder
Partner Group Program Manager
Microsoft Malware Protection Center

Categories: MDT

Configuring Hyper-V Replica Resynchronization

Virtual PC Guy's WebLog - Wed, 10/09/2013 - 00:51

If you have Hyper-V Replica enabled on a virtual machine, and Hyper-V is not able to send all disk changes across in a timely fashion, the replication relationship will eventually be put into a failed state.  At this point in time you need to perform a resynchronization to get the replication relationship back to normal.

We do allow you to configure for automatic resynchronization – like this:

However, I do not enable this on my virtual machines – and I would encourage any users of Hyper-V Replica to be very careful about how and when they enable automatic resynchronization.  There are two main reasons for this note of caution:

  1. Resynchronization is a very heavy weight operation.

    When a virtual machine is resynchronized there is a whole bunch of CPU, disk and network utilization going on.  Chances are you do not want this happening at an unpredictable point in time.  And you certainly do not want it happening for multiple virtual machines at the same time.  If I were to enable automatic resynchronization, I would configure each virtual machine with a different resynchronization window to try and avoid multiple resynchronizations happening at the same time.

  2. You want to know when things go wrong.

    This is the real reason why I do not enable automatic resynchronization.  If there is something going wrong in my environment that causes virtual machines to require resynchronization – I want to know!  And I want to fix it so it does not happen again!  I do not want to think that everything is fine when I actually have a problem to fix.

Cheers,
Ben

Categories: MDT

MSRT October 2013 – Shiotob

Microsoft Deployment Toolkit Team Blog - Tue, 10/08/2013 - 12:00

​This month the Malicious Software Removal Tool (MSRT) is giving some special attention to two malware families - Win32/Foidan and Win32/Shiotob.

We are targeting these families due to their increased prevalence.

Lately, we’ve been adding and improving our detections for the Shiotob family. Shiotob is a family of trojan spyware that steals system information and user credentials by monitoring network activities. These were first seen in 2011, yet are still managing to trouble people today.

The family can use several installation methods, and we’ve seen them  spreading as an email attachment. Shiotob trojans are capable of gathering email addresses from an infected system and sending them to the trojan server, at which point the collected addresses are sent emails with the malware as an attachment.

Here are some example attachment file names:

  • DHL_Express_POST-NOTIFICATION_<some strings>.zip
  • Booking_Hotel_Reservation_Details_<some strings>.zip
  • DHL-International-Delivery-Notification_<some strings>.zip
  • DHL_ONLINE_SHIPPING_PREALERT_<some strings>.zip
  • DHL-Worldwide-Delivery-Notification-<some strings>.zip

In this case <some strings> are random and can include dates and random text, for example DHL_Express_POST-NOTIFICATION_28FEB_4S1XFSR9.zip.

When the trojans run, they inject themselves into legitimate processes and then terminate their own process. We’ve seen them inject themselves into:

  • csrss.exe 
  • svchost.exe
  • iexplore.exe
  • explore.exe

This makes them hidden from the user when viewing processes in Task Manager or other process-viewer tools.

The injected code is also capable of modifying and monitoring the start-up registry by creating the following entries: In subkey: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\userinit.exe
Adds value: "Debugger"
With data: "<malware path>"
In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Adds value: "random value name"
With data: "<malware path> -autorun" If the modified entry is deleted, the malware will re-create it.   The Win32/Shiotob family is capable of sending information about the infected machine to a hacker using HTTP POST. This information can include details about the:
  • OS version
  • Service pack
  • IP address
  • User Access Control (UAC) status (on or off)
  • Email addresses from Windows Address Book (WAB)
  • FTP credentials
  • Email accounts
It does this by injecting its code to the following processes which belong to browsers, email clients and FTP client applications: 
  • Avant.exe
  • Ccftp.exe
  • Chrome.exe
  • Coreftp.exe
  • Filezilla.exe
  • Firefox.exe
  • Ftpte.exe
  • FTPVoyager.exe
  • Iexplore.exe
  • Maxthon.exe
  • Mozilla.exe
  • Msimn.exe
  • Myie.exe
  • Opera.exe
  • Outlook.exe
  • SmartFTP.exe
  • Thebat.exe
  • Totalcmd.exe
  • WinSCP.exe 
It then hooks the following Windows APIs from the above-mentioned injected processes to execute its malicious routine: 
  • Closesocket
  • Connect
  • HttpOpenRequestA
  • HttpOpenRequestW
  • HttpQueryInfoA
  • HttpQueryInfoW
  • HttpSendRequestA
  • HttpSendRequestW
  • InternetCloseHandle
  • InternetQueryDataAvailable
  • InternetReadFile
  • InternetReadFileExA
  • InternetWriteFileExW
  • Send
These Windows APIs are used by applications to send or receive network data from visited sites or when establishing a connection to a server.   The information gathered by the malware will be saved in encrypted form and stored in the following registry entry:   In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\<version number>\<Random string>
In value: (default)
With data: "<encrypted gathered data>"   You can find more details about this family in our Win32/Shiotob encyclopedia description.   As always we recommend using a complete antivirus solution to help stay protected from this and similar threats.
Microsoft Security Essentials and Windows Defender detect and remove Win32/Shiotob and a range of other malware and potentially unwanted software.   Jonathan San Jose MMPC
Categories: MDT

MSRT October 2013 – Shiotob

The USMT team blog - Tue, 10/08/2013 - 12:00

​This month the Malicious Software Removal Tool (MSRT) is giving some special attention to two malware families - Win32/Foidan and Win32/Shiotob.

We are targeting these families due to their increased prevalence.

Lately, we’ve been adding and improving our detections for the Shiotob family. Shiotob is a family of trojan spyware that steals system information and user credentials by monitoring network activities. These were first seen in 2011, yet are still managing to trouble people today.

The family can use several installation methods, and we’ve seen them  spreading as an email attachment. Shiotob trojans are capable of gathering email addresses from an infected system and sending them to the trojan server, at which point the collected addresses are sent emails with the malware as an attachment.

Here are some example attachment file names:

  • DHL_Express_POST-NOTIFICATION_<some strings>.zip
  • Booking_Hotel_Reservation_Details_<some strings>.zip
  • DHL-International-Delivery-Notification_<some strings>.zip
  • DHL_ONLINE_SHIPPING_PREALERT_<some strings>.zip
  • DHL-Worldwide-Delivery-Notification-<some strings>.zip

In this case <some strings> are random and can include dates and random text, for example DHL_Express_POST-NOTIFICATION_28FEB_4S1XFSR9.zip.

When the trojans run, they inject themselves into legitimate processes and then terminate their own process. We’ve seen them inject themselves into:

  • csrss.exe 
  • svchost.exe
  • iexplore.exe
  • explore.exe

This makes them hidden from the user when viewing processes in Task Manager or other process-viewer tools.

The injected code is also capable of modifying and monitoring the start-up registry by creating the following entries: In subkey: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\userinit.exe
Adds value: "Debugger"
With data: "<malware path>"
In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Adds value: "random value name"
With data: "<malware path> -autorun" If the modified entry is deleted, the malware will re-create it.   The Win32/Shiotob family is capable of sending information about the infected machine to a hacker using HTTP POST. This information can include details about the:
  • OS version
  • Service pack
  • IP address
  • User Access Control (UAC) status (on or off)
  • Email addresses from Windows Address Book (WAB)
  • FTP credentials
  • Email accounts
It does this by injecting its code to the following processes which belong to browsers, email clients and FTP client applications: 
  • Avant.exe
  • Ccftp.exe
  • Chrome.exe
  • Coreftp.exe
  • Filezilla.exe
  • Firefox.exe
  • Ftpte.exe
  • FTPVoyager.exe
  • Iexplore.exe
  • Maxthon.exe
  • Mozilla.exe
  • Msimn.exe
  • Myie.exe
  • Opera.exe
  • Outlook.exe
  • SmartFTP.exe
  • Thebat.exe
  • Totalcmd.exe
  • WinSCP.exe 
It then hooks the following Windows APIs from the above-mentioned injected processes to execute its malicious routine: 
  • Closesocket
  • Connect
  • HttpOpenRequestA
  • HttpOpenRequestW
  • HttpQueryInfoA
  • HttpQueryInfoW
  • HttpSendRequestA
  • HttpSendRequestW
  • InternetCloseHandle
  • InternetQueryDataAvailable
  • InternetReadFile
  • InternetReadFileExA
  • InternetWriteFileExW
  • Send
These Windows APIs are used by applications to send or receive network data from visited sites or when establishing a connection to a server.   The information gathered by the malware will be saved in encrypted form and stored in the following registry entry:   In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\<version number>\<Random string>
In value: (default)
With data: "<encrypted gathered data>"   You can find more details about this family in our Win32/Shiotob encyclopedia description.   As always we recommend using a complete antivirus solution to help stay protected from this and similar threats.
Microsoft Security Essentials and Windows Defender detect and remove Win32/Shiotob and a range of other malware and potentially unwanted software.   Jonathan San Jose MMPC
Categories: MDT

MSRT October 2013 – Shiotob

​This month the Malicious Software Removal Tool (MSRT) is giving some special attention to two malware families - Win32/Foidan and Win32/Shiotob.

We are targeting these families due to their increased prevalence.

Lately, we’ve been adding and improving our detections for the Shiotob family. Shiotob is a family of trojan spyware that steals system information and user credentials by monitoring network activities. These were first seen in 2011, yet are still managing to trouble people today.

The family can use several installation methods, and we’ve seen them  spreading as an email attachment. Shiotob trojans are capable of gathering email addresses from an infected system and sending them to the trojan server, at which point the collected addresses are sent emails with the malware as an attachment.

Here are some example attachment file names:

  • DHL_Express_POST-NOTIFICATION_<some strings>.zip
  • Booking_Hotel_Reservation_Details_<some strings>.zip
  • DHL-International-Delivery-Notification_<some strings>.zip
  • DHL_ONLINE_SHIPPING_PREALERT_<some strings>.zip
  • DHL-Worldwide-Delivery-Notification-<some strings>.zip

In this case <some strings> are random and can include dates and random text, for example DHL_Express_POST-NOTIFICATION_28FEB_4S1XFSR9.zip.

When the trojans run, they inject themselves into legitimate processes and then terminate their own process. We’ve seen them inject themselves into:

  • csrss.exe 
  • svchost.exe
  • iexplore.exe
  • explore.exe

This makes them hidden from the user when viewing processes in Task Manager or other process-viewer tools.

The injected code is also capable of modifying and monitoring the start-up registry by creating the following entries: In subkey: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\userinit.exe
Adds value: "Debugger"
With data: "<malware path>"
In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Adds value: "random value name"
With data: "<malware path> -autorun" If the modified entry is deleted, the malware will re-create it.   The Win32/Shiotob family is capable of sending information about the infected machine to a hacker using HTTP POST. This information can include details about the:
  • OS version
  • Service pack
  • IP address
  • User Access Control (UAC) status (on or off)
  • Email addresses from Windows Address Book (WAB)
  • FTP credentials
  • Email accounts
It does this by injecting its code to the following processes which belong to browsers, email clients and FTP client applications: 
  • Avant.exe
  • Ccftp.exe
  • Chrome.exe
  • Coreftp.exe
  • Filezilla.exe
  • Firefox.exe
  • Ftpte.exe
  • FTPVoyager.exe
  • Iexplore.exe
  • Maxthon.exe
  • Mozilla.exe
  • Msimn.exe
  • Myie.exe
  • Opera.exe
  • Outlook.exe
  • SmartFTP.exe
  • Thebat.exe
  • Totalcmd.exe
  • WinSCP.exe 
It then hooks the following Windows APIs from the above-mentioned injected processes to execute its malicious routine: 
  • Closesocket
  • Connect
  • HttpOpenRequestA
  • HttpOpenRequestW
  • HttpQueryInfoA
  • HttpQueryInfoW
  • HttpSendRequestA
  • HttpSendRequestW
  • InternetCloseHandle
  • InternetQueryDataAvailable
  • InternetReadFile
  • InternetReadFileExA
  • InternetWriteFileExW
  • Send
These Windows APIs are used by applications to send or receive network data from visited sites or when establishing a connection to a server.   The information gathered by the malware will be saved in encrypted form and stored in the following registry entry:   In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\<version number>\<Random string>
In value: (default)
With data: "<encrypted gathered data>"   You can find more details about this family in our Win32/Shiotob encyclopedia description.   As always we recommend using a complete antivirus solution to help stay protected from this and similar threats.
Microsoft Security Essentials and Windows Defender detect and remove Win32/Shiotob and a range of other malware and potentially unwanted software.   Jonathan San Jose MMPC
Categories: MDT

MSRT October 2013 – Shiotob

The Deployment Guys - Tue, 10/08/2013 - 12:00

​This month the Malicious Software Removal Tool (MSRT) is giving some special attention to two malware families - Win32/Foidan and Win32/Shiotob.

We are targeting these families due to their increased prevalence.

Lately, we’ve been adding and improving our detections for the Shiotob family. Shiotob is a family of trojan spyware that steals system information and user credentials by monitoring network activities. These were first seen in 2011, yet are still managing to trouble people today.

The family can use several installation methods, and we’ve seen them  spreading as an email attachment. Shiotob trojans are capable of gathering email addresses from an infected system and sending them to the trojan server, at which point the collected addresses are sent emails with the malware as an attachment.

Here are some example attachment file names:

  • DHL_Express_POST-NOTIFICATION_<some strings>.zip
  • Booking_Hotel_Reservation_Details_<some strings>.zip
  • DHL-International-Delivery-Notification_<some strings>.zip
  • DHL_ONLINE_SHIPPING_PREALERT_<some strings>.zip
  • DHL-Worldwide-Delivery-Notification-<some strings>.zip

In this case <some strings> are random and can include dates and random text, for example DHL_Express_POST-NOTIFICATION_28FEB_4S1XFSR9.zip.

When the trojans run, they inject themselves into legitimate processes and then terminate their own process. We’ve seen them inject themselves into:

  • csrss.exe 
  • svchost.exe
  • iexplore.exe
  • explore.exe

This makes them hidden from the user when viewing processes in Task Manager or other process-viewer tools.

The injected code is also capable of modifying and monitoring the start-up registry by creating the following entries: In subkey: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\userinit.exe
Adds value: "Debugger"
With data: "<malware path>"
In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Adds value: "random value name"
With data: "<malware path> -autorun" If the modified entry is deleted, the malware will re-create it.   The Win32/Shiotob family is capable of sending information about the infected machine to a hacker using HTTP POST. This information can include details about the:
  • OS version
  • Service pack
  • IP address
  • User Access Control (UAC) status (on or off)
  • Email addresses from Windows Address Book (WAB)
  • FTP credentials
  • Email accounts
It does this by injecting its code to the following processes which belong to browsers, email clients and FTP client applications: 
  • Avant.exe
  • Ccftp.exe
  • Chrome.exe
  • Coreftp.exe
  • Filezilla.exe
  • Firefox.exe
  • Ftpte.exe
  • FTPVoyager.exe
  • Iexplore.exe
  • Maxthon.exe
  • Mozilla.exe
  • Msimn.exe
  • Myie.exe
  • Opera.exe
  • Outlook.exe
  • SmartFTP.exe
  • Thebat.exe
  • Totalcmd.exe
  • WinSCP.exe 
It then hooks the following Windows APIs from the above-mentioned injected processes to execute its malicious routine: 
  • Closesocket
  • Connect
  • HttpOpenRequestA
  • HttpOpenRequestW
  • HttpQueryInfoA
  • HttpQueryInfoW
  • HttpSendRequestA
  • HttpSendRequestW
  • InternetCloseHandle
  • InternetQueryDataAvailable
  • InternetReadFile
  • InternetReadFileExA
  • InternetWriteFileExW
  • Send
These Windows APIs are used by applications to send or receive network data from visited sites or when establishing a connection to a server.   The information gathered by the malware will be saved in encrypted form and stored in the following registry entry:   In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\<version number>\<Random string>
In value: (default)
With data: "<encrypted gathered data>"   You can find more details about this family in our Win32/Shiotob encyclopedia description.   As always we recommend using a complete antivirus solution to help stay protected from this and similar threats.
Microsoft Security Essentials and Windows Defender detect and remove Win32/Shiotob and a range of other malware and potentially unwanted software.   Jonathan San Jose MMPC
Categories: MDT

Virtualizing Exchange on Hyper-V

Virtual PC Guy's WebLog - Mon, 10/07/2013 - 19:37

I was recently given a pointer to the following white paper that goes through all the best practices for virtualizing Exchange on top of Hyper-V:

http://download.microsoft.com/download/4/A/C/4AC32FD3-220E-45DC-AA97-DBDBE19C15B2/Best_Practices_for_Virtualizing_and_Managing_Exchange_2013.pdf

It does a really good job of going through pretty much all of the features / aspects of Hyper-V and explaining the best configuration option to choose when running Exchange inside a virtual machine.

Cheers,
Ben

Categories: MDT

Delete Behavior for Devices in ConfigMgr 2012

Steve Rachui's Manageability blog - Thu, 10/03/2013 - 12:03
I can already hear you saying it to yourself – delete behavior? Well that’s pretty simple. Deleting a device , well, deletes it!  Yes it does but there are actually some interesting details about how this works that are different in ConfigMgr 2012...(read more)
Categories: MDT

Convert XML and XSL to HTML

NINet.org - Thu, 10/03/2013 - 06:13
Just a quickie. I have a script that outputs an XML file and I use an XSL file to display it but Management wanted HTML files, the thought of having to re-code the output was disheartening to say the least. I then came across “msxsl.exe” it’s a Microsoft tool that takes a XML file and [...]
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 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

Pages