[EP_X0FF]

New way of code inject that can be achieved without having and/or droping any additional files to disk.
Original source https://www.blackhat.com/docs/eu-17/mat ... anging.pdf

Implemenations:

Spajed version
https://github.com/Spajed/processrefund

My test version
https://gist.github.com/hfiref0x/a9911a ... daea9a177f

The code maybe bugged however it serves only proof-of-concept demonstration purpose.

They are not that much different and all based on presentation slides.

Method
advantages:
- It is relatively new;
- Can execute payload from memory (fileless);
- Zombified target process has legitimate look;
- It is Windows design feature, not a bug or vulnerability not in NTFS not in loader, nothing to fix here;
- Doesn't require admin privileges to execute.

disadvantages:
- Semi manual create process required, cannot inject in already running processes;
- Target process memory modification required;
- Create remote thread required;
- TmTx object required;
- Exotic API usage required (Windows doesn't use NtCreateProcessEx but NtCreateUserProcess instead in CreateProcess API);
- Windows 10 TH2/RS1/RS2 null pointer dereference BSOD in NtCreateProcessEx;
- Practically useless anywhere except potential malware limited usage.

I didn't tested it with any of crapware AV's available on market and don't even want to download them, so cannot confirm or deny any of "undetectable" claims from these slides.
If someone want to test some AV's - feel free to do so.

[Itachi Sempai]

could you upload exe file of that test version? i really want to test the attack but cant execute that code

[waffles2.0]

Just download from here https://github.com/Spajed/processrefund

then build and execute it as it says in the README.

[Vrtule]

nothing to fix here

Well, it seems Microsoft sort of fixed the issue (or attempted to do so at least). The Windows Defender filter driver (wdfilter.sys) blocks creation of processes with file objects being in transaction. I experienced this behavior on WIndows 10 (older versions of Windows seem "unpatched").

[Brock]

Interesting. Thanks for sharing Vrtule

[EP_X0FF]

nothing to fix here

Well, it seems Microsoft sort of fixed the issue (or attempted to do so at least). The Windows Defender filter driver (wdfilter.sys) blocks creation of processes with file objects being in transaction. I experienced this behavior on WIndows 10 (older versions of Windows seem "unpatched").

Does it drop any message or entry in WD log? Recently WD got some behavior signature (I assume via registry callback from driver) for massively abused "fileless" UAC bypass registry key.

[Vrtule]

nothing to fix here

Well, it seems Microsoft sort of fixed the issue (or attempted to do so at least). The Windows Defender filter driver (wdfilter.sys) blocks creation of processes with file objects being in transaction. I experienced this behavior on WIndows 10 (older versions of Windows seem "unpatched").

Does it drop any message or entry in WD log? Recently WD got some behavior signature (I assume via registry callback from driver) for massively abused "fileless" UAC bypass registry key.

It reports the blocking only by a call to its MpLogPrintfW roiutine.

Code: Select all

MpLogPrintfW(
      (const char *)L"[Mini-filter] Blocked transacted process creation from %wZ, parent pid: %u",
      ImageFileName,
      ParentProcessId);

I am not sure whether this message reaches any logs, howerver, the logic behind MpLogPrintfW seems quite complicated at first glance (it definitely is not a simple wrapper around DbgPrintEx).

[EP_X0FF]

That's interesting find, thanks for sharing.