AnyDesk Compromise

CISO IT, Episode 2

CISO IT Talks AnyDesk

In this episode of Automox's CISO IT podcast, Jason Kikta, Tom Bowyer, and Henry Smith discuss the recent Any Desk compromise and its implications.

The hosts and their guest highlight the risk of the code signing certificate and the potential for arbitrary malware to be signed using it. The lack of transparency from Any Desk and the importance of password security are also discussed.

Automox's response to the incident, including the development of a PowerShell script to search for affected executables, is emphasized. The episode concludes with a reminder to protect code signing keys and thoroughly investigate potentially impacted systems.

Read the CISO IT Transcript

Jason Kikta: All right, let's light this candle. Drop that up. Oh, fuck, no. Off to a great start. All right, Lynn.

Tom Bowyer: Siri, play that song.

Jason Kikta: Hey Siri, stop.

Tom Bowyer: Okay, I'm not trolling you.

Jason Kikta: Yeah, I know you do.

Henry Smith: Too much tomfoolery.

Jason Kikta: All right, let's light this candle. Hey, good afternoon. Nope, don't want to do a date. Never time.

Welcome everyone to Automox's CISO IT podcast. My name is Jason Kikta and I am the CISO at Automox. With me today are Tom Bowyer and Henry Smith. And why don't each of you introduce yourselves?

Tom Bowyer: Hey everyone, Tom Bowyer and I'm the Director of Security and IT here at Automox.

Henry Smith: Hey everyone, I'm Henry, Senior Application Security Engineer, working under these lovely individuals.

Jason Kikta: So today we're going to do a special episode and a little bit out of sequence, but with the news from last week of the AnyDesk Compromise, we felt it was important to move up our production schedule and talk about this one specifically because we've seen a fair amount of confusion out there.

And also I think that it probably hasn't gotten the level of focus that it deserves simply because of everything else going on with the... uh, ongoing public exploitation of Ivanti, but this is a separate issue. And, uh, this, AnyDesk compromise is pretty serious because it is the loss of control of a code signing certificate.

So this is a systemic risk to the entirety of the internet. If you run Windows, you're at risk here. What we know so far based on, uh, AnyDesk's public statement as well as a few news reports is that unknown threat actors at an unknown time for an unknown duration compromised at least their most recent until last week code signing certificate for Windows as well as other things within their environment. And so they released, AnyDesk released a new version of their Windows executable, their Windows version, uh, with the new code science certificate. And, we do recommend that you upgrade, uh, to that certificate immediately.

However, the real risk here is not any desk. Uh, this, the risk is that code science certificate. You don't steal, uh, the code science certificate for a, uh, a popular piece of software to necessarily masquerade as that software. That is the thing that you could do.

Uh, but it's not the most bang for your buck because you can use this to, uh, sign arbitrary malware. And I'll say as well, um, I've been watching across the infosec community, uh, over the weekend and today as people have been, uh, you know, looking for any desk in their environment. And so far I haven't seen anyone come back and say, Oh, we had less any desk than we thought. I've even seen people say we don't have any, any desk and then, Oh, actually we have dozens or hundreds.

So this is, you know, I wouldn't just take that for granted. And again, this applies to you whether you're an AnyDesk customer or not, because that malware could have been out there. You know, any potential malware that was signed, you know, may have been in your environment for some time. And I think the other aspect that's causing a little bit of confusion is, while AnyDesk says that they have revoked a certificate Microsoft's regular updates to Windows should include those updated certificate revocation lists. That only applies when you start a new execution of a program. So if that malware is there, and it's on disk, and someone tries to fire it up brand new, that should stop it. But if the process is already running and loaded in memory, or any prior execution of that malware that happened and enables someone to compromise your environment, that CRL is not going to, like that's just not what it's designed to do. It's not going to help you there. So, you know, Tom, what are your thoughts on this?

Tom Bowyer: I mean, two things come to mind first, is this an EV cert or not? That's still something I'm trying to understand. Nothing in their official update. I mean, I haven't done too much research around it, but an EV cert is X times more valuable than a standard code signing cert just because of the bypasses it provides you in Windows, through SmartScreen, and the like. And second, how long, right? No TTPs, nothing in the report, right? Who accessed the system, how, et cetera, et cetera. I'm just extremely disappointed that, you know, here we are again.

Jason Kikta: Yeah. I don't know if we're talking about years, months, days, weeks, hours. Like, we don't know because they haven't given us any data on that.

Tom Bowyer: Yeah. And you know, as a practitioner, right? It's like I just search for any desk and update it. Like, am I not looking for anything else? Right, like you gotta give me something here. You gotta give me something.

Jason Kikta: No, I think that's why we went into, you know, here at Automox, we went into overdrive on Friday because our immediate concern was, hey, you know, how do I know that there aren't executables lurking in the Windows portion of our environment that have been signed with this certificate, you know, certificate types, binding a certificate to a certificate purpose is only as good as the enforcement. So, we sat down with our worklet team here and had them write a PowerShell script to be able to search those system and user certificate stores on Windows to search for any EXEs or MSIs on disk that were signed with this. And we immediately realized that this is not only useful to us, but it's useful to

Or, and, and not only to our customer base, but this would be useful to public as well. So we, we worked late into the night Friday and, and. Publish that thing, uh, in a blog. Uh, and it's on our Mox's website if anyone's interested in it, but you know, we wanted to try and get something out there to help people to fix the issue. Right. Because, you know, I think that's something that people don't always understand.

Well, the security role in these types of incidents is to find the issue, whereas it's usually IT's responsibility, depending on the system and the structure of it, but it's usually IT's responsibility to fix it. So our unique, you know, capabilities and posture here as an IT company, but one with high-security awareness, you know, really made us feel sort of

I don't know if, uh, in clients, not the right words, really, you know, almost obligated, uh, to, to try and help out where we could, because this is going to be one of those long tail painful vulnerabilities that we see for a long time, correct, Henry?

Henry Smith: Yep, absolutely.

Tom Bowyer: Yeah. I also feel like, you know, code signing certs aren't just used to sign like MSIs and the XCs, right? You can also sign PowerShell, right? And there's a big push in the industry to move to fully signed PowerShell execution, right? I'm only going to execute PowerShell from trusted known providers. And you know, there's a unique opportunity here to pull down, you know, grab your favorite post exploitation PowerShell and sign it with the stolen certificate and run it. Right. That's, you know, that's where my head is in all this. And, you know, I'm just really disappointed in the public statement. You know, I don't want to keep harping on any desk, but their lack of transparency there is really disappointing to see. They didn't even put like the certificate hash in the statement or anything like that. I could.

Jason Kikta: No, yeah, we had to go search those down through other, through third parties. That was, that was mind-blowing to me.

Henry Smith: Well, that's it. Yeah, and I think one thing that really stood out to me is how many details around this incident were essentially crowdsourced based on evidence that security researchers found. For example, like the change log of the AnyDesk Windows application stating they were rotating the code signing cert. That was on, I think, January 29th. So why did it take someone reading the change log and reporting on it for the news to come to light about that? Why wasn't that included?

Jason Kikta: Yeah, why do people have to find out from security researchers on Twitter who read a change log and said, This, you know, You know, mind-blowing.

Henry Smith: Yeah, and then, yeah, and the whole thing, well, it's not ransomware. Okay. That's not the only thing that we have to worry about.

Jason Kikta: There's a lot more to worry about than ransomware, certainly. Uh, it just, just kind of mind-numbing it. And on that topic of other things, um, you know, there's another narrative floating around out there that is separate from the threat of the code signing certificate, and it has to do with user credentials for the, uh, for any desk support portal.

Henry Smith: So from what I was reading this morning, there's one security blog, I think it's re-security, put out a blog just following the Anydesk incident, mainly with customer credentials being leaked and published for sale on the dark web. And my understanding is they actually reached out to some of the individuals that were in the sample dump that was provided on the dark web. And those, they were active accounts. These customers didn't even know that this was a problem and they learned about it from re-security reaching out. Another thing too that caught my eye was I think they said the majority of the leaked credentials didn't have 2FA turned on. We've been talking about 2FA forever. Turn it on.

Jason Kikta: Yep. Well, and I think that's, you know, that's where, you know, I saw this piece in the register where someone had looked at it and said that, you know, Hey, there are a lot of these in here that have been, you know, in previous dumps. And so I think seeing so many combo lists that surface again and again, it's easy to lose track of, of whether or not this is, you know, new data or old data. But I think.

Jason Kikta: You know, A, if they haven't changed it as a result of those old compromises, then they're still at risk. And B, if there was a new compromise and that isn't even rolled in, then that's new risk that you have to worry about. And also, if you're not using 2FA, and if you reuse credentials, like that to me is the most worrisome is, it's not. whether or not someone can come in and pose as my administrator and put in a support ticket.

While that is dangerous, you know, hopefully, AnyDesk, hopefully, is going to overcome that by with good verification procedures. I don't know that I'd hang my hat on it, but hopefully. But if you've reused the credentials to manage that they with which you used to manage AnyDesk, can you reuse those in the customer portal uh, and you weren't using a single sign-on solution, then, you know, that, that actor, I mean, the actors prob actors are going to try that. They're going to give it a try. And if there's no two FAA, then, you know, onward they go and now they can, they can own you a different way.

Tom Bowyer: Yeah. And I think, you know, the unfortunate reality is, you know, if you have a public-facing portal, it's going to be subject to password spraying. And as a business, you just got to understand like, yeah, we trust our customers to use safe and secure passwords. But, you know, if you look at the 23andMe case recently, like, did I do anything wrong legally? No. But, you know, the court of public opinion absolutely railroaded them because of all the, you know, reuse passwords within their app and they got in and they were on a pivot through all these other people's DNA history. And right. It's like, that's just another avenue. You got to understand like that's a risk. Like I gotta, I gotta prevent people using compromised and insecure passwords in my platform. That's just, it's just another thing. It's just the reality of how the world works today. Right.

Henry Smith: Not to mention the information they could take from just any desk portal can be used in targeted fishing campaigns.

Jason Kikta: Absolutely. Yeah. It, it's one of those multifaceted risks that can, can go on a lot of unexpected directions, so, uh, regardless of your exposure or really your, your perception of your exposure to it, you should immediately move to mitigate that. So, all right, Henry and Tom, any closing thoughts?

Tom Bowyer: I'm gonna steal Henry's but turn on two-factor

Henry Smith: I think my closing thought is, you know, there's still a lot of unknowns, but it's one thing I take away from this is that it's paramount to protect those code signing keys. It cannot be stressed enough. You know, we've seen it also time and time again, not to name any companies, but one thing in particular I'm thinking of is Nvidia. They were one in the news where I believe malware was actually deployed using one of their code signing certs. So, protect those at all costs.

Jason Kikta: Absolutely. And I think the thing that I'm going to leave everyone with is, you know, when these code signing certificates have been in the wild for an unknown period, this is where, you know, you need to not look at the immediate task not over-focus on the immediate task of upgrading the affected software, but really do a thorough scrub of all of your potentially impacted systems to make sure that, you know, anything that has that certificate is found, investigated and removed, and you need to get it right away.

And so whether you use, uh, the, uh, the script that we put in our blog, um, you know, by all means, please, please do, but if you have another, whatever method you use, please do it right away, because this one has the potential to be pretty, pretty bad.

All right. Thank you, everybody, for joining us today on Automox's CISO IT podcast. Stay safe out there, and I will see you next time.