Cisco Blogs

Threat Spotlight: Rombertik – Gazing Past the Smoke, Mirrors, and Trapdoors

- May 4, 2015 - 23 Comments

This post was authored by Ben Baker and Alex Chiu.

Executive Summary

Threat actors and security researchers are constantly looking for ways to better detect and evade each other.  As researchers have become more adept and efficient at malware analysis, malware authors have made an effort to build more evasive samples.  Better static, dynamic, and automated analysis tools have made it more difficult for attackers to remain undetected. As a result, attackers have been forced to find methods to evade these tools and complicate both static and dynamic analysis.

Table of Contents
Executive Summary
The 10,000 Foot View at Rombertik
A Nasty Trap Door
The Actual Malware
Coverage and Indicators of Compromise

It becomes critical for researchers to reverse engineer evasive samples to find out how attackers are attempting to evade analysis tools. It is also important for researchers to communicate how the threat landscape is evolving to ensure that these same tools remain effective. A recent example of these behaviors is a malware sample Talos has identified as Rombertik. In the process of reverse engineering Rombertik, Talos discovered multiple layers of obfuscation and anti-analysis functionality. This functionality was designed to evade both static and dynamic analysis tools, make debugging difficult. If the sample detected it was being analyzed or debugged it would ultimately destroy the master boot record (MBR).

Talos’ goal is to protect our customer’s networks.  Reverse engineering Romberik helps Talos achieve that goal by better understanding how attackers are evolving to evade detection and make analysis difficult.  Identifying these techniques gives Talos new insight and knowledge that can be communicated to Cisco’s product teams.  This knowledge can then be used to harden our security products to ensure these anti-analysis techniques are ineffective and allow detection technologies to accurately identify malware to protect customers.

The 10,000 Foot View at Rombertik

At a high level, Romberik is a complex piece of malware that is designed to hook into the user’s browser to read credentials and other sensitive information for exfiltration to an attacker controlled server, similar to Dyre. However, unlike Dyre which was designed to target banking information, Rombertik collects information from all websites in an indiscriminate manner.

Rombertik has been identified to propagate via spam and phishing messages sent to would-be victims.  Like previous spam and phishing campaigns Talos has discussed, attackers use social engineering tactics to entice users to download, unzip, and open the attachments that ultimately result in the user’s compromise.

Figure 1: Email messages such as the one seen here are spammed out in the hopes that users will open them and open the attachments.  This is one sample that was used to propagate Rombertik.

Figure 1: Email messages such as the one seen here are spammed out in the hopes that users will open them and open the attachments. This is one sample that was used to propagate Rombertik.

In this sample, the message observed in Rombertik’s distribution appears to come from the “Windows Corporation,” an organization that possesses “state-of-the-art manufacturing quality processes.”  The attackers attempt to convince the user to check the attached documents to see if their business aligns with the target user’s organization.  If the user downloads and unzips the file, the user then sees a file that looks like a document thumbnail.


While this file may appears to be some sort of PDF from the icon or thumbnail, the file actually is a .SCR screensaver executable file that contains Rombertik.  Once the user double clicks to open the file, Rombertik will begin the process of compromising the system.

The process by which Rombertik compromises the target system is a fairly complex with anti-analysis checks in place to prevent static and dynamic analysis.  Upon execution, Rombertik will stall and then run through a first set of anti-analysis checks to see if it is running within a sandbox.  Once these checks are complete, Rombertik will proceed to decrypt and install itself on the victims computer to maintain persistence.  After installation, it will then launch a second copy of itself and overwrite the second copy with the malware’s core functionality.  Before Rombertik begins the process of spying on users, Rombertik will perform once last check to ensure it is not being analyzed in memory.  If this check fails, Rombertik will attempt to destroy the Master Boot Record and restart the computer to render it unusable.  The graphic below illustrates the process.

Figure 2: An illustration of the step-by-step process Rombertik follows to compromise the target system.

Figure 2: An illustration of the step-by-step process Rombertik follows to compromise the target system.


From the beginning, Rombertik incorporates several layers of obfuscation along with anti-analysis functionality.  Obfuscating the functionality of a malware sample can be accomplished in many different ways.  A common method is to include garbage code to inflate the volume of code an analyst might have to review and analyze.  In this case, the unpacked Rombertik sample is 28KB while the packed version is 1264KB. Over 97% of the packed file is dedicated to making the file look legitimate by including 75 images and over 8000 functions that are never used. This packer attempts to overwhelm analysts by making it impossible to look at every function.

Figure 3: This chart shows the breakdown of the Rombertik executable and how it contains a large amount of unnecessary code and data.

Figure 3: This chart shows the breakdown of the Rombertik executable and how it contains a large amount of unnecessary code and data.

As we started to slowly peel back the layers and focus on the subset of functions that are actually used, we observed an interesting sandbox evasion technique. A common technique to evade sandboxes is to sleep for extended lengths of time with the intention of forcing the sandbox to time out before the malware “wakes up” and begins executing.  In response, sandboxes got better at detecting and responding when malware slept for extended periods of time.  Rombertik employs a similar approach to delay execution, but does so without sleeping.  Rombertik instead writes a byte of random data to memory 960 Million times.  This is designed to consume time, like sleeping, but presents a couple disadvantages for sandboxes and application tracing tools.  Sandboxes may not be able to immediately determine that the application is intentionally stalling since it’s not sleeping.  The other disadvantage is that the repetitive writing would flood application tracing tools.  If an analysis tool attempted to log all of the 960 Million write instructions, the log would grow to over 100 gigabytes. Even if the analysis environment was capable of handling a log that large, it would take over 25 minutes just to write that much data to a typical hard drive.  This complicates analysis.

After intentionally stalling by writing to memory repeatedly, Rombertik checks to see if analysis tools have modified code in the Windows API ZwGetWriteWatch routine.  It does this by calling ZwGetWriteWatch with invalid arguments.  If the routine does not return with a specific error, Rombertik terminates. The assumption behind checking for a specific error versus a generic error is to check for sandboxes that suppress errors returned from API routine calls.   Once the sandbox check is complete, Rombertik calls the Windows API OutputDebugString function 335,000 times as an anti-debugging mechanism.  Finally, an anti-analysis function within the packer is called to check the username and filename of the executing process for strings like “malwar”, “sampl”, “viru”, and “sandb”. If the packer detects any of these substrings, it will stop unpacking and terminate.  At this point, the initial anti-analysis checks are complete.

Once the packer has run through initial anti-analysis checks, it will check to see if it is executing from %AppData%\rsr\yfoye.exe.  If the packer is not executing from there, it will proceed to install itself in order to ensure persistence across system reboots before continuing on to execute the payload. To install itself, Rombertik first creates a VBS script named “fgf.vbs”, which is used to kick off Rombertik every time the user logs in, and places the script into the user’s Startup folder.  Rombertik then creates %AppData%\rsr\yfoye.bat and moves the packed version of itself into %AppData%\rsr\yfoye.exe.

If Rombertik detects it is already executing from %AppData%\rsr\yfoye.exe, the malware will then begin decrypting and executing the main unpacking code in memory.  Rombertik will then proceed to execute yfoye.exe a second time to create a new instance of the process.  Once the unpacking is complete, Rombertik will overwrite the memory of the new process with the unpacked executable code.  The unpacking code is monstrous and has many times the complexity of the anti-analysis code.  The code contains dozens of functions overlapping with each other and unnecessary jumps added to increase complexity. The result is a nightmare of a control flow graph with hundreds of nodes.  Figure 4 helps illustrate how complex the unpacking code is in comparison to the all the code that performs anti-analysis checks.


Figure 4: The graph on the left represents the interwoven functions within the unpacking code that is decrypted to memory.  The control flow graph on the right represents the  previously mentioned anti-analysis checks. These 23 basic blocks represent the 930 million writes, 335 thousand API calls, checking ZwGetWriteWatch, and checking file and usernames. All of this functionality fits in this rather simple graph, where the red block is only executed if all of the checks were satisfied. A typical function has less than 20 nodes (basic blocks) and would normally be easy to see how all basic blocks relate to each other.

Figure 4: The graph on the left represents the interwoven functions within the unpacking code that is decrypted to memory. The graph on the right represents the previously mentioned anti-analysis checks. These 23 basic blocks represent the 930 million writes, 335 thousand API calls, checking ZwGetWriteWatch, and checking file and usernames. All of this functionality fits in this rather simple graph, where the red block is only executed if all of the checks were satisfied. A typical function has less than 20 nodes (basic blocks) and would normally be easy to see how all basic blocks relate to each other.

A Nasty Trap Door

Once the unpacked version of Rombertik within the second copy of yfoye.exe begins executing, one last anti-analysis function is run — which turns out to be particularly nasty if the check fails.  The function computes a 32-bit hash of a resource in memory, and compares it to the PE Compile Timestamp of the unpacked sample. If the resource or compile time has been altered, the malware acts destructively. It first attempts to overwrite the Master Boot Record (MBR) of PhysicalDisk0, which renders the computer inoperable. If the malware does not have permissions to overwrite the MBR, it will instead destroy all files in the user’s home folder (e.g. C:\Documents and Settings\Administrator\) by encrypting each file with a  randomly generated RC4 key. After the MBR is overwritten, or the home folder has been encrypted, the computer is restarted.

The Master Boot Record starts with code that is executed before the Operating System. The overwritten MBR contains code to print out “Carbon crack attempt, failed”, then enters an infinite loop preventing the system from continuing to boot.


The MBR also contains information about the disk partitions. The altered MBR overwrites the bytes for these partitions with Null bytes, making it even more difficult to recover data from the sabotaged hard drive.


Once the computer is restarted, the victim’s computer will be stuck at this screen until the Operating System is reinstalled:


Effectively, Rombertik begins to behave like a wiper malware sample, trashing the user’s computer if it detects it’s being analyzed.  While Talos has observed anti-analysis and anti-debugging techniques in malware samples in the past, Rombertik is unique in that it actively attempts to destroy the computer’s data if it detects certain attributes associated with malware analysis.

The Actual Malware

At this point, Rombertik will assume that all anti-analysis checks have passed and will actually begin doing what was originally intended — stealing user data.  Rombertik will scan the user’s currently running process to determine if a web browser is currently running.  If Rombertik detects an instance of Firefox, Chrome, or Internet Explorer, it will inject itself into the process and hook API functions that handle plain text data. Once accomplished, Rombertik is then able to read any plain-text data the user might type into their browser and capture this input before it gets encrypted if the input is to be sent over HTTPS. This enables the malware to collect data such as usernames and passwords from almost any website.  Rombertik does not target any site in particular, such as banking sites, but instead, attempts to steal sensitive information from as many websites as possible.  The collected data is then Base64 encoded and forwarded to (in this example) over HTTP with no encryption.

Coverage and Indicators of Compromise

Sample Analysed (SHA256)


Command-and-Control Servers




Rombertik is a complex piece of malware with several layers of obfuscation and anti-analysis functionality that is ultimately designed to steal user data.  Good security practices, such as making sure anti-virus software is installed and kept up-to-date, not clicking on attachments from unknown senders, and ensuring robust security policies are in place for email (such as blocking certain attachment types) can go a long way when it comes to protecting users.  However, a defense in depth approach that covers the entire attack continuum can help identify malware and assist in remediation in the event that an attacker finds a way to evade detection initially.

For Talos, understanding how malware changes and evolves is essential to developing detection content and ensuring that static, dynamic, and automated analysis tools remain effective. We must adapt, change, and respond accordingly to address the evolving threat landscape. Looking forward, Talos expects these methods and behaviors to be adopted by other threat actors in the future.


Protecting Users From These Threat

image06We encourage organizations to consider security best practices, starting with a threat-centric approach that implements protections across the extended network and across the full attack continuum.

ESA can block malicious emails, including phishing and malicious attachments sent by threat actors.

CWS/WSA web scanning prevents access to websites hosting malicious content.

Advanced Malware Protection (AMP) is designed to prevent the execution of the malware used by these threat actors.

Network Security appliances, such as NGIPS and NGFW, have signatures to detect and block malicious network activity by threat actors.




Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


    Another reason to have multiple detection techniques instead of just sandboxing excellent work from Talos team.

  1. Question 1: This malware attacks MBR. Will it also attack GPT? Question 2: Can a user remove this malware completely by restoring a clean backup of the OS partition and the MBR (while using the backup-tool's recovery cd)?

  2. If I understand correctly, disabling VSB prevents it from executing? Not to mention deleting startup entires/folders before restart/shutdown.

  3. Great article. I'm interested in reverse engineering as well, so I'd like to know how the team mastered all the anti-analysis and anti-debugging techniques. If log files get too big, I think the only solution is to modify the runnning process by reducing the ammount of random garbage writes to memory? Focusing on what calls are acutally being used by the malware instead of analysing each and every call seems clear to me. It must have taken alot of time to perform analysis on this particular malware. Congrats!

  4. Protecting writes to MBR via an open handle to physicaldisk0 is trivial.. all sane sanboxes/live protection tools should have a low (disk or port) level filter driver that could differentiate btw mbr writes originating from rouge code vs valid os tools..even if they are not able to differentiate the mbr sector should always be backed up before allowing the write to proceed. a single random byte write, 960 million times is lot of duplicated data.. this should be deduped and not stored ad is on disk

  5. Why does the malware bother encrypting home directory files with random RC4 keys? Does it store or transmit the keys somewhere? If not, why not just use random data?

  6. Won´t a simple FIXMBR from a XP windows do the trick without reinstalling the OS?

    • No it will work but your computer will start and as soon as the av starts on windows your doomed again so it is a never ending cycle unless you format and reinstall windows

  7. What about Testdisk? (Deeper Search will also search for FAT32 backup boot sector, NTFS backup boot superblock, ext2/ext3 backup superblock to detect more partitions, )

    • testdisk would do a good job restoring your partitions (I destroyed my hdd with 10 partitions two months ago by overwriting the first 8gb with an empty USB stick and got 100% of data back with testdisk), but that won't help to much as your home directory ist encrypted. You'll still have to reinstall your os or at least restore a copy of your home dir from an image or a good backup.

  8. A FIXMBR won#t help 'cause the partition entries are overwritten, too. It's a not so difficult for boot repair disks (e.g. a Knoppix copy) to fix that (if you know how to), but that won't give you your home directory back. ALWAYS keep a copy of the MBR and some ouptut of FDISK (start/end/type of paritions) on a safe USB stick or so. Backup. Backup. And sometimes backup that. But BY NO MEANS doubleclick attachments! Use Linux. Save your life.

  9. Excellent research and a well written article. Reminds me of reverse engineering Dark Avenger's Mutation engine 25 years ago ;-)

  10. Typo in your Table of Contents. "Acutal" Good article though, or should that be aritcle? ;)

  11. Being from the non-technical side of the house, I can only comment on the email's contents. I would think that anyone receiving such an email (written awkwardly, and "you" instead of "your"), would immediately be suspicious, especially if it was unsolicited. It doesn't cost anything to check the validity of the sender, including even a phone call if you're really bothered. A few moments of time can save you hours, if not days, of grief.

  12. would it be too simple to disable .scr files or have them open as text file or other none executable or be blocked altogether stopping at source? as well as suggested by somebody else disabling VSB.

  13. Brilliant article, showing clearly how on top of its game Talos is. The work that must have gone into unravelling that malware sounds enormous. The presence of garbage like that on the internet underlines the need to run serious software on a Unix platform, preferably, one not containing an Intel CPU. If you use Sun, HP or IBM, you will be proof against 99.99% of the malware that's out there - for at least the decade it takes the parasites to learn how to write SPARC assembler.

  14. One part you glossed over. If it's taking login/passwords, where is it sending them to? That would be the first thing I'd look at when tracking down who created it. Russian/Chinese/US?

    • It says right in the article that the information is sent via a POST request.

  15. How can I get the samples? thank you!

  16. Looks like some guys did further research:

    How can I contact someone to provide a sample of something I believe to be either Rombertik or a variant. I need a way to first determine the extent of the infection in the office systems and then clean them without total data loss. In the two system where I was able to detect the virus it immediately deleted all files. "Power off" only delayed the final erasure. If not "Rombertik" it is certainly a close variant.

  17. I am right about that you guys do not have valuable data stored in any home directory no matter the OS. Aren't I?

  18. I'm right about as well, that non of you forget backing up, as you surely always create partitions and external drives, and may even use a Linux of a kind and OS X of course, not staying by Microsoft only?