Attacks/Breaches
4/19/2010
01:58 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%
Repost This

Researcher Demonstrates How To Counterattack Against A Targeted Attack

Proof-of-concept turns the tables on attackers who wage targeted attacks on enterprises

Targeted attacks might be tough to prevent, but what if you could fight back against the attacker once he's infiltrated your network? A researcher has come up with a proof-of-concept (PoC) that does just that by finding vulnerabilities in the attacker's malware and using it against him.

Security consultant Andrzej Dereszowski last week at Black Hat Europe demonstrated how it's possible to wage a counterattack in a targeted attack: His PoC was based on some fuzzing and reverse-engineering he conducted against malware used in an infected PDF that was sent to a pharmaceutical company. Dereszowski found a buffer overflow bug in the malicious toolkit, which was the Poison Ivy tool, and then built an exploit for it.

"I [had been] asking myself, in theory, what if you wanted to counterattack -- provided that it's possible," he says. "You can [actually] hack the hackers and counterattack" as demonstrated by the PoC, he says.

But such an attack in reality would obviously be illegal for a victim company to execute, he says. Instead, the goal of his research is to show there are techniques for fighting back once a targeted attack is already under way, he says. "This is for the purpose of research," he says, although some special government agencies may be able to, or already are, deploying such techniques, he says.

Dereszowski says his research also shows how to quickly analyze malware, which would be useful to a company hit by a targeted attack. "My method of [malware] identification is quite generic and can be applied to any case. I think this could be beneficial to companies," he says.

Not just anyone could pull off the counterattack technique, however: "You have to know reverse-engineering and exploit-development techniques," Dereszowski says. Similar techniques have been used by researchers and investigators in botnet infiltration research, he says.

The recent wave of targeted attacks on Google, Adobe, Intel, and others served as a wake-up call to businesses that stealthy targeted attacks are often tough to detect and basically are a fact of life for many organizations. These attacks, often out of China, gain a foothold inside governments and company networks and remain entrenched in order to steal intellectual property and other data. They are almost always successful and undetectable until it's too late.

Dereszowski's new research sheds light on the possibility of a counteroffensive to the targeted attack, or at least on finding vulnerabilities in the attacks themselves.

He says he began by assuming that the PDF attacker in his research had used a toolkit that was publicly available online, which he found to be the Poison Ivy Trojan toolkit (after doing some reconnaissance). He then broke through the obfuscated code in the infamous Trojan tool in order to run static analysis of the malware. The PoC shows how in a targeted attack using the Poison Ivy Trojan there's a way to fight back against the attacker, he says.

The PoC was running in Dereszowski's virtual machine against its own command-and-control (C&C) server, he says. "If you were to attack a real command-and-control server of an attacker, you could [theoretically] do lots of damage because you would have full permission on their host" with this approach, he says. "But it also depends on the protections they [the attackers] have set up."

The exploit would be invisible to the attacker, and the counterattacker would basically exit the system after he had finished, leaving the exploit behind with a window into the C&C server. Dereszowski ran a standard Metasploit shellcode to open an active connection to the C&C server. This form of counterattack could apply to other Trojans, such as the pervasive Zeus Trojan, he says, as long as you have access to the C&C and can get hold of the malware code.

A copy of Dereszowski's white paper on the counterattack research is available here for download (PDF).

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. Kelly Jackson Higgins is Senior Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Latest Comment: LOL.
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-3154
Published: 2014-04-17
DistUpgrade/DistUpgradeViewKDE.py in Update Manager before 1:0.87.31.1, 1:0.134.x before 1:0.134.11.1, 1:0.142.x before 1:0.142.23.1, 1:0.150.x before 1:0.150.5.1, and 1:0.152.x before 1:0.152.25.5 does not properly create temporary files, which allows local users to obtain the XAUTHORITY file conte...

CVE-2013-2143
Published: 2014-04-17
The users controller in Katello 1.5.0-14 and earlier, and Red Hat Satellite, does not check authorization for the update_roles action, which allows remote authenticated users to gain privileges by setting a user account to an administrator account.

CVE-2014-0036
Published: 2014-04-17
The rbovirt gem before 0.0.24 for Ruby uses the rest-client gem with SSL verification disabled, which allows remote attackers to conduct man-in-the-middle attacks via unspecified vectors.

CVE-2014-0054
Published: 2014-04-17
The Jaxb2RootElementHttpMessageConverter in Spring MVC in Spring Framework before 3.2.8 and 4.0.0 before 4.0.2 does not disable external entity resolution, which allows remote attackers to read arbitrary files, cause a denial of service, and conduct CSRF attacks via crafted XML, aka an XML External ...

CVE-2014-0071
Published: 2014-04-17
PackStack in Red Hat OpenStack 4.0 does not enforce the default security groups when deployed to Neutron, which allows remote attackers to bypass intended access restrictions and make unauthorized connections.

Best of the Web