Reverse Deception: Organized Cyber Threat Counter-Exploitation (92 page)

Wherever he steps, whatever he touches, whatever he leaves, even unconsciously, will serve as a silent witness against him
.

—
Professor Edmond Locard

Y
ou’ve dedicated a significant amount of your valuable time reading about advanced, persistent, and advanced persistent threats before arriving at this chapter. The study of the legal and threat landscape, as well as the various TTPs employed by those who wish you harm, is very important. However, what does it all mean? What happened? When did this all start? Where did they get in, and where did they go? Why did they attack you?

At the core of this discussion is determining who decided to break into your system, who decided to steal your financial information, and who decided to make your life miserable. Discovering the
who
can help paint a clearer picture of the
what, when, where, why
, and
how
, and determine its
impact
on your business. So, in case you’ve already forgotten the title of this chapter, we’re going to focus on trying to attribute malicious actions to a particular actor or group.

Your journey down this weary path likely started like so many others. It probably began with a small anomaly on your network or system—maybe the system was just running a little slow. You then went through some immediate troubleshooting steps to find out what piece of software or hardware was giving you problems. However, as your problem-solving steps took you deeper down the rabbit hole, you noticed some other anomalies, which required you to follow incident response protocols per your company’s guidelines. Something didn’t feel quite right while you were containing the incident, so you dug a little deeper to find the root of the problem. That’s when you notice it. Your company’s crown jewels—whether financial data, technical specs on the new design, or the CEO’s e-mail messages about a merger—have been exposed, which could derail your company’s reputation and business success. Who did this? What was their end game? And so begins your next journey, from hunted to hunter.

Postincident Characterization

Postincident or forensic adversary characterization refers to a situation where an incident of an undetermined type has occurred, presenting some form of already occurred observable data that was collected after the incident. This data is taken and used in a manner that may help you analyze the attack. There are several primary objectives of this form of characterization, which are limited since the incident has already occurred.

One objective is that the characterization will provide leverage to justify a measured reaction to an incident. It may be that the reaction is to change the design of a production network to a more secure model. You may also realize that the forensic analysis was only the beginning, and it is necessary to define an accurate profile of the adversary to aid in his capture. Most important, you may need to obtain a better understanding of the kinds of people who really want to break into your network, their motivations, and the types of attacks you are likely to see coming from the characterized subset of adversaries.

Because an actual event has occurred, the starting point for the characterization changes from the typical starting point of a theoretical characterization (which are the events that led to the discovery of the occurred events) to the data (from sources like the IDS and firewall logs or other) pertaining to an incident. To this end, one of the applications of theoretical adversary characterization that has attracted substantial interest is the possibility of a technology that can automate the characterization of adversaries from IDS data alone, providing a real-time “score” of the adversary responsible for triggering some rule or mechanism of an IDS. However, such automated mechanisms are currently not as effective as having a human in the loop. An IDS that provides characterization is basing that information on the IDS data alone, which could be bypassed by your attackers if they begin to understand those IDS rules though trial-and-error practices. Administrators can provide keen insights based on inputs from other systems as well as the IDS. Although automated characterization is possible and could be here in the near future, at this point, completely relying on technological solutions is not the route you want to take.

Metrics applied to examine the semantics of an attack could be used to draw conclusions about an adversary from data such as the operating system the attackers are using, the exploit they are using, the operating system of the target, and the difficulty of the hack.

Chapter 2
examined much of the characterization theory alluded to in this chapter, including concepts that can be applied for both theoretical (asset type) and postincident characterizations, giving us a framework through which we can seek attribution.

Attack characterization can have two primary components:
events
, which refer to what has occurred in the attack, and
threats
, which are the motives and intent of the attack.

Characterizing an attacker will rely on analyzing what you can see over the network and on the hosts. Generally, session data isn’t available through existing infrastructure or production resources (operational network). The following might provide information:

Web servers retain session logs, which can contain keystrokes.

Host security programs, if installed and configured properly, can record user activity and session information.

IDSs can monitor session activity.

Honeynet technologies, if configured properly, can be deployed to monitor session-level interactions.

Another Tall Tale

Michael was the senior network engineer at an up-and-coming software company. He had been with the company since it opened its doors about eight months ago, and had only one other person working with him. Given the small staff, he also served as a jack-of-all-trades, offering technical support when required.

The software company was still a small player on the scene. However, it had just devised a new way to process and analyze very large data collections. This new discovery had garnered the company some press lately, as it was going to partner with a major defense contractor. This could really put the company on the map, and the developers were working all hours to complete the final version of their code.

The day started out like any other. Michael had just arrived at work, still finishing his first cup of coffee. He noticed that the message light was blinking on his phone, and he wasn’t really ready to hear about someone who couldn’t open an e-mail message or some other mundane problem. That’s when Ryan, the other network engineer, came in and told him that his phone had already been ringing off the hook this morning. So, Michael decided he should actually check the voicemail and find out what was going on. It was Todd, one of the junior programmers, informing Michael that he came in last night to work, and his system had been running very slow. He probably hadn’t rebooted his system in forever, and that might be the problem.