Lessons from a CISA Security Incident

Marc Laliberte  0:00  
Hey everyone, we've got a quick opportunity to share with you all. If you think you've got the next great AI idea for MSPs, now is your chance to make it real. WatchGuard is investing $10 million in AI innovation through our very own AI innovation challenge. We're inviting MSPs to submit their best AI agent or automation idea, and if your idea is selected, our agentic development team will build it with up to $100,000 in funding for each idea selected. Also, one winning submission will win a VIP trip to impact North America in Nashville this October, plus a one-on-one meeting with the WatchGuard executive of their choice, stop imagining, start building, and submit your idea between july 10 and july 29 at secure.watchguard.com/aichallenge. Hey everyone, welcome back to the 443 Security Simplified. I'm your host Mark Lalibete, and joining me today

Corey Nachreiner  0:59  
is Cortney Giga Chad Nachreiner, you love him, right?

Marc Laliberte  1:07  
No, not even a little bit. On today's episode, we will discuss Giga Chad's Giga Wiper. Before that, we'll dive into some research from Wiz on some vulnerabilities in Amazon Q's MCP extension for VS Code, but before that, we'll go through a lessons learned that CISA published about a recent security impact, a security incident that impacted the organization. With that, let's go ahead and I don't know what is a chad- Never mind. Let's just start the episode.

Marc Laliberte  1:52  
Cory, let's start this week with a pretty short but interesting post that I actually I'd like to see from our friends at CISA, the Cybersecurity Infrastructure and Security Agency, that they published just a couple of days ago at the time of this recording, where their acting CIO and acting CISO published a lessons learned article about a security incident that occurred within the organization back in May. And before we dive in, actually, real quick, acting CIO and acting CISO says a lot about the current state of this agency that has not had an actual official confirmation in quite some time.

Corey Nachreiner  2:31  
We take care of cybersecurity for the entire

Marc Laliberte  2:33  
U.S. and we're temporary. Yeah. Anyways, into the post. So on may 15, a investigative reporter inquired about some internal CISA AWS GovCloud keys that they found in a public GitHub repository. So if you're not familiar, AWS with their public cloud, like us normal folks, have access to one version of AWS's cloud, and they maintain a totally separate version for government usage. Think like

Corey Nachreiner  3:07  
approved.

Marc Laliberte  3:09  
Yep, think like U.S. security agencies, like CISA, the Defense Department would be using this as well too. It's completely separate from the normal public cloud, but it operates effectively the same with most of the same services running in the same ways you would access it, just different sets of keys. But CISA's own AWS GovCloud keys, like a credential to log into that environment with some level of access, would be pretty dang important to secure and prevent from falling into unwanted hands. A little,

Corey Nachreiner  3:43  
just a little. But so they became laying around all the time. No one cares

Marc Laliberte  3:49  
exactly. But so a security researcher in May noticed that they were in a public repository. They reached out to a journalist firm, who then reached out to CISA to basically point it out and ask for comment, which sent CISA into incident response mode. And so, in this post, they walk through like their incident response process, at least at a high level. And I thought it's interesting for us to go through that. They talked about how they first took containment steps by bringing that public repository offline while also saving a copy for later analysis. So, assuming they wanted to make sure, like exactly what was in it at that point in time, which is why they saved that copy. They did note that the repository was not a part of their official GitHub organization, but it was a personal repository owned by a contractor, which is probably how it was allowed to become public in the first place, but we'll get into the the whole data disclosure issue in a second for how that ended up in a a personal GitHub repository. They also took down their entire development environment and reset all credentials associated with it, basically to prevent those leaked credentials. From being used anywhere within Cissa's GovCloud accounts, they revoked system access from the individual who exposed the keys. So the person who accidentally made that public repository temporarily disabled their account, and then they started investigating that copy of the public repo, where they found that the individual had uploaded first copies of CISA's build and deploy repository, basically their CI/CD pipeline maintained as infrastructure as code. This individual had gotten a copy of that and posted it to their own personal GitHub repository, which they believe they were trying to set up like infrastructure for deploying autonomously by just reusing that code, but in the worst way possible. Unfortunately, that repository had had secrets saved into it at some point in time. These GovCloud AWS keys. So when that individual copied it from the private repository where the secrets were present, but at least they were private internal only, to now those public one. That's how they got leaked. Pausing there for a second, like, and they talk about it towards the end. One of the big issues for this that caused this to be such a concern was those credentials were saved in the repository long before this copy became public. So presumably they were missing some sort of like secret scanning or secret identification service in their code repositories that would have caught this. They then started investigating the credentials. They confirmed that they, even though they were exposed, they were not used outside of Syss's environments. So no one had found them yet and started using them. At least, they also confirmed that no customer or emission data had been exposed through these credentials. And then they talk about their corrective actions. All credentials across all environments that this contractor had access to, they went and rotated all of those secrets, not just the ones that were exposed. They also set up a allow and deny list for code repositories, basically further restricting who has access to what. And then they also implemented a rule to limit the ability for a user to upload a public code repository. Just period. In general, that's like an enterprise control you can turn on within a GitHub organization. So there are a couple things that like went wrong in here, but they pointed out a couple of things that went well. Like first off, they took that report seriously and acted on it immediately, and they are able to effectively contain this before those credentials were used by anyone else, which is, I think, a great success in that front. They also noted they already had strong visibility and zero trust controls across their environments, which helped with incident response. Like they wouldn't have been able to investigate and confirm that they weren't used if they didn't have high confidence that they had visibility into everywhere that it could be. And then they also noted their logging pipeline was already was a good help in that front too. But when it comes to things that did not work well, they pointed out first off those missing controls on public repositories for an agency like CISA. I imagine some users have a need for creating public repositories.

Marc Laliberte  8:24  
Like CISA maintains some open source tools, like I think Scuba is their creation. So they'll want some users to be able to do it. But at least like other roles, like maybe this contractor potentially working on just internal only stuff, it makes sense to restrict their ability to publish things publicly. They also pointed out they were missing the capability to monitor for secrets in their repositories, which would have flagged this issue long before it became public. So even if their like infrastructure as code was copied publicly, at least there wouldn't have been access keys in it. They also pointed out something I think all of us can learn from this, where they were missing a playbook for this scenario too. They noted that like when this happened, they were basically the first bit of time they had to spend just figuring out what the heck to do, instead of having a playbook already defined for it. And I think that's an area that like a lot of organizations can maybe take a step back, look at their critical applications, like what's most important in their tech stack, and proactively create playbooks for how you would respond to incidents involving those too. That way, you can hit the ground running immediately when something like this pops up. And then finally, one that stood out to me is CISA said their incident reporting channels were not well defined, which kind of blows my mind because they are like one of the top advocates for good security incident and vulnerability reporting practices for companies. They're heavy advocates for radical transparency and working with external researchers. It was kind of funny seeing CISA admit that. It's actually kind of tough for this researcher to get a hold of them, which is why they went through the the news outlet instead of like directly the system. Do do

Corey Nachreiner  10:08  
as I say, not as I do.

Marc Laliberte  10:11  
It's I don't think there's anything malicious about it. Like it seems like it's more of an oversight kind of thing where they they realize they their information wasn't very clear to researchers.

Corey Nachreiner  10:22  
We don't have. They pointed out security.org or whatever security at org.

Marc Laliberte  10:28  
Exactly, and so they actually they do have that. But the issue was this researcher didn't go look at that, and they pointed out that not all researchers rely on securities.txt as a file on the domain,

Corey Nachreiner  10:41  
which

Marc Laliberte  10:41  
is why it was it was difficult. So, I I like the transparency coming from an organization like CISA. I I would in fact I would like transparency from the U.S. federal government on like all security incidents. Obviously, you have to maintain some level of secrecy with like federal agencies, but there's something all of us can learn from public organizations like this when they do encounter an incident and how they went through it. And so I really liked seeing this from the acting CIO and acting CISO over at CISA. I'm also surprised that there are still any executives at CISA or any employees at CISA. So that was a nice surprise too. Yeah,

Corey Nachreiner  11:22  
this is a good thing. I can't. I can't hammer that. It's a good thing to share. I was hoping that in one, by the way, not just CISA, not just the government. I would like to see organizations be more transparent about the details on their breaches, not to like air dirty laundry, but to help the industry and everybody in security to recognize new potential threats. My only downside on this is for people that have followed security a lot. This you you feel like it's just going to share an incident, and they want to share it transparently for learnings. Maybe it's going to be some sort of novel new type of thing, but honestly, the whole oh I had a public, I had secrets in my repository. Oops, and insider took one of my private repositories and put it in their public repository. This is something that I think all organizations will even say we've had cases of this where external actors never found it, but we we have had to clean up our own practices and make sure there was an awareness with developers that they shouldn't be copying private code to their their personal repositories. But I think the story itself and the learnings aren't necessarily new. It's something I feel like we talked about five years ago because it was happening quite a bit. So, in a way, it's kind of wow. Cis is probably reported on other companies having shared secrets in a repository, let alone a personal repository having private information. So it's kind of funny that this is the one they're transparently talking about.

Marc Laliberte  13:00  
I think it's clear that nobody is perfect, not even CISA in this case.

Corey Nachreiner  13:04  
I guess that's a very good point. Nobody is perfect.

Marc Laliberte  13:09  
Yeah, and I will say one thing

Corey Nachreiner  13:11  
they didn't talk about is contractors, and this is something we think about ourselves, you and I, as someone that safeguards WatchGuard's data. Is businesses use contractors. Everyone uses contractors. There's nothing wrong with that, but I'm sure every company has a policy for normal employee acceptable use, normal employee onboarding, and normal employee security practices and configurations. But contractors, do you have a policy for how you onboard and handle the security of contractors? Because you're probably going to have different levels of contractors. You're probably going to have contractors that have limited access and bring their own devices. The fact that they bring their own devices that you don't control could be an issue versus a contractor that you might give deeper access that maybe you need to require them to use your devices, or so. Anyways, one thing not mentioned in the report is having a policy about contractors or external organizations you work with that you start to give privileged insider access. Maybe CISA was very good at training their developers not to copy repositories to other places, but the the key thing here was a contractor. So, one additional thing to think about from the learnings that CISA shared, CISA, I should say, CISA. I guess, yeah.

Marc Laliberte  14:34  
Oh boy. Well, I was almost on your page, but now I'm not.

Corey Nachreiner  14:38  
Hey, that's how I remember when we finally talked to them, and they told us it was CISA,

Marc Laliberte  14:43  
yeah, that is fair. But I would like-I hopefully they don't have another security incident in the future. But if they happen to, then I hope they continue to be transparent about this and continue publishing lessons learned. And even if it's not CISA, it'd be nice for them to publish lessons. Learned about the other federal agencies that they're mandated to secure too. So, like, if you are a an organization that does any software development, if you have got any secrets in GitHub, like this is a good lessons learned for you to take and learn some lessons from too before becomes an issue for you and your organization. But moving on. So another post that I saw this last week that was pretty interesting. Our friends over at Wiz from their research team published a blog post describing a vulnerability that they found in the Amazon Q Developer Extension for VS Code. That's CB 2026 12957 So Amazon Q Developer Extension. It's like one of a series of AI coding assistant extensions, kind of like Clog Code or Codex or Cursor, that a software developer can include in their IDE, like VS Code, to bring in this AI-powered software development help. This one's Amazon Q.

Corey Nachreiner  16:02  
James Bond's Q. Do you think that's why they named it Amazon Q? It

Marc Laliberte  16:07  
is. I mean, there's a lot of James

Corey Nachreiner  16:08  
Bond that brought you all the cool tools, AI tools in this case.

Marc Laliberte  16:14  
There's a lot of dumb names in AI, and this is definitely one of them towards the top of it.

Corey Nachreiner  16:19  
Does that mean you think Q and James Bond is dumb?

Marc Laliberte  16:23  
I don't think that. Yeah, I don't think he's dumb. I think I have no idea what Amazon is thinking about this, and it's not catchy. It's whatever. I'm not in product marketing. What do I know? I just think it's silly. But so this vulnerability allows arbitrary code execution and cloud credential theft simply by a developer opening up a malicious repository. They don't have to take any action once they've opened it. If they are just tricked into opening something malicious in their VS Code application with this vulnerable extension installed, boom, the attacker can execute arbitrary code. So they describe the issue, and actually, first they lay the foundation where when you open up a project folder in VS Code or any other developer tool, you're implicitly trusting a bunch of files that are in it. Now, most of them are usually configuration files. They're things that help set up the environment itself, maybe configure whether it wants four spaces or one tab for code indentation, things like that, or even more complex configuration items too. But generally, those things that automatically run and automatically apply, they can't execute code on their own. But extensions to VS Code kind of blur that line, like they said, where they may read a workspace-specific configuration, but then act on it automatically without letting the user know. So next thing he went through a refresher of Model Contacts Protocol or MCP, which is a protocol that lets AI tools spawn and run processes on the computer to extend their capabilities, could do something like make an API call or connect to a database, run a local build tool, or just access a local resource. It's basically a way for an AI to interact with other stuff in the environment. And that security model, though, assumes that the developer is the one that configured that MCP server and that integration that they are the one explicitly authorizing the AI tool to have access to this action to be able to do something like internally at WatchGuard we've got MCP servers for connecting to our source code repositories our knowledge repositories for us and the security team and our red team you've got MCP servers for connecting to like Cali Linux virtual machines, to other penetration testing tools like Burp Suite and Metasploit. It opens up a lot of activity that these AI tools can use, so it's really powerful and opens up an opportunity for risk in this case. So they found two issues with Amazon's MCP implementation within, or at least how Amazon Q's extension handled MCP server configurations. First, it auto executes without consent, so it'll load up the MCP configuration file, which is just a JSON file with like a description of what the server is, how it works, what actions it should do, including ones that it can run automatically when it's loaded. So it loads that up immediately upon opening the folder without any dialog to approve those MCP servers that are in that file, and then also the extension gives full environment access. So it'll spawn a process that inherits the user's complete environment, which could include environment variables for like secrets, like AWS keys, authentication tokens, API keys, even SSH agent sockets to like connect to remote resources. So basically, by opening up a repository that has this MCP. Figuration in it. If you have the Amazon Q extension enabled, it will execute an MCP server, meaning a malicious one in there could run a command. So, like steal your credentials or exfiltrate them out to a server. Basically, the attacker has control over what would run. So, they Amazon did actually fix this. Now there there's a display that pops up like a prompt telling you that Q wants to load a MCP server. It tells you what it does and asks for permissions, but they pointed out that this is like a broader pattern of just auto executing workspace issues that are affecting a bunch of other extensions too. There are several from Cloud Code, one from Cursor, one from like NPM, the the JavaScript Package Index, where as good as like Microsoft has gotten at securing VS Code itself, these extensions are just opening up another door for potential opportunities for attackers to execute code without the victim knowing, I think this is important.

Marc Laliberte  21:04  
Like Corey, how many times in the last year have we talked about stories where, like, threat actors are targeting software developers through like fake jobs where they say, "Oh, go open this repository as a test. Like, go, I want you to implement this fix in this sample repo, and that's enough to execute code on their system. Like this is another up. This would have been another opportunity until Amazon patched it for that style of social engineering attack against a unsuspecting developer.

Corey Nachreiner  21:33  
They mentioned fake jobs in this post too. Yeah,

Marc Laliberte  21:38  
but it's good to see them add that prompt. Like VS Code itself, the platform already has a lot of protections for this. Anything that could potentially like cause changes on an endpoint already prompts the user. Like, do you want to? Do you actually trust this repository? It tells you don't do it for public ones if you're not sure what's going on. So there's some like seatbelt chimes for that, I guess, but it feels like the extension ecosystem maybe needs a little bit more overall control from the platform itself from VS Code, so that extensions like this can't screw their users by just executing code without them knowing from a repository. For sure. Either way, like I said, it's fixed. So for like the three developers in the world that use Amazon Q, you're now safe. And then for everyone else that uses Claude or or Codex, they've already patched similar issues in those extensions earlier this year too. I shouldn't throw stones. I haven't actually tried Amazon Q's stuff. Maybe it is decent and cost effective. Who knows? My gut tells me no. But moving on to the the last one, mr. Giga Chad, Microsoft's threat research team published a blog post just this last week, describing a what they're calling Giga Wiper attack, which is basically a what they originally thought was a backdoor, but it turns out to be this like amalgamation of multiple destructive wiper tools all bundled into a single platform. It started in October 2025 when they discovered a GoLang-based backdoor that was doing destructive wiping activities, and they've now realized this is just one coordinated campaign. And the interesting thing is, it's not like a single-purpose-built tool. It looks like it's a collection of different malware families and different techniques from other tools that they've rewritten in GoLang and packaged into Europe,

Corey Nachreiner  23:46  
and probably also ones that come from the same Giga Chat threat actor too, right? Probably yes, probably the same threat actor. I'll stop talking about Giga Chat. Thank you, I appreciate it. Although maybe I'll just picture it for a while for everyone to enjoy.

Marc Laliberte  24:04  
Perfect. So this this malware supports multiple modes of destruction. So it's got one wiping method that can just overwrite the raw disk contents, like your hard drive, and remove partition metadata. It's got a wiper that they derive from the Crucio ransomware family that encrypts files with randomly generated keys that are just never saved or transmitted anywhere. And then there's a GoLang implementation of a tool called Flock Wiper, which does like a multi-pass secure wiping of a storage device too. Now all of these are they're wipers, meaning it's not ransomware. Where if you pay an extortion, you can get keys back, get your data back. It is it destroys the data often irrecoverably, with no way of no way of getting it back, and as the intention for it. And the attackers combined all of this into like this modular backdoor that also. Has a bunch of command and control capabilities and other functionality too. So in their blog post, Microsoft they went through all the different components of this, starting with just a standalone wiper binary, where it starts by like iterating through the disks attached to your computer to get metadata. It then removes and recreates that partitioning metadata on each storage device, which basically wipes the partitions and recreates them. And then it goes through each device and overwrites the raw data, like with chunks of just zeros, and then reboots the machine. So when the machine reboots back up, it's got totally different partitions with totally blank data, effectively rendering it unusable unless you can use some expensive storage recovery software. That same standalone wiper was also implemented in a larger backdoor malware that has a whole bunch of other functionality. So it gains persistence with a scheduled task called OneDrive Update. It communicates to a command and control server using a protocol called RabbitMQ, which is like a message queuing service to receive commands, and then uses Redis to send back the results of those commands back to the attacker. And then it's got a kind of nice stealth c2 channels. You know, it's those are legit potentially things, so may not be things that defenders always look for for c2 channels. Yep, and it's got like 20 different commands that this thing supports too. Everything from like executing that first wiper. There's another one where it will a command it can run that basically destroys the Windows recovery partition, then deletes a couple of critical kernel files to trigger a blue screen of death that is unrecoverable on the system. That one's pretty mean. There's one that encrypts all files and renames them with the dot candy extension with keys that just aren't saved-that's pretty rude. There's some basic like file exfiltration commands to just steal data from the endpoint, send it to remote storage. There's another encryption process that actually does support passing in a a key and a an IV variable that the attacker could know, so you theoretically could get recovery from it. It also supports just not passing those in, so it's randomly generated, and there's no way to recover it. It's got ways to execute arbitrary executables, PowerShell. It can take screenshots or screen recordings. It's got that multi-pass secure wipe for the the C drive, and ways to cover its tracks by deleting Windows event logs, among many other things. Now, Microsoft didn't go as far as to like have attribution for this one. Not even like a specific geographic region. We

Corey Nachreiner  27:50  
know it's Giga Chat, Mark. We already know it's in the name,

Marc Laliberte  27:54  
right? But I know, like, just from previous Wiper attacks, they seem to be very focused on like Eastern European conflicts right now, right? And so that is one possibility. If I was gonna make a guess, an educated guess from it, I know. And sometimes like China has gone after other Southeast Asian organizations too. Yep. But yeah, don't wave too hard, Corey. We don't want to attract their attention anymore. But like wiping is just like a whole nother, like as crappy as ransomware is. Like getting a an attack from a wiper is just a really bad time since it is theoretically unrecoverable if you don't have good backup and recovery practices.

Corey Nachreiner  28:43  
Yeah, as you said before, it's kind of rude.

Marc Laliberte  28:46  
Kind of rude.

Corey Nachreiner  28:48  
People with young kids a decade ago, wiper, no wipe eating.

Marc Laliberte  28:52  
Oh my god!

Corey Nachreiner  28:53  
Backpack, backpack.

Marc Laliberte  28:57  
Yep, perfect. What kind of podcast is this? Nickelodeon or security?

Corey Nachreiner  29:02  
Is that what Dora was on?

Marc Laliberte  29:05  
I had a little sister that liked watching it, so yes, it is Nickelodeon. But anyways,

Corey Nachreiner  29:11  
your little sister. I had a friend. I'm asking for a friend. Sure, Mark.

Marc Laliberte  29:18  
Hola, Yosoy Dora. Anyways, back to the story. the The good news is that, like at least with wipers, like I guess this one had some data theft capabilities, but it was pretty rudimentary. Like there is still a way to recover from it with good backup and restoration procedures. But if the wiper just deletes your entire system partitions, like that is a very manual recovery process for at least like hardware versus virtual machines, which might be. We

Speaker 1  29:46  
don't have

Corey Nachreiner  29:47  
any evidence, but to me, this is clearly nation state because this is a mix of destructive and espionage. Like having the back door there, there's plenty of opportunity for file stealing, espionage, and actually retaining file. Data, but the wiping is a fantastic way to have plausible deniability once you get caught. So this feels completely nation state to me.

Marc Laliberte  30:13  
I agree with that assessment.

Corey Nachreiner  30:18  
But what does no? I'm going to go back to watching Dora.

Marc Laliberte  30:23  
Good. I'm glad you're focusing on that instead of much more important things, like I don't know, helping us secure the ecosystem.

Corey Nachreiner  30:33  
But we're fine. We have you as the director of SOC. So again, hi G, are you poking tigers today.

Marc Laliberte  30:42  
We are fine. Everything is fine. The world is fine.

Corey Nachreiner  30:46  
Flames,

Marc Laliberte  30:49  
and hopefully everyone else's data backup and recovery procedures are fine too. Hey everyone, thanks again for listening. As always, if you enjoyed today's episode, don't forget to rate, review, and subscribe. If you have any questions on today's topics or suggestions for future episode topics, you can reach out to us on Blue Sky. I'm at it's Mark.me. Corey's at SecAdept. We're both also accessible over email. Bet you can guess what our email addresses are, and you can find us on Instagram at WatchGuard underscore Technologies. Thanks again for listening, and you will hear from us next week.

Corey Nachreiner  31:23  
Make sure to join our AI competition for innovation.