CyberWire Daily - SUPERNOVA activity and its possible connection to SPIRAL threat group. [Research Saturday]

Episode Date: May 8, 2021

Guest Mike McLellan from Secureworks joins us to share his team's insights about SUPERNOVA and threat group attribution. Similarities between the SUPERNOVA activity and a previous compromise of the network suggest that SPIRAL was responsible for both intrusions and reveal information about the threat group. In late 2020, Secureworks® Counter Threat Unit™ (CTU) researchers observed a threat actor exploiting an internet-facing SolarWinds server to deploy the SUPERNOVA web shell. Additional analysis revealed similarities to intrusion activity identified on the same network earlier in 2020, suggesting the two intrusions are linked. CTU™ researchers attribute the intrusions to the SPIRAL threat group. Characteristics of the activity suggest the group is based in China. The research can be found here: SUPERNOVA Web Shell Deployment Linked to SPIRAL Threat Group Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's 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. So in November 2020, we were conducting an incident response engagement with a client, and we were seeing that the threat actor was interacting with an internet-facing SolarWinds server. So it became clear that what we were seeing in late November was actually this supernova webshell activity. That's Mike McClellan. He's a director at SecureWorks Counter Threat Unit. 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. And now a message from our sponsor Zscaler, the leader in cloud security.

Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, Thank you. transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler, zero trust, and AI. Learn more at zscaler.com security. 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 Wobeshed activity had been active for a number of years. So based on all those things, we thought it would 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. 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? 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 who'd been 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 LSAS 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 working directories on the host that compromised. We saw overlap in the compromised accounts that were being used. So three of the same administrator accounts were being used. And probably most tellingly for us, the threat actor in both cases has focused on two servers in particular, one a domain controller and one a server that would give access potentially to sensitive data that this client held. particular, one a domain 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 sort 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 host 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 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 rather than their C2 infrastructure, suggesting that maybe the operators's based in the world. But in this case, it looked like the leak of an actual operator IP rather than their C2 infrastructure, 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. 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've 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? 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 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 outputs of these recon commands to a file on the server, and then later exfiltrating that file and all its content. 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 to delete server logs and those kinds of things to hide their tracks. So we sort of see all this intrusion activity. The thing we couldn't quite figure out was exactly how they gained access to the server, how they were running these commands and what had allowed them to do this. And it was only later in December 2020 when SolarWinds put out their notification about previously unknown vulnerability in the SolarWinds Orion API,

that it became clear this is how the threat actually had been gaining access to the server, and they'd been leveraging that at the time, zero day, to run these commands and deploy the Supernova web shell. 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. Yeah, absolutely. I mean, it's not uncommon in targeting 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 the 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. They 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 in 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. 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?

Exactly, yeah. 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 and did 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. 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. 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 that 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. 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 it'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. 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? 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 servers have they 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.

So we'll try and 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 those kind of 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 do a full domain-wide credential reset to evict them in a coordinated way? What are the steps we need to go through just to make sure that they can't obtain 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 is there a stage in in this sort of effort

where um you all are being intentionally stealthy in other words you know is it is part of um your strategy that the the uh the attackers don't know that you know for a certain amount of time? So, you know, to give you visibility on what they might be up to? 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 our band communication, so potentially standing up new email accounts 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 network defenders are doing. So it's really important we try and hide the response work

as best we can from a threat actor. Is there an emotional component to this as well as you're working with your clients and walking them through the remediation of trying to get them back to feeling like their feet are on the ground? There is a bit of that. That's certainly probably more true with some of the ransomware engagements we do where it can be a really disruptive and fairly shocking time for the organization especially for ransomware attackers have 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, as far as I'm concerned, is what they might be going after in the environment. 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 is 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 ultimately go about evicting the threat actor. And how does this fit into the larger SolarWinds event? How directly does this tie into that? 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.

There was then further clarification in mid-December to suggest actually it probably wasn't linked. And certainly our findings support that hypothesis. So what we've got here is we've got a supply chain compromise against solar winds that happened towards the back end of, well, sorry, last summer, really. The bulk of the activity there, which we assess was likely Russian in origin. And then separately, we've got this activity, which we assess to be likely Chinese in origin, where rather than a supply chain compromise with SolarWinds, ThreatActor has found a zero-day vulnerability in the SolarWinds Orion platform and was using that to compromise internet-facing servers. 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 map

into our broader understanding of the Chinese or ABT landscape. And so what are the takeaways here in terms of, you know, organizations looking to better protect themselves? What are some of the lessons that they can take away from this particular incident? I think this is one of those cases where we will always tell organizations 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 proactively to prevent that because you can't patch 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, you know, 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 so that's that's

one point to make is that layer controls are still important perimeter controls are important but being able to spot things sort of post-compromised 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 as i just sort of mentioned, there are at least two different groups who are targeting solo in software, one through a sort of classic supply chain compromise, and this one through a 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 that you understand what normal behavior looks like for that software so you can spot anomalies. It's just really important. I can't kind of emphasize the importance of that. Our thanks to Mike McClellan from SecureWorks for joining us. The research is titled Supernova Web Shell Deployment Linked to Spiral Threat Group. We'll have a link in the show notes. And now a message from Black Cloak. Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning

digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365, with Black Cloak. Learn more at blackcloak.io. 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 Elliot Peltzman, Puru Prakash, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Vilecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening.