BIOC vs IOC
- Idan Buller
- Oct 28, 2020
- 6 min read
Updated: Dec 27, 2020
Intro
Indicators of compromise is a subject we encounter in our daily lives in the cybersecurity field. As a soc analyst, we must use these to improve your monitoring process. As security researchers, we must use them to manage the malware analysis process as reliable as possible. As an IR analyst, we must use them to verify file integrity and so on…
If we want to define them, Indicators of compromise (IOCs) serve as forensic evidence for potential intrusions on a host system or network. These artifacts enable information security professionals and system administrators to detect & prevent intrusion attempts or other known malicious activities. Security researchers use IOCs to better analyze a particular malware’s techniques and behaviors. IOCs also provides actionable threat intelligence that can be shared within the community to further improve an organization’s incident response and remediation strategies.
Some of these artifacts are found on event logs in the security system, as well as on its applications and services. Security and IT professionals also employ various tools that monitor IOCs to help mitigate, if not prevent, breaches, or attacks.
Some of the well-known example for IOC:
File Hash
File Name
Full Path
Source/Destination IP Address
Domain Name
Behavioral Based Indicators of Compromise (BIOCs), allowing analysts at any expertise level to configure and tune behavioral rules and optimize the ongoing detection of recurring attacks on a host system or network. These features block malicious activities and behavioral patterns as well as other harmful processes before they can do damage to the organization.
Some of the well-known example for BIOC:
Process, execution & injection.
File creation, editing, reading, and deleting.
Network – outgoing & incoming
Registry HIVES – Writing, renaming, and deleting by value path and data.
IOC - pro's & con's
Pros:
Reliable and verify –
With the help of IOCs, network defenders are able to detect & prevent with high precision thanks to these artifacts being injective, which leads us to the next pro.
Injective –
For each and every IOC possibility, the IOC is the only value you can get. Which means that there can be at most one element for the entity we want to detect.
In mathematics, Injective means we won't have two or more "A"s pointing to the same "B", and that is the exact definition of a reliable IOCs.
Cons:
Static –
For an effective network defending relying on IOCs, we will need to be updated constantly on the most dangerous and newest cyber risk around the cyber field. For that we can use many security add-ons and third parties to our security systems, for example, Virus Total, Alien Vault, etc. or keep being updated be yourself, and this process will take many resources for the security teams.
Can be changed easily –
In the cyber filed injective indicators can be changed easily, by adding a ‘space’ or changing the Domain name. For this Proof of concept, I made this example:
As we can see, the moment we added a ‘space’ into the file, the hashing algorithm calculated a different hash.
Examples:
For example, we chose the new variant of cryptojacking malware named Black-T (for more info, link). Among other things, this malware uses three different network scanning tools to identify additional exposed Docker daemon APIs, within the local network of the compromised system and across any number of publicly accessible networks, to extend their cryptojacking operations.
As network defenders, we would like to monitor the relevant IOCs to detect this malware’s TTP –
URLs:
hxxps://teamtnt[.]red
hxxps://teamtnt[.]red/BLACK-T/beta
hxxps://teamtnt[.]red/BLACK-T/CleanUpThisBox
hxxps://teamtnt[.]red/BLACK-T/setup/bd
hxxps://teamtnt[.]red/BLACK-T/setup/docker-update
……………..
File Hashes:
90c74c9ff4c502e155d2dc72f3f6c3f512d354d71b5c480c89b6c1b1852bcb1f
1cf803a8dd2a41c4b976106b0ceb2376f46bafddeafbcef6ff0c312fc78e09da
a5dd446b2a7b8cfd6b6fd4047cc2fddfcea3a4865d8069dcd661e422046de2a1
………………
BIOC - pro's & con's
Pros:
Flexible –
With the help of BIOCs, a network defender will be able to detect behavioral-based activity Regardless of the names/ addresses/ hashes of the activity origin.
The behavioral-based IOC will monitor any kind of activity based on pre-configured OS artifacts.
Able to block malicious activity before it damaged the network –
As the BIOCs reduce the inflexibility of the IOC, we will be able to prevent a malicious activity before it even started or caused real damage to the network by blocking the activity when it started.
Cons:
Dement effort, human source, and betterment –
This kind of defense rules based on OS processes, registry HIVES, etc. which are usually considered as a more intermediate level of understanding. A good BOIC rule demands a lot of time thinking and understanding the malicious activity and human resources should be more experienced.
Examples:
As an example of a complex behavioral indicator, consider the following.
An adversary is identified that tends to rely on “spear phished” email attachments. The emails tend to come from a specific range of IP space. When the attachment is executed, a curl request is executed and the dropper malware gains persistence by writing to specific registry keys and then installs a PoisonIvy variant.
Network [OUTGOING, INCOMING] AND Source AND Local IP != 192.168.* AND Process [curl.exe , wget.exe]
Inside my EDR system, I have this rule that prevents the curl.exe entity to perform an outgoing/incoming network request. By that, I prevented a malicious activity regardless of the C&C server IP address, etc.
Tools
In this section of the article, I am going to introduce you to a few tools that can level-up your understanding and hands-on skills.
Atomic Red Canary
An open-source project maintained by the Red Canary team is a collection of scripts that can be used to test how you might detect certain techniques and procedures mapped to ATT&CK techniques. The best part here is that the ATT&CK techniques are followed by defense rules related to APT groups.
For example, we will demonstrate a full process of the tool capabilities:
· The tool’s execution framework can execute many attack techniques sorted by ATT&CK ID.
· For this example, we will take a look at ‘T1571 - Non-Standard Port’, that using a protocol and port paring that are typically not associated.
Inside the readme file, we can see the exact payload used in the Proof of concept –
Test-NetConnection -ComputerName #{domain} -port #{port}
· For every ‘atomic’, we can .yaml file to implement a defense rule fits to the ATT&CK technique we executed –
Sigma
Sigma is an open-source project to create a generic signature format for SIEM systems. The common analogy is that Sigma is the log file equivalent of what Snort is to IDS and what YARA is for file-based malware detection. However, unlike Snort and Yara, support for Sigma does not have to be built into each application.
With the help of Sigma, we can use the defense rules list and convert them to, for example:
1. Elastic search queries
2. Splunk searches
Etc.
For example, we will demonstrate a full process of the tool capabilities:
1. We can check the defense rules list ./rules in the main GitHub page and will choose one for the POC – generic_brute_force.yml
2. Convert the .yaml file to Splunk rule with the help of the tool – sigmac –
The project is still supported, and the defense rules list is still up to date.
Virus Total
There is no need to go into details with VirusTotal, one of the most well-known projects, aggregates many antivirus products and online scan engines to check for IOCs that pulled the user's own security systems and event logs. This search engine contains multiple features for searching and uploading IOCs and test their maliciousness.
With the help of the Virus Total API, we may upload and scan files or URLs, access finished scan reports and make automatic comments, etc. In other words, it allows us to build simple scripts to access the information generated by VirusTotal.
Here is some tool I created to make my life easier in the process –
Yara rules
YARA is a powerful and flexible pattern matching tool. These rules are running from a command line on Linux and Windows, which is handy when you are working locally on reverse engineering or incident response procedures.
Because YARA is extremely flexible, it can be targeted to find a specific file hash on a web server or to broadly detect a certain file type across multiple systems.
Most of the advanced EDR solutions allow the implementation of this kind of rules into the monitoring process.
For this example, we will demonstrate an example rule and it’s capabilities with the help of the open-source project ‘Yara-Rules’ (https://github.com/Yara-Rules):
This .yar file is responsible for catching a well-known Chinese autospreader webshell, that exploits PHP based servers –
Conclusion
To sum things up, both types of defense rules are extremely important in the network defense process, and even better, the mix of them creates good protection layers. These rules must be updated daily and to be part of the security systems in our network, with the help of human sources, built-in features, and third-party services.
Atomic Red Canary, Sigma, VirusTotal, and YARA rules are the tip of the iceberg.
Comments