Fileless malware: Invisible threat or scaremongering hype?

Well, one could argue that memory objects are also files.
Mrk

 

Actually, some do. Eset for example employs an advanced memory scanner. As Eset correctly notes in their documentation, this is a post-execution mitigation. As such, their is a risk that some partial malware infection might have occurred prior to in memory detection.

Another example would be Emsisoft's behavior blocker which continuously monitors suspicious processes for memory injection activities and the like. The difference here is the memory injection activities themselves are being detected versus any malicious code that is in memory.

The main problem currently is malware that abuses valid Windows system processes such as WMI, COM, and the like to execute scripts namely Powershell to perform like memory modification activities using .Net components and/or programs. Unless the code injected into memory is known to be malicious, memory scanning of it is ineffective.

Even advanced AI engines that continually monitor process execution deviation from norm have issues when malware is deployed via scriptors.

 

So assuming one is running in an SUA, couldn't powershell.exe be restricted using whitelisting anti-exectuable to be run only by Administrators, with UAC at Always Notify? Add to this, restrict its outbound connections using firewall, as well as script blocking in the browser?

 

I know where you are coming from @RockLobster and agree with you. And perhaps it is nitpicking.

But don't these - once executed actually change the Registry?

 

Yes, it could change the registry if it has access to it, the main difference between it and most known malware is it tries to avoid detection by not installing itself on the hard drive as an executable.
It might sacrifice persistance by not doing that but it could be used by an attacker to open up a system to further penetration by a one time hit on system security settings.
I would imagine for example, a script in a webpage that opens a file from a remote location, or a macro in an email that does something similar, or perhaps that
file:/// url that attempts to open a file on the remote host? That might be another way to do it with a disguised URL.

Once running as a process in RAM, it's purpose might be to wait for the victim to enter an admin password then grab it and use it to change system security settings, thereby opening up the system to further attack and if it wasnt executed from a file on the local host it might be difficult to identify how that happened.

 

Here's a great article by Barkly that pretty much covers all bases in regards to fileless malware: https://www.barkly.com/what-are-fileless-attack-techniques .

UAC set to max. level is a great mitigation for detecting a process that requires admin privileges started as hidden. How malware gets around that is to use a process that does not require admin privileges to run and set it to run with admin privileges as shown below. Anything started thereafter will acquire its privileges from the parent process:

https://www.powershellempire.com/?page_id=380

 

Excellent overview at: https://www.barkly.com/what-are-fileless-attack-techniques

Thanks for posting that @CompTIA.

 

Yes good article, good to see people advocating UAC too.
I feel sure there was a deliberate effort to undermine UAC by those who saw it as a threat to their phone home data mining privacy stealing business model.
The internet was infested with articles and posts downing UAC and file system virtualization when it was introduced in Vista and I was dissapointed when Microsoft bended to that false criticism and weakened its functionality because if you go back and install an out of the box Vista, the original UAC was really good.

 

Thank you @itman for the article. Finally an article that provides useful suggestions on how to mitigate an exploit, rather than simply scaremonger about how harmful they are and how everyone should be terrified It was excellent. I employ many of those mitigations - several of which are already built into Windows - on my home machines.

 

I have one question about that POC. It says: "This method abuses the fact that wscript.exe (and cscript.exe) don’t have embedded manifests. By moving wscript.exe and dropping a custom manifest file (wscript.exe.manifest) to C:\Windows, we are able to execute commands through C:\Windows\wscript.exe as a high-integrity process." [my bolding]

How exactly are those actions achieved without triggering UAC prompt if UAC is set to high? I tried both actions and couldn't make them without UAC prompt. Is this bypass only for UAC set at deafult level (as most of other bypasses)?

 

Kaspersky back in 2016 wrote an informative blog posting in regards to UAC and the Windows integrity mechanism here: https://securelist.com/malicious-code-and-the-windows-integrity-mechanism/76751/ . The posting starts out by noting a well quoted Microsoft statement:

Also to my best knowledge, Microsoft has never deviated from this position as evidenced by the current default Win 10 UAC setting is the same as that for all Win versions since XP.

The Kaspersky article makes no assumptions the role UAC plays in the current state of malware's apparent ease in escalating privileges. It only shows statistics to support the ease at which malware can do so. I have always held the belief that advanced malware will find a way to escalate privileges to the level it requires to do its activities. Therefore, UAC use as a malware mitigation can best be described as a "control check mechanism" that will alert to some but not all anomalies.

 

Appears that is the case based on the POC write-up:

https://github.com/Vozzie/uacscript

 

Yes, I agree. There are at least 2 situations where UAC wouldn't help much. First is a case of malware that is designed to work under LUA and doesn't make system wide modifications. Second is malware exploting holes in software that runs with high privileges (drivers, services...). In both cases UAC (or even SUA) wouldn't help much.

 

I will add a third situation that is applicable to fileless malware. This is to inject the malicious code into a high integrity process. Microsoft's mitigation for that in Win 10 in regards to "high value" targets such as lsass.exe was to introduce Protected Mode. The problem is pen-testers have already demonstrated that can be bypassed without great difficulty.

 

Excellent point.

 

Yes, good article. You now see why I was so impressed with Barkly? I have always said that file-less malware is far from unstoppable.

 

Rasheed- Many people think that "fileless" attacks are magical and they are far from it. In order for any malware to do something malicious on your system it has to have some Local effect (even something like a reflective dll attack via metasploit). With the proper protection any such Local effect can be detected/negated.

Being overly concerned with fileless malware attacks is like being overly concerned about picking up an STD from a toilet seat...

 

Overall and excluding scriptors, I would say your three most widely used fileless memory injection methods are:

1. Reflective DLL injection
2. Process Hollowing
3. APC thread high-jacking

Process hollowing is noteworthy in that many security solutions do not monitor suspended processes for process modification activities. Even the specialty third party security solutions attempt to stop PH activities by monitoring child process startup activity which is not the way to do so.

APC thread high-jacking was deployed by the DoublePulsar exploit both in kernel mode for unpatched systems and in user mode. Again, this is not 100% diskless in that a malware process is started and a thread set from a .dll in that process to the targeted process. What makes this method unique is it does the thread setting without setting a hook in the targeted process. Also the attack .dll does not have to be a reflective one.

 

Indeed, all malware need to be delivered (email attachment, downloaded file, compromised webpage), they need a stager. Deploy the proper security solution/mechanism, and fileless malware are just another malware.
Black Hats don't use fileless malware because they are uber-powerful (or not) to compromise the system, they use it for its stealthiness.

 

Fileless malware: part deux

https://blog.malwarebytes.com/malwarebytes-news/2018/10/fileless-malware-part-deux/

 

This part of the article I disagree with:

Eset for example has a memory scanner. So it can detect malware in memory by signature. The downside to all memory scanners however is the malware has begun execution. As such, malicious activities could have been performed prior to in memory signature detection. Heuristic scanning offers limited protection as long as the malware manifests while being sandboxed. Likewise machine learning/behavior monitoring is only effective if the activity is associated with previously known suspicious/malicious actions.

The article does have an excellent explanation of .Net based malware that confuses many. @Rasheed187 take note.

 

@itman according to Eset's explanation it seem to me that advanced memory scanner is in a way more similar to behavior blocker than signature scanner. More info here: https://help.eset.com/eis/11.2/en-US/technology_ams.html

If you're talking about memory scans being conducted by on demand scanner, those scans won't protect user from infection. They will only detect malware once it's already in memory and on demand scanner is run. Though I might be wrong...

 

As far as Eset's AMS goes, its primary interface is through Win 10's AMSI. Remember that its a "rule rather than exception" for scripts to be packed and obfuscated and at times encrypted. AMS intercepts those scripts after they have unpacked and decrypted in memory and scans them using its realtime scanner. I have also seen AMS detect non-script based malware but I don't currently have an example in my Eset logs. Also this is dynamic scanning; not on-demand triggered.

https://www.eset.com/int/about/technology/

Note: Eset DNA detections are similar to the YARA signatures mentioned in the Malwarebytes article but also include behavior elements such as Win API usage and the like. This publication has detailed explanations on DNA signatures and Eset's machine learning: https://cdn1.esetstatic.com/ESET/INT/Docs/Others/Technology/ESET-Technology.pdf

 

Didn't read the article yet, can you explain to me what's so special about .Net based malware? All I said is that malware always need to run inside a process. As long as a process is monitored it doesn't matter what technique malware is using.

 

some fileless malware doesn't, they embark their own interpreter which is ran in-memory, no need to touch the disk, so no detection, no blocks from whatever sec apps you use (except probably from anti-exploits like HMPA/MBAE or memory protection based apps).