Myth Stealer Initial Investigation
Hey folks,
I just wanted to share an interesting investigation that started just yesterday, and resulted in some new detection in the ET ruleset, regarding “Myth Stealer”.
I hadn’t spotted this post by trellix about a month ago, having been buried in IoT vulns at the time.
It all started when I was looking at my inoreader RSS feed (that I had talked about previously) for something to do.
I came across this post on the /r/cybersecurity subreddit. The user stated they had visited combatshell.com via a discord link, and linked to a tria.ge sandbox run here, and the ability to download the pcap.
Packet Analysis
My usual thing is to check for HTTP, DNS, and TLS SNI (Server Name Indicator) in a pcap.
If you use the filter dns.flags == 0x0100 in wireshark, this gives you just the standard DNS queries in a PCAP. Almost immediately, I spot the unusual out of the usual microsoft telemetry spam:
combatshell[.]com
followed by queries for
pokettohiro[.]com
Now, just so everyone knows, pokettohiro[.]com is a red herring, and a victim of this scam as well. pokettohiro is NOT malicious! The actors behind this campaign will either create their own somewhat professionally done Indie game website to entice people into downloading a demo, or copy an existing game’s website and switch out the links with payloads containing myth stealer. How do I know this? Well, these actors aren’t doing a great job of hiding their network traffic. Further into the pcap we see queries for api.ipify[.]org, and mythstealer[.]win:
If you switch wireshark filters to tls.handshake.type == 1 (TLS Client Hello), We get a list of TLS Server Name Inidicators present in the pcap, and we can confirm that:
combatshell[.]com
pokettohiro[.]com
api.ipify[.]org
mythstealer[.]win
Are all being served over HTTPS, So no way to easily spot the mythstealer traffic.
Second Sandbox run, this time with TLS Decrypt
Not easily, but also not impossible Thanks to sources and methods (mitmproxy, physical hosts, SSLKeyLogFile, etc.) We have decrypted pcaps. The md5 file hash for the payload I analyzed is:
4a0998be49a361908a5adaf8d0665a41
As indicated by the trellix blog post, the stealer has a unique key HTTP header that starts with myth-, but also, check out the post request body. This is… interesting to say the least:
While the key header is the same as in the trellix blog post, this new version appears to sending data to /myth/api instead of /api/send. Additionally, (just like in the trellix blog) Everything in the HTTP request body is backwards. But those of you who are savvy on hex dumps, file magic, file carving and packet captures usually know that when you see a list of filenames and PK repeatedly in a payload that its a zip file, and you’re looking at the archive contents. In the screen cap above, we see pcinfo.txt, in reverse, as a file in this archive.
How do we fix this so we can file carve?
Practical File Carving
In wireshark, there are options on how to display data in a data stream. The default is usually ASCII. If we switch it to raw, we get the bytes in printable form:
Yes, that’s a lot of gibberish on-screen, but we know that HTTP headers end with \r\n\r\n (or \x0d\x0a\x0d\x0a So we know that every byte past the bytes that terminate the header are bytes that belong to the request body:
So you’ve copied ALL of the data in red past the http header termination. What now? We go to cyberchef:
These two options in a single recipe will:
- Change the bytes that were in “printable” format in wireshark to their “raw” format
- Reverse the entire payload by byte (Note that the default is character, and reversing by character will not work.
Do it the right way, and the output section will show something like:
click save, and give this pile of bytes the .zip file extension and you can open it with whatever tools your OS uses for archive management:
the pcinfo.txt file can be extracted quite easily:
But wait a minute, that’s not all.
I decided to look up combatshell[.]com on virustotal and while I was suspecting that the data was “scrambled” or that they acquired registrant privacy, Here’s the data I found, anyways:
We can pivot on the e-mail address: 9e4e64fd6ed60ee1s@gmail.com This is one of those things that, unfortunately requires a Premium virustotal account or another service that can allow users to search via Registrant data.
I wasn’t expecting anything, but we find that the same e-mail address is associated with another domain that, so far, doesn’t appear to have been detected combatsouls.com.
So that’s all I got for you right now. The original reddit post seems to indicate that this scam starts out with random people contacting discord users, trying to convince them to check out their new game. Its unfortunate to say this, but even someone like me who loves his video games (especially the indie titles), you have to be cautious in this day and age.
Be wary, try submitting payloads to sandbox engines or virustotal before committing to running anything, just to be safe.
Happy Hunting,
-Tony
IOCs:
Domains/TLS SNI:
combatshell[.]com
combatsouls[.]com
api.ipify[.]org
mythstealer[.]win
file hash:
4a0998be49a361908a5adaf8d0665a41
sandbox run:
https://tria.ge/250629-dkj41sfj6x/behavioral1
Decrypted HTTP headers:
POST /myth/api HTTP/1.1
key: myth-e8552bc3-d60a
content-type: application/octet-stream
content-length: 6783
accept: */*
host: mythstealer.win
Other notes:
I’ll be submitting rules for the domains, TLS SNI, and decrypted HTTP data associated with this stealer (both the new stuff I found, and the IOCs from the trellix report – yes, even the expired domains), and update this post when the SID numbers are assigned.