Antivirus as Data Source

[dobin]

I try to apply this in relation with my project Avred (related to Antivirus signatures), and it got me thinking.

If an AV has a signature of a tool, it will be Level 2. But is it A, U, or K?

The AV itself will be an userspace application, but its usually protected by the OS, and acting upon OS file write events, so it's "secure" like K. Same if an AV or EDR is doing disk- or in-memory scanning with yara rules, what exactly is the data source? What if executed on-demand for hunting? What if the yara scanner is downloaded and executed manually and interactive by the user?

[rdunspellable]

Great questions, dobin! The answer to whether an antivirus alert, or other event, would get an A, U, or K depends on where in the OS the information is being collected. For this initial release of our methodology, we haven’t looked at many event sources yet – just Windows Audit events and Sysmon – so until we have a larger mapping of event sources to our matrix, we don’t know which column a particular sensor should be placed in. Here’s some information that may help you research the A/V software you’re studying.

You’re right that many A/V and EDR solutions have both userspace and kernel components. The key to assigning an A, U, or K is where within the OS the A/V scanner obtains its data from. Your questions touch on a few different scenarios, so let’s enumerate them and walk through the nuances:

1. The A/V subscribes to file write events provided by the OS and runs analytics against those events: a. The events come from a user-mode monitoring facility within the OS. b. The events come from a kernel-mode monitoring facility within the OS.
2. The A/V executes “on demand” scanning of files or memory: a. The A/V scans files or memory using a user-mode OS API or facility. b. The A/V scans files or memory using a kernel-mode OS API or facility. c. The A/V leverages some form of direct memory access or direct filesystem access, bypassing the OS facilities.

Before we score these scenarios, we need to keep in mind that the current version of the StP methodology does not address tampering situations, i.e., if the adversary has installed malware that "hooks" the monitoring facilities below the level where the sensor operates, the current robustness scoring cannot account for that as it introduces too many variables. So, the question of how the A/V itself is protected is out of scope for the current methodology, but it may not matter, as you’ll see in a moment.

In the cases involving user-mode facilities or events, we would assign those scenarios (1.a., 2.a.) a U. For the subscription scenario, the score is a U because the adversary could evade detection by using kernel APIs or syscalls to bypass the event being logged at the user-mode OS API. The on-demand scenario is scored as a U for a slightly different reason: we would expect that a user-mode application would not have the privileges to scan protected memory or filesystem locations, so the adversary could evade this kind of scanning by writing their malware into those locations.

The scenarios involving kernel-mode facilities or events follow the same pattern, i.e. we would assign those situations (1.b., 2.b.) a K event robustness score because the only way to evade detection (without tampering) would be to somehow go "lower" than the kernel and use direct memory access or direct filesystem access to write their material.

This brings us to the last scenario, 2.c., where the A/V itself uses direct memory or filesystem access to monitor. This use case is outside of the current robustness matrix, as it is effectively outside of the operating system’s control. We plan to extend the StP scoring matrix in several ways, including going "lower" in the levels, so we could address this use case at that point. You could score this scenario with a K, for now, as it’s the value that most closely approximates the event robustness of this data.

Regarding yara, if the user downloaded it and ran it on-demand, we would score it the same way as the A/V on-demand scan, and have to ask the same questions – what facilities does it use to obtain its data and what are its privileges for reading memory or the filesystem directly?

Beyond the scoring, your questions touched on a couple interesting nuances that aren’t addressed in the current methodology, but we are noting them for research in future StP updates. First, the question of access privileges of the event source and the adversary are potentially other dimensions of robustness vs evadability that are worth scoring. Second, the question of how data is collected – event subscriptions versus “polling” or on-demand scanning – may have some implications for evadability that we should tease out.

I hope this explanation helps you and thank you so much for your questions!

[dobin]

Thanks for the detailed answer! It is indeed an interesting question to think about.

I would come to a different conclusion tho. Especially as tampering is excluded.

The A/U/K level is being used to show the "trustworthyness" of the data. Lower levels can be bypassed by the attacker using higher A/U/K level techniques (which are more "low level" to the OS). By chance, it matched the Application/Usermode/Kernelmode layers, but i think this is more by accident.

An AV usually consists of three components: 1) The actual high privileged AV scanner process (with the signatures), maybe PPL'd 2) A kernel component feeding/calling the high privileged AV events of file writes/openings (AMSI or similar) 3) A userspace GUI component interacting with the high-privileges AV process (on-demand scans)

How can an attacker bypass AV scans when writing files? I say he cannot! Files are written on the file system, the kernel always gets the file events. There is no "lower level" where an attacker can write files on a filesystem without the kernel knowing, by definition. And if there is, he will not be able to use it, e.g. to execute malware. Afaik there is no technique to bypass the file event writes, therefore AV scans are always K. Where/how the actual signature scan is being performed (userspace, PPL'd process, or even on another server) doesnt matter, as the "orchestrator" is always the kernel.

(note that there may be techinques to open a NTFS volume as RAW, and manually write a file, not triggering the kernel callbacks. But that file has to be read/execute sooner or later with normal kernel functionality, or it wont be useful really. Except to hide data, but we talk about signatures of programs).

As examples:

In case of a user-executed usermode yara-scanner with low privileges ("./yara-scan c:*"), it is easily bypassed by an attacker by setting the file permissions restrictively (e.g. only readable to SYSTEM). It is clearly A.

In case of a user-executed usermode yara-scanner with high privileges (local admin) ("sudo ./yara-scan c:*"), it may be possible to hide files from it with some trickery. So maybe its a U.

A low-privileged user-initiated yara scan from a UI window, using a high-privileged process to scan a file system by querying the OS about all existing files, is probably like a K. An attacker can tamper with the UI, but this is excluded.

A yara scanner initiated by file writes from the kernel, but running as a usermode process, is still a K.

Once we include tampering, an attacker wigh high-privileges in usermode can just kill the AV process. Or backdoor the AV GUI. So in that case the complete event source chain with all involved systems have to be considered.