Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

7/22/2009
03:13 PM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

Using Malware In Penetration Testing

Huh? That's the exact reaction I had when I first read the title for the blog entry "Pentest Evolution: Malware Under Control."

Huh? That's the exact reaction I had when I first read the title for the blog entry "Pentest Evolution: Malware Under Control."The blog is by Gunter Ollmann and covers pen-testing from a historical perspective, with discussions about how the art (and science) of pen-testing has branched out during the years into specialized areas. It's an interesting read, but I think the article's point is going to be missed or skewed by many because Ollmann uses the term "malware" when talking about exploiting users and client-side applications.

If you were told the company performing pen-testing against your organization was planning to use malware to try and penetrate your systems, then how would your CIO/CISO respond? Probably with a resounding, "Hell, no!" The truth is, we as security professionals use "malware" all the time. I can't tell you how many times I've had my tools folder decimated because my antivirus software decided to forget its exclusion rules and instead deleted a bunch of my tools it deemed malicious.

But in information security, one man's tool is another man's malware. What Ollmann is describing as a pen-test using malware is what Chris Gates of the Carnal0wnage blog has referred to as many times as full-scope penetration testing. In the simplest of terms, instead of limiting a pen-test to only include Internet-facing systems, systems containing sensitive information, or some other arbitrary limitation, a full scope pen-test includes ALL systems -- including users.

Gunter is using the term malware to refer to the tools that currently exist for creating custom code that can be used to compromise systems the same way an attacker would with a malicious Website. His example is saying, "Prove it" when confronted by a statement like: "Drive-by downloads are a fact of life, and all it takes is one unpatched host to browse a dangerous site to infect our network. But that's okay, because we have anomaly detection systems and DLP, and we'll stop them that way."

In truth, there are many do-it-yourself malware creation kits that attacks use, but I don't think any reputable pen-tester is going to go out and get one of them. Instead, we have well-known and well-respected tools, like the Metasploit Framework and Core IMPACT, that provide us with the same capabilities to exploit users and systems through phishing and client-side attacks.

We don't need malware creation kits and the risks of using them....or is that what Ollmann was calling tools like Metasploit or IMPACT? It certainly wouldn't be the first time a tool like netcat or Sysinternals pstools was labeled as malware and deleted by AV, because tools we've used for good as infosec pros were also used for malicious purposes. No matter the distinction, the reality is that comprehensive, full-scope pen-tests using the methods described in Ollmann's blog are taking place, and have been for a couple of years now.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.