Year: 2016

Introduction

On February 16, 2016 Google described a critical vulnerability in GLIBC’s getaddrinfo function. They provided a crash PoC, and so the task of producing a reliable exploit began. In this post, we will show how CVE-2015-7547 can bypass ASLR-enabled systems.

The Bug

getaddrinfo() is used to resolve a hostname and a service to struct addrinfo. This is done by performing a DNS query to get the corresponding IP address(es).

As an optimization, getaddrinfo()’s implementation uses alloca() function (which allocates a buffer on the stack) for the DNS response. In case the response is too long, it allocates a heap buffer and uses that instead. The bug stems from the fact that, under certain circumstances, the code updates the buffer size to the newly allocated heap buffer but keeps using the old stack buffer pointer. This creates a classic stack-bases overflow.

ASLR? ASLR!

The return address of getaddrinfo can be overwritten using this vulnerability, but where should we point it? In ASLR-enabled systems, module addresses are randomized. Therefore an attacker is not able to set the execution flow to a predefined address. In case the exploited application is compiled with PIE (as it should be), we cannot rely on its main executable to be located at a predefined location.

fork()

The standard way to create new processes in Linux is fork(). A typical fork would look like the following:

Code resumes from the same opcode instruction in both parent and child processes. It only differs by the value of “pid”, which is returned by fork(). Unlike Windows, this means that a child process shares many characteristics with its parent — it has the same register state, stack and memory layout.

Sample Application Flow

Let us consider a server application that acts like the following:

1. A client remotely connects to the application.
2. In order to handle the client’s request, the application daemon forks itself.
3. As part of handling the request, the forked child process resolves a hostname using the “getaddrinfo()” function. Thus, it sends a DNS request to its DNS server.
4. DNS server replies with a valid response for the DNS request.
5. Child process initiates a connection with the resolved host.

Each time a request is handled by the daemon, it forks itself. This means that all child processes will share the same memory layout – including the addresses where modules are loaded. This simplified scenario is very common for many services such HTTP-proxies, email servers or DNS servers.

Exploitation Flow

For exploitation, we assume an attacker has the ability to answer arbitrary DNS requests performed by the server victim. The way this can be achieved is out of the scope of this paper; but, to name a few, this can be done by local ARP poisoning attack, DNS spoofing, etc.

1. An attacker initiates a request to the victim server.
2. In order to handle the attacker’s request, the victim daemon forks itself.
3. Forked child process performs a DNS request.
4. Attacker replies with a malicious DNS response that overwrites the child process’ instruction pointer (RIP) to the address. In this example, it sets it to 0x12121212.
5. Attacker gets a TCP-syn request initiated by the child process using “connect ()”.

If 0x12121212 is indeed the right return address of “getaddrinfo()”, then the application flow is continued as it should and issues the “connect()” right afterward.

If this is not the situation, and the attacker transferred the instruction pointer (RIP) to any other address, the application will crash either due to a segmentation fault or invalid opcode execution.

This behavior can be used as an indication of whether an address is the correct return address of getaddrinfo (if so, a TCP-connection will be created). Since module addresses are not randomized between different forks(), this address remains constant in all child processes. An attacker can abuse this behavior and enumerate all possible addresses until guessed correctly. At each DNS-response, the adversary would reply with a different address, knowing a crash means that address is incorrect.

However, this still requires enumerating ~2⁶⁴, which is not feasible.

Byte-by-Byte Approach

Instead, the attacker can overwrite a single byte every time. For example, assume the return address of getaddrinfo is 0x00007fff01020304:

We first respond with the right amount of bytes that only overwrite the LSB of getaddrinfo’s return address. We overwrite it with 0x00, which is incorrect since, in the above example, the return address LSB is 0x04; getaddrinfo will return to 0x00007fff01020300, which is invalid, and will crash. We repeat this process, but each time we increase the guessed LSB by 1. When we reach 0x04, the application won’t crash – this means 0x04 is the LSB of the return address!

Now we repeat the entire process, enumerating the next byte by overwriting 2 bytes of the return address (0x04 0x00). We set the value of the first byte (LSB) to the previously leaked one, so we only enumerate the second. This is proceeded until the entire return address is leaked (each time enumerating the next byte).

With this approach, the maximum amount of tries is 8 * 2⁸ tries (2⁸ per byte, 8 bytes per address). This enumeration is quite small and feasible within a few seconds.

Finding Exploitable Applications

We used the website http://codesearch.debian.net, which indexes the source of ~18,000 Debian packages. Searching for all the applications that call both “fork()” and “getaddrinfo()”, we found over 1300 potential exploitable apps. We then need to inspect the source code of each app and check if its flow suits our needs.

Tinyproxy

The tinyproxy application matches this flow. A new child process is “fork()d” when it issues an HTTP-connect request. It then calls “getaddrinfo()” to retrieve the IP address of the requested website. Then “connect()”s that host to get the website content.

Exploitation

The diagram previously shown is a simplification of the actual scenario. When overwriting the return address, we also overwrite several stack variables. If the attacker doesn’t set those to the right values beforehand, the application will crash before returning from getaddrinfo. If that happens, the adversary will not be able to overwrite RIP. Thus the attacker would employ the same technique in order to leak them.

Leaking an Arbitrary Stack Pointer

The first crash we encountered happened to be on the following code block:

First, rbx gets overwritten. It is then dereferenced by the “mov BYTE PTR [rbx], sil” instruction. Originally, rbx pointed to a buffer on the stack. This means that, if we use the byte-by-byte approach, we can enumrate its value and leak an address on the stack.

The diagram below (output of /proc/PID/maps) shows the stack’s boundaries. As you can see, its initial size is always greater than 0x1000 bytes.

The address pointed by rbx must be writable (otherwise a segmentation fault will be raised). But it happened to be a flaw in which it doesn’t matter to where we write the value of “sil”. As long as it is a writeable address, the flow will continue correctly. This means that it does not matter what value we set to the lower 12 bits of rbx since it will always be readable due to the size of the stack.

So we leaked an arbitrary pointer within the stack range. What happens when we have to be precise, where the address pointed by a stack variable affects the flow in a considerable way?

Leaking Stack Base

For situations like these, we have to rely on constant offsets. Since the flow of the application is always the same, the stack depth will always be the same. This means we can rely on the offset from stack base to these variables, structs and buffers.

Leaking the stack base is simpler than enumerating an arbitrary address. Since we already have an address within stack range – we can enumerate where the stack base is. We know the stack base is aligned to a page boundary (0x1000), and we also know that it will be the first non-readable address following the stack.

Let us assume that the stack base is at 0x00007fffed008000. We take the arbitrary stack address we leaked and align it to a page boundary – for instance 0x00007fffed000140 is aligned to 0x00007fffed000000. We then enumerate the stack base, starting from this aligned address and incrementing it between each attempt by 0x1000 (page size). After we send a response that overwrites the previously mentioned pointer, we wait for a short while and check if the server tried to connect to our resolved IP. If it did, it means we haven’t reached the stack base yet. If a timeout occurs, we assume the server crashed and we reached our goal.

Stack Base Offset

Before returning from getaddrinfo, the following check is performed:

(@ glibc nss_dns_gethostbyname4_r)

Note the block that is highlighted in red. If we reach it and pass an invalid heap pointer as an argument, the application crashes (as it tries to free an invalid heap block). To bypass this free(), r14 and rdi must be equal. r14 points to the original __alloca() stack buffer. Since the stack base was previously leaked, and the __alloca() buffer’s offset from the stack base should be constant, we didn’t expect to encounter any problem. However, we found out that the offset is slightly different at every run. Why?

/arch/x86/kernel/process.c

Observing the above kernel code, you can see that, if ASLR is enabled, SP (stack-pointer) is decremented by a random number. This means that there will be a random delta between rsp and the stack base on every different run.

Fortunately, this number is quite small – only slightly bigger than the size of your average byte. We can easily enumerate this random offset.

Looking at the above IDA code snippet, we can see that if rdi equals to r14, the code path that attempts to free rdi won’t be taken. Thus, we used our previously leaked stack base, combined with a pre-calculated (i.e., if arch-align stack would return 0), and then attempted all the other 2⁹possibilities.

Leaking LIBC Module

This part is now trivial, as we use the previously mentioned technique to enumerate each byte of the return address.

Code Execution

All that is left to do is to construct a ROP chain. This is very easy and straightforward. We know the offset of system() function from the base of libc, so we just set up its argument and call it using ROP.

Conclusion

“Classic” stack overflow vulnerabilities do not provide address leaks by nature. Still, under certain conditions, an attacker can leverage creative techniques to exploit those vulnerabilities. In this research, we abused the way Linux creates processes to bypass ASLR. In other scenarios, different security mitigations might be evaded.

This technique can be leveraged for other memory corruption bugs. Therefore, a vigilant user should always attempt to secure servers by deploying software patches and updates in a timely fashion. At Palo Alto Networks, developing a deeper understanding of such exploitation methods is a core objective of our mission to help our clients prevent breaches and secure our way of life in the digital age. This type of knowledge allows us to develop better threat intelligence and implement preventive techniques that help our customers stay one step ahead of potential threat actors.

Gal De Leon and Nadav Markus

[Palo Alto Networks Research Center]

In May 2016, Unit 42 observed targeted attacks primarily focused on financial institutions and technology organizations within Saudi Arabia. Artifacts identified within the malware samples related to these attacks also suggest the targeting of the defense industry in Saudi Arabia, which appears to be related to an earlier wave of attacks carried out in the fall of 2015. We have grouped these two waves of attacks into a campaign we have named ‘OilRig’.

In recent OilRig attacks, the threat actors purport to be legitimate service providers offering service and technical troubleshooting as a social engineering theme in their spear-phishing attacks. Earlier OilRig attacks appear to use fake job offers as a social engineering theme. The campaign appears highly targeted and delivers a backdoor we have called ‘Helminth’. Over the course of the attack campaign, we have observed two different variations of the Helminth backdoor, one written in VBScript and PowerShell that was delivered via a macro within Excel spreadsheets and the other a standalone Windows executable.

Clayslide: Excel Macros Install Helminth Script

In May 2016, Unit 42 began researching attacks that used spear-phishing emails with attachments, specifically malicious Excel spreadsheets sent to financial organizations within Saudi Arabia. We observed spear-phishing emails sent between May 4 and May 12 of this year that delivered these malicious Excel spreadsheets, which we are tracking as ‘Clayslide’. ClaySlide documents contain malicious macros that display decoy content within the spreadsheet and installs a variant of a Helminth backdoor. FireEye also reported on these attacks in a May 22 blog post.

The macro within Clayslide samples installs the Helminth script, which is composed of a VBScript called ‘update.vbs’ and a PowersShell script called ‘dns.ps1’. The purpose of the VBScript is to send network beacons to its command and control server using HTTP requests and will either download a file or run a batch script provided within the HTTP response. The VBScript also uploads the output of the provided batch scripts to the command and control (C2) server, which provides threat actors a functional remote shell to the system.

The PowerShell script has similar capabilities to the VBScript, but instead of using HTTP for communications it uses a series of DNS queries to send and receive data from the server. This communication channel relies on the C2 server responding to DNS queries with IP addresses that the PowerShell script will parse treat as data to construct a batch script to execute on the system. The script specifically looks for the IP address “33.33.x.x” to mark the beginning of the batch script transfer. The script will continue sending additional DNS requests and use the octets of the resolving IP addresses as characters to write to the batch script. The script continues to write data to the batch script until it receives the IP address “35.35.35.35”, which notifies the script to stop saving data to the file and to run the batch script.

Please reference the Appendix for more detailed information on the Clayslide delivery documents and the Helminth script variant.

Discovery of Executable Helminth Variant

Additional samples were discovered in WildFire exhibiting the same DNS-based C2 behavior as the script variant of Helminth; however, many of these samples were found to be Windows executable, instead of the previously observed VBScript and PowerShell combination. These samples were found to contain the same functionality as the previously mentioned Helminth samples. Figure 1 shows the code within the VBScript version of Helminth checking resolving IP addresses for the 35.35.35.35 IP address to stop appending data to a batch script before executing it, while Figure 2 shows the same functionality within the executable version of the Trojan.

Figure 1 Helminth dns.ps1 PowerShell script looking for 35.35.35.35 IP address

Figure 2 Helminth executable looking for the 35.35.35.35 IP address

This suggests that the threat actors developed the executable variant of Helminth as a standalone option whose installation does not rely on a macro within an Excel spreadsheet. This also suggests that the threat actors purposely used the same communication methods across both variants with the intention to use the same command and control server application. This variant of the Trojan is also where we obtained its name, as several of these payloads had the following debug symbol path that suggests the malware author called this project ‘Helminth’:

E:\Projects\hlm updated\Helminth\Release\Helminth.pdb

Please reference the Appendix for additional details on the Helminth executable variant.

Delivery of Windows Executable Helminth Variant

Unit 42 does not have detailed targeting information associated with attacks delivering the executable variant of the Helminth Trojan, however, we found a Zip archive created in August 2015 that may have been used by the threat actors to deliver the Helminth Trojan. This Zip file was hosted at the following location:

hxxp://minfosecu.doosan[.]com/data/joboffer.zip

The Zip archive is encrypted with an unknown password, but we know it contains two files named joboffer.chm and thumb.db. The thumb.db file in the archive has the same name and file size (368128 bytes) as a dropper Trojan we track as ‘HerHer’ (SHA256: fb424443ad3e27ef535574cf7e67fbf9054949c48ec19be0b9ddfbfc733f9b07) that installs a known Helminth executable sample. The joboffer.chm file is a compiled HTML file that we believe loads and executes the ‘thumb.db’ file as a payload, but we cannot be absolutely sure as we do not have the password required to extract the files from the archive.

The decoy opened by the Helminth sample installed by ‘thumb.db’ (seen in Figure 3) is a dialog box associated with HTML help, which further strengthens our theory that the joboffer.chm ran the sample. This decoy suggests that the threat actors wanted to open the HTML help dialog after installing the Helminth Trojan, as the joboffer.chm file is effectively a standalone HTML file. We believe that the threat actors employed social engineering to underplay the situation and provide a different legitimate job offer if the victim responded with concerns of malicious activity.

Figure 3 A Helminth sample displays this dialog box if provided ‘w’ on the command line

The executable variant of Helminth is installed with a dropper Trojan that we are tracking as the HerHer Trojan. This Trojan has two objectives: installing embedded Trojans and displaying either a fake error prompt or a fake “trubleshooting” (the malware author misspelled this word in each sample) utility. Figures 4 and 5 display an example of the fake error prompt and the fake Websphere troubleshooting utility displayed by the HerHer Trojan. The fake troubleshooting utility fits the service provider social engineering theme as seen in the decoy contents displayed in the Clayslide Excel spreadsheets.

Figure 4 Fake Error Prompt Displayed by the HerHer Trojan

Figure 5 Fake Troubleshooting Utility Displayed by the HerHer Trojan

The Helminth executable variant is very similar in functionality to its script-based counterpart, as it also communicates with its C2 server using both HTTP and DNS queries. The major difference in capabilities between the two variants is that the executable version comes with a module that Helminth uses to log keystrokes and the clipboard contents to exfiltrate to the C2 server.

Helminth executable samples send artifacts within network beacons to its C2 server that the Trojan refers to as a ‘Group’ and ‘Name’. We extracted the group and name values from the Helminth executable samples to determine their purpose. It appears that the group values hardcoded into the malware is associated with the targeted organization, as several are Saudi Arabian organizations within the telecommunications and defense industries. This suggests that the threat actors are not only focused on financial organizations, as their target set could include other industries as well.

The name values hardcoded into the Helminth samples are also interesting, as a majority of the names are related to famous philosophers, such as ‘Plato’ (Greek philosopher), ‘Arasto’ (Persian and Urdu for Greek philosopher Aristotle), and ‘ALAfghani’ (Jamal ad-Din al-Afghani, Islamic Philosopher). Other name values embedded in samples contain other Persian words, such as ‘Nafti’ (نفتی) that translates to ‘oily’, which led us to name this campaign OilRig).

Helminth Infrastructure

Examining the known infrastructure of the collected sample set of Helminth provides several interesting findings in regards to the adversary’s tactics. The variants leveraging malicious macros embedded in Excel documents all share the same command and control server of go0gie[.]com. The executable variants, on the other hand, used a variety of domains:

checkgoogle[.]org
mydomain1110[.]com
kernel[.]ws
mydomain1607[.]com
mydomain1609[.]com

 

Figure 6 Helminth C2 Infrastructure

Each sample of the weaponized Excel document variant used a unique command and control domain to retrieve a bot ID, using the following format:

00000000<base 36 of a random number smaller than 46655>30.go0gie[.]com

Each of these domains, however, resolved to the same IP address of 5.39.112.87. This IP is observed as the resolution for two domains in use by the portable executable variants, kernel[.]ws and mydomain1110[.]com. Judging by compile timestamps of the executables and last saved timestamps of the weaponized documents, it is likely the adversary is recycling a previously created C2 server at 5.39.112.87 for the newer macro based variant. The other C2 domains and IPs observed in use by the previous portable executable samples did not have shared infrastructure with the newer macro variants, although there is tactical overlap via the naming scheme of the domains.

Historical WHOIS data reveals additional findings, potentially alluding to an Iranian-based operator. From a timeline perspective, a new domain was registered almost in consecutive months, beginning in July 2015. Each of the domains’s WHOIS data contained registrant information that was either reused, or was closely related to previously used information. For example, the domains mydomain1607[.]com and mydomain1609[.]com used the exact same registrant information. The email address edmundj@chmail[.]ir and the geolocation of Tehran, Iran, being of note. Kernel[.]ws and checkgoogle[.]org used very similar email addresses, andre_serkisian@yahoo[.]com and andre.serkisian@chmail[.]ir, respectively. The registrant information for kernel[.]ws also provided a geolocation of Tehran, IR and the email provider for the address used in checkgoogle[.]org was the same used for mydomain1607[.]com and mydomain1609[.]com, chmail.ir. The mydomain1110[.]com domain did not appear to reuse any of the previously observed WHOIS data artifacts, but did still give a geolocation of Tehran in addition to the use of an email address linked to other domains thematically similar to the know command and control domains and are potentially related.

Although there is heavy use of Iranian-based artifacts within the WHOIS registrant information, it is important to remember that this data is easily falsified. At face value, however, taking into account the registrant information and the use of Persian language in the samples are compelling indicators that the operators may indeed be based out of Iran.

Conclusion

While researching the OilRig campaign, we have seen two waves of targeted attacks on Saudi Arabian organizations in which a group of threat actors delivered the Helminth Trojan as a payload. The two waves of attacks used separate variants of the Helminth Trojan, specifically a script and executable variant of the Trojan.

The two variants of Helminth use almost identical command and control protocols, which allows the threat actors to maintain consistent infrastructure throughout the campaign to manage the compromised hosts, regardless of the Helminth variant used in the attack.

The two variants of Helminth do require different delivery methods, with the script variant relying on an Excel spreadsheet for delivery, while the executable variant is more traditional in the fact that it can be installed without a delivery document. We speculate that the executable variant involves threat actors socially engineering the victim into running the payload, rather than installing the payload as the result of successful exploitation of a vulnerability. The multiple delivery methods suggest this threat group is capable of adapting their procedures to suit the current operation in the overarching campaign.

Palo Alto Networks customers are protected from the Helminth Trojan and can gather additional information using the following tools:

• WildFire detection of all known samples as malicious
• All Helminth C2 domains have DNS signatures created and are identified as malicious in PAN-DB.
• AutoFocus tags Clayslide, Helminth and HerHerDropper.

Appendix

Clayslide Delivery Documents

At first, Clayslide spreadsheets display a worksheet called “Incompatible” that contains instructions for the user to manually enable macros (as seen in Figure 7), as macros are disabled in Excel by default. This is an attempt to trick the user into running the embedded macro to install the Trojan, which does not require any vulnerability exploitation. Figure 7 shows the “Protected View” alert in Excel informing the user that there is an embedded macro that may cause harm to the system.

Figure 7 Clayslide spreadsheet showing the Incompatible worksheet with instructions to enable macros and Excel displaying its Protected View alert message

Before the user can enable the macros in accordance with the instructions displayed in the spreadsheet, the user must click the red bar displayed by Protected View and click the “Edit Anyway” button, as seen in 8.

Figure 8 Protected View further mentioning the potential danger with editing the spreadsheet in the ClaySlide sample

After clicking the “Edit Anyway” button, Excel displays another security warning bar alerting that the spreadsheet contains macros, as seen in Figure 9. The “Enable Content” button mentioned within the instructions displayed within the Clayslide spreadsheet is now presented to the user.

Figure 9 Excel security warning with the Enable Content button mentioned in Incompatible worksheet

If the user clicks the “Enable Content” button, the macro hides the “Incompatible” worksheet and makes hidden worksheets visible that displays decoy content to minimize the victim’s suspicions of malicious behavior taking place. Figure 10 below shows the decoy content displayed by macros within a Clayslide sample, specifically showing the status of internal network IP addresses that fit with the service provider social engineering theme used throughout the attack campaign. Figure 10 also shows that the “Incompatible” worksheet is no longer visible, as the decoy content is displayed in a worksheet called “Sheet1”.

Figure 10 Decoy content displayed after enabling macros within a Clayslide sample

After displaying the decoy content, the macro begins installing the script variant of the Helminth Trojan to the system. The process used by the macro to install this variant of Helminth begins with the creation of the following files and folders:

%PUBLIC%\Libraries\update.vbs
%PUBLIC%\Libraries\dns.ps1
%PUBLIC%\Libraries\up
%PUBLIC%\Libraries\dn
%PUBLIC%\Libraries\tp

The malicious macro finishes the installation process by creating a scheduled task that is responsible for running the two scripts at regular intervals, as the scripts themselves do not have the ability to continually run after the initial execution. The following code snippet within the macro creates a scheduled task named “GoogleUpdateTaskMachineUI” that will run the update.vbs script every three minutes:

Helminth Script Variant

The script variant of the Helminth Trojan consists of a VBScript and PowerShell script named update.vbs and dns.ps1. We aptly named this variant the script version, as we found another version of this Trojan that we will discuss later in this Appendix. The update.vbs script is responsible for reaching out to its command and control (C2) server using HTTP requests to the following two URLs:

hxxp://go0gIe.com/sysupdate.aspx?req=<random number>%5Cdwn&m=d
hxxp://go0gIe.com/sysupdate.aspx?req=<random number>%5Cbat&m=d

The C2 server will respond to the HTTP requests to the “bat&m=d” URL with a batch script that update.vbs will save to the “dn” folder and execute. The output of the downloaded batch script is saved to a text file in the “up” folder and uploaded to the C2 server via an HTTP POST request to the following URL:

hxxp://go0gIe.com/sysupdate.aspx?req=<random number>%5Cupl&m=u

Palo Alto Networks WildFire observed commands provided by the C2 server for the known Helminth samples. The commands, as seen below, show that the threat actors are attempting to do initial information gathering on the system, including available user accounts, username, computer name, running tasks, services, network services and if remote desktop is enabled.

The update.vbs concludes by running the dns.ps1 PowerShell script. The dns.ps1 script is also responsible for communicating with the C2 server, but it uses DNS queries to send data to the server. The DNS queries sent by this script are queries to subdomains on the same domain as the C2 server, which contains system information or the contents of files from the system. The subdomain of the DNS request that acts as the initial C2 beacon has the following structure:

00000000<base 36 of a random number smaller than 46655>30

The dns.ps1 script checks the response to this DNS query and uses the first octet of the resolving IP address as an identifier for the compromised system. The script then uses this identifier in a follow up DNS request to a subdomain with the following structure:

00<identifier>00000<base36 of a random number smaller than 46655>30

The C2 server will respond to these DNS queries with IP addresses that the script will parse and eventually treat as data to construct a batch script to execute on the system. The script specifically looks for the IP address “33.33.x.x” to mark the beginning of the batch script transfer. Upon receipt of this IP address, the script uses the last two octets of this IP address as a filename for the batch file that it saves to the “tp” folder that was initially created by the macro. Once the batch file name is obtained, the script will continue sending additional DNS requests and use the octets of the resolving IP addresses as characters to write to the batch script. The script continues writing characters to the batch script until it receives the IP address “35.35.35.35” that notifies the script to stop saving data to the file and to run the batch script.

The output of the downloaded batch file is saved to “%PUBLIC%\Libraries\tp\<batch filename>.txt”. The script will then upload the output of this batch file by including the data in a sequence of DNS queries. The exfiltrates the output of the batch script by splitting up the data within the text file into chunks up to 23 bytes and sends the data within a series of DNS queries that have the following structure:

00<identifier><filename of batch file without its extension><base36 of sequence number><base36 of a random number smaller than 46655><up to 23 bytes of data from batch script output>

Both the update.vbs and dns.ps1 both provide a fully functional remote shell to the actors, which allow the actor to carry out any activities on the compromised system they wish.

Helminth Executable Variant

The executable variant of Helminth is installed with a Trojan that we are tracking as the HerHer Trojan. The HerHer Trojan saves several files to the file system upon execution to install the Helminth Trojan to the system.

• %APPDATA%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Certificate Managment.lnk
• %APPDATA%\Roaming\Microsoft\Windows\Start Menu\Programs\Certificate.ico
• %APPDATA%\Roaming\Microsoft Temperary\adbmanager.exe
• %APPDATA%\Roaming\Microsoft Temperary\adbtray.exe
• %APPDATA%\Local\Temp\acro\Users\config.txt
• %PUBLIC%\Libraries\~Windows\wintrust.hlm

The “Certificate Managment.lnk” shortcut uses the “Certificate.ico” file for its icon, as seen in Figure 11.

Figure 11 Icon file used

Additionally, it has a comment of ‘herher’, which is basis of the dropper’s name. Helminth relies on the following shortcut for persistence, as it runs the Trojan each time the system starts using the following command line:

“C:\Users\Rick James\AppData\Roaming\Microsoft Temperary\adbmanager.exe” q 1

The ‘adbmanager.exe’ and ‘adbtray.exe’ files are the actual Helminth Trojan, both of which are the same executable. The reason for two different filenames is currently unknown. The Helminth Trojan requires arguments on the command-line to execute properly (‘q’ in the analyzed sample as seen in the ‘Certificate Managment.lnk’ shortcut), one of which will run the Trojan’s functional code and the other can open a dialog box as a decoy.

The Helminth Trojan begins by creating a mutex named ‘[username]ver4.1’ and writes its embedded configuration as ciphertext to the following file:

%APPDATA%\Local\Temp\acro\Users\config.txt

The Trojan will later decrypt the contents of this file using the RC4 algorithm, using the MD5 hash of ‘f246b23d-c2d6-45f2-b268-dec30d9adaad’ as the key. We decrypted the configuration file dropped by Helminth and found the structure of the configuration file is ‘IsAlive,[sleep interval]\r\n[C2 domain]’. For example, one Helminth sample had the following data within the “config.txt” file:

IsAlive,30
checkgoogle.org

The Helminth executable variant is able to run batch scripts provided by the C2 server, which is very similar to the script version of this Trojan. The executable variant has one additional capability that is not present in the script version, which involves the ability to log keystrokes via a supplemental keylogger module.

Helminth loads its keylogger module of the Trojan by loading the wintrust.hlm file dropped by the HerHer Trojan as a DLL and calling its exported function named ‘Initialize’. The keylogger that creates a window named ‘kk’ to monitor both the clipboard and keystrokes and to save the data in cleartext to the file ‘%TEMP%/acro/Users/[GUID from CoCreateGuid]kk.tmp’. The keylogger saves the keystrokes and the name of the Window visible while the keys were typed to this file in the following structure:

####T####[Window Name]####ET####
[logged keystrokes]

The wintrust.hlm keylogger logs the contents of the clipboard to the same file, but the clipboard contents do not follow a header that specifies the window name like the other logged keystrokes. The clipboard contents are logged to the file in the following format:

<<< Clipboard —> [contents of clipboard]>>>

Helminth Exe C2 Communications

The Helminth executable is able to communicate with its C2 server via HTTP and via DNS queries in very similar ways to the Helminth script variant. In fact, the DNS beacons follow the same structure and sequence as the script variant of Helminth discussed in the previous section. The main difference between the beacons sent from the two variants of Helminth is the data included within the beacon, as the script variant does not send any system information within the beacons, whereas the executable version sends system and malware specific information within both the HTTP and DNS beacons.

Helminth executables include the system and malware information within HTTP beacons in the “Cookie” field of the request. Helminth structures the beacon data as follows:

Function=F1; ID=[MD5 of Computer and Username]; Group=[Hardcoded in Malware]; Name=[Hardcoded in Malware]; Service=0;

The Trojan will encrypt this data using RC4 and the MD5 hash of “f246b23d-c2d6-45f2-b268-dec30d9adaad” as the key and encode the encrypted data using base64.

Figure 12 shows a Helminth HTTP beacon with the Cookie field containing the base64 data.

Figure 12 Helminth HTTP C2 beacon

Helminth sends data within DNS beacons differently than the HTTP beacons and includes additional information as well. The data within the DNS beacons follows the structure:

<path of folder containing keylogger module>
<path of folder containing key logs and batch script output files>
<group name hardcoded in malware>
<name hardcoded in malware>
<computer name>
<user name>
<sleep interval>
<C2 domain>

The Trojan does not encrypt the data sent via DNS beacons, rather it converts the ASCII characters into their hexadecimal values and includes these values in cleartext. The DNS beacons sent from the Helminth executable have the following structure, which is very similar to the script version:

00<identifier>01<sequence number><up to 24 hexadecimal values of the ASCII data>

Figure 13 shows an example of the DNS beacons sent from a Helminth executable.

Figure 13 Helminth DNS C2 beacon

The encoded data within the DNS beacons displayed in Figure 13 decode to the following:

C:\Users\Public\Libraries\~Windows\
C:\Users\Administrator\AppData\Roaming\Microsoft\Internet Explorer\Users\
[redacted company name]
Plato
[Computer Name redacted]
Administrator
30
kernel.ws

Robert Falcone and Bryan Lee

[Palo Alto Networks Research Center]