Indicator of Attack – What comes before a good old indicator? 

By Emad Haffar, Head of Technical Experts for the META region at Kaspersky & Damir Shaykhelislamov, Advanced Threat Protection Solutions Manager at Kaspersky.

Cyberthreat detection has always been a trade-off between speed, accuracy, threat coverage, and the amount of information required to verify the security verdict.

The indicators of compromise (IoC) is one of the core aspects of cyber threat intelligence. Observable artifacts pointing to the presence of specific adversarial activities in the network infrastructure is what best describes IoC.

The simplicity of the concept itself and a variety of precise indicators (atomic or computed, network or host-based) presented as IP addresses, DNS names, JA3 TLS fingerprints, registry entries, or cryptographic hashes, along with the presence of numerous cyberthreat intelligence tools, open-source feeds, and exchange standards (STIX, Yara, OpenIOC) make them easily distributed, and digested by any automated technology (EDR/XDR, SIEM, NGFW, etc.).

However, despite being the most shared type of threat information, the operational limit of main IoC types (especially in combating complex threats) can be characterised by the attacker’s low to moderate ease to evade defenders’ detection capability. This is done by recompiling the code, modifying binary timestamps, changing URLs, etc. that usually results in IoC’s short lifespan and high false positive rate.

From the attacker’s perspective, a good example of how to evade the IoC-based detection is by taking advantage of Domain Generation Algorithms used to generate pseudo-random domain names. These names are often used to establish more robust communications with the attacker’s command and control (C2) servers. From the defenders’ standpoint, this fact means blocking domains is an endless task, let alone being close to impossible to timely and effectively track.

Such a fundamental weakness of using low-level indicators was illustrated by the concept of the “Pyramid of Pain” presented by David J. Bianco almost ten years ago.

The static nature of IoC-based detection and the post-breach view of the incident deprive the security analysts of the ability to examine what is happening behind the scenes when the attack is in progress. The widespread “fileless” persistence mechanisms (PowerShell, WMI, etc.) utilised by modern evasive malware, also lead to more meaningless forensic artifacts and observables, which make simple IoCs of little help.

Hunting down suspicious behaviour

As every activity on the enterprise infrastructure leaves its mark – and malicious cyber operations are not an exception – automating the process of spotting how attackers are switching between a variety of offensive tactics, techniques, and procedures (TTP) and raising corresponding red flags is a key step to keep up with a modern threat landscape.

The call for a new (proactive and more dynamic as opposed to traditional) detection approach was heard by the security industry. Today, the concept of threat indicators has dramatically evolved, making them more concerned with capturing behavioural characteristics and patterns of attack than solid and static artifacts.

These behaviour-based indicators, representing the attacker’s modus operandi, received the term Indicators of Attack (IoA); they enabled enhanced visibility of malicious techniques used during various phases of the attack cycle – from discovery to data exfiltration. For instance, the evidence of grabbing NTLM hashes by dumping the lsass.exe process followed by the subsequent execution of PowerShell script (with a hash value as a launch parameter) can be indicative of the pass-the-hash technique used to bypass normal access controls and move laterally through the infrastructure.

Looking at the screenshot above, alerts that are raised based on IoA detections signifying bad or suspicious symptoms will be extremely helpful to security officers. When dealing with some devastating human-operated ransomware attacks, the ability to spot the signs of compromise long before the encryption process starts could be invaluable to timely cure the systems affected.

Less fragile from a defender’s standpoint and hardest to dodge by attackers, IoA-based detection logic incorporated into threat protection technology stack helps to enrich the overall context of the threat actor’s ultimate intent. It also ensures coverage of detection for wider clusters of malicious objects, and defines rapid remediation efforts.

The concept has found its special recognition and become the key driving force in Endpoint Detection and Response (EDR), emerging Extended Detection and Response (XDR), SIEM tools, and security service offerings such as Managed Detection and Response (MDR).

IoA’s are highly instrumental when hunting for the heavily leveraged  “living off the land” techniques. In their attempts to evade detection and ‘blend in’, attackers exploit trusted, legitimate, and dual-use OS tools ( scripting engines, binary utilities, etc.) to blind monitoring solutions and get off the security radars.

No matter the OS, the range of actions available at the post-exploitation phase is enormously wide – whether it is the creation of new user accounts, deleting disk shadow copies, or attempts to disable existing security mechanisms – a carefully created IoA rules can alert for any suspicious sequence of events covering a wide range of scenarios.

Due to the probabilistic nature of the detection process, not all IoA-triggered events shall be treated with equal importance. Using netsh.exe utility to add some local firewall rule exception or using schtasks task scheduler can be considered as a weaker signal in comparison with attempts to execute highly obfuscated Powershell scripts (MITRE T1027) or patterns known to dumping credentials from lsass process memory (MITRE T1003). Therefore, assigning an indicator’s severity level based on expert-opinion (by the rule vendor or the user) is essential for an adequate alert triage process and to achieve optimum resource allocation tactics.

Provided that sufficient coverage by regularly updated IoA ruleset exists, the chances of raising attention of the defenders as a threat actor progresses and attempts to maintain their persistent within the infrastructure are quite high.

What are the requirements to implement effective behavioural detection?

Data acquisition and processing

Firstly, detecting attack patterns using IoA requires  acquiring and storing raw telemetry/log data from all relevant sources. Filtering and aligning event data to a common format (normalisation) is required – depending on the used tools, each vendor specifies the optimal amount of data and normalisation standards. As part of the process, the IoA engine queries the current event repository and extracts actionable intelligence in the form of tactics, techniques, and procedures.

Multi-source signals

When addressing some targeted and sophisticated campaigns, no event could be strong enough to diagnose the threat scope, thus correlation of multiple signals (sometimes ‘weak’ to confidently raise a single incident) is required for further investigation. Using endpoint, network, or cloud sources for IoA rule engineering is the key to recognizing hidden, and temporal dependencies between seemingly unrelated activities.

Retention and retrospective analysis

The duration of cyber-offense operations could be lengthy, so long-term retention of historical telemetry data () can be a good practice to be able to look backward for detection of previously unseen threat activities by re-applying a regularly updated set of IoA rules.

Data exchange

The intelligence lifecycle is unthinkable without the phase of distribution of actionable threat-related data across other interest groups (in our case, machine-readable behavioural rules). Traditionally, when describing IoA rules, security vendors tend to define their specification language and sharing schemes – the lack of easily adoptable and commonly accepted standard presents a challenge for the industry, so further unification efforts (e.g., SIGMA language) seem promising.

Tailoring behaviour indicators to current infrastructure

Each organisation is unique and local context matters when talking about targeted attacks. Although an ever-growing industry-recognised knowledge base of adversarial tactics and techniques (such as MITRE ATT&CK) is incorporated into a great number of out-of-the-box vendor rules, the ability to extract additional detection opportunities from practical observations, and produce its own set of indicators is a great way to perform hunting activities more effectively.

Whether it would be the uploads of code fragments to the Github repository, execution of some binaries not used in practice by the DevOps team, policy violations, or tracking some previously unseen Command & Control beaconing patterns – using IoA, the analyst can establish detection engineering process and automate testing of detection hypotheses. The latter requires specific expertise in place for proper tuning.

The ability to set the exceptions and temporarily disable certain behavioural indicators from the processing might also be a reasonable step in efforts to minimise the overall noise level, e.g., whitelisting of activities associated with specific administration tools.

We should remember there is always room for further automation – whether it will be adding more log sources, creating a global and shareable repository of indicators, or applying machine learning techniques to detections to enhance an alert confidence scoring.

Summary

Behavioural correlation of events from multiple sources helps to act faster, get more attack context and start looking for previously unseen activities.

None of the detection technologies and approaches shall be considered a silver bullet. Being the most trivial threat intelligence unit, the significance of using classic indicators of compromise should not be undervalued – atomic indicators are precise, easy to apply, share, and multiple machine-readable formats are available. Not so many organisations use even this form of threat data efficiently.

The following comparison matrix highlighting key features of detection approaches, demonstrates that taking the best of both methods is required to better understand an attacker’s tradecraft.