CyberWire Daily - Has GOLD SOUTHFIELD resumed operations? [Research Saturday]

Episode Date: July 23, 2022

Rob Pantazopoulos from Secureworks, joins Dave to discuss their work on "REvil Development Adds Confidence About GOLD SOUTHFIELD Reemergence." Secureworks researchers published a new analysis on what can be considered the ‘first’ set of ransomware samples associated with the reemergence. These updated samples indicate that GOLD SOUTHFIELD has resumed operations. The research states "The identification of multiple samples containing different modifications and the lack of an official new version indicate that REvil is under active development." Researchers identified two samples, one in October of 2021, and the other in March of 2022. The March sample has modifications that lead researchers to distinguish the two samples from one another. The research can be found here: REvil Development Adds Confidence About GOLD SOUTHFIELD Reemergence 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 the threats and vulnerabilities,

solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. Before we jump in here, let's establish, are you an REvil guy? Are you an REvil guy? I'm a REvil guy, and above all, I am not a Sudden No Keepy guy. That's Rob Pantazopoulos. He's a senior security researcher and malware reverse engineer at SecureWorks. The research we're discussing today is titled,

REvil Development Adds Confidence About Gold Southfield Reemergence? 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, continuously verifying every request based on identity and context. Thank you. can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. With families like Reval,

that we determine a rise to the level that we need to do tracking on them. We set up typically a number of different tripwires, if you will. So we will identify samples and if those samples have any different types of variations in them or unique aspects of them. So if there's a new version value within the binary, if there's a new configuration element, so on and so forth, we will set up notifications. So we'll get alerted to when we find those. We also do open source monitoring. And that is actually in this case, how we came across a

sample. There was a Twitter post by the director of malware research over at Avast, by the director of malware research over at Avast, Jakob, I'm not quite sure how you pronounce his name. But he had notified the good people on Twitter that they had identified a new Reval sample, what they thought to be a Reval sample. And one of the interesting quirks about it was that it wasn't actually encrypting files. So they weren't quite positive. It seemed like they weren't quite positive of what the sample was. So as soon as we saw that, pulled down the sample. And now because we've been tracking Revol since it hit the scene, we had all types of research stored up on it, including every single version or every single variant that we've come across, we've analyzed,

documented. So one of the first things that we did was pulled up one of the most recent analysis of version 2.8.08 that we had done back in October and did a side-by-side comparison of the old sample and this new sample within IDA Pro and we found that basically the decompiled pseudocode was almost exactly the same. There were some new features which we had called out, but ultimately the core of the code was nearly identical. There's other aspects of it as well, such as there's a string format that it uses.

We call the Stats.JSON, which contains things like the real version information information that about the the computer that is obtained at runtime information about the encryption session is placed inside this this json data structure and that information is actually ultimately sent back to the was sent back to the threat actor. So that was there as well. So that was really kind of like the absolute, yes, this is Revol. Well, give us a little bit of the background history here. I mean, we're talking about two groups. We've got Revol and then we've got Gold Southfield. And I guess what we're getting at here is, you know, is that a distinction

without a difference? What's the backstory? Sure. So Gold Saltfield is the name of the threat group that runs the ransomware as a service offering, leveraging Revol ransomware. So Revol really is the software used by the Gold Saltfield threat group. I see. And so let's dig into some of the specifics here of some of the changes that you all were tracking in these most recent samples. Can you take us through some of the highlights? Yeah, sure. So the sample shared by Jakob actually didn't contain much of interest. But one of the first things that we did once we realized that, yes, this is Revol, we tried to find aspects of that code to try to then perform retro hunts within VirusTotal to maybe find other samples that had not yet been identified.

And sure enough, we had found, we had hit on a sample from March 11th of this year, 2022, that nobody else had reported on. So we retrieved that sample. We did an analysis of that sample. And that sample actually contained a lot of the new features that you see in the report that we published. And for some reason, that wasn't in the sample that Jakob had published. I don't exactly know why. Jakob's sample was actually compiled later on.

That sample was compiled on, I think it was March or April 12th. So this was roughly a full month before, but contained, the older sample contained more newer features. So once we saw that, we really kind of put our full focus into analyzing that sample. One of the first features that we found was that there was an inclusion of a new command line argument, dash T. Now, when we submitted this sample initially to our sandbox, it didn't do anything. But then once we began analyzing it, we realized that this dash T expected to receive some type of token value that it then used for decoding strings at runtime. And these strings were critical to the success of its execution because it decoded strings such as like kernel32.dll and all the different function names that it would be dynamically importing at runtime that were critical to its execution. So if you didn't have the appropriate value,

it just wouldn't run at all. The token used here was implemented within all of the string-to-code operations. What we wanted to do is in order to find out what the token was, we loaded the old sample up that didn't have the string-to-coding logic into IDA Pro, and we compared it to the new code that was using this string decode logic.

And one of the values that this token was being applied to was the key length for the encrypted string. All right, so in Revol, the strings used by Revol are encrypted using RC4, and they're stored. They have the key, which is then immediately followed by the actual encrypted string. And the string decrypt function has the location of the decryption key, the length of the decryption key, the location of the encrypted string, and the length of the decryption string. So that's how it knows, all right, here's the start and end of the key, here's the start and end of the encrypted string, and when it goes to decrypt it, that's how it kind of extracts that information out. So in this new sample, of those four values, the encrypted key length was encoded, and then the address of the encrypted string was encoded.

So they did that with the intention of making it impossible to figure out what the actual full key and what the actual full encrypted string was. and what the actual full encrypted string was. The problem was is that the, so the way that they do the encoding is that this token value that you pass on the command line has an XOR operation applied to another four byte value. And in this case, the token value was XORed with the hex value 2F9BODCA. Now, fortunately, because the old version didn't have this encoding applied,

and they also didn't change any of the code around there, we knew that the string being decrypted at that location had a key length of 12 bytes. So we knew that whatever value was passed in the token field was XORed with this 2FB90DCA equals the integer 12. So those are kind of like the, now we have kind of the pieces that we need in order to determine what the token value is. So the second bit of information that's important to know is for what is XOR, right? The XOR is a mathematical bitwise operation. And the interesting bit of information is that anytime you XOR a value with itself,

the resulting value is null or, you know, hex zero zero. So the integer value 12 only takes up a single byte. However, the code allocates this value within a four-byte memory allocation, which is padded by null bytes. So the first three bytes of this four-byte allocation are nulls. So we can apply that logic to say whatever this token is XORed with the 2F9B0DCA,

if the result of that operation, the first three bytes are no bytes, then the first three bytes of that token must be the 2F9B0D. So now instead of having to figure out like maybe brute force, you know, all four bytes and trying to find the appropriate value, all we really have to do is brute force all four bytes and trying to find the appropriate value, all we really have to do is brute force that last byte to see what XORed by the hex value CA equals the integer 12, which was a really fast operation that we could do within a Python script. And it turns out that the hex value C6 XORed by the hex value CA equals the integer 12.

So that means that the expected token passed the command line was the hex value 2F9B0DC6 or the integer 798690758. So I know there was a long kind of technical explanation, but that was really, for me, that was really interesting that they made a little bit of a mistake there in their encoding routine. It was supposed to be this really complicated thing to prevent people from running their malware within sandboxes or performing analysis on it. But it took, you know, a few minutes of us doing this analysis to determine what the key was. And then we ran it through our sandbox, we provided the appropriate token value, and then boom, it fully executed. It must have been quite gratifying to, you know, when faced with this attempt from them at obfuscation to be able to unpack it and figure it out, you know, so quickly.

Yeah, I mean, I feel like that's why a lot of malware researchers, security researchers do what they do, because it's just a constant puzzle. So this was kind of figuring out one of those puzzles and then it's kind of on to the next one. Yeah. Well, what are some of the other things that you all noticed here, things that were of interest to you? Sure. So the second thing that I found really interesting was the inclusion of a new configuration element, the ACCS configuration element. Now, we had identified a new sample back in October of 2021. This was after the take down, Western law enforcement had performed a take down of Gold Saltfields infrastructure. So this sample was identified after that had occurred, which is what kind of gave us, piqued our interest. This new sample, we didn't publish anything publicly about that, but the sample had contained this ACCS configuration element, but we didn't publish anything publicly about that, but the sample had contained

this ACCS configuration element, but it didn't contain any values. It was just kind of an empty array. But through reverse engineering, we knew that it played a role in the encryption of remote resources, such as like map drives that would try to authenticate to these remote resources using whatever credentials were contained within this ACs configuration element but at that time there was speculation as far as what type of credentials would be contained within there um would it be kind of generic like admin password or you know admin welcome one two three and it would just be like an opportunistic brute force type of credentials? Or would it be more targeted so the malware could operate a lot faster? Targeted credentials that may be obtained through initial compromise of their network.

They try to obtain as many username and passwords as they can from that network. And then when they deploy Revol, Revol is already packaged with the credentials that are for that environment so they can kind of get maximum impact from an encryption standpoint. This sample that we identified, the March 2022 sample, actually had credentials stored within it.

And they were targeted credentials. So that kind of answered that question that we had of what kind of credentials would be stored within it. And they were targeted credentials. So that kind of answered that question that we had of what kind of credentials would be stored within there. And it turns out to be targeted credentials. One, I guess, unfortunate side effect of this is that because they're targeted credentials, now if these samples get released into the wild, it may be easy for other people to, you know, figure out that you were compromised and infected with RIVO ransomware, even though that information may not have been made public. Oh, that's interesting.

One of the things that caught my eye, you know, these ransomware groups, I guess, famously have restricted their operations, you know, to not affect what we presume is their own homeland. But in some of the things you examined here, they had deactivated that, that region check. Yeah, that's definitely an interesting change. And we're not 100% sure of exactly why that is. We know why they implemented it to begin with, right? They don't want to bring heat upon themselves by basically friendly fire. But why they removed it was a curious move. There was definitely a lot of

turmoil, if you will, around that time. It was initially removed in that October timeframe. And that was roughly when the takedowns had occurred and then ramping up with tensions with Russia and some of the Ukraine stuff going on. So there's a lot that was happening around this time frame, but nothing really stands out as to why they did it. So what are the take-homes for you? As you look at the changes that you and your colleagues tracked here, what do you take away from it? So in the past, when we've seen this kind of activity, meaning when we've seen multiple new samples without a new version value, multiple changes between the samples, it was typically indicative of, you know, we could expect a new sample or new official version to be released typically within a month to two months is what we've seen. That has yet to play out. As a matter of fact,

so what we published our public blog on May 9th, and the last actual activity that we've seen from Gold Southfield was on May 6th. So the last victim published their leak site was on May 3rd, and the last sample that we have was compiled on May 6th. And since then, we haven't heard anything. We're not quite sure on what to expect for the next steps. There's many different scenarios that could play out, but certainly we're going to be ever vigilant and, you know, try to keep on top of this. Our thanks to Rob Pantazopoulos from SecureWorks for joining us. The research is titled, RE Development Adds Confidence About Gold Southfield Re-Emergence. 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 Cyber Wire podcast 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 Cyber Wire team is Rachel Gelfand, Liz Ervin, Elliot Peltzman, Trey Hester, Brandon Karpf, Eliana White, Puru Prakash, Justin Sabey, 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. We'll see you back here next week.