Don’t Get Caught! How Malware Authors Are Tracked Down

Some people believe in house spirits and poltergeists, others in Bigfoot, and some think that a malware developer can guarantee their own anonymity just by packing their binary or obfuscating their code. There are even those who are convinced that law enforcement will never be interested in their activities as long as their programs don’t cause direct financial harm, aren’t distributed in Russia, or no one files a stack of police reports. It’s hard to say where this confidence comes from, but I suspect it’s because these “virus makers” were hit on the head with a school backpack a few too many times in their youth.

The facts, however, tell a different story. Unmasking malware authors has become so routine that such incidents barely surprise anyone anymore. “Oh, another coder got caught? Big deal.” Some even brag about their supposed invulnerability: “Here I am, let them try to catch me. Who would bother?” Well, someone will, and they definitely care.

Why Would Anyone Care?

First off, both major Russian antivirus companies work closely with law enforcement, and they don’t hide it. They have to, since they regularly need to get licenses and certifications from government agencies for developing information security tools, working with cryptography, protecting personal data, and so on. This means these companies are frequently audited and have close contact with officials.

They also have licenses to conduct technical forensics and regularly use them, including for government interests. There are persistent rumors that many cybersecurity firms are required to send regular reports on the current virus and cybercrime landscape to the authorities. If they can include details about a specific malware author in those reports, why wouldn’t they? The answer is obvious.

But there’s good news, username. If you wake up one morning to find your name in antivirus company news feeds, it means one of two things: either you’re already sitting in a cell awaiting trial, or law enforcement hasn’t paid you the attention you “deserve” yet.

There’s such a thing as an ongoing investigation, and details can’t be disclosed until charges are filed or a suspect appears in court. So, if you see yourself in the news, don’t celebrate—it means you’re already on the radar, and your activities have been reported to the right people. Sooner or later, that lack of interest from law enforcement could turn into very focused attention. Circumstances can change in the strangest ways.

It’s Your Own Fault: How Malware Authors Expose Themselves

In every widely known case of deanonymization, the reason can usually be found in the mirror. Malware authors often get caught because of ridiculous mistakes. Why keep personal files on the same server as your botnet admin panel? Why send botnet stats via SMS to a burner phone number that’s already been used in online ads with your city and even the nearest subway station? Who thought it was a good idea to set up a trojan’s C&C server on your dad’s business website and hardcode the URL into the code?

It might seem like only the least intelligent coders make these mistakes, but anyone can step on a rake—especially if they don’t develop the habit of watching their own steps.

Debugging Details: Leaking Personal Info in Code

Debugging is a painful process of removing bugs from a program. Some compilers add special debug strings to the binary, which can include the full path to the project’s source folder—sometimes with the Windows username, like C:\Users\Vasya Pupkin\Desktop\Super_Virus\ProjectVirus1.vbp.

During reverse engineering, these details inevitably come to light. If the username is a real name or even a surname, it makes identifying the author much easier. Even if it’s just a nickname, it’s still a valuable clue. Most people use the same nickname across different platforms, making it easy to find their forum posts, GitHub, or Twitter profiles. Matching avatars, signatures, or repeated text across sites can quickly lead to the real person.

The takeaway: if you’re writing a program that someone might want to analyze, practice good hygiene and make sure nothing unnecessary ends up in your code.

Email Addresses: A Common Slip-Up

Another common mistake is storing email addresses as plain text in the code. These are the first things reverse engineers look for. Some think that simply XOR-ing the string is enough to hide their email from prying eyes. It’s not.

If an email is found in the code, it’s immediately Googled. From there, it might lead to a Telegram account, social media profiles, or forum registrations. Sometimes, nothing comes up—usually if the user wisely keeps separate emails for technical and personal use.

Passwords in Code: A Recipe for Disaster

It gets even worse when someone hardcodes logins and passwords directly into the code—like for a bot admin panel or a cloud storage account where stolen files are uploaded. It’s especially bad if the same password is used everywhere: admin panel, email, social networks.

There was a recent case where an anonymous user tested a stealer trojan on their own computer. The stealer worked perfectly, uploading all their personal files to a cloud account whose login and password were stored in plain text in the trojan. Researchers got a full view of the person’s private life. Avoid this, username.

Hardcoded Domains: Making Tracking Easy

Some people still hardcode C&C server addresses into their code, even though DGA (Domain Generation Algorithms) have existed for ages. DGA makes trojans more resilient by automatically switching to new servers if one goes down. Even if a server’s address is known, it can be brute-forced, sinkholed, or DDoSed. Generated addresses can also be tracked by analyzing the algorithm, but other protections like server signature verification and encrypted data transfer come into play.

Even if researchers can’t break into the admin panel, they can get a lot of info using WHOIS. Hiding domain ownership doesn’t always help. You can also look for other sites on the same IP, see what’s there, and try to access them. Many have heard of CloudFlare, but few bother to understand what it actually does.

Some people even host admin panels on public hosting or on sites where they run other projects or their employer’s website. No comment—mocking this is pointless, and crying about it is exhausting.

Pride Comes Before a Fall

Pride is a deadly sin, and according to religious leaders, sinners will be punished. Not all malware authors are content to stay in the shadows and quietly make money—they want fame, respect, and applause. Some start recording videos about compiling and obfuscating trojans and upload screencasts to YouTube, forgetting to close browser tabs with their VK page or file explorer windows showing revealing details in HD.

Another person didn’t make compromising videos but published detailed articles online about bypassing UAC, writing exploits, and privilege escalation tricks—with code samples, of course. He was identified by matching variable names, comments, and coding style between his public posts and code found in IDA Pro. Denying it was pointless—he posted the code in his personal blog under his real name. Fatality.

Conclusion

There are countless ways to identify malware authors; I’ve only mentioned the most obvious. The conclusion is just as clear: it’s usually the author’s own incompetence and careless attitude toward basic security that leads them to the investigator’s office. Maybe that’s not such a bad thing—after all, as a certain bearded Russian writer once said, natural selection helps the species survive.