In memory fileless malwar edetection ..... any antimalware software?

# For powershell bypass, just copy powershell.exe and the retrospective command
# to the same directory as the backdoor and modify the script.

He searches for a whitelisted directory where the backdoor .exe will run. Then he copies powershell.exe into the same directory. This bypasses the SRP restriction since it is set for the one in C:\Windows\System32\WindowsPowerShell\v1.0 directory. He can use the copied instance of powershell.exe to do whatever he wants.

If for some reason powershell didn't exist; couldn't be copied; or couldn't be run; he can use the backdoor to download one with limited user privileges.

 

That assumes there is somewhere he could write or copy the Powershell executable with execute privilege. On a properly locked down system, there won't be such a place. The whitelisted directories will have either execute or read/write privileges, not both at the same time.

 

And here is where the SRP bypass ends.
1. If SRP is properly configured user can't copy powershell.exe into directory where user can execute it, as MisterB pointed out.
2. Also if powershell.exe is blacklisted using hash rule it will be blocked from whatever location you want to launch it.
3. If he downloads his own copy, he again won't be able to copy it to location from where he can execute it, as pointed out in 1.
There is also an assumption that compromise already happened... A lot of assumptions and bad SRP configuration without any actual POC is what we have at the end.

 

You can hack ACL permissions again using .Net via a C# program:

https://blog.blechschmidt.saarland/get-access-to-a-protected-file-or-registry-key-in-c/
https://helgeklein.com/setacl/examples/setting-permissions-and-inheritance-from-csharp/

This will work in .Net 4 also as long a CAS policy has not been established.

 

Yes you can hack everything. But an article from your post doesn't mention this and bypass described in that article doesn't work on properly configured SRP & ACL. There is no unhackable security configuration and we can play this game of hacking/hack preventing till infinity.

 

There haven't been a lot of Group Policy bypasses in the wild because malware development is a numbers game as you well know. The numbers here are the preponderance of Home versions of Windows that do not have the GPO feature. I believe that with "whitelisting" now being in vogue, you will start seeing these bypasses appearing; especially for SRP which is outdated technology. More so by the ransomware people who definitely don't want to "take a hit" to their lucrative revenue stream.

Appears malware developers have wasted no time in capitalizing on the SRP craze though. Here is banking malware that will actually use SRP against you: http://www.zdnet.com/article/malware-uses-windows-security-feature-to-block-security-software/ . Note the following Trend Micro quote:

This is not the first time SRP has been used by malware, but Trend Micro says that the prominence of VAWTRAK attacks makes it more significant.
​

My personal opinion of whitelisting is best summed up by this article excerpt:

They found that Application Whitelisting is nothing more than a small road block much like current Anti-Virus. They found that there are some very easy ways to get around this type of software due to lack of features, lack of understanding the current threat landscape and in some cases vulnerabilities in the software that allow complete bypass. They took the audience through their testing methodology and findings. They tested Bit9 Parity 6.0.x, Microsoft AppLocker and McAfee Application control on both Windows XP and Windows 7.
http://foregroundsecurity.com/resou...hite-flag-bypassing-application-white-listing​

​

 

Hi,

This was discussed at Wilders back then, and there was confusion as to whether or not SRP was enabled prior to the infiltration of this backdoor, bkdr_vawtrak.a

Unfortunately, TrendMicro does not say.

Malware uses SRP to disable Antivirus
https://www.wilderssecurity.com/threads/malware-uses-srp-to-disable-antivirus.364898/

You have to search to find a discussion of the infection vectors:

https://www.sophos.com/en-us/medialibrary/PDFs/technical papers/sophos-vawtrak-international-crimeware-as-a-service-tpna.pdf

This is not to make light of the sophistication of this malware, but the alert reader will want to know the complete story so as to determine the weaknesses in her/his defenses.

----
rich

 

Yes, that is the name of the game, to keep it from running in the first place. And if it does get a chance of running, giving it a net of barriers to keep it from doing what it intends to do. Make privilege escalation a real complicated affair for any malware that made it though the first hoop so there will be multiple mechanisms in place to check its advance in any direction it tries to go.

The human element is really the deciding factor. Social engineering is what is used to make someone click on a link that they should have paid more attention to. I'm exposed to questionable links daily but I'm generally aware of them and I've set things up so even if I click on one, the possibility of damage is limited.

 

Per the Sophos article:

The second typical infection vector is through Exploit Kits (EK), in particular Angler EK1. In this attack scenario a previously harmless website is compromised, a malicious flash redirector is inserted into the page and traffic is sent to the EK landing page. The landing page usually contains highly obfuscated JavaScript that will attempt to exploit a vulnerability in the victim's browser or browser plugins and load Vawtrak as the payload.​

Per Dell:

The Malware adds the following files to the system:

• Angler.EK1
  
  • %Userprofile%\raxgyxjo.exe
    
  • %Userprofile%\Local Settings\Temp\6238.bat

https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=813

Note that the environment variable %Userprofile% translates to C:\Users\username ; a folder not protected by anti-execs I believe. Additionally, C:\Users\username\Local Settings is not accessible.
​

 

Also, even the static protection of CryptoPrevent Free will be able to block the launch of that malware. So, in this sense, it's a weak exploit in terms of sophistication of avoiding detection.

 

Yeah, that version of Angler pretty benign but new versions are "fileless" and anti-execs have not been very effective against them as noted by Kafeine's blog:

Faronics do not catch the 2 second call of Bedep. But only the third one, when Bedep is injected in Explorer and writing disks on Drive. Problem is that some malware are not spread with that third call (Poweliks for instance, and I guess soon or later : Phase).

http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html
​

-EDIT-

Kafeine refers to stage 3 payload of Angler. A bit more detail below. Appears it has possible intelligence to know if disk based execution will be detected and then decides to do everything in memory instead.

The third stage shellcode decodes the download binary using a static key “adR2b4nh”.

All the decision on whether to save and execute the downloaded binary or execute in-memory is all depends on the first two bytes of the download binary. If the first two bytes of the payload is “MZ” then it will write it into disk and registers the file using regsvr and continue execution. Otherwise if the first two bytes is 0x9090 then it will continue executing that buffer.

The in-memory payload is a nightmare for detection technologies that depends mostly on the file system activities.

https://hiddencodes.wordpress.com/2014/10/01/digging-deep-into-angler-fileless-exploit-delivery-2/
​

A newer variant here:

http://malware.dontneedcoffee.com/2015/07/a-fileless-ursnif-doing-some-pos.html​

 

That's my *assumption*, Pete.

----
rich

 

I used the contact form but have not received a reply.

After reviewing the blog and code again, I see that this was an in-house test, a POC. That's fine, and I know this thread is about what malware does when allowed to execute, and how it can be blocked on the system.

But I'm interested to know if such stuff, when in the wild, could get past my perimeter (what the triggering mechanism is), thus I asked for a URL to look at.

----
rich

 

First, I would like to see some tests on how effective it is. That said, let's take a look at it:

Guarded Applications

Any application that processes data or files originating from outside its host should be guarded. Applications that should be guarded include Internet-facing applications and applications that load data files that may contain malicious code. If an application is located in User-Space, applications are automatically untrusted and guarded on execution and if located in System-Space, applications can be added to the Guard List guarded on execution.​

Memory Protection

Memory Write protection prevents a Guarded Application from writing to any process's memory. Attackers seek to re-allocate memory, place executable code into the newly allocated memory, and execute it within the context of the target process.​

It is fairly obvious that problem with this protection is it is only preventing a guarded app from altering another processes memory. It is not protecting the guarded app's memory itself from being altered. Standard HIPS process modification protection is better since it will protect a targeted process against any process modifying it's memory.

However for the new "fileless malware," neither is adequate since there is no external process doing the memory modification. The memory modification is occurring within the exploited process itself which is usually the browser.

So let's look at modern consumer anti-exploit protection most of which appear to be built on Heaplocker technology:

HeapLocker uses 5 techniques to protect applications from exploitation via heap-sprays:

1.Pre-allocate pages inside the heap at application startup
2.Pre-allocate page 0
3.Monitor the process' private memory usage
4.Monitor the process' memory for NOP-sleds
5.Monitor the process' memory for a specific string

DWORD value PrivateUsageMax is used to configure technique 3: monitoring private memory usage.

When this DWORD value is defined (at application level or global level), HeapLocker will create a new thread to periodically check (every second) the value of counter PrivateUsage in PROCESS_MEMORY_COUNTERS_EX. This counter reports the size of the private memory used by the process in bytes. When a heap-spray is performed, the amount of private memory becomes very large (thousands of megabytes). When the amount of private memory is equal to or larger than the value of PrivateUsageMax (expressed in MB), HeapLocker will suspend all threads (except this monitoring thread used by HeapLocker) and warn the user that a heap-spray is probably executing. The user is offered the choice to terminate the process or continue. When the user decides to continue, the virtual memory usage monitoring is disabled.

This check is experimental and primitive, and hence prone to false positives. When a user opens many large documents at the same time, the virtual memory usage will also be large. One needs to find a high enough value for PrivateUsageMax to limit false positives without causing false negatives.​

The "rub" is in the above last paragraph that indicates monitoring private memory usage is easier said than done.

The recent articles I have read all state that the only effective way to detect memory modification is through the use of behavior monitors employing artificial intelligence. Appears some endpoint products are already doing this. EMC's ECAT product appears to have this technology. You can read about it here: https://www.emc.com/collateral/software/data-sheet/ds-ecat-final.pdf .

 

I consider third party anti-exploit software to be "grayware" in that I have never seen any tested by a main stream AV lab.

On the other hand, NSS labs this summer tested the following AV vendors exploit protection using their Cyber Advanced Warning System platform. This was an unsolicited test and NSS Labs received no compensation from any tested vendor. Using this platform, web based exploits were 24/7 continuously monitored for a 2 month period. During that time, approx. 1300 exploit attempts were made. Norton IS, Avast IS, Avira Pro, AVG, and Eset Smart Security all scored between 98 - 100% in exploit blocking capability. Eset scored the highest at 100%. The lowest scoring products were MSE at 72% and Panda at 81%.

If people want to spend additional money on untested anti-exploit products, that is their choice. I personally feel confident that Eset will protect me from exploits.

https://www.nsslabs.com/reports/categories/end-point-protection

 

This is the environment listed for the testing:

Operating System: Windows 7 Enterprise Service Pack 1 32-bit
Windows Defender disabled
Windows Firewall disabled
Browser: Internet Explorer 9.0.8.8112.16421
Smart Screen Filter disabled Application Reputation disabled
Applications: Silverlight 4.x and 5.x versionsAdobe
Flash Player 10/11 with ActiveX/10/11 Plugins
Adobe Reader 10/11 Java 6 and Java 7 versions

No indication of the privilege level the tests were run from and it is a fairly vulnerable setup overall full of vulnerable applications. IE, Java, Silverlight, Adobe Reader and Flash can all be eliminated if you want more security. IE can't be uninstalled but access to it can be removed with an ACL tweak. The only one of these that I might want to keep for access to content is Flash and I always use the version without Active X in a browser that is much more secure than IE. No Windows Firewall?? Some of the AVs tested might provide a firewall but many do not. If the exploits had this low a success rate on such systems, I don't have much concern for mine.

 

Correction - NSS didn't use the CAWS platform for these tests. To do so, they would have had to use the Network Stack Methodology 2.0 that wasn't put into production until mid-Sept.

They used an older ver. 1.5 Stack Methodology. You can read about it here: https://www.nsslabs.com/sites/default/files/public-report/files/Stack Methodology v1_5_0.pdf

BTW - I believe testing of vendor security software is free on the CAWS platform.

 

Still no mention of the privilege level these tests were run from so I assume they were run from a default Windows admin account with UAC. They look like tests run on vulnerable systems so the performance of the AVs can be isolated from other security mechanisms that should be in place if you want to have an exploit resistant system.

 

You already posted the system configuration. Only thing I see disabled is IE's Smart Screen filter which is appropriate. As far as active account in use, not sure what default is for WIN 7 Enterprise. I assume limited admin.

Again, they were testing the effectiveness of each security product in a stand alone situation. It is established practice to run with default system and browser settings.