StealC’s Annoyingly Sneaky Presence
First things first—Lexfo Security did some heavy lifting on StealC, a malware family that started making waves in 2023. To get familiar with reverse engineering, you might want to check out Ghidra, a popular open-source tool developed by the NSA, or Binary Ninja, a user-friendly disassembler. You can check out their full analysis in their three-part series here: Part 1, Part 2, and Part 3. If you’ve ever wanted to see how professionals tear down a malware program stage by stage, this was it. They documented their analysis through several stages of a reverse engineering adventure—beginning with unpacking the malware itself and continuing with static analysis and decryption routines. In other words, it’s the cybersecurity equivalent of a reality TV show—except without the drama (well, maybe just a little).
StealC, as we learn, is a classic “Malware-as-a-Service.” Imagine renting out evil—only instead of horror movie ghosts, you’re getting a set of finely crafted programs that can pilfer user credentials, crypto-wallets, instant messages, and emails. It uses HTTP POST requests to communicate with Command and Control (C2) servers, which basically means it’s like a criminal constantly sending postcards to home base.
Who Needs to Read This?
If you’re a reverse engineering nerd, a cybersecurity enthusiast, or someone who just loves a good malware takedown story, keep reading. Lexfo’s insights are sharp, but there’s always room to look at the devilish details with fresh eyes. And yes, we’ll throw in some sarcasm because, let’s face it, unpacking malware can use some fun.
Stage 1: The Basics—Because Nothing Comes Easy
The journey begins with a heavily packed sample (StealC’s Stage 1)—the malware equivalent of that friend who comes to a sleepover with ten layers of pajamas. It uses a packer called “pkr_ce1a.” A packer, for those unaware, is just a fancy piece of software that compresses the code and obscures its contents, making it as readable as hieroglyphics for detection systems.
But fear not, because tools like MIASM (an open-source symbolic execution emulator) help in getting down to business. Analysts used VirtualAlloc (yeah, it’s as fun as it sounds) and tracked memory allocations. You can read more about memory allocation on the Microsoft VirtualAlloc documentation. Remember those childhood games where you follow a trail of clues to find a prize? This is the malware version of that—just replace candy with obfuscated binary data.
Here’s the deal: the packer encrypts and executes its payloads in memory, which is why you need to be a savvy debugger to catch it. Tools like Binary Ninja, Detect It Easy, and Ghidra are your best buddies here. They tell you when entropy values go through the roof—an indication that something is trying a bit too hard to stay hidden.
Stage 2: Now It Gets Interesting
Stage 2 is where StealC moves from a packed binary to a PE loader. The game becomes “find the Command and Control (C2) server. If you’re new to C2s and want to learn more, check out Command and Control Basics.” If that sounds like detective work, well, it is. Analysts detected the loader performing network calls and reaching out to IP addresses (185.172.128[.]90, among others) that belong to StealC’s C2 infrastructure.
And here’s where things get interesting—the sample downloads additional executables like syncUpd.exe from these C2 servers. Spoiler alert: syncUpd.exe was packed using the same methods as Stage 1, and if you ran a Yara rule scan, you’d see those beautiful hits matching the previous packer.
Yara Rules are like trained sniffer dogs, sniffing out the specific patterns of a malware sample. And StealC, clever as it is, couldn’t escape its match (check out Yara Rules if you’re curious). The match was clear: win_stealc_auto. Imagine a dog wagging its tail after finally tracking down a fox.
Stage 3: Static Analysis and All Its Goodness
Lexfo’s final part of the analysis revolved around unpacking the Stage 3 sample using static analysis tools like Binary Ninja and automating decryption of encoded strings. For more on encryption basics, you can refer to Wikipedia’s page on XOR Encryption.
Simple Crypto XOR—Seriously?
One of the functions that StealC leaned heavily on was a good old XOR operation for string decryption. Yeah, if you’re familiar with malware, you’ll know that XOR-ing is just the starting level of the ‘How to Build Malware’ game. XOR has been around since ancient times (well, 1918, if you count Claude Shannon as “ancient”).
In Lexfo’s analysis, they used Python scripts to analyze which functions called simple_crypto_xor the most and used that information to decode the malicious strings. Here’s a snippet of how they did it:
xored_str = None
def xorme(secret_string, key, key_len):
final = ""
for i in range(0, key_len):
final = f"{final}{chr(secret_string[i] ^ key[i])}"
return finalThe above Python snippet can help you in decrypting XOR-ed strings that StealC tried to keep secret. If the malware community’s motto was to “stay packed, stay hidden,” Lexfo just cracked it open like a piñata.
Recovering Command and Control (C2) Servers
StealC doesn’t just sit around on your machine—it has to talk to its boss. And that boss? The C2 server. During analysis, the authors used both sandbox detonations (using CAPE and Inetsim) and static methods to identify the malware’s communication channels.
A few of the C2s mentioned:
- 185.172.128[.]90 – Ping here if you want to say hello to some malware.
- 185.172.128[.]59 – Yeah, same host—different motive.
The malware communicates by sending requests to these C2s and usually tries to download more junk, like the previously mentioned syncUpd.exe. By the way, if you want to test the waters, use curl and route it through Tor:
torify curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.129 Safari/537.36" -O syncUpd.exe.bin hxxp://185[.]172.128.59/syncUpd.exeCaution: The risk is real. Don’t use your actual IP to visit malicious sites. Use a VPN or anything else to hide your tracks. There’s nothing like accidentally alerting a hacker that you’re onto them.
Tools Used: Because Nothing Succeeds Without Gadgets
Lexfo’s analysis was possible because of some seriously cool tools. Here’s what was in the analyst’s kit:
- Binary Ninja: Reverse engineers’ love-child. It lets you automate much of the nitty-gritty with Python APIs.
- MIASM: This tool is basically your malware’s worst nightmare—a symbolic emulator that just doesn’t quit until it understands every byte.
- Cape Sandbox: You want to see how malware behaves without affecting the outside world? This is what you need.
- Yara: Ah, the sniffer. Detect those patterns and never get caught unaware.
Of course, let’s not forget the countless hours of debugging and setting breakpoints. VirtualAlloc, VirtualFree, sub_4043b0—it’s like the malware version of setting traps and making sure your prey steps on them.
FAQs
What is StealC?
StealC is a Malware-as-a-Service used to steal user credentials, crypto-wallets, emails, and browser information. It’s a C-based malware with anti-emulation and anti-debugging techniques.
How does StealC evade detection?
It uses several stages of encryption and packing to hide itself, employs XOR-based decryption for strings, and actively tries to detect if it’s running in a virtual or sandbox environment.
What are Command and Control (C2) servers in StealC?
These are servers that StealC communicates with to transmit stolen information or download additional payloads. Examples of C2 addresses include 185.172.128[.]90 and 185.172.128[.]59.
Can StealC be detected with Yara?
Yes, rules like win_stealc_auto and win_stealc_w0 can be used to match StealC’s characteristics and flag it during analysis.
What tools are needed to analyze StealC?
You will need tools like Binary Ninja, CAPE Sandbox, Yara, and MIASM, along with a disassembler like Ghidra or IDA Pro to fully analyze StealC.
Conclusion: The Art of Keeping Calm While Unpacking Evil
StealC’s multi-stage execution is a nightmare for analysts, but when you break it down layer by layer, it’s just another malware with too much attitude. Between anti-debugging and multiple encryption stages, it did everything possible to stay hidden. But with Lexfo’s comprehensive analysis and our guide here, you’ve got the basics to understand how StealC operates.
Have you faced off against a malware sample that thought it could outsmart you? Drop your thoughts in the comments, or let us know if you’d like us to analyze any other malware. If you want more guides like this, subscribe and keep your reverse engineering toolkit sharp.
