Posted by Felix, March 2017.
Author contact: Twitter | Mail | LinkedIn
Tags: Necurs botnet, Nemucod, Locky ransomware, malware/threat intelligence, rootkit, monitoring, indicators of compromise, SPAM, tshark, ettercap, scripting, Talos LockyDump
I recently came across an interesting paper titled "botwatcher: transparent and generic botnet tracking". The paper discusses ways to track a botnet, a centrally controlled group of computers on which a backdoor is installed. One of the botnets discussed in the paper is called Necurs. Necurs is a group of compromised computers which send spam emails with malicious attachments to a large number of recipients – usually the messages are created to look like a request to check invoice details or to confirm a purchase. The attachments contain packed scripts which install Locky ransomware when ran. The paper enthused me to gather malware intelligence regarding the origin of Locky ransomware. Initially only the spammails and the malicious packed scripts (droppers) spread by the Necurs botnet were in scope of the malware intelligence system. Later on I also added payload (Locky ransomware) intelligence.
In this blog I will discuss the creation and results of the basic self-developed Locky malspam intelligence system. My approach was to run the Necurs rootkit in a virtualized environment (setup displayed below). Running the rootkit made me join the Necurs botnet and gave the Necurs operators control over the virtualised PC. Not long after infecting the virtualised PC with Necurs, it started to send Locky SPAM mails. This behaviour was monitored and controled (restricted) with a firewall. Monitoring the sent malicious mails (with the help of packet captures) was used as input for the intelligence system.
Image one: Setup of the malware intelligence system. The virtual machine is part of the Necurs botnet which sends malicious mails to mail servers. The PCs in the botnet connect to peers and to a centralised C&C server.
The gathered intelligence is stored in a database and displayed via a dashboard (initial dashboard build shown below). Each monitored SPAM wave is an entry in the dashboard. For each SPAM wave, the subject and contents of the mails are stored, as well as the attachments (samples and hashes). The malicious mail attachments (droppers) are detonated in a sandbox. This detonation creates additional threat intell such as the payload hosting location (URL) and the payload itself (Locky ransomware, a packed DLL file). Finally, the payload (Locky) is used to extract additional information such as hardcoded command and control IPs (used to send statistics and encryption key), URL postback pattern and affiliate identifier. All this is intelligence is gathered automatically, no manual interaction is required.
To become part of the Necurs botnet, I used this Necurs sample to infect a virtual windows 7 machine. Necurs nests itself inside a Windows installer folder and shows a lot of rootkit like behavior. The malware comes with a lot of self-protective measures, a few of them are shown in image three. While Necurs is running, it is not possible to kill the Necurs process (hidden as syshost), to start monitoring tools that make use of drivers (such as memory dumping tools or sysinternals process monitor) or to view the access rights to the executable.
Necurs sends a heartbeat via HTTP to its C&C server every six minutes on average, communication with peers is done via UDP. The Necurs infected PC sent SPAM waves almost daily; I didn't notice any SPAM waves during the night, nor during weekends.
The virtual machine infected with Necurs sent plaintext SMTP mails, which makes it easy to monitor. An example mail sent by the infected machine is shown below.
To capture the mails, I created a basic batch script which I ran inside the infected virtual machine. The script runs a loop which captures the network traffic via Wireshark and saves it as a packet capture. At the end of the loop, the packet capture is inspected for presence of SMTP mails with the help of tshark (commandline wireshark). If SMTP traffic is found in the packet capture, the network adapter gets disabled for two hours to prevent the machine sending any additional mails. The packet capture containing the SMTP mails is then processed by another script which extracts the SMTP attachments, this will be explained in the next paragraphs.
Script one: Bath script which creates packet captures (pcaps) until SMTP mail traffic is detected. When SMTP traffic is detected, the ethernet adapter gets disabled.
The script shown in the previous paragraph prevents the Necurs infected machine from sending spam mails any longer than thirty seconds. A lot of additional countermeasures were taken to prevent that any malicious mail was actually received by a mail server. Discussing all these countermeasures is out of the scope of this blog, however I will discuss one easy to implement countermeasure, namely content filtering with ettercap.
I used a second virtual machine running Kali Linux to run ettercap, and I routed the internet traffic from the infected Windows machine trough the Kali machine.
To test the filtering setup, I first tried to filter the browser user agent from the infected machine. I used a simple ettercap rule which replaced the string "Firefox" with "LiteFox". The rule was compiled and the virtual Windows machine was put on the target list of ettercap, as shown on image six.
When visiting a website with a Firefox browser on the infected Windows machine, the user agent got changed. This replacement is transparent to the virtual Windows machine: i.e. when inspecting the sent requests inside the machine, we still see a "Firefox" string. The receiver of the request (e.g. the whoishostingthis.com website) however receives a modified user agent, as shown on image seven.
Mail attachment (dropper) extraction (tshark)
In the mail monitoring paragraph, I explained how packet captures containing the SMTP mails were automatically generated. In this paragraph, I will briefly explain how the mail attachments are extracted from those packet captures. I created a quick-and-dirty powershellscript to extract the (base64 encoded) mail attachments. The script uses a tshark functionality to dump the contents of a specific TCP (conversation) stream. Tshark can only dump a TCP stream for which a specific numerical index is defined, so the script needs to provide a list of indices which correspond to TCP streams containing SMTP mail attachments. Each TCP stream is dumped in hex format, so the script needs to convert the hex format to an ASCII format. Finally, the conversion result (base64 encoded mail attachments, mostly zip files) needs to be stored in a text file.
Script two: Powershell script which extracts zip attachments from SMTP mails in packet captures (pcaps)
The first part of the above script dumps mails in ASCII format. The second part of the script looks for unique base64 encoded zip files. Each SPAM wave generated at least twenty unique zip files, each zip file contains a malicious script with an extension such as "js" or "wsf". The zip files are decoded, extracted and sent to a sandbox, where they will be executed (not shown in script). Their execution will provide additional threatintell, this will be explained in the last paragraph.
Payload extraction and intelligence
The final part in the basic Locky malspam intelligence system is responsible for gathering some intelligence regarding what the cybercriminals actually try to achieve by sending their spam mails: deliver ransomware to the end user. The previous paragraph explained how the droppers (mail attachments) were extracted. Automated static inspection of these droppers with the goal of finding additional indicators of compromise (IOCs) is hard because of the high obfuscation grade of the embedded scripts. It is much easier to automatically extract the scripts from the zip archive, and to dynamically run and analyze them in a sandbox. Running a Locky dropper script always generates the same pattern: an encrypted file is downloaded from a website. This encrypted file is decrypted and saved as a dynamic link library (DLL). This DLL is the Locky ransomware payload and is executed via the 'rundll32' Windows executable. The ransomware does not immediately start encrypting the files, it sleeps a certain amount of time to avoid sandbox detection. This behaviour gives us the opportunity to run the malicious dropper in a sandbox, and to wait until the rundll32 process is started. If we terminate the started rundll32 process immediately, no harmful changes will be made to the sandbox. The started rundll32 process will contain the location of the downloaded, decrypted payload (the DLL file) in its commandline argument.
The payload hosting URL can be extracted from packed captures, the payload itself can automatically be archived in the intelligence system. The archived payload (Locky) contains a lot of additional interesting information, which is also usefull to put in the intelligence system. Examples are: hardcoded command and control servers, URI patterns and an affiliate identifier. This information can easily be extracted from the DLL with a fantastic tool called 'LockyDump', developed by Talos. Below an example of the output of the payload extraction and intelligence script is shown.
Transparent and Generic Botnet Tracking, T. Barabosch et al.
Necurs analysis, CERT Poland
Angler exploit kit delevering Necurs, B. Duncan (SANS ISC)
Necurs – the Heavyweight Malware Spammer, TrustWave
The curse of Necurs (blacklisting drivers), Virus Bulletin
Analysis of Necurs botnet in 2012 (French), Malekal.com
Tutorial on how to use ettercap on Kali Linux, YouTube
TCP flow, Wikipedia
Extracting Locky config with LockyDump, Talos