Threat Level: green Handler on Duty: Guy Bruneau

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Attackers Exploiting WebLogic Servers via CVE-2020-14882 to install Cobalt Strike

Published: 2020-11-03
Last Updated: 2020-11-04 13:50:55 UTC
by Renato Marinho (Version: 1)
0 comment(s)

Starting late last week, we observed a large number of scans against our WebLogic honeypots to detect if they are vulnerable to CVE-2020-14882. CVE-2020-14882 was patched about two weeks ago as part of Oracle's quarterly critical patch update. In addition to scans simply enumerating vulnerable servers, we saw a small number of scans starting on Friday (Oct. 30th) attempting to install crypto-mining tools [1].

On Friday, Oracle amended its patch for CVE-2020-14882 [2]. A new variation of the vulnerability (CVE-2020-14750) can be used to exploit WebLogic servers with a trivial modification of the exploit code.

Last Saturday we started seeing a campaign using a chain of Powershell obfuscated scripts to download a Cobalt Strike payload. According to Cisco Talos Q4 2020 CTIR report, 66% of all ransomware attacks this quarter involved the use of Cobalt Strike [3]. Thus, as expected, there is a high probability ransomware gang included CVE-2020-14882 exploit in their arsenal. 

The attack, as seen in Figure 1, exploits the vulnerability to execute a PowerShell payload base64-encoded. 

Figure 1 - Payload delivery

Decoding the base64 content, we can find the following code. As seen, there is another encoding layer using base64 and gzip compression. I usually make some adjustments to the original malicious script to make it save the decoded content to a file. So, replacing “IEX” by “$content =” and appending the script with “$content |out-file -filepath decoded_script.ps1” is enough to accomplish this result for this case.

Figure 2 - First stage decoding

Part of the resulting code is shown in Figure 3. Notice that there is another protected code. There is a loop decrypting each byte of the code using an XOR function with the byte 0x35. 

Figure 3 - Second stage decoding

The result of this operation is a shellcode to download and execute a Cobalt Strike payload hosted at http://185[.]205.210.179:4321/Z8qZ.

Figure 4 - Cobalt Strike payload download

Submitting the binary to VirusTotal, we had the following result:

]

Figure 5 - Cobalt Strike payload submitted to Virus Total

Running the malicious scripts in a controlled environment, it was possible to see connections established from time to time with the C2 at http://185[.]205.210.179/en_US/all.js.

References
[1] https://isc.sans.edu/forums/diary/PATCH+NOW+CVE202014882+Weblogic+Actively+Exploited+Against+Honeypots/26734/

[2] https://www.oracle.com/security-alerts/alert-cve-2020-14750.html#AppendixFMWl
[3] https://blog.talosintelligence.com/2020/09/CTIR-quarterly-trends-Q4-2020.html


IOCs:

Network:

45[.]134.26.174
http://185[.]205.210.179:4321/Z8qZ
http://185[.]205.210.179/en_US/all.js

Files:

Z8qZ
8ca0251bc340fc207e6f832eb6165b8d (MD5)
8f4654952833b7d7b7db02ca7cb6c2f6cb9c3c545dc51124b0f18588b3c4e1c0 (SHA256)

The malicious requests are available at https://isc.sans.edu/WebLogicPS.log.zip

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Keywords:
0 comment(s)

Emotet -> Qakbot -> more Emotet

Published: 2020-11-03
Last Updated: 2020-11-03 00:00:46 UTC
by Brad Duncan (Version: 1)
0 comment(s)

Introduction

On Friday 2020-10-30, I generated an Emotet infection in my lab and saw Qakbot as the follow-up malware.  I let the activity run for a while, then another Emotet infection appeared on the same host after Qakbot started.

This appears to be an Emotet to Qakbot to another Emotet infection, with all three infections persistent on my infected lab host.


Shown above:  Flow chart for the infection chain I saw on Tuesday 2020-10-27.

Today's diary reviews this Emotet to Qakbot to more Emotet infection from last week.

The malspam

The malicious spam (malspam) was a Halloween-themed message sent on Thursday 2020-10-29 to one of my honeypot email accounts.  It had a Word doc attached to the message.  The Word doc has a malicious macro designed to infect a vulnerable Windows host with Emotet.


Shown above:  Halloween-themed malspam with malicious Word doc attachment pushing Emotet.

The attached Word document uses a template that's typical for recent Word docs pushing Emotet.


Shown above:  Word doc with macro for Emotet.

Infection traffic

The traffic didn't look much different than what I've seen before for Emotet to Qakbot infections, there just seemed to be more Emotet traffic than normal after the Qakbot traffic kicked in.  That didn't seem too unusual, though.


Shown above:  Start of the infection traffic filtered in Wireshark.


Shown above:  Traffic from the end of my pcap filtered in Wireshark.

In the above image, Emotet traffic is more frequent than I usually see.  Usually, Emotet will call back every 15 minutes, unless the host has been turned into a spambot.  Emotet spambot activity includes more frequent C2 callback traffic, but we would also see indicators of spambot traffic, and that's not the case here.

Forensics on an infected Windows host

When I checked the registry, I saw two entries for Emotet.  When Emotet updates itself, it will replace an already existing binary.  I'd never personally seen two separate Emotet binaries active and set up in the registry like this.


Shown above:  Windows registry updates from my infected lab host.



Shown above:  Persistent Emotet EXE from 1st Emotet infection and Qakbot follow-up malware.


Shown above:  Qakbot persistent on my infected lab host.


Shown above:  Another Emotet infection persistent approximately 17 minutes after the initial Qakbot EXE appeared.

Of note, Emotet backdates the persistent EXE files 8 days before the current date.  So the modified date on both of these Emotet EXE files is 2020-10-22, but the timestamp is the correct time for 2020-10-30.  Based on the timestamps for these binaries, it appears that Qakbot caused the second Emotet infection.

Indicators of Compromise (IOCs)

SHA256 hash: ed51269c3602786ff6ddef3a808d8178d26e4e5960f4ac7af765e4bd642128dd

  • File size: 233,466 bytes
  • File name: Party invitation.doc
  • File description: Word doc with macro for Emotet

SHA256 hash: a4c780c8b6ecb7d73f7498a4a46286cf2a2ecc6f378e2ba89deea06591c3cc04

  • File size: 364,544 bytes
  • File location: hxps://imperfectdream[.]com/wp-content/xb2csjPW6/
  • File location: C:\Users\[username]\Nscs8ry\S8t4g_l\Epl6_wa2m.exe
  • File location: C:\Users\[username]\AppData\Local\msexcl40\msimg32.exe
  • File description: Emotet EXE retrieved by Word macro

SHA256 hash: dcda70b5cc63629dd2760dbc76ffda0bedefd0ee92af4d4e3740acc7dd2eaff2

  • File size: 261,080 bytes
  • File location: C:\Users\[username]\AppData\Local\msexcl40\cryptnet7e4.exe
  • File location: C:\Users\[username]\AppData\Roaming\Microsoft\Gzzndshwwc\rrcbu.exe
  • File description: Qakbot EXE retrieved by the Emotet-infected host

SHA256 hash: 4180c4c11e631a7545d40dadb74280c00f53271a75b113c387bb87adaf2cecf7

  • File size: 318,992 bytes
  • File location: C:\Users\[username]\AppData\Roaming\Microsoft\Gzzndshwwc\rrcbu.exe
  • File description: Updated Qakbot EXE persistent on the infected Windows host

SHA256 hash: 4d1eeb527a61391ddcf30b0f9d6d9f96369e0179c1e1a65da5da33a196a991d4

  • File size: 192,512 bytes
  • File location: C:\Users\[username]\AppData\Local\AccountsControlInternal\mfc40.exe
  • File description: Another Emotet EXE persistent on the infected Windows host

HTTPS traffic caused by Word macro to retrieve initial Emotet EXE:

  • port 443 - enjoymylifecheryl[.]com
  • port 443 - homewatchamelia[.]com
  • port 443 - seramporemunicipality[.]org
  • port 443 - imperfectdream[.]com

HTTP traffic caused by the two Emotet infections:

  • 91.121.200[.]35 port 8080 - 91.121.200[.]35:8080
  • 45.230.228[.]26 port 443 - 45.230.228[.]26:443
  • 172.91.208[.]86 port 80 - 172.91.208[.]86
  • 50.91.114[.]38 port 80 - 50.91.114[.]38
  • 121.124.124[.]40 port 7080 - 121.124.124[.]40:7080
  • 167.99.105[.]11 port 8080 - 167.99.105[.]11:8080
  • 159.203.16[.]11 port 8080 - 159.203.16[.]11:8080
  • 188.226.165[.]170 port 8080 - 188.226.165[.]170:8080
  • 75.127.14[.]170 port 8080 - 75.127.14[.]170:8080

Traffic caused by Qakbot:

  • 47.44.217[.]98 port 443 - HTTPS traffic
  • 89.105.198[.]119 port 80 - a.strandsglobal[.]com - attempted TCP connections
  • port 443 - cdn.speedof[.]me - HTTPS traffic

Caused by Qakbot and Emotet:

  • various IP addresses - various ports - attempted TCP connections

Final words

In order to become infected, a victim must open the Word document and enable macros.  In most cases, people would see a warning against enabling macros.  Just opening the Word document by itself should not kick off the infection chain, unless the computer was set up to have macros automatically enabled.

Although Emotet pushes other families of malware like Qakbot, this is the first time I've seen indications that Qakbot has pushed Emotet.

A zip archive containing a pcap from today's infection is available here.  The Word doc and EXE files from the IOCs have been submitted to MalwareBazaar Database.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

Keywords: Emotet Qakbot
0 comment(s)
Diary Archives