Advice Request AMSI .Net and reducing the attack surface

Please provide comments and solutions that are helpful to the author of this topic.

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
.Net framework support AMSI as of 4.8 Announcing .NET Framework 4.8 Early Access build 3694 | .NET Blog

Security-wise removing older version of .net reduces the attack surface and especially removing versions before 4.8

Forgetting application which may need a specific version of .net, has anyone remove older versions of .Net? are their Windows installations having any issues because of it ?
 

MacDefender

Level 16
Verified
Top Poster
Oct 13, 2019
779
You cannot force .NET assemblies to run against a different major version of .NET — it will run against the latest patch series of the version of .NET it was built against.

As such I don’t really get the fascination with AMSI. I can always, for example, compile a copy of IronPython against an AOT linked Mono and that would basically be a standalone .NET scripting runtime that will never support AMSI.
 

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
You cannot force .NET assemblies to run against a different major version of .NET — it will run against the latest patch series of the version of .NET it was built against.

That's clear, some 3rd party applications are expected to break, are core windows services and apps working ok though ?

As such I don’t really get the fascination with AMSI. I can always, for example, compile a copy of IronPython against an AOT linked Mono and that would basically be a standalone .NET scripting runtime that will never support AMSI.

Yes - but you can always put mono runtime in a non-default path and omit it from your env variables, so that it's hard for an on-the-fly exploit to leverage it.
 
  • Like
Reactions: oldschool

MacDefender

Level 16
Verified
Top Poster
Oct 13, 2019
779
That's clear, some 3rd party applications are expected to break, are core windows services and apps working ok though ?



Yes - but you can always put mono runtime in a non-default path and omit it from your env variables, so that it's hard for an on-the-fly exploit to leverage it.

Most core Windows services are not .NET based and the ones that are rarely get updated to a new version of the .NET framework when it's not a major Windows release update.

AMSI's use case isn't really exploit blocking. It's for introspecting pseudo fileless and fileless threats. Even the article says so:
However, assemblies loaded from elsewhere, such as by using Assembly.Load(byte[]), would not be scanned and could potentially carry viruses undetected.

So it's similar to making it easier for Powershell scripts that use "eval" scan those contents, anything that's executed via eval() is passed via AMSI to scan. The .NET equivalent is calling Assembly.Load on an in memory buffer which isn't scannable by a traditional real-time file scanner.

They are not claiming this somehow makes your anti-malware part of the .NET JIT and able to introspect in real-time.
 
  • +Reputation
Reactions: oldschool

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
Most core Windows services are not .NET based and the ones that are rarely get updated to a new version of the .NET framework when it's not a major Windows release update.

AMSI's use case isn't really exploit blocking. It's for introspecting pseudo fileless and fileless threats. Even the article says so:


So it's similar to making it easier for Powershell scripts that use "eval" scan those contents, anything that's executed via eval() is passed via AMSI to scan. The .NET equivalent is calling Assembly.Load on an in memory buffer which isn't scannable by a traditional real-time file scanner.

They are not claiming this somehow makes your anti-malware part of the .NET JIT and able to introspect in real-time.

I see your point, AMSI of course can't stop an exploit, but for .net there's little it can do for the payload itself, unless in a quite low probability scenario part of the payload is already delivered as an assembly.
What about remoting in .net? these days I don't know anyone who develops using in-framework remoting as either rest calls or grpc have become industry standards but if the framework still supports remote loading, this does reduce the attack surface.
 

MacDefender

Level 16
Verified
Top Poster
Oct 13, 2019
779
I see your point, AMSI of course can't stop an exploit, but for .net there's little it can do for the payload itself, unless in a quite low probability scenario part of the payload is already delivered as an assembly.
What about remoting in .net? these days I don't know anyone who develops using in-framework remoting as either rest calls or grpc have become industry standards but if the framework still supports remote loading, this does reduce the attack surface.

Well once the framework is open-sourced, we can take a look at exactly where .NET calls out to AMSI. The API for AMSI isn't super magical, there's simply a way for an interpreter/runtime (like PowerShell or .NET) to call out to an IAMSIProvider to scan an AMSIStream* (basically a buffer). The provider can be hinted whether to consider this buffer a part of an overall session, or as a separate session. The idea being that malware that attempts to load or eval bits and pieces accumulate into the same stream and that gives a scanner a better chance of seeing the whole thing.

This is primarily a way to make fileless malware more scannable. The AMSI API doesn't really provide a way to provide more introspection into what the process is doing.

Right now it seems like the AMSI hooks are literally just on Assembly.Load with a byte array, as a way to scan .NET assemblies that aren't loaded from DLLs on disk. I mean I suppose if one were crazy enough to run a .NET service that takes in user/network input and then attempts to Assembly.Load() it as a byte array, this can stop that sort of attack, but that's a bit far fetched.

Don't get me wrong, I think it's good that AMSI is being introduced in more places. But overall the protection this provides is really minimal. AMSI is great for detecting hollow things like PowerShell, cmd.exe, or other always-available interpreters from being used to load KNOWN malware from network directly into memory. But nothing that ships with Windows uses .NET and assembly loading into memory in this manner, so it's unclear to me what kind of attack this was supposed to prevent.
 
  • Like
Reactions: oldschool

notabot

Level 15
Thread author
Verified
Oct 31, 2018
703
Well once the framework is open-sourced, we can take a look at exactly where .NET calls out to AMSI. The API for AMSI isn't super magical, there's simply a way for an interpreter/runtime (like PowerShell or .NET) to call out to an IAMSIProvider to scan an AMSIStream* (basically a buffer). The provider can be hinted whether to consider this buffer a part of an overall session, or as a separate session. The idea being that malware that attempts to load or eval bits and pieces accumulate into the same stream and that gives a scanner a better chance of seeing the whole thing.

This is primarily a way to make fileless malware more scannable. The AMSI API doesn't really provide a way to provide more introspection into what the process is doing.

Right now it seems like the AMSI hooks are literally just on Assembly.Load with a byte array, as a way to scan .NET assemblies that aren't loaded from DLLs on disk. I mean I suppose if one were crazy enough to run a .NET service that takes in user/network input and then attempts to Assembly.Load() it as a byte array, this can stop that sort of attack, but that's a bit far fetched.

Don't get me wrong, I think it's good that AMSI is being introduced in more places. But overall the protection this provides is really minimal. AMSI is great for detecting hollow things like PowerShell, cmd.exe, or other always-available interpreters from being used to load KNOWN malware from network directly into memory. But nothing that ships with Windows uses .NET and assembly loading into memory in this manner, so it's unclear to me what kind of attack this was supposed to prevent.

No what you say is correct, for .Net the added value is only for uncommon scenarios and malware authors probably have bigger fish to fry.
 
  • Like
Reactions: oldschool

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top