Risk
7/29/2010
10:08 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Malware Authors Leave Their Fingerprints On Their Work, Black Hat Researcher Says

Careful study of malware can help experts recognize its source and protect against it

LAS VEGAS, NEVADA -- Black Hat USA 2010 -- At the rate malware is proliferating, it sometimes seems impossible to tell one bit of malicious code from the next. But according to a security researcher here, malware authors leave "fingerprints" all over their work, which could aid security professionals in stopping them.

Click here for more of Dark Reading's Black Hat articles.
At a session on malware attribution, HB Gary researcher Greg Hoglund outlined a wide variety of methods that can be used to identify the source of malware and, ultimately, determine how to defend against it.

"We're not talking about naming names here, or finding their Social Security number and missile coordinates," said Hoglund, whose company does detailed analysis of malware. "What we're saying is that there is a human factor here that can help us understand what we're dealing with when we see new malware."

Malware developers leave "fingerprints" on their programs in the form of the tools they use, their styles of code-writing, and even in the parameters they choose, Hoglund says. These clues can help security experts determine whether a new attack is based on an old one, or whether a development toolkit was used to create it.

Such information might not be enough for law enforcement to track the malware back to its author, but recognizing similarities in malware development patterns can be helpful in preparing effective defenses, Hoglund stated.

After extensive malware analysis, HB Gary has identified some basic "rules" of malware authorship, Hoglund said. Rule No. 1 is that humans are lazy and seldom rewrite source code if they can avoid it.

"There might be 50,000 variations out there, but the base code is still the same," he said.

The second rule is that most attackers are focused on making a rapid reaction to network-level filtering and other standard defenses, Hoglund said. "They are not so focused on host-level stealth," which makes host-level analysis useful in following their tracks, he observed.

The third rule is that physical memory is king. "Once executing in memory, code has to be revealed, and that's where you can see its true behavior," even though the malware author may have taken sophisticated steps to pack or otherwise obfuscate it, Hoglund said.

Malware attribution is not particularly difficult if you know what to look for, Hoglund stated. "If you can read a packet sniffer, you can attribute malware," he said. If more security professionals investigated the source of the malware they saw, then it would be easier to develop defenses, he observed.

Hoglund took the audience through a broad range of methods for identifying a malware author's fingerprints, ranging from toolkits and development tools used to time stamps and source code analysis.

"So far in malware analysis, the industry has focused mostly on the binary end of the spectrum," Hoglund said. "We want to open people's minds up to the human side."

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message. Tim Wilson is Editor in Chief and co-founder of Dark Reading.com, UBM Tech's online community for information security professionals. He is responsible for managing the site, assigning and editing content, and writing breaking news stories. Wilson has been recognized as one ... View Full Bio

Comment  | 
Print  | 
More Insights
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-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.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web