Malware For beginners

[spartadon]

Malware Noob Month Post #1

Anti-malware vendors (anti-virus companies, but it's more appropriate to call them "anti-malware" now), rely heavily on known-good and known-bad lists.

In other words, anti-malware companies maintain a large list of file signatures which are safe and which are dangerous.

Every file an anti-malware company encounters is digitally "fingerprinted" using what is known as "file hashing". There are many different fingerprinting (or file hashing) techniques. Although, the most commonly used techniques used by anti-malware services are MD5, SHA-1, or SHA256 hashing.

When you first install an anti-malware product on your computer it walks each directory on your computer (it goes through your entire computer), and "fingerprints" everything.

It compares the fingerprint of each file against its "known-good" or "known-bad" list. If a known-good is encountered, it skips it. If it is a known-bad, it will take action based on what it believes the threat to be. If the file is unknown, other action may be taken based on the file characteristics (is it a .exe, a picture of a cat, etc).

Everyday anti-malware vendors update their "known-good" and "known-bad" lists. This is one of the easiest way for anti-malware vendors to combat malware.

The likelihood of 2 files having the same "fingerprint" (SHA256 hash) is 2^256

Or, to be specific, the chance of 2 files having the same fingerprint is 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936

Hence, using this simple file fingerprinting identification system, anti-malware services can feel fairly confident their fingerprinting method works and is accurate

Now you're asking... is there a way for malware writers to avoid fingerprinting? To change their fingerprint? Of course! That's for tomorrows post

all other posts will be made under this thread. So stay tuned and keep watching the thread

 

[spartadon]

Post#2
It is common for people to perpetuate the myth that malware will impact computer performance. This myth is also perpetuated in corporate trainings.

Historically, in the 90's and early-2000's, it was possible for malware to be so resource intensive (using excessive memory or CPU) it would slow down the machine. However, in 2025 this isn't a problem due to improvements in computer hardware.

Part of this myth comes from "polling" operations performed from malware.

An example of "polling" is when you're writing a (shitty) keylogger. You may want to write code which continuously checks to see if a key on the keyboard has been pressed. Then, when your code determines a key has been pressed, write the pressed key to a text file (recording what the user is typing).

This action of continually checking to see if something has been performed (any key being pressed) is "polling". As recent as Windows XP, "polling" when writing malware was considered dangerous because there was a concern of excessive CPU usage.

In 2025 "polling" isn't really a concern. The only malware now which is resource intensive is crypto-mining malware.

 

[spartadon]

Malware Noob Month Post #3

The easiest malware to develop is information stealer malware.

Of course any malware can get really crazy, all the buzzwords and mumbo jumbo, but an information stealer is extremely basic in concept.

All your code needs to do is copy everything from a users machine to a remote computer you control.

The most deceptively hard malware to write is ransomware. In principle it seems easy, but ransomware very quickly can become very strenuous on a developer.

Ransomware must be fast, must be multi-threaded, must be asymmetrically encrypted, must be bug free (or else decryption won't work), and while also trying to avoid detection (almost impossible for ransomware).

Ransomware is incorrectly called "skidware" because it is the most heinous types of malware. But good ransomware (which is rare) can be challenging to develop.

And for the Threat Actors and Red Teamers reading this: DO NOT USE BABUK RANSOMWARE. Babuk is filled with bugs. Babuk will destroy everything. If you're a Threat Actor using Babuk, you won't get paid and you'll waste everyone's time (including yours). If you're a Red Teamer, the people won't be able to restore their data.

 

[spartadon]

Malware Noob Month Post #4

Does malware need to be written in C or C++?

No. You can write malware in any language you want. In fact, I encourage you to write malware in other programming languages.

The reason why C (or C++) is so common is because, as is tradition, it has some historical context.

Back in the day the language for programming was assembly. However, as IDEs and compilers improved, it became more acceptable to write in C (for reasons we can discuss later).

Either way, Operating Systems began exposing APIs (Application Program Interfaces) in C. Basically, you could communicate to the Operating System and have it do things for you such as create a file or make space in memory.

C very quickly became the standard for APIs for Windows and Linux. Hence, malware would inevitably use this language. Additionally, C is very similar to assembly in regards to memory management and ability to ruin your day.

In 2025 dozens of programming languages can interopt with Operating Systems. You do not need to use the old school Windows API or do things on Windows anymore.

You can write malware in Rust, Go, Java, NodeJS, CSharp, VB, Python, ???. It doesn't matter.

C (or C++) is the old school standard, it has seniority, it's been around forever. But, as long as the language gets the job done, it can be literally anything you want.

It should be noted though that C (and C++) has a reputation of being elitist (myself included sometimes), so when you make a cool proof-of-concept and it's not C or C++, some people might sigh or complain (myself included), but just ignore them (myself included).

 

[spartadon]

Malware Noob Month Post #5

"Malware written in Java? Malware written in Python?!"

Yes, this is more common than you think. Python, Java, CSharp (kind of), Perl, Ruby, etc. are interpretation-based languages.

Each of these languages listed (and more I didn't list) depend on a "virtual machine" to "interpret" the code. In the simplest of terms, a computer program reads the code you wrote (Python, Java, etc) and transforms the code into assembly code in real time.

Interpretation languages are cool because they (normally) are easier to write. The downside is that, because they depend on a "translator" (using that liberally here), they are slower than compilation-based languages. Each instruction in your script is being translated as the script continues.

Compilation-based languages, such as C, C++, Go, Rust, etc. compile directly into assembly code.

Malware written in interpretation languages has pros and cons. The positive side of writing malware in an interpretation-based language is the ease. Writing malware in Python is much easier than other languages. While it may not have as much "power" and "flexibility" as something like C, the simplicity of the language allows R.A.D. (Rapid Application Development). Basically, you can write a bunch of code really fast.

The downside is that your malware source code (usually*, you'll see soon) will be exposed as a .py file. In other words, your malware source code is easily exposed. Someone can simply open your malicious code in a text editor and inspect it. Furthermore, your malware is dependent on the "translator" program being present. If your malicious program written in Python, or Java, or Perl, does not have the appropriate software installed your code is basically dead before it can even start (it literally cannot start).

It is EXTREMELY common to find malware which targets Discord being written in Python. Java-based malware is less common nowadays, but in the mid-2000's it was hot stuff (long story). However, like all languages, malware tends to go through "phases".

To address the usually* with an asterisk which I wrote up above: in the mid-2010's malware written in Python was pretty common because the secret ingredient was using an external tool which would place the Python "translator" inside of an .exe and the Python script as well. Basically, it coupled everything together so a .py became a .exe. It made it possible to write Python code without relying on the "translator" program (it was all just jammed together).

But when anti-malware companies learned this trick and made tools to identify it (bundling .py and "translator"), the hype died down because it was caught super easily. They crashed the party.

 

[spartadon]

Malware Noob Month Post #6

"If ransomware just encrypts things, can't they use other encryption software?"

Absolutely! This is a discussion topic in malware analysis circles. For awhile (and maybe still now, haven't been as focused on ransomware) it was "trendy" for some ransomware strains to abuse utilities such as 7z or WinRAR to encrypt things.

The problem with this method however was the password being exposed. Traditionally, ransomware uses "asymmetric encryption". Basically, the "password" to encrypt something is NOT the same password to decrypt something (tl;dr public/private keys).

When ransomware uses 7z, WinRAR, etc. the password to encrypt is the same password to decrypt. Hence, the malware author would have to go through great lengths to hide the password they used to ransom the machine.

It's possible, but has weaknesses which make it difficult and not ideal.

 

[spartadon]

Malware Noob Month Post #7

There are different types of reverse engineering. Each play a critical role in malware reverse engineering and detection engineering.

The most widely known is what I would define as "standard" reverse engineering. This is attaching a debugger to a running process (i.e. x64dbg) and watching what the program does as it's running.

Another common method for reverse engineer is "static reverse engineering". Static reverse engineering is looking at the program while it's "on disk", in other words, staring at it while it's not running. People usually use Ida or Ghidra.

A third method for reverse engineering is "emulation", "sandboxing", or "triaging". They all kind of mean the same thing, all maybe a little different if you want to get really nitty gritty on the details. This type of reverse engineering is detonating (running) the program in a virtual machine (or special environment) and recording everything that the program does.

Each method listed has a strength and weakness.

Emulation is really good at doing the job quick and dirty. If you use emulation tool suites, like Triage or AppAnyRun, you can very quickly get a high level overview of what the malware is doing, where it's connecting to, etc. Additionally, these tool suites usually have built in rules to automatically detect the malware family (if applicable). However, these tool suites cannot detect everything and it's possible for malware to fall between the cracks and evade emulation.

Static reverse engineering, using Ida or Ghidra, is also really good. You can review the malware before it tries performing evasive actions. The primary issue with this method however is that if the malware obfuscates itself on-disk (encryption, it's packed, etc) this method can challenging.

"Standard" reverse engineering is probably the most difficult form of reverse engineering. It requires you to have a good understanding of Assembly. However, this method is the most superior. Once you're comfortable with assembly and the debugger you're using, it makes it extremely difficult for malware to "evade" the reverse engineer (some non-noobs probably feel tempted to mention LLVMs, don't).

Regardless, it is impossible for malware to evade all of these methods. It is possible to develop malware that makes it challenging to reverse engineer, but ultimately a dedicated (or skilled) reverse engineer will figure it out.

Malware authors must constantly evolve their malware code (update it, use new methods, introduce additional layers of complexity) to hinder reverse engineers. If they do not do this, reverse engineers will have developed methods to detect the malware and it's basically game over.

Large scale malware campaigns are constantly changing the malware code base, delivery mechanism, etc. to ensure the malware can "survive". Likewise, anti-malware companies and reverse engineers must constantly monitor malware campaigns, keep reverse engineering them, and updating their strategies to detect them.

It's a game of cat and mouse.

 

[spartadon]

Malware Noob Month Post #8

What is "undetectable malware";

Well, it doesn't really exist. Kind of. There has been discussions of governments (United States, Russia, China) which had malware active for long durations of time and not getting caught. For example, Russia's "Woodchipper" was undetected for years.

The secret is "tailored" malware.

Malware campaigns are caught and tracked all the time because Threat Actors want their malware on as many computers as possible. The more "noise" these groups make, the more machines they infect, the more anti-malware companies can see.

However, specially crafted malware, designed for unique systems, unique environments, with a very specific goal in mind, can go undetected for A LONG time. Once a malicious program has made its way onto the target... And it's nowhere else in the world... How can anyone know it exists?

In these scenarios the chance of the malware being detected boils down to luck and/or fate.

For example, the United States government malware "Stuxnet", which targeted Nuclear Centrifuges, was caught by complete accident. That is a long story I highly recommend you read (or maybe look it up on YouTube, maybe a video exists about it)

In summary, the more machines infected the more likely you'll be detected.

 

[spartadon]

Malware Noob Month Post #9

It's impossible to know everything about malware.

That's an obvious statement people say about every subject, but I think it's important to add some context to this to really shine a light on the topic.

First and foremost, malware exists on different platforms and different architectures. This in of itself broadens the scope of malware. You essentially have a few main categories of study and then what I would describe as "everything else"

1. Windows malware
2. Linux malware
3. MacOS malware
4. Mobile malware
5. Web malware
6. ICS/SCADA malware
7. IoT malware
8. everything else...

Windows malware is the most common and widely studied and discussed. The reason why is that Windows is most commonly used in enterprise environments. That's where malware will drift toward naturally. That's where the money is.

Linux malware is far less common due to the rarity of Linux based operating systems in enterprise environments. Yes, of course they exist in enterprise environments, but it's not nearly as common as Windows. Linux malware also has some difficulties whereas Linux users *usually* aren't as ... uneducated ... as Windows users. Basically, Linux is for nerds. It's a little harder to get nerds to detonate malware.

MacOS malware very much exists. It's an extremely niche and specialized field of study on the malware ecosystem. Being completely honest, I don't know shit about MacOS malware. I've never even really used an Apple product. People like Patrick Wardle do lots of research on MacOS malware and do malware things.

Mobile malware is rampant. It exists on both Android and iPhone. However, iPhone malware is much more hush-hush (I can only speculate why). Android malware is a huge field of study, it's found every single day, it poses a very real risk. I also don't know much about it. People like Laurie Wired and some other nerd who works at ESET, discuss it often. Mobile malware now has become a real area of focus since the rise of targeted malware (such as Pegasus Spyware). Everyone has a mobile device. Long story. Crazy stuff.

Web malware is fairly generic nowadays. Historically PHP malware was a huge problem in the mid-2000s. Now most web based malware is malicious HTML pages which try to convince you to run binaries. It exists, but it isn't as robust as it used to be due to changes in web application architecture.

ICS/SCADA malware is a cluster fuck. It's malware for Industrial Control Systems such as Electrical Power Plants, Nuclear Centrifuges, Water Plants, etc. I know even less about ICS/SCADA malware than I do about MacOS malware. Cybersecurity firm Dragos is a big player in ICS/SCADA malware. ICS/SCADA malware is also kind of "deadly" in that this sort of malware can really impact people's lives (losing power in their home, for example).

IoT malware (Internet of Things), is a currently fairly generic malware topic. Most IoT devices (cameras, washing machines, shit that shouldn't be connected to the internet) are Linux based operating systems. Hence, they have heavy overlap with Linux malware. However, IoT devices and IoT malware typically revolve around botnets (DDoS) because (usually) IoT devices cannot be used for much else other than bandwidth.

Everything else...
Nerds putting malware on toasters, car firmware, ... Anything niche and weird. People will do something cool with it. Someone once put malware on stuff that tracks cows? They turned cows into DDoS stuff or something. Someone also wrote ransomware for chastity belts...