Over the years, changes in the threat landscape have made attribution more difficult. Attribution has always been challenging, but has been and can continue to be eased through visibility. That is, if your view into an event or campaign is limited to resources such as malware samples pulled from public repositories, then attribution can be challenging. Even adding information regarding infrastructure extracted from the sample configs can still give a somewhat limited view. However, as visibility is expanded to include data from intrusions and incidents, attribution becomes clearer and more granular.
I ran across A Complex Threat Landscape Muddles Attribution recently and found it to be a fascinating, insightful read, one that anyone involved in threat intelligence, even peripherally, should take a good, thoughtful, intentional look at, marinate on it, and then contribute by sharing their own and thoughts and insights. This isn't something that you should just read over once, check the box that you read it, and move on.
I thought I'd take a few minutes to share some of my own thoughts. I'm not what anyone would refer to as a "threat intelligence professional". I don't have a military or LE intel background. However, what I am is a DFIR professional who sees, has seen, and has demonstrated the value of leveraging threat intel to further DFIR activities. I've also seen and demonstrated the value in leveraging DFIR activities (those that go beyond keyword and IOC searches) to further the threat intel picture, and subsequently, attribution. To that end, I spoke several times during 2021 on the topic of using DF analysis (specifically, analysis of the Windows Registry) findings to further the understanding of actor intent, "sophistication", and ultimately, attribution. One of the instances that I spoke on the topic was a half-day training event for federal LE.
I should note that Joshua M. (of Proofpoint) is one of the folks quoted several times in the article. I mention this largely to illustrate his background (check out his LinkedIn profile) as a counterpoint to my own. Joshua is what one would likely refer to as a more traditional intelligence professional.
I hope that brief description level-set the lens through which I'm viewing the content of the article. I get that we all have different perspectives, due in large part to each of us bringing our own experiences and knowledge to bear when reading and thinking about such things.
The first sentence of the article really sets the tone:
The sheer fluidity of the threat landscape is making the challenging process of attribution even more difficult for researchers.
IMHO, it's a good idea to unpack this a bit, not so much for the threat intel folks who've been doing this work for 20 yrs, but for everyone else. What this means is that "back in the day", there were some pretty clear delineations between activities. For example, "APT" (a.k.a., "nation-state" or "targeted") threat actors were distinctly different from 'e-crime' actors; different in how attacks and campaigns were organized and executed. Of course, if you look at the definitions used at the time, the Venn diagram included an overlap between "APT" and "e-crime" threat actors, in the form of credit card theft (PCI) attacks; these were considered 'e-crime' but were also clearly 'targeted'. However, the involvement of regulatory bodies (Visa, then later the PCI Council) served to move these attacks into an outlier status, the "everything else" column.
Over the years, we started to 'see' that the sharp lines of delineation between activities of 'nation-state' and 'e-crime' threat actors were becoming blurred; at least, this is what was being stated at presentations and in open reporting. I'll admit, I was seeing it as well, but I was seeing it through a different lens; that is, while a lot of threat intel is based on analysis of malware samples, the team(s) I worked with were quite literally following the threat actors, through a combination of active monitoring (EDR telemetry) and DF analysis. The EDR technology we were using was capable of not only monitoring from the point of installation going forward, but also of taking a "historical" look at the system by extracting, parsing, and classifying data sources on the system, that were populated prior to the installation of the EDR monitoring function. This provided us not only with unparalleled visibility into systems, but also allowed us to quickly scope the incident, and also quickly identify systems that required a closer look, a deeper DFIR examination. For example, on one engagement, there were over 150,000 total endpoints; we found that the threat actor had only "been on" a total of 8 systems, and from there, only needed to do a deep forensic analysis of 4 of those systems.
Finally, the reference to "researchers" can be viewed as a way of separating those attempting to perform attribution. A "researcher" can be seen as different from a "practitioner" or "responder", in that a researcher may be interacting with a somewhat limited data source (i.e., malware samples downloaded from a public repository) where a "practitioner" or "responder" might be engaging with a much wider range of data, including (but not limited to) EDR telemetry, logs, endpoint data acquired for analysis, etc.
The second paragraph references a couple of things we've seen develop specifically with respect to ransomware over the past 2+ yrs. Beginning in Nov 2019, we started to see ransomware threat actors move to a "double extortion" model, where they announce that they've stolen sensitive data from the compromised environment, and then prove it by posting samples of the data on the web. Prior to that, most DFIR consulting firms published reports with statements akin to "...no evidence of data exfiltration was found...", without specifying what evidence was looked for, or examined. The point is, Nov 2019 was a point where we started to see real, significant changes in the "ransomware economy", specifically with respect to how the activities were being monetized. In the months since then, we've seen references to "triple extortion" (i.e., files encrypted, data stolen, and a threat to inform customers), and even more than a few references to "n-tuple extortion" (don't ask). There's even been references to some actor groups further monetizing their attacks through the stock market, shorting stocks of companies that they were planning to or had "hit". Depending upon how the attacks themselves are carried out, endpoints might include clear indications of the threat actor's activity, as well as their intent. Some systems will clearly contain data pertaining to the threat actor's initial access vector, and other systems will likely contain data pertaining to not just the tools that were used, but also how those tools were used (i.e., threat actors may not use all capabilities provided by a tool in their kit).
Also mentioned in the second paragraph, some ransomware groups have moved away from conducting attacks and deploying ransomware themselves, and shifted to a "ransomware-as-a-service" (RaaS) model where they provide the ransomware and infrastructure for a fee. Add to that access brokers who are selling access to compromised infrastructures, and the end result is that not only has there been an increase in monetization associated with such attacks, but there has also been a significant lowering of the barrier for entry into the "ransomware game".
For example, in May, 2021, Mandiant published a blog article regarding DarkSide RaaS, and specifically regarding how they'd identified five clusters of threat activity, providing details of three of these clusters or groups. Even a cursory overview of what is shared regarding these clusters illustrates how analysts need to go beyond things like malware samples and infrastructure to more accurately and completely perform attribution.
Anti-Forensics and "False Flags"
Over the years, we've seen threat actors take actions referred to as "anti-forensics", which are efforts to remove or inhibit analysis and understanding of their techniques and actions. To some extent, this has worked. However, in some instances, what it has taken to achieve those goals has left much more indelible toolmarks that can be applied directly to attribution than the data that was "removed".
There's also "false flags", intended to throw off and mislead the analyst. These can and have worked, but largely against analysts who are trying to move too quickly, or do not have sufficient visibility and are not aware of that fact.
From the article:
“Many attacker groups have been observed to fake one or more evidence types, like planting a string of a foreign language in their malware,” he said. “But there are no documented cases of attacker groups that took the effort to plant false flags consistently in all aspects of their attacks and in all evidence types.”
While there's no elaboration on what constitutes "all evidence types", so its unclear as to what was examined; that is, malware samples were analyzed, comparing not just code but also embedded strings.
Something else to consider when researching malware samples is validation. Very often, "embedded strings" might consist of sequences of commands or batch files. For example, in the spring of 2020, one observed ransomware sample included 156 embedded commands for disabling services. Either way, the question becomes, do the commands actually work?
Finally, the second paragraph ends with, "...analysis of the breadcrumbs left behind by threat actors - including those in the malware’s code and the infrastructure - that researchers look at during attack attribution."
I've long been of the opinion that, however unknowingly, threat actors often seem to target analysts as much as infrastructures; perhaps a more appropriate description would be that threat actors target analyst's visibility, or their access to those "breadcrumbs". After all, it's very often the breadcrumbs that provide us that attribution.
As demonstrated via the Mandiant article, what's really missing from threat intel's ability to perform attribution is visibility. For example, from a great deal of public reporting, it's less that a threat actor "disabled Windows Defender" (or other security mechanisms) and more about how they did so, because the how and the timing can be leveraged to enable more granular attribution. While some threat actor activities appear to be consistent across monitored groups, at a high level, digging into the mechanics and timing of those activities can often reveal significant differences between the groups, or between individuals within a group.
Article Link: Windows Incident Response: The Threat Landscape and Attribution