I am sure that every one of you has heard of IoCs, or Indicators of Compromise. They are the forensics that security investigators look for so they can identify the characteristics of the malicious activity that has already occurred. Some examples of IoCs are:
- Hash values of files
- IP addresses used by the attacker
- Domain names associated with the attack
- Network/host artifacts
On the AttackIQ platform, after running an assessment you can see the IoC details when you select a test on the results page. Click on any test that has run and you will find a section in the scenario details that shows the Indicators of Compromise (IoC) information. Below, you can see the IoC output for the “Dump Passwords using PwDump7” scenario. Clicking on the little magnifying glass will show you the IoC details in the STIX (Structured Threat Information eXpression) format, which grew out of the need from the security community to share information that characterizes an attack, in a standardized manner.
While IoCs are important, they are analogous to a post-mortem after the patient has died. Sure, it’s useful to know what the cause of death was, but what you really want to have is the key knowledge required to save the patient’s life. You need to be able to identify unusual behaviors in an environment that are reliable indicators that an attack is underway.
Back in 2014, Crowdstrike wrote a blog post titled “Indicators of Attack vs Indicators of Compromise.” They define an Indicator of Attack (IoA) as a series of activities that, when observed together, indicate with a high likelihood that an attack is taking place. Rather than looking at static pieces of evidence in isolation, they are looking for a sequence of activities that, taken together, can be used to infer that an attack is in progress. Carbon Black described a similar notion in their post in 2016, though they called it “Patterns of Attack” instead. Regardless of the name, almost all of today’s security technologies use some kind of behavioral heuristics to detect that malicious activity is underway and seek to disrupt or block the attack.
Here are some Indicators of Attack (IoA) that security vendors are incorporating into their detection mechanisms:
Internal hosts communicating to external servers using non-standard ports.
Most external traffic should be HTTP or HTTPS over port 80 or 443 respectively. If you detect activity from internal servers to external SMB(445), FTP(21), NET-BIOS(137), or other non-standard ports, there is a high likelihood that the attacker has co-opted the use of these ports to communicate with the malware.
Network scans from an employee’s machine.
After the initial breach, attackers are eager to look around for information they can steal. A popular mechanism is to scan for ports and discover services in the internal network. Security vendors are adding capabilities to detect port scanning type of activity and quickly take action to quarantine the compromised endpoint.
Repeat alarms from single or multiple hosts.
Repeated unsuccessful logins or a succession of logins from different hosts with the same user credentials is also a common indicator that the bad guys are at work in your enterprise. Many EDR vendors are streaming complete endpoint data and using predictive models to detect malicious behavior in the early stages of the attack.
Unusual DNS query activity.
Most large organizations have endpoints configured to query their internal DNS servers for domain name resolution. If you find that an internal host is directly querying an external DNS like 18.104.22.168 (Google DNS), that is another indication that something has run amok on that host. Another warning sign is an excessive number of DNS queries (> 1,000 queries/hour ) from a single endpoint. These point to exfiltration through DNS, which is another common way of getting sensitive information out of the enterprise.
The above items are only a sampling of the behavioral data that security vendors are now collecting and analyzing to provide an early detection system for their customers. We need to ensure that the scenarios we develop match not only the techniques of the attacker but are also accurately modeling their behavior, so we can help our customers truly evaluate the efficacy of their security controls.