Detection and recovery of NSA’s covered up tracks

Part of the NSA cyber weapon framework DanderSpritz is eventlogedit, a piece of software capable of removing individual lines from Windows Event Log files. Now that this tool is leaked and public, any criminal willing to remove its traces on a hacked computer can use it. Fox-IT has looked at the software and found a unique way to detect the use of it and to recover the removed event log entries.

Introduction

A group known as The Shadow Brokers published a collection of software, which allegedly was part of the cyber weapon arsenal of the NSA. Part of the published software was the exploitation framework FuzzBunch and post-exploitation framework DanderSpritz. DanderSpritz is a full-blown command and control server, or listening post in NSA terms. It can be used to stealthy perform various actions on hacked computers, like finding and exfiltrating data or move laterally through the target network. Its GUI is built on Java and contains plugins written in Python. The plugins contain functionality in the framework to perform specific actions on the target machine. One specific plugin in DanderSpritz caught the eye of the Forensics & Incident Response team at Fox-IT: eventlogedit.

DanderSpritz with eventlogedit in action

Figure 1: DanderSpritz with eventlogedit in action

eventlogedit

Normally, the content of Windows Event Log files is useful for system administrators troubleshooting system performance, security teams monitoring for incidents, and forensic and incident response teams investigating a breach or fraud case. A single event record can alert the security team or be the smoking gun during an investigation. Various other artefacts found on the target system usually corroborate findings in Windows Event Log files during an investigation, but a missing event record could reduce the chances of detection of an attack, or impede investigation.

Fox-IT has encountered event log editing by attackers before, but eventlogedit appeared to be more sophisticated. Investigative methods able to spot other methods of event log manipulation were not able to show indicators of edited log files after the use of eventlogedit. Using eventlogedit, an attacker is able to remove individual event log entries from the Security, Application and System log on a target Windows system. After forensic analysis of systems where eventlogedit was used, the Forensics & Incident Response team of Fox-IT was able to create a Python script to detect the use of eventlogedit and fully recover the removed event log entries by the attacker.

Analysing recovered event records, deleted by an attacker, gives great insight into what an attacker wanted to hide and ultimately wanted to achieve. This provides security and response teams with more prevention and detection possibilities, and investigative leads during an investigation.

Before (back) and after (front) eventlogedit

Figure 2: Before (back) and after (front) eventlogedit

eventlogedit in use

Starting with Windows Vista, Windows Event Log files are stored in the Windows XML Eventlog format. The files on the disk have the file extension .evtx and are stored in the folder \Windows\System32\winevt\Logs\ on the system disk, by default. The file structure consists of a file header followed by one or more chunks. A chunk itself starts with a header followed by one or more individual event records. The event record starts with a signature, followed by record size, record number, timestamp, the actual event message, and the record size once again. The event message is encoded in a proprietary binary XML format, binXml. BinXml is a token representation of text XML.

Fox-IT discovered that when eventlogedit is used, the to-be-removed event record itself isn’t edited or removed at all: the record is only unreferenced. This is achieved by manipulation of the record header of the preceding record. Eventlogedit adds the size of the to-be-removed-record to the size of the previous record, thereby merging the two records. The removed record including its record header is now simply seen as excess data of the preceding record. In Figure 3 this is illustrated. You might think that an event viewer would show this excess or garbage data, but no. Apparently, all tested viewers parse the record binXml message data until the first end-tag and then move on to the next record. Tested viewers include Windows Event Viewer as well as various other forensic event log viewers and parsers. None of them was able to show a removed record.

Untouched event records (left) and deleted event record (right)

Figure 3: Untouched event records (left) and deleted event record (right). Note: not all field are displayed here.

Merely changing the record size would not be enough to prevent detection: various fields in the file and chunk header need to be changed. Eventlogedit makes sure that all following event records numbers are renumbered and that checksums are recalculated in both the file and chunk header. Doing so, it makes sure that obvious anomalies like missing record numbers or checksum errors are prevented and will not raise an alarm at the system user, or the security department.

Organizations which send event log records on the fly to a central log server (e.g. a SIEM), should be able to see the removed record on their server. However, an advanced attacker will most likely compromise the log server before continuing the operation on the target computer.

Recovering removed records

As eventlogedit leaves the removed record and record header in its original state, their content can be recovered. This allows the full recovery of all the data that was originally in the record, including record number, event id, timestamps, and event message.

Fox-IT’s Forensics & Incident Response department has created a Python script that finds and exports any removed event log records from an event log file. This script also works in the scenario when consecutive event records have been removed, when the first record of the file is removed, or the first record of a chunk is removed. In Figure 4 an example is shown.

Recovering removed event records

Figure 4: Recovering removed event records

We have decided to open source the script. It can be found on our GitHub and works like this:

$ python danderspritz_evtx.py -h
usage: danderspritz_evtx.py [-h] -i INPUT_PATH [-o OUTPUT_PATH]
 [-e EXPORT_PATH]

danderspritz_evtx.py - Parse evtx files and detect the use of the danderspritz
module that deletes evtx entries

optional arguments:
 -h, --help show this help message and exit
 -i INPUT_PATH, --input INPUT_PATH
 Path to evtx file
 -o OUTPUT_PATH, --output OUTPUT_PATH
 Path to corrected evtx file
 -e EXPORT_PATH, --export EXPORT_PATH
 Path to location to store exported xml records

The script requires the python-evtx library from Willi Ballenthin.

Additionally, we have created an easy to use standalone executable for Windows systems which can be found on our GitHub as well.

Danderspritz_evtx.exe

Hashes:
md5    c07f6a5b27e6db7b43a84c724a2f61be 
sha1   6d10d80cb8643d780d0f1fa84891a2447f34627c
sha256 6c0f3cd832871ba4eb0ac93e241811fd982f1804d8009d1e50af948858d75f6b

 

Recommendations

To detect if the NSA or someone else has used this to cover up his tracks using the eventlogedit tool on your systems, it is recommended to use the script on event log files from your Windows servers and computers. As the NSA very likely changed their tools after the leaks, it might be farfetched to detect their current operations with this script. But you might find traces of it in older event log files. It is recommended to run the script on archived event log files from back-ups or central log servers.

If you find traces of eventlogedit, and would like assistance in analysis and remediation for a possible breach, feel free to contact us. Our Forensics & Incident Response department during business hours or FoxCERT 24/7.

Wouter Jansen
Fox-IT Forensics & Incident Response

Ransomware deployments after brute force RDP attack

Fox-IT has encountered various ways in which ransomware is being spread and activated. Many infections happen by sending spam e-mails and luring the receiver in opening the infected attachment. Another method is impersonating a well-known company in a spam e-mail stating an invoice or track&trace information is ready for download. By following the link provided in the e-mail, the receiver can download the file which contains the malware from a convincing looking website. Distributing ransomware through malvertising, an exploit kit being served on an advertisement network, is also a common way for criminals to infect systems.

In the past few months, Fox-IT’s incident response team, FoxCERT, was involved in several investigations where a different technique surfaced: activating ransomware from a compromised remote desktop server.

Getting access

Before we get to why this might be lucrative for the criminals, how do they get access in the first place? RDP, or Remote Desktop Protocol, is a propriety protocol developed by Microsoft to provide remote access to a system over the network. This can be the local network, but also the Internet. When a user successfully connects to a system running remote desktop services (formerly known as terminal services) over RDP, the user is presented with a graphical interface similar to that when working on the system itself. This is widely used by system administrators for managing various systems in the organization, by users working with thin clients, or for working remotely. Attackers mostly tend to abuse remote desktop services for lateral movement after getting foothold in the network. In this case however, RDP is their point of entry into the network.

Entries in the log files show the attackers got access to the servers by brute forcing usernames and passwords on remote desktop servers that are accessible from the internet. Day in, day out, failed login attempts are recorded coming from hundreds of unique IP-addresses trying hundreds of unique usernames. Connecting remote desktop servers directly to the internet is not recommended and brute forcing remote desktop services is nothing new. But without the proper controls in place to prevent or at least detect and respond to successful compromises, brute force RDP attacks are still relevant. And now with a ransomware twist as well.

visio_blog
Image 1: Example network with compromised RDP server and attacker deploying ransomware.

The impact

After brute forcing credentials to gain access to a remote desktop server, the attackers can do whatever the user account has permissions to on the server and network. So how could an attacker capitalize on this? Underground markets exist where RDP credentials can be sold for an easy cash-out for the attacker. A more creative attacker could attempt all kinds of privileged escalation techniques to ultimately become domain administrator (if not already), but most of the times this is not even necessary as the compromised user account might have access to all kinds of network shares with sensitive data. For example Personally identifiable information (PII) or Intellectual property (IP) which in its turn can be exfiltrated and sold on underground markets. The compromised user account and system could be added to a botnet, used as proxy server, or used for sending out spam e-mail messages. Plenty of possibilities, including taking the company data hostage by executing ransomware.

Depending on the segmentation and segregation of the network, the impact of ransomware being executed from a workstation in a client LAN might be limited to the network segments and file shares the workstation and affected user account can reach. From a server though, an attacker might be able to find and reach other servers and encrypt more critical company data to increase the impact.

The power lies in the amount of time the attackers can spend on reconnaissance if no proper detection controls are in place. For example, the attackers have time to analyze how and when back-ups are created of critical company data before executing the ransomware. This helps to make sure the back-ups are useless in restoring the encrypted data which in its turn increases the chances of a company actually paying the ransom. In the cases Fox-IT was involved in investigating the breaches, the attackers spend weeks actively exploring the network by scanning and lateral movement. As soon as the ransomware was activated, no fixed ransom was demanded but negotiation by e-mail was required. As the attackers have a lot of knowledge of the compromised network and company, their position in the negotiation is stronger than when infection took place through a drive-by download or infected e-mail attachment. The demanded ransom reflects this and could be significantly higher.

indialocker
Image 2: Example ransomware wallpaper.

Prevention, detection, response

Connecting Remote Desktop Services to the Internet is a risk. Services like that, which are not essential, should be disabled. If remote access is necessary, user accounts with remote access should have hard to guess passwords and preferably a second factor for authentication (2FA) or second step in verification (2SV). To prevent eaves dropping on the remote connection, a strong encryption channel is recommended. Brute force attacks on remote desktop servers and ransomware infections can be prevented. Fox-IT can help to improve your company’s security posture and prevent attacks, for example by an architecture review, security audit or training.

If prevention fails, swift detection will reduce the impact. With verbose logging securely stored and analyzed, accompanied by 24/7 network and end point monitoring an ongoing breach or malware infection will be detected and remediated. The Cyber Threat Management platform can assist in detecting and preventing attacks. And if business continuity and reputation are at stake, our emergency response team is available 24/7.

Wouter Jansen, Senior Forensic IT Expert at Fox-IT