SUPERNOVA activity and its possible connection to SPIRAL threat group.

Dave Bittner: Hello everyone, and welcome to the CyberWire Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

Mike McLellan: So, in November of 2020, we were conducting an incident response engagement with the client and we were seeing that the threat was interacting with an Internet-facing SolarWinds server. So it became clear that what we were seeing in November was actually this SUPERNOVA web shell activity.

Dave Bittner: That's Mike McClellan. He's a director at SecureWorks Counter Threat Unit. The research we're discussing today is titled, "SUPERNOVA web Shell Deployment Linked to SPIRAL Threat Group."

Mike McLellan: That element of the whole SolarWinds saga in December didn't receive a whole lot of coverage, and furthermore, when we looked into it more closely, we could actually trace this intrusion potentially back as far as 2018, suggesting that whoever was responsible for the SUPERNOVA web shell activity had been active for a number of years. So, based on all of these things, will it be useful to put a blog together explaining our findings, giving our insight, and then just open up to the community to see if anyone else had any similar observations they were able to share.

Dave Bittner: Well, let's walk through this together. I mean, you are calling out an organization that you call the SPIRAL threat group. What can you tell us about them?

Mike McLellan: When we first started, not much. We could see the activity we were observing in November, and that was about it. So all we could see at that point was this was a group being able to gain access to this SolarWinds server, they had deployed a web shell, and they were using that access to try and move laterally, dump credentials, and those kind of things. When we looked back, we looked at a similar intrusion at the same client that we investigated earlier in 2020. As we dug deeper into some of the behaviors we were seeing, we saw some similarities. So, we saw identical commands used to dump credentials to try and dump the LSASS process to steal credentials from that process memory. We saw the same working directory used in both intrusions, so some evidence that possibly it was the same actors using the same work directly on the host they'd compromised. We saw overlapping and compromised accounts that were being used, so three of the same administrator accounts were being used.

Mike McLellan: And probably most tellingly for us, the threat actually in both cases focused on two servers, in particular: one of the main controller and one a server that would give access potentially to sensitive data that this client held. So there were lots of sort of tenuous links between the two intrusions, lots of similarities in behavior. And that was really interesting to us. And then I guess the final element that was very interesting to us was, at some point during the August intrusion, the threat actor had appeared to download a copy of our POST agent and executed it on their own host, and that appeared to have exposed an IP address based in China. And that, obviously, for us was an interesting data point, because while normally command-and-control infrastructure, you know, you can't take too much from where it's based in the world, but in this case, it looked like the leak of an actual operator IP from their C2 structure, suggesting that maybe the operators were based in China. So that's our kind of current understanding of the group. We're obviously working to see if we can associate that with any other known Chinese threats that we track.

Dave Bittner: Well, let's dig into some of the details together. Let's walk through it. I mean, as you point out in the research that you published, back in November 2020, your team was on an incident response engagement, and that's when this all sort of started to come to light. Can we go through step-by-step of how you unrolled what was going on here?

Mike McLellan: Yeah, absolutely. So, this client had our endpoint agent installed on their SolarWinds server, and we were seeing encoded PowerShell commands through that host agent's telemetry. And for us, that's always an interesting sign, particularly when those commands are running under as a child process of something like a web server, or in this case, the SolarWinds server itself. So, we're seeing these encoded PowerShell commands running, we can decode those and see that the actor is actually running a series of reconnaissance commands, and then writing this recon data – the output of these recon commands – to a file on the server, and then later exfiltrating that file and all its content.

Mike McLellan: So, we're seeing this recon activity. We also saw a base64 encoded blob being written to the server. And again, when we looked at that, that turned out to be an encoded version of the SUPERNOVA web shell. So we're seeing the web shell being written to disk, and we see the threat actor trying and delete server logs and those kind of things to hide their tracks.

Mike McLellan: So we sort of see all this intrusion activity. The thing we couldn't quite figure out exactly how they had gained access to the server, how they were running these commands, and what had allowed them to do this. It was only later in December 2020, when SolarWinds put out their notification about a previously unknown vulnerability in the SolarWinds Orion API that it became clear this is how the threat actor had been gaining access to the server. They'd been leveraging that that at-the-time zero-day to run these commands and deploy the SUPERNOVA web shell.

Dave Bittner: You point out in your work here that the threat actor mapped network shares on two hosts, as you mentioned – a domain controller and a server that had some sensitive business information in there. And that was an interesting point to you, how targeted they were.

Mike McLellan: Yeah, absolutely. I mean, it's not uncommon in targeted intrusions to see the threat actor really focusing on the assets they're interested in. Typically, they'll have some idea about what they're after and they'll kind of go after servers that will hold that data for them. But what was interesting in November was they went straight to these two hosts, and this wasn't necessarily a particularly intuitive traverse from the SolarWinds server. The obviously knew which boxes they were interested in. As I said earlier, when we began to look back at what happened in the summer of 2020, the intrusion we investigated then, it was clear they were the same hosts they'd been interested back in the summer. So they clearly knew what they wanted. They went after it very quickly in November. And that was really an interesting data point for us.

Dave Bittner: So the conclusion here, or the supposition, I suppose, is that when they'd gotten in earlier, they'd been able to sort of map out the networks. And so when they came in this time, they knew exactly where they had to go.

Mike McLellan: Exactly. So it looked like the original access they had dated back from 2018. They were likely evicted in the summer of 2020 when we went into incident response with the client. And then it looks like they were able to regain access in late November. As you say, they knew exactly what they were after and tried to go straight to those hosts.

Dave Bittner: Let's talk about this sort of inadvertent revealing of themselves that they did when they downloaded one of your EDR agents. Can you walk us through that? That's a fascinating little wrinkle here.

Mike McLellan: Yeah, it's quite unusual to see that. I can't think of another example that we've seen where this has happened. But essentially, when we deploy our host agent out for an incident response engagement, the client will install out onto as many machines as possible. And we try and do that as one of the first parts of the engagement to gain widespread visibility of the environment. What appeared to happen in this case was we saw a host begin to check in from an IP address geolocated to China, to a data center in China. And after extensive consultation with the client, it became clear this wasn't their host. It wasn't an IP address they recognized, it wasn't a host name they recognized. It appeared to be kind of an anomaly

Mike McLellan: And the conclusion we draw based on the data we've got is that potentially the threat actor downloaded the installer for the EDR agent, executed it, and when the agent installs itself, the first thing you'll do is try and check in to make sure it's got network connectivity. So we saw a single check-in, then they stopped checking in, so we assume they killed it. But in that time period, we gained a very brief glimpse potentially into some of their operator infrastructure.

Dave Bittner: Can you take us through what the cleanup process is like in a case like this, when you discover this type of infiltration, how do you go about cleansing these systems?

Mike McLellan: These targeted intrusions are very different to incidents like ransomware, where you may have a very short kind of time window before something truly awful is going to happen to the customer. So when we work in these sort of targeted espionage intrusions, the most important thing early on in the incident response engagement is to try and understand how extensive the compromise is. So, which services have the got access to? What credentials are they using? Are there any other redundant access points they can use for persistent access if we shut down the ones that we can see?

Mike McLellan: So we'll try and to spend as much time as we think we can to understand the scale of the intrusion, and then it just becomes a case of figuring out, do we need to rebuild systems or can we remove artifacts to remove malware from the infected hosts? Do we need to do a full domain-wide credential reset to evict them in a coordinated way? What are the steps we need to go through to make sure that they can maintain their access and they can't come back in afterwards? So we'll spend as much time as we can understanding the scale of the intrusion, then we'll develop an eviction plan with the client. We'll then do that eviction with them, and then we'll monitor for a period of time after that to identify any attempts to come back in. And in this case, we haven't seen any so far.

Dave Bittner: Is there a stage in this sort of effort where you all are being intentionally stealthy? In other words, you know, is part of your strategy that the attackers don't know that you know for a certain amount of time, you know, to give you visibility in what they might be up to?

Mike McLellan: Yeah, there's a period of advantage, you know, after the initial detection, before we start to actually shut down any of the access they've got, we have that small opportunity window where we know they're there and they don't know that we know. So it's really important in that phase to try and be as covert as possible. And we'll do that through means such as using out-of-band communication. So potentially standing up a new email account for the client to make sure we communicate outside of their corporate systems, finding ways that we can coordinate and discuss the incident response engagement without tipping the adversary off. Because we've seen examples where  the threat actor has access to email inboxes or potentially even things like Microsoft Teams. We've seen threat actors in those platforms monitoring what the defense is doing. So it's really important we try and hide the response work as best we can from a threat actor.

Dave Bittner: Is there an emotional component to this as well as you're working with your clients and, you know, walking them through the remediation of trying to get them back to, you know, feeling like their feet are on the ground?

Mike McLellan: There is a bit of that, certainly probably more true in some of the ransomware engagements we do, where it can be a really disruptive and fairly shocking time for the organization, especially if a ransomware attack has been successfully conducted against them. With these kinds of intrusions it's a slightly different focus, because here, for us as intelligence analysts and as researchers, we're trying to make sure the client understands the potential impact and the potential context of the intrusion. So, understanding who the threat actor might be and therefore what they're after. Because that's really the important bit about intent, far as I'm concerned, is what they might be going after in the environment. 

Mike McLellan: Making sure the customer understands the background – so in this case, because of all the other SolarWinds stuff going on at the same time, we had to try and separate out this activity from the broader supply chain stuff that was being covered extensively in the media. So there was definitely an element of education and making sure the client understands what's going on, what's important, and that can then help them understand how we should drive the response forward and how we should also go about evicting the threat actor.

Dave Bittner: And how does this fit into the larger SolarWinds event? How directly does this tie into that?

Mike McLellan: Well, the short answer is it doesn't really. And this was the initial confusion, I think, because there was initially reporting that suggested that this web shell was linked to the supply chain compromise that's been widely publicized that SolarWinds suffered last year. Though, then for further clarification in mid-December suggest actually it probably wasn't linked and certainly our findings support that hypothesis. So what we got here is we've got a supply-chain compromise against SolarWinds – that happened towards the back end of last summer, really, the bulk of the activity there, which we assessed was likely Russian in origin. And then separately, we've got this activity which we assessed to be likely Chinese in origin, where, rather than a supply chain comprising SolarWinds, the threat actually found a zero-day vulnerability in the SolarWinds Orion platform, and was using that to compromise Internet-facing service. So, much smaller in scope than the SolarWinds supply-chain compromise. Very targeted from what we've seen. And this is not a group that we've seen anywhere else before other than this one client, and certainly one that we're trying to make into our broader understanding of the Chinese APT landscape.

Dave Bittner: And so what are the takeaways here in terms of organizations looking to better protect themselves, what are some of the lessons that they can take away from this particular incident?

Mike McLellan: I think this is one of those cases where we will always tell organizations to to patch and prioritize patching based on their business needs. But when you come to these kind of incidents where zero-days are leveraged, there's obviously not much you can do sort of proactively to prevent that because you can't patch a vulnerability that no one knows about yet. So the importance then becomes one of understanding, if compromise can be achieved by the threat actor, how quickly can you detect that? In this case, our endpoint agent was able to do that. And we always strongly encourage our clients to deploy endpoint controls as broadly as possible. Any good EDR agent will give you the sort of visibility you need to spot this stuff early on in the kill chain, because when prevention fails, obviously detection becomes the most important thing.

Mike McLellan: So, that's one point to make is that layered controls are still important, perimeter controls are important, but being able to spot things, post-compromise activity are, you know, incredibly important nowadays with some of the threats that we see. I guess the second main takeaway is that, as I just mentioned, there are at least two different groups who are targeting SolarWinds software, one through a sort of classic supply chain compromise, and this one zero-day vulnerability. So it just shows that sophisticated threat actors continue to try and target third-party software for access, and they will continue to do that. So, again, making sure that you are putting the right controls around third-party software you're running, making sure you understand what normal behavior looks like for that software so you can spot anomalies. It's just really important and I can't overemphasize the importance of that.

Dave Bittner: Our thanks to Mike McLellan from SecureWorks for joining us. The research is titled, "SUPERNOVA web Shell Deployment Linked to SPIRAL Thread Group." We'll have a link in the show notes. 

Dave Bittner: The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliott Peltzman, Puru Prakash, Kelsea Bond, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Gina Johnson, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Rick Howard, Peter Kilpe, and I'm Dave Bittner. Thanks for listening.