Why Stuxnet Isn't APT

...or at least, shouldn't be considered as such...

Stuxnet has become so buzz-worthy that I almost feel like an article relating it to "APT" is the epitome of anecdotal industry navel-gazing. Making a qualitative assessment of each can be a useful exercise in classifying and understanding the threat landscape, however. This in turn helps clarify risk, driving resource allocation, investment, and R&D. Even more important than the conclusions presented herein, I want to elucidate some of the analysis that goes into threat assessments so that others might be empowered to do the same. At the same time, do not interpret this as an exhaustive or 'correct' methodology, but rather a single case study.

So many unrelated conversations these days seem to drift toward the inclusion of Stuxnet that I'm beginning to see it like the invocation of a Hitler analogy in modern US political debates. There's a lot to be said about this event, to be sure, but I feel we can do much better in understanding similarities and differences in various threat landscapes, thus my initial motivation to write this article. The bottom line is that I feel we do both Stuxnet and APT a disservice by classifying the former into the latter, and worse yet, confuse what could otherwise be informed threat-oriented decisions on CND.

Intent

Often, the intent of an actor is inferred based loosely on observations by analysts tracking down impacted systems, targets, and entry vectors. I'm going to stick to the observable properties of Stuxnet, in comparison to what I feel is consensus on APT as used by those of us in the DoD/DIB community (where the term originated).

The first clear divergence of Stuxnet from APT is in targeting. Although it has been said that the intended target of Stuxnet was China/Iran/Mars/Your Mom, in practice, this operation targeted all machines with a certain configuration controlling certain devices. The target selection/recon is conveniently embedded in the Stuxnet code, leaving little room for interpretation of how this occurs. Infected systems seek other victim systems for propagation at OSI layers 3 & 4. This is fundamentally different than APT intrusions, which target users. The code intends to spread to machines with certain configurations, that perform certain functions. Again, this is different than APT intrusions, which usually focus on accessing data describing certain technologies. Though nuanced, that difference is very important.

Scope, or visibility, is another area where Stuxnet differs from APT intrusions. Whereas most (but not all) APT intrusions focus on a small set of targets, Stuxnet will propagate promiscuously, regardless of whether the target system contains the desired configuration, or is even a SCADA system at all. This scalpel-versus-hammer distinction, as well as the manual/automated target selection, bears no resemblance to APT intrusions. Somewhat aside, it also makes the probability of discovery very high as compared to APT intrusions, and its broad impact allows for a sort of "analytical economies of scale" benefit that we see with other widespread viruses and worms. This alone can fundamentally alter a defensive strategy.

Objective is another divergent characteristic between the two, and is quite straightforward in one sense: Stuxnet impacts integrity, with the end goal of impacting availability. Thus, Stuxnet is an attack tool, putting it under the CNA umbrella. APT intrusions have been exclusively CNE, and will almost necessarily remain so by definition. Quite related, this objective of Stuxnet is inherently tactical. APT intrusions take the form of campaigns over extended periods of time, and behaviors demonstrate that adversaries will persistently launch intrusions, and/or desire persistent access to targeted environments. These "campaigns" are strategic intrusions by their very nature, which provides for important Intel-driven CND opportunities that may be very different, or missing altogether, from Stuxnet.

Capability

The level of sophistication of Stuxnet is by every account very high. The code is relatively difficult to reverse engineer, contains a PLC rootkit, multiple zero-day exploits, and code that can run on processors with different chipsets. More often than not, the binaries in APT intrusions are relatively straightforward, and exploit a single vulnerability most often in client applications. This enables the adversary to "hide in plain sight" without triggering any heuristic attention through various code obfuscation and file hiding techniques that tend to leave unusual artifacts. After all, with a small target space, the likelihood of discovery is low, and analytical economies of scale will not apply for APT intrusions, meaning survivability against RE efforts is less important to build in.

The role of command-and-control (C2) in Stuxnet achieving its objectives is quite different than conventional APT C2. This capability exists for remote code updates to be distributed to systems infected by the worm. Unlike Stuxnet, the process of achieving objectives in APT intrusions is not necessarily straightforward once a system is compromised. Systems must be manipulated manually for the surgical removal of data, and to facilitate lateral movement within an environment that the intruder may have no, or limited, a priori knowledge of. Backdoors used in APT intrusions therefore either provide a much more robust command set, or funnel keystrokes sent via the channel to a command shell. These differences in C2 role and capability, objective automation and manual intervention, present both opportunities and challenges for CND that are different for Stuxnet and conventional APT intrusions.

So What?

Because of the numerous fundamental differences between Stuxnet and canonical "APT," intelligence-driven CND for each will necessarily be quite different. I would even say it's difficult to find a single attribute clearly shared by the two. If we classify Stuxnet as APT, then one of two things must happen: either we must remove certain attributes from our APT definition so Stuxnet will properly fit that criteria, or we ignore the divergent attributes of Stuxnet. It's easy to see that either case would leave us with fewer strategic approaches to CND that would be effective against both. By keeping them separate, we can consider each with enough specificity for effective CND, and depending on the industry, choose to prioritize one over the other.

Michael is a senior member of Lockheed Martin's Computer Incident Response Team. He has lectured for various audiences including SANS, IEEE, the annual DC3 CyberCrime Convention, and teaches an introductory class on cryptography. His current work consists of security intelligence analysis and development of new tools and techniques for incident response. Michael holds a BS in computer engineering, an MS in computer science, is working towards a PhD in systems engineering, has earned GCIA (#592) and GCFA (#711) gold certifications alongside various others, and is a professional member of ACM and IEEE.