Event Details

How Often Can One Program Infect Another? Let Us Count the Ways

At Black Hat, experts from SafeBreach report on the many different ways a malicious program could infect another process with its own code. Spoiler alert: it's a lot.

LAS VEGAS—There's a reason we refer to computer viruses and devices or processes as being "infected." Back when viruses were new, and programs were compiled to COM files, infecting a program was simple. The virus appended its own code to the end of the target and overwrote the very first instruction with a jump to that code. The last instruction from the virus started the execution of the program's regular functions—a very early form of process injection.

Fast forward to the modern world, and the possibilities are more complex and numerous. At the Black Hat conference here, a pair of researchers from SafeBreach, which contracts to assess and mitigate security risks, unveiled an exhaustive survey of all the ways one program can inject code into another. Their session isn't until Thursday, but we caught up with them ahead of the briefing.

Co-founder and CTO Itzik Kotler and VP of Security Research Amit Klein set out with their team to collect, curate, and demonstrate all the possible ways a malwarecoder could compromise other processes. Initially, they figured they'd find six or seven, but they wound up with 20 variations, boiled down to a dozen. In a nod to popular culture, the presentation is subtitled "Gotta Catch Them All."

Process Injection for All

I mentioned my thought about old COM-program viruses to Kotler, and he agreed it was a very early example of process injection. "It's important to remember that COM files and DOS had no security," he said. "Today Microsoft has to offer security for everyone."

Kotler and Klein first surveyed all the techniques that had been used to inject code into Windows programs, discarding those no longer viable, and found they still had plenty.

I won't go into detail about the actual techniques, except to mention that along with this collection, Kotler and Klein also created a new one they dubbed Stack Bombi. At their Black Hat presentation, they will release a tool called Pinjectra that implements each of the collected techniques.

Who Needs It?

Pinjectra is an open-source tool, freely available to anyone. Tech-savvy consumers could use it to test the abilities of a security suite. Corporate security teams could do the same with their endpoint protection. And of course, malware coders could study the code to get some new ideas.

I asked Kotler why he'd put this tool in the hands of the bad guys. "I've been doing offensive security for 15 years. It's my belief that when we don't publish stuff, it doesn't mean the bad guys don't have it," he responded. "It just means we as a community don't address it. Ignoring reality doesn't fix things."

He noted that the Pinjectra tool has no malicious payload. If your security doesn't protect against a particular attack, you'll see a pop-up message saying "Hello World," nothing more. "Yes, people can change that," he admitted. "But they can change pretty much anything to evil."

Why Didn't Microsoft Fix It?

I asked why Microsoft couldn't just patch the OS to prevent these process injection attacks. "Of course I can't speak for them, but these techniques could be used for legitimate purposes," he said. "They might be needed to support legacy applications. Some can be used for debugging. Nothing in process injection is inherently bad."