Last updated at Fri, 07 Jul 2023 13:39:33 GMT

Synopsis

You’re a malware writer. You’ve been tasked with infecting a remote computer, one that you have never seen before, have no physical contact with, and don’t have the IP address of. Maybe you have the email address of a user of that computer, or just the name of the facility in which that computer is stored. How do you proceed?

Hopefully I’m not describing you or someone you know, but sometimes it can be helpful to consider the mindset of an adversary when devising defensive measures. In this article we’ll take a high-level look at four possible avenues of attack, including email & social engineering, web exploits, flash drive planting, and the insidious firmware/hardware loading.

Learn more about Malware Attacks

An Entrance: Social Engineering & Email

"Everybody has their trigger. A good social engineer will find that trigger."
– Bruce M. Snell, director of technical marketing at McAfee Security Systems

Humans are frequently the weakest link in a computing system, and email provides a great general attack vector. Many people don’t think before filling out forms, clicking links in emails, etc. A common avenue of attack involves exploiting automatically loaded images in emails. Dropping an img tag in an email formatted to display HTML content can open up a host of exploits, primarily by directly linking to a malicious website. More subtly, the img tag could link to a server that returns an HTTP 302 error which redirects to a malicious website, adding a layer of indirection. The img tag can evan contain malformed image data which causes the target system to navigate to an malicious web resource.

Let’s make a tiny, tiny node server to demonstrate this in action.

 const http = require('http');
 
 var visits = [];
 
 const log = res => { 
     console.log(Date()) 
     visits.push(Date()); 
     res.end(JSON.stringify(visits)); 
 }
 
 http.createServer((req, res) => { 
     log(res); 
     console.log("outer") 
 }).listen(8080, "localhost", _ => { 
     console.log("Server running at on port 8080"); 
 });

Our server simply logs & returns an array of timestamps indicating when the site was visited, and indirectly how many times the site was visited.

Now for our attack html page (or email).

 <img src="http://localhost:8080">

Navigating to the html page, we’ll notice in our server’s logs that our server is hit every time we load the above html page, despite our having no knowledge of the page other than it seemingly containing a broken image link. How many times have you seen a broken image link in an email before?

Google has even gone ahead and made gmail load external images by default, but attempted to circumvent malicious image loading practices by preloading images to their own secure servers, checking for malicious non-image content, information disclosure, etc. in external links. Despite this, we can still figure out whether or not the target computer is opening our emails with some tricks, or by hijacking another, reputable website and sending our malicious emails from there.

Exploiting Control: Web Exploits

How can we set up a malicious website to take advantage of this? Once again, social engineering comes into play. If we know the types of sites a user of our target computer uses, we can load up an XSS attack related to a website we know they’re logged into. XSS attacks deserve their own article, but we could load a url like

https://users-social-media.com/resetPassword

into our image tag, causing the user to inadvertently reset their password or cause other nefarious activity. Many possibilities for tracking users exist here, as well as getting users to disclose information inadvertently. Maybe this gets us what we need, or maybe it just leads us to another attack.

Gaining one-off control of the user’s browser with malicious img links might been a first step, but we’re probably not going to get malware onto anyone’s computer that way. If we get a user of our target computer to visit our malicious site, however, we can force them to download a plain old executable or a special PDF. This is accomplished via XSS attacks, again, or by exploiting filesystem access in combination with a Flash or Java exploit. Assuming the target users aren’t going to open it for us (many will if it’s engineered to seem like something the user wants), we can next use browser vulnerabilities or more social engineering to get the user to open our program.

Here’s an example of how an IE memory corruption bug could allow a specially crafted webpage to gain access to a system as the current user.

Here’s another example where a specially packaged version of the google chrome installer can be exploited to run local files.

Once we’re running an executable on the target system, we’re basically home free. There are well documented techniques programs can use to avoid detection by anti-virus, primarily writing your own malware the world has never seen before. There are other well documented techniques programs can use to keep running even if the user detects something evil afoot.

Direct Access: Flash Drives

If you have physical access to a location geographically near the building in which this computer is housed, you might try to pull off a simpler social engineering attack. Many, many users, even sophisticated government employees like flash drives, and wouldn’t bat an eyelash using a found flash drive. I’ve even done it before, and you probably have too. It’s an amazingly simple way to get malicious programs onto a target computer, as many external storage devices have autorun functionality enabled. In the more modern software ecosystem (Windows 10, Mac OS X etc.) this is disabled, but vulnerabilities for overriding this behavior still exist.

This is an incredibly powerful type of attack, as it supersedes encryption schemes like TPM, BitLocker, etc. as it exploits the target system while the user is engaged. In fact, plugging in the flash drive is a type of user initiated activity, giving a malware author with software loaded on the flash drive great power.

A No Win Scenario: Hardware & Firmware Exploits

An even more difficult to defeat but happily harder to pull off attack vector is modifying device hardware or firmware to allow backdoor access/exploitation. This is another subject deserving its own article, but there’s a good high level treatment of the subject available. These types of attacks involve changing data the user doesn’t generally interact with, i.e. going beyond the filesystem. Instead, hardware and firmware exploits target device firmware, BIOS & UEFI, or even physical chips in devices. Data in these sections of a computer will persist after an operating system is reinstalled, disks are wiped, etc. Luckily this type of attack is very nuanced, requiring advanced knowledge of (usually undocumented) vendor specific driver code, usually inaccessible to all but the most sophisticated threat groups.

This type of attack is especially of concern given the amount of hardware organizations import from outside their own country. If a processor or hard drive factory exists somewhere an adversary has access or influence, they might be loading up chips with backdoors or other vulnerabilities.

Awareness: The Best Defense

If there’s any takeaway from our very high-level traversal of common malware attack vectors, it’s that while running anti-virus is a good practice, isn’t going to save you if someone really wants to target you. Keeping your browser updated is a good practice, but it also isn’t going to save you if someone really wants your data. Living indoors and never going outside isn’t necessarily going to save you either. There is no magic bullet solution; the best you can do is to

  1. be aware of the threats out there,
  2. practice defensive computing in all aspects of your digital life,

and

  1. use common sense. If it seems fishy, it probably is.

More Reading & Other Resources