Archive

Archive for the ‘CME’ Category

Microsoft partners with Interpol, industry to disrupt global malware attack affecting more than 770,000 PCs in past six months

April 13th, 2015 No comments

'Simda.AT' designed to divert Internet traffic to disseminate other types of malware.

Today Interpol and the Dutch National High Tech Crime Unit (DNHTCU) announced the disruption of Simda.AT, a significant malware threat affecting more than 770,000 computers in over 190 countries. The Simda.AT variant first appeared in 2012. It is a widely distributed malware that causes significant damage to users through the manipulation of internet traffic and spread of other malware. 

Interpol coordinated the operation and the DNHTCU, with the support of the Federal Bureau of Investigation (FBI), successfully took down Simda.AT's active command and control infrastructure across four countries including the Netherlands, Luxembourg, Russia and the United States.

The Microsoft Malware Protection Center (MMPC) and the Microsoft's Digital Crimes Unit (DCU) led the analysis of the malware threat in partnership with CDI Japan, Kaspersky Lab, and Trend Micro.

MMPC activated the Coordinated Malware Eradication (CME) platform to provide in-depth research, telemetry, samples, and cleaning solutions to law enforcement and our partners.  This information helped law enforcement take action against Simda.AT and its infrastructure, while providing easy remediation and recovery options for victim machines around the world.  

Since 2009, the Simda malware family has been a dynamic and elusive threat.  Simda's function has ranged from a simple password stealer to a complex banking trojan.  To read more about the Simda family, see Win32/Simda.

Encounters

Simda.AT makes up the vast majority of our current detections for this malware family. We've measured approximately 128,000 new cases each month over the last six months with infections occurring around the world. The 'Top 10' countries accounted for 54 percent of the detections our customers have experienced from February through March:

Simda.AT machine detections from October 2014 to March 2015

Figure 1: Simda.AT machine detections from October 2014 to March 2015

Percentage of Simda.AT machine detections by country from February to March 2015

Figure 2: Percentage of Simda.AT machine detections by country from February to March 2015

Simda.AT machine detections heat map from February to March 2015

Figure 3: Simda.AT machine detections heat map from February to March 2015

Distribution

Over time, the Simda family was distributed in various ways, including:

With Simda.AT, the most common infection vector we identified was compromised websites using embedded or injected JavaScript.  Compromised sites were used to redirect users' traffic to another website, named the "gate".  Figure 4 shows an example of an injected JavaScript which is detected as Trojan:JS/Redirector.  

This gate website is part of the exploit tool chain, which will redirect the browser to the exploit landing page. The "gate" in this Simda.AT example, is detected as Exploit:JS/Fiexp (aka  Fiesta Exploit kit). Fiesta can serve several types of exploits. For example, we have observed Fiesta delivering Simda.AT through malicious SWF files (Shockwave Flash), detected as Exploit:SWF/Fiexp, malicious Java applet files, detected as Exploit:Java/Fiexp and malicious Silverlight files, detected as Exploit:MSIL/CVE-2013-0074.  More specific details related to the exploits can be found in the following CVEs: 

Compromised website with injected malicious JavaScript

Figure 4: Compromised website with injected malicious JavaScript

 

The “gate” contains script that redirects the browser to the Fiesta landing page. From the landing page, Fiesta attempts to deliver one of three exploits to compromise the machine.  Figure 5 shows the general Simda.AT payload delivery process:

Fiesta exploit kit in action

Figure 5: Fiesta exploit kit in action          

Behaviors

Simda.AT provides two primary functionalities:

  • Internet traffic re-routing
  • Distribution and installation of additional software packages or modules

Anti-emulation/Anti-sandbox techniques

For years, Simda used anti-sandbox techniques to evade detection. In most cases, the malware will not run properly, or might sleep indefinitely when the malware suspects that it's being installed into a software security research environment like the one we have at MMPC.  

During installation, the binary checks against a list of black-listed programs and running processes.  The checks performed might seem standard and predictable, but Simda.AT collects information from machines it deems suspicious to update the list. Then it uses an automatic and sustainable process for releasing a new binary every couple of hours with updates that cannot be detected by the majority of the AV scanners.  See the Simda.AT encyclopedia page for details about the dozens of files, processes, and registry keys checked by Simda.AT at the time of installation.

HOSTS file manipulation

During installation, Simda.AT also modifies the file %SYSTEM32%driversetchosts by updating the content and changing the file attributes to be read-only and hidden.  The specific changes are hard-coded into each binary, and can cause the victim machine's internet traffic to be routed according to the new instructions for targeted hosts. 

After applying the updates, the installer creates a new and empty file %SYSTEM32%driversetchosts.txt to further obfuscate the changes made to the system. The most recent samples are targeting network communication from the following URLs:

  • connect.facebook.net
  • google-analytics.com
  • www.google-analytics.com

Older samples were also seen targeting Bing.com hosts for redirection (e.g. u.bing.com, bing.com, ca.bing.com, gb.bing.com, www.bing.com) and a portion of recent Simda.AT samples connecting to Bing.com using the following URL pattern:  http://www.bing.com/chrome/report.html?<encoded string> 

The malware authors might have intended to use the HOSTS file modifications to relay additional information about victim machines to the servers of their choosing.  However, from our research, Simda.AT samples stopped updating the HOSTS file with the Bing.com hosts in early February.  As a result, we've been able to monitor traffic to this, normally unused, location for the last several days, and we have observed an average of approximately 5,000 unique IPs reach out to us each day.

Software distribution and modules

Based on our research, we believe the primary monetization method for this is through a Pay-Per-Install (PPI) program in which the authors can be compensated for distributing and installing additional software packages or modules.  Over time, we have observed the following types of software to be distributed by Simda.AT:

Persistence

The initial infection modifies the system registry to execute during every system start-up.  There are no communications outside of the initial program execution. 

C&C communication

DGA/Command and Control Infrastructure

The Simda.AT command and control infrastructure is organized differently than similar malware families.  Each binary contains up to six hard-coded IPs that dictate the communication infrastructure for each bot.  The Domain-Generation-Algorithm (DGA) that's normally used to define the infrastructure is instead used to generate a seed for the encryption that is used by the host and the command and control servers.

Using RDTSC instruction, the DGA creates a random, 15-19 character long string that's embedded into a domain in one of the following formats:

  • report.<random>.com
  • update[1,2].<random>.com 

These domains are then injected as the 'Host' in the associated POST requests issued to the command and control servers.

To decrypt the 'report' HTTP request, append the query string to the hostname and use as the key. Then unquote the query value and enumerate each byte and get the decrypted byte with the following python code snippet:

decrypted_string += chr(ord(cipher[i]) – ord(hostname[i % len(hostname)]))

The third, or 'update' request, requires an additional step to base64 decode the query string.

Check-In and update

As alluded to earlier, Simda.AT has two primary functions while communicating with the command and control server:

  • 'report'
  • 'update'

These two functions are differentiated in the POST request sent to the servers, and they are normally issued to different servers through the hard-coded configuration in the binary.

The 'report' function acts as a simple check-in and provides the following type of information, from the victim machine, to the command and control server prior to terminating the connection ahead of the server response:

  • Adapter information
  • Assorted other system and registry information to distinctly identify the computer
  • Creation time of the folder "C:System Volume Information"
  • Computer name
  • Hard disk information
  • MAC address
  • Volume serial number

This information is used to provide a unique ID for the bot.

In some situations, the bots can also append information about installed applications and processes that are running that we suspect are used for anti-emulation updates for new samples.

The 'update' command is used when downloading modules or additional software packages.  Again, a small amount of machine and binary information is packaged from the victim machine and sent to a different, 'module', or server.  When the module servers receives the request and then responds with an 'Active' message, the bot drops an embedded component (TrojanDropper:Win32/Simdown.A) that handles the download and installation of all modules using hard-coded paths. 

Both functions are called at the initial infection and at every system restart.

It's interesting to note that Simda.AT has been using the same user agent strings in its command and control communication since 2012, which can provide a valuable signature for IPS/IDS engines:

"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101114 Firefox/4.0b8pre"

"Mozilla/4.0 (compatible; MSIE 8.0; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.590; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729"

While the disruption action can disable the ability of existing infections to download or update new software components, it will not disable modules that might have been installed by Simda.AT. 

If you have been infected by Simda.AT, run a comprehensive scan of your environment using Microsoft Safety Scanner, Microsoft Security Essentials, Windows Defender, or your preferred Anti-Malware Solution.

As a part of our cleaning solution, we will detect and remove any malware distributed by this family, and return your HOSTS file to the default, blank, state.

As always, we urge Windows users to be vigilant against malware:

  • Be cautious when opening emails or social media messages from unknown users.
  • Be wary about downloading software from websites other than the program developers.
  • Run an antivirus software regularly.

As a reminder to organizations invested in security, if your organization is interested in joining or initiating an eradication campaign, or you are just interested in participating in the CME program, please see the CME program page. You can also reach out to us directly through our contact page for more information. 

Tommy Blizard, Rex Plantado, Rodel Finones, and Tanmay Ganacharya

MMPC

Microsoft partners with Interpol, industry to disrupt global malware attack affecting more than 770,000 PCs in past six months

April 13th, 2015 No comments

'Simda.AT' designed to divert Internet traffic to disseminate other types of malware.

Today Interpol and the Dutch National High Tech Crime Unit (DNHTCU) announced the disruption of Simda.AT, a significant malware threat affecting more than 770,000 computers in over 190 countries. The Simda.AT variant first appeared in 2012. It is a widely distributed malware that causes significant damage to users through the manipulation of internet traffic and spread of other malware. 

Interpol coordinated the operation and the DNHTCU, with the support of the Federal Bureau of Investigation (FBI), successfully took down Simda.AT's active command and control infrastructure across four countries including the Netherlands, Luxembourg, Russia and the United States.

The Microsoft Malware Protection Center (MMPC) and the Microsoft's Digital Crimes Unit (DCU) led the analysis of the malware threat in partnership with CDI Japan, Kaspersky Lab, and Trend Micro.

MMPC activated the Coordinated Malware Eradication (CME) platform to provide in-depth research, telemetry, samples, and cleaning solutions to law enforcement and our partners.  This information helped law enforcement take action against Simda.AT and its infrastructure, while providing easy remediation and recovery options for victim machines around the world.  

Since 2009, the Simda malware family has been a dynamic and elusive threat.  Simda's function has ranged from a simple password stealer to a complex banking trojan.  To read more about the Simda family, see Win32/Simda.

Encounters

Simda.AT makes up the vast majority of our current detections for this malware family. We've measured approximately 128,000 new cases each month over the last six months with infections occurring around the world. The 'Top 10' countries accounted for 54 percent of the detections our customers have experienced from February through March:

Simda.AT machine detections from October 2014 to March 2015

Figure 1: Simda.AT machine detections from October 2014 to March 2015

Percentage of Simda.AT machine detections by country from February to March 2015

Figure 2: Percentage of Simda.AT machine detections by country from February to March 2015

Simda.AT machine detections heat map from February to March 2015

Figure 3: Simda.AT machine detections heat map from February to March 2015

Distribution

Over time, the Simda family was distributed in various ways, including:

With Simda.AT, the most common infection vector we identified was compromised websites using embedded or injected JavaScript.  Compromised sites were used to redirect users' traffic to another website, named the "gate".  Figure 4 shows an example of an injected JavaScript which is detected as Trojan:JS/Redirector.  

This gate website is part of the exploit tool chain, which will redirect the browser to the exploit landing page. The "gate" in this Simda.AT example, is detected as Exploit:JS/Fiexp (aka  Fiesta Exploit kit). Fiesta can serve several types of exploits. For example, we have observed Fiesta delivering Simda.AT through malicious SWF files (Shockwave Flash), detected as Exploit:SWF/Fiexp, malicious Java applet files, detected as Exploit:Java/Fiexp and malicious Silverlight files, detected as Exploit:MSIL/CVE-2013-0074.  More specific details related to the exploits can be found in the following CVEs: 

Compromised website with injected malicious JavaScript

Figure 4: Compromised website with injected malicious JavaScript

 

The “gate” contains script that redirects the browser to the Fiesta landing page. From the landing page, Fiesta attempts to deliver one of three exploits to compromise the machine.  Figure 5 shows the general Simda.AT payload delivery process:

Fiesta exploit kit in action

Figure 5: Fiesta exploit kit in action          

Behaviors

Simda.AT provides two primary functionalities:

  • Internet traffic re-routing
  • Distribution and installation of additional software packages or modules

Anti-emulation/Anti-sandbox techniques

For years, Simda used anti-sandbox techniques to evade detection. In most cases, the malware will not run properly, or might sleep indefinitely when the malware suspects that it's being installed into a software security research environment like the one we have at MMPC.  

During installation, the binary checks against a list of black-listed programs and running processes.  The checks performed might seem standard and predictable, but Simda.AT collects information from machines it deems suspicious to update the list. Then it uses an automatic and sustainable process for releasing a new binary every couple of hours with updates that cannot be detected by the majority of the AV scanners.  See the Simda.AT encyclopedia page for details about the dozens of files, processes, and registry keys checked by Simda.AT at the time of installation.

HOSTS file manipulation

During installation, Simda.AT also modifies the file %SYSTEM32%driversetchosts by updating the content and changing the file attributes to be read-only and hidden.  The specific changes are hard-coded into each binary, and can cause the victim machine's internet traffic to be routed according to the new instructions for targeted hosts. 

After applying the updates, the installer creates a new and empty file %SYSTEM32%driversetchosts.txt to further obfuscate the changes made to the system. The most recent samples are targeting network communication from the following URLs:

  • connect.facebook.net
  • google-analytics.com
  • www.google-analytics.com

Older samples were also seen targeting Bing.com hosts for redirection (e.g. u.bing.com, bing.com, ca.bing.com, gb.bing.com, www.bing.com) and a portion of recent Simda.AT samples connecting to Bing.com using the following URL pattern:  http://www.bing.com/chrome/report.html?<encoded string> 

The malware authors might have intended to use the HOSTS file modifications to relay additional information about victim machines to the servers of their choosing.  However, from our research, Simda.AT samples stopped updating the HOSTS file with the Bing.com hosts in early February.  As a result, we've been able to monitor traffic to this, normally unused, location for the last several days, and we have observed an average of approximately 5,000 unique IPs reach out to us each day.

Software distribution and modules

Based on our research, we believe the primary monetization method for this is through a Pay-Per-Install (PPI) program in which the authors can be compensated for distributing and installing additional software packages or modules.  Over time, we have observed the following types of software to be distributed by Simda.AT:

Persistence

The initial infection modifies the system registry to execute during every system start-up.  There are no communications outside of the initial program execution. 

C&C communication

DGA/Command and Control Infrastructure

The Simda.AT command and control infrastructure is organized differently than similar malware families.  Each binary contains up to six hard-coded IPs that dictate the communication infrastructure for each bot.  The Domain-Generation-Algorithm (DGA) that's normally used to define the infrastructure is instead used to generate a seed for the encryption that is used by the host and the command and control servers.

Using RDTSC instruction, the DGA creates a random, 15-19 character long string that's embedded into a domain in one of the following formats:

  • report.<random>.com
  • update[1,2].<random>.com 

These domains are then injected as the 'Host' in the associated POST requests issued to the command and control servers.

To decrypt the 'report' HTTP request, append the query string to the hostname and use as the key. Then unquote the query value and enumerate each byte and get the decrypted byte with the following python code snippet:

decrypted_string += chr(ord(cipher[i]) – ord(hostname[i % len(hostname)]))

The third, or 'update' request, requires an additional step to base64 decode the query string.

Check-In and update

As alluded to earlier, Simda.AT has two primary functions while communicating with the command and control server:

  • 'report'
  • 'update'

These two functions are differentiated in the POST request sent to the servers, and they are normally issued to different servers through the hard-coded configuration in the binary.

The 'report' function acts as a simple check-in and provides the following type of information, from the victim machine, to the command and control server prior to terminating the connection ahead of the server response:

  • Adapter information
  • Assorted other system and registry information to distinctly identify the computer
  • Creation time of the folder "C:System Volume Information"
  • Computer name
  • Hard disk information
  • MAC address
  • Volume serial number

This information is used to provide a unique ID for the bot.

In some situations, the bots can also append information about installed applications and processes that are running that we suspect are used for anti-emulation updates for new samples.

The 'update' command is used when downloading modules or additional software packages.  Again, a small amount of machine and binary information is packaged from the victim machine and sent to a different, 'module', or server.  When the module servers receives the request and then responds with an 'Active' message, the bot drops an embedded component (TrojanDropper:Win32/Simdown.A) that handles the download and installation of all modules using hard-coded paths. 

Both functions are called at the initial infection and at every system restart.

It's interesting to note that Simda.AT has been using the same user agent strings in its command and control communication since 2012, which can provide a valuable signature for IPS/IDS engines:

"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101114 Firefox/4.0b8pre"

"Mozilla/4.0 (compatible; MSIE 8.0; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.590; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729"

While the disruption action can disable the ability of existing infections to download or update new software components, it will not disable modules that might have been installed by Simda.AT. 

If you have been infected by Simda.AT, run a comprehensive scan of your environment using Microsoft Safety Scanner, Microsoft Security Essentials, Windows Defender, or your preferred Anti-Malware Solution.

As a part of our cleaning solution, we will detect and remove any malware distributed by this family, and return your HOSTS file to the default, blank, state.

As always, we urge Windows users to be vigilant against malware:

  • Be cautious when opening emails or social media messages from unknown users.
  • Be wary about downloading software from websites other than the program developers.
  • Run an antivirus software regularly.

As a reminder to organizations invested in security, if your organization is interested in joining or initiating an eradication campaign, or you are just interested in participating in the CME program, please see the CME program page. You can also reach out to us directly through our contact page for more information. 

Tommy Blizard, Rex Plantado, Rodel Finones, and Tanmay Ganacharya

MMPC

Microsoft Malware Protection Center assists in disrupting Ramnit

February 25th, 2015 No comments

Recent disruption of the Ramnit malware family was successful due to a multinational collaboration, led by Europol’s European Cybercrime Center (EC3), in partnership with Financial Services and Information Sharing & Analysis Center (FS-ISAC), Symantec, AnubisNetworks, Microsoft’s Digital Crimes Unit (DCU), and the Microsoft Malware Protection Center (MMPC).

The MMPC has been closely monitoring Ramnit since its discovery in April 2010, as you can see by reading: Ramnit – The renewed bot in town and Little Red Ramnit: My, what big eyes you have, Grandma!

The Ramnit threat tampers with antivirus software and disables Windows Update to prevent computers from getting critical security updates through Windows Update and antivirus software. We recommend using Microsoft Safety Scanner to scan and clean the threat. Additional technical details about what Ramnit can do, and how to clean it up, can be found by visiting the Malware Protection Center and help-page respectively.

During the past six months, Microsoft detected approximately 500,000 instances of computers infected with Ramnit.

Infected machines in the last six months

 Figure 1: Ramnit infection trend from the past six months

 

Ramnit is a module-based malware which concentrates on stealing credential information from banking websites.

Ramnit is configured to hide itself, disable security defences, and establish a connection with the Ramnit command and control server (C&C).

Ramnit generates 300 domains through a Domain Generation Algorithm (DGA), which is a function of rand and a hard-coded seed in the threat. Then, it tries to communicate to each through a custom protocol using port 443. Ramnit expects a reply from the C&C server that is signed using a RSA 1024-bit key, and uses RC4 encryption for the communication.

C&C server that is signed using a RSA 1024-bit key, and uses RC4 encryption for the communication.

See the Python implementation of DGA below:

Python implementation of DGA

  Figure 2: Sample Python code

 

Ramnit's design is modular to accommodate dynamic modules from the C&C server that can add additional functionality to the threat. This allows different malware modules that are pushed from the C&C server to plug into the malware framework on the user's computer and allows it to operate diskless (off of RAM).

To accomplish this, when an infected computer first contacts a C&C server, it can download one or more malware modules which give it new capabilities. For example, one module is designed to steal sensitive files from the user's computer, while a different module is designed to steal user credentials when the user logs into the website of a targeted financial institution, etc.

We have observed that Ramnit uses the following modules:

  • Hook-Spy Module:

This core module does a sophisticated form of fraud referred to as a "web-injection" attack to capture the user's banking credentials. To achieve this goal, this module first downloads a configuration file which contains a list of websites to monitor. A majority of the websites we saw were banks. With this list, Ramnit continues to monitor websites on the list.

When Ramnit sees the user attempting to connect to one of the websites on the list, it silently captures the credential information and uploads it to the C&C server.

Configuration can also specify additional information to be collected from the user. User interface elements needed to collect this information are dynamically inserted into the web page that the user is visiting.

For the user, it appears as though the target website itself is requesting new information. For example, Figure 3 shows the effect of a Ramnit web-injection. The image on the left shows how the webpage would be presented to a user on an uninfected computer. The image on the right shows how the webpage would be presented to a user on a Ramnit-infected computer. 

The effect of Ramnit web-injection

Figure 3: What a web page looks like before and after a Ramnit infection

We observed two different control servers:

    • C&C1 – the server that is contacted through DGA that controls what modules are downloaded, to provide command and VNC interface to the bot controller.
    • C&C2 – exists in the configuration file that is designed to handle web-injection responsible for stealing extra credential information.

By having two disassociated C&C, the threat gains the following advantages from its architecture:

    1. Dynamic content injected into webpages can change more rapidly and be tailored to the victim according to the country where the victim is located in and the websites visited.
    2. This can also act as a camouflage to hide the C&C2 from researchers, as this server is not referenced in the malware binary, reverse engineering the binary wouldn't reveal it. Identifying this server requires decryption of the configuration file sent by C&C1. The encryption algorithm used is RC4 with a machine specific key that also protects and increases the difficulty in finding it.
    3. The website content might update frequently. Updates for the website require the retrieval of a new configuration file. With this new server, it gives Ramnit bot controller the ability to put a portion of the injection code in a remote server.
    4. It allows credential information to be stored and managed separately. Figure 4 shows how the Ramnit C&C servers are organized.

The way Ramnit C&C servers are organized

Figure 4: A high-level flow of how Ramnit C&C servers operate

  • Anti-AV Module

There is a significant Anti-AV function that is part of the Ramnit installer. When Ramnit is installed, it disables the following Windows components:

  • Windows Firewall
  • Windows Update
  • Windows Defender
  • Windows User Account Control

When the C&C connection was established, the C&C server sent a blacklist of more than 300 types of antivirus applications. See the detailed list in this blog: Ramnit – The renewed bot in town.

This dynamic module sent from the server was first observed in 2013 with the name "Antivirus Trusted Module v1.0.” See the technical details in this blog: Ramnit – The renewed bot in town

In recent months, this blacklist shrunk to Microsoft Anti-AV application core executables.

  • FTP Grabber

The FTP Grabber enables Ramnit to steal credentials from FTP applications. One of Ramnit's propagation techniques is to implant those files with either Ramnit itself or other malware so that a user who downloads one of those files will be infected with Ramnit. See Win32/Ramnit for the detailed list of FTP Applications targeted by Ramnit. .

  • Cookie Grabber

The Cookie Grabber enables Ramnit to steal browser cookie information or to forge cookies. A cookie is a piece of information sent by the web server during a web session. In the case of a banking session, the cookie might contain user credential identification information. Ramnit steals that cookie information for later use in defrauding the user.

It also shows the list of websites that the user visited so that the C&C server can send a tailored spy configuration module. See Win32/Ramnit for the detailed list of browsers targeted by Ramnit.

  • VNC Module

The VNC module enables the Ramnit botnet controller to directly access and control the user's computer through a virtual network computing (VNC) connection. In other words, this allows the herder to access and completely control the user's computer. Machines with a properly configured firewall, or sit behind network address translation (NAT) won't be affected.

  • Drive Scan Module

The Drive Scan module enables Ramnit to gather credential information in addition to the information gathered by the Hook-Spy module. By achieving this, this module scans the computer looking for interesting files that contain specific key words, typically associated with banking credentials. Figure 5 shows a list of keywords that this module looks for as it attempts to identify files to steal. If the Ramnit running on a user's computer can locate file names with these keywords in them, it will upload the file to the C&C server.

The Ramnit botnet controller then collects that file and reviews it for information to more effectively target the computer user.

The way Ramnit C&C servers are organized

 Figure 5: The list of keywords that Ramnit looks for

In summary, Ramnit has a hot pluggable modular framework design that gives it plenty of flexibility to extend new functionality on demand.

As always, we urge Windows users to be vigilant against malware:

  • Exercise caution when opening emails or social media messages from unknown users.
  • Be wary about downloading software from websites other than the program developers.
  • Run an antivirus software regularly.

If you're using Windows 8 or later versions, Windows Defender is built-in. If you're running an older operating system, you can install Microsoft Security Essentials.

As a reminder to organizations invested in security, MMPC has a Coordinated Malware Eradication Program. If your organization is interested in joining or initiating an eradication campaign or participate in the CME program, please see the CME program page. You can also reach out to us at cme-invite@microsoft.com for more information. 

 

Tanmay Ganacharya, Karthik Selvaraj, and Tim Liu

MMPC

 

Microsoft Malware Protection Center assists in disrupting Ramnit

February 25th, 2015 No comments

Recent disruption of the Ramnit malware family was successful due to a multinational collaboration, led by Europol’s European Cybercrime Center (EC3), in partnership with Financial Services and Information Sharing & Analysis Center (FS-ISAC), Symantec, AnubisNetworks, Microsoft’s Digital Crimes Unit (DCU), and the Microsoft Malware Protection Center (MMPC).

The MMPC has been closely monitoring Ramnit since its discovery in April 2010, as you can see by reading: Ramnit – The renewed bot in town and Little Red Ramnit: My, what big eyes you have, Grandma!

The Ramnit threat tampers with antivirus software and disables Windows Update to prevent computers from getting critical security updates through Windows Update and antivirus software. We recommend using Microsoft Safety Scanner to scan and clean the threat. Additional technical details about what Ramnit can do, and how to clean it up, can be found by visiting the Malware Protection Center and help-page respectively.

During the past six months, Microsoft detected approximately 500,000 instances of computers infected with Ramnit.

Infected machines in the last six months

 Figure 1: Ramnit infection trend from the past six months

 

Ramnit is a module-based malware which concentrates on stealing credential information from banking websites.

Ramnit is configured to hide itself, disable security defences, and establish a connection with the Ramnit command and control server (C&C).

Ramnit generates 300 domains through a Domain Generation Algorithm (DGA), which is a function of rand and a hard-coded seed in the threat. Then, it tries to communicate to each through a custom protocol using port 443. Ramnit expects a reply from the C&C server that is signed using a RSA 1024-bit key, and uses RC4 encryption for the communication.

C&C server that is signed using a RSA 1024-bit key, and uses RC4 encryption for the communication.

See the Python implementation of DGA below:

Python implementation of DGA

  Figure 2: Sample Python code

 

Ramnit's design is modular to accommodate dynamic modules from the C&C server that can add additional functionality to the threat. This allows different malware modules that are pushed from the C&C server to plug into the malware framework on the user's computer and allows it to operate diskless (off of RAM).

To accomplish this, when an infected computer first contacts a C&C server, it can download one or more malware modules which give it new capabilities. For example, one module is designed to steal sensitive files from the user's computer, while a different module is designed to steal user credentials when the user logs into the website of a targeted financial institution, etc.

We have observed that Ramnit uses the following modules:

  • Hook-Spy Module:

This core module does a sophisticated form of fraud referred to as a "web-injection" attack to capture the user's banking credentials. To achieve this goal, this module first downloads a configuration file which contains a list of websites to monitor. A majority of the websites we saw were banks. With this list, Ramnit continues to monitor websites on the list.

When Ramnit sees the user attempting to connect to one of the websites on the list, it silently captures the credential information and uploads it to the C&C server.

Configuration can also specify additional information to be collected from the user. User interface elements needed to collect this information are dynamically inserted into the web page that the user is visiting.

For the user, it appears as though the target website itself is requesting new information. For example, Figure 3 shows the effect of a Ramnit web-injection. The image on the left shows how the webpage would be presented to a user on an uninfected computer. The image on the right shows how the webpage would be presented to a user on a Ramnit-infected computer. 

The effect of Ramnit web-injection

Figure 3: What a web page looks like before and after a Ramnit infection

We observed two different control servers:

    • C&C1 – the server that is contacted through DGA that controls what modules are downloaded, to provide command and VNC interface to the bot controller.
    • C&C2 – exists in the configuration file that is designed to handle web-injection responsible for stealing extra credential information.

By having two disassociated C&C, the threat gains the following advantages from its architecture:

    1. Dynamic content injected into webpages can change more rapidly and be tailored to the victim according to the country where the victim is located in and the websites visited.
    2. This can also act as a camouflage to hide the C&C2 from researchers, as this server is not referenced in the malware binary, reverse engineering the binary wouldn't reveal it. Identifying this server requires decryption of the configuration file sent by C&C1. The encryption algorithm used is RC4 with a machine specific key that also protects and increases the difficulty in finding it.
    3. The website content might update frequently. Updates for the website require the retrieval of a new configuration file. With this new server, it gives Ramnit bot controller the ability to put a portion of the injection code in a remote server.
    4. It allows credential information to be stored and managed separately. Figure 4 shows how the Ramnit C&C servers are organized.

The way Ramnit C&C servers are organized

Figure 4: A high-level flow of how Ramnit C&C servers operate

  • Anti-AV Module

There is a significant Anti-AV function that is part of the Ramnit installer. When Ramnit is installed, it disables the following Windows components:

  • Windows Firewall
  • Windows Update
  • Windows Defender
  • Windows User Account Control

When the C&C connection was established, the C&C server sent a blacklist of more than 300 types of antivirus applications. See the detailed list in this blog: Ramnit – The renewed bot in town.

This dynamic module sent from the server was first observed in 2013 with the name "Antivirus Trusted Module v1.0.” See the technical details in this blog: Ramnit – The renewed bot in town

In recent months, this blacklist shrunk to Microsoft Anti-AV application core executables.

  • FTP Grabber

The FTP Grabber enables Ramnit to steal credentials from FTP applications. One of Ramnit's propagation techniques is to implant those files with either Ramnit itself or other malware so that a user who downloads one of those files will be infected with Ramnit. See Win32/Ramnit for the detailed list of FTP Applications targeted by Ramnit. .

  • Cookie Grabber

The Cookie Grabber enables Ramnit to steal browser cookie information or to forge cookies. A cookie is a piece of information sent by the web server during a web session. In the case of a banking session, the cookie might contain user credential identification information. Ramnit steals that cookie information for later use in defrauding the user.

It also shows the list of websites that the user visited so that the C&C server can send a tailored spy configuration module. See Win32/Ramnit for the detailed list of browsers targeted by Ramnit.

  • VNC Module

The VNC module enables the Ramnit botnet controller to directly access and control the user's computer through a virtual network computing (VNC) connection. In other words, this allows the herder to access and completely control the user's computer. Machines with a properly configured firewall, or sit behind network address translation (NAT) won't be affected.

  • Drive Scan Module

The Drive Scan module enables Ramnit to gather credential information in addition to the information gathered by the Hook-Spy module. By achieving this, this module scans the computer looking for interesting files that contain specific key words, typically associated with banking credentials. Figure 5 shows a list of keywords that this module looks for as it attempts to identify files to steal. If the Ramnit running on a user's computer can locate file names with these keywords in them, it will upload the file to the C&C server.

The Ramnit botnet controller then collects that file and reviews it for information to more effectively target the computer user.

The way Ramnit C&C servers are organized

 Figure 5: The list of keywords that Ramnit looks for

In summary, Ramnit has a hot pluggable modular framework design that gives it plenty of flexibility to extend new functionality on demand.

As always, we urge Windows users to be vigilant against malware:

  • Exercise caution when opening emails or social media messages from unknown users.
  • Be wary about downloading software from websites other than the program developers.
  • Run an antivirus software regularly.

If you're using Windows 8 or later versions, Windows Defender is built-in. If you're running an older operating system, you can install Microsoft Security Essentials.

As a reminder to organizations invested in security, MMPC has a Coordinated Malware Eradication Program. If your organization is interested in joining or initiating an eradication campaign or participate in the CME program, please see the CME program page. You can also reach out to us at cme-invite@microsoft.com for more information. 

 

Tanmay Ganacharya, Karthik Selvaraj, and Tim Liu

MMPC