Fileless malware: Invisible threat or scaremongering hype?

Also Python malware that both I and @cruelsister have previously commented on fall into this class. Note that the ransomware developers have switched to Python as their favorite code language.

 

Python is a beautiful thing; such a shame that the Pro's finally realize that there can be an issue...

 

You're still missing my point. No matter if malware is file based or file-less it needs to run inside a process. Malware can run inside some trusted system process, which is a problem because they are often not monitored. Best thing you can do is to allow only certain processes to have network access, this means malware won't be able to connect out. Unless they inject code into the browser, so it's tricky stuff.

 

Python have got such a popularity 'cause it's more friendly for those who have no IT background, like me (tho I learned C & assembly as hobby).
Believe it or not, those who have developed ML don't have much things to do w/ IT.

 

Or better, in this case tho, monitor dynamic compile itself - I guess it can potentially cause performance issue. Are there any legitimate use for that? Why don't compile beforehand and run the binary (assuming legit programmer)?

 

Yes, it is browser based but the malicious code is not injected into the browser by a malicious process running on the client device.

Per the Malwarebytes article:

All that required is a browser redirect to a malicious web server and its game over unless some type of memory scanner is deployed. Also a great example to quell the debate about HTTPS protocol scanning.

 

Pls educate me, so is it essentially the same thing how interpreter generally work? python.exe is ofc legit, but it can interpret whatever code, legit or malicious, and yeah these days many codes are on internet so it makes sense to dynamically interpret code on internet?
I still don't see why the whole source code have to be compiled dynamically tho.

 

Had to smile when I saw an article by Malwarebytes pontificating about fileless malware. They should spend their time instead by attempting to detect a simple Scriptor worm.

 

Python is a script based language. If one wanted to employ it for daily use, they would install Python to run those scripts. This would lead one to believe that if they employ some anti-exec solution with generic process name blocking such as coding *python.exe, any python script execution would be blocked.

As a side comment, it should be noted that if an attacker can gain remote access to a device, all that is required is that a script be dropped on the device. The attacker can then run that script remotely using one of the pen tester tools as has been published about the recent spat of PowerShell attacks performed using this method.

Back to Python. Well it turns out that Python does not have to be installed on a device to run a malicious Python script. Due to the fact the Python engine is interpretive, the engine and script can be downloaded together with the engine executing "on the fly" to run the script in a fashion similar to that described in the Malwarebytes article for the malicious C# .Net program. Start reading about this at this posting: https://www.wilderssecurity.com/thr...sables-security-services.403061/#post-2763472

Also, the PyLocky ransomware is another example of this technique: https://www.securityweek.com/new-python-based-ransomware-poses-locky

-EDIT- Since @Rasheed187 will "call me out" on this, the above examples require that the Python engine components be bundled into an executable. So as long the anti-exec your using can block that from executing, these type of Python attacks won't succeed. A favorite delivery method for these would be a wscript installed as WMI consumer script event since it uses its own script engine to run the script; not wscript.exe.

 

@itman
Thx, but python.exe was just an example of interpreter. I understand what's described in the article is that source code of malware was dynamically compiled on client machine then executed inside the trusted process - so static scanner couldn't detect it. To me it appears similar to what interpreter generally will do if they fetch code from internet. Is this correct? If so, what is the legitimate use of that? I even don't understand why interpreter have to interpret code on internet directly, that will degrade (already slow, you know) performance. Why don't just download source code and then run interpreter? If only malware author use that functionality, is it possible to block that?

BTW if my understanding is correct, https scan won't detect it anyway - MB also said it bypass NIPS. Given how many times AV vendors have done blunder on MITM, I don't see strong justification for https scanning (I mean, it will be effective in some cases but still can be bypassed by technique like this), but as these days addon is quite restricted, better memory scanning (not only effectiveness, but also in performance) will be required.

 

In the detail analysis of PyLocky by Trend Micro, the zipped e-mail attachment contained the malware dropper executable. The sole purpose of it was to download all of the Python components to run the Python ransomware executable. This executable contained all components to dynamically load the Python engine and run the Python ransomware code. The Trend Micro article is ambiguous as to how lockyfud.exe was run. It can be assumed it was not run directly from the C:\Users\{user}\AppData\Local\Temp directory since everyone is blocking executables from there. Assume it was by WMI consumer/command event triggering since this ransomware does install anti-sandboxing code there.

Here's the link to the Trend Micro analysis: https://blog.trendmicro.com/trendla...r-look-at-the-locky-poser-pylocky-ransomware/

 

Exactly my point. I don't care about these fancy .Net and Python malware, they all need some process in order to operate. So behavior blockers should be trained to monitor even system processes for abnormal behavior and that's the tricky part.

 

I have read both of the Malwarebytes articles and it confirmed what I already thought. The most scary file-less attacks are the ones that are triggered by exploit. Because in theory they can operate from within the exploited process like the browser. This means that ransomware will never have to be dropped to disk and all encrypting is done by the browser. But a good anti-ransomware tool will block encryption no matter which process is doing the damage. Luckily we are need seeing these attacks in real life.

 

Fileless Malware: What Mitigation Strategies Are Effective?

https://www.databreachtoday.com/fileless-malware-what-mitigation-strategies-are-effective-a-11975

 

Hum ………..

Appears the author really isn't current on technologies used by the major AVs today. First, most malware today is still identified by signature. Also, today's signatures are not the 100% code match versions of the past. Code snippet and YARA like behavior signatures are also deployed by the memory scanners used in the major AV products. Bottom line - very few malware creations are "original works of art" with code readily copied from previous malware.

 

but python uses many modules, that stuff gets detected, isn't it better to use assembly or even C, C++

 

Yes it is as far as stealthy malware goes. And C preferably since you almost have the same low level code capability that assembler language has.

The problem with the Python embedded engine downloads is they are huge which in itself is suspicious. Also executing Python malware code this way is very "noisy" which in itself can be detected by some AVs.

 

What I would like to see in HIPS is this stuff, it should be able to spot malicious activity, even when malware is already running:

https://www.cybereason.com/malicious-activity-models

 

@Rasheed187 since I brought up reflective PE injection in the like fileless malware registry thread, here's a good article on the technique: https://www.andreafortuna.org/2018/09/24/some-thoughts-about-pe-injection/ . Your best protection against it? Use an AV solution with advanced memory scanning protection.

-EDIT- Reflective PE injection is most often used in process hollowing attacks. Start svchost.exe in suspended mode, inject the PE code, "tiddy up" things memory-wise, and start the process. Walla! We now have a rogue Win trusted system executable running.

 

Correct, process hollowing is a real problem, only HMPA is able to block it out of the box, I don't know if AV's can do the same. Normally when malware runs, it will try to inject code into another process (malware.exe modifies memory of firefox.exe), but I believe that the parent process (malware.exe) must still be running. So that's why they came with process hollowing.

 

As I have stated multiple past times, Eset HIPS's process modification detection will detect same for suspended processes. "The rub" is you have to create manual rules for this. Obviously, you're are not going to do so for every .exe on your HDD.

Likewise unless HMP-A is setting a hook into any process that can be started in suspended mode, which is all of them as far as I am aware of, you are still vulnerable using HMP-A.

 

HMPA injects into almost every process, but it only list the mitigations being used for vulnerable applications like Web Browsers, Pdf Viewers, Office Applications, Media Players, Compression Software (Winrar, 7zip, Winzip, etc.), and a few others. Since HMPA injects into almost everything else, I wonder what it is monitoring for the application that are not on it's vulnerable application list.

Edited 5/11 @ 8:57: It may be possible to tell by using something like HookShark or maybe even ProcessHacker. I don't have HMPA installed right now though. I think HookShark will list all those being used by HMPA instead of on a per application basis though.

 

The problem with .dll hook injection via security process is it is increasingly getting harder to do because Win 10 system processes are increasingly using PPL. Lsass.exe is a good example. The problem is PPL bypass is fairly trivial to perform by malware. So what we now have is a "chicken or the egg" scenario. Eset's HIPS process modification detection does not employ any type of hook injection into the process. Not 100% sure what it uses but suspect its one of its kernel mode driver stubs.

 

Memory analysis is the ground truth
May 17, 2019
https://www.helpnetsecurity.com/2019/05/17/memory-analysis/

 

I'm not sure if it's necessary to hook every process in order to spot process hollowing. But from what I understood, HMPA should be able to spot all forms of process hollowing. I don't believe that SpyShelter can do this out of the box. SS will probably give some general warning about process memory reading, that's not good enough of course.