Friday, July 17, 2026

GoldenEyeDog Subgroup Linked to DigiCert Breach and Code-Signing Certificate Theft

Cybersecurity researchers have attributed the April 2026 DigiCert security incident to a threat activity cluster dubbed CylindricalCanine.

Expel, which shared technical details of the event, described the threat actor as a sub-group of GoldenEyeDog (aka APT-Q-27, Dragon Breath, and Miuuti Group), a Chinese cybercrime group known for its targeting of the gambling and gaming sectors using counterfeit websites to push malware-laced software. It's known to be active since at least 2015.

"In April 2026, GoldenEyeDog used their malware to access a support member's device at DigiCert, a code-signing certificate provider, and leveraged their access to steal certificates intended for DigiCert customers," Expel security researcher Aaron Walton said in an analysis. "This attack highlighted the capability of the malware and operators."

Central to the threat actor's operations is a modified version of Gh0st RAT (aka Farfli), a remote access trojan (RAT) widely used by Chinese hacking groups, including another prolific Chinese cybercrime group tracked as Silver Fox. The modular malware, referred to as Golden Gh0st RAT, is delivered by means of Golden Gh0st Loader.

In a report published in November 2025, Elastic Security Labs detailed the adversary's use of a multi-stage loader codenamed RONINGLOADER to distribute a Gh0st RAT variant through NSIS installers masquerading as legitimate programs like Google Chrome and Microsoft Teams.

Earlier this year, another campaign linked to the hacking group was observed orchestrating a multi-stage attack directed at customer support staff working for Web3 companies, using suspicious links sent via customer support chat to deliver Gh0st RAT.

"These actors are using malware and targeting victims consistent with other Chinese cybercrime activity, including targeting finance organizations in the Asia-Pacific region," Expel said. "The malware targets finance organizations in the Asia-Pacific region."

Golden Gh0st RAT shares behavioral and tactical overlaps with a payload detected by Chinese security vendor QiAnXin back in 2020 in connection with an attack campaign aimed at the gambling industry since 2019. It also overlaps with a malware documented by ANY.RUN in February 2025 as Zhong Stealer.

The DigiCert Compromise

What's more, CylindricalCanine has been observed abusing code-signing certificates, gaining unauthorized access to DigiCert to intercept code-signing certificates intended for DigiCert customers, and then using them to sign their own malware to avoid detection.

In April 2026, the certificate authority (CA) revealed it revoked certificates fraudulently obtained from its internal support portal after gaining access to two support analyst workstations by executing a malicious payload delivered via a customer chat channel.

"On 2026-04-02, a threat actor contacted DigiCert's support team via a customer chat channel and delivered a ZIP file disguised as a customer screenshot," DigiCert explained at the time. "The file contained a .scr executable with a malicious payload."

"The threat actor used a limited function within the customer-support portal, which allows authenticated DigiCert support analysts to access customer accounts from the customer's perspective to facilitate support tasks. The threat actor was able to use this function to access initialization codes for orders that were approved but pending delivery for EV Code Signing certificate orders across a finite set of customer accounts."

The fatal oversight here was that the possession of an initialization code, coupled with an approved order, was "functionally sufficient" to obtain EV Code Signing certificates across a set of customer accounts and CAs. The company said it revoked 60 certificates issued by the following CAs -

  • DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1
  • DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
  • GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1
  • Verokey High Assurance Secure Code EV

Of these, 27 are said to have been explicitly linked to the threat actor, with the exploited certificates weaponized to sign Zhong Stealer malware artifacts.

"The threat model did not account for the scenario in which initialization codes stored within DigiCert's internal support portal could be viewed by a compromised DigiCert analyst account operating through the portal function," the company explained, adding it has since deployed a code change to mask initialization codes from proxied users on both E.U. and U.S. platforms using either the UI or API.

Attack Chains Lead to Golden Gh0st RAT

Expel said the primary tactic of CylindricalCanine is to distribute files disguised as screenshots in phishing emails. The files are embedded within the messages in the form of a link that, when clicked, downloads additional payloads from an external server.

The end goal of the attack is to trigger a DLL side-loading chain, leveraging a legitimate executable to run a rogue DLL, while simultaneously displaying a decoy PDF document displaying an HTTP 503 "Service Unavailable" error. The DLL then proceeds to load an encrypted payload ("update.log").

The final stage is Golden Gh0st RAT, which comes with a wide array of capabilities to set up persistence, steal sensitive data, start a SOCKS proxy tunnel, suppress display output, log keystrokes, take screenshots, enumerate processes, execute shell commands, drop additional payloads, and clear Windows Event logs. Some of the applications it specifically targets for data collection include Skype, Google Chrome, Mozilla Firefox, 360 Secure Browser, 360 Speed Browser, and Tencent QQ Browser.

The findings make CylindricalCanine the latest addition to a list of threat actors, such as Black Basta, TamperedChef (aka EvilAI), and Rhysida, that are known to abuse code-signing certificates in their cyber operations.

"Golden Gh0st RAT is used primarily in phishing emails and/or submissions to support portals (these submissions may themselves be emails received by a ticketing system)," Expel said. "As with all Gh0st RAT variants, the capability of the malware is handled through plugins and an internal module dispatcher."



from The Hacker News https://ift.tt/4CNnbod
via IFTTT

Microsoft at Black Hat USA 2026: Defending trust in the age of AI and supply chain attacks

Across the threat landscape, in this moment, one pattern sits at the center of the story: threat actors are following trust.

They are not only looking for vulnerable systems, but rather targeting the software, services, identities, tools, developer workflows, and AI systems that organizations already depend on.

A package can become a distribution path. A build pipeline can become an access path. A trusted tool can become or expand an attack surface. An AI agent with the wrong access can become a new way to reach code, data, or infrastructure.

While the surfaces may change, the goal for the majority of threat actors remains the same: find what is trusted, abuse it, and scale the impact.

At Black Hat USA 2026, Microsoft Security will walk through how we are seeing this shift unfold, how security teams can look for it earlier, and how threat intelligence, expert-led response, and security operations need to work together when campaigns move across software, identity, cloud, data, and AI systems.

On Wednesday, August 5, 2026, the day begins with David Weston’s keynote, The End of Rare: Defending When Offense Is Cheap, which looks at what defense requires when offensive capability becomes easier to access, automate, and scale. Later that afternoon, Aarti Borkar and Tanmay Ganacharya will resume the main stage for Poisoned at the Source: Inside the Hunt for Supply Chain Attacks, which offers a closer look at how Microsoft Threat Intelligence is hunting attacks across software ecosystems, developer workflows, and trusted services. This includes details into the ongoing attacks on npm (Node package manager). 

Together, these sessions frame the challenge security teams are facing now: when offensive capability becomes easier to scale, security teams need to understand the trust paths threat actors can abuse before those paths become open doors for attacks. 

At our booth, we’ll also showcase Microsoft Defender Experts Threat Intelligence, a new expert-led service delivering continuous, curated intelligence tailored to your organization, and Microsoft Defender Experts MDR, now extended with third-party and multicloud coverage.

From August 4 to 6, 2026, at Mandalay Bay in Las Vegas, you’ll find Microsoft Security on the Business Hall floor at booth #2144, and on Wednesday evening, join us at the Microsoft Security reception at Swingers at Mandalay Bay.

Weston on the future of defense 

At 9:15 AM PT on Wednesday, August 5, 2026, David Weston, CVP of Agentic Security, will examine what changes for security teams when offensive capability becomes easier to access, automate, and scale. 

The keynote sets up one of the central questions security leaders are facing now: how does the security operations center (SOC) and analysts adapt when threat actors can move faster, test more often, and reuse trusted paths across software, identity, cloud, and AI systems? Join the keynote Wednesday, August 5, 2026, then continue the conversation with Microsoft Security at booth #2144. 

Our latest intelligence (and response) on npm supply chain attacks

That same intelligence-to-action challenge is at the center of our main stage session at Black Hat. 

On Wednesday, August 5, 2026, from 2:30 PM PT to 3:00 PM PT, Aarti Borkar, Corporate Vice President (CVP), Microsoft Security, and Tanmay Ganacharya, Vice President of Microsoft Security Research and Threat Intelligence, will share intelligence and insights into the ongoing supply chain campaigns impacting all areas of the threat landscape. The talk, Poisoned at the Source: Inside the Hunt for Supply Chain Attacks, will walk through Microsoft Threat Intelligence’s investigations into the ongoing npm supply chain attacks targeting software ecosystems, developer workflows, trusted services, and how organizations are handling the challenges associated with npm packages.

Follow the research in the Black Hat Briefings

Microsoft Security researchers will also present peer-reviewed technical research in the Black Hat Briefings. These sessions go deep into cloud, mobile, and software supply chain defense.

GitHub Can Tell You’re Being Hacked. You’re Just Not Listening: Building EDR for GitHub from Its Own Event Stream

  • Presented by Yossi Weizman, Principal Security Research Manager
  • Wednesday, August 5, 2026, from 10:15 AM PT to 10:45 AM PT

One Click to System: Exploiting Bixby’s Trust Model for Full Device Compromise

  • Presented by Dimitrios Valsamaras, Senior Security Researcher
  • Wednesday, August 5, 2026, from 12:00 PM PT to 12:40 PM PT

Handle With Care: Chaining Azure Automation Flaws for Cross-Tenant Identity Takeover

  • Presented by Shay Shavit, Senior Security Researcher
  • Wednesday, August 5, 2026, from 4:30 PM PT to 5:10 PM PT

Check the official Black Hat schedule for final room assignments and any timing updates.

Go deeper in Microsoft sessions

Microsoft experts will also lead sessions that give you a closer look behind the scenes, including:

Mind the Gap: Turning Threat Intelligence into Decisive Action with Expert-Led Defense

  • Presented by Wes Malaby, General Manager of Customer Success
  • Wednesday, August 5, 2026, from 5:00 PM PT to 5:20 PM PT

Cyber Defense Showdown

  • Presented by Fanta Kaba and special guest Jimmie Galaites
  • Wednesday, August 5, 2026, from 5:00 PM PT to 5:20 PM PT

Agentic Security: What’s Next

  • Presented by Naadia Sayed, Principal Product Manager
  • Thursday, August 6, 2026, from 11:15 AM PT to 12:00 PM PT

These sessions extend the main stage story into practitioner decisions: how teams move from intelligence to action, how defenders test their judgment under pressure, and how AI and agents are changing security workflows.

Visit booth #2144 for research, community, and hands-on defense

This year we are transforming the Microsoft Security booth into a community center. Click here to jump to the full schedule.

If the keynote and main stage sessions frame the largest challenges across the threat landscape, booth #2144 is where you can directly explore the workflows behind it: threat intelligence, incident response, AI security, security operations, partner solutions, and hands-on practice.  

You will find:

Connection circles, ask-me-anythings (AMAs), meetups led by industry influencers, and lightning talks

Short-form conversations with practitioners and experts on threat intelligence, incident response, AI security, identity, data protection, and security operations. If you swing by when the expo area opens, we’ll also fuel you up so you can skip the food court.

Partner presence

At Black Hat 2026, the Microsoft booth will feature 13 partners from the Microsoft Intelligent Security Association (MISA) who will showcase solutions built with Microsoft Security technology. Security Insider Conversations will feature MISA partners Critical Start (August 5, 2026, at 3:30 PM PT) and Huntress (August 6, 2026, at 2:00 PM PT) alongside Microsoft Security experts. Additionally, thank you to our Microsoft Security VIP Mixer sponsors: Ascent Solutions, Avertium, Devicie, Huntress, Illumio, Maureen Data Systems, and Security Risk Advisors. 

Demo our latest innovations

Explore connected experiences across defending with AI, securing AI, strengthening posture for AI adoption, using security intelligence in investigations and response, working with trusted partners, and connecting with Microsoft Defender experts.

Exclusive swag (featuring a surprise guest)

Spend some time with us at the experience we built around the booth and you’ll earn tokens that can be exchanged for custom patches and hats (because security experts have to wear many hats). Your favorite paperclip may be among the patches. Maybe.

Decompress with mini golf

The biggest Microsoft Security community moment of the week is our reception at Swingers at Mandalay Bay, hosted by Aarti Borkar.

Join us Wednesday, August 5, 2026, from 6:00 PM PT to 9:00 PM PT for food, drinks, mini golf, partner activations, and time with the Microsoft Security team away from the show floor.

Come compare notes with peers, meet Microsoft researchers and responders, and connect with the broader Microsoft Security community.

Space is limited, so reserve your spot early.

Plan your week with Microsoft Security

You can find Microsoft Security at booth #2144 during Business Hall hours:

  • Tuesday, August 4, 2026: 4:00 PM PT to 7:00 PM PT
  • Wednesday, August 5, 2026: 9:00 AM PT to 6:00 PM PT
  • Thursday, August 6, 2026: 9:00 AM PT to 4:00 PM PT

Stop by early to see the booth schedule, find upcoming AMAs and connection circles, and plan which live sessions and hands-on experiences you want to attend.

Skill up before and after Black Hat

You do not need to be in Las Vegas to take part in the broader Microsoft Security Black Hat experience.

The Microsoft Black Hat Skilling Challenge begins July 20, 2026, and will help defenders build hands-on skills across Microsoft Defender, Microsoft Sentinel, and Microsoft Security Copilot. Attendees can use the challenge to prepare before the event, then bring questions to on-site experts and community sessions. Remote participants can follow along through Microsoft Tech Community, AMAs, recaps, and post-event resources.

See you at hacker summer camp

Threat actors are adapting around the systems organizations already trust. Security teams need to understand those trust paths before they become attack paths.

At Black Hat USA 2026, Microsoft Security will bring the research, expert perspective, and hands-on experiences to help practitioners see where attacker behavior is moving and how defense can adapt.

Add Poisoned at the Source to your schedule. Visit us at booth #2144. Join the skilling challenge. And register for the Microsoft Security reception on Wednesday night.

Microsoft Security booth #2144 experiences and schedule

Tuesday, August 4, 2026

TimeTitle
5:00 PM PT to 6:00 PM PTHow Practitioners Build Effective Security Playbooks
6:00 PM PT to 7:00 PM PTAgentic Security: What’s Next

Wednesday, August 5, 2026

TimeTitle
9:00 AM PT to 9:30 AM PTSecurity Communities Meet Up
10:00 AM PT to 10:30 AM PTUsing Offensive Security Research to Advance AI Security
10:30 AM PT to 11:00 AM PTThe Confused Deputy Strikes Back: How AI Agents Turn Into RCE Proxies
12:00 PM PT to 12:30 PM PTHunting in the Gray: When Nation-States and Cybercrime Collide
12:30 PM PT to 1:00 PM PTAI in Security Operations: What Actually Works and What Doesn’t
1:00 PM PT to 2:00 PM PTAI in the SOC: Lessons Learned from the Front Lines
2:30 PM PT to 2:30 PM PTMicrosoft Defender Challenge
2:30 PM PT to 3:00 PM PTFrom Alert Fatigue to Action: How Practitioners Prioritize What Matters
3:00 PM PT to 3:30 PM PTAgents in the Flow of Work: From Signals to Action
3:30 PM PT to 4:00 PM PTWill It Hold Up in Court? Forensic Defensibility of Microsoft 365 Evidence
5:00 PM PT to 6:00 PM PTZero Trust for the Agentic Era: An Interactive Discussion for Securing AI

Thursday, August 6, 2026

TimeTitle
9:00 AM PT to 9:30 AM PTThe Future of Microsoft Security and How Communities Can Support You
10:00 AM PT to 10:15 AM PTQuantum Is Here: What Practitioners Must Do Now
11:00 AM PT to 12:00 PM PTThe Next Era of Cyber Defense: Clarity, Control, and Response at Scale
12:00 PM PT to 12:30 PM PTLessons from the Field: What to Do When You’re Under Attack
12:30 PM PT to 1:00 PM PTWhen Browsers Become Agents: The Emerging Security Risks of AI‑Powered Browsers
2:30 PM PT to 3:00 PM PTSocial Engineering Always Matters
3:00 PM PT to 3:30 PM PTAI Runs on Data: Securing the Foundation of AI Adoption

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Microsoft at Black Hat USA 2026: Defending trust in the age of AI and supply chain attacks appeared first on Microsoft Security Blog.



from Microsoft Security Blog https://ift.tt/pVNKBz3
via IFTTT

The Good, the Bad and the Ugly in Cybersecurity – Week 29

The Good | Authorities Sanction Cybercriminals & Dismantle Russian Bulletproof Hosting Infrastructure

The EU and the United Kingdom have jointly sanctioned multiple Russian individuals and entities for targeting government networks and critical infrastructure across Europe. The sanctions specifically target senior Russia military intelligence (GRU) officers and operators, as well as four entities linked to the Federal Security Service (FSB).

Officials say that the Russian government actively utilizes these state-sponsored units alongside recruited cybercriminals and private companies to systematically destabilize international partners and compromise key infrastructure across the continent.

From the U.S. Treasury Department, two individuals and a virtual private network (VPN) provider face sanctions for actively enabling ransomware attacks against American organizations.

OFAC designated First VPN Service (1VPNS) and its administrator, Dmytro Rashevskyi, for supplying infrastructure that helped cybercriminals obscure their identities and manage stolen data. The service, which law enforcement dismantled last May, notoriously ignored abuse complaints and maintained zero user logs.

Yegeniy Silayev was also sanctioned for developing cryptors designed to conceal malware. Investigators estimate these specific tools and services directly facilitated billions of dollars in financial losses across critical sectors.

U.S. Federal prosecutors also unsealed indictments this week against three Russian nationals for operating bulletproof hosting services that facilitated over $62 million in global ransomware damages.

Defendants Aleksandr Volosovik, Yulia Pankova, and Kirill Zatolokin allegedly managed “Media Land” and “ML Cloud”, providing essential infrastructure to syndicates like Lockbit, Play, and Blacksuit. These hosting platforms actively shielded cybercriminals by disregarding victim complaints and ignoring law enforcement takedown requests.

To disrupt this supply chain, the State Department is offering a $10 million reward for actionable information regarding foreign government links to these hosting providers.

The Bad | Attackers Trojanize Popular Remote User Platforms to Deploy Starland Malware

Cybersecurity researchers identified a financially-motivated Russian threat actor tracked as UAT-11795. Active since June 2025, the actor has utilized trojanized applications to harvest user credentials and cryptocurrency while primarily targeting users across the United States, Germany, Romania, and Venezuela.

To distribute their payloads, UAT-11795 operators disguise malicious installers as legitimate software, including WebEx, Zoom, MobaXterm, DBeaver, and FaceIT. Researchers suspect the attackers likely deploy these files via ClickFix social engineering.

The infection chain typically starts when a victim executes a malicious HTA file. This file retrieves an altered NSIS installer harboring a hidden Python loader disguised as a standard text document. The loader then modifies the Windows Registry to ensure persistent access before decrypting and deploying the Starland remote access trojan (RAT).

Upon execution, Starland verifies whether it is operating within a sandbox before creating scheduled tasks and attempting to escalate its system privileges. The malware scans compromised systems for browser data, cryptocurrency wallet assets, detailed system configurations, any antivirus products, and Active Directory infrastructure such as domain structure and controllers.

Beyond data theft, Starland possesses extensive capabilities to capture desktop screenshots, execute arbitrary shell commands, and fetch secondary payloads. Depending on system architecture, the malware can inject a 64-bit shellcode chain to deliver the CastleStealer information stealer or a 32-bit chain to deploy the Remcos remote access trojan.

UAT-11795-controlled Telegram channels (Source: Cisco Talos)

To maintain resilient command and control (C2) communications, the operators integrate a redundancy mechanism that queries a Polygon smart contract for a fallback domain, and control two Telegram bots to receive notification beacons, including messages with the victim’s machine fingerprints and cryptowallet inventories.

Users are reminded to avoid executing unidentified commands online and should only download confirmed software from official vendor sources.

The Ugly | Nearly 300 Imposter GitHub Repositories Distribute Infostealing Malware to Collect Sensitive Data

Threat actors have published almost 300 fabricated GitHub repositories to distribute an information stealer from the BoryptGrab malware family. The actors systematically impersonated premium security products, cryptocurrency tools, and developer utilities to deceive victims searching for free software downloads.

As part of the lure, the malicious landing pages employ highly sophisticated client-side scripts that parse referral URLs to render customized branding and spoofed trust badges, significantly increasing the likelihood of successful social engineering.

Once a targeted victim clicks the download link, the infrastructure delivers a constantly rotating ZIP archive containing a legitimate, signed WinGUP updater paired with a trojanized dynamic link library file. When the user executes the updater, the program side-loads the malicious file, which then decodes and reflectively executes the BoryptGrab-variant payload directly into system memory.

Operating without establishing long-term persistence, the malware is designed to exfiltrate maximum data in a single execution cycle. The stealer targets passwords, payment details, and session cookies across 19 different web browsers and 32 cryptocurrency wallet brands, alongside messaging tokens from Discord, Steam, and Telegram.

The infostealer’s execution workflow (Source: Arctic Wolf)

To maximize collection, operators utilize direct code injection to bypass Chrome’s native App-Bound Encryption. All newly harvested data is compressed and routed to a Russian-based C2 server. Although the malware leaves behind forensic evidence by failing to wipe temporary staging directories, the scale of the impersonation campaign poses significant risks to unsuspecting developers.

GitHub has already removed a large portion of the false repositories, though several of the malicious redirector pages remain actively online. Researchers advise users to independently verify software authenticity and exercise extreme caution when navigating unofficial portals, sharing this YARA rule to help detect BoryptGrab activity and IoCs.



from SentinelOne https://ift.tt/cB0doYM
via IFTTT

Fake Coding Tests Deliver OtterCookie-Aligned Malware Hidden in SVG Flag Images

North Korean threat actors linked to the Contagious Interview campaign have been observed employing steganography in SVG image files to conceal malicious payloads as part of a campaign using fake job postings and coding challenges.

"Any user who ran the project ended up with a four-stage payload aligned with OTTERCOOKIE: a browser credential and crypto wallet stealer, a file stealer, a Socket.IO-based remote access trojan (RAT), and a clipboard stealer," Elastic Security Labs said in a report shared with The Hacker News.

The findings once again highlight the continued targeting of software developers by state-sponsored hackers aligned with the Democratic People's Republic of Korea (DPRK) with an aim to steal sensitive data and plunder cryptocurrency wallets. The activity is being tracked under the moniker REF9403.

The cybersecurity arm of the Dutch enterprise search and observability platform said it discovered the campaign after the threat actors targeted members of its community Slack workspace with social engineering lures for purported job offers, highlighting a new initial access avenue not previously documented in attacks associated with Contagious Interview, a sophisticated social engineering operation ongoing since at least December 2022.

The messages, posted by a user named Maxwell on the #jobs Slack channel in late May 2026, sought an experienced developer to help with upgrading their e-commerce platform to a "modern, scalable architecture using Next.js (v14), NestJS, PostgreSQL, and Auth.js" along with Stripe integration.

Those who expressed interest in the opportunity were moved into direct messages that instructed them to complete a coding assessment as part of the job offer, a standard ploy observed in Contagious Interview campaigns. The assignment involved executing a trojanized repository containing malware designed to exfiltrate valuable data and configuring a Socket.IO backdoor.

Specifically, the repositories distributed as part of the scheme incorporate fully functional code but also embed malicious code in the form of SVG images to sidestep detection.

"While these legitimate-looking projects run perfectly fine, the malicious code is triggered silently behind-the-scenes," Elastic said. "The payloads are split into base64 fragments inside HTML comments across every SVG flag image inside an assets directory. These files appear to be normal images of country flags (AE.svg, AF.svg), but each file contains an injected comment block with Base64-encoded data."

The payload is then assembled together by a JavaScript file ("serverValidation.js") present in the repository. The attack chain is engineered such that the malware is executed on each server boot. Elastic said the main payload shares overlap with OtterCookie, a cross-platform malware that first emerged in September 2024.

OtterCookie "evolved from a basic tool for executing remote commands and searching for crypto keys into a modular program capable of broader data theft with a capability to check for VM environments, install communication clients like socket.io for C2, exfiltrate information, executes arbitrary shell commands, load other modules to collect specific intended data and reports results," Microsoft noted back in March.

The malware incorporates four distinct modules that allow it to harvest data from web browsers and cryptocurrency wallets, collect files matching a specific list of extensions, facilitate persistent remote control using a Socket.IO-based trojan that can execute shell commands, capture clipboard content, and drop Windows executables.

Among the files gathered by OtterCookie include artificial intelligence (AI) coding tooling extensions such as .claude, .cursor, .gemini, .windsurf, .pearai, and .llama, suggesting the threat actor is actively refining its arsenal to hoover as much information as possible.

It's worth noting that the malware also exhibits some functional overlaps with a data stealer and trojan distributed via bogus npm packages masquerading as Rollup polyfill tooling, suggesting the threat actors are pursuing multiple vectors for propagation.

"This campaign reinforces that developers remain a prime target, where the compromise of a single individual can provide the initial access needed to enable far-reaching supply chain attacks against downstream organizations," Elastic said. "The success of these operations underscores how compromising an individual developer can provide a path to much broader organizational impact."



from The Hacker News https://ift.tt/NOHbfE3
via IFTTT

Armenia Detains Russian Tourist on U.S. Warrant for REvil Hacker, Lawyers Say Wrong Man

Armenia has held a Russian tourist named Aleksandr Ermakov in a detention center since June 28, on a U.S. extradition request for a REvil ransomware suspect named Aleksandr Ermakov.

His wife, Maria Yurova, told REN TV that border officers pulled him out of the departure hall at Yerevan's Zvartnots airport, held up a phone with a photo of him off his VKontakte page, and walked him into a side room. His lawyers say Washington has the wrong man.

The Ermakov the U.S. wants is Aleksandr Gennadievich Ermakov, sanctioned by Australia, the US, and the UK in January 2024 for stealing 9.7 million records from Medibank Private, one of Australia's largest private health insurers, and dumping some on the dark web.

He is also serving a two-year Russian sentence that bars him from leaving the country, according to TASS and to case files two Russian outlets say they have read. The man in the Armenian cell, his lawyers say, is Aleksandr Yuryevich Ermakov, from Omsk, a former prison-service lawyer who does not speak English.

Ermakov is accused of taking part in Sodinokibi/REvil attacks from roughly April 2019 to July 12, 2021, with more than 1,000 victims among private companies, law enforcement, government offices, schools, and hospitals, some in the Northern District of Texas.

That comes from the US charging document, which RIA Novosti says it holds. The Interpol notice built on it, which Izvestia says it has, goes further: one of the platform's administrators, with a take of over $13.7 million. Channel Five dates the warrant to that district's federal court, June 26, two days before the arrest.

Medibank was hacked in October 2022, fifteen months after that window closes, and the US has never announced a charge against Ermakov over it. Treasury's designation put him at REvil's edge, an actor "believed to be linked" to the gang. The notice puts him at its center. That court has seen REvil before: DOJ charged Yevgeniy Polyanin there in 2021 over Sodinokibi/REvil attacks on Texas businesses and government entities on or about August 16, 2019.

Russian passports carry a patronymic, and it is the field that tells one Aleksandr Ermakov from the next. Australia's consolidated list has it: Aleksandr Gennadievich Ermakov, born 16 May 1990. The UK's entry has it. OFAC's does not.

The SDN record runs: ERMAKOV, Aleksandr, Moscow, DOB 16 May 1990, male, one Yandex address, four handles (blade_runner, GistaveDore, GustaveDore, JimJones). Given name, surname, nothing in between. What the Interpol notice itself carries is not public.

Dylan Rajavi, one of the detained man's lawyers, told Izvestia the defense's working theory is that the U.S. paperwork carried a given name and a surname, no more, and an automated check did the rest. He also said there are standard ways to settle who someone is, fingerprints or full passport data, and that neither has been produced.

"There is only an arrest warrant," he said. That is the defense's account, not a finding.

Armenian authorities have said nothing, the Justice Department has announced no charges, and none of the Russian outlets holding the documents says how it got them. Nor are there as many outlets as they look: Izvestia, REN TV, and Channel Five all sit under National Media Group, and Izvestia's newsroom has supplied the news for the other two since 2017. The man is being held on a 30-day Interpol detention order while Moscow asks Yerevan for consular access.

Where the Name Came From

Australia's signals directorate and federal police spent 18 months on Operation Aquila before naming him. And the chain from the sanctioned Ermakov to SugarLocker does not run through Russian state media.

Once Australia published the nicknames, Intel 471 went back through years of collected forum data. SHTAZI and shtaziIT were among Ermakov's handles, it reported, and his alias JimJones had spent 2019 and 2020 on the Exploit forum hawking malware development and a dev shop called Shtazi-IT.

A month later, Russian police said they had rolled up the SugarLocker ransomware crew operating behind Shtazi-IT, with @GustaveDore sitting in the contact field of its developer job ads. A US vendor and Russia's interior ministry reached the same shopfront from opposite ends.

In October 2024, a Moscow court gave Ermakov two years of restriction of freedom under Article 273(2), Russia's malware statute, for co-writing SugarLocker and selling it to a buyer with a Tor control panel attached.

Case material seen by Izvestia says he pleaded guilty, and the case ran through Russia's summary procedure. "Ermakov was sentenced to 2 years of restriction of freedom," a law enforcement source told state agency TASS on Thursday. The term has not run out.

Armenia's court still has to decide whether to put the other Ermakov on a plane to Dallas, and his brother told RIA on Friday the family expects it to go through. Two and a half years of sanctions, an 18-month intelligence operation, and a new U.S. warrant have, between them, put exactly one Aleksandr Ermakov in a cell, and his lawyers say it is the wrong one.

The Ermakov warrant name is at home, reporting once a month to the prison service that the man in the cell spent his career working for.



from The Hacker News https://ift.tt/Yi12odG
via IFTTT

New GoSerpent Malware Targets Southeast Asian Governments and Diplomats for Espionage

Cybersecurity researchers have discovered a previously undocumented malware called GoSerpent that has been put to use in cyber attacks targeting entities in Southeast Asia since late 2025 with a focus on long-term access and intelligence gathering.

Russian cybersecurity company Kaspersky, which uncovered the activity in February 2026, said it was aimed at government and diplomatic entities in the region. GoSerpent is designed to contact an external server and deploy secondary payloads on sensitive data collection and credential dumping on the system.

"Monitoring the activities of this threat actor revealed that in May 2026 they came back with an evolved set of malicious tools: new Stowaway RAT and proxy tool which resembled the initial malware as well as an additional stealthy tool to exfiltrate sensitive data collected for the previous few months through network share," security researcher Noushin Shabab said.

The end goal of these efforts is to harvest sensitive files and stage them for subsequent exfiltration using a data collecting tool dubbed ThumbcacheService. The attacks have also employed credential dumping tools via GoSerpent to capture system credentials need to facilitate data exfiltration through network shared drives.

Earlier iterations of the Go-based implant and remote access trojan (RAT) have been put to use since 2021 against victims in Southeast Asia, with recent variants deployed as recently as this year.

The malware functions by receiving encrypted and Base64-encoded command-line arguments containing the command-and-control (C2) address and communication password. Once decrypted, the backdoor connects to the C2 server over an encrypted connection, where the SHA256 hash of the communication password serves as the encryption key.

The list of supported commands is listed below -

  • To alert the server of an active infection
  • Start listening on a specific port
  • Close a listening port
  • Connect to a remote server
  • Spawn a shell on the infected machine
  • Upload a file or directory to the server
  • Download from the server
  • Start a SOCKS5 proxy on the infected machine
  • Forward to a connected node

"GoSerpent can establish SOCKS5 proxy servers to route traffic through compromised hosts, enabling attackers to access other networks while masking their true IP addresses," Kaspersky explained. "The backdoor is capable of deploying additional malicious tools, including ThumbcacheService for file collection, Mimikatz for credential dumping, and QuarksDumpLocalHash for local account password hash extraction."

Some of the other tools deployed over the course of the attacks are as follows -

  • McMx RAT, a basic Go-based proxy and remote access tool that's a lightweight version of GoSerpent with capabilities such as SOCKS5 proxying, port forwarding, file transfer, and remote shell
  • ThumbcacheService, a DLL that supplements GoSerpent with a sophisticated file collection mechanism
  • Mimikatz, to dump memory from the Local Security Authority Subsystem Service (LSASS) process to extract credential material
  • QuarksDumpLocalHash, to extract local account password hashes from the SAM registry hive

After months of covert data harvesting, the threat actors behind the activity are said to have returned to the compromised environment in May 2026 to deploy another set of tools -

  • Stowaway, a proxy and remote access tool with SOCKS5 proxying, port forwarding, reverse tunneling, remote shell access, file transfer, and SSH-based tunneling features
  • TmcLoader, a C++ loader module that contains an encrypted payload dubbed TmcPayload
  • TmcPayload, to exfiltrate stored sensitive data from the victim's machine

"What makes this threat particularly concerning is the strategic deployment of various tools with sophisticated data collection and exfiltration capabilities," Kaspersky said. "The chain from ThumbcacheService to TmcLoader/TmcPayload demonstrates sophisticated operational planning."

Although definitive attribution remains cloudy at best, the security vendor said the campaign shares targeting, technical capabilities, and operational overlaps with TetrisPhantom, a "highly skilled and resourceful threat actor" it first documented in October 2023 as targeting government entities in the Asia-Pacific (APAC) region.

"The attacker covertly spied on and harvested sensitive data from APAC government entities by exploiting a particular type of secure USB drive, protected by hardware encryption to ensure the secure storage and transfer of data between computer systems," the company noted at the time.

"The campaign comprises various malicious modules, through which the actor can gain extensive control over the victim's device. This allows them to execute commands, collect files and information from compromised machines, and transfer them to other machines using the same or different secure USB drives as carriers."

DoNot Team Attack Chain

The disclosure comes as Cyderes Howler Cell detailed a targeted cyber espionage operation orchestrated by DoNot Team targeting Bangladesh's military and defence establishments using spear-phishing emails containing a malware-laced RTF document to drop a DLL implant that sets up scheduled-task persistence disguised as OneDrive telemetry, profiles the host, and beacons to a C2 server over HTTPS.

"The RTF uses remote template injection to fetch a VBA macro, with server-side geofencing restricting payload delivery to victims inside the target region," researchers Reegun Jayapaul, Rahul Ramesh, and Baskar M said. "Once the macro runs, it injects architecture-aware shellcode through callback-based API abuse. The shellcode moves through several XOR-encoded stages, each pulled from the same C2 domain under benign-looking file extensions."

The implant is then used to deliver a second-stage DLL ("ejtest.dll"), which features modular download capability for follow-on payloads. The attribution to DoNot Team is based on similar C2 URI paths, matching AES key material, VBA-based shellcode injection tradecraft, and geofenced payload delivery that serves clean templates to non-targets.



from The Hacker News https://ift.tt/btl2rex
via IFTTT

Thursday, July 16, 2026

Begun, the Patch Wars have

Begun, the Patch Wars have

Welcome to this week’s edition of the Threat Source newsletter. 

We all knew, to some degree or another, that this summer was going to a hot mess. I don’t mean FIFA drama or record setting heat waves. I mean the slow but steady momentum that AI frontier models were accruing for vulnerability research. If you were like me, and guesstimating exactly when that shoe would drop, my money was on the middle of summer. And... well, friends, I hate to say it, but I was right.  

This July’s Patch Tuesday is an absolute whopper. There are 622 vulnerabilities being patched, with 62 being a critical severity. To put this context, this month alone has more vulnerabilities listed than all of 2018 combined. Three are zero days, two of which are being actively exploited. July is usually a quiet month historically – two years ago, it was just five patches issued in total! These are wild times, friends.  

Microsoft has said this is due their AI frontier-accelerated research. We knew that this was coming, but what I am less sure about are companies that can meet the demand of this patch flood and getting these patches out to their infrastructures. The pessimist in me knows how most IT enterprises operate: You test, review stability, and then deploy. There’s a lag there – always has been, always will be. But that system worked under a sane patching load. As surely as much as Microsoft is using frontier models to research and announce vulnerabilities, so every is every other vendor.  

Either through bug bounty programs or their own internal research, vendors are eating these bugs from a fire hose. Some are straight-up slop and just noise, but some have absolute value and need to be fixed. A giant like Microsoft has the money and resources to address this – as well they should. But for every Microsoft, there are five other companies who don’t have those resources. They’ll get bugs analyzed and patches issued, surely, but it will be on a much longer timeline.  

The trick, I think, will be identifying what is a “surge” vs. our new normal. If everything is a fire drill to patch, then nothing is a fire drill. What might just be a hot summer for patching, might turn into a 12-month fusillade of KEV and EPSS notifications, with companies already under the gun taxed even more. 

I truly don’t know how this ends, but… Find your change management and IT administrators and give then a hug. There are going to be some long days and hard questions to answer, and they’ll need all the help they can get. 

The one big thing 

Cisco Talos is disclosing a new campaign by UAT-11795, a sophisticated, financially motivated Russian-speaking adversary targeting users in the U.S. and Europe since at least June 2025. UAT-11795 uses trojanized software installers — including popular tools like Webex, Zoom, and MobaXterm — to deliver a custom Python-based remote access tool we track as "Starland RAT." This RAT acts as a gateway to deploy further malicious payloads, most notably a bespoke, in-memory PowerShell command-and-control (C2) implant known as the "WLDR agent." 

Why do I care? 

This opportunistic campaign casts a wide net across multiple victim profiles, turning a simple software download into a full-blown compromise. UAT-11795 employs highly evasive techniques, including AMSI and ETW bypasses, and uses a clever blockchain-anchored fallback mechanism to maintain persistent command and control. Once inside, attackers rapidly deploy secondary payloads like CastleStealer and Remcos RAT to siphon high-value credentials and cryptocurrency assets. 

So now what? 

Educate your users on ClickFix social engineering tactics and the dangers of unofficial software downloads. Monitor for suspicious execution of mshta.exe and unusual PowerShell activity, particularly scripts executing from memory or creating unexpected scheduled tasks. Ensure endpoint detection solutions are tuned to catch in-memory execution and AMSI tampering. Read the full blog for coverage and indicators of compromise (IOCs). 

Top security headlines of the week 

Microsoft patches record 622 flaws, including two zero-days under active attack 
Microsoft shipped its largest Patch Tuesday on record, more than triple June's previous high of around 200. (The Hacker News

RabbitMQ vulnerability threatens enterprise systems 
RabbitMQ is a popular open-source message broker that routes, buffers, and distributes messages, enabling asynchronous communication between applications. The security defect impacts an open management endpoint that returns the OAuth secret to anyone, without authentication. (SecurityWeek

Nigeria deepens cybersecurity efforts as cybercriminals see more profits 
The West African country advanced rules to force organizations to disclose cyberattacks, joining other nations in a shift to mandated transparency. (DarkReading

Two-click cursor exploit enables dev environment takeover 
Cursor AI, a popular AI coding tool used by more than 50,000 enterprises and 64% of the Fortune 500, can be exploited in just two clicks, allowing attackers to install permission-rich model context protocol (MCP) servers on privileged developers' machines. (DarkReading

Can’t get enough Talos? 

[Video] Where protection starts: Cisco Talos Intelligence Integrations 
Every day, defenders make high-consequence decisions with incomplete information. Learn how Cisco Talos Intelligence Integrations help reduce uncertainty by turning the latest threat intelligence into proactive protections across Cisco technologies. 

The Hunter's Paradox: Is it time to embrace automated threat hunting?
Humans can no longer keep up with the volume and velocity of security data on their own, but AI can't be fully trusted. David discusses the merits of both and what the future might look like.

The serpent’s tongue: Luring the Python out of its den 
Protect your development environment from rising Python supply-chain threats by understanding the package installation lifecycle and implementing these essential defensive strategies. 

ARToken: How attackers are bypassing MFA and maintaining access 
In this episode of Talos Takes, we dive deep into ARToken, a sophisticated phishing-as-a-service platform that steals credentials, bypasses MFA entirely, and leverages primary refresh tokens (PRTs) to maintain persistence in your environment long after a password reset. 

Upcoming events where you can find Talos 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
MD5: 2915b3f8b703eb744fc54c81f4a9c67f 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201** 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
MD5: 38de5b216c33833af710e88f7f64fc98 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: SECOH-QAD.exe 
Detection Name: Win.Tool.Procpatcher::1201 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
Example Filename: tmp00055df5.dll  
Detection Name: Auto.90B145.282358.in02 

SHA256: b8be9a5e0a191050f9099c11c155b436863e9bc43bc904cdb842e249679aa35a 
MD5: 0398df5a18f71efcfeef4571a2cef577 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=b8be9a5e0a191050f9099c11c155b436863e9bc43bc904cdb842e249679aa35a 
Example Filename: b8be9a5e0a191050f9099c11c155b436863e9bc43bc904cdb842e249679aa35a.js 
Detection Name: W32.B8BE9A5E0A-95.SBX.TG 



from Cisco Talos Blog https://ift.tt/ybB5lM6
via IFTTT

n8n Token Exchange Flaw Could Let Attackers Log In as Users From Another Issuer

n8n, the workflow automation platform, handed out the wrong accounts at login. On Enterprise instances configured to trust more than one external token issuer, it matched an incoming JWT to a local user on the sub claim alone and ignored iss.

A valid token from issuer A carrying a sub that belongs to someone under issuer B logged you in as them. Their password never came into it. n8n shipped the fix on June 24.

The flaw is tracked as CVE-2026-59208. The CVE record did not go public until July 9. n8n credits the report to the GitHub account bearsyankees, whose profile lists Strix, which makes an AI penetration testing agent.

Strix says it pointed out that the agent at the token-exchange flow and found the identity-binding bug there.

Two issuers, one account

Token exchange is n8n's Enterprise route for OEM partners who embed the product, an RFC 8693 implementation that spares their users a second login screen.

The partner signs a short-lived JWT with its own key, n8n verifies it against a configured public key, matches the claims to a local account, and the user is in. Trusted keys go in N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, and the deployment docs still tag the feature as preview.

The token itself checks out. The matching is the bug. A sub value is only guaranteed to be unique inside the issuer that minted it. RFC 7519 asks that it be "scoped to be locally unique in the context of the issuer" or else globally unique. The identifier for a user is therefore the pair, iss plus sub.

n8n keyed on half of it. Nothing stops two issuers from emitting the same subject string, and when they do, both land on one n8n account.

How big a deal is this

The flaw reaches an instance only if token exchange is switched on and the config trusts at least two external issuers. n8n says nothing else is affected. Token exchange is Enterprise-only and still flagged as a preview, so the exposed set is small and specific: OEM deployments, where trusting a second issuer is a supported configuration.

What the advisory does not pin down is how an attacker gets the token. It says only that they can obtain one. The practical question is whether an ordinary user at a trusted issuer can influence the sub they receive. The public record does not answer it. GitHub's CVSS 4.0 vector marks attack requirements as present and stops there.

GitHub assigned that vector. As the CNA here, it puts CVE-2026-59208 at 7.6 on CVSS 4.0, high. NVD puts the same bug at 6.8 on CVSS 3.1, medium, and has not issued a 4.0 assessment at all; its record carries CWE-287 and CWE-346. CISA's July 13 SSVC assessment records exploitation as none, and The Hacker News found no public proof-of-concept in searches on July 16.

Two weeks before the June 24 fix, the maintainers patched CVE-2026-54305, another Enterprise-only flaw. It lets any authenticated user overwrite or revoke another user's stored OAuth tokens through the Dynamic Credentials endpoints. That one was a missing ownership check, not an identity binding. Different bug, same surface.

The Hacker News has reached out to n8n for confirmation on the scope and impact of CVE-2026-59208 and will update this story with any response.

Patch or cut the issuer list

CVE-2026-59208 affects every n8n release below 2.27.4 and version 2.28.0. The fix first landed in 2.27.4 and 2.28.1. Those are the floor. On July 16, n8n's npm package carried 2.30.6 on both its latest and stable tags. It ships a new minor most weeks by its own account, so check the tag and take the newest stable build your deployment supports.

If patching has to wait, work out what you are running: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS holds the trusted signing keys, and a separate preview flag controls whether token exchange is on at all. Cut back to a single trusted issuer, or turn the feature off.

The advisory calls both short-term measures and says neither fully remediates the risk. That is boilerplate, identical in at least three other n8n advisories, including the June 10 one. By n8n's own scope statement, an instance with token exchange off is not affected.

Neither release note mentions the fix. The Hacker News checked both: between them, the 2.27.4 and 2.28.1 changelogs cover a Python import fix, a Google Ads node upgrade, an AI workflow check, and a node-building change, and nothing about identity.

The advisory is where this one lives. If your upgrade decisions run on changelogs, this is the kind of fix that slips past.



from The Hacker News https://ift.tt/vAIsmow
via IFTTT

Demystifying AI Exploits: A Blueprint for AI-Assisted Vulnerability Management

Written by: Jules Czarniak


Introduction 

As highlighted in the Mandiant M-Trends 2026 report, the mean time-to-exploit (TTE) has dropped to -7 days, meaning vulnerabilities are often exploited a week before a patch even exists. 

To keep pace, many security teams are exploring how to integrate large language model (LLM) agents into their codebases, development environments and continuous integration and continuous delivery (CI/CD) pipelines for automated vulnerability discovery and remediation. However, deploying privileged artificial intelligence (AI) agents without mature integration processes introduces new architectural risks. 

In response to customer inquiries about how to safely integrate AI capabilities into vulnerability management workflows, this blog provides actionable guidance from Mandiant Consulting about how to establish operational guardrails for AI assisted vulnerability management, including several detailed scenarios. What each of these examples show is that security teams can accelerate workflows with AI while also upholding the structural integrity of their environments. We suggest that combining AI capabilities with deterministic controls and human intelligence in strategic ways maximizes benefits and reduces risk. 

Establish Operational Guardrails to Safely Deploy AI Agents

To safely adopt advanced AI capabilities without introducing unpredictable failures into deployment pipelines, organizations should ground their approach in established industry standards. While guidelines like the NIST AI Risk Management Framework (RMF) and the OWASP Top 10 for LLMs provide comprehensive baselines for identifying risks, operationalizing these controls requires a structural blueprint.

Frameworks like Google’s Secure AI Framework (SAIF) and Google’s approach to secure AI Agents provide a practical path forward, demanding that organizations extend existing deterministic controls directly into the AI execution environment. When deploying AI agents, security teams should navigate specific operational and structural risks:

  • Pre-agent data security and Defense-in-Depth: Agents should not be able to access personally identifiable information (PII), protected health information (PHI), or other sensitive data. Organizations should enforce data security before the prompt reaches the model. This includes strictly using non-production environments populated with synthetic data for testing. For production, security teams should deploy a hybrid defense-in-depth model. This includes Layer 1 deterministic policy engines acting as chokepoints, alongside Layer 2 reasoning-based defenses like specialized guard models (such as Model Armor or similar provider-agnostic guardrails) to filter out sensitive data and block malicious prompt injections before they reach the agent layer. Crucially for vulnerability discovery, security teams should treat the codebase itself as an untrusted input. Threat actors can embed indirect prompt injections within source code comments or third-party dependencies (e.g., hidden instructions telling the agent to ignore vulnerabilities or exfiltrate environment variables), making input sanitation a requirement even for internal scanning.

  • Cloud provider limitations and zero data retention (ZDR): Many cloud and LLM providers block or throttle automated offensive security probing by default to prevent abuse. Organizations should establish clear rules of engagement and authorized testing agreements to navigate acceptable use policies. Furthermore, organizations should enforce strict zero data retention (ZDR) agreements with their LLM providers to guarantee that proprietary code and discovered vulnerabilities are never used to train external models.

  • Workload isolation: Agent workloads should execute in strictly isolated, unprivileged containers with dynamically limited privileges. By relying on robust sandboxing to prevent privilege escalation, if an agent hallucinates a destructive command or is hijacked via prompt injection, the blast radius remains contained.

  • Red Teaming: Before deploying autonomous vulnerability scanners that can dynamically spin up sandboxes and execute code, organizations should subject the AI agents themselves to human-led red teaming as part of comprehensive assurance efforts. This validates the agent's resilience against jailbreaks, recursive logic loops, and complex prompt injections, ensuring the security tooling does not become the attack vector.

  • Least-Privileged Machine Identities and Human Controllers: While workloads should be isolated, agents inherently require privileges to generate pull requests and commit code. Security teams should ensure these agents operate under distinct, strictly scoped machine identities that tie back to human controllers to ensure accountability and user consent. Organizations should use short-lived, just-in-time (JIT) tokens bound exclusively to the specific repository and branch under review. This enforces the principle of limited agent powers and ensures that even if an agent’s container is compromised via prompt injection, the threat actor cannot pivot to modify adjacent enterprise codebases.

  • Supply chain resilience for skills: As developers augment AI with third-party skills and model context protocol (MCP) servers, security teams should treat these integrations as untrusted supply chain components. MCP plugins introduce the risk of supply chain poisoning, where a previously benign integration is silently updated with malicious dependencies. Additionally, security teams should evaluate the underlying agent orchestration frameworks themselves (e.g., LangChain, AutoGen) for inherent vulnerabilities, such as session memory poisoning or recursive loop hijacking.

  • Toxic flow analysis (TFA) and Observable Actions: The objective of TFA is to monitor data paths at runtime, ensuring agents do not exfiltrate sensitive internal context to unvetted external endpoints. Agent actions, inputs, reasoning, and outputs must be fully observable and transparently logged. While implementing dynamic taint tracking for LLMs remains a complex architectural challenge, organizations should clearly separate this runtime observability from static supply chain controls. Integrating threat intelligence to hash and vet incoming agent tools provides a necessary baseline for verifying integrity before deployment. However, because static controls cannot address behavior post-deployment, mitigating data exfiltration ultimately requires active runtime monitoring and secure, centralized logging to trace and restrict the actual flow of data.

Demystifying AI image1

Figure 1: Visual representation of an isolated AI agent environment using SAIF mechanisms

By operationalizing these tools within frameworks that demand verifiable integrity and structural resilience, organizations can safely bridge the gap between AI velocity and enterprise defense.

The need for human-led threat modeling

While LLMs excel at identifying syntax patterns, source code itself rarely contains the full picture of unwritten business intent. Some organizations attempt to solve this by connecting LLM agents to internal wikis, design documents, and issue trackers using retrieval-augmented generation (RAG).

While RAG gives the model access to external business context, it is not a perfect fix. Corporate documentation is frequently stale, contradictory, or incomplete. An AI agent might retrieve an outdated architecture diagram and confidently hallucinate a secure path that no longer exists in production. Because LLM agents struggle to resolve conflicting, undocumented human assumptions, human-led threat modeling remains a critical security control across both legacy applications and modern agent workflows.

Security teams should apply threat modeling during both the pre-build system design phase to establish a secure foundation, and during post-build architecture reviews. While an AI agent might successfully identify a poorly configured internal endpoint locally, a human threat modeler asks the structural question: why does that microservice possess broad database read permissions in the first place? 

Identifying architectural vulnerabilities requires reasoning about business risk, data sensitivity, and operational constraints. To structure this process, organizations can use industry frameworks like PASTA (Process for Attack Simulation and Threat Analysis) or service offerings like the Mandiant Threat Modeling Security Service to map trust boundaries, uncover structural design flaws, and prioritize compensating controls. Securing fundamental architecture through human oversight is a necessary component when relying on automated agents to find bugs in a poorly designed system.

Once these AI agents are safely sandboxed, as guided by SAIF, and the architecture is verified through threat modeling, organizations can typically apply them to two different problem spaces: Enterprise Vulnerability Management (to assist in managing the volume of known CVEs in commercial off-the-shelf (COTS) software and infrastructure) and Product Security (to identify vulnerabilities in 1st-party (1P) code).

Track 1: Enterprise Vulnerability Management

Foundational security and discovery 

While the second track of this post explores how AI agents can uncover complex zero-days in custom code, organizations should manage the scale of enterprise infrastructure in tandem with these AI deployments. Even as new AI capabilities dominate headlines, organizations should still address foundational security challenges, such as secrets sprawl, unmanaged service accounts, missing FIDO2 MFA, and legacy VPN concentrators. Although vulnerability exploitation was the primary initial infection vector in intrusions Mandiant investigated last year, threat actors consistently rely on missing foundational controls and unpatched edge devices to secure and escalate their foothold after exploiting a vulnerability.

Furthermore, AI cannot replace foundational visibility. As security teams deploy AI agents, they should simultaneously close these tactical entry points by maximizing dynamic discovery capabilities like External Attack Surface Management (EASM), Cloud Security Posture Management (CSPM), and Continuous Threat Exposure Management (CTEM). In hybrid and cloud environments, tools like Wiz can be used to map this initial footprint.

Risk-based vulnerability management 

Vulnerability management teams are already overwhelmed by the current volume of findings generated by traditional scanners. As organizations scale dynamic discovery tools, such as EASM, CSPM and CTEM, alongside automated AI agents, this influx of findings will compound the problem. To manage this influx, telemetry from these diverse discovery methods must first be normalized and deduplicated. This normalized data serves two purposes: it feeds directly into the risk engine, and it acts as a live overlay to correct stale records in the configuration management database (CMDB). By evaluating the deduplicated vulnerabilities alongside this newly updated asset context and frontline threat intelligence, the RBVM engine calculates a custom risk score that allows security teams to dynamically prioritize remediation.

A mature RBVM methodology calculates a customized risk score on a 0 to 100 scale using a weighted average. A sample formula for calculating this risk-based score is:

Final Score = (W_1 * S_vuln) + (W_2 * S_asset) + (W_3 * S_threat)

The variables and weights (W) are customized to the organization's risk appetite (for example, 0.20 for vulnerability, 0.40 for asset, and 0.40 for threat, summing to 1.0), while the underlying variables (S) are scored on a 0 to 100 scale and defined as follows:

  • Vulnerability severity (S_vuln): The inherent technical severity of the flaw. This is calculated by taking the CVSS Base Score (which natively accounts for confidentiality, integrity, and availability impact) and multiplying it by 10.

  • Asset context (S_asset): A combined metric of exposure and data sensitivity. Scores range from 100 for internet-facing assets holding customer data, down to 25 for internal-only assets with no sensitive data. To translate this impact into monetary terms for non-technical stakeholders, organizations can incorporate Factor Analysis of Information Risk (FAIR) principles into this metric. However, this approach requires highly accurate, continuously updated financial data that many enterprises struggle to maintain at scale.

  • Threat context (S_threat): The real-world urgency of the vulnerability. Scores range from 100 if actively exploited by threat actors relevant to the organization's profile, 75 if a proof-of-concept exists or if it is a vulnerability class easily exploited by autonomous AI agents, down to 25 if the exploit is theoretical and highly complex. Organizations should also map the Exploit Prediction Scoring System (EPSS) probability percentage directly into this variable. This allows the threat score to automatically scale up or down as real-world exploitation telemetry shifts, aligning static vulnerability data with active threat intelligence.

An asset's customized risk score should directly influence internal remediation service-level agreements (SLAs), unless external compliance-driven mandates, such as CISA Binding Operational Directives (BODs), or relevant equivalents, override internal prioritization. A risk-driven and threat-intelligence-driven vulnerability prioritization methodology will help organizations focus resources on managing and mitigating the most critical security vulnerabilities first. This is an area where LLMs can support the vulnerability management process, particularly by helping teams synthesize unstructured threat intelligence to surface relevant risk contexts more efficiently. Enforcing strict SLOs for patching, while requiring formal risk acceptance documentation for any patching exceptions, will help reduce the number of vulnerabilities available to threat actors and increase the visibility of outstanding risks across the organization. Furthermore, organizations should integrate RBVM data directly into their security orchestration, automation, and response (SOAR) platforms for automated alert enrichment.

Demystifying AI image5

Figure 2: Integration points of a risk-based vulnerability management (RBVM) program.

Containment and Observability

Modern architecture blueprints must prioritize attack surface reduction under the assumption that vulnerabilities will inevitably be exploited. Moving away from traditional perimeter defenses, organizations should align with zero trust principles, ensuring that security boundaries are established around every asset, workload, and identity.

A component of this alignment is the implementation of strong authentication principles. Organizations should eliminate implicit trust by enforcing continuous, context-aware authentication and authorization. Utilizing Zero Trust Network Access (ZTNA) solutions, such as Identity-Aware Proxies (IAP), shields critical management interfaces (e.g., SSH, RDP) and internal systems from direct internet exposure, granting access only to verified identities and compliant devices.

For public-facing applications and APIs, attack surface reduction involves deploying Layer 7 inspection at the load balancer or API gateway level. This hardening layer enforces strict schema validation, intercepting and neutralizing malformed inbound traffic and potential exploits before they can interact with internal application logic.

Securing the software supply chain is equally vital in modern blueprints, and organizations should align with frameworks like Supply-chain Levels for Software Artifacts (SLSA) across both dependency and build tracks. Security policies should mandate that third-party dependencies are routed through a centralized artifact repository equipped with automated curation services, such as Google Assured Open Source Software (OSS) or an equivalent solution, preventing untrusted code from entering the development lifecycle. Furthermore, maturing toward advanced SLSA build levels (e.g., SLSA level 3) through the implementation of isolation, ephemerality and reproducibility requirements via  ephemeral compute infrastructure for CI/CD runners reduces the likelihood of attacker persistence by ensuring environments are short-lived and automatically cycled.

To complement these pre-build controls, runtime observability should be established across all production workloads. This requires monitoring both infrastructure-level behavior and the specific runtime libraries actively executing in production, which surfaces true exploitable risk far beyond a static Software Bill of Materials. In tandem with monitoring workloads, organizations should secure how they authenticate by implementing workload identity federation. By removing static credentials and instead using short-lived tokens backed by strong cryptographic identity verification, organizations can reduce the risk of credential theft and unauthorized lateral movement.

Within the internal environment, microsegmentation should be enforced to break down flat networks into granular security zones. Routing application traffic through a Secure Access Service Edge (SASE) architecture integrates network routing directly with robust identity controls, rendering internal services completely invisible to unauthenticated users and containing threats to their initial point of entry.

Finally, automated containment and incident response within a zero trust framework must rely on deterministic, auditable tooling. Endpoint detection and response (EDR) platforms and SOAR playbooks should handle high-fidelity containment tasks through hardcoded execution logic. While AI tools accelerate triage and policy recommendation, actual execution capabilities must remain restricted to well-defined, pre-tested workflows to maintain total architectural predictability.

Demystifying AI image8

Figure 3: Structural containment and observability architecture

Track 2: Product Security & Development (1P Code)

Deterministic and probabilistic tooling

Integrating LLM agents into vulnerability management and security workflows requires recognizing the differences between deterministic and probabilistic tooling. Traditional SAST and DAST tools utilize fixed methodologies to evaluate vulnerabilities through structural code parsing or definitive runtime observations. LLMs, however, evaluate source code by processing tokens simultaneously to calculate statistical and semantic relationships, rather than tracing deterministic execution tracks.

While techniques like Chain of Thought (CoT) prompting allow models to bridge this gap by decomposing complex code paths into intermediate reasoning steps, this process remains bounded by architectural limitations. Even when a model possesses a context window large enough to ingest entire repositories, it may experience attention degradation across long inputs, often failing to correctly weight intervening validation or sanitization logic within the prompt. For example, if a variable is tainted on line 10 but sanitized on line 500, attention degradation can cause the model to lose track of the sanitization logic. Furthermore, when enterprise codebases require chunking to fit within context limits, the resulting fragmentation may cause the model to lose track of end-to-end data flows.

Consequently, probabilistic engines are effective at uncovering localized, static anomalies, such as hardcoded credentials or outdated dependencies, but frequently misjudge complex vulnerabilities split across fragmented chunks or extended context windows. Notable exceptions occur when these probabilistic models are coupled with deterministic feedback loops. For instance, when analyzing C++ memory corruption, an LLM can be equipped with a test harness to iteratively execute code and definitively prove a crash. While these dynamic validation applications are detailed in subsequent sections, the baseline limitation for static analysis across standard enterprise codebases remains: models struggle to consistently evaluate dispersed logic.

Demystifying AI image4

Figure 4: Deterministic SAST scanners vs. probabilistic LLMs

Binary and architectural oracles

Many security programs are moving toward agent workflows where an agent autonomously spins up a test environment and uses tools to execute payloads and verify its findings. This is a promising approach, but it is important to understand where it is most effective.

Agent workflows perform well against bug classes with binary and observable oracles, meaning the system provides an objective, 'crash or no crash' feedback loop. For example, if a model is hunting for memory corruption in a C++ kernel, a successful exploit is undeniable: the payload executes, and a resulting crash definitively proves the vulnerability. This explains why the industry is currently seeing a surge in AI-discovered vulnerabilities across memory-unsafe targets like web browsers and operating systems.

However, enterprise software is heavily dominated by vulnerabilities that require architectural oracles for validation. Vulnerabilities like authorization bypasses, complex business logic flaws, and indirect server-side request forgeries require an understanding of business context and cross-service trust boundaries. If an agent's payload fails to produce a clear outcome, it can't reliably distinguish whether the vulnerability is a hallucination or if it simply constructed the payload incorrectly. An agent's malformed payload might even crash an unrelated background process and cause the model to hallucinate a success and report a false confirmation. Complex enterprise architecture contains unwritten business intent that a probabilistic engine can't inherently know.

Demystifying AI image3

Figure 5: Evaluating vulnerabilities against binary vs. architectural oracles

Targeted deployment and human impact

Organizations adopting LLMs for vulnerability discovery face a massive staffing challenge. LLMs can generate findings significantly faster than human engineers can triage them. If every LLM-generated alert requires manual review, security teams will quickly face burnout and/or suffer alarm fatigue.

Rather than indiscriminately pointing agents at all available codebases and risking an influx of unverified output, security teams need a selective deployment strategy. Mature programs should maintain SAST and DAST for baseline hygiene and deterministic rule enforcement, and reserve intensive agent audits for high-impact components with clear binary oracles.

Organizations can prioritize agent audits on systems where the technology's strengths align with the broader risk profile:

  • Memory-unsafe codebases: Legacy or high-performance components written in memory-unsafe languages such as C, C++, or Assembly are strong candidates for LLM audits. These languages are susceptible to memory corruption flaws, such as buffer overflows and use-after-free conditions. Because these vulnerabilities trigger definitive failure states like segmentation faults, they work well with automated sandboxes where agents can compile the code with memory sanitizers and write proof-of-concept inputs. This approach is also effective for auditing the native extensions where safe languages call unsafe internal libraries, such as Python C extensions or the Java Native Interface (JNI).

  • Systems highly exposed to outside content: First-party data ingestion pipelines, custom API gateways, or proprietary edge proxies. A prerequisite here is direct access to the source code, this strategy is strictly for internally developed or fully open-source codebases where the organization can inspect the logic. Because these systems directly parse untrusted internet traffic, targeting their source code for LLM-driven audits yields the highest risk-reduction ROI.

  • Shared internal libraries and utilities: Core serialization/deserialization packages, common utility functions, and custom middleware wrappers (such as internal message-queue parsers) maintained in-house. Because the enterprise owns the source code for these shared building blocks, agent tools can easily hook into them within automated test harnesses to fuzz inputs and catch low-level logic or parsing bugs with high fidelity.

  • Foundational security boundaries: Internally developed centralized authentication services, custom OAuth providers, and internal credential brokers. While testing complex identity boundaries generates higher logic-based noise, having full access to the source code allows teams to pair agents with deterministic checks to safely triage findings, given that the blast radius of an authentication failure justifies the human effort.

To filter the noise generated by LLMs, organizations should establish routing rules. Require the agent to generate a fully reproducible, deterministic test harness (such as a compiled binary or a Python test script) that attempts to prove the exploit. This harness must execute automatically in an isolated, monitored sandbox. If the sandbox execution fails (due to a syntax error or a failed exploit), the ticket is discarded, sparing human resources. However, organizations should enforce execution timeouts and iteration limits on these test harnesses. Without hard limits, an autonomous agent attempting to prove a vulnerability can fall into an infinite loop: writing a script, failing, rewriting, and failing again, exhausting API token budgets and compute resources against a single dead-end vulnerability, creating significant cost overruns without advancing the security review. To manage these expenses, organizations should incorporate FinOps principles to balance the compute and API costs of LLM audits against the traditional expenses of manual triage.

However, a successful execution in the sandbox does not guarantee an actionable, high-priority risk. In practice, autonomous agents frequently produce working PoCs for genuine technical flaws that are ultimately irrelevant; or warrant a lower remediation priority within the context of the system's threat model. For example, the agent might successfully exploit an unreachable dead-code path, or trigger a bug that requires administrative access to execute and yields no further escalation of privilege. Therefore, a human engineer should be assigned to review and prioritize the ticket only if the sandbox registers a successful execution, validating environmental context, reachability, and true business impact as part of the review.

This workflow reduces the volume of alerts, but it is important to understand that the security team's workload does not disappear. The engineer's primary job shifts from manually hunting for the initial vulnerability to auditing the LLM-generated proof to ensure it represents a meaningful risk rather than an unexploitable or contextually irrelevant finding. Leadership should properly staff and train teams for this new reality. Deploying LLM agents does not remove the need for skilled practitioners; it redirects their workload toward complex validation. Equally important is training teams to recognize the risk of false negatives. A hyper-focus on filtering AI-generated noise can create a false sense of security. If an exploit relies on a novel technique or a zero-day vulnerability that was not heavily weighted in the model's training data, the agent will likely scan right past it in silence. LLMs augment discovery, but they do not guarantee exhaustive coverage.

When integrating LLMs into SAST triage pipelines, human engineers should also verify the broader architectural integrity. Prompting an LLM with specific SAST warnings can induce contextual narrowing, where the agent becomes hyper-fixated on resolving a localized syntax error and misses broader architectural flaws existing in the same file. Furthermore, if the agent's mandate extends beyond discovery to automated remediation (such as writing and proposing code fixes), this human-in-the-loop validation becomes critical to ensure the LLM does not inadvertently introduce new regressions or bypass intended business logic.

Demistiying Image 6 New

Figure 6: Flowchart outlining the targeted LLM deployment and triage workflow.

Remediation and hardening

LLM-assisted code remediation

A primary goal of integrating large language models (LLMs) into the software development lifecycle is automated remediation. To achieve this, organizations are deploying these capabilities through two primary execution methods: directly within the integrated development environment (IDE) or as a centralized pipeline runner. Examples include CodeMender, although as of time of writing, it is not publicly available.

IDE-integrated method 

This method shifts remediation as far left as possible by operating as an active pair-programmer. Tools running continuous static analysis in the background of the IDE surface vulnerabilities directly to the developer via editor diagnostics like inline indicators or hover tooltips.

  • Localized scope: The developer can trigger the LLM agent to analyze the localized data flow and generate a targeted patch (such as implementing parameterized SQL queries). By constraining the LLM to localized, syntax-level fixes, the scope of the change remains contained. This prevents the agent from attempting sprawling, multi-file refactors that frequently break complex architectural logic.

  • Human-in-the-loop: The developer reviews the AI-generated patch before the code is committed.

  • Managing false positives: Local IDE agents allow developers to manage false positives dynamically. Suppressing alerts anchored to specific line text reduces alert fatigue and preserves developer trust.

CI/CD runner method 

The runner method executes asynchronously within the CI/CD pipeline to use an LLM to review committed code and automatically propose remediation.

  • Restricted execution and deterministic validation: Asking a centralized runner to automatically rewrite a complex, multi-file authorization flaw directly in the main branch introduces a high risk of breaking logic errors. To mitigate this, agents must be restricted to generating pull requests (PRs). Once a PR is generated, it must automatically execute standard regression suites alongside the deterministic test harness. By rerunning the initial PoC against the patched code, the workflow repurposes the exploit script as a validation oracle to prove the vulnerability has been remediated. A human engineer then reviews the PR to validate the architectural logic before merging.

In all cases security teams should define a clear boundary between the two methods rather than rely on a single approach. IDE agents provide immediate, syntax-level support. They catch and resolve low-complexity errors locally before developers commit code. Centralized CI/CD runners handle broader organizational baselines. They propose complex, repository-wide fixes for vulnerabilities that bypass local environments.

Post-deployment controls 

Even with human review and deterministic test harnesses, AI-generated patches can still introduce logic regressions in production. Organizations should implement strict post-deployment controls:

  • Automated rollbacks: Treating LLM-generated code with the same post-deployment scrutiny as any major architectural change ensures that if an unforeseen regression traverses the CI/CD pipeline, the environment can revert to a known good state.

  • Mitigating model drift: Relying on managed AI services introduces the ongoing risk of model drift. To prevent silent weight updates from breaking test harnesses, organizations need to pin specific model API versions to frozen releases. When a pinned version reaches its end-of-life, organizations will face a forced migration. Mitigating this pipeline fragility requires combining model pinning with deterministic regression suites.

  • Compliance and auditability: If an AI agent automatically closes a security ticket or generates a patch in the CI/CD pipeline, organizations should maintain immutable audit logs to satisfy frameworks like SOC 2 ,PCI-DSS, FedRAMP, and CMMC. National security deployments must also account for data sovereignty requirements. This logging should record the specific model version that proposed the fix, the deterministic test results that validated it, and the human engineer who approved the merge. Furthermore, because emerging legislation like the EU AI Act emphasizes human oversight for high-risk applications, security teams should carefully evaluate how autonomous remediation workflows align with these evolving global regulatory standards.

demistifying image 7

Figure 7: Flowchart demonstrating the difference between local IDE AI remediation and centralized CI/CD pipeline remediation.

Conclusion

Leveraging LLMs in vulnerability management is a multi-layer solution: Integrating it requires separating workflows by layer. At the enterprise infrastructure level, Risk-Based Vulnerability Management (RBVM) and exposure management are necessary to process the volume of findings and configuration drift. At the product and code security level, LLM-enabled vulnerability assessment and remediation must operate alongside foundational deterministic controls, such as SAST and DAST, to audit custom, open-source, or third-party code.

Although LLMs can help manage technical debt and accelerate vulnerability discovery, they do not replace secure-by-design principles. The fact that LLM agents are proving exceptionally capable at identifying and exploiting localized memory corruption in memory-unsafe codebases, alongside other primary vectors, should serve as a wake-up call. 

As a long-term strategy aligned with NSA guidance on Software Memory Safety, organizations need to phase memory-safe languages into new internal development. LLMs are beginning to expand what is possible here by reducing the manual labor required for code migration. Converting existing C or C++ codebases to Rust has historically been unrealistic due to the large volume of engineering hours needed. While fully automated translation is not a turn-key solution, using LLMs to assist engineers with the bulk of the conversion can make these long-term migrations operationally viable. Beyond internal efforts, organizations should use procurement requirements to incentivize vendors to reduce their reliance on memory-unsafe languages and establish secure configuration defaults over time. Bridging the gap between AI velocity and enterprise defense means building an automated pipeline to manage the current backlog, while architecting systems where entire classes of vulnerabilities and misconfigurations are eliminated by design.

Acknowledgements

This analysis would not have been possible without the assistance of Google Threat Intelligence Group (GTIG) and other broader Google teams.



from Threat Intelligence https://ift.tt/zeCajyD
via IFTTT