#credentialtheft

Read Time:3 Minute, 24 Second

A threat cluster targeting government bodies and state-affiliated infrastructure turned a trusted Linux administration routine into a password-stealing trap. Rather than exploit a defect in sudo, the attackers changed shell startup files so that a counterfeit prompt captured a user’s password and then passed it to the genuine command. The requested task still worked, making the theft much easier to overlook.

Unit 42 tracks the related activity as CL-UNK-1211 and observed it between October 2025 and April 2026. The “UNK” label means researchers have not determined whether the cluster belongs to a state-backed group or financially motivated criminals. The evidence supports a coordinated campaign, but not a confident attribution to a named actor or government.

A malicious alias hid inside Bash configurationThe attackers replaced a user’s .bashrc file with a modified version containing an alias for sudo. When the victim entered an administrative command, the alias presented a familiar-looking password request. It saved the submitted secret to an attacker-controlled file before forwarding it to the legitimate utility, preserving the expected behavior and reducing the chance of suspicion.

The stolen credentials were written to a file called Solarwinds.StatusLog.txt, apparently chosen to resemble an ordinary system artifact. Unit 42 found no indication that SolarWinds products or infrastructure were involved. That filename is camouflage, not evidence of a SolarWinds compromise.

This technique is important operationally because a conventional patch cycle will not remove it. There was no flaw in sudo to fix. Responders must inspect user profiles, aliases and startup scripts, compare them with known-good configurations, and determine how the unauthorized change was introduced.

Credential collection extended beyond the command lineThe campaign also modified a PHP login page to collect administrator usernames and passwords. Operators searched configuration files and command histories for email, SMTP and database secrets, then examined government mailboxes for messages related to social-media accounts. Researchers observed attempts to archive mailbox contents and retrieve database information, although at least one collection script contained a syntax error and would not have worked as written.

For persistent remote access, the attackers deployed web shells and a custom Go-based remote-access Trojan named SysGoRAT. The malware runs on Linux and Windows, communicates over WebSocket, and supports command execution, interactive shells, file operations and persistence. Binaries used names such as sys-control-client, pip2.7 and ea_install to blend into a system.

AI traces appeared in parts of the toolkitSeveral scripts included conversational comments and step-by-step reasoning notes that Unit 42 assessed as consistent with AI-generated code or work performed with an automated coding agent. The toolkit also moved among PHP, JavaScript, Bash and Python and used encoded commands. These characteristics suggest AI helped create or modify parts of the operation; they do not prove that a model independently selected targets or directed the campaign.

The practical lesson is less about novelty than speed and accessibility. An operator can use an assistant to translate techniques between languages, repair scripts and document procedures. Yet the campaign also displayed ordinary mistakes, reinforcing that AI-assisted malicious code can be inconsistent and should be evaluated by behavior, not mystique.

What defenders should inspectCompare .bashrc and other shell profiles against approved baselines, looking for unexpected aliases and password-handling logic.

Review PHP settings, prepend directives and login pages for unauthorized changes.

Search for suspiciously named binaries, web shells and unusual WebSocket connections from servers.

Preserve logs and histories during response, especially when evidence suggests timestamp changes or cleanup attempts.

Rotate exposed administrative, email and database credentials from a trusted system after containment.

The operators tried to stop endpoint-security processes, erase logs and shell history, delete temporary scripts and alter timestamps. They also planted labels such as “RedTeamOps2025” to make activity look authorized. Defenders should verify claimed testing with change records and named owners; a red-team-style marker is not proof of permission. Configuration integrity monitoring, careful privilege review and centralized logs can reveal the kind of tampering that a vulnerability scanner alone will miss.

Read Time:4 Minute, 6 Second

An established information-stealing malware family known as Aoki — sometimes labeled Aokigahara after a string used in its decryption routine — has expanded its target list to include the local files and session data belonging to AI coding assistants, including ChatGPT, Claude, OpenAI Codex, Cursor, Codeium, and Google Gemini. The addition, identified by Symantec’s Threat Hunter team, signals a broader shift in what infostealer operators now consider valuable loot sitting on a developer’s laptop.

A Familiar Threat, Updated TargetingAoki is not a new strain — it has circulated for some time as a general-purpose credential and data thief. What’s changed is its collection list. Symantec’s analysis found that recent builds actively search for files tied to Claude, ChatGPT, and Codex, along with authentication tokens used by GitHub Copilot, Cursor, Gemini, JetBrains AI Assistant, and Kiro. Earlier Aoki samples didn’t bother with any of this, which suggests the AI-tooling targeting is a deliberate, relatively recent addition to the malware’s capabilities rather than a longstanding feature.

Specific files named in Symantec’s report include the .claude.json configuration file, locally stored Claude desktop and ChatGPT session cookies, and Codex’s config.toml and .env files — exactly the kind of files that routinely hold live session tokens, API keys, or account secrets. Aoki also reaches into Cursor’s local state database, which can retain chat history and code snippets, though Symantec notes the malware’s apparent priority is grabbing credentials and session data rather than harvesting source code for its own sake.

Why a Stolen AI Token MattersUnlike a vulnerability in an AI vendor’s cloud service, this is squarely a device-compromise problem: Aoki only works if it’s already running on an infected machine. But the consequences of a successful theft extend well past the AI subscription itself. A stolen session token or API key can let an attacker operate as the account’s legitimate owner — running up paid usage charges, or, more worryingly for development teams, potentially reaching any repositories, cloud services, or CI/CD pipelines that the AI tool had legitimate access to.

This isn’t an isolated concern. Compromised cloud credentials have already been observed fueling a scheme known as LLMjacking, in which stolen access is used to run paid AI workloads at someone else’s expense. Aoki’s reported behavior is distinct — it steals data directly from the device rather than cloud keys specifically — but the underlying risk to victims is the same: someone else quietly operating under your account and your bill.

AI Tools Are Just One Target Among ManyAoki’s reach goes far beyond developer tools. Symantec’s report describes it harvesting browser cookies, saved passwords, autofill data, and stored payment card details across a wide range of browsers, alongside cryptocurrency wallet files and extensions, password manager data, VPN and file-transfer application credentials, gaming account details, and data from Telegram and Discord. It also fingerprints which security products are installed on the infected machine — reconnaissance that can inform follow-on attacks or help the operator evade detection.

That breadth is what makes a single infection consequential: one compromised laptop can become a pivot point into a developer’s cloud accounts, source control, messaging platforms, and financial tools all at once. Stolen data is sent to attacker-controlled infrastructure through a /gate endpoint; Symantec notes that newer samples spread requests across multiple domains, while older variants relied on a single IP address communicating over unencrypted HTTP on port 8080.

Symantec has not tied Aoki to a specific named threat actor or an established malware family, and the report doesn’t offer insight into its distribution method. The company tracks the family internally as Infostealer.Aoki.

What Development Teams Should DoTreat AI assistant configuration files, session cookies, and local state databases with the same sensitivity as cloud API keys or source-control credentials — because they now function the same way to an attacker.

If compromise is suspected, use a known-clean device to revoke active AI tool sessions, rotate exposed API keys, and review recent account activity for unauthorized usage.

Audit connected repositories, cloud services, and CI/CD systems for unexpected access tied to AI tool accounts following any suspected infection.

Avoid storing long-lived secrets in files local applications can read freely, and scope tokens to the minimum access and lifetime actually needed.

Monitor endpoints for unusual access to AI tool configuration folders and unexpected outbound connections, which may indicate stealer activity even before other symptoms appear.

Security teams should note that multi-factor authentication offers limited protection here — if a session token has already been lifted from a compromised device, an attacker can often reuse it without ever needing to pass an MFA challenge. Aoki’s pivot toward AI tooling fits a wider pattern researchers have flagged recently, including fake npm packages impersonating AI tools specifically to harvest credentials from developer machines, underscoring that the rapid adoption of AI coding assistants has made local developer environments a genuinely attractive target rather than an overlooked one.

Read Time:3 Minute, 46 Second

A credential-theft campaign uncovered by security firm Huntress shows just how little a victim needs to do wrong to hand over the keys to their corporate network: a routine search, a plausible-looking result, and a login prompt that looks exactly like the one they’d expect to see.

A Search That Led to a Lookalike SiteHuntress investigators were called in after an October 7 incident involving an administrator at a managed service provider. Browser history showed the administrator had searched Bing for a WatchGuard VPN client download, clicked through to what appeared to be WatchGuard’s own site within eight seconds, and landed on a page carrying the company’s branding, product descriptions, and even a mocked-up support FAQ.

The evidence pointed to search engine optimization poisoning rather than a paid malicious ad: the site had apparently been engineered to rank well for the exact phrasing IT staff tend to type in when they need a VPN client in a hurry. It’s a tactic cybersecurity researchers have flagged repeatedly in recent years, and one that undermines a habit many users rely on for safety, trusting whatever appears near the top of a search results page.

The Capture MechanismClicking the download button didn’t trigger a file download at all. Instead, it opened a form requesting three pieces of information: a VPN server address, a username, and a password, the exact fields a real WatchGuard SSL VPN client would ask for. Because the request matched what a legitimate connection attempt looks like, there was little about it to raise suspicion.

Behind the scenes, roughly 150 lines of JavaScript quietly packaged whatever the victim typed into a JSON payload and sent it off to a separate collection server via an HTTP POST request. Each submission was tagged to indicate whether it was a first or second attempt, a detail that turns out to matter.

That’s because the page was designed to reject the first submission outright, clearing the form and displaying an “Incorrect data” error regardless of what was entered. Many users, assuming they’d simply mistyped a password, try again, which is exactly the point: the operators wanted two sets of credentials rather than one, in case a mistyped password on the first attempt made the stolen data useless.

The Payoff: A Genuine, Signed InstallerOnly after the second submission did the page turn its error message green and quietly trigger a download, not of malware, but of the actual WatchGuard Mobile VPN with SSL client, version 12.11.5, pulled directly from WatchGuard’s own official content delivery network. Huntress confirmed the file’s digital signature was valid and its contents unmodified.

That design choice separates this campaign from more familiar vendor-impersonation schemes, where attackers bundle malware or a tampered DLL into a fake installer. Here, the victim who completes the download walks away with working, legitimate software and may never suspect anything happened, even though their VPN credentials, and potentially the address of their organization’s VPN gateway, are already sitting on an attacker-controlled server.

Caught Fast, But the Exposure Still MattersIn the incident Huntress investigated, its Managed Defender service flagged the suspicious activity just 21 seconds after the page loaded, and browser history showed no evidence the WatchGuard installer had actually been downloaded, suggesting the administrator may not have completed the second form submission. Still, Huntress couldn’t rule out that a first set of credentials had already gone through.

The phishing domain itself was taken offline by the time Huntress published its findings on October 13, though the firm noted a related domain had been registered and used in earlier campaign activity, suggesting this kind of lure may resurface under a new name.

What Organizations Should DoTreat any VPN credentials entered on a search-result page, rather than a bookmarked or internally distributed link, as potentially compromised and reset them.

Assume any VPN server address typed into such a form is now known to attackers, and monitor for connection attempts against it.

Enforce multifactor authentication on VPN logins so a stolen password alone isn’t enough to gain access.

Direct staff to bookmark the official WatchGuard software portal rather than relying on search engines to find vendor downloads.

Remember that a valid digital signature on a downloaded file says nothing about whether the site that served it handled your credentials safely beforehand.

The episode is a useful reminder that phishing doesn’t always involve a fake or broken program. Sometimes the lure is just a login box in front of the real thing.

Read Time:4 Minute, 1 Second

Cisco Talos researchers have published a detailed breakdown of a phishing kit that doesn’t just collect passwords, it actively relays victims through a real Google login in real time, letting a human or automated operator watch and respond to each authentication step as it happens. The technique, known as adversary-in-the-middle phishing, lets attackers bypass multi-factor authentication not by breaking it, but by sitting invisibly between the victim and Google’s actual sign-in service and forwarding each step along.

Talos tracks the operation as UAT-11985 and first observed it during mid-2026, publishing its full technical findings on October 8. The targets were people connected to research organizations in Taiwan, approached through emails disguised as invitations to academic and policy events.

A Convincing Setup Built on Real DetailsThe phishing emails impersonated three organizations: the Taiwan European Union Centre, the NCCU Institute of International Relations, and the Taiwan Research Institute. When Talos checked with those actual institutions, none could confirm that the purported senders were real employees or representatives, meaning the identities were fabricated even as the event details referenced in the emails were accurate. That mix of real event information with invented sender identities is what made the approach convincing: recipients checking the event itself would find it legitimate, even though the person inviting them wasn’t.

Talos also flagged stylistic signs consistent with AI-assisted writing in the emails, including repeated sentence structures and broadly tailored compliments that shifted easily between topics and recipients, though the researchers stopped short of proving a language model generated the complete messages. Beyond email, the attackers also doctored legitimate event posters, replacing the real QR codes with malicious ones, a tactic that could ensnare victims who never received the original phishing email at all, simply by scanning a poster they encountered elsewhere.

Inside the Real-Time RelayThe technical core of the operation is what sets it apart from ordinary credential-harvesting pages. Victims first land on a fake Google Form that redirects to a cloned Google sign-in page, but rather than simply storing whatever is typed into it, the kit actively drives victims through each stage of a real authentication flow using a persistent WebSocket connection.

Talos’s analysis breaks down the sequence as follows:

An initial google_login_start request collects the victim’s browser language, user-agent, screen size, and device type, then opens a WebSocket connection tied to that session

A google_input_identifier event sends the victim’s email address or phone number to be checked against Google’s genuine authentication backend

Once a password is entered, google_login_check forwards it along with the account identifier and browser fingerprint

If Google’s real system then demands a further verification step, such as an MFA prompt, the operator uses the open WebSocket to push live instructions telling the fake page exactly which screen to display next

That architecture, separating bulk data uploads over HTTP from instant screen-update commands over WebSocket, lets the kit react to Google’s authentication flow as it unfolds, rather than relying on a static, pre-scripted fake login sequence. The end result, according to Talos, is theft of fully authenticated session tokens, giving attackers account access even after a victim correctly completes an MFA challenge they believed was protecting them.

A Familiar Threat With a More Dynamic DeliveryThe core idea, intercepting a live login session to defeat MFA, isn’t new. Talos points to similarities with earlier kits like Tycoon 2FA, and Cyber Security News has separately reported on Mirage2FA, a kit that used stolen session cookies to hijack Microsoft 365 accounts across roughly 3,500 organizations. What distinguishes UAT-11985 is its use of persistent WebSocket connections to drive the fake interface dynamically rather than scripting a fixed sequence of fake pages in advance, giving operators more flexibility to react to whatever Google’s real authentication system actually asks for.

The kit’s interface supports Simplified Chinese, Traditional Chinese, and English, and Talos assessed with moderate confidence that Simplified Chinese was the developer’s primary working language, a finding the researchers were careful to note does not by itself establish the attacker’s nationality or any state affiliation.

Why Completing MFA Isn’t EnoughThe central lesson from this campaign is uncomfortable but important: successfully completing a multi-factor authentication prompt does not guarantee a safe login session if that prompt was relayed through an attacker-controlled intermediary. Security teams are better served by phishing-resistant authentication methods, such as hardware security keys that cryptographically verify the destination domain, than by MFA factors that can be relayed step by step. Talos also recommends independently verifying unexpected event invitations through official channels before clicking registration links, and treating any suspected session theft as requiring more than a simple password reset, since a hijacked session token can remain valid regardless of password changes made afterward.

Read Time:3 Minute, 38 Second

A new wave of ClickFix-style attacks is raising the bar for social-engineering malware by hiding its payload somewhere most defenders never look: the browser’s own cache. Microsoft Threat Intelligence has flagged a cluster of compromised websites that trick visitors into running a malicious command themselves, under the guise of a routine CAPTCHA or “fix this error” prompt.

A Familiar Trick With a New TwistClickFix-type attacks have become a staple of modern malware delivery because they sidestep technical exploits entirely and instead manipulate human behavior. Visitors to a booby-trapped site are shown a fake verification screen instructing them to open the Windows Run dialog, paste a snippet of text, and press Enter. A genuine CAPTCHA never asks a person to execute system commands, but the instruction is phrased convincingly enough that many users comply without a second thought.

What sets this variant apart is timing. In most ClickFix campaigns, the pasted command reaches out to a remote server to fetch the actual malware after the victim acts. Here, the heavy lifting happens beforehand: attackers quietly pre-position a VBScript payload inside the browser’s profile cache, disguising it as an ordinary PNG image file. By the time the victim pastes anything into Run, the malicious code is already sitting on the machine.

How the Infection Chain Plays OutThe pasted command is short deliberately, just long enough to launch a search through cache directories, such as a Firefox profile folder, for a file matching a specific byte size set by the attackers in advance. Once a match is found, the command copies that disguised “image” into a temporary VBScript file and executes it through the Windows Script Host, with all output and error messages suppressed so nothing looks amiss on screen.

From there, the infection escalates methodically:

The VBScript profiles the machine using Windows Management Instrumentation and pulls down a follow-on PowerShell script.

A second payload is retrieved, and the attackers invoke .NET compilation utilities to build and launch code on the fly.

That code is injected into a legitimate, trusted Windows process, where it hunts for browser-stored credentials and other sensitive device data.

For persistence, the PowerShell execution policy is flipped to “Bypass,” Python components are unpacked, and a scheduled task is created to relaunch a Python-based payload silently, even after the browser is closed.

Why Cache-Based Smuggling Is Hard to CatchSecurity tools are generally tuned to flag suspicious downloads and outbound network requests at the moment of execution. By front-loading the payload into cache storage long before the user interacts with it, attackers sidestep that detection window almost entirely. Because the “trigger” size value varies between campaign variants, simple file-size heuristics are not a reliable defense either, forcing analysts to look at behavior rather than static indicators.

This approach builds on a broader trend documented in earlier reporting on fake CAPTCHA phishing and related “FileFix” cache-smuggling techniques, where the common thread is the same: abuse the implicit trust people place in routine verification prompts, then let the victim’s own click do the work a traditional exploit would otherwise need.

What Defenders Should Watch ForBecause the attack leans on living-off-the-land behavior rather than an obviously malicious download, Microsoft and independent researchers point security teams toward behavioral signals instead of file signatures. Useful hunting leads include:

Unusual read activity against browser cache folders shortly before a WScript or PowerShell process spawns.

Entries in the RunMRU registry key reflecting pasted Run-dialog commands.

PowerShell sessions launched with the execution policy set to Bypass.

Newly created scheduled tasks invoking a windowless Python interpreter.

Microsoft is recommending that organizations enable cloud-delivered protection, web protection, network protection, application control, and PowerShell script-block logging to improve visibility into this kind of multistage, human-triggered attack chain. Security teams should also consider blocking or tightly monitoring the Run dialog’s clipboard-paste pattern on managed endpoints, and reinforce user training that no legitimate CAPTCHA or error message will ever ask someone to open Run and execute a command.

As cache-smuggling and other “human-assisted” infection techniques continue to spread, the underlying lesson is consistent: attackers are increasingly optimizing for the moment a user clicks rather than for a software flaw, which means awareness training and behavioral detection now carry as much weight as traditional patching.

Read Time:4 Minute, 22 Second

Security researchers at LevelBlue have pulled back the curtain on a credential-harvesting toolkit, internally named TIKTOUK, that turns an everyday WordPress mistake — leaving a site backup or configuration file sitting in a publicly reachable location — into a pipeline for stealing cloud and email credentials at scale. A leaked control panel used to run the operation revealed roughly 50,000 real, server-side credentials gathered from about 37,000 domains, including hundreds of AWS access keys that the researchers confirmed were still active.

Rather than relying on one single exploit, TIKTOUK bundles several different collection techniques together: scanning sites for exposed sensitive files, recovering stored passwords from plugin configurations, and scraping secrets out of JavaScript served to ordinary site visitors. LevelBlue says the operation was already running at meaningful scale by the time it was identified through a combination of source code review, reverse engineering, and controlled lab testing.

Inside the Toolkit’s ArchitectureTIKTOUK is built from two Python components plus a Linux-based crawler written in Go, all of which check in with a central HTTP service to receive tasks and report back findings. The coordination layer distributes targets and collects results, though LevelBlue’s testing didn’t find evidence of a fully automatic handoff between the different components — suggesting a human operator may still be steering parts of the operation.

The probing component handles initial reconnaissance: it pulls a list of targets, confirms which ones are running WordPress, and then sends specially crafted REST API batch requests that combine a malformed URL with delete and content-rendering operations. When a request formatted as JSON gets rejected, the tool automatically retries using multipart encoding instead — and that retry frequently succeeds. That specific fallback pattern, LevelBlue notes, gives defenders a distinctive signature to hunt for in their own web server logs.

Turning a Backup File Into a Credential DumpA separate collection module goes after exposed WordPress configuration backups directly, pulling database credentials and WordPress security keys out of them. It doesn’t stop there — the same component also probes for exposed environment files, repository configuration, raw database backups, and debug logs, essentially sweeping up anything left accessible through a plain web request that shouldn’t be.

Some of its database queries are notably methodical: nested batch requests first retrieve the name WordPress uses for its options table, then feed that name into follow-up queries designed to pull the option values themselves. The tool decodes hexadecimal-encoded responses back into readable text and assembles structured records containing database settings, stored email credentials, AWS key pairs, and recognizable API key patterns.

From Website Compromise to Cloud TakeoverThe blast radius extends well past the compromised website itself. The leaked operator panel contained AWS keys with the potential to be abused for sending email, spinning up compute resources, or accessing AI services tied to the victim’s cloud account. TIKTOUK’s collector can specifically decrypt stored settings from popular SMTP plugins — WP Mail SMTP, Easy WP SMTP, and FluentSMTP — recovering plaintext email credentials using encryption keys or configuration material the tool already has access to. LevelBlue is careful to note this isn’t a cryptographic breakthrough; the toolkit simply gets its hands on what it needs to unlock settings that were never meant to be exposed in the first place. In one particularly efficient step, it can even derive an Amazon SES email password directly from a stolen AWS secret key.

A third piece, the JavaScript crawler, fetches site pages and any scripts they load, scanning the contents for credential patterns tied to services like SendGrid, Anthropic, AWS Bedrock, and AWS more broadly — all secrets that were likely embedded in client-side code by mistake and shipped straight to every visitor’s browser.

Exploitation Links and What’s Still UnconfirmedLevelBlue connected TIKTOUK’s request patterns to two specific vulnerabilities, CVE-2026-60137 and CVE-2026-63030, which affect a batch-route mechanism in WordPress versions 6.9.x prior to 6.9.5 and 7.0.x prior to 7.0.2. Importantly, the firm’s lab testing didn’t go as far as demonstrating a full working exploit — controlled test targets returned pre-prepared responses without actually executing attacker-supplied SQL. That said, separate incident telemetry did confirm the toolkit successfully retrieved payloads and communicated with its controller infrastructure in the wild, and investigators separately identified a related Go-based botnet capable of remote command execution.

In short: the lab results establish exactly how the components behave, not that a specific live production site has been fully breached end-to-end using this chain. Site operators shouldn’t read that distinction as reassuring, though, given the scale of credentials already found in the leaked panel.

What WordPress Site Owners Should CheckConfirm backup files, configuration exports, and debug logs are never stored inside a publicly web-accessible directory.

Update WordPress past the affected 6.9.x and 7.0.x ranges identified in the advisory.

Rotate SMTP plugin credentials and any AWS keys that may have been referenced in configuration files or client-side JavaScript.

Watch server logs for the JSON-then-multipart retry pattern on REST batch endpoints as a potential sign of probing activity.

Audit JavaScript served to visitors for hard-coded API keys or secrets that should never have been placed there.

Read Time:3 Minute, 33 Second

Attackers investigating a Viva Aerobus environment turned a Microsoft SQL Server connection into a channel for operating-system commands and data theft, according to newly disclosed threat research. The intrusion shows how legitimate database functionality can become a covert control path after credentials or access have already been obtained.

The activity was observed from September 25 through September 29, 2026. Researchers recovered evidence of credential collection, source-code gathering and attempts to prepare access to other systems. The initial entry point has not been established, and the available evidence does not prove a passenger-data or payment-data breach.

An unusual operational mistake gave defenders a close look at the campaign: the attackers left their own server publicly accessible. It contained tools and collected files that could be retrieved by unrelated internet users, creating a second exposure on top of the original compromise.

Database access becomes operating-system controlThe intruders relied on xp_cmdshell, an SQL Server feature capable of launching commands through Windows when it is enabled and sufficiently privileged. Recovered utilities submitted ordinary command-line instructions and encoded PowerShell through database sessions. That transformed a database connection into an interface for the host beneath it.

The technique does not by itself reveal how the attackers first gained access. There is no confirmed software vulnerability, password-spraying event or named malware family tied to the initial compromise. What the evidence does show is post-compromise abuse: once the SQL path was available, the attackers no longer needed a conventional remote-access implant for every action.

Defenders sometimes monitor databases principally for destructive queries, suspicious account creation or bulk record access. This incident highlights a wider requirement. Process creation under an SQL Server service account, especially cmd.exe or powershell.exe, can signal that database privileges are being converted into host control.

Files moved through query responsesThe same connection also carried data outward. Tools read files, split them into smaller blocks, converted those blocks to Base64 text and returned the encoded content through SQL query results. Base64 provides no confidentiality; it simply represents binary data as text. In this case it allowed stolen material to fit naturally inside database responses.

Using an established database channel can help activity blend into expected network flows. Security controls focused on new command-and-control domains or unusual outbound protocols may miss exfiltration when the traffic travels between systems already permitted to communicate. Detection therefore needs behavioral context, including abnormal query size, repeated encoded output and file operations performed by database processes.

Credential collection and lateral-movement preparationThe exposed server held 17 named tools. They included scripts for extracting browser and Windows credentials, testing SQL logins, accessing Windows credential stores and transferring files. Mimikatz artifacts indicated credential-dumping activity, while SQL Server Management Studio history revealed database usernames and saved password material protected by Windows DPAPI.

Collected source code and configuration data referenced OAuth, email, SFTP, database, payment and reporting integrations. Such material can disclose architecture and secret locations even when every credential is not immediately usable. Investigators also found utilities designed to test credentials against additional SQL servers and probe SMB administrative shares.

Those artifacts support an assessment that the attackers were preparing to move laterally, but they do not prove that each attempted target was compromised. Researchers withheld private hostnames, usernames and reusable values rather than amplifying the leak. Any secret that reached the exposed staging server should nevertheless be considered compromised because third parties accessed its contents.

Detection and containment prioritiesInvestigate unexpected use or enablement of xp_cmdshell.

Hunt for encoded PowerShell and command shells launched by SQL Server service accounts.

Review large or repetitive query responses that could contain Base64 file chunks.

Rotate database, OAuth, email, SFTP and integration secrets present in exposed files.

Check SQL login testing, SMB admin-share access and unusual connections to other servers.

Organizations should also minimize SQL service-account privileges and disable risky features where business needs do not require them. Network segmentation must account for what a database server can reach after compromise, not only who can connect to it. The incident is a reminder that trusted administrative channels can become effective attacker infrastructure without introducing a distinctive malware protocol.

Source: Cyber Security News, reporting on ThreatMon’s investigation.

Read Time:3 Minute, 55 Second

A new analysis from threat intelligence firm ReversingLabs, shared with Cyber Security News, pulls together three separate software supply chain incidents — S1ngularity, Shai-Hulud, and activity linked to a group tracked as TeamPCP — into a single picture of how attackers are turning the ordinary mechanics of software distribution into a credential-harvesting machine. The common thread: once an attacker gets hold of a single maintainer token or slips into an automated release pipeline, they can push malicious code through an update channel that developers and their security tools already implicitly trust.

The report, published September 30, 2026, argues that the danger isn’t confined to any one language ecosystem or vendor. Stolen GitHub tokens, npm publishing credentials, cloud API keys, and SSH keys can each become the opening move in a chain reaction — and in several of the documented cases, credentials stolen from one victim were reused to poison the next release down the line.

S1ngularity: When an AI Assistant Becomes the Attacker’s Search ToolThe S1ngularity campaign, which ReversingLabs dates to August 26, 2025, began when attackers used a crafted pull request against the Nx build tool’s repository to obtain a publishing token and swap in a malicious CI script, ultimately triggering a legitimate-looking publish of infected packages. Once installed on a developer’s machine, those packages ran post-install hooks designed to hunt down tokens, credentials, and SSH keys — then used any GitHub credentials they found on the host to spin up public repositories as a convenient exfiltration channel.

What set the campaign apart was a more unusual twist: the malicious code reportedly issued prompts to local AI coding assistants already installed on the victim’s machine, instructing them to search the file system for likely credential locations such as GitHub and npm tokens, cloud secrets, and SSH keys. In effect, the attackers tried to recruit the developer’s own AI tooling as an unwitting reconnaissance assistant — a technique that goes well beyond a conventional credential stealer. In the aftermath, Nx moved to a trusted-publisher model built on short-lived, per-run credentials specifically to reduce how much damage a single stolen token can do going forward.

Shai-Hulud: A Worm That Spreads Through Trust ItselfWhere S1ngularity relied on a one-time pull-request trick, the Shai-Hulud campaign built self-propagation directly into its design. The worm scanned compromised systems for npm publishing credentials, used whatever it found to identify which packages a given victim had permission to publish, and then quietly inserted malicious code into those packages’ next releases. That approach let it spread from project to project without needing to find a fresh software vulnerability at each stop — the compromised credentials themselves did all the work.

TeamPCP and the Trivy Incident: Recycling a BreachThe report also details how a group associated with or possibly overlapping with TeamPCP exploited an earlier breach of the Trivy vulnerability scanner project. A privileged token had been extracted back in February 2026, but an incomplete credential rotation left a residual path open, which attackers used in March to push a malicious update through an automated release system by manipulating version tags relied on by CI/CD workflows. The payload specifically targeted secrets inside running workflow environments, where automation pipelines tend to concentrate valuable credentials in one place.

From there, the group reportedly used npm tokens harvested through the Trivy compromise to distribute a further piece of malware dubbed CanisterWorm, which went on to compromise more than 60 separate npm packages. Downstream, organizations including Checkmarx, LiteLLM, and Telnyx were also caught up in the fallout — a chain that illustrates how a single stolen credential can ripple outward across unrelated companies with no direct relationship to the original breach.

Shoring Up the Software Supply ChainReversingLabs frames a successful supply chain compromise as something closer to a full credential breach than a single tainted package, and recommends organizations respond accordingly. Practical steps include:

Replace long-lived publishing secrets with short-lived, per-run credentials wherever release tooling supports it.

Scope API and publishing tokens as tightly as possible rather than granting broad, standing access.

Pin CI/CD pipeline dependencies to specific, reviewed commits instead of trusting mutable tags.

Monitor repository and package-publishing activity for anomalies, such as releases that don’t correspond to a known code change.

Rotate any token or credential that may have touched an affected build pipeline, and audit for repositories, workflows, or package versions the team didn’t create.

The throughline across all three incidents is that attackers are no longer just looking to plant malware on an endpoint — they’re trying to compromise the publishing process itself, so their code arrives wearing the reputation of a package or vendor the victim already trusts.