Stalking the Kill Chain: The Attacker’s Chain

By Alex Cox, Sr. Researcher, RSA

In 2009, incident responder Mike Cloppert with the Lockheed Martin CERT, published a series of articles that discussed security intelligence and leveraging indicators. In this series, he introduced a concept known as the “attacker kill chain”.

This concept breaks attacker methodology into a series of sequential stages.

Attacker Kill Chain Progression

Each stage represents a focus on a particular aspect of an attack, both from an attacker perspective, as well as a defender perspective.

“We have found that the phases of an attack can be described by 6 sequential stages. Once again loosely borrowing vernacular, the phases of an operation can be described as a “kill chain.” The importance here is not that this is a linear flow – some phases may occur in parallel, and the order of earlier phases can be interchanged – but rather how far along an adversary has progressed in his or her attack, the corresponding damage, and investigation that must be performed.”

Reconnaissance

With the amount of publicly available information on the Internet, the ability for an attacker to do target reconnaissance in an unnoticed fashion is almost unlimited. Commonly used techniques include:

– Reading company websites for information on key initiatives and personnel
– Reading industry whitepapers to identify projects and personnel associated with those projects.
– Searching Google for email addresses, contact points and other bits of information.
– Identifying social network participation of likely targets, often providing attack vectors through trusted friends and associates.

In the reconnaissance phase, the ability for the defender to take defensive actions is limited, as attacker reconnaissance is often done in a covert and hard to detect manner.

Weaponization and Delivery

At this point, the attacker has established a target or collection of targets, and weaponizes an attack payload and delivers it to the target. Let’s use a spear-phishing attack as an example scenario.

In most APT-style spear-phishing attacks that RSA NetWitness has observed a third party document is used as the delivery method for a malware payload. Typically, it will be a trojaned PDF or Office document. While 100% detection of this phase is difficult, information sharing and intelligence gathering on previous attacks helps to identify repeatable characteristics of attacker “playbooks” which can help identify recycled exploit document filenames, shellcode, PDF structure, etc.

From a RSA NetWitness perspective, the platform looks at the documents from a higher level, by analyzing for threatening characteristics in the sessions rather than specific malware or exploit signatures.

Example 1: Jim in HR receives a PDF via an email link for a job applicant. As Jim downloads the PDF and it crosses from the Internet onto his workstation, the organization’s NetWitness NextGen platform:

1. Identifies that the file is forensically a PDF.
2. Identifies that the PDF has a “Launch” action in it.
3. Identifies that the PDF has embedded javascript.

While these three factors don’t mean that the file is absolutely malicious, they identify enough threatening characteristics to warrant a second look, and to pull it from the likely high volume of PDFs that appear on the network daily; thereby “removing the hay until only needles remain”.

Exploitation

Diverging from Cloppert’s approach here, consider immediate post-compromise activities as secondary parts of the exploitation event. During the exploitation phase of the attack, the host machine is compromised by the attacker and the delivery mechanism typically will take one of two actions:

– Install malware (a dropper) allowing attacker command execution.
– Install malware (a downloader) and download additional malware from the Internet, allowing attacker command execution.

Once a foothold is established inside the network, the attacker will typically download additional tools, attempt privilege escalation, extract password hashes, etc.

At this point, defensive strategies have ultimately failed, and the attacker has control of a resource. We would typically move to a detective model here and focus on identifying second-stage malware and toolsets being downloaded to the compromised workstation post-exploitation.

– Forensically identify executable download, both un-obfuscated and obfuscated.

Obfuscation and encryption methods vary, in some cases custom algorithms or none at all in others. A few methods tend to be re-used:

– Single-Byte XOR
– Base64
– Custom Base64

Command and Control

Once the attacker has successfully exploited and taken control of a workstation, he will usually install malware that has a command and control mechanism. This allows persistent connectivity for continued access to the environment as well as a detective measure for defender activity.

Command and control of a compromised resource is usually accomplished via a beacon over an allowed path out of the network.

Beacons take many forms, but in most cases they tend to be:

– HTTP or HTTPS-based
– Made to look like benign traffic via falsified HTTP headers

In cases that use encrypted communication, beacons tend to use self-signed certificates or use custom encryption over an allowed path (often TCP 443)

Strategies for detection at this stage tend to revolve around:

– Identifying the use of self-signed certificates during encrypted communication.
– Identifying falsified HTTP headers via anomaly detection strategies.
– Identifying recurring, consistent beacon activity to the same domain or IP address over time.
– Identifying the use of non-standard or unapproved encryption over allowed paths.

Keep in mind that immediate takedown of hosts that have identified beacon activity may clue attackers into defender activity (loss of a known beacon), causing them to switch to secondary (and potentially unknown) infrastructure. While incident response, as a program, is out of the scope of this whitepaper, this should be a consideration when faced with this type of discovery.

Exfiltration

The final phase of the kill chain is exfiltration. In this phase, the attacker has successfully entered the target network, taken control of a host and potentially:

– Downloaded and staged tools
– Elevated privileges
– Moved laterally onto other hosts
– Located and packaged information

At this point, the final goal is to gather the packaged information, and deliver it to a location under control by the attacker. These locations are typically hacked hosts that are used as temporary holding areas for stolen data or hosts that reside in an area that is under complete control of the attacker (bulletproof hosting).

Exfiltration commonly takes the form of:

– Encrypted .rar or .zip files
– FTP’d or uploaded to a controlled host

However, in the case of malware such as ZeuS, SpyEye, etc., exfiltration and C2 beacons often take place at the same time (the compromised host will export stolen data on a repeated schedule, basically an information stealing beacon).

Exfiltration marks the point that data loss has occurred. Detection at this phase leads to damage control activities for lost data, invoking an IR process, and a move backwards through the kill chain to establish root cause.

In the last post of the series, I will bring all the concepts together and highlight some tips you can use from an RSA NetWitness perspective.

Alex Cox, MSIA, CISSP, GPEN, GSEC is a Senior Consultant and Security Researcher with RSA’s Advanced Threat Intelligence Research group. Alex has worked more than a decade in IT with a background in desktop architecture, emerging threat research, network forensics and behavioral malware analysis.

Leave a Reply

Your email address will not be published. Required fields are marked *

No Comments