Level 3: Core to Pre-Existing Tools or Inside Boundary
Description: Observables associated with a tool or functionality that existed on the system pre-compromise, may be managed by the defending organization, and is difficult for an adversary to modify.
Why are tools split between adversary-brought and pre-existing?
Pre-existing tools provide less flexibility to adversaries than tools that are brought by an adversary, as an adversary must behave and act with what is available to them through the tool. The configurations, command-line arguments, and other observables for this level will remain consistent with what is available for the tool.
Since the adversary cannot change the capability because it is managed by an organization, it is much more difficult to distinguish adversary use from benign use. This provides an opportunity for an adversary to blend into the computing environment, also known as a Living off the Land (LotL) attack 1 2. It is likely that analytics utilizing native tool observables will need to be combined with other observables at other levels or require further research into low-variance behaviors of abusing these tools through MITRE ATT&CK techniques.
Why are detections between the inside and outside boundaries split?
Detections are split between the inside and outside boundaries because the analytic robustness is greatly dependent on whether the adversary controls one or both endpoints in a network connection. For example, given a network connection that extends outside the defender’s boundary, such as to an endpoint somewhere on the public internet, we presume that the adversary has control over both the external endpoint and the internal, compromised endpoint. If the adversary has control of both endpoints, then they have the advantage and the flexibility to configure the tool or network connection, such as encryption, obfuscation, and so on, and change implementations to meet their specific needs, which lowers the analytic robustness to Level 2: Core to Adversary-Brought Tool or Outside Boundary.
On the other hand, if a network connection stays inside the defender’s boundary, then the analytic robustness depends on the ATT&CK tactic or phase of the adversary’s cyber operation. If the network connection is for the purpose of lateral movement or remote execution, then the adversary controls only the originator endpoint and has not yet achieved control of the target endpoint. The analytic robustness would improve to Level 3: Core to Pre-Existing Tools or Inside Boundary because the adversary must behave and act with what is available to them through network protocols, operating systems, and applications running on the target endpoint.
What is the difference between Ephemeral observables and Core to Pre-Existing Tool observables?
Some observables that may seem to have Level 1 (Ephemeral) properties may be classified as Level 3 (Core to Pre-Existing Tools or Inside Boundary) if they meet certain conditions, notably if they are key to the operation of the attack and not able to be modified at that point in the attack chain. For example, while an “Image” is an Ephemeral observable, a “TargetImage” value can be deemed Core to Pre-Existing Tools when it is a key component of the program’s function and at the point where it is being detected (e.g., in Sysmon EID 10), and thus it is not directly accessible for change by the adversary. To evade detection would require the adversary to have already accessed and modified the value. Additionally, a Level 1 value can move up to a Level 3 value if the value itself is critical for the functioning of the program. For example, a specific filename, including a file path, that is in the environment would be considered a Level 3.
Examples: Signatures, command-line arguments, tool-specific configurations, metadata, binaries
Note
These observables may change as pre-existing tools present in the environment change.
Observables
Category |
Observables |
Generating Activity |
Evade Behavior |
|---|---|---|---|
Command-Line Arguments |
CommandLine (Sysmon)
Process Command Line (EID)
ParentCommandLine (Sysmon)
|
Built into the tool to identify different functionalities, be called by a tool or scripts, or be called by an interactive sessions with a user. |
Change the tool or configuration that has different command-line arguments. |
Process Creation |
OriginalFileName (Sysmon)
|
Filename is embedded into the PE header of a tool. |
Use a tool with a different filename or edit the PE header |
Signatures |
Signature (Sysmon)
SignatureStatus (Sysmon)
link_target (Sysmon)
|
||
Tool-Specific Configurations |
Integrity Level (Sysmon)
Mandatory Label (EID)
Token Elevation Type (EID)
Access Level (EID)
File Path Outside Adversary
Control
|
A recommendation for setting up and using tools that support processing of information. 3 |
Pivot to tool or raise permissions to avoid alerts on a specific-configuration. |
User Session |
Login Type (EID)
Login successful (EID)
|
A user log ons to a profile or application 4 |
Log in to application or user with a different logon type 5 |
Authentication |
Auth Service (CAR)
Decision Reason (CAR)
Method (CAR)
|
||
Network Connection |
Originator IP Address
Responder IP Address
TCP/UDP Ports
Inbound/Outbound
Process Name
Process ID
User Account
|
The adversary initiates an activity on the originator endpoint that results in a network connection to another endpoint. |
For Inside Boundary, if the adversary controls only the originator endpoint and not the responder endpoint, then this observable would not be evadable when observed on the responder endpoint. |
Named Pipe Connection |
Pipe Name
Originator IP Address
Originator Port
Process Name
Process ID
User Account
User Account
|
The adversary initiates an activity on the originator endpoint that results in a network connection to a named pipe on another endpoint. |
For Inside Boundary, if the adversary controls only the originator endpoint and not the responder endpoint, then this observable would not be evadable when observed on the responder endpoint. |
References