Attacks/Breaches
2/17/2013
07:01 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

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.

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Larry Seltzer - UBM Tech
50%
50%
Larry Seltzer - UBM Tech,
User Rank: Apprentice
2/19/2013 | 11:34:22 PM
re: Tech Insight: Attribution Is Much More Than A Source IP
It seems to me that even when you do the best you can in these cases, especially if you're using fingerprinting, deniability is always plausible enough for public relations reasons. You'll never catch these guys red-handed.
digitalsec4u
50%
50%
digitalsec4u,
User Rank: Apprentice
2/18/2013 | 3:16:52 AM
re: Tech Insight: Attribution Is Much More Than A Source IP
Tim,-áUnfortunately its a when and if they do realize a breach has-áoccurred. But some of the work that is being done in fingerprinting the attacks looks promising.

V/r,
Don-á-á-á
DarkReadingTim
50%
50%
DarkReadingTim,
User Rank: Strategist
2/18/2013 | 1:32:15 AM
re: Tech Insight: Attribution Is Much More Than A Source IP
Interesting piece here.-á Wonder if any of our readers have been able to backtrack their attackers and arrive at a definitive attribution?-á It seems very difficult to do, yet a crucial piece of stopping so many attacks. One of the reasons that attacks continue to proliferate is because attackers have so little fear of being caught.
--Tim Wilson, editor, Dark Reading
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

CVE-2014-2392
Published: 2014-04-24
The E-Mail autoconfiguration feature in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 places a password in a GET request, which allows remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer log...

CVE-2014-2393
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in Open-Xchange AppSuite 7.4.1 before 7.4.1-rev11 and 7.4.2 before 7.4.2-rev13 allows remote attackers to inject arbitrary web script or HTML via a Drive filename that is not properly handled during use of the composer to add an e-mail attachment.

CVE-2011-5279
Published: 2014-04-23
CRLF injection vulnerability in the CGI implementation in Microsoft Internet Information Services (IIS) 4.x and 5.x on Windows NT and Windows 2000 allows remote attackers to modify arbitrary uppercase environment variables via a \n (newline) character in an HTTP header.

CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

Best of the Web