Downloaders, droppers and decoys: The malware that arrives before the real malware

When cybercriminals are around, what you see at the outset is rarely what you get in the end.

Attacks in many stages

In recent SolCyber articles, podcasts and webinars, you’ll have heard us mentioning many different sorts of cyberattack, and numerous different sorts of attacker.

For example, ransomware tends to dominate cybersecurity headlines, given the degree of human despair it causes when personal data is deliberately leaked as a blackmail strategy, and given the level of IT devastation it often leaves behind.

But many, perhaps even most, ransomware incidents don’t unfold as a single attack involving a single item of malicious software, or malware for short.

Make no mistake, ransomware attacks can happen that way: you could receive a single rogue program file by email, either as an attachment or a download link, unadvisedly run that file, and instantly watch your precious files getting scrambled.

Indeed, back in 2013, that’s pretty much exactly how the first wave of modern, file-scrambling ransomware attacks were carried out, by a malware strain dubbed CryptoLocker, which also became the name given to the gang who created it and sent it out.

These attackers, and the extortion-based cybergangs with names such as Locky and Teslacrypt that soon followed, ended up making millions of dollars, perhaps even hundreds of millions, by blackmailing thousands or tens of thousands of individuals simultaneously, in wave after wave of attacks, demanding about $300 to $1000 in bitcoins for each computer that had been scrambled.

If your company had 1000 laptops and 50 of them got locked up simultaneously, perhaps because of a spam campaign that tricked 50 users before you could circulate a warning telling everyone to watch out, you were stuck with paying 50 × $300.

Each computer needed its own, unique decryption key, because these early ransomware attackers weren’t specifically targeting businesses or networks.

Spray-and-pray

In case you’re wondering how well this old-school sort of ‘hit-and-hope’ ransomware attack worked, often also known as a spray-and-pray, the University of Kent in England published a survey in early 2014 that told a dramatic story about how much those early one-at-a-time CryptoLocker crooks probably made.

Because the survey was conducted with some sort of academic rigour, and wasn’t “research” carried out by a vendor with sales and marketing in mind, the conclusions were widely accepted, and made scary reading: 1 in 30 households admitted to having been hit, and 40% of those said they’d paid up to get their computers ‘repaired’.

If we use 2013 statistics for the number of households in Britain, and the fraction of those with computers, we get a total of just over 26 million households × 83% with computers, for about 22 million possible ransomware victims.

If 1 in 30 got hit, that’s more than 700,000 ransomware incidents; and if 40% of those coughed up $300 each, that’s more than $80,000,000 in blackmail payments in Britain alone.

If you add the population of Western Europe and North America to that, the number of potential victims increases about ten-fold.

Evading detection

The University of Kent survey suggested that just over a quarter (about 28%) of those surveyed admitted to taking no security precautions (this was back in 2013, so that number could be very different today), including having no anti-virus or threat-blocking software at all.

But this means that a significant majority of those who did take precautions nevertheless ended up with the CryptoLocker malware implanted and activated on their computers.

So, if the CryptoLocker gang infected hundreds of thousands of computers in Britain alone, where more than two-thirds of households were protected in some way against malware attacks…

…how did their ransomware, which remained substantially similar in operation throughout its year-long lifetime, continue to evade detection?

How cybercriminals stay on the attack

How does any long-lived crimeware group, whether they’re pushing out ransomware, cryptominers, keyloggers, data stealers, or any other sort of malware, stay actively threatening for months or years?

Do they literally need to rewrite their malware from scratch after every attack, or are there other tricks they can use to make individual malware samples go further and last longer?

The answer is that they can use a range of different techniques, including:

• Rewriting their malware with significant changes on an irregular basis. Ransomware gangs, for example, may stick with a similar overall modus operandi (what law enforcement calls their MO, Latin for ‘mode of operation’) for years. Like regular software vendors, however, they will irregularly introduce new malware ‘upgrades’, both to add new ‘features’ and to change their run-time behaviour enough to bypass known detection techniques. This could involve changing the underlying encryption algorithms used, altering the way that the code finds and modifies files on disk, or rewriting the entire malware in a new programming language to give it a completely different final appearance.
• Reworking their malware sample regularly and frequently. Even the same source code can be transformed into very different output files just by rebuilding it with a different compiler or with different build-time options. Malware coders may also choose similar but different functions in the Windows programming interface to achieve the same results, harmlessly rearrange the order of functions in their code, or randomly add unnecessary new code to change the look of the final program without affecting its behaviour.
• Rearranging their malware resources very often. Some aspects of malware can trivially and automatically be changed for every sample, thus ensuring that cloud-based ‘live detection’ tools such as hash-based lookups and reputation checks see a different file every time. Adding fake ‘serial numbers’, changing filenames used inside the code, or using different URLs in every sample (just like email marketers do when tracking individual users), provides the crooks with an ever-changing stream of distinct malware samples.
• Revealing their intended malware only at the very last minute. The first malware sample that the crooks deliver, whether it’s an emailed link they lure you into clicking and installing, a disguised attachment they include in a scam email, or a rogue QR code that takes you to an imposter website, very often isn’t the malware they ultimately want to implant on your computer. The initial sample may just be a stripped-down installer program, known in malware jargon as a downloader, that ‘calls home’ to a unique URL to fetch the real malware.
• Repackaging their intended malware to shroud its presence. Even the final malware that gets downloaded might not be the program that actually does the dirty work, because the crooks can take the program they want to run and package it as data into a ‘carrier pigeon’ program that unpacks the real malware and chains to that instead. Malware that extracts the final malware onto disk and runs it is often referred to as a dropper, because its function is to ‘drop’ a new file. Malware that builds a new program directly in memory, which is a more complex coding task, is typically referred to as an injector, because it doesn’t leave behind any tell-tale ‘dropped’ files.

As you can imagine, these tricks can be combined not only to make detecting new malware harder, because it’s changing all the time, but also to frustrate researchers trying to get hold of new samples.

A scam email could contain a unique download link that returns entirely innocent content when researchers visit, but when regular users click the link, malware is sent back instead.

Likewise, the malware you receive could be selected by the server based on your operating system, your country, the time of day, or many other factors that are known only to the criminals who set up the server, and can only be guessed at by researchers.

The delivered malware could be a tiny downloader that visits yet another unique link and fetches a dropper program in which another downloader is packaged as a compressed, scrambled blob of digital shredded cabbage…

…and so on until the final malware is installed, in a delivery chain that’s as long and as devious as the criminals wish to make it.

The trouble with downloaders

The trouble with downloaders is that they are easy to create, tiny to deliver, and trivial to modify.

Even (perhaps especially) if you detect a new downloader before it calls home and wreaks more havoc, and even if you manage to isolate it and remove it from all the affected computers on your network automatically, you can’t simply pat yourself on the back and move on, because there are numerous related questions you need to consider, too, including:

• How did it get there? Was there some other malware infection, such as a downloader that downloaded the downloader, that might still be there? Given that downloaders and droppers don’t have to unleash their next stage immediately, how long has it been there?
• Did it download anything else? Even if you’re certain it didn’t fetch additional malware this time, how sure are you that it didn’t evade detection before?
• What might have come next? Are there any indicators of what this downloader family, if known, typically does next?
• Who was behind it? Are there any indicators of what sort of criminals control the server that the downloader connects to, and what they might be interested in?
• Does it count as a breach? Could this malware, no matter how simple it might seem on its own, also have uploaded data that might need disclosing to the regulator and your customers?
• What advice can you give to your users? Is there a human-level response, for example in terms of user awareness, that will help you prevent this kind of attack in future, or that would have helped you to detect it earlier?

To give you an idea of just how compact a downloader can be, here’s a simple example.

(We’re not giving away any dangerous tricks here that aren’t already widely available in source code repositories across the internet.)

Don’t worry if you’re not a C programmer; just note the brevity of the code, and how it makes use of existing, easy-to-use Windows programming functions with self-descriptive names such as URLDownloadToFileA().

The system() command, which you also see below, is a one-liner that tells Windows to run the specified filename, which could be a batch file, a program, a PowerShell script, or numerous other types of executable object:

Note how Windows takes care of the download details for you, including automatically using end-to-end HTTPS encryption (denoted by the URL prefix https://), setting up the network connection, dealing with the HTTP protocol interchange with the other end, receiving the data sent back by the server, and saving it into a filename of your choice.

All in one line of code (line 5).

If you want to try this out for yourself, you can download a tiny, free, fully-functional Windows C compiler from my Github site.

Save the program as dl.c and compile it like this to produce a downloader executable called dl.exe that’s just 1536 bytes in size:

Adding more layers of disguise

Admittedly, opening this tiny file in a hex editor and looking at the text strings inside it makes its function rather obvious, without needing any expertise in decompiling or disassembling executable code:

The Windows functions used by the program are listed in the .EXE file, so Windows knows in advance which system code it needs to get ready, so you can see at a glance that the program uses URLDownloadToFileA() from urlmon.dll, as well as the handy system() function from the Microsoft Visual C runtime, msvcrt.dll.

But some tiny changes can make both the URL and the executable filename harder to spot automatically.

This time, we’ve trivially scrambled the ASCII text of the URL and filename simply by adding 1 to the ASCII code of each character (as you can see, the letters https are now less obviously stored as iuuqt, and the giveaway string :// is now the more innocent-looking ;00:

We can also get rid of the mention of urlmon.dll and the function URLDownloadToFileA from what’s known as the function import table by loading them manually at runtime with the widely-used Windows functions LoadLibrary() and GetProcAddress(), which means that the downloader function doesn’t appear in memory until after the downloader program itself has loaded:

The suspicious DLL name and function name of interest no longer appear in the function import table at the bottom of the hexdump, replaced by the rather more innocent functions LoadLibraryA() and GetProcAddress(), which are very widely used by legitimate programs.

However, our own stored-in-the-code strings still give the game away:

Of course, we can use our add-1-to-the-ASCII-code trick once more, and re-obfuscate all our strings, like this:

The giveaway text strings signalling that we’re using URLDownloadToFileA() are no longer visible in the hexdump:

Easier than it might seem

Here, we’ve been messing around with our own code to create a disguised downloader, using common techniques that most programmers would already know: there’s nothing advanced or hard-to-learn about the examples shown above

Additionally, all popular web servers make it easy to generate what are known as dynamic web pages, so that visiting the same URL over and over again creates and sends back a different page each time.

This makes it surprisingly easy for attackers not merely to produce permuted or shuffled-around new malware for every download, but also to repackage that permuted malware inside a permuted downloader or dropper ‘utility’ that is generated and compiled uniquely for each visit.

It’s also easy for attackers to redirect multiple different web domains to a single server, and to arrange for thousands or millions of different URLs to resolve to the same dynamic web page generation script.

All these different-looking URLs might therefore ultimately be handled by just a single server:

http://one.example/free-offer.html
https://one.example/free-offer.html
https://one.example/unsubscribe
https://two.example/unsubscribe
http://look-alike.test/free-offer.html
http://l00k-al1ke.test/free-offer.html

At the same time, all of these different URLs, even if visited multiple times, could end up sending out a different, unique malware sample each time.

And, of course, the malware samples could be multiple, obfuscated samples of the same single family, or multiple samples of multiple very different malware families, perhaps even sent out by cybergang A on behalf of pay-to-play cybergangs X, Y and Z.

Simply put, as we said at the top of the article, what you see at the start of an attack is rarely what you end up with.

Even worse, downloaders and droppers don’t have to be as simple as the ones we’ve shown here.

Criminals can take existing software utilities or installers – programs you already expect to ‘call home’ to download and install further software – and modify them very slightly so that they act as malware decoys.

Decoys of this sort generally do everything that their legitimate originals do, including fetching and activating software you really do want to install, as well as quietly installing malware in the minimalistic, uncomplicated fashion of a standalone downloader or dropper.

What to do?

• Stick to trusted sources for software downloads. Beware of unofficial ‘software collection’ sites that offer copies of other people’s software, even if it’s open source and legal for anyone to redistribute it. Even well-known download sites often re-package legitimate tools with so-called bundleware or bloatware addons of their own, sometimes installed in not-very-obvious way. At best, you may end up with adware or other unwanted apps; at worst, you may end up with malware or security holes opened up to enable future attacks.
• Always investigate any malware that seems designed to deliver more serious malware later on. If you find software on your network that shouldn’t be there, don’t just delete it and assume you’ve conquered the problem. All you’ve really done is treat a symptom, rather than homing in on the likely cause and the best way to prevent it happening again.
• Don’t be afraid to ask for help. It’s expensive and time-consuming to stay on top of the many cybercrime gangs out there, their MOs, the sorts of attack they like to unleash, and the cybercrime ‘partnerships’ they may be involved in. Remember that a downloader implanted by cybergang A can be used to install malware on behalf of one or more other gangs in future, with already-infected computers advertised on the dark web and ‘sold on’ or ‘rented out’ for further crimes.
• Never give up on the human aspects of cybersecurity. Find a security operations center (SOC) that doesn’t rely on automation, AI bots or entry-level call centers to manage your cybercrime responses. Even if your cybersecurity tools mop up the early part of an attack automatically, take the trouble to ask yourself, “Why did we miss this one? What could we do differently next time? Can we stay on top of this ourselves, or should we ask for human-centric help?”

Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!