Advice Request AMSI PowerShell Basic Test

[509322]

Invoke-Mimikatz.ps1

1. Copy-paste into Administrator PowerShell > blocked from running in-memory (NOTE reference to detection via AMSI)

2. Right-click > Run as administrator > blocked upon access (NOTE no reference to AMSI)

3. Double-click on Desktop > blocked upon access (NOTE no reference to AMSI)

NOTE the difference signatures, dependent upon how executed.

 

[shmu26]

So it looks like even Windows Defender doesn't know how to implement AMSI right.

 

[509322]

So it looks like even Windows Defender doesn't know how to implement AMSI right.

Microsoft AMSI is good. They are just using different names\signatures based upon where the code is launched from.

 

[Eddie Morra]

So it looks like even Windows Defender doesn't know how to implement AMSI right.

Microsoft's Windows Defender Team are the only team which know exactly how to implement AMSI properly along with having access to all of the knowledge on what can go wrong and what will or won't trigger it... unless you reverse-engineer everything and even then you may have missed something.

Microsoft intentionally withhold documentation and it causes third-parties to become confused. This can lead to improper implementations which are unreliable and unstable in the long-run and cause an unknown number of issues. It's Microsoft's fault. The public documentation may as well not exist at all in its current state because it's absolutely atrocious - it isn't very descriptive at all and this isn't helpful on any level.

It's a pathetic state of affairs.

Anyway... here is some information from me that may help you guys. Note, this information is from my own experience and may be inaccurate for Windows Defender's case specifically (since I do not have Windows Defender insider knowledge).

1. When you open PowerShell yourself, that triggers AMSI. When you try to execute any scripts by typing/copy-pasting and entering them, that also triggers AMSI.

2. If you open a PowerShell script from a file and then it loads in PowerShell, this will trigger AMSI as well. The same as #1 will trigger AMSI.

However, Windows Defender also supports on-execution scanning, and if PowerShell is included for this... then this will happen before AMSI can be triggered (because it'd be before PowerShell actually tries to execute the script - AMSI doesn't let you scan the original script, it scans the interpreters version which means obfuscation is also defeated).

Therefore, I suspect what is going on here is the normal Windows Defender scanning engine is identifying the PowerShell script for the non-AMSI detection's. At this point, AMSI scanning probably hasn't even been included for that session unless PowerShell has actually tried to execute the script, since it'd be scanning earlier before this point. The first test which had the AMSI detection would have triggered AMSI but it wouldn't have triggered the normal Windows Defender scanning engines (e.g. for on-execution).

 

[Eddie Morra]

Therefore, I suspect what is going on here is the normal Windows Defender scanning engine is identifying the PowerShell script for the non-AMSI detection's. At this point, AMSI scanning probably hasn't even been included for that session unless PowerShell has actually tried to execute the script, since it'd be scanning earlier before this point. The first test which had the AMSI detection would have triggered AMSI but it wouldn't have triggered the normal Windows Defender scanning engines (e.g. for on-execution).

This makes more sense when you take into account that the AMSI detection for the "Affected Items" isn't referencing the file-name of the PowerShell script (e.g. "C:\Users\Lockdown\Desktop\Test.ps1" and "C:\Users\Lockdown\Desktop\Invoke-Mimikatz.ps1").

I am pretty sure that such information isn't provided through AMSI because you won't be told the file path to the script on-disk, you are just handed the script (e.g. in a stream) to scan it yourself when you're acting as a provider for scanning objects. At-least, I've not yet seen such information provided via IAntimalwareProvider yet... then again, the documentation is incredibly small and simple, so who knows.

However, for things like on-execution scanning, Windows Defender would indeed be aware of such information (e.g. the location of the object on the file-system) because obviously such information would be vital for the normal scanning engine to intervene.

Windows Defender has on-execution scanning support from kernel-mode the same way other vendors do. They use kernel-mode callbacks like PsSetCreateProcessNotifyRoutine/Ex among others... and also have file-system monitoring support the same way other vendors do through interacting with the Filter Manager (fltMgr.sys) with FltRegisterFilter.

That being said, in the last test from the original post, the "\Device\HarddiskVolume4\..." formatting indicates the information came from a kernel-mode callback as part of an on-access/on-execution implementation. The formatting isn't DOS like in user-mode (and AMSI is user-mode based).

 

[shmu26]

Microsoft's Windows Defender Team are the only team which know exactly how to implement AMSI properly along with having access to all of the knowledge on what can go wrong and what will or won't trigger it... unless you reverse-engineer everything and even then you may have missed something.

Microsoft intentionally withhold documentation and it causes third-parties to become confused. This can lead to improper implementations which are unreliable and unstable in the long-run and cause an unknown number of issues. It's Microsoft's fault. The public documentation may as well not exist at all in its current state because it's absolutely atrocious - it isn't very descriptive at all and this isn't helpful on any level.

It's a pathetic state of affairs.

Anyway... here is some information from me that may help you guys. Note, this information is from my own experience and may be inaccurate for Windows Defender's case specifically (since I do not have Windows Defender insider knowledge).

1. When you open PowerShell yourself, that triggers AMSI. When you try to execute any scripts by typing/copy-pasting and entering them, that also triggers AMSI.

2. If you open a PowerShell script from a file and then it loads in PowerShell, this will trigger AMSI as well. The same as #1 will trigger AMSI.

However, Windows Defender also supports on-execution scanning, and if PowerShell is included for this... then this will happen before AMSI can be triggered (because it'd be before PowerShell actually tries to execute the script - AMSI doesn't let you scan the original script, it scans the interpreters version which means obfuscation is also defeated).

Therefore, I suspect what is going on here is the normal Windows Defender scanning engine is identifying the PowerShell script for the non-AMSI detection's. At this point, AMSI scanning probably hasn't even been included for that session unless PowerShell has actually tried to execute the script, since it'd be scanning earlier before this point. The first test which had the AMSI detection would have triggered AMSI but it wouldn't have triggered the normal Windows Defender scanning engines (e.g. for on-execution).

So in simple language, in the last 2 tests Windows Defender standard detection caught the malicious script before AMSI, and that's why we don't see an AMSI detection?

 

[Eddie Morra]

So in simple language, in the last 2 tests Windows Defender standard detection caught the malicious script before AMSI, and that's why we don't see an AMSI detection?

That is what I suspect, yes.

Try and see if the same scripts which were blocked without the AMSI detection name are blocked by Windows Defender on Windows 8.1 as well... that might be an easy way to confirm without reverse-engineering. Since Windows 8.1 doesn't have AMSI, it's a Windows 10-only feature.