Malware Traffic Analysis Challenge: Mondogreek

9 min readApr 4, 2020

--

https://dribbble.com/shots/2541987-Binary-File

Introduction

So welcome to my first MTA (Malware Traffic Analysis) challenge, I’ve went with the most recent one, Mondogreek. In typical MTA fashion, you receive a zip folder with a pcap in, some alerts to review and a brief of what you need to do i.e. write an incident report or answer questions.

This one will be an incident report, I like this style so I can steer the investigation around my own hypotheses that I form from my findings.

TCPReplay

TCPReplay is an excellent tool, I use SecurityOnion with a sniffing interface, this means I can use tcpreplay to ‘replay’ the pcap I recieve against the interface and generate the alerts again so I can work with them in other tools such as ELK/Squert.

Now I’ve replayed the traffic, I’ll open Wireshark and identify my surroundings…

Network identification

Wireshark searches used:

http.request and !(ssdp) — Find out user agents and identify OS version
nbns — Find hosts through Netbios Name Service Registration packets
ldap — LDAP Traffic to identify DC and Domain

LAN Segment: 10.3.11.0–10.3.11.255

Domain: mondogreek.com

DC: MONDOGREEK (10.3.11.3)

Hosts & Operating Systems

LAPTOP-SQSA420 — Windows 10 (10.3.11.119)
LAPTOP-7XMV2SN — Windows 10 (10.3.11.194)
LAPTOP-I9ZPI04 — Windows 10 (10.3.11.218)
MONDOGREEK — No HTTP Traffic to identify OS from User Agent (10.3.11.3) — Potential DC?

Alerts with Squert and Sguill

At this point, I’ve got my hosts figured out, I made a few off-the-screen side notes of things I noticed in Wireshark during identifying hosts and I’m now ready to dig for suspicious activity to find malicious activity.

I’m now going to use Squert and Sguill to look at my alerts…

The above screenshots show our alerts and traffic flow. I can see we have an alert for Trickbot which is good news, we know what we’re working with now.

The sankey diagram is a great visualisation too; we can see that 10.3.11.194 which is LAPTOP-7XMV2SN, is the only machine in our network talking to external addresses, so I can safely assume we know our compromised device.

Compromised device: LAPTOP-7XMV2SN (10.3.11.194)

Let’s check the external IP addresses in some threat intelligence platforms…

IP Addresses marked as low priority by Squert

Comment from Community: This IOC was found in a paste: https://pastebin.com/5C3EYdwS with the title “Trickbot c2's”

Comment from Community: This IOC was found in a feed: hxxps://blacklist.cyberthreatcoalition.org/vetted/ip.txt with the title “# COVID19 Cyber Threat Coalition blacklist”

IP Addresses marked as high priority by Squert

Noted marked as phishing, could there be a maldoc hiding in the traffic?

All in all, quite a noisy infection as far as threat intel goes!

Using ELK Stack to drilldown

ELK in SecurityOnion is a life saver… our Bro logs are fed in and we can slice and dice these to our hearts content as incident responder.

Note, the times in the below messages are from the SecurityOnion VM.

17:51:28 — GET request for YAS20.exe from bolton-tech[.]com

17:51:39 — POST to C2 with /yas20/DeviceInformation in URI

Wiresharking for YAS20.exe

I had a quicker than usual skim in ELK, though I’m happy that YAS20.exe is our Trickbot malware. My ‘Wireshark-Fu’ is a bit weak, so apologies for the yellow syntax warning; we can see the first odd request was the GET at 21:24:36 to bolton-tech[.]com:

Following this, we had a lot of normal ‘licensing[.]mp[.]microsoft[.]com’ network chatter over 443 then two GET requests directly to 64[.]44[.]133[.]131 which were:

GET /images/imgpaper.png HTTP/1.1
GET /images/cursor.png HTTP/1.1
User Agent: WinHTTP loader /1.0\r\n

When we follow the stream for ‘imgpaper.png’, we actually find that the response shows a header for a portable executable, MZ along with the magic sentence “This program cannot be run in DOS mode.”

PE delivered by GET request for a PNG file.

Following the TCP stream for ‘cursor.png’ shows a different executable, we know this as the content length is 542144 and the exe delivered by ‘imgpaper.png’ is 582656.

Second PE delivered by GET request for a PNG file.

We will extract these soon.

Post infection traffic — HTTPS/SSL/TLS and Certs

(ip.src == 10.3.11.194) and (http.request or ssl.handshake.type == 1 or tcp.flags eq 0x0002) and !(ssdp)

Soon after the infection of the machine, we then see connection attempts to 185[.]141[.]27[.]238 over 443 followed by a successful connection to 45[.]148[.]120[.]153

There is then an IP address check using checkip[.]amazonaws[.]com this alone isn’t an indicator however a good method for malware to grab machine information.

We then see some traffic to port 447 and 449:

I went through looking for all external IP addresses that have a “Client Hello”, so now we know we have established connections to:

45[.]148[.]120[.]153 — This was alerted for being a C2.
190[.]214[.]13[.]2 — Another reported for being a C2.
51[.]254[.]164[.]244 — This alerted from Abuse.CH’s SSL Certificate Blacklist.
185[.]14[.]31[.]98 — This alerted from Abuse.CH’s SSL Certificate Blacklist.

I then ran the following search and found three certs for the HTTPS/TLS/SSL traffic:

(ip.dst == 10.3.11.194) and (ssl.handshake.type == 11) and (ip.src == 45[.]148[.]120[.]153) or (ip.src == 190[.]214[.]13[.]2) or (ip.src == 51[.]254[.]164[.]244) or (ip.src == 185[.]14[.]31[.]98)

Cert 1

id-at-countryName=GB
id-at-stateorProvinceName=London
id-at-LocalityName=London
id-at-organizationName=GlobalSecurity
id-at-organizationalUnitName =IT Department
id-at-commonName=example.com

Cert 2

id-at-countryName=AU
id-at-stateorProvinceName=Some-State
id-at-organizationName=Internet Widgits Pty Ltd

Cert 3

id-at-countryName=GB
id-at-stateorProvinceName=Greater Manchester
id-at-LocalityName=Salford
id-at-organizationName=Comodo CA Limited
id-at-commonName=Comoda RSA Certification Authority

C2 callout and data exfiltration

Once those PE’s are pulled down, we then see a POST request to 203[.]176[.]135[.]102 which sends the compromised devices details inside the URI over port 8082.

I’m not sure why we see another GET for the same PE that’s already been sent, we can also see two POST’s which look the same to me…

First POST request

Upon following the stream on the POST request, I noticed an OpenSSH Private Key, this was starting to look like a credential grabber function. So I done some Google-Fu and found a Threatpost report on Trickbots evolution to look for SSH keys.

Second POST request

The second POST included some creds for browsers

Third POST request

The third POST got interesting, we see a list of the running processes on the machine, system info, ipconfig from command line, net config, net view of the domain and domain trusts and finally local machine data identifying the domain controller. See below:

The fourth and final POST

In this one, we see the OpenSSH private key exfiltration attempt, respective of the first POST request which was looking for OpenVPN…

Unit42/ThreatPost article

Unit 42 also went on to say they found that regardless of if the victim machine has OpenVPN or OpenSSH installed, Trickbot will still make the POST requests. So I can safely now say, that is why we have two POST’s, one for each product.

Extracting the Portable Executables

On Wireshark, I went to File > Export Objects > HTTP and then exported my 3 portable executables by saving them one by one.

On VMRay analyser, YAS20.exe is tagged as Emotet, which makes sense as Emotet has been known to drop Trickbot; VirusTotal 59/73 detection rate with most marking this as a ‘dropper’ which further increases my confidence in the infection chain.

When submitting our PNG’s, these are both categorised as Trickbot with a high infection rate:

I could, if I wanted to, go further and extract the raw binaries from the PNG’s and also reverse both Emotet and Trickbot, though I’ll leave that for a reverse engineering series! :)

Domain Controller Check

So I did remember the DC in the end, I quickly checked for Trickbot activity on the domain controller however we only see the ports 123, 137 and then 49174 upwards. I was looking for 80, 443, 447, 449.

IOC’s

Malware name: Trickbot

How many signatures: 17

URL’s:

GET bolton-tech[.]com /YAS20.exe
GET 64[.]44[.]133[.]131/images/imgpaper.png
GET 64[.]44[.]133[.]131 /images/cursor.png

C2 IP Addresses:

185[.]14[.]31[.]98 — ET TROJAN ABUSE.CH SSL Blacklist Malicious SSL Certificate Detected (Dridex/Trickbot CnC)
51[.]254[.]164[.]244 — ET TROJAN ABUSE.CH SSL Blacklist Malicious SSL Certificate Detected (Dridex/Trickbot CnC)
190[.]214[.]13[.]2 — ET CNC Feodo Tracker Reported CnC Server TCP Group 12. Also reported on VT as a C2
203[.]176[.]135[.]102 — ET CNC Feodo Tracker Reported CnC Server TCP Group 16
45[.]148[.]120[.]153 — ET CNC Feodo Tracker Reported CnC Server TCP Group 18
51[.]254[.]164[.]244 — ET CNC Feodo Tracker Reported CnC Server TCP Group 19
185[.]141[.]27[.]238 — ET CNC Feodo Tracker Reported CnC Server TCP Group 8

SHA-256 of post-infection files:

Emotet dropper— YAS20.exe — 02db3c6b9aff73bf8a11c41107c836b6c800c919c5d3d1304f336aee03f79f4c
Trickbot — 8aa9c596dd3eb7560bc7416ba181e858f1174fcbcb5432050f3f9a663ed1ffa2
Trickbot — 68798ccf8e2a5f9682a4e011bec288ad9b3f900244f82c6ae5e8ca538725f92e

Conclusion

So I learnt a fair bit!

We found that our machine was infected with an Emotet dropper, which in turn dropped Trickbot that scraped the machine to death for credentials and posted them to the C2 over port 8082.

It looks like the user downloaded yas20.exe then was infected, perhaps phishing?

Things I would change: