Welcome to the Secure AF Cybersecurity Podcast — your tactical edge in the ever-evolving cyber battlefield. Hosted by industry veterans including Donovan Farrow and Jonathan Kimmitt, this podcast dives deep into real-world infosec challenges, red team tactics, blue team strategies, and the latest tools shaping the cybersecurity landscape.
Whether you're a seasoned pentester, a SOC analyst, or just breaking into the field, you'll find actionable insights, expert interviews, and unfiltered discussions with Alias team members and top-tier guests from across the cybersecurity spectrum.
Patches are meant to strengthen security, but they can also give attackers valuable clues. In this episode, we explore how threat actors analyze updates, reverse-engineer fixes, and weaponize vulnerabilities before organizations have time to patch.
Watch full episodes at youtube.com/@aliascybersecurity. Listen on Apple Podcasts, Spotify and anywhere you get your podcasts.
SPEAKER_00
Good morning, good afternoon, or good evening, whenever you may be. And welcome back to another episode of the SOC Brief. I'm your host, Andrew, and today we're talking about an attack campaign that I think is worth paying attention to, not just because it involves multiple zero days, but because of how quickly those zero days went from being vulnerabilities to an actual working attack kit being used by multiple threat actors. This exploit kit is called Blue Moon, and according to research released by ProofPoint, at least four different espionage-focused threat groups began using Blue Moon within days of one another. The first activity was observed on August 28th. Within about a week, Blue Moon was being used against organizations in the United States and Asia, including aerospace companies, NGOs, mining companies, community trading organizations, government-related targets, and manufacturing. And the attack chain is pretty impressive. Blue Moon combines two vulnerabilities in Chrome's V8 JavaScript engine with a Windows kernel privilege escalation vulnerability. So essentially, get code execution through the browser, escape the browser's security sandbox, escalate privilege is in Windows, and then execute whatever payload the threat actor wants on the machine. And that's a pretty complete exploit chain. ProofPoint identified the three vulnerabilities as CVE 2026-85046, 87491, and 85880. Google and Microsoft have since released fixes, and SISA has added exploited vulnerabilities from the chain to its known exploited vulnerabilities catalog. So let's walk through what actually happened. Threat actors sent targeted emails containing links designed to convince specific people to visit attacker-controlled websites. In one campaign, attackers posed as university students interested in internships. Another campaign targeting U.S. aerospace companies use business to business and request for quote themed emails. So the message itself doesn't necessarily look like click here to install malware. It might look like a potential customer, a student, a business partner, or someone requesting information. The victim clicks the link and lands on an attacker-controlled website, and that's where Blue Moon takes over. The first vulnerability gives the attacker code execution inside Chrome's renderer. Normally, Chrome's sandbox is supposed to limit what that code can actually do to the operating system. So Blue Moon chains in another V8 vulnerability to escape the sandbox. Then it fingerprints the Windows machine to determine what version of Windows it's running, and if the system matches one of the supported builds, Blue Moon attempts the third vulnerability, which is 85880, a Windows kernel level privilege escalation flaw. Successful exploitation gives the attacker additional privileges, and from there the exploit chain can break out of the browser and execute an attacker-specified command. The default Blue Moon configuration does something almost surprisingly simple. It calls curl, it downloads an executable, and it runs it. Proofpoint actually pointed out that the final stage creates some relatively high signal detection opportunities because this is not some incredibly stealthy, invisible post-exploitation technique. We're potentially talking about a browser suddenly spawning command line activity that downloads and executes a file. And that's something a SOC can work with. And here's where the story gets even more interesting. Different groups were using the same exploit kit, but delivering completely different payloads. One China Aligned group, commonly associated with the name APT31, used Blue Moon against US organizations and ultimately installed a malicious Chromium browser extension disguised as a Google Gemini extension. Proofoint calls that extension Gemstone. And Gemstone is basically a browser surveillance and credential theft platform. It can capture cookies, monitor keystrokes, access browser storage, take screenshots, monitor browsing activity, and receive commands from the attacker. Think about how much of modern business happens inside the browser now, from things like email, cloud applications, SSO portals, administrative consoles, banking, HR passwords, HR systems, password resets. Even if the attacker never installs a traditional remote access trojan, compromising the browser itself can give them an enormous amount of access. Another group targeting US aerospace organizations use Blue Moon to deploy Shadowpad, and other groups deploy different loaders and persistence mechanisms. Same door, different people walking through it. But the part of this research that really caught my attention is something Proofoint describes as a patch gap zero day. Two of the Chrome vulnerabilities apparently existed in this weird window where the underlying vulnerabilities had already been fixed in publicly available Chromium source code. But those fixes had not yet reached the current stable versions of Chrome and other Chromium-based browsers that users were actually running. For CVE 202685046 specifically, Proofoint says the corrective code was committed on August 7th, and the stable Chrome update didn't arrive until September 3rd. That's almost four weeks where somebody could potentially look at the public code change, figure out what vulnerability Google fixed, reverse engineer it, and build an exploit while normal users were still running vulnerable software. And that appears to be what may have happened here. That is something I think SOX and vulnerability management teams need to start thinking about more seriously. We usually think about vulnerability response beginning when a CVE is published. Vendor announces vulnerability, security team gets notification, we determine exposure, then patch management starts deploying updates. Sometimes the fix itself becomes the disclosure. An attacker doesn't necessarily need somebody to publish a 20-page technical write-up explaining the vulnerability. They can compare the old code to the new code. They can ask what changed, why did they change it? What security assumption did this fix, and then work backwards. The patch effectively becomes the blueprint. And as our ability to analyze code gets faster, including with increasingly capable AI tools, that gap between a security fix becoming visible and a working exploit appearing may continue to shrink. And ProofPoint actually found artifacts inside Blue Moon that they say are consistent with possible AI-assisted development. There were extensive debugging logs, detailed comments describing previous failures and revisions, and even references to markdown handover documentation. Now that's not proof that an AI agent wrote Blue Moon, and ProofPo has been very careful about saying that. But it does raise a pretty important question. What happens when reversing a security patch and turning it into a working exploit becomes dramatically faster because the defenders already have a timing problem. We need to test patches, schedule deployments, deal with maintenance windows, account for applications that break, wait for laptops that haven't checked in, and attackers only need one vulnerable machine. So what should SOC teams be doing about Blue Moon right now? First and foremost, patch your browsers. Google did patch the 85046 in Chrome 152-079782 and .83 on September 3rd and publicly acknowledged that an exploit existed in the wild. Chrome 153 released September 8th and addressed 87491, and Google again confirmed exploitation in the wild. And remember, this isn't just about people who consciously open Google Chrome. Chromium is everywhere. It's in Microsoft Edge, Brave, Vivaldi, and plenty of other applications embedded Chromium components. Know what's installed in your environment and make sure your browser update policies are actually working. Second, patch windows. The CVE5880 was addressed in Microsoft September security updates and is confirmed as actively exploited. The Blue Moon version of the exploit specifically targets several older Windows builds, including Windows 10, Server 2019, Server 22, and the original Windows 11 21 H2 release. And here's an important inventory lesson. Old systems matter. Maybe 95% of your organization is running a current Windows build, and that's great. But the attacker doesn't need 95%. They need the forgotten system sitting in the corner that nobody wanted to upgrade because some business critical application still depended on it. CISA added CVE 2026 85880 to its known exploited vulnerabilities catalog on September 8th. And third, don't assume patching means you're finished. And this is extremely important. Installing the browser and Windows patches prevents those vulnerabilities from being exploited going forward. It does not remove malware that was installed yesterday. If an endpoint was already compromised, your new Chrome version isn't uninstalling the attacker's persistence. So make sure you're hunting. One very simple process chain to look for is Chrome spawning command activity that results in a curl.exe downloading an executable. ProofPoint specifically observed a chain involving Chrome, command execution, curl, and a downloaded executable named msgbox.exe. So look for messagebox.exe or chrome update.exe appearing unexpectedly in user temporary directories. OneBlue Moon campaign created a directory named Stomp underscore ext, and that was in the user's public folder, and that's where the malicious Gemstone browser extension was installed. Review browser extensions, particularly extensions that don't line up with your organization's approved software, and don't assume something is illegitimate because it calls itself Google Gemini. ProofPoint also documented persistence through schedule task with names including EdgeCore underscore auto update, Microsoft Edge Updates Task Machine, AVP Checkup, and GForce Service. Again, don't blindly alert on a name and assume compromise, but those are very good hunting leads when combined with other suspicious behavior. And then go back to the beginning of the attack. Email. These campaigns started with targeted phishing. That means your email telemetry matters, your web proxy telemetry matters, your DNS logs matter, your browser telemetry matters, and anything on your endpoint matters. This is exactly why defense in-depth exists. Maybe your small gateway doesn't identify the initial message as malicious. Your secure web gateway might catch the destination, and maybe that doesn't happen. Your browser protection may prevent exploitation, but maybe it doesn't. Your EDR may catch Chrome launching suspicious processes, and if that fails, maybe your network monitoring sees command and control traffic. An attack chain gives defenders multiple opportunities to win. You don't have to stop the attacker at step one, you just have to stop them before they accomplish the objective. And there's one final lesson from Blue Moon that I think is probably the most important. Exploit capability is moving faster. Proofpoint absorbed four different espionage-focused threat clusters using essentially the same exploit kit within days. A sophisticated browser exploit chain used to be something we associated with pretty small number of highly capable threat actors. Now we're watching one apparently move between multiple groups almost immediately. And Proofpoint believes Blue Moon is likely to proliferate further and potentially move beyond espionage focused actors. And that's the part SOC should really pay attention to. Yesterday's nation state technique eventually becomes tomorrow's ransomware affiliate technique. The question is usually just how long it takes. So my challenge for your team this week is pretty straightforward. Check your browser versions. Don't just check Chrome. Understand what Chromium-based browsers exist in your environment. Verify that September's Windows security updates are actually deployed, particularly to your older systems, and then go hunt. Look for browsers spawning command shells, curl, PowerShell, or unexpected executables. Look for the Blue Moon artifacts we talked about. Review unexpected browser extensions, and identify older Windows systems that may be falling outside your normal patch cadence. But then zoom out a little bit. Ask your vulnerability management team how quickly your organization can respond when an actively exploited vulnerability appears. Not how quickly the policy says you patch critical vulnerabilities, how long does it actually take? Because Blue Moon is a good reminder that attackers aren't necessarily waiting for us to finish our change control meeting. The gap between vulnerability discovery, exploit development, and real-world attacks continues to shrink. Our response time needs to shrink with it. And that's a wrap for this episode of the Sock Brief. If your team has been hunting Blue Moon or you've been looking at ways to better monitor browser based attacks, hit us up through the website or on social media. Keep your browsers patched, keep your eyes open, and keep sharpening those skills. We'll talk soon. Stay secure out there. Bye.
Podcasts we love
Check out these other fine podcasts recommended by us, not an algorithm.