Thread by @Purp1eW0lf

This is a cool bit of offensive Nim from @WhyDee86

Let's unravel this from a Defenders point of view 🧵

We'll start with some basic reverse engineering analysis, and then move into monitoring this from an ELK stack

TLDR: A decent SIEM setup will catch this.

Let's start off by compiling it.

We'll then analyse it like we don't know the source code, and we're investigating malware on a machine.

If your compile fails, you'll likely need to download winim library.

[Winim github.com/khchen/winim#i…]

First, let's throw StringSifter at the EXE.

What catches my eye are the ranked strings to do with NIM as well as the AMSI DLL reference.

From a basic strings, I'd already be sus of an unknown EXE like this on a host.

[StringSifter github.com/mandiant/strin…]

Getting Capa's opinion isn't too enlightening for this EXE.

It does highlight that the EXE is Nim-based, which is nice I guess?

Capa is (usually) great for getting a heads up on what an EXE is going to do; a sketch of the battlefield ahead.

[Capa github.com/mandiant/capa]

MalAPIReader pulls out the APIs in the binary.

It lets us know it's likely going to mess around with some of the processes on our host.

Like Capa, MalAPIReader is useful to know what you're up against.

[MalAPIReader github.com/HuskyHacks/Mal…]
[MalAPI malapi.io]

Alright, let's pit the EXE against Defender.

Interestingly, Defender calls StartCleanPs.exe out as malicious straight away.

But let's go on and assume an adversary will get this executed on the host somehow, eventually.

Okay let's move on to some dynamic monitoring.

We trigger AMSI to check it's working, and then we can fire StartCleanPs.exe off.

After a successful execution, we have a PowerShell prompt that is free of AMSI restrictions.

[AMSI docs.microsoft.com/en-us/windows/…]

In the PowerShell gifted by StartCleanPs.exe, l et's open up calc.

This is so we have a possible artefact in the logs, which will make a good starting point to work backwards from when we look next at our SIEM.

We'll assume we had Sysmon and an ELK stack, to enhance security monitoring.

From ELK, the initialisation by StartCleanPS.exe is clear to see. And the resulting PowerShell is very visible.

[Sysmon docs.microsoft.com/en-us/sysinter…]
[Florian's config github.com/Neo23x0/sysmon…]

The start-up for PowerShell is noisy AF

Notice StartCleanPS terminating. It is an unknown parent process for PowerShell to begin with, but it's even stranger that parent instantly terminates (EventID 5)

Hard to detect true positives this way, IMO. Lots of things start PwSh.

If we use a debugger to control the tempo of StartCleanPS.exe, we can dig deeper into the process tree

In the first image, we can see how the PowerShell clearly belongs to the malicious EXE. In the second image, the EXE is nowhere to be seen.

[x64Debug x64dbg.com]

Back to ELK, we can identify our child calc spawning from the AMSI-free PowerShell.

The adversary can now execute malicious stuff from that shell.

But, as we have demonstrated, your SIEM is not blind to this activity.

Configure your ELK to really dig deep on process trees.

Yes threat actors can disown parent processes, but 90% of the adversaries (I encounter) just don't.

So tune and filter your SIEM, so you are familiar with the processes that spawn PowerShell, or Cmd, and other things!

Likely missed some obvious stuff here. I'll appreciate any other defensive insight on this.

Thanks again to @WhyDee86 , I hope you didn't mind that I spoiled some of the Red team fun by partially unravelling SmartCleanPS.

*StartCleanPS 😞