1) Incident Response Process
2) IoC Basic
0x02. IoC - Eye oh See
1) IoC Conversion in Using Process
2) IoC Evaluation
3) How to divide IoC
0x03. The Pyramid of Pain
Hi mates, welcome to Project # paper item. Basically, we are a group founded by several old boys. This blog-type project is home-based and try out. Anywayz, I’m very excited cause all of us lazy bones really wanna do something meaningful.
The incident response process consists of all the activities necessary to accomplish the goals of incident response. The overall process and the activities should be well documented and understood by the response team, as well as by stakeholders throughout the organization.
In my opinion, the process consists of three main activities:
- Gather all relevant details from person who reported incident
- Gather technical details from IT staff
- To understand the context for the incident from business perspective
- Review network and security logs to identify data that could support that the incident has occurred
- Document all information
This is the most important stage in the whole IR process. The goal of an investigation is to determine facts that describe what happened, how it happened, and in some cases, who was responsible.
- Initial Leads
- IoC Creation
- Deploy IoC
- Identify Systems of Interest
- Collect Evidence
- Data Analysis
Mitigation and Remediation
Remediation plans will vary greatly, depending on the circumstances of the incident and the potential impact.
IoC creation is the process of documenting characteristics and artifacts of an incident in a structured manner. This includes everything from both a host and network perspective that things beyond just malware. Just think about items such as working directory names, output file names, login events, persistence mechanisms, IP addresses, domain names, and even malware network protocol signatures.
The goal of IoC is to help us effectively describe, communicate, and find artifacts related to an incident. Because an IoC is only a definition, it doesn’t provide the actual mechanism to find matches.
An important consideration is choosing how to represent IoC to use the format. The network indicators of compromise are most commonly represented as Snort rules, from the host perspective , some of the IoC formats available are:
In this part, I just wanna introduce OpenIoC basically.
OpenIoC is achieved by XML, each IoC is a compliance indicator essentially and is defined by a logic tree comprised of expressions. IOC will hit when one of the expressions describes a true circumstance.
There is a sample IoC Structure in this following details:
It is very common to use IoC review for internal incident response in Chinese understanding of Threat Intelligence, however , this scene seems very simple , it just matches log data and intilligence, actually it’s more than that, in my confrontation work in recent years, I have made much different cognition of this scene, in my opinion, IoC Intelligence could be divided into three levels.
In this primary stage, it is not complicated to match IoC Intelligence itself. The key point is quality of IoC, that is Relevance, Timely, Accuracy, The ability guide the cause and effect.
Among them, The ability guide the cause and effect is the most important, that means intelligence needs to provide attacker and malware families for attack purposes, effects, TTPs, etc. thereby help IR team to determine if it needs to solve and draft priority of response.
Gradually, I consider that IoC Intelligence is not only a matching problem, but also it need to be optimized through data log analysis like DNS log.
DNS log is an ideal type for IoC matching. cause some of RAT servers don’t support DNS resolution, it will note generate application log for other type. And we could infer a host that if it was infect by malware or trojan even an APT attack through this pure indicator.
The RAT IOC attributes maybe a domain. This situation is relatively simple; but if it is a URL, how to match in this case is a relatively complicated matter, because pure DNS data cannot accurately determine whether a fault has occurred. It is often necessary to introduce some reference data categories and consider which types of threats the enterprise is paying more attention to. In this case, a more complex matching mechanism is needed. This level can be called an advanced match.
After the first two stages, most organizations should be able to use threat intelligence for testing. However, from the higher requirements, there maybe some problems that need to be solved. For example, the domain name displayed in the log does not have direct threat information hits, but the host where the domain name is located is actually a cybercrime organization.
How to generate an alarm; if you want to make a detailed analysis and judgment on an email, you need to analyze from multiple dimensions, which will use multiple types of threat intelligence. To solve these problems, not only threat intelligence and network basic data, but also a corresponding analysis and judgment model is needed.
In fact, what is good threat intelligence, the industry has long been a consensus, it’s only need to guarantee its quality in four aspects.
Actually,it is mentioned above.Relevance, Timely, Accuracy, The ability guide the cause and effect.
It is similar to the traditional detection rate, but more emphasis on the specific user’s area and industry-related, that is, the environment needs to be targeted to this user, to identify the important threats that may be encountered.
The relation is not determined by whether the vendor provides an industry attribute field in the intelligence, or how many IOCs have a specific industry identifier, because it is known that some vendor’s field identification is completely wrong and will be targeted at Internet users. A certain type of random attack identification is an industry-specific attack. In this situation, it is impossible to determine the correlation from the field and the number.
The timely of intelligence include several parts, such as huntting collections , intelligence process and conclusion released.
It is always relate to the rate of mistakes , cause security community is used to quote other members/companies/organizations reports, if anyone of these released a IoC that confuses and mistakes, it will affect the research of similar nature.
Every IoC should has the ability to guide the cause and effect, this means that IoC is similar with the clues for solving the case, it should be helpful for making a policy decision and actions for next step.
This item determines the quality of the whole threat intelligence , it maybe determine case credibility , priority , harmfulness(the target aim/method/affect) , even mitigations.
In according with application scenes, IoC could be divide into three type.
Tactics Level IoC is used for discovering threat and make a sort for priority. such as CnC IoC, IP IoC are included in this type, they are common machine-readable IoC, could be used by TI platform and complete above-mission.
Compromised Intelligence, that is, attacker own C2 server information used by the victim host. These IoCs are often in the form of Domain, IP, URL(sometimes including certificates, samples HASH, etc.) They basically provide rich contextual info such as attack organizations , effects, malware families to help prioritize incidents and guide subsequent security response activities.
Operational Level IoC is used by security analysts or security incident responders to analyze known critical security incidents(including (alarm confirmation, effects, attack chain and aims, technical methods, etc.) or use the known attacker’s technical and tactical methods actively track for related clues. The first type is part of incident response, and the second type is part of an activity named “Threat Hunting” .
Security incident response requires local syslog, traffic and terminal information, it also requires asset discovery information. In this situation, Operational Level IoC is more like an entry point and source for expanding more intelligence. It is possible to find more attack incidents and details related to the attacker, and to have more understanding of the purpose, technical and tactical techniques through a Domain or IP related to attack itself; in this way, it is possible to find more attack incidents and details related to the attacker, and have more profound understanding of the attack TTPs.
Strategic Level IoC is used by the organization security managers, such as CISO. However there is a problem, is that business managers who are not good at specific technologies need to have enough information to determine input and strategy in security. If the CISO has Strategic Level IoC/Intelligence, it will figure out the problem at hand directly.
Strategic Level IoC includes the type of attack organization, attack affect, attack tactical ability, resources, and the specific cases. In this way, security decisions are no longer blind, but more in line with the organization business situation and the real threats it faces.
On February 18th,2013. Mandiant released a well-known APT report started the APT research upsurge, after being acquired by FireEye, the share price has risen through APT concept. There followed a small flood of reports from other entities like the Symantec and the DHS/FBI. However, almost no one is using the detailed technical information included in the report appendices effectively. David Bianco proposed the concept of The Pyramid of Pain, aiming to classify the IoC reference significance in detail so that other malicious internet activities researchers can properly use IoC to perfect the puzzle.
Let’s start by simply defining types of indicators make up the pyramid:
- Hash Values: SHA1, MD5 or other similar hashes that correspond to specific suspicious or malicious files. Often used to provide unique references to specific samples of malware or to files involved in an intrusion.
- IP Addresses: It’s, um, an IP address. Or maybe a netblock.
- Domain Names: This could be either a domain name itself (e.g., “evil.net”) or maybe even a sub- or sub-sub-domain (e.g., “this.is.sooooo.evil.net”)
- Network Artifacts: Observables caused by adversary activities on your network. Technically speaking, every byte that flows over your network as a result of the adversary’s interaction could be an artifact, but in practice this really means those pieces of the activity that might tend to distinguish malicious activity from that of legitimate users. Typical examples might be URI patterns, C2 information embedded in network protocols, distinctive HTTP User-Agent or SMTP Mailer values, etc.
- Host Artifacts: Observables caused by adversary activities on one or more of your hosts. Again, we focus on things that would tend to distinguish malicious activities from legitimate ones. They could be registry keys or values known to be created by specific pieces of malware, files or directories dropped in certain places or using certain names, names or descriptions or malicious services or almost anything else that’s distinctive.
- Tools: Software used by the adversary to accomplish their mission. Mostly this will be things they bring with them, rather than software or commands that may already be installed on the computer. This would include utilities designed to create malicious documents for spearphishing, backdoors used to establish C2 or password crackers or other host-based utilities they may want to use post-compromise.
- Tactics, Techniques and Procedures (TTPs): How the adversary goes about accomplishing their mission, from reconnaissance all the way through data exfiltration and at every step in between. “Spearphishing” is a common TTP for establishing a presence in the network. “Spearphishing with a trojaned PDF file” or “… with a link to a malicious .SCR file disguised as a ZIP” would be more specific versions. “Dumping cached authentication credentials and reusing them in Pass-the-Hash attacks” would be a TTP. Notice we’re not talking about specific tools here, as there are any number of ways of weaponizing a PDF or implementing Pass-the-Hash.
Starting at the lower level of the Pyramid, you could try to keep track of all the IPs that you know the adversary uses for reconnaissance operations, but this is not likely to be very effective. You may potentially be tracking hundreds of individual IPs, each of which may only be used for a short time. This is a lot of effort on your part to manage that data, and it is likely to generate a significant amount of false positive alerts which will consume analyst time.
The adversary has effective countermeasures against this, too. They can rent access to a botnet, giving them thousands of throwaway IPs, or they could simply use any of a number of anonymizing services such as Tor, I2P or even a VPN. The best part (the worst for you) is that not only are these easy to use, but they are usually free or very low cost. It costs you a lot of resources to effectively track at this level, and it’s free and easy for the attacker to counter your efforts. Sound like a win?
Moving up the Pyramid, though, makes things a bit moe complicated for the attacker. Detecting the network artifacts of their tools (e.g., a distinctive URL pattern or User Agent string they use when spidering your website) puts the burden on them to change up their toolset. Once your monitoring structure is in place, creating new signatures for new tools is usually not too difficult, and can be done at only an incremental cost to you.
Here is the key point:
If you can move even further up, perhaps operating at the TTP level, you’re forcing the adversary to rewrite their playbook, something that is extremely time consuming for them. Again, there will be a cost associated with gaining the ability to operate at this level, but once you pay it, the costs for future detections are likely to be incremental. In other words, once you reach that plateau, you can stay there with modest resources. On the other hand, every time you force the adversary to relearn new TTPs, they pay the cost. Again, and again and again.
The essence of the confrontation between attack and defense is the confrontation of attack and defense cost
- [David Bianco]
This is a paper that has delay for nearly six months, but it was finally finished.There are still a lot of views on Incident Response and Threat Intelligence that have not been expressed specifically, I wish I can have the opportunity to express more in the following papers.
However, my next one should discuss the issue of supply-chain attack and release a research about Ken Thompson Hack(KTH).