Tech Insight: Attribution Is Much More Than A Source IP
Recent attacks are shining more light on the need for attribution, but companies seem too quick to jump on the Chinese/APT bandwagon
"The Chinese hacked us" is becoming an all-too-common phrase in recent corporate hacks. While it is no doubt true in some of the situations, it's hard not to wonder how many of these attack victims are crying Red Army ... er, um ... wolf. Or how many are simply basing their accusations on incomplete, faulty evidence? Attribution of attacks can be difficult, especially when a skilled attacker -- who wants to remain anonymous -- carries out the attack.
What seems to be happening in many intrusion cases is that an IP located in China has been associated with the attack. The immediate assumption, often by inexperienced persons involved in the investigation, is that someone in China, most likely state-sponsored, targeted their incredibly important information.
More Security Insights
White PapersMore >>
- Agile Service Desk: Keeping Pace or Getting out Paced by New Technology?
- Inside Threats: Is Your Company at Risk?
The reality is more likely that some attacker found a vulnerable website in Country X, gained access to it, and then exploited a vulnerability in a mail server in Country Y. From Country Y, the attacker jumped through an open proxy in Country Z to access a previously compromised server in China. That compromised server in China was then used to launch the attack and is now considered part of a Chinese conspiracy to steal the formula for Justin Timberlake's latest fragrance. All that leaves us with the original question of: Whodunit?
Attribution is hard, and it doesn't help when there are questionable clues left behind, like the "Red October" malware campaign or attacker groups falsely claiming responsibility for certain attacks. It's clear that relying on the source IP of the attack is not enough to know where the attack truly originated. While geolocation may point to some city or province in China, it is only the first, and potentially misleading, clue.
In a recent PBS interview on The New York Times attack, Mandiant VP Grady Summers said that investigations into attacks are similar to that of a burglary. Detectives will attempt to profile a thief through their tools, time of break-in, and other characteristics. "We do much the same thing in the cyberworld. We look at hundreds, if not thousands, of indicators," Summers said. "And when we see those tools and techniques used again, we can usually pinpoint it with pretty good accuracy."
That approach works well for companies performing incident response full time and have a wealth of knowledge on various attackers, but it doesn't work for businesses that can't afford a third-party investigation firm. These companies have to "take to the streets" and do their own investigations. The first step is to start gathering as much information about the attack as possible, similar to what Summers described.
Some example questions to ask include: Where did the attack come from? Was any evidence left in server or network logs showing Web browser user agents, websites used for exfiltration of stolen data, or tools for guessing passwords or elevating privileges? Was custom malware used, and does analysis of that malware reveal any information about where it was developed, the native language of the developers, or snippets of code seen in other malware?
With answers to some of those questions, online research using open-source intelligence (OSINT) can help with corroborating details surrounding an attack. OSSINT leverages information readily accessible from search engines, social media, bulletin boards, online forums, and sites like Pastebin and Pastie. Search engines may help find sources of code or tools used during the attack, while actual commands may be traceable back to forums and bulletin boards where the attackers discussed how to carry out the attack.
Analysis of the malware can often lead to interesting clues about the developer. Sometimes debugging information can leak details about the developer's system, such as the name of the computer, location where the code was stored on the drive, and even the username. The Shamoon malware used in the Saudi Aramco attack is one example that shows some info about the developer's system and possible heritage. While fingers were pointed at Iran as the perpetrators, the string "C:\Shamoon\ArabianGulf\wiper\release\wiper.pdb" found in the malware could indicate the attacker is not from the region since Iranians refer to the gulf as the Persian Gulf. False flag or not, if a computer system were seized as part of a raid, the presence of that directory and code would be a powerful piece of evidence.
Will attribution get easier as more companies begin to focus on attribution? My guess is attackers will simply adapt to ensure there is less of an evidence trail to follow. It may be that forward-thinking companies start by trying to modify their defenses to include things like the recently released Active Defense Harbinger Distribution (ADHD) Linux distribution. ADHD is designed to interfere with the attackers' scanning and reconnaissance efforts, and even includes some tools focused on attribution. Whatever the choice in defensive strategy, it's clear that more and more victims are looking to identify their attackers.
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.