Any statistics on memory-only malware ?

Hi


Following on from a few recent threads here on POC regarding memory only malware.

https://www.infosecisland.com/blogview/7571-Memory-Only-Malware-Look-Mom-No-Files.html

Google - Metasploit

Does anyone have any statistics on how widepread these are in the wild ?

 

Katio has pointed out that there may be unreported successful targeted attacks in the business world -- unreported for various reasons.

On another note: As I understand the article you cite, the memory-only payload requires a vulnerable system that can be breached:

Preventative measures begin with the attack vector -- the triggering mechanism of the exploit.

Taking the PDF example: if the user doesn't have the PDF plug-in enabled, being fooled into visiting a booby-trapped website will not trigger the exploit. No shell code can run.

regards,

-rich

 

The usual vector is opening a malicious PDF in a vulnerable Adobe Reader version. I think you are referring to a particular browser based exploit/exploit tool kit.
When you select a PDF exploit in metasploit it will create a PDF file for you which you need to send to the victim.

As Didier Stevens just posted in the meterpreter thread sandboxing (if done right, IE doesn't :/) is quite effective. Also I pointed out that HIPS and software firewalls should detect it as well if you actually start doing something with meterpreter like process migration or up/downloading files. Finally EMET blocks meterpreter from running at all (at least with the exploit I used and if configured for the targeted application)

 

Based on my own findings I'm drawn to following conclusions:

Memory only malware is has a very high cost vs gain ratio (I'm only talking about the easy stuff, metasploit and similar kits not a skilled hackers using their own code)

For a successful attack you need to pick the right target at the right time. Most exploits in metasploit are against long time patched vulns. You'd be quite effective against average users but not against the interesting targets who do have a patch policy. Against average users you use the ordinary trojans and drive bys - simpler and more effective.

Metasploit has code for a handful unpatched 0day at any given time too. The probability that you can get in is high, but then what? Usually an exploit crashes the vulnerable application. When this happens I think most users are going to try to kill the offending application, if that doesn't help they log out or even reboot. You'll be kicked of before the payload could even be loaded (which takes its time, a few seconds to a minutes if you use a very automated exploit, that is one that needs to do several checks on the target first).
Meterpreter can "migrate" but that has its problems too. It's less stealthy (HIPS, or even the user manually checking running processes) and sometimes you can't migrate at all (Adobe Reader X, Chrome, or if it detects a software firewall).
Let's assume everything went well. We exploited a Medium level process that isn't sandboxed and the user isn't running a HIPS. We migrate to explorer.exe.

As long as the user is logged on (and explorer doesn't crash) we have access to the system. Meterpreter is incredibly easy (I want to say user friendly) but still it's nothing but a very limited shell environment. If you know your target already, like where the files you want to steal are stored, you can execute a script that will do that for you, quick in and out, no one has seen anything. If not you first need to recon the system which costs precious time.

So me, thinking as a black hat, the next thing I'd do is to install a backdoor into the system, that means privilege escalation to evade other security protections like Anti-execs, AV, Sandboxes and so forth. But then we are no longer talking about script kiddies but the skilled targeted attacks that simply don't show up in any statistic.

Meterpreter is just one of many payloads, you can also use metasploit for the download exe and run it kind of attack and I think that's way more common because it's fully automated and persistent and just as effective against most targets that are vulnerable in the first place.

 

Are you saying that sending the PDF file to a victim would be a more common attack vector than sending the victim to a booby-trapped web site with the PDF file store there?

I ask this because you quote from the article the part that mentions Adobe plugin vulnerabilities, which implies a web-based attack.

Thanks,

rich

 

Yes, I think that this is more common for attacks carried out using the metasploit framework because it's much simpler to set up. You just run the script and get a PDF file as a result. To exploit the PDF plugin in the browser you'd first need to set up the website yourself. I didn't dive into metasploit enough to be sure I haven't missed such option though.

 

I remember malware (but I can't remember the exact name) that would patch a Microsoft service in memory, back to an older version that was vulnerable to remote exploits.
This gave a reliable backdoor to the authors of this malware.

 

YES & here's the confirmation !

Posted today by MrBrian

 

Thanks.

So, here web browser also has a role.

 

The way memory only malware can execute on the system without anything to stop it is what alarms me.

I have a question Rmus or Katio; Are the limited actions of Meterpreter due to their author's decisions to make it a simple payload? Or is memory only malware confined by technical limitations such as size, hence needing the download of the actual virus?

If size is not an issue then is it possible to craft a memory only malware that simulatneously runs malicious commands that could have been included in an exe instead? The memory-only design being used to evade AE tools.

 

Meterpreter is a "generic" payload: It must work for pretty much every exploit contained in metasploit. It must be small and simple so a small and simple shellcode (which often is constrained by size and other factors) can load it. But once meterpreter is loaded the attacker isn't constrained by those anymore. Meterpreter has enough functionality to launch further memory only payloads which can do anything a standalone exe could do, including allocating more memory.

However as it gets larger and more busy it becomes easier to detect. Many functions of meterpreter or whatever secondary payload is launched can be detected by firewalls and HIPS and if it wants to become persistent AE still might safe the day.

 

Are there any effective tools to counteract memory-only payloads from loading/running? I have heard of EMET? (but which is the best tool of this class, provided it doesn't cause software conflicts)

Is using safer browsers like chrome enough to stop meterpreter from keeping anything persistent on the system?

Is there many of these? if so what other examples/names of such paloads are there? - I'm talking about ones that are able to carryout more advanced attacks from memory
http://ezinearticles.com/?How-Can-I-Stop-Malware-That-Only-Lives-in-RAM?&id=4817612

This article seems to give contradicting info about the abilities of any malware that is only memory resident. Implying that all mem-only attacks are inherently limited and can't function as an actual downloaded exe. I am confused, please clarify.

 

EMET is the only tool available to mitigate memory corruption exploits besides what's already built in (ASLR, DEP, SEHOP). Well, and there's HeapLocker http://blog.didierstevens.com/programs/heaplocker/
But it's a bit more complicated to set up.

EMET takes care of incompatible software because you can disable each of its protections separately application per application.

Besides EMET running applications that are likely targeted with restricted rights greatly limits what an exploit can do. Because Chrome uses sandboxing and integrity levels it's difficult to get a reliable exploit to load meterpreter in the first place. But even in the highly improbable case that you can exploit it you'd be confined by the sandbox and couldn't do much like accessing your files, migrating to other processes, load other components and so on.

That "article" got it wrong. mem-only code can load any library available to the host application, if you tricked the user into loading a crafted file (that might have triggered the exploit) this file could already contain a library and you can simply load it. With meterpreter you can upload files to the remote system and load them.

The only limitation is that mem-only malware on its own isn't persistent. With AE it can't just write itself or a dropper into an autostart location. The only way to get around this "problem" is privilege escalation. Meterpreter/metasploit has modules for that too. If the attacker is familiar with his tools and the system is vulnerable he could circumvent AE and install a backdoor with admin rights.
Game over

 

Hello, Serapis,

In addition to considering the technical aspects of malware in memory, give some thought to the potential attack vectors for getting the malware onto your computer before it can be loaded into RAM.

The Proof of Concept designed by D. Stevens requires opening a Microsoft Excel file which then runs an embedded macro that loads the malware into memory.

Ask yourself: Under what condititions would I be inclined to open an Excel file from someone else, which could be infected with a malicious macro?

D. Stevens mentioned doing the same thing with a PDF file. So, ask yourself the same question, this time, a PDF. Or, any file type that can potentially execute code to load something into memory.

Another attack method for PDFs would be being redirected to a malicious site with an infected PDF file.

Ask yourself: Do I have the PDF plugin disabled so that the browser will not load the PDF file automatically into the browser window? If so, then the exploit cannot run, and you will see a prompt from the browser for action, at which time you will know that something is wrong, and you will Cancel the prompt.

It's fearful, indeed, to contemplate malware being loaded into RAM. Yet, a review of your policies and procedures should help alleviate this fear, for you know that you will have to be tricked before the exploit can succeed.

This, IMO, is the first step in considering a strategy for dealing with this potential exploit.

Those who succumbed to the "I-Love-You" VBS worm which arrived by email attachment would have benefited from such considerations!

regards,

-rich

 

Thank you Katio and Rmus for your helpful explanations. I intend to explain my security configuration and my use policy so that you could tell me if what I'm doing is enough or if I should consider EMET.

I basically run Chrome with all plugins disabled in a locked down sandboxie sandbox which has blocked access to java and flash. With only chrome allowed to start. I have read access to all of C:\ which stops sandboxed programs from writing any files to disk. Sandbox has DropRights enabled too. PDF reader is set as blocked filepath in this sandbox.

Seemingly this config has basically demolished any chances of a successful driveby execution scenario, leaving memory malware as my main focus. I never run untrusted exe's or anything on my system that I dont trust. fullstop.

My only attack vector would be the browser. I am bracing my system against the lethal types of drivebys that seem to plague the internet.

 

You are welcome, Serapis.

I'm not familiar with the products you use or ask about, so I'll defer comment to someone else.

regards,

-rich

 

I don't open malicious PDF's or macros of potential danger. I don't know though, can html be used to execute arbitrary code in memory like this POC?

 

If the html renderer (of your browser) has a arbitrary code exection vulnerability, yes absolutely. But as in the case of Chrome:
The already sandboxed Chrome withing sandboxie is a very strong setup and protects against meterpreter as well because as I said, the sandboxes all restrict what meterpreter can do.
Also, Chrome is designed from the ground up with security in mind (unlike all the other browsers I have to say - and I'm not a Chrome fanboy) and its track record is very strong: to my knowledge in the few years its been out there hasn't been a single remote code execution vuln been exploited in the wild.

Your browser is secure by all means but maybe your weakest link is somewhere else. Office macros are a big problem, you should disable all active x/scripting and/or run them in a sandbox too (if you open office docs from other people, including "trusted" source - who knows how secure they keep their computers...)
Other entries are media files of all kinds: mp3s, videos.
I put the media players into emet, you could sandboxie them in addition.
For PDFs I would just use the built in pdf reader of Chrome. It's the most secure pdf reader on the market as unlike Reader X its sandbox has been proven to be reliable and since it doesn't have lots of features (it's really just a "reader") the attack surface is much smaller.

If you use sandboxie make use of its additional functions. On itself it doesn't protect you from data loss, identity theft and so on. If you never clean the sandbox a persistent backdoor would be executed every time you run the sandbox. If the sandbox has full access to all your files a sandboxed attacker can still achieve whatever he came for.

 

Thank you very much Katio. Your expertise and explanation is very reassuring. I have decided to download EMET and use it for mediaplayers and office. I am curious if there are any other superior products to EMET that are in the same class (if any)?

How does EMET measure against Steve's Heaplocker? Complexity won't be an issue as I teach myself advanced configurations.

I am very interested in the security setup of a knowledgeable person like you, can you please list all the software you use so I could try to emulate your setu[p as much as possible?

 

Heaplocker and EMET aren't competitors or alternatives, they complement each other.

What's in the same "class" as EMET? Well, PAX, exec shield, W^X come to my mind: these are corresponding implementations on non Windows OSs (MS is late to the game as usual )
There are some commercial products like comodo firewall too but from what I've seen aren't really maintained and updated. To be effective however they'd need to incorporate new techniques whenever new exploit techniques are discovered. The EMET devs promised to keep adding new features, we'll see how that works out in the future but right now EMET is still very new and therefore state of the art.

One thing you should keep in mind is that EMET or similar tools can only protect against certain classes of "memory exploits". They can't protect against configuration errors, design errors, backdoors, cryptographic weaknesses etc. It's only one layer and not a panacea to security just like isolating and sandboxing alone isn't, or just patching software.

I don't think you'd be very happy about my personal setup, I've written about it in this thread:
https://www.wilderssecurity.com/showthread.php?t=291694

But here's a list of stuff I use on other systems and partially I may use myself:
EMET, MSE, Sandboxie, NoScript (+forced https), Requestpolicy, Chrome, Windows Firewall (which you can lock down in advanced settings), virustotal.com, urlvoid.com, ssh, Virtualbox and finally lots of backups.