Threat
TA551
TA551, also known as Shathak, is a threat group that uses large-scale phishing campaigns to deliver additional malware payloads. IcedID and Valak were the predominant payloads we observed with TA551 phishing campaigns in 2020.
Pairs with this song Threat Sounds
Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2021.
Analysis
TA551 was the most prevalent threat Red Canary encountered in 2020 by a wide margin. Its pervasiveness was revealed not only in the volume of detections, but in the number of organizations affected across multiple industries and company sizes. The preeminence of TA551 is due in part to our depth of detection coverage for it: throughout 2020, 55 distinct detection analytics triggered on activity that we’ve associated with TA551.
TA551 also took the top spot due to our ability to detect it in the earliest stages of initial access through patterns in malicious attachments. Approximately two-thirds of TA551 detections we observed didn’t progress beyond opening the malicious attachment. To understand how an organization can be part of the two-thirds that didn’t get infected with the next stage of malware, let’s take a look at the progression of a TA551 attack.
Initial access
TA551 gains initial access via macro-laden Microsoft Word documents delivered within a password-protected ZIP archive attached to a phishing email. Wrapping malicious attachments within password-protected archives enables these messages to bypass many mail protection filters by preventing direct analysis of the malicious files. This technique has become more common in recent years, as it increases the likelihood that the phishing message will make it to a user’s inbox. While TA551 varies the filenames for these ZIP archives, including targeted names tailored to the recipient’s organization, in many cases the name was either request.zip or info.zip.
The drop
After opening the archive using a password provided within the email body, the recipient is presented with a Word document containing malicious macros. This is the dropper, designed to download additional malware from an adversary-controlled site. This is a crucial point for organizations with a defense-in-depth strategy; many of our TA551 detections progressed no further than the opening of this malicious document. Why? Because organizations that have implemented a restrictive macro policy disrupt this attack by preventing the execution of malicious code. Such a policy is the primary distinction between the two-thirds of detections that stopped here and the one-third that progressed to the more impactful stages of the attack.
The macro factor
For a variety of reasons, many organizations and users do allow macros to run. In these cases, the macro will result in a network connection to attempt to download the next stage of the malware. Herein lies another example of a defense-in-depth strategy that may disrupt the attack: a web proxy that inspects network traffic may block access to the domain hosting the malicious payload. In some cases, we observed a network connection and creation of an empty file as a result of the attempted download, but because the malicious content was prevented from being downloaded, the attack chain ended there.
DLL installation
If a macro policy doesn’t prevent the code from running and a web proxy doesn’t prevent the next payload from being downloaded, a new malware family will likely execute. TA551 typically transitions from the initial access phase to malware execution via a DLL installer. There have been several variations in how the DLL installer payload was downloaded (see T1105: Ingress Tool Transfer). In some cases, Microsoft Word downloaded the file directly. Other cases leveraged renamed system utilities certutil.exe or mshta.exe to further distance the payload from the dropper. The downloaded DLL file typically masqueraded as well, using a variety of different non-DLL extensions to attempt to blend in—we’ve seen .dat, .jpg, .pdf, .txt, and even .theme file extensions.
Despite these attempts to masquerade (and sometimes because of them), our detection analytics repeatedly triggered when the payload was executed. For most of 2020, this execution was done via regsvr32.exe; however, near the end of the year this was replaced with the use of rundll32.exe. While far from the only threat to use these T1218: Signed Binary Proxy Execution sub-techniques, it is no coincidence that T1218 was the second-most prevalent technique we observed in 2020.
Payload
Once the DLL installer runs, the next stage of malware begins. TA551 has delivered various payloads over the years:
- In 2019 and early 2020, Ursnif and Zloader were common payloads
- In mid-2020, TA551 favored delivering Valak as a first-stage and IcedId as a second-stage payload for a few months
- By mid-July 2020, TA551 stopped using Valak and exclusively delivered IcedID (our fourth most prevalent threat) as its first-stage payload through the end of the year
- In January 2021, after a brief holiday hiatus, TA551 campaigns returned with a new notable payload: Qbot (our third most prevalent threat)
Our understanding of this threat is still evolving, as is the relationship between TA551’s initial access and the post-exploitation goals of the later-stage malware. For another perspective on TA551, check out this post from Unit 42 and follow Brad Duncan on Twitter, who has helped us better understand this threat.
Detection opportunities
Detection opportunity 1
Winword spawning regsvr32.exe
ATT&CK technique(s): T1218.010 Signed Binary Proxy Execution: Regsvr32
ATT&CK tactic(s): Defense Evasion, Initial Access
Details: TA551 transitions from initial access to execution via a defense evasion tactic leveraging the Microsoft-signed binary regsvr32.exe. While the use of a signed binary may try to blend in with typical running processes, the unusual parent-child relationship between winword.exe and regsvr32.exe provides a detection opportunity from an endpoint perspective. It is extremely unusual to see Word executing regsvr32.exe; this is almost always indicative of a malicious macro. In the example below, 84925290.dat is actually a DLL file masquerading as a data (DAT) file. More on that in Detection opportunity 3 below.
Detection opportunity 2
Renamed Windows system binary mshta.exe spawned from WMI and making external network connections
ATT&CK technique(s): T1218.005 Signed Binary Proxy Execution: Mshta, T1036.003 Masquerading: Rename System Utilities
ATT&CK tactic(s): Defense Evasion, Execution
Details: TA551 changed its macro execution during 2020, evading the first detection opportunity by leveraging Windows Management Instrumentation (WMI) to break the parent-child process lineage from winword.exe. Instead of downloading the installer DLL directly via the macro, TA551 leveraged a Microsoft HTML Application (HTA) file to retrieve the malicious payload. Not only that, the adversaries took the extra step to rename mshta.exe in an attempt to masquerade this activity.
Despite these efforts at evasion, this activity actually represents three detection opportunities in one! Evaluating process hashes and/or internal binary metadata is a must when masquerading is in play. When a legitimate file has been renamed, identifying a mismatch between the expected filename and the observed filename often leads to high-fidelity detection. In this case, once we’ve unmasked mshta.exe, two more detection opportunities arise from an understanding of typical behavior for this binary. The relationship of wmiprvse.exe as the parent process to mshta.exe is also highly unusual, and a high-fidelity detection opportunity. Similarly, an external network connection from mshta.exe is unusual behavior that may draw attention to this process execution.
For those of you detecting at home, note that none of this would have been possible if our detection coverage relied solely on the filename of mshta.exe to be accurate.
Detection opportunity 3
Regsvr32 attempting to register a file without a .dll extension
ATT&CK technique(s): T1218.010 Signed Binary Proxy Execution: Regsvr32, T1036.003 Masquerading
ATT&CK tactic(s): Defense Evasion
Details: While the first two detection opportunities focused on how TA551 delivered the malicious installer DLL, our third detection opportunity focuses on how that payload is executed. Continuing with the masquerading theme, TA551 prefers to disguise its malicious code as a more benign file type such as a JPG or PDF. While this might foil a defender looking for executable file extensions to analyze, this masquerading trick again results in a detection opportunity with endpoint monitoring due to abnormal process behavior. It is highly unusual for regsvr32, a tool designed to register and unregister object linking and embedding controls on Windows systems, to register files with these extensions. While there are some legitimate exceptions you may need to tune out in your environment, regsvr32 typically acts upon files with a .dll extension.
