DLL Injection Methods - Test Apps (Discussion)

As far as Stealth Process Hollowing (via Hotswapping Maps) technique, a point to note:

As such, it is only applicable to a limited number of Win processes.

I also view this technique in the memory injection NOP category. Someone should test HMP-A and see if it detects the activity. Also Emsisoft since it monitors unknown processes for memory modification activities.

 

Also MBAE:

https://forums.malwarebytes.com/topic/205865-malwarebytes-anti-exploit-112-build-68-released/

 

Good point, perhaps anti-exploit will detect it. About the Stackhackr discussion, I don't know why this guy is making such a big deal about it, he's being stupid. It's a simple leak-testing tool, obviously made to generate buzz.

However, it does simulate behavior that should be blocked. Actually, I hope they will spice things up a bit, perhaps they can also add code-injection and process hollowing techniques. Not to forget about keylogging, perhaps done by PowerShell. See link for more info.

https://www.barkly.com/how-stackhackr-works

 

Makes me also reflect back on RanSim:

 

Forgot about RanSim, I've read that RansomFree failed all, and AppCheck passed all tests. But I've checked out the Barkly leak-tests, the first one fails when wscript.exe is blocked, but I couldn't block the second one, I guess it tries to read process memory from lsass.exe, but not a peep from SpyShelter. Apparently Sophos InterceptX couldn't block it either, so not sure what to think. You can find the tool in the link:

https://community.sophos.com/produc...erceptx-2-0-against-barkly-malware-simulation

 

Based on this:

https://www.barkly.com/how-stackhackr-works

Appears StackHacker will just create a PPL process to simulate Lsass.exe protection. It was shown some time ago that Win 10 PPL can be bypassed. So all StackHacker is doing is executing the bypass against its test PPL process. However, lsass credentials can accesses a number of ways w/o direct memory access to lsass.exe:

Credential dumping methods: https://attack.mitre.org/wiki/Technique/T1003https://attack.mitre.org/wiki/Technique/T1003

Credential access methods: https://attack.mitre.org/wiki/Credential_Access

In regards to specifically lsass.exe credential access:

 

This one is quite interesting.

Link: https://github.com/zeroSteiner/reflective-unloader

This is a special DLL which you combine specifically with the original ReflectiveDLLInjection (https://github.com/stephenfewer/ReflectiveDLLInjection/tree/master/bin) by Stephen Fewer.

Compiled binaries: https://github.com/zeroSteiner/reflective-unloader/releases

 

https://www.wilderssecurity.com/threads/windows-defender-is-becoming-the-powerful-antivirus-that-windows-10-needs.383448/page-71#post-2755310

 

Yes. Win 10 Credential Guard will mitigate most but not all credential stealing methods.

However, it is only applicable if your system meets the following requirements:

https://docs.microsoft.com/en-us/wi...redential-guard/credential-guard-requirements

 

So Windows 10 Education supports Credential Guard, but Windows 10 Pro does not.

 

In other cases, better then enable the ASR rule below:

Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled

"Block credential stealing from the Windows local security authority subsystem (lsass.exe)"

 

Nice. So this tweaks the registry? Do you maybe know where to find the registry entry that it makes? Or is it a Group Policy setting?

 

Only applicable to Enterprise E5, Windows Defender, and Win 10 1803:

https://docs.microsoft.com/en-us/wi...-guard/attack-surface-reduction-exploit-guard

 

https://docs.microsoft.com/en-us/wi...-guard/attack-surface-reduction-exploit-guard

The rule above is for Powershell.

 

Why then the USB rule works in my W.10 home?

https://www.wilderssecurity.com/threads/windows-defender-is-becoming-the-powerful-antivirus-that-windows-10-needs.383448/page-71#post-2755310

 

Right, I understood that far. My question is whether it tweaks the registry or the group policy.
But anyways, I understand from @itman that it won't work in Win 10 Pro or Home.

 

Most likely because of this:

Test the lsass.exe protection and report back.

 

OK.
If an ASR rule works, all the others ASR rules should work.

 

Also of note is Microsoft has a test tool to evaluate attack surface reduction rules here: https://docs.microsoft.com/en-us/wi...ploit-guard/evaluate-attack-surface-reduction. It does not however contain any test scenarios for the new Win 10 1803 ASR rules.

 

We could try to insert this rule:

Rule: Block executable files from running unless they meet a prevalence, age, or trusted list criteria
This rule blocks the following file types from being run or launched unless they meet prevalence or age criteria set by admins, or they are in a trusted list or exclusion list:

• Executable files (such as .exe, .dll, or .scr)

Script files (such as a PowerShell .ps, VisualBasic .vbs, or JavaScript .js file)


if it works this too, they all ASR rules work.
But in Italy it's time to have dinner ........

 

You can't enable a feature by powershell applet, if the feature is not installed.
Each edition of Windows has a different set of features.

 

Good catch!

Here's what I get when I try to enable the lssas ASR on Win 10 1803 x(64) Home:

 

https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard

9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2