Did you say, PCAP Inception?

Hrm…

Have you ever thought this packet capture was suspect even though standard tools/processes said it was ok? This post will detail some interesting triage steps to find malicious artefacts that automated tools sometimes miss and create a Suricata rule to detect said artefacts in future!
So the first thing I noticed is that there were no HTTP or HTTP/2 calls in the pcap, even though I was told it could have exfiltrated data.

Upon looking at the pcap, a call to api[.]ip[.]sb was identified. This is a IP geolocation service that didn’t respond, but Cloudflare did with a CNAME.

For unknown reasons, this service is currently down, but we know the attacker tried to use an IP location service behind Cloudflare.

Suspicious PCAP

So to ensure the data from the wire was correct, I completed a few dig commands and traced what I was seeing.

dig api.ib.sb
flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
api.ib.sb. IN A
dig api.ip.sb cname +answer +trace
Received 530 bytes from 204.61.216.31#53(pch.nic.sb)
api.ip.sb. 600 IN CNAME api.ip.sb.cdn.cloudflare.net.
curl cli.fyi/api.ip.sb.cdn.cloudflare.net
“dns”: [
“api.ip.sb.cdn.cloudflare.net. 300 IN A 172.67.75.172”,
“api.ip.sb.cdn.cloudflare.net. 300 IN A 104.26.13.31”,
“api.ip.sb.cdn.cloudflare.net. 300 IN A 104.26.12.31”,

I confirmed that the resolution to the IP Geolocator was down and is hosted by Cloudflare, nothing more to see on here… Except maybe we could write a Suricata rule for detection against this API, but out of scope for this post.

Interesting https://github.com/omriher/CapTipper

After that, I ran Captipper to ensure no HTTP streams have been missed, and I was correct.

python2 CapTipper.py /1ac9dcaebd7d.pcap

So I continued using the trusted Wireshark, removed all LAN-based protocols, enabled protocol statistics, and interestingly found TCP data taking up 95% of the volume, which is weird because it’s not SSL or encrypted. Unusual!

Data tells me something interesting

(((((!(llmnr)) && !(nbns)) && !(browser)) && !(ssdp)) && !(arp)) && !(stp)

Double-checking my work, I leveraged Brim against the capture and confirmed that the TCP steam includes nearly 5Mb of data.

Brim says I might have something interesting https://www.brimsecurity.com/

Ok, so the normal process would enable Zeek to extract files from the pcap, but in this case, no files were extracted, which is uncommon but not unusual.

I still had a suspicion that something funky was going on.

Nope, dammit https://zeek.org/

/usr/local/zeek/bin/zeek -r 1ac9dcaebd7d.pcap

Let us test it with BruteShark; BruteShark extracted the network map and approx. Seventeen files were all garbage, so I cried a little, but that’s ok.

Wireshark will come to the rescue soon.

BruteShark, also found no files of worth! https://github.com/odedshimon/BruteShark

/BruteSharkCli -i /1ac9dcaebd7d.pcap -m Credentials,NetworkMap,FileExtracting,DNS -o Export/

Before getting to Wireshark, I tested the capture against my script “pcapparse”, and Suricata generated no alerts. This confirmed that something phishy is going on (see what I did there!).

No malicious calls found with default ET rules

bash pcapparse.sh 1ac9dcaebd7d.pcap

A strings check against the PCAP identified some unusual data within the output. For example, as you can see in the image below, user data and a potential “wsman/SOAP/Microsoft-HTTPAPI/2.0” endpoint receiving the data.

Definitely some strings in there!

strings /1ac9dcaebd7d.pcap

So back into Wireshark and a quick search for the TEMP/Malware strings!

For reference, you could have followed the TCP stream at the start and manually scrolled through the data and identified a few strings manually; In this case, scrolling through a 5Mb stream tested my patience!

Wireshark! https://www.wireshark.org/

The below image shows the strings “PNG” and “IHDR”, which are the calling cards for PNG file headers and PNG end statements. At this point, I hypothesised that this capture contained stolen computer information and possible screenshots of the desktop of the infected machine.

PNG files….

To double-check, I leveraged XXD with the hex values of the PNG header and footers and discovered four PNG images within the stream.

Ok, so PNG files are in there… https://linux.die.net/man/1/xxd

xxd -p 1ac9dcaebd7d.pcap |grep “504e47”
xxd -p 1ac9dcaebd7d.pcap |grep “49454e44”

At this point, I created a Suricata detection rule based on the compromised information the malware was sending.

Flow detection rule for this sample https://github.com/OISF/suricata

alert tcp any any -> any any (msg:”CUST TROJAN Hypnoz? CnC? Checkin”; content:”|4C 6F 67 69 6E 73|”; distance:0; content:”|54 65 6d 70 5c 48 79 70 6e 6f 7a|”; distance:0; classtype:trojan-activity; sid:1000069; rev:1; metadata:affected_product Windows_10, attack_target Client_Endpoint, created_at 2021_08_28, deployment Perimeter, former_category MALWARE, malware_family Hypnoz?, signature_severity Major, updated_at 2021_08_28;)

Rule works and looks good!

TCPFLOW + FOREMOST has to give me what I need, right? Running these tools against the capture identified four PNG files, YAS! Then I attempted to open said files in ImageMagick, but the files were slightly corrupted dam!

Promising

tcpflow
tcpflow -r 1ac9dcaebd7d.pcap -o tcpflow/
cd tcpflow/ && cat ./* > ./dump
foremost -i ./dump -o ./foremost
ls -R foremost/

The audit log is telling me is working https://github.com/simsong/tcpflow

cat tcpflow/foremost/audit.txt

I double-checked the audit log, and the files look ok, but we still can’t open them.

Let’s be fancy and use some PowerShell! lol

Windows Desktop Images! Thanks https://github.com/jantari

C:\poshpics-master> powershell.exe -noprofile -executionpolicy bypass -file .\draw.ps1 D:\foremost\png\00000022.png

Yes! The files extracted are Windows 7 Desktop images.

FYI, I’m not going over the identification/extraction of the SOAP credential data in this post as it’s out of scope.

After all that pcapin, I wanted to look at the C2 to which the victim was sending data.

Ukraine you say? https://apackets.com/

The IP address looks to be within Ukraine; what a surprise.

Check Shodan if you would like!

Checking the server looks to be a Windows 10 machine, running to primary services.

Yes YeS YES

There used to be a tool called “eyewitness” that can screenshot RDP, but python3 isn’t supported.

I patched together the below bash script that does the same thing, just for RDP! (code is at the end of this post)

bash rdpshot.sh BADIPMMHMM

Thanks for reading, and if you have any questions or “positive feedback”, feel free to reach out, and as always…..

Yes, I said it.