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).
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).
π59β€39π€£15π2π₯1π₯°1π’1
People keep forgetting that time a hacker was strategically bombed by Barack Obama
Nerd from the United Kingdom fled to Syria to become a Jihadist hacker. He was pissing off the United States government, so Obama just bombed his ass.
Killed him and his homies
Nerd from the United Kingdom fled to Syria to become a Jihadist hacker. He was pissing off the United States government, so Obama just bombed his ass.
Killed him and his homies
π40π€―23π14π€£13π’6β€2π€2π€2π₯°1
vx-underground
People keep forgetting that time a hacker was strategically bombed by Barack Obama Nerd from the United Kingdom fled to Syria to become a Jihadist hacker. He was pissing off the United States government, so Obama just bombed his ass. Killed him and his homies
Not memeing, Obama bombed him and his homies. They couldn't arrest him, or something, so they opted to just kill him
https://en.wikipedia.org/wiki/Junaid_Hussain
https://en.wikipedia.org/wiki/Junaid_Hussain
π€―38π₯°11β€6π₯6π€£6π1π1π―1
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.
"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.
β€69π₯°4π₯1π’1π―1
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.
"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.
β€61π―7π₯6π₯°1π’1
The University of Oregon leadership are so wildly incompetent they should seriously consider resigning.
A physics major discovered that the universities SharePoint was misconfigured. Using an asterisk (wildcard) while searching unveiled sensitive documents at the university including staff social security numbers.
When he reported the issue he got a disciplinary hearing for violating the university computer usage policy. He was suspended.
The university then notified the staff of a "breach" and issued all the staff 1 year of credit monitoring.
Absolute brain dead slime over there at the University of Oregon. All the student did was use a wildcard, report it wasn't configured correctly, then the dean started going schizo.
More information: https://archive.is/NPRM1
A physics major discovered that the universities SharePoint was misconfigured. Using an asterisk (wildcard) while searching unveiled sensitive documents at the university including staff social security numbers.
When he reported the issue he got a disciplinary hearing for violating the university computer usage policy. He was suspended.
The university then notified the staff of a "breach" and issued all the staff 1 year of credit monitoring.
Absolute brain dead slime over there at the University of Oregon. All the student did was use a wildcard, report it wasn't configured correctly, then the dean started going schizo.
More information: https://archive.is/NPRM1
archive.is
A University of Oregon student reported a troubling online privacy laβ¦
archived 5 Sep 2025 21:30:50 UTC
π42π€―29π€£13β€7π₯°6π’5π1
vx-underground
The University of Oregon leadership are so wildly incompetent they should seriously consider resigning. A physics major discovered that the universities SharePoint was misconfigured. Using an asterisk (wildcard) while searching unveiled sensitive documentsβ¦
tl;dr * IS ILLEGAL AND FOR NERDS
β€47π€21π11π’2π2π―1π€£1
vx-underground
wtf someone cut internet cables in the Red Sea
ok to be fair it could be like, an underwater squirrel or a shark or something (idk if sharks exist in the red sea), but kind of suspect tbh
π€£50β€5π4π3π’1π1
Anthropic just got fined $1,500,000,000 for piracy.
π€£99π24π₯6β€4π₯°2π€2π±2π’1π―1
vx-underground
Anthropic just got fined $1,500,000,000 for piracy.
Sorry, I need to make some language corrections.
It is a $1,500,000,000 settlement*, to authors for alleged piracy, or something.
It is a $1,500,000,000 settlement*, to authors for alleged piracy, or something.
π€£38π12π₯6β€2π’1
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.
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.
π₯43β€31π€8π3β€βπ₯1π’1π―1
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.
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.
β€71π8π₯4π€3β€βπ₯1π€―1π’1π―1
I watched this video on YouTube which questioned the validity of a YouTube series called "Hot Ones".
To make a long story short, each of the hot sauces in that show are derived from super mega fuck off hot peppers, but the sauces themselves are not nearly as hot because they're watered down, given flavoring, etc. It's like, sort of fake advertising, but sort of not? It allows people to be like "i HaD tHe HoTtEsT sAuCe eVeR", but it's not. Whatever.
Anyway, then these nerds sent all these different sauces to a laboratory to have scientists do science. They determined that they hottest sauce in the world (or from the dozens of sauces they selected) is a hot sauce called "Mad Dog 357".
I just got a bottle of it
I don't know why because normally the spiciest thing I eat is salt. The science and stuff inspired me to experience the hottest thingy of sauce in the world.
To make a long story short, each of the hot sauces in that show are derived from super mega fuck off hot peppers, but the sauces themselves are not nearly as hot because they're watered down, given flavoring, etc. It's like, sort of fake advertising, but sort of not? It allows people to be like "i HaD tHe HoTtEsT sAuCe eVeR", but it's not. Whatever.
Anyway, then these nerds sent all these different sauces to a laboratory to have scientists do science. They determined that they hottest sauce in the world (or from the dozens of sauces they selected) is a hot sauce called "Mad Dog 357".
I just got a bottle of it
I don't know why because normally the spiciest thing I eat is salt. The science and stuff inspired me to experience the hottest thingy of sauce in the world.
β€41π€£25β€βπ₯9π±2π’1
vx-underground
I watched this video on YouTube which questioned the validity of a YouTube series called "Hot Ones". To make a long story short, each of the hot sauces in that show are derived from super mega fuck off hot peppers, but the sauces themselves are not nearlyβ¦
I don't expect anyone to give a shit about "the weird malware cat picture collection" persons thoughts on hot sauce and esoteric YouTube videos is. I just wanted to share this random bit of information with someone.
π32β€16β€βπ₯14π€£10π’1
vx-underground
I watched this video on YouTube which questioned the validity of a YouTube series called "Hot Ones". To make a long story short, each of the hot sauces in that show are derived from super mega fuck off hot peppers, but the sauces themselves are not nearlyβ¦
Update: Tried MadDog 357. The bottle is cool looking and it comes with a bullet thingy that is a keychain. No idea.
Opened the bottle, the smell made my nose tingle. Very cool.
I put a few drops around a chip. The few drops were probably too much in retrospect. Nerds told me to use a single drop. I thought they were being dramatic. They were not.
At first it tasted kind of sweet. It then went 0 to 100 and it summoned a burn I haven't really experienced before from spicy stuff.
It made my tongue feel like it was physically on fire.
It's been well over an hour and my stomach feels like it has a bruise.
I drank milk and slowly the burn went away within 5 minutes or so.
Overall I rate the experience a 3/10. It was painful and uncomfortable, but it wasn't crazy (I didn't cover a chip in the sauce, I used the sauce sparingly). It sucked, but it was a fun experience with super spicy stuff.
Opened the bottle, the smell made my nose tingle. Very cool.
I put a few drops around a chip. The few drops were probably too much in retrospect. Nerds told me to use a single drop. I thought they were being dramatic. They were not.
At first it tasted kind of sweet. It then went 0 to 100 and it summoned a burn I haven't really experienced before from spicy stuff.
It made my tongue feel like it was physically on fire.
It's been well over an hour and my stomach feels like it has a bruise.
I drank milk and slowly the burn went away within 5 minutes or so.
Overall I rate the experience a 3/10. It was painful and uncomfortable, but it wasn't crazy (I didn't cover a chip in the sauce, I used the sauce sparingly). It sucked, but it was a fun experience with super spicy stuff.
β€42π«‘24π€£18π₯8π2π’1
Really exciting things coming.
Working on a massive enhancement to vx-underground. It'll take several months to accomplish it, but it'll be well worth it.
Thank you all of our sponsors and donors. Your money lets me do crazy shit on the internet.
Hint: it's involves malware
Working on a massive enhancement to vx-underground. It'll take several months to accomplish it, but it'll be well worth it.
Thank you all of our sponsors and donors. Your money lets me do crazy shit on the internet.
Hint: it's involves malware
β€84π€―10π₯°3π«‘3π’1
for a really long time i thought the Large Hadron Collider was the "Large Hardon Collider".
i never even questioned it. i was like, "well, its science and things are hard"
i never even questioned it. i was like, "well, its science and things are hard"
π37π€£26β€7π€4π’1π€©1