You’ve probably heard of the MITRE ATT&CK framework, a public-private partnership funded by the US federal government that aims to maintain a comprehensive and continually evolving chart of the many different TTPs (as the jargon calls them) that cybercriminals use against us.
The abbreviation TTPs is short for tactics, techniques and procedures, and has its roots in the military terminology that has been widely adopted in the cybersecurity industry.
Keeping track of TTPs helps in two related ways:
The challenge of using the ATT&CK framework effectively is that it’s huge and tricky to master.
The Enterprise Techniques page alone, for example, lists 202 techniques and 435 sub-techniques:
Rather than fretting about the daunting size of the ATT&CK matrix, however, we’re going to jump right in and focus on just a few of its entries, discussing them as a whole rather than as a bunch of separate islands in the whole framework.
(If you want to follow along in the ATT&CK table, we’ll be touching on at least the following: T1027.011, Obfuscated Files or Information: Fileless Storage; T1620, Reflective Code Loading, and some of the sub-techniques of T1055, Process Injection.)
The importance of these so-called fileless techniques is that they form part of cybersecurity that lends itself to dramatic headlines, not least because malware that uses these tricks is often pitched as “undetectable”.
As we discussed in a previous article, “undetectable” malware clearly isn’t, at least if we know enough about it to write it up (after all, if it were truly undetectable, we wouldn’t know it existed to start with).
Nevertheless, threat response is often much easier when malicious content is directly contained in one or more files that already exist on disk, because those files can be seized, copied, saved, and analysed offline.
Many early malware samples were deliberately and astonishingly complex, but they were usually coded as self-contained programs known in the jargon as viruses, simply because few users had internet access, and therefore were rarely able upload and download files on demand.
Malware was therefore deliberately coded to spread itself, for example by copying itself across local networks (LANs), by infecting hundreds or even thousands of pre-installed programs on the current computer, or by copying itself to floppy diskettes as soon as they were inserted, so that those disks would surreptitiously be turned into virus carriers of their own.
In other words, as soon as you could isolate an infected file, you usually had a self-contained copy of everything you needed to replicate the behaviour of the malware for yourself, without needing to connect to any specific internet-based services, or even to be online at all.
For many years, malware “zoo collections” typically consisted of a huge sea of files, in which most (though admittedly not all) samples consisted of a single file.
From these zoo samples, you could create as many copies, or replicants (a jargon term borrowed from the seminal 1982 science fiction film Blade Runner) as you wanted.
Complexity in anti-malware research generally came from the challenge of extracting and deconstructing the malevolent code in the samples you’d already collected, rather than in collecting and collating the underlying components of the malware in the first place.
Modern malware, of course, can usually rely on an active internet connection, doesn’t need to be completely self-contained, and rarely re-distributes itself in the style of early viruses.
This greatly reduces the level of suspicious activity it generates, given that programs deliberately making hundreds of thousands of copies of themselves attract immediate attention.
Nevertheless, many if not most malware attacks still leave behind some kind of permanent, detectable and recoverable trace in the form of files on your hard disk.
Capturing file-based artefacts for analysis is still an important part of threat response, both by automated anti-malware software and by human-led threat hunters who work in a SOC.
Now imagine that you could unleash a malware attack that saved nothing to disk at all – no files of its own; no temporary files; no logs; and no other disk-based artefacts.
That would make life much harder for threat hunters.
Unfortunately, fully fileless malware is indeed possible, and as we wrote in a previous article about “undetectable” cyberthreats, some of the fastest-spreading computer viruses in history have taken that approach.
The infamous Code Red worm of 2001 and SQL Slammer in 2003, for instance, arrived in network packets that were supposed to be plain web requests and database lookups.
By triggering directly exploitable vulnerabilities in the IIS web server and Microsoft’s SQL server respectively, these attacks immediately took over the running servers, which began blasting out new copies of the malware themselves.
SQL Slammer, for example, fitted entirely into a single unexceptionable network packet, with no files or even file-like content created at any time:
In the early 2000s Windows had negligible protection against memory buffer overflows, making self-contained, fileless malware attacks of this sort much easier to come up with than they are today.
The intensity of the Code Red attack, which anti-malware security products of the day weren’t really designed to deal with, and which threat responders weren’t really used to watching out for, led to a famous email in early 2002 from Bill Gates to all staff at Microsoft with a pithy subject line: Trustworthy computing
.
This resulted in buffer overflow protections being retrofitted to Windows, even if they didn’t quite arrive in time to head off the SQL Slammer outbreak.
The virulence of Code Red even led to a dramatic nickname for this sort of attack: Warhol Worm, a term intended to echo the saying “in the future, everyone will be world-famous for 15 minutes,” often wrongly attributed to pop artist Andy Warhol.
Make no mistake, the fact that both these worms spent their executable lifecycle entirely in computer memory after being set loose, combined with their dramatic spreading speed, made them tough to deal with.
With its single-packet construction and with no file-based artefacts created during or after infection, SQL Slammer was particularly hard to spot using a traditional “search all disks for any rogue content left behind” approach.
But even totally fileless malware is not truly undetectable, whatever news stories might imply, for the reasons we mentioned earlier.
Once we have learned enough about the malware, we can identify and isolate infectious samples by grabbing them right out of memory, though this often require riskier and more intrusive tools than simply scanning through files on a hard disk.
Digging into memory inside live processes is generally trickier than peeking into files on a hard disk, because there’s a lot that can go wrong.
Likewise, human threat hunters from the SOC who decide to dig through the running processes in a suspect system have to be careful in their approach.
Coders who are developing and debugging their own code on a test system generally have the luxury that there aren’t any live servers or real-life customers to worry about, so they can be aggressive in how much they interfere with, and how many measurements they take from, running programs.
Live threat hunters typically don’t have the same liberty, not least because their spelunking could reveal data that’s not really supposed to be seen or saved, such as passwords in transit or payment card data, and because digging in too deeply could cause the software to misbehave or crash.
Fortunately, pure-play memory-only malware presents an operational challenge to cybercriminals, too.
The problem with memory-only malware is something known in the jargon as persistence, a word you’ve probably seen in the phrase advanced persistent threat, or APT for short.
For all the excitement implied by the name APT, advanced often boils down to ‘it got past us’; threat refers to ‘some sort of cyberattack’, usually involving malware; and persistent loosely means ‘survives a reboot’.
While cybercriminals will take any foothold they can get, no matter how slight or transient, they usually prefer to implant a persistent threat, even if it means leaving behind additional artefacts that can be used by defenders to detect the intrusion.
That is why most so-called fileless malware includes at least some, and sometimes several, non-fileless components that can, with the right knowledge and diligence, be used to spot an attack.
As an aside, both Code Red and SQL Slammer could be disinfected simply by rebooting, as inconvenient as that might have been for some servers. Sadly, unless the computer was patched at the same time, re-infection was likely, given that already-infected devices sent out a continuous stream of infectious packets to other computers chosen pseudorandomly from the internet. And even you did patch your own systems, that alone wasn’t enough to stop other computers from flooding your servers with unsuccessful re-infection attempts.
Sadly, there is a whole raft of techniques that attackers can use to confuse threat responders, creating what we might call partly fileless malware.
One collection of tricks involves using popular programming languages including Java, C# and PowerShell that can create programs that look innocent when stored on disk, but that generate, load and execute completely different code once they’re started up.
Traditional programming languages such as C and C++ can’t easily do this, because self-descriptive Windows functions such as CreateProcess()
and LoadLibrary()
can only load up software that’s already stored on disk as a file.
That’s because the API, or application programming interface, only accepts a filename as the location of the new code:
C#, as it happens, provides a similar function called Assembly.LoadFile()
and Assembly.LoadFrom()
, which tell the C# subsystem to load in new code from a disk file whose name you provide.
(In case you’re confused, assembly in C# doesn’t refer to the well-known term assembly language, a low-level way of representing raw machine code when you are programming, but simply to a chunk of pre-compiled C# code.)
But C# also offers the function Assembly.Load()
, which does much the same thing, except that you can launch your new code directly from data you’ve put together in memory:
As you can probably imagine, cybercriminals love this way of loading software, because they can fetch the program they actually want to run from almost anywhere, such as directly into memory from a remote website, or extracted from a hiding place in an apparently unrelated file such as an image or a document.
Once the rogue code is extracted, unscrambled and executed, it essentially becomes a piece of fileless malware with no obvious counterpart on disk.
Another trick involves quite deliberately leaving a trail that leads from an active copy of the malware in memory to a clearly-identified file on disk…
…that is an innocent and unexceptionable system file serving as a decoy.
There are many variations on and jargon terms for this sort of attack, but ones you may have encountered are reasonably self-descriptive, including code caving, process injection, and process hollowing.
Process injection and process hollowing are moderately complicated to implement, but in simple terms they work something this:
NOTEPAD
or another widely-known system utility. This program will serve as an innocent bird’s nest, or ‘carrier program’, into which the nefarious code you intend to run will be inserted like a cuckoo’s egg..EXE
file.The final trick we’ll look at here involves saving program code in a system database such as the Windows registry.
Strictly speaking, items in the Windows registry aren’t truly fileless because they’re committed to disk somewhere, stored in a number of proprietary, system-managed files known as hives.
In practice, however, registry entries are as good as fileless because those hive files can’t easily or usefully be scanned in traditional file-based ways.
There are dozens of different locations in the Windows registry that keep track of programs that the operating system will run when certain system events take place, including: whenever the system starts up; when the system next starts up; whenever anyone logs in; and whenever certain other programs are used.
These registry entries can easily be abused to run code that’s stored right inside the registry itself as a chunk of text.
If you have ever used one of Microsoft’s popular scripting engines such as PowerShell or the Microsoft HTML Applications (MSHTA) tool, you’ll know that you can run script programs in two different ways: either by saving the script into a file and launching that file, or by putting the script directly on the command line when you invoke PowerShell or MSHTA.
By using the registry not only to tell Windows to run the scripting engine of your choice, but also to provide the code you want to run, you no longer need to save your rogue script code into a regular disk file:
This forces malware detectors and threat responders to dig into a list of known hiding places in the registry, using special, registry-specific API functions instead of simply opening and reading regular files.
PowerShell even gives attackers the special command-line option encodedCommand
that allows complex, multi-line scripts to be packaged into base64-encoded text strings, which simultaneously shrouds the code from view and passes it filelessly into the PowerShell scripting engine.
Even truly fileless malware will generally leave some evidence of its arrival and execution, for example in network and firewall logs.
Once you you know what to look for, and how to be selective enough about capturing actionable data without harming privacy or overloading your network, you have a fighting chance of catching the malware to learn how it works, and how to detect and fix it.
Other fileless malware tricks such as the ones described above can be often be unravelled using tools such as: the Windows event log viewer, behaviour monitoring software provided by endpoint security applications, debuggers and process profiling tools, Microsoft’s own handy Sysinternals utilities, and more.
The challenge, of course, is finding both the time and the expertise to keep on top of all currently-known techniques, and mastering the latest tools for capturing the evidence when needed.
The MITRE ATT&CK matrix can help with this, of course, but bear in mind that the ATT&CK framework is already copious, and expanding all the time.
Why not ask how SolCyber and its human-led SOC can keep on top of cybersecurity for you, leaving you free to focus on the things that matter directly to you and your business?
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 by Mike Tinnion under the Unsplash License.