Carbanak Continues To Evolve: Quietly Creeping into Remote Hosts

I recently engaged in an investigation involving two new Carbanak campaigns targeting the hospitality sector. In each campaign a malicious Word or RTF document was sent to specific employees, claiming the sender had trouble with the online ordering system, or was filing a lawsuit because a member of his group got sick after dining at one of the organization's restaurants. This social engineering scam is augmented with a personal phone call from the attacker, encouraging the intended victim to open the email attachment and click inside it. The attacker then calls back 30 minutes later to check if the document was opened and hangs up as soon as the employee says yes.

Phishing continues to be an effective attack vector, and a number of systems at the organization became infected as a result of opening the attachment. This time around, however, there are several twists added to the usual credit-card scraping and screen-shot grabbing malware previously seen in the November 2016 Carbanak campaign published in the Trustwave SpiderLabs blog (https://www.trustwave.com/Resources/SpiderLabs-Blog/New-Carbanak-/-Anunak-Attack-Methodology/).

I want to provide my sincere thanks to Rodel Mendrez,Trustwave SpiderLabs Senior Security Researcher, for all his assistance and knowledge. From malware reversing, to writing custom Python scripts, to historical knowledge of exploits, his help was invaluable to unraveling the many layers of trickery employed by the Carbanak malware writers. Thanks also to Brian Hussey,Trustwave SpiderLabs, VP of Cyber Threat Detection and Response and Mike Wilkinson, Trustwave SpiderLabs IR, North America Managing Consultant, for their review and guidance.

Did You Open The Attachment?

The infected email attachment is a Microsoft Word docx or RTF file. These documents, and their MD5 hashes, have appeared across several campaigns:

Name

MD5 Hash

File Size

2-reservation-1.docx

D5FBFD2D1D71405A755C73E1CAC5DF23

77,238 bytes

Claim_Dave.docx

FBF653B89A0814F515DDBDCF82CC3795

119,256 bytes

Letter 216 micro.docx

FB442B402F73269BA5367142392B40C7

371,888 bytes

4404_inf04.docx

3C12B6A6EBFFFDA75E4707067072C9CF

395,857 bytes

Ord2.rtf

ABAB101E4E25A989D2943C30447DD216

1,075,043 bytes

Let's take a look at what the most recent document, Ord2.rtf, puts into motion when opened. Note that all of the files listed here are contained within the malicious RTF document and extracted when it is opened:

So that is two VBS and one PS1 file created by the infected RTF document. Persistence is established by creating a scheduled task that runs the main malware file every 25 minutes.

In addition to another PS1 file and four more VBS scripts, we also see INI and TXT files being created. What are these for? The answer is coming shortly.

So much malware from one little RTF and a simple socially-engineered click to start everything in motion. This is why continuous security awareness training is essential.

When you look at all the functionality built into those VBS and PS1 files you can see why Carbanak continues to be a significant threat. Even though some of the PS1 and VBS code is the same or very similar to that of previous attacks, there are some new twists in these files, and they are dramatic.

Bring Back the INI Files

This new Carbanak campaign also resurrects the INI file, using it to issue commands to the compromised machine as well as to reflect the status of previous commands. INI files are text files used in earlier versions of Windows that contain software configuration details organized into sections, properties, and values. Here is an "in-use" INI file from the investigation:

The "last_cmd_id=2" entry indicates that the malware has transmitted the victim's system information and a list of currently running processes back to the attacker, and is waiting for a new command to process. This is quite clear from the following code snippet:

This information, along with other items, such as encoded and encrypted IDs based on the hard-drive serial number and the software version of the malware, are bundled into various "parameter=value" strings and sent to the CnC sever.

The parameter names are randomly generated and match the regular expression [a-z]{1,2}[a-z0-9]{1,6} and there are also random data strings generated and transmitted (presumably to confuse anyone decoding them) that correspond to the regular expression [a-z0-9]{1,8}.

Here is information from my own analysis system that is gathered by the malware and transmitted:

And here we see similar information from a different system on its way to the attacker:

Knowing the format of the messages sent to the attacker may assist in developing alerts for your organizations SIEM, firewall, or other security monitoring tools.

Lateral Movement Without Passwords

Unlike previous campaigns, where Mimikatz or some other credential stealer was used, lateral movement between systems is accomplished without user accounts and passwords. Instead, the malware bypasses authentication on the remote system and uses SMB commands (including TreeConnect and Open/Write AndX) to locate a vulnerable host by checking the ability to write data to the C:\Windows\Temp folder on a potential victim system. If the write operation is performed, the attacking system writes a short batch file to the victim and runs it remotely via another SMB command (DCERPC). The batch file creates a log file whose contents are either "x86" or "amd64" depending on the bit-size of the operating system on the victim.

The batch file looks like this:

The attacking system reads the log file and uses its contents to then transfer a 32-bit or 64-bit executable file to the victim's C:\Windows\Temp folder and run it. The executable acts as a stager and enables the transfer of the meterpreter DLL to the victim system. The meterpreter DLL is made operational via reflective DLL injection, which copies the meterpreter DLL into the memory space of a chosen victim process (such as explorer.exe) and runs it as a thread.

The entire sequence of operations looks like this:

The {~random} file names are not really random, but instead a base64 combination of the victim's system volume serial number and MAC address, which are obtained by queries to the system's WMI Service. The IP address 5.149.251.167 is used to enable a reverse_TCP meterpreter shell back to the attacker' system, allowing for complete control over the victim computer. The attacker system at 5.149.251.167 is most likely running a meterpreter listener that transfers an XOR-encrypted meterpreter DLL to the victim and provides the quiet and authentication-free lateral movement between systems the attacker wants.

This WHOIS lookup of 5.149.251.167 indicates that this IP address should raise red flags.

A total of 606 SMB messages back and forth between the attacking and victim systems are needed to process the 9 infection steps previously described, and takes 105 seconds to complete, as the stager EXE is 59 KB. The stager is one of many that have been created to enable victim-CnC communication using metasploit. The following Wireshark screenshot shows a small portion of the SMB messages that transfer the stager to the victim:

Malware Transfer Via DNS TXT Records

A PowerShell script created by the infected email attachment contains a base64-encoded block of text that is decoded, written into memory as a thread, and executed. This uses the same technique as the metasploit 'DNS TXT Record Payload Download and Execution' module, as described below (with slightly modified code):

This code performs DNS queries to the attacker's malware domain, as illustrated here:

A 255-character TXT record is received in response to each query. For example, a query to:

Note that frequency analysis of the symbol distribution in the records may be helpful in generating a rule for detection, as well as also noting if additional systems are performing the same queries. From a detection perspective, it is important to note that the TXT records are specifically requested in the DNS query, as shown here:

This is not typical DNS behavior.

As you refer back to the first TXT record you'll see the majority of the symbols are colored differently. You may also notice there are alphanumeric symbols in this portion of the TXT record that do not appear in the remainder of the record, or in fact, in any of the remaining 1,542 TXT records (as the DNS queries cycle through caa, daa, and so on up to zaa, then rolls over to aba, bba, caa, etc. until all the TXT records have been obtained).

The alphanumeric portion of the first TXT record is alphanumeric shellcode. The advantage of using alphanumeric shellcode is that it flies under the radar of AV and IDS/IPS, even though the ASCII codes associated with the alphanumeric characters represent actual 80x86 opcodes. Here are a few examples:

Here is a portion of the alphanumeric shellcode decoding loop (original alphanumeric shellcode and decoded shellcode):

&nbsp;

The shellcode decodes itself to create more useful and efficient instructions needed to decode the remaining TXT records that contain the payload. The payload is undergoing detailed analysis and additional information will be forthcoming.

Note: a previous Carbanak campaign used this base domain:

aaa.stage.14919005.www1.proslr3.com

Both of these DNS malware domains are registered in Russia. As with many malware delivery domains, they operate for a short period of time and then are shut down as the attackers move to a different domain.

Now, consider this: the number of DNS queries to the three-letter subdomains for the malware analyzed in this new campaign is 1,543. That is a very significant number of 255-character TXT records and over 385 KB of encoded characters. In one test the time to perform the 1,543 queries is 214 seconds, or 7 queries per second.

This is an example of "program behavior" rather than "human behavior." Security analysts would agree that this clearly indicates a human was not sitting at a computer rapidly clicking links for over three minutes straight.

Recognizing this type of behavior is a valuable addition to an organization's malware alerting controls. A continuous stream of DNS queries from the same system to the same TLD exceeding 420 queries per minute or some similar threshold would be a suitable alerting mechanism (not for a busy server perhaps but certainly for a user workstation).

Layers Upon Layers

The Carbanak malware writers have used several methods to hide the functionality of their malware. Consider all of these steps required to fully deliver just one of the malware files in this campaign:

Alphanumeric shellcode contains an initial decoding stub that XOR decrypts a portion of the shellcode into the payload decoder.

The payload decoder uses the remaining TXT record data to create an in-memory DLL file, thus ensuring that this attack does not leave malware traces on the system itself, only in memory.

The operation of the payload decoder is very simple: Each pair of ASCII characters become a single byte of code in the final payload. As shown in the following figure, each ASCII code in a pair has 'A' (0x41) subtracted from them. The resulting difference is always between 0 and F and becomes the high-order or low-order nibble of the final payload byte.

In addition to the base64 encoding, other files are also encoded and obfuscated. For example, the script updater is initially created by decoding a base64 string. But looking into the file shows these two encoded and obfuscated sections:

Take a moment to examine the symbols in the string that represents the encoded VBS statements. Then look at the symbols in the decoding key, and perhaps you'll see where I am headed.

Did you notice anything strange? If you missed it, take a look here:

Only the first 16 symbols in the decoding key are used to decode the VBS statements string. The second group of 16 symbols do not appear anywhere in the VBS statements string. In fact, the only place all those symbols appear is in a second encoded string that is at the end of the encoded and obfuscated VBS file, and this string is not referenced or processed. Decoding the string results in binary mumbo-jumbo and the purpose of this unused string is not known at this time.

If you are a "code talker" and want to give the second string a go, here it is:

The obsPayload1 variable is set equal to the long encoded string representing the actual VBS statements. Leaving the VBS files encoded like this while they reside on disk is an attempt to prevent detection by AV scans looking for suspicious keywords. Note that the last statement in the DeObs1() subroutine should be

WScript.Run DecodedPayload1

but was changed to WScript.Echo to simply view, rather than execute, the code.

Watch The Compromise Unfold

If you have access to CarbonBlack, the chain of events and spawned processes can be traced from the moment the malicious Word document is opened. Here is a timeline of an actual compromise:

So, based on the available event sequence, we can identify IoCs as well as the way to detect and/or prevent actions we do not want taking place.

Organizational Preparedness

There are several steps an organization can take to prevent or limit the severity of a Carbanak attack. All of the following steps apply and can be achieved via internal security engineering or by engaging an MSSP: