Endpoint Security

Detecting Fileless Attacks with Enterprise EDR’s AMSI Visibility

[vc_row][vc_column][vc_column_text]If this year’s 2020 Cybersecurity Outlook Report taught us anything, it’s that defenders are seeing an increasing amount of defense evasion techniques in their environments. It’s crucial for security teams to have the granular visibility they need to spot malicious attacker behavior, however obfuscated, before it’s too late.

To combat this trend, Enterprise EDR customers are leveraging new search fields and a brand new AMSI Threat Intelligence feed delivering unparalleled visibility into in-memory attacker behaviors. This added visibility provides hand-crafted detections for a wide range of advanced attacker behavior identified by the VMware Carbon Black Threat Analysis Unit (TAU). The new AMSI data source is available to all Enterprise EDR customers running the latest Carbon Black Cloud sensor (v3.5).

Enterprise EDR customers can subscribe to the feed in the Carbon Black Cloud console by selecting Enforce from the left hand menu bar →  WatchlistsAdd watchlists (upper-right corner). Then select the AMSI Threat Intelligence feed and click Subscribe.

Our Threat Analysis Unit recommends enabling alerts for this AMSI feed. The detections in this feed cover highly suspect behaviors.

What is AMSI?

AMSI is Microsoft’s Anti-Malware Scanning Interface, a new security hook introduced in Windows 10 that endpoint vendors can leverage to inspect in-memory executions of “fileless” content. For a more detailed overview of AMSI, Microsoft has a great write-up here.

What sort of visibility does AMSI provide?

The VMware Carbon Black AMSI support will hook and provide visibility into:

PowerShell (scripts, interactive use, and dynamic code evaluation)
Example: PowerShell is loaded into another process dynamically and code is executed.

Windows Script Host (wscript.exe and cscript.exe)
w/cscript.exe executes embedded shellcode which downloads and executes a payload in memory.

User Account Control, or UAC (elevation of EXE, COM, MSI, or ActiveX installation)
UAC COM object is used for elevated code execution.

WMI Events
WMI is used to perform endpoint reconnaissance, persistence, and execution

JavaScript and VBScript
VBscript with embedded JavaScript is used to execute malicious content


Can I write my own AMSI detections?

Yes! There are a few new data facets now available on the Investigate page. Here are the different values that you can search on and what they can do:

This allows you to search on any of the content recorded via an AMSI event. This is tokenized, free form searching of the data that is recorded.

With this facet you can search on the total length of the AMSI scanned content. With malicious invocations of PowerShell, the content tends to be suspiciously long. This will allow you to detect or modify existing searches looking for those longer AMSI content lengths.

Every time the Carbon Black Cloud sensor records AMSI content it will create a hash of that script block. This then allows you to search for a specific script block invocation signature that you have identified in your environment. For example, if you find malicious behavior, you can quickly pivot to see where else that script block was executed.


Where can I see the Enterprise EDR AMSI data within the console?

AMSI data is part of process execution metadata. On the Process Analysis page, there is a new facet within the process metadata events at the bottom of the page: fileless_scriptload. This is a new generic event type added as part of the new AMSI data stream.

Just like the other process metadata events, you can expand the fileless_scriptload events to see the raw AMSI data:

Often times the fileless script event is too large to show in this view so you can click on the pop-out modal to see the entire contents of the fileless script event:

Other metadata that is captured in the fileless script events include the script length as well as the unique SHA256 hash of the fileless script event. Both of these can be used to further refine your own custom AMSI queries.


Pulling the entire AMSI script block log for further IR investigations

All AMSI content is logged locally on the endpoint in a machine-readable json format. The contents of this log contain all AMSI content seen by the sensor, including events not reported to the Carbon Black Cloud for privacy reasons. Here is an example of how the data is organized within the local AMSI sensor log:

[code lang="js"]{

   "scan_request_id": 132266028535867379,

   "psc_policy_guid": "19EF3154-298C-4257-B2E0-CB548FDD8909",

   "psc_rule_guid": "DCF71840-BFCA-4FFC-A74D-71EC237D28B6",

   "psc_rule_description": "Log AMSI Content Scan events",

   "application_path": "c:\\windows\\system32\\wscript.exe",

   "application_sha256": "47CACD60D91441137D055184614B1A418C0457992977857A76CA05C75BBC1B56",

   "amsi_application_name": "JScript",

   "amsi_content_name": "C:\\Users\\tbrady\\Documents\\cactus.js",

   "amsi_content_length_in_bytes": 1906,

   "amsi_content_sha256": "762EA2233301BD5DC61F9C569C11A5186C3D22F2A1F48785350CF033E7CFDE4A",

   "amsi_content_as_string": "_ASCIIEncoding._6002000f(\"AAEAAAD/////AQAAAAAAAAAEAQAAACJTeXN0ZW0uRGVsZWdhdGVTZXJpYWxpemF0aW9uSG9sZGVyAwAAAAhEZWxlZ2F0ZQd0YXJnZXQwB21ldGhvZDADAwMwU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcitEZWxlZ2F0ZUVudHJ5IlN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb2\");\r\n_ASCIIEncoding._60020014(\"AAEAAAD/////AQAAAAAAAAAEAQAAACJTeXN0ZW0uRGVsZWdhdGVTZXJpYWxpemF0aW9uSG9sZGVyAwAAAAhEZWxlZ2F0ZQd0YXJnZXQwB21ldGhvZDADAwMwU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcitEZWxlZ2F0ZUVudHJ5IlN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb2\");\r\n_FromBase64Transform._60020009(\"Unsupported parameter type 00002011\", \"0\", \"11972\");\r\n_MemoryStream._60020017(\"Unsupported parameter type 00002011\", \"0\", \"8979\");\r\n_MemoryStream._6002000b(\"0\");\r\n_BinaryFormatter._60020008();\r\n_BinaryFormatter._60020006(\"Unsupported parameter type 00000009\");\r\n_ArrayList._60020020(\"Unsupported parameter type 00000009\");\r\n_ArrayList._6002001b();\r\n_HeaderHandler._60020007(\"Unsupported parameter type 0000200c\");\r\n",


You can pull this local log from any endpoint that supports AMSI inspection with Live Response as well.



Which VMware Carbon Black Cloud products support AMSI visibility?
Enterprise EDR is the first product to support AMSI visibility. Customers must have the 3.5 Windows sensor deployed to record AMSI data.

Which operating systems are supported?
Endpoints must be running Windows 10 RS2 or higher for our sensors to record AMSI data.

Are you inspecting all of my private scripts and sending them to the cloud?
No, the VMware Carbon Black Cloud sensor will only report events to the cloud if they originate from an event that is NOT backed by an on disk file. So if an event is generated from a script that is on disk, its content will not be sent to the cloud. These events still reside on disk and can be pulled via Live Response as detailed above.

I thought AMSI inspects macros in Office documents? I don’t see macro events in the AMSI data.
Correct, our implementation does record macro executions, but for privacy reasons we are currently not reporting these events to our cloud. We are working on ways to bring these events to the cloud to balance customer privacy with security efficacy. You can still pull these AMSI macro events by pulling the AMSI log from the endpoint via Live Response as detailed above.

What is the AMSI data retention policy?
AMSI data captured by the Carbon Black Cloud sensor as part of process execution follows the same data retention guidelines as other Enterprise EDR processes. The local AMSI log on the endpoint remains for the life-span of the endpoint and is archived to a zip file and rolled to a new log once it reaches a certain size. Ten copies of the rolling archives are kept locally.




To learn more about how to be the best defender in 2020 check out VMware Carbon Black’s 2020 Cybersecurity Outlook Report

Read Now