Michael Sikorski on Reverse Engineering Ransomware

The ship on my opening slide belongs to Maersk, the container shipping company. Ransomware crippled its ability to move goods until its systems were rebuilt, costing it about $300 million. This is not just a news story: an attack on Baltimore also prevented me from paying my property and water bills online. These incidents affect ordinary life as well as the organizations directly hit.

I want to explain what my team does, how malware analysis works, and why it matters to security, before examining ransomware and looking at actual assembly code. I am a malware analyst, researcher, author and teacher. I spent years at Mandiant, first doing a range of security consulting and then concentrating on incident response.

Incident response means being called in after an organization is hacked and sorting out the mess. We became especially familiar with groups in China, their tools and methods. When the New York Times was compromised, our knowledge helped us investigate efficiently; around the same time Mandiant published its APT1 report on Chinese cyber espionage and intellectual-property theft.

FireEye acquired Mandiant, and my malware team supports incident response and intelligence by taking samples apart and explaining how they work. What began with two reverse engineers grew to around 50, analyzing thousands of samples a year. We invest in technology and efficiency, share tools with the community, and run a reverse-engineering competition that only a small fraction of its thousands of entrants finish.

Malware analysis is a specialized skill that takes time to acquire and constant practice to maintain. It is a cat-and-mouse game: attackers deliberately change their software to interfere with our analysis tools. At one point we noticed malware looking for FLARE tools and changing its behavior when it found them.

Analysis is distinct from forensics and incident response, but it informs both. If we discover how malware persists across a reboot, responders can search an entire enterprise for that sign and remove it. The work ranges from basic static and dynamic analysis to much deeper reverse engineering.

Basic static analysis examines the file without running it: we compare hashes with known samples and extract strings that might reveal a domain or other clues. Attackers often encode those strings until runtime, so our FLOSS tool helps decode them. File-format information provides more context about the sample.

Basic dynamic analysis runs the sample while monitoring the host and network to see what it installs and where it communicates. That is dangerous, so isolation matters. FakeNet simulates network services without connecting the malware to the real internet, allowing it to continue behaving as though it had reached a site.

A sandbox applies the same general idea automatically: it can open attachments and links, observe suspicious behavior, and quarantine an email. Sandboxes can also examine network traffic and files. We use virtual machines and snapshots so that after a sample damages the environment we can restore it; our FLARE VM distribution packages tools for Windows malware analysis.

Basic analysis has limits. A sample can sleep for five days before doing anything malicious, while an email sandbox cannot wait that long to deliver a message. To discover the delayed behavior, we take apart the executable, examine its instructions, and sometimes debug it while observing its internal state.

A compiler turns source code into machine instructions. A disassembler presents those instructions as assembly; a decompiler attempts to recover a higher-level representation, but in my experience it cannot reliably recover an entire complicated original program. Much of an analyst's life is spent reading assembly and working out what it does.

Tools such as IDA Pro and the NSA's open-source Ghidra make the instructions easier to navigate by showing control flow as a graph. In one example I can recognize a switch statement: four boxes represent the paths for different input values. This view turns a mass of instructions into a puzzle we can follow.

Financial malware takes many forms. Botnets can use other people's computing power to mine cryptocurrency or steal wallets. Banking Trojans can interfere with a browser to capture banking information, while card scrapers seek payment data in memory, sometimes on a central server rather than on every individual terminal.

We have also seen malware on ATMs and point-of-sale terminals. In one retail investigation, we cleaned infected terminals but found that newly opened stores kept becoming infected. The attacker had compromised the standard image used to set up new stores, so the retailer was inadvertently installing the malware itself each time.

The people behind financially motivated attacks have changed too. In addition to criminal groups, we see state-linked actors seeking money. I cite North Korea and Russia as examples of states whose operations have included theft for revenue, alongside espionage and long-term access to networks.

Ransomware is malware used for cyber extortion: it might encrypt files or lock a system and demand payment to restore access. Cryptocurrency made payments easier for attackers to collect, although obtaining it can be difficult for victims. The sophistication varies: one sample we saw merely renamed files, yet still persuaded people their data was inaccessible.

A law firm we investigated faced a large ransom and involved the FBI. The investigation identified a domestic attacker, and the firm recovered its data without paying. The firm had already bought bitcoin for a possible payment, and its value rose during the investigation; I recall that unusual result as a gain of roughly $1 million.

Reverse engineering helps answer urgent questions: how can we stop spread, prevent further encryption, and recover files? Paying is not necessarily a solution. Some programs damage data or contain mistakes that make recovery impossible even for their authors; other implementations have weaknesses that analysts can exploit to recover data without paying.

To find the relevant code in Windows malware, we can look for file APIs such as ReadFile and WriteFile, then work backward from a write to the code that transforms the data. Other samples map a file into memory and modify it there. These landmarks let us focus on a small part of a large executable.

Encryption design matters. Symmetric algorithms such as AES use the same secret key for encryption and decryption and are fast, but the attacker must keep the key from the victim. A sample might generate a key and send it to a command-and-control server, request it from that server, or embed it in the malware. An embedded key can make recovery much easier.

Asymmetric cryptography uses a public and private key pair. A public key can be left with the malware to encrypt data while the private key remains with the attacker. Managing keys across many infected systems creates operational work; the details of a particular sample determine whether and how a recovery path exists.

We use signatures and our own tools to identify familiar cryptographic or compression code inside a disassembler. Encryption functions can have enormous control-flow graphs, and reverse engineering every instruction is expensive. Sometimes we can extract and reuse a function directly once we have the key, even without reconstructing every detail of the algorithm.

WannaCry was a worm that used the EternalBlue exploit against SMB to spread through networks. Its demand screen asked for payment in bitcoin, and the malware targeted many file extensions. Its impact reached hospitals and equipment as well as corporate systems; I cite an estimated $4 billion in losses and describe services being disrupted.

Patching matters only when systems receive and install the updates. WannaCry spread rapidly through vulnerable networks, and by the time the first wave subsided analysts had little time to understand and interrupt it. Microsoft and others attributed the attack to North Korea; our team also reached that assessment based on multiple indications.

A large team can divide a complex sample into components: the encryption and decryption routines, the exploit, network communication and anti-forensic behavior. That parallel work helps produce answers quickly when an outbreak is moving faster than a single analyst can investigate.

A researcher known as MalwareTech noticed that WannaCry queried an unregistered domain and registered it. The resulting sinkhole helped stop the spread of the original outbreak. The interesting reverse-engineering question is why registering a seemingly random domain changed the malware's behavior.

In IDA Pro, the sample's main function shows an early branch. Following the path backward reveals calls that attempt to open a URL. If the request succeeds, that path exits the process; otherwise the malware continues toward its harmful behavior. The domain registration made the exit path available to affected instances.

I interpret the check as an anti-sandbox measure: a sandbox that simulates internet responses might return a page even for a random domain, alerting the malware that it is being observed. Attackers could change the domain or remove the check in later variants. The sinkhole bought defenders time to understand the outbreak and patch systems; it was not a universal switch for every possible variant.

NotPetya, also called EternalPetya in this talk, illustrates a different outcome: the machine can be effectively destroyed rather than recoverably held for ransom. It displayed a demand for $300, stole credentials and spread using exploits and other mechanisms. Its impact included Maersk and ordinary businesses such as grocery stores.

The sample installed a boot component and encrypted the master file table, which records where files and their contents are located. Our analysis indicated the key needed to reverse that damage was not made available to the attacker. In that situation a ransom notice does not mean the attacker can restore the system; affected machines may need to be rebuilt.

NotPetya did not have the same kill switch, but analysis uncovered a temporary protective measure for the sample we studied. Malware often checks for a marker indicating that a copy is already present, avoiding multiple instances on the same system. In this case a file played that role.

The disassembly shows a branch leading to ExitProcess. If the marker file exists, execution exits; otherwise the malware creates the marker and continues. Working backward from that branch and into a helper function tells us which path the sample checks.

The helper takes the malware's current filename, extracts its name, combines it with the Windows directory and removes the extension. For the distribution name in this example, the resulting marker is C:\Windows\perfc. Creating that file could protect systems against this particular sample while defenders worked on containment and patching; a different distribution name or variant could change the check.

The point of these examples is the analysis process. Reverse engineering reveals an attacker's goals, installation methods and indicators, and can show whether recovery is even possible. Sometimes it produces a way to slow an outbreak or protect a particular system. The work can take hours, days or weeks, especially when malware deliberately attacks the analyst's tools.