Memory Lane: Why malware descriptions aren’t what they used to be

Memory Lane: Why malware descriptions aren’t what they used to be

Paul Ducklin
Paul Ducklin
6 min read
Share this article:

Malware writeups used to tell you everything there was to know about each new threat. Cybersecurity support staff insisted on knowing the gory details so they could plan their responses. But life’s not like that today, and it’s not because threat researchers aren’t as smart or as diligent as they used to be!

Portmanteau words, as Humpty Dumpty famously explained to Alice in “Through the Looking Glass” way back in the 1870s, started out as a bit of linguistic fun, consisting of two meanings neatly packed up into one word that rolled off the tongue more easily and entertainingly than either part on its own. Often-quoted contemporary examples include brunch, which is, of course, a happy combination of breakfast and lunch, and chillaxing, which is chilling out and relaxing at the same time, a word that superbly describes any doubly laid-back experience.

Unfortunately, one particular portmanteau word caught on quickly and stuck firm in the English language not because it was delightful and uplifting, but because it described something that was troublesome, dangerous, and needed referring to so frequently that we were compelled to come up with an abbreviated form that retained all the angst of the the original phrase. That word is malware, shorthand for ‘malicious software’, a portmanteau word that arrived in our collective vocabulary well over 30 years ago, and that has sadly embedded itself permanently into cybersecurity jargon as a vital but very gloomy term.

The warning years

Plenty of malware tricks that we sometimes think of as modern have been around since long before the turn of the millennium, when attackers started figuring out how to make money by deliberately implanting rogue software.

The first mass-spammming malware that brought a global network to its knees was the CHRISTMAS Worm of 1987. This was a script virus (it was coded in the language REXX, which was pretty much the PowerShell of its day) that spread in the form of email messages, and spammed itself to your entire list of contacts if you fell for the harmless-sounding ruse of typing in the word CHRISTMAS to see a digital ‘Christmas card’.

Just under a year later, in November 1988, the internet experienced an unexpectedly aggressive attack from the Morris Worm, named after its creator and disseminator Robert Morris Junior. The worm caused considerable embarrassment in official circles because Robert Morris Senior, the virus writer’s father, was a Chief Scientist at the US National Security Agency.

Morris Junior became the first person convicted under America’s Computer Fraud and Abuse Act. He avoided jail time, but had to pay a fine of more than $10,000 and do 400 hours of community service.

The Morris worm automatically exploited three main avenues of attack, all of which remain troublesome cybercrime enablers to this day: poor password choices, poor programming protection against buffer overflows, and poor system configfuration.

And at the tail end of 1989, the first-ever ransomware attack kicked off, when US resident Dr Joseph Popp sent tens of thousands of floppy diskettes across the globe to a mailing list he had acquired under false pretences from a British computer magazine. Popp’s AIDS Information program pretended to be an AI system that gave advice about HIV and AIDS, but ended up scrambling your files approximately three months later, and printing out a blackmail note demanding $378, payable by international money order to a postbox address in Panama.

(I received my very own copy of Popp’s PC malware for analysis, complete with its original envelope and postage stamp. I made a secure digital image of the diskette and didn’t preserve the original for posterity, though now I wish I had.)

These three global malware samples were quickly analysed in great depth by many different researchers, who collectively published numerous detailed, complete and useful reports.

Most early malware, once acquired, could generally be taken into secure, isolated laboratory conditions, air-gapped from the world, and analysed completely, given enough time. Many malware creators went out of their way to disguise their code and their programming tricks, so reverse engineering it was often very difficult indeed, but devising and writing up a full and frank analysis was at least theoretically possible, if not always practicable.

Rise of the Zombies

Importantly, and very differently, beginning in about the mid-2000s, this comparative convenience came to a disappointing end, thanks to the appearance of what we now know as bots or zombies.

Bots, short for ‘robot malware programs’, introduced two features that made them more valuable to their criminal creators, and more worrying to their victims. Bots reguarly ‘call home’, usually in an unassuming or unremarkable way such as by making a simple outbound web request to an unexceptionable server, to fetch instructions about what to do next. They also include a ‘feature’ that allows them to fetch and install brand new malware, or even to replace themselves entirely with a completely new threat. The full range of behaviour that you could be subjected to by malware of this sort cannot be analysed or described in advance, because it isn’t part of the original malware programming.

Simply put, malware descriptions these days don’t tell you as much as they used to because that is no longer possible. Cybercriminals have learned not merely to play their cards closer to their chests, but to play without dealing their hands at all until the very last moment possible. Sometimes, the crooks behind an active bot network, or botnet for short, may simply sell it on to someone else, swapping their malware out for code that they themselves couldn’t have told you about in advance, even if they’d been inclined to do so.

There’s also another important problem with relying on detailed malware descriptions these days, namely that the malware you find during a routine threat hunt today may not be a useful indicator of what’s coming tomorrow, even if you have a complete analysis of what that malware is capable of.

Just hunting for threats without the time or experience to place them in context can be misleading, because attackers already in your network might be experimenting with malware that they know you can and should detect, simply as a vehicle for testing your security configuration. By risking alerts for malware you are likely to be confident in dealing with, attackers can gently probe to look for weak spots in your security settings that have accumulated over months or years of tinkering with policy exceptions to save time and to defuse complaints from users.

For example, by running known malware to see when and where you don’t detect it, and then either removing it themselves or waiting for you to do it for them and signing it off as low-risk, attackers can map out effective hiding places where their future attack tools will go unnoticed anyway. If you’ve excluded certain directories from scanning for performance reasons, or exempted certain processes from inspection for convenience reasons, and if that’s what the attackers want to test, then knowing in detail what their decoy malware is capable of won’t help to inform your response.

What to do?

Does this mean that malware descriptions are now worthless? Are the experts amongst us who write explanatory articles about new threats wasting our time?

No, not at all.

But modern malware sometimes doesn’t lend itself to having its evil behaviours mapped out in advance, and sometimes doesn’t reveal its immediate purpose anyway, even if you have detailed articles about it sitting right in front of you.

That’s something to take with you into every threat hunting engagement, no matter how trivial it might seem at the time.

(Don’t forget: if you’re finding it hard to keep on top of new threats that attackers have made unknowable by design, you can always call in the cavalry!)

PS. If there are any knotty topics you’re keen to see us cover, from malware analysis and exploit explanation all the way to cryptographic correctness and secure coding, please let us know. DM us on social media, or email the writing team directly at amos@solcyber.com.

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!

Photo credit: Image of magnetic core memory by Konstantin Lanzet sourced here, licensed under Creative Commons.

Paul Ducklin
Paul Ducklin
Share this article:

Table of contents:

The world doesn’t need another traditional MSSP 
or MDR or XDR.

What it requires is practicality and reason.

Related articles

The world doesn’t need another traditional MSSP or MDR or XDR.
What it requires is practicality and reason.

And security that won’t let you down. It's time to put an end to the cyber insanity once and for all.
No more paying for useless bells and whistles.
No more time wasted on endless security alerts.
No more juggling multiple technologies and contracts.

Follow us!


Join our newsletter to stay up to date on features and releases.

By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.

SolCyber. All rights reserved
Made with
Jason Pittock

I am interested in
SolCyber XDR++™

I am interested in
SolCyber MDR++™

I am interested in
SolCyber Extended Coverage™

I am interested in
SolCyber Foundational Coverage™

I am interested in a
Free Demo