What’s in a name? How attacks and attackers get their tags (Part 1 of 2)

A rose by any other name

Threat naming has been a troublesome issue since the very early days of hackers and malware.

Not, perhaps, so troublesome that it has caused any sort of long-term crisis in threat research and threat response, but tricky enough that it has sometimes got in our way.

And anything that buys cybercriminals even the tiniest bit of extra time, or amplifies their attacks even modestly, is worth thinking about.

In the early days of the virus-writing scene, new malware samples were unusual, and the difficulty of writing truly new malware variants meant that exciting names were often chosen.

For example, the very first mass-mailing virus (a harbinger of malware such as the infamous LoveBug and Anna Kournikova viruses more than a decade later) disguised itself with a crude, text-based image of a Christmas tree alongside a cheery seasonal greeting.

The virus was serious enough to bring the the global academic network BITNET and IBM’s own VNET network to a halt, due to the huge amount of unwanted network traffic it generated.

The media-friendly name Christmas Tree worm caught on, and it helpfully described what it looked like when it ran.

But the words “Christmas Tree” described a characteristic of the malware that revealed itself too late to help worried users to prevent the virus, because the tree and its bogus greeting was aimed at distracting you believably in the foreground after the malware attack had started in the background.

As threat names go, this one wasn’t as helpful as it could have been.

Cybercrime in Jerusalem

Another virus of that early era, this one for MS-DOS computers, also illustrates how threat names can be memorable but at the same time confusing and even misleading.

The Jerusalem virus also first showed up in late 1987, although the destructive payload it contained was programmed not to happen until 1988 at the earliest, presumably to give the virus a chance to spread for a while without drawing attention to itself.

The name comes from the fact that it was first spotted at the Hebrew University of Jerusalem and written up in detail by a computer scientist called Yisrael Radai, who later coined the shorthand term malware that we still use as a handy way of referring to malicious software of all sorts.

But some anti-virus researchers were determined that the malware names reported by their products should include some useful information about the threat to which they referred, such as by using a number that denoted how many bytes were added to program files after they were infected.

Under this protocol, the Jerusalem virus acquired the name 1813, because every infected .COM file became exactly that many bytes bigger than it was before.

But MS-DOS at that time supported two quite different formats for programs, known as COM and EXE, and this virus had different techniques for infecting them, such that infected ..EXE files grew by 1808 bytes instead, so some anti-virus products used the name 1808, not 1813.

And the virus ended up with a third name that the media (and indeed the public in general) found just too good to ignore: Friday the Thirteenth, because on those days, and those days alone, the virus stopped spreading and started deleting files instead.

It didn’t help that Jerusalem was one of the most copied and modified viruses of its era, and that at least some of those variants deliberately capitalized on the naming confusion.

For example, some variants triggered on Saturday the Fourteenth or Sunday the Fifteenth instead, thus catching out people who tried to “inoculate” against the original variant by advancing their system clocks.

Other variants adjusted their infectious size to match that of unrelated, possibly less harmful, strains of malware in the hope of being treated less urgently.

A hypothetical example

The sort of problem that inconsistent threat reports can cause due to naming differences, which can happen even when multiple products from the same vendor are involved, can be seen in the following hypothetical example.

Imagine that:

1. Some incoming email attachments are being quarantined or deleted outright, logged as infected with the Win/Dangerbot-WOO malware.
2. Some laptops are flagged as actively infected, logged as malware called Trojan:Generic.A.
3. Some network firewalls are reporting connections to known cybercrime sites, flagged as related to malware known as Win.Botnet!E9654429.

But what does this mean, and how many malware incidents are involved?

Was the Dangerbot attack via email reliably and completely repulsed, so that the simultaneous infection reports on laptops represent a completely unrelated attack by a different attacker, using completely different malware about which you can infer nothing because it is tagged by the meaningless name Generic?

Or did the email filter miss some Dangerbot samples and allow them to reach users’ laptops and spring into life, thus representing a single attack with unreliable detection, so that Dangerbot and Generic turn out to be two names for the same thing?

If Dangerbot is sufficiently hard to find that the email scanner did only a partial job of blocking it, could there be active samples of this malware in your network that should have been caught as Generic but were also missed by your endpoint detection and response (EDR) tools?

And if there really is Botnet malware inside your network that is known to be calling home as part of a botnet (short for software robot network), how does that behavior relate to the other two reports, if at all?

Taxonomies and naming schemes

Many attempts have been made over the past few decades to concoct official taxonomies or naming schemes in the hope that different threat detection and threat response products would produce compatible, consistent and non-contradictory results.

One often-suggested “solution” that has appeared many times over the years is simply to copy weather forecasters, and agree a list of names in advance, like British, Irish and Dutch meteorologists do at the start of each winter storm season, running predictably through the alphabet. (If they run out, they just start again from A with a new list.)

But this rational-sounding and objective approach simply doesn’t scale to the field of threat detection and classification, because new malware samples appear at such a high rate that no one can agree on how many new samples they really are, let alone count them precisely.

Fortunately, the huge quantity of previously unknown malware samples that show up each day is not as alarming as it might first seem, because few of them are truly new.

To be “new and unique” in this case means simply that at least one bit in the file is different, such as one character in a text message, or the timestamp added to the file header when it was compiled.

Dealing with the flood of new samples is greatly assisted by online services such as Google’s VirusTotal, where you can cross-reference malware names between different threat detection tools by entering the checksum (SHA256 is recommended) of a suspicious file on your computer.

The service checks whether any of more than 70 malware scanning products detect it, and if so what each product calls it.

This is useful because it automatically provides a real-time cross-reference that helps to disambiguate detection uncertainties, as in our hypothetical example above where we were faced with the unhelpful threat names Dangerbot, Generic, and Botnet, all at the same time.

If the sample is not detected by any product, you can optionally upload the file itself, if you’re sure it doesn’t contain any protected or sensitive data, and the service will securely share the file with researchers whom the service trusts, including detection experts at the vendors on the scanning list.

Malware naming is not enough

Unfortunately, even if the rate of new malware samples were much lower, and some form of storm-style, agreed-in-advance malware naming list were possible, it would still be as good as impossible to be sure what side-effects a malware sample may have had, or which other malware might be lurking undetected in your network, no matter how precise the threat names already in your logs.

That’s because a large proportion of modern malware samples aren’t pre-programmed only to carry out a fixed list of evil activities, in the way that the Jerusalem virus was hard-wired to delete files deliberately on Friday the Thirteenth.

Downloaders, for example, connect to a possibly wide range of different rogue websites (some of them use a secret algorithm to generate a list that changes from day to day, so there is no text-based list of URLs you can extract from the code), and serve only to “update” themselves to an unknown and unguessable new malware sample.

Each sample may be uniquely re-compiled for each download, to ensure that no two are identical, or chosen based on the victim’s location, operating system type, network connection speed, time of day, or preferred language.

Even researchers who diligently download hundreds or thousands of different samples in an effort to deduce the behavior of a downloader and the servers it connects to may learn nothing, because the malware samples they receive may never be seen again, or may be deliberately chosen to be different from what a real-world user would see, in order to deceive the researchers.

Bots, also known as zombies, almost always offer a similar “feature” in the form of a remotely triggerable command that instructs the zombie malware to download new, additional malware from a previously-unknown server.

Many bots can also replace themselves entirely with an “upgrade”, for example to switch out a zombie sample that has become known to VirusTotal with one that hasn’t.

Threat categories and how to name them

Similar naming problems exist with the terminology we choose to refer to specific classes of cyberattack, from phishing emails that lure you into installing actual malware, to human-based scams in which cybercriminals induce you to hand over money but give nothing in return.

One issue with naming cybercrime threat categories, rather than just naming individual threat samples, is the possibility of demeaning or insulting the victims rather than the perpetrators.

We wrote about this sort of naming dilemma last week when we discussed online investment scams known colloquially as “pig butchering” because those are more or less the words used by the criminals themselves to describe just how deep their contempt for their victims goes.

In these scams, the attackers aren’t after stealing some money.

It’s part of the process to go after the victim’s entire savings pot if possible, and to butcher their lives entirely, like farm animals fattened for slaughter.

Some observers, notably INTERPOL, argue that this demonizes victims and makes it less likely that they will seek help or report the crimes against them, and therefore propose to start calling this sort of scam by the name “romance baiting” instead.

This alternative name is based on the observation that the first wave of criminals who pursued this type of investment scam commonly used dating sites as a way to make initial contact with their victims.

Unfortunately, many of these criminals were very careful not to suggest that they had any romantic interest in their potential victims, even though they first met up first on a dating site.

The criminals often went out of their way to make it clear that there wasn’t a romantic spark, but that they were happy to engage in some friendly, short-term, chat, as if out of politeness.

Also, these “pig butchers” started using numerous tricks other than dating sites for forging their first contact with potential victims.

Calls and text messages that look like wrong numbers, or misdirected social media postings that suggest nothing more suspicious than a typing error of the recipient’s name, are popular ruses that these scammers use today, with dating site “introductions” now only one of many ways that attackers spread their nets.

Clearly, referring to investment scams by the name “romance baiting” invites at-risk internet users to watch out for the wrong thing, especially if no dating site is involved, and the notion of a romance never even comes up.

Advance fee fraud

We faced a similar problem in the 2000s and early 2010s, when scammers who often turned out to be operating from Nigeria worked their social engineering skills against vulnerable or desperate victims, and admittedly sometimes against victims who were themselves greedy, unprincipled, or even criminally-minded themselves.

These scammers used a mixture of charm and pressure to lure victims into wiring them cash, which could not be recovered by any bank, to be used as bribes or legal fees to get access to projects or funds that were tied up or frozen for a variety of vaguely plausible reasons, such as incompetence, corruption, or missing documentation.

These crimes became widely known as “Nigerian scams,” which was not only unfair to the many honest residents of Nigeria, by far the most populous country in Africa, but also misleading because the name gave no hint of how the scam actually worked.

Even worse, it gave scammers who were indeed based in Nigeria the opportunity to pretend to be anywhere else in the world, from South Africa or Ghana to the Netherlands or Australia, and therefore to sidestep any warning implicit in the name “Nigerian scam.”

Eventually, the more useful term advance fee fraud, or AFF for short, was widely adopted to indicate the nature of the crime (send money now in the hope of getting into a profitable deal later), rather than naming just one country from which this scam might seem to originate.

What to do?

• Don’t get married to jargon. Use plain English as much as you can. “Pig butchering” sounds dramatic, and it may be the term that some experts and the media are using, but it isn’t very helpful. As well as being potentially offensive to victims (and why be rude when you simply don’t need to be?), it needs insider knowledge to decode its meaning. If a “pig butcher” is trying to lure victims into an investment scam where they will lose money, perhaps lots of it, just refer to it as “an investment scam” instead.
• Don’t worry too much about threat names these days, not least because some vendors may offer you “identifications” no better than Generic or AI. But even if you can identify a malware sample exactly, and have access to a detailed research paper that lists exactly which malicious functions it includes, you may well be dealing with a tiny part of a much more complex and un-named attack that was enabled by the named malware you know about.
• Don’t rely entirely on AI and automation. Invest in building a cybersecurity culture, based on communication in plain English, to build resilience against the human issues involved in many attacks. Social engineering in which criminals coerce or persuade staff to do the wrong thing, such as sharing private data or entering a password into a rogue website, often succeed even if there is no malware or traditionally-detectable “threat” involved.
• Don’t be afraid to ask for help. Staying on top of cybersecurity incidents as they occur is hard enough on its own, even before you work on improving your internal security culture. SolCyber focuses on delivering a human-centric managed security service that includes a security operations center (SOC) so you don’t need one; provides ongoing training, awareness and cybersecurity culture development; and sits down with you for regular security reviews. Learning millions of threat names and navigating thousands of threat-related jargon terms doesn’t have to be your job. SolCyber will take care of those details for you, all the while communicating with you in plain English.

Now read 🔗 Part 2, where we tackle topics including: how to decode the names given to the very bugs and security holes that open up networks to security exploits, and how to make sense of the names given to the threat actors themselves.

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!

Featured image of red roses by Biel Morro via Unsplash.