MDT

Redirect hides browser extension

The USMT team blog - Fri, 10/11/2013 - 19:45

​While analyzing a malicious Chrome browser extension we recently came across a Virtool that tries to redirect the Chrome Extension page.

We detect it as VirTool:JS/Redichrextor.A.

VirTool:JS/Redichrextor.A won’t let you view, change, remove or uninstall Chrome browser extensions. It does this by stopping you from viewing the Chrome Extension page.

It uses this technique so an affected user won’t be able to remove or uninstall the malicious extension without help from their antimalware software. This makes VirTool:JS/Redichrextor.A a useful piece of code for any malicious Chrome browser extension that wants to avoid manual detection or removal.

When an affected user does try to view the Chrome browser extension page they are redirected. We have seen it open a new tab, or go to the Chrome web store or Google.com:

  • Chrome://newtab

  • Chrome.google.com/webstore

  • http://google.com

We have also seen similar behaviour used by the following known malicious Chrome browser extensions:

Once VirTool:JS/Redichrextor.A is detected and removed, you should be able to go to the Chrome extension page.

We recommend you then check and uninstall any suspicious browser extension that might be linked to VirTool:JS/Redichrex.A or other malware. We also recommend keeping your security products up-to-date to avoid infection. 

While this new trick makes it harder to remove the Virtool manually, it is still easily detected and removed by Microsoft Security software.

SHA1s:

5a72d55f6b6c467565a2a53fe7ecb08beb996947
59131b62bb58bf80ab83e7f6522689ed38553cfb
0b516d26316c889a3468b92b4e376573567a822c

Jonathan San Jose

MMPC

Categories: MDT

Redirect hides browser extension

​While analyzing a malicious Chrome browser extension we recently came across a Virtool that tries to redirect the Chrome Extension page.

We detect it as VirTool:JS/Redichrextor.A.

VirTool:JS/Redichrextor.A won’t let you view, change, remove or uninstall Chrome browser extensions. It does this by stopping you from viewing the Chrome Extension page.

It uses this technique so an affected user won’t be able to remove or uninstall the malicious extension without help from their antimalware software. This makes VirTool:JS/Redichrextor.A a useful piece of code for any malicious Chrome browser extension that wants to avoid manual detection or removal.

When an affected user does try to view the Chrome browser extension page they are redirected. We have seen it open a new tab, or go to the Chrome web store or Google.com:

  • Chrome://newtab

  • Chrome.google.com/webstore

  • http://google.com

We have also seen similar behaviour used by the following known malicious Chrome browser extensions:

Once VirTool:JS/Redichrextor.A is detected and removed, you should be able to go to the Chrome extension page.

We recommend you then check and uninstall any suspicious browser extension that might be linked to VirTool:JS/Redichrex.A or other malware. We also recommend keeping your security products up-to-date to avoid infection. 

While this new trick makes it harder to remove the Virtool manually, it is still easily detected and removed by Microsoft Security software.

SHA1s:

5a72d55f6b6c467565a2a53fe7ecb08beb996947
59131b62bb58bf80ab83e7f6522689ed38553cfb
0b516d26316c889a3468b92b4e376573567a822c

Jonathan San Jose

MMPC

Categories: MDT

Redirect hides browser extension

The Deployment Guys - Fri, 10/11/2013 - 19:45

​While analyzing a malicious Chrome browser extension we recently came across a Virtool that tries to redirect the Chrome Extension page.

We detect it as VirTool:JS/Redichrextor.A.

VirTool:JS/Redichrextor.A won’t let you view, change, remove or uninstall Chrome browser extensions. It does this by stopping you from viewing the Chrome Extension page.

It uses this technique so an affected user won’t be able to remove or uninstall the malicious extension without help from their antimalware software. This makes VirTool:JS/Redichrextor.A a useful piece of code for any malicious Chrome browser extension that wants to avoid manual detection or removal.

When an affected user does try to view the Chrome browser extension page they are redirected. We have seen it open a new tab, or go to the Chrome web store or Google.com:

  • Chrome://newtab

  • Chrome.google.com/webstore

  • http://google.com

We have also seen similar behaviour used by the following known malicious Chrome browser extensions:

Once VirTool:JS/Redichrextor.A is detected and removed, you should be able to go to the Chrome extension page.

We recommend you then check and uninstall any suspicious browser extension that might be linked to VirTool:JS/Redichrex.A or other malware. We also recommend keeping your security products up-to-date to avoid infection. 

While this new trick makes it harder to remove the Virtool manually, it is still easily detected and removed by Microsoft Security software.

SHA1s:

5a72d55f6b6c467565a2a53fe7ecb08beb996947
59131b62bb58bf80ab83e7f6522689ed38553cfb
0b516d26316c889a3468b92b4e376573567a822c

Jonathan San Jose

MMPC

Categories: MDT

Coretech Application E-Mail Approval Tool

Coretech Blog » Kent Agerlund - Thu, 10/10/2013 - 18:54
A little over a year ago we released the first version of our Application E-mail approval utility. Ever since our first release we have received lots of positive feedback and ideas to new features. Most of the ideas are implemented in this new release. Thanks for all the feedback and please keep it coming. This […]
Categories: MDT

Ensuring custom GPO packs are copied to linked deployment shares

It’s been a surprisingly common question in the past few weeks – how come MDT doesn’t copy custom GPO packs to linked deployment shares?  Well, it’s been like that since support for GPO packs was added to MDT 2012 Update 1.

The simple scenario:  Someone has created a custom security template using the Security Compliance Manager and exported that as a local GPO pack.  They then copied that GPO pack into an MDT deployment share, under the “Templates\GPOPacks” folder and added a step to one or more task sequences to apply that GPO pack.  And everything works fine – until they set up linked deployment shares or media.  In those situations, they find that the extra GPO pack isn’t copied to the other deployment shares.

So why does this happen?  MDT knows to replicate certain folders to linked deployment shares and media.  (Really media is just another linked deployment share from a behavior perspective.)  And the “Templates\GPOPacks” folder isn’t included in that list of folders.

Fortunately, MDT does include a mechanism for adding folders to the list, a feature added just in case there was ever a need to do something like this.  See http://blogs.technet.com/b/mniehaus/archive/2009/10/01/mdt-2010-new-feature-21-copying-extra-folders.aspx for details.  I still don’t think it’s in the documentation, and it’s definitely not in the UI.  So you need to use PowerShell to configure it.

The process for doing that has changed a little since 2009, only because we now use a PowerShell 2.0 module.  So you would want to execute commands like so:

Import-Module 'C:\Program Files\Microsoft Deployment Toolkit\Bin\MicrosoftDeploymentToolkit.psd1'
Restore-MDTPersistentDrive
Set-ItemProperty -Path 'DS001:\Linked Deployment Shares\LINKED001' -Name ExtraFolders -Value @(“Templates\GPOPacks”)
Set-ItemProperty -Path 'DS001:\Media\MEDIA001' -Name ExtraFolders -Value @(“Templates\GPOPacks”)

These commands assume you only have one “main” deployment share (which becomes DS001: when the Restore-MDTPersistentDrive cmdlet runs), one linked deployment share (which has a logical name of “LINKED001”), and one media definition (which is “MEDIA001”).  You might need to adjust the values if you have more deployment shares or different objects.  (You can see the logical IDs in Workbench.)

After executing the command to add the extra folder, the next time you update or replicate the content, the custom GPO packs will be copied.

Categories: MDT

Ensuring custom GPO packs are copied to linked deployment shares

It’s been a surprisingly common question in the past few weeks – how come MDT doesn’t copy custom GPO packs to linked deployment shares?  Well, it’s been like that since support for GPO packs was added to MDT 2012 Update 1.

The simple scenario:  Someone has created a custom security template using the Security Compliance Manager and exported that as a local GPO pack.  They then copied that GPO pack into an MDT deployment share, under the “Templates\GPOPacks” folder and added a step to one or more task sequences to apply that GPO pack.  And everything works fine – until they set up linked deployment shares or media.  In those situations, they find that the extra GPO pack isn’t copied to the other deployment shares.

So why does this happen?  MDT knows to replicate certain folders to linked deployment shares and media.  (Really media is just another linked deployment share from a behavior perspective.)  And the “Templates\GPOPacks” folder isn’t included in that list of folders.

Fortunately, MDT does include a mechanism for adding folders to the list, a feature added just in case there was ever a need to do something like this.  See http://blogs.technet.com/b/mniehaus/archive/2009/10/01/mdt-2010-new-feature-21-copying-extra-folders.aspx for details.  I still don’t think it’s in the documentation, and it’s definitely not in the UI.  So you need to use PowerShell to configure it.

The process for doing that has changed a little since 2009, only because we now use a PowerShell 2.0 module.  So you would want to execute commands like so:

Import-Module 'C:\Program Files\Microsoft Deployment Toolkit\Bin\MicrosoftDeploymentToolkit.psd1'
Restore-MDTPersistentDrive
Set-ItemProperty -Path 'DS001:\Linked Deployment Shares\LINKED001' -Name ExtraFolders -Value @(“Templates\GPOPacks”)
Set-ItemProperty -Path 'DS001:\Media\MEDIA001' -Name ExtraFolders -Value @(“Templates\GPOPacks”)

These commands assume you only have one “main” deployment share (which becomes DS001: when the Restore-MDTPersistentDrive cmdlet runs), one linked deployment share (which has a logical name of “LINKED001”), and one media definition (which is “MEDIA001”).  You might need to adjust the values if you have more deployment shares or different objects.  (You can see the logical IDs in Workbench.)

After executing the command to add the extra folder, the next time you update or replicate the content, the custom GPO packs will be copied.

Categories: MDT

Our commitment to Microsoft antimalware

Microsoft Deployment Toolkit Team Blog - 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

Our commitment to Microsoft antimalware

The USMT team blog - 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

Our commitment to Microsoft antimalware

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

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

Pages