Steve Gibson (105:32)
Wow. Okay, so everybody, this is just. First of all, okay, first I want to thank our listeners who sent me a heads up about this. My first thought upon seeing just the headline was that it might be little more than a passing note, but the truly oh, Leo, diabolical and clever nature of what was achieved by unknown but suspected agencies caused this to stand stand out on a scale similar in scope to Britain's deliberate secrecy once they had unraveled the operation of Germany's Enigma machine. You know, keeping their discovery a secret was diabolical. And so is what was accomplished by the FAST 16 sys file system driver. The same year as this podcast started and well before five years before Stuxnet. So last Thursday, the Sentinel Labs group of the Sentinel 1 security research firm posted their piece about what they discovered and how that happened. Their piece was titled Fast 16 Mystery Shadow Brokers Reference Reveals High Precision Software Sabotage Five Years Before Stuxnet. Remember, the Shadow Brokers was the leak of the internal NSA stuff. Turns out there was some clues in that. So they wrote. Our investigation into Fast16 starts with an architectural hunch. A certain tier of Apex threat actors has consistently relied on embedded scripting engines as a means of modularity. Flame, Animal Farms, Bunny plexing, Eagle, Flame 2.0 and Project Sauron each built platforms around the extensibility and modularity of an embedded LUA vm. We wanted to determine whether that development style arose from a shared source. But like, where? How did they all. How did all these individual actors get this idea? So they said. So we set out to trace the earliest sophisticated use of an embedded LUA engine in Windows malware. They write LUA is a lightweight scripting engine with a massive. I'm sorry, with a native proficiency for extending C and C functionality. Given the appeal of C for reliable high end malware frameworks, this capability is indispensable to avoid having to recompile entire implant components to add functionality to already infected machines. We did not find an indication of direct shared provenance. But our investigation did uncover the oldest instance of this modern attack architecture. LUA leaves a distinctive fingerprint. Compiled bytecode contains compiled bytecode containers. Start with the magic bytes 1b4c7561 in hex followed by a version byte, and the engine typically exposes a characteristic C API and environment variables such as LUA path Hunting for These traits across mid 2000s malware collections surfaced. A sample that initially looked unremarkable was titled Service Management SVC mgmt EXE Surface Service Management EXE on the Surface, Service Management XE appears to be a generic console mode service wrapper from the Windows 2000 XP era. A closer look reveals an embedded Lua 5 virtual machine and an encrypted bytecode container unpacked by the service entry point, meaning when the service is loaded, it's then initialized. And at that point this Lua 5 virtual machine reads this encrypted bytecode container and unpacks it. The developers of this executable extended the LUA environment to include a wide string module to provide native Unicode handling. You know, dual byte 16 bit characters as opposed to single byte characters. A built in symmetric cipher exposed through a function commonly labeled B used to decode embedded data. The multiple modules that bind directly into the Windows NT file system, the Registry, service control and network APIs. Even by itself, Service Management XE already looks like an early high end implant. A modular service binary that hands most of its logic to encrypted LUA byte code. The binary includes a crucial detail, a PDB path that links the binary to the kernel driver fast 16 sys. Okay, I'll interrupt here to say that anyone who's developed code using Microsoft's tool chains will be familiar with its creation of PDB files. Even I, because I'm using their, their linker to link my assembly code. I've got, you know, PDB files, you know, DNS, bench.pdb coming out my ears. They're everywhere if you're using Microsoft tools. So, so they said so so anyway, so, so what Sentinel Labs, the researchers are saying here is that their, their search for the earliest instances of the use of LUA scripting in malware turned up a reference to something unknown and unsuspected, which was a Windows kernel driver named fast16sys. So they continue writing. Buried in the binary strings is that PDB reference to C colon backslash buildy backslash driver backslash FD backslash i386 fast 16 PDB. At first glance, they write, the path is structured like any other compiler artifact, an internal build directory, a component name fast16 and an architecture hint i386. However, in this case there's a mismatch. The string appears inside of a service mode executable. And yet the driver FDI386 fast 16 segment of the PDB string clearly refers to a kernel driver project. Following that clue led us to examine a second binary fast 16 sys, which I'll just note they wouldn't have otherwise known to look for. But the point is that this the the the clue of this PDB reference. They realized this was not a part of a service, this was part of a kernel driver. Why was a kernel driver in a service and why. What is fast 16 sis? They wrote this kernel driver is a boot start file system component that intercepts and modifies executable code as it's read from disk. Although a driver of this age will not run on Windows 7 or later, for its time, fast 16 sys was a cut above commodity rootkits, thanks to its position in the storage stack, control over file system, IO and rule based code patching functionality. Okay, again pausing to add some clarification. What this means is that this is a rootkit, plain and simple. It's marked for boot time loading by the operating system, which is busy loading all manner of random stuff to get Windows up and running. But in this case, when fast 16 sys kernel rootkit is loaded and initialized, its initialization code, which happens immediately upon its loading, that code immediately installs interception hooks deep into the operating system so that it is able to subsequently oversee and interfere with whatever it might wish to. So they continue. In April 2017, almost 12 years after the compilation timestamp, the same file name fast16 appeared in the Shadow Brokers leak, which refers to a text file drive underscore list text drv list text. They said the 250k byte file, which is a text file, is a short list of driver names used to mark potential implants cyber operators might encounter on a target box as friendly or to pull back in order to avoid clashes with competing nation state hacking operations. And then we have a sample from their posting. The report shows A snapshot of five lines from the Drive_list TXT file of file identifiers. Four of the five lines identify the malware by name. Misty Veal Net, Spider, Olympus, and Petal Cheap, each with a file name like net, h, d, LR or khlp807w. But the entry for the fast 16 driver does not show any malware name. Somewhat ominously and unlike any of the others, it says nothing to see here, carry on. So someone somewhere knew to just leave this one alone and said so without identifying why or who or what it was, the researchers wrote the guidance for this One particular driver, Fast 16, stands out as both unique and particularly unusual. The string inside service management exe provided the key forensic link in this investigation. The PDB path connects the 2017 leak of deconfliction signatures used by NSA operators with a multimodal Lua powered carrier module compiled in 2005 and ultimately its stealthy payload, a kernel driver designed for precision sabotage. And we're going to get to the precision sabotage in a second. So just to back up recall that the Shadow Brokers leak, as I mentioned before, was believed to be a publication of secret documents stolen from the Equation Group that was believed to be a group within the nsa. So the evidence is suggesting that that all these other files were associated with known malware from other actors. But the fast 16 sys driver was not that. If you see it, leave it alone. Nothing to see here. These are not the droids you're looking for. The flag was to back off. So they said the core component of fast 16 service management XE functions as so the the core component the that is to say the service management XE functions functions as a highly adaptable carrier module, changing its operational mode based on command line arguments, no arguments. It runs as a Windows service with a hyphen p it install. It sets the install flag to 1 and runs as a service. So that means propagate, install and run with a hyphen I that sets install flag to 1 and executes the Lua code, meaning install and execute Lua. If if the argument has a hyphen r that executes LUA code without setting the install flag, so just execute any other argument such as a file name, interprets that as a file name, and spawns two children, the original command and one with the hyphen r argument. So that's the so called rapsi or the wrapper or proxy mode. So they said Internally, Service Management XC stores three distinct payloads, including encrypted luabyte code that handles configuration, its propagation and coordination logic, auxiliary con, notify DLL, and that fast 16 syske kernel driver. By separating a relatively stable execution wrapper from encrypted task specific payloads, the developers created a reusable compartmentalized framework that they could adapt to different target environments and operational objectives while leaving the outer carrier binary largely unchanged across campaigns. In other words, this was an extremely sophisticated design. They Continue the early 2000s saw a large number of network worms. Most were written by enthusiasts, spread quickly and carried little or no meaningful payload. FAST 16 originates from the same period, but follows a completely different pattern, indicative of its provenance as state level tooling. It's the first recorded LUA based network worm and was built with a highly specific mission. The carrier was designed to act like cluster munition in software form, able to carry multiple wormable payloads, referred to internally as wormlets. The Service Management XC module performs the following steps. First, prepares the configuration, defining the payload path, service details, and target IP ranges. Next, converts the configuration values to wide character strings for the C layer. Third, escalates privileges and installs the carrier executable as the service management service, then starts it. Fourth, optionally based on the configuration setting, deploys the kernel driver implant fast 16 sys. Next releases the wormlets. In this particular configuration, the wormlets release the wormlets.
