Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Security Apps
Microsoft Defender
AMSI .Net and reducing the attack surface
Message
<blockquote data-quote="MacDefender" data-source="post: 844624" data-attributes="member: 83059"><p>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.</p><p></p><p>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. </p><p></p><p>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.</p><p></p><p>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.</p></blockquote><p></p>
[QUOTE="MacDefender, post: 844624, member: 83059"] 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Top