Research has identified 42 weaponized GitHub repositories belonging to 11 legitimate owners in the testmetest npm campaign, exposing an operation that combines credential theft, development-tool execution hooks, and malicious package publishing. The findings establish that the campaign extended beyond attacker-controlled test packages into established developers’ repositories. Researchers Guy Korolevski and Yair Benamou uncovered oversized payload […]

The post Malicious npm Campaign Hijacks 42 GitHub Repositories to Steal Credentials and Spread Malware appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

A startup led by former GitHub CEO Thomas Dohmke is introducing its own platform for storing, reviewing and shipping code written by AI agents, competing with the company he used to run.

The startup, Entire, on Monday unveiled what it calls a Git forge — a service for hosting code, reviewing changes and running builds, the core of what GitHub does — designed for teams whose AI agents write code faster than people can review it. The company is pitching it as an alternative to GitHub.

The news comes two days before GitHub’s annual Universe conference in San Francisco. Microsoft acquired GitHub for $7.5 billion in 2018 and has since folded it into its CoreAI division.

The biggest change is Trails, Entire’s replacement for the pull request, the standard way developers propose and review code changes. The pull request “has become an audit log that only the agent reads,” Dohmke wrote in a blog post Monday. Instead of reading through every changed line, developers see a dashboard of scores from AI agents evaluating the code on each update.

According to Entire, multiple AI agents check the quality of each change, so developers can merge code without reading every line. Teams can also require a person’s sign-off, or passing automated tests, before any code goes in, the company said.

The launch comes as GitHub strains under the load from AI agents. The platform has had several significant outages in recent months, including one in August that lasted nearly eight hours. GitHub is moving from its own data centers to Microsoft’s Azure cloud to add capacity. GitHub said developers and agents made 7.38 billion commits, or saved code changes, on the platform in September alone.

Dohmke, who is based in Bellevue, Wash., left GitHub last year after nearly four years as CEO. Entire says it now has 50 employees. The company is fully remote.

Entire isn’t alone in rethinking code hosting for AI agents. AI coding company Cursor launched its own code-hosting service, Origin, in August. And Anthropic recently described building its own source control system as the number of code changes it merged each day grew from about 2,500 in May to more than 30,000 in September.

With the latest updates, Entire now lets developers host private code repositories directly on its service in the U.S., Europe, India and Australia, and says its service can handle up to 89 times as many code pushes per second as GitHub, based on its own benchmarks. It’s partnering with Buildkite and Depot on build and test pipelines, giving developers a way to move off GitHub Actions. Public repositories and self-hosting are on the roadmap.

Entire is also adding what it calls Continuous Memory, which lets AI agents search past coding sessions for the context behind earlier changes. The company says one part of it, a map of the codebase, cut token use by up to 71% in its testing.

That goes beyond the startup’s July launch, which mirrored existing GitHub repositories on a faster network rather than replacing them. Developers can still mirror from GitHub, or now move their code to Entire instead.

Microsoft’s venture arm M12 was among the backers of Entire’s $60 million seed round in February. Felicis led the round, with participation from Seattle-based Madrona and Basis Set Ventures, along with individual investors such as Yahoo co-founder Jerry Yang and Y Combinator CEO Garry Tan.

“Code review was always a bottleneck,” Dohmke said at a Madrona event last month. “I’ve never worked in a software company where I didn’t wait for somebody else to review my pull request, and you have to ping people in Slack three times. And there was this one guy that had to review everything because he knew what to look for. And now that bottleneck is 10 times bigger.”

OVHcloud has reported a supply-chain attack involving its command-line interface (CLI) repository. An attacker exploited a developer’s GitHub account to distribute a malicious binary designed to steal sensitive information from users’ disks. CEO Octave Klaba confirmed the incident on October 19, 2026, after a customer reported it. The company identified the compromised release at 14:47 […]

The post Hackers Compromise OVHcloud GitHub Repository to Distribute Secret-Stealing Malware appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

GhostAction has returned with an expanded credential-theft operation, injecting malicious GitHub Actions workflows into 790 repositories by October 9, 2026. GitGuardian first documented GhostAction in 2025, when it reported 817 affected repositories and 3,325 stolen secrets. The latest wave builds on the same account-takeover approach: attackers enumerate repositories a compromised maintainer can write to, then […]

The post GhostAction Hackers Inject Malicious Security Workflows Into 790 GitHub Repositories appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

An espionage campaign targeting government organizations across the Commonwealth of Independent States (CIS), with additional interest in water, environmental, and energy sectors. The investigation found four infection chains active from June 2025 through 2026. The attackers used macro-enabled Word documents, PS2EXE-built executables, malicious shortcuts that launched GitHub-hosted PowerShell, and a crafted WinRAR archive that exploited […]

The post UAT-6275 Hackers Use WinRAR Exploit and GitHub PowerShell to Target CIS Governments appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Meta has revealed a breach of a GitHub repository that exposed software code and personal information belonging to about 1,500 individuals, most of whom are U.S. employees. The company began notifying affected individuals on October 13, after discovering the intrusion several weeks earlier, which involved the theft of an employee’s credentials. According to Meta’s statement […]

The post Meta GitHub Repositories Compromised, Exposing Software Code and Employee Personal Data appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Most of the affected individuals are Meta employees in the United States and they are being offered credit monitoring services.

The post Meta Says Hackers Took Code, Personal Data of 1,500 in GitHub Breach appeared first on SecurityWeek.

GeekWire is profiling over the next few weeks some of the people and teams that are shaping the evolution of Microsoft in what we’re calling its “Microsoft 2.5” era.

A delicate dance: In August 2025, Microsoft moved to integrate GitHub into the mothership, under its CoreAI division, after having allowed it to run as a quasi-independent entity since acquiring it in 2018. At the same time, GitHub CEO Thomas Dohmke announced he would leave the company at the end of the year.

A number of developers feared the worst: GitHub would become just another arm of Microsoft and lose the community-mindedness that had made it attractive to developers of all stripes, and especially open-source ones.

GitHub Chief Operating Officer Kyle Daigle — a 13-plus-year GitHub veteran — had been one of the main champions of the need to “keep GitHub GitHub.” He maintained that stance even after he added the “Chief Marketing Officer of Developer” title for all of Microsoft to his COO role in January 2026.

So, how has Microsoft done this past year with managing GitHub? In an interview with GeekWire, Daigle acknowledged that GitHub’s relationship with Microsoft has changed since the end of the standalone CEO era. But the goal is no longer just “don’t break GitHub.” It’s to export GitHub’s community, developer-first ethos and learnings across Microsoft.

GitHub has influence beyond just the GitHub product set now, Daigle said. And the fact that Microsoft opted to consolidate its developer-facing messaging and community outreach under Daigle, someone who came from GitHub, not from Microsoft’s traditional DevDiv organization, gives weight to his claim.

“Bringing teams together — engineering teams and marketing teams and everyone that wasn’t talking to each other before — has been a really big part of the work,” Daigle said. “I see all these opportunities for GitHub to directly help and impact the overall mission of Microsoft versus keeping it cloistered in a way that isn’t helping either GitHub’s mission or Microsoft’s mission.”

These days, developer teams across Microsoft and GitHub are sharing foundations and the GitHub Copilot software development kit across organizations “in a way that would have seemed improbable before,” he said.

As Microsoft historians know, “Microsoft’s challenge isn’t creating products. It’s connecting them,” Daigle said.

Growing pains: At the same time, the rise of AI agents has strained GitHub’s infrastructure. Over the past few months, GitHub has experienced some significant outages, including one in August that lasted nearly eight hours.

GitHub officials have said they are migrating from their own datacenters to Azure to try to ease some of the capacity issues. Daigle said it’s not a simple lift-and-shift process; rather, it’s a major re-architecture for the platform.

GitHub is roughly 60% through its Azure migration as of early October, he said.

It’s working with Azure storage teams on separating compute and storage for the Git distributed version control system to help alleviate bottlenecks caused by developers and agents working concurrently in the same repositories. Developers and agents made 7.38 billion commits on GitHub in September alone, according to the company.

GitHub’s recent growth would not have been manageable without Microsoft scaling expertise and Azure support, Daigle said. GitHub is in a unique position of being able to request major additional capacity, such as millions of CPUs, and work with Microsoft teams to provision it, he said.

The GitHub app and agent store: GitHub got its start as a platform for source control and collaboration. But its role is evolving as part of its Microsoft integration. In addition to developing and supporting Microsoft’s most successful Copilot, GitHub Copilot, GitHub has an important place in Microsoft’s agent-centric strategy.

GitHub is becoming “the store for anything that needs to be coded and needs some verification,” Daigle said. “We’ll connect you to whatever the right tool inside of Microsoft is for you to run that or whatever tool you’re using, not just (from) the Microsoft product suite.”

In the new world order, GitHub isn’t just the store for apps. Increasingly, it’s also the store for agents, which means GitHub is acting as the developer layer for Microsoft’s “agent factory” strategy.

(Microsoft co-founder Bill Gates envisioned Microsoft as a “software factory” that could produce software at scale. These days, CEO Satya Nadella and team talk about Microsoft as an “agent factory,” helping customers create agents at scale.)

GitHub currently serves more than 200 million developers, plus an unknown but quickly growing number of agents.

Developers need to be thinking in new ways when it comes to agents, Daigle said. They need to consider ideas such as scaling application programming interfaces (APIs) for agents separately from humans, creating APIs designed specifically for agents, rewriting documentation and tooling so agents can consume GitHub efficiently, and treating agent access as a fundamentally different workload from human access.

In the longer term, Daigle said he expects AI to make software economically viable for smaller audiences, such as a family, an individual or a single team. The app-store model may change substantially in the coming years, as people create highly specialized applications. GitHub could help like-minded users discover software for specific interests, such as a narrowly focused household or community use case.

GitHub historically has considered anyone who has seen or touched code to be part of the developer community. Daigle’s vision is for GitHub and Microsoft to let both professional developers and newer builders create and run software and agents without needing to manage token costs, uptime, monitoring or operational overhead.

GitHub will have more to say about its plans at the GitHub Universe conference in San Francisco, Oct. 28-29. The event won’t focus on code generation alone; it will include information on tools covering the full lifecycle, proactive security approaches and how to determine whether software is working well after deployment.

“We’re looking to solve the core parts of the platform, like Git, like Actions, in a way that I hope will make people excited and feel like they can absolutely trust GitHub for the next decade to come,” Daigle said.

Roughly 200,000 of the credentials were exposed after GitHub enabled push protections by default.

The post 500,000 Active Credentials Left Exposed on GitHub appeared first on SecurityWeek.

Manifold Security found placeholder domains cited in 359,000 GitHub files and 349 AI agent skills serving cloaked scam…

At Black Hat USA 2026, Novee found GitHub workflow flaws in Claude Code, Gemini CLI and Codex that enabled RCE, credential theft and agent control in pipelines.

Threat actors are increasingly exploiting legitimate cloud services to evade detection and streamline the deployment of their scam infrastructure. Cloud hosting services and decentralized networks have become primary platforms for hosting phishing pages and sites. Throughout 2025 and 2026, we have observed phishing operators steadily migrate toward platforms like Cloudflare Workers, Vercel, Netlify, GitHub Pages, and IPFS. This post analyzes the mechanics of a real-life adversary-in-the-middle (AitM) attack in a cloud environment and presents detailed statistics on the platforms and domains phishers abuse most frequently.

The cloud as a safe haven for phishers

Threat actors select platform-as-a-service (PaaS) offerings and distributed cloud environments to host phishing sites for much the same reasons legitimate software developers do:

• Inherent trust and reputation. Phishing pages hosted on reputable platforms appear trustworthy, reducing suspicion among potential victims.
• Most platforms offer generous free-tier developer plans. The onboarding process takes minutes and rarely requires Know Your Customer (KYC) identity verification. This enables a single operator to create hundreds of malicious accounts.
• Evasion and anonymity. Attackers leverage native security features to obscure their true origin server IP address behind a CDN, which complicates detection for security vendors.

Additionally, these platforms allocate shared subdomains hosting millions of legitimate projects and websites. Security teams cannot simply block the parent domain or its subdomains without inflicting collateral damage on bona fide users – a limitation that malicious actors take advantage of. To counter this tactic, security vendors must advance content-based analysis methodologies.

Multi-stage AitM attack

Consider a modern AitM phishing campaign that leverages Cloudflare Workers, a widely adopted cloud platform. The attackers execute the operation through multiple HTML pages distributed across a compromised website and the cloud platform. Each page serves a specific function: harvesting target email addresses, initializing the reverse-proxy infrastructure, or spoofing the login form to capture multi-factor authentication (MFA) sessions.

Stage 1. Contact harvesting and network monitoring evasion

The attack typically begins with a phishing email that uses a plausible pretext – such as a request from a coworker to review documents – to entice the target into clicking a malicious link.

Upon clicking the link, the user is redirected to a fake CAPTCHA landing page hosted on a compromised legitimate website. This specific campaign used the https://t[REDACTED]e.com website, but any other variations are possible. In this scenario, the compromised page served as a disposable relay — vendor detection mechanisms typically block phishing links delivered directly via email much faster — to prevent the early discovery of the core phishing content hosted on Cloudflare.

If the user entered their email address and clicked Continue, the pseudo-CAPTCHA marked them as a human user and initiated a redirect. The primary objective of this stage is to harvest target email addresses, filter out bots, and route legitimate users to a subdomain of workers.dev. Such subdomains are generated automatically and free of charge by Cloudflare Workers. The victim’s email address was embedded in the URL hash (the part of the URL following the # character), allowing the page at [REDACTED].workers.dev to extract the email without issuing a request to the attacker’s server, thereby avoiding detection.

Stage 2. Initializing a transparent proxy

The user’s browser then loaded a [REDACTED].workers.dev page with #user@business.com at the end of the URL. At this point, the page presented the victim with a genuine CAPTCHA challenge. This step ensured that an actual user was interacting with the page rather than a security sandbox.

Once the user successfully completed the challenge, a service worker was registered in their browser. This is a special JavaScript file capable of running in the background and intercepting all network requests generated by the current tab. As this type of script was designed as a core component of progressive web apps (PWAs) to optimize load times and support offline functionality, browsers treat service workers as standard site feature and execute them without prompting for user consent as long as the website uses an HTTPS connection.

The attackers leveraged the service worker to deploy Ultraviolet, a legitimate open-source web proxy library, to dynamically rewrite all links and forms on the page. This forced every outgoing request – including those for Microsoft login credentials – to route through the attackers’ server rather than directly to the legitimate services.

Immediately upon loading, the page extracted the victim’s email address from the URL hash and stored it in the browser’s sessionStorage property so it would not be overwritten when the CAPTCHA loaded. This step also allowed the script to pre-fill the username field in the form automatically. A pre-populated login field enhanced the page’s credibility and bolstered user trust. Once the CAPTCHA was passed, the malicious script constructed a redirect URL for the third stage, appending the email retrieved from sessionStorage back to the hash. By passing the email via the URL hash across three consecutive stages, the attackers successfully kept it hidden from network attack detection systems.

Stage 3. Session hijacking and browser window spoofing

The final stage unfolded on a third page, combining adversary-in-the-middle (AitM) traffic interception with a browser-in-the-browser (BitB) UI spoofing technique. BitB attacks operate by rendering a block inside a legitimate webpage that visually mimics a native browser pop-up window.

In this case, the script hosted on the attacker’s page generated a pop-up visually identical to a native browser window, complete with window controls and a spoofed address bar showing a trusted Microsoft URL. Within this simulated window, an iframe loaded the authentic login interface, routed dynamically through the service worker reverse proxy created in Stage 2. When the victim entered their credentials and MFA code into the BitB window, the proxy script intercepted both the credentials and the session tokens. Combining BitB with AitM significantly increases the threat: BitB provides a convincing, trusted visual wrapper (displaying a legitimate URL and branding), while the hidden AitM proxy quietly handles traffic interception and session hijacking behind the scenes.

Upon successful login, the proxy instructs the interface to close the pop-up and redirect the victim to a generic system error page, such as SessionExpired. This minimizes suspicion: the victim assumes a technical glitch occurred and attempts to log in again, unaware that the attacker already has full access to the session.

Cloud platform phishing attack statistics

We analyzed phishing URLs hosted across popular cloud platforms – including Cloudflare, Netlify, and GitHub Pages – over a 12-month period spanning August 2025 to July 2026. The data below outlines trends in unique third-level domains exploited to deliver phishing content. In total, our security solutions blocked 224,984 unique third-level domains on cloud and decentralized services used in phishing attacks within that timeframe.

Number of unique third-level domains
(download)

Based on this telemetry, we compiled a list of the TOP 10 cloud domains most frequently abused in phishing campaigns over the specified period.

Unsurprisingly, Cloudflare and Vercel emerged as the undisputed leaders: both offer free tiers, automated SSL certificate issuance, and global CDNs. GitHub Pages ranked third. The widespread legitimate use of the github.io domain complicates bulk blocking efforts, as security teams risk limiting access to non-malicious projects.

Decentralized networks also warrant close attention – we posted on this subject in 2023. The ipfs.io and dweb.link domains function as IPFS gateways. The principal risk associated with these platforms is content persistence: even if a specific gateway gets blocked, the phishing page remains accessible via alternative nodes across the network.

The visual website builders Wix and Webflow also ranked among the TOP 10 (eighth and ninth, respectively). These platforms allow low-skilled individuals to build phishing pages rapidly without advanced coding expertise, which significantly lowers the barrier to entry for less capable malicious actors.

 

	Domain	Number of phishing links	Platform
1	pages.dev	24.9%	Cloudflare Pages
2	vercel.app	13.8%	Vercel
3	github.io	13.7%	GitHub Pages
4	netlify.app	10.0%	Netlify
5	dweb.link	7.8%	IPFS gateway
6	ipfs.io	5.3%	IPFS (InterPlanetary File System)
7	workers.dev	2.5%	Cloudflare Workers
8	wixstudio.com	1.9%	Wix Studio
9	webflow.io	1.0%	Webflow
10	azurewebsites.net	1.0%	Microsoft Azure
	Other	17.9%

In total, we identified and neutralized over 390,000 phishing pages hosted across legitimate cloud platforms and decentralized networks (IPFS) over the past 12 months. This data confirms that threat actors actively exploit the implicit trust associated with legitimate PaaS providers (such as Cloudflare Workers, Vercel, Netlify, and GitHub Pages) and IPFS gateways. High domain reputation, generous free tiers, and built-in evasion capabilities enable phishers to deploy multi-stage AitM attacks designed to hijack MFA sessions.

Recommendations

Traditional security controls, such as relying on HTTPS lock icons or reputation-based domain denylists, are inadequate against these attacks. The cloud provider’s apex domain maintains a positive reputation score, while attackers generate malicious subdomains programmatically and at scale.

Effective defense against these threats calls for a layered security posture:

• Exercise caution with unexpected requests, even if they are served from reputable domains or secured with valid SSL/TLS certificates.
• Treat any CAPTCHA interface requiring personal data input as a possible scam. Legitimate CAPTCHA challenges rarely request personally identifiable information, such as email addresses.
• Inspect the URL in the address bar at the very top of the browser window. In BitB attacks, threat actors can render a fake browser pop-up displaying any target URL, even a legitimate one. However, the true address bar – located at the top of the main browser window alongside native navigation controls (Back, Forward, Refresh) – will continue to display the actual attacker-controlled domain.
• Avoid entering credentials in pop-ups you did not expect to see. If a login or MFA form appears without your explicit action, close the tab immediately. Navigate to the intended service manually by entering its address directly into the browser.
• Additional protection can be provided by Kaspersky Secure Mail Gateway for enterprise environments and Kaspersky Premium for personal correspondence. These robust email security solutions neutralize phishing links at the delivery stage before they reach the inbox.

For thirty years, we have measured security operations by the tools we buy. The next decade will measure us by the outcomes we deliver. That shift is already here, and it is being driven by something quietly radical: a repository of AI “skills” that turns the deep expertise of a principal analyst or engineer into a capability any team member can invoke on demand.

I want to talk about what that actually changes for the business, not the bits and bytes underneath it.

The problem every CISO already knows by heart

You are not short on data. You are drowning in it. Endpoint telemetry, identity logs, firewall traffic, cloud control planes, email security, SaaS audit trails. Each one speaks a different language. Each one demands a specialist who knows where the bodies are buried. The talent who can fluently read all of them at once is rare, expensive, and almost certainly already burned out.

So the work stacks up. Alerts wait. Investigations get triaged by whoever is awake. The third repeat of an attack pattern goes unnoticed. The analyst who caught the first two left for a competitor. Your security posture quietly becomes a function of who happens to be on shift.

This is the real cost center in modern security operations: expert human attention, not licenses or infrastructure. There is never enough of it.

What changes when expertise becomes a skill

The ai-siem repo, located on the Sentinel One GitHub community (https://github.com/Sentinel-One/ai-siem/tree/main/plugins/s1-secops-skills), attacks that bottleneck directly. Instead of asking a human to remember how to query log sources, pivot through threat intelligence, correlate findings, and write it all up, each of those steps becomes a skill. Captured once. Available to everyone, every shift, every time.

Disclaimer: This sample script/prompt is community-contributed, open-source content provided “AS IS,” without warranty of any kind. SentinelOne does not certify or endorse it, is not responsible for its accuracy or outputs, and is not liable for any outcomes arising from its use. Test and validate in a non-production environment before use.

The senior analyst’s playbook stops living in one person’s head. It becomes a durable asset owned by the whole organization. That single change cascades into outcomes leadership actually cares about.

The data lake is the foundation nobody’s talking about

Here is the part that makes the rest of it work. It is the most underrated shift in security right now. Skills are useless if the data lives in a dozen disconnected silos. Each has its own query language, retention tier, and price per gigabyte. The reason this whole model becomes possible is the security data lake. A single place where endpoint, identity, network, cloud, email, and your own application logs land together in one queryable substrate, at a cost that doesn’t punish you for keeping data.

This is where SentinelOne’s Singularity Data Lake stops being infrastructure and starts being the differentiator. It was built for streaming AI from day one, not retrofitted onto it. That architecture is what makes an AI analyst viable. Data becomes searchable the moment it arrives. No indexing delay to wait through. Everything stays hot and searchable. All of it. There’s no cold tier to thaw, and no log you quietly dropped because retention got expensive. It scales to petabytes where legacy SIEMs buckle at terabytes. And it does this at more than ten times the query performance, for less than half the cost of the per-gigabyte SIEM model it replaces.

Translate that into outcomes, and the picture is stark. Ingestion, detection, and query that used to take minutes to hours on a legacy SIEM now happen in seconds. More than 2,000 detections run in the stream itself. Threats surface as the data lands, not minutes after it’s stored. That speed is not a nice-to-have. An AI agent is only as fast as the data underneath it. Give it a lake that answers in under a second, and it reasons across your entire estate before you’d have opened one console tab.

That is what breaks the twenty-year SIEM economics. For twenty years, the industry’s answer to “where do we put all the security data” was a SIEM. One that charged so much per gigabyte that teams were forced to drop the very logs they later wished they’d kept. The data lake inverts that math. Keep everything. Query everything. Correlate everything. Let the ingest bill stop dictating your detection strategy. The skills are the brain. The data lake is the nervous system, letting the brain feel the whole body at once, instantly. You cannot have the outcomes below without it.

This is Autonomous Cybersecurity (AI-Native Protection Across the Enterprise) in practice. Autonomous Security Intelligence, ASI, is the intelligence fabric that runs on top of that data. It is not a bolt-on skill pack. It is what turns a queryable lake into an analyst that never sleeps.

Outcome 1: Investigations that took a shift now take minutes

The gathering is the slowest part of any investigation, not the decision: pulling the alert, finding the affected asset, enriching every indicator against external intelligence, sweeping the rest of the fleet for the same fingerprint, and assembling the timeline. That is hours of skilled work that have to happen before anyone can even say “true positive” with confidence.

When those steps run as orchestrated skills, the gathering collapses into minutes. Your analysts spend their judgment on the verdict and the response, which is the part only a human should own. Mean time to detect and mean time to respond stop being aspirational metrics on a slide. They become numbers you can defend to the board.

Outcome 2: A first-year analyst operating at a principal level

This is the one that genuinely reshapes the org chart. When the hard-won method of your best investigator becomes a skill, a junior analyst inherits it directly: the answer, arrived at the right way, with evidence cited, confidence calibrated, and assumptions flagged.

The skills gap that has defined this industry for a decade narrows dramatically. You stop competing for the handful of unicorns who can do everything, because everything is now a shared capability. Tier-one talent does tier-three work. New hires become productive in days, not quarters. And the people you already have stop drowning. That’s how you keep them.

Here is what convinced me that this is real and not a demo. It was not a SOC analyst who proved it first. It was an engineer. Reviewing application logs, they surfaced a genuine fraud case. A true positive lived in business telemetry. No traditional security tool was even watching. Sit with that for a second. People who do not carry a security title, looking at data that never reaches the SIEM, caught actual fraud. That is what happens when investigative expertise stops being gated behind a job description. The capability travels to wherever the data and the curiosity are. Threats that used to hide in the gaps between teams suddenly have nowhere to live.

More impact per analyst and greater control with less fatigue.

Outcome 3: No blind spots, because nothing gets correlated in isolation

Attackers do not respect your tool boundaries. They land in email, execute on the endpoint, move through identity, and leave through the network. A threat that is invisible in one source is often obvious the moment you line it up against three others. The trouble is that lining them up has always required a specialist for each layer. All working in concert, under time pressure, at 3 am.

Cross-source correlation built into the workflow doesn’t depend on who’s in the room. The full attack story assembles itself. You see the chain, not the fragments. The single most dangerous phrase in security operations, “we had the data, we just never connected it,” starts to disappear.

Outcome 4: Every alert arrives with context already attached

A medium-severity alert on a domain controller matters more than a critical one on a throwaway sandbox. Every experienced analyst knows this. Yet most alerts land in the queue as bare indicators with no business context. Someone has to hunt down what the asset is, who owns it, and whether it matters. That manual lookup happens thousands of times a week. It’s where prioritization quietly goes wrong.

When asset enrichment runs autonomously, every log and every alert already carries the device and user context that determines its importance: what the machine is, how critical it is, and whose account is involved. The queue effectively sorts itself by business impact. Analysts stop chasing noise in disposable systems and spend their time where the real risk lies. False-positive fatigue drops, and the genuinely dangerous signal stops getting buried under the trivial. Prioritization by business impact stops being an aspiration and becomes the automatic default.

Outcome 5: Proactive defense, finally, at machine speed

Known-bad signatures catch yesterday’s threats. The adversaries that actually hurt you, the patient ones and the insiders, only ever show up as deviations from normal. A login at an impossible hour. A workstation reaching a destination it’s never touched. A service account suddenly behaving like a human.

Hunting for that kind of anomaly across the entire estate, continuously, has always been a luxury. Reserved for the most mature and best-funded teams. Make it a repeatable skill and proactive hunting stops being a quarterly project you never quite get to. It becomes the default mode of the SOC. You move from reacting to alerts to anticipating the attacker’s next move. That is the whole point of the discipline. Most teams never have the capacity to actually do it.

Outcome 6: A new threat in the headlines becomes a detection the same morning

When a new campaign breaks, the clock starts immediately. The window between “this threat is now public” and “we are protected against it” is pure exposure. Historically, that window has been measured in days or weeks. Someone has to read the intelligence, translate it into detection logic, test it, and push it live. That someone is usually already underwater.

Make detection engineering a skill, and that window collapses to a morning. The moment an emerging threat surfaces, its behavior becomes a live detection rule: validated and deployed across the estate before the first coffee gets cold. Your defenses move at the speed of the threat landscape instead of at the speed of your backlog. Just as importantly, the detection logic your team writes today gets captured and reused. Coverage doesn’t just grow. It compounds.

Outcome 7: New data sources onboarded in minutes, not quarters

Onboarding a new data source has traditionally been a small project: parse the logs, normalize the fields, build the dashboards, write the detections, and wire up the response. Weeks of specialist time have to pass before that source earns its keep. That’s exactly why the backlog of “sources we really should be ingesting” never shrinks.

That math is now broken in your favor. When those steps are packaged as skills, a new feed goes from raw and unreadable to fully operational in minutes: normalized, with detections firing and a dashboard live. Read that again, because it rewrites your roadmap. Every integration you’ve been deferring for budget or bandwidth reasons just got cheap. Cheap enough to do the same day someone asks for it. Coverage stops being a function of how many quarters you can fund. It becomes a function of how fast you can decide.

That is the compounding version of Maximize Efficiency and Effectiveness of Security Operations: coverage that gets cheaper and faster to extend every time you use it.

The economics that should end the conversation

Now brace for the part that makes the CFO lean in. Everyone assumes the AI is the expensive bit. It is the opposite. Bring-your-own-AI on top of the data lake costs peanuts relative to what it replaces and the work it does. The heavy historical spending on security operations was never on intelligence. It was on the ingestion licensing of a legacy SIEM, and the salaries of specialists doing by hand what a skill now does in seconds.

Sit the two columns next to each other. On one side: per-gigabyte SIEM pricing that grows with your business, whether or not it makes you safer. Plus the fully loaded cost of analysts spending their nights on manual gathering. On the other: a data lake built for scale, and an AI layer whose run cost rounds to a rounding error against either line item. The capability goes up and to the right while the cost line stays flat. That’s a different business model for security. It’s a rare case where the cheaper option is also the more capable one.

This is Enable Business Growth and Innovation Safely in dollar terms: the budget fight between “more coverage” and “more efficient spend” disappears, because the same architecture delivers both.

The deeper shift: the SOC stops being a cost center and starts compounding

Here is the part that should excite anyone running a security budget. Every investigation a human does is an effort spent once and largely lost. Every investigation captured as a skill is an effort spent once and reused forever. Your operation stops being a treadmill and starts being an asset that compounds. The work your team does today makes the work tomorrow faster, cheaper, and more consistent.

AI answering faster is the easy headline. The real shift: institutional security expertise stops walking out the door and starts accumulating on the balance sheet.

What I would tell a peer

We have spent a generation buying tools and hoping the outcomes follow. The teams that win the next decade will flip the order. Define the outcomes first. Then make the expertise to achieve them a capability everyone can summon, day or night, junior or senior, first alert or thousandth.

The technology to do this exists now. Our purpose is simple: to give the advantage to those who secure our future. That advantage only counts if it reaches every analyst, not just the ones already fluent in every log source. The organizations that adopt it won’t just be faster. They’ll run a fundamentally different kind of security function: one where the best analyst in the building is available to everyone, all the time, and gets sharper with every case it touches.

The bottleneck was never the data. It was access to expertise. That bottleneck just broke.

If you run a SOC, lead security for your organization, or work the queue every day: how much of your team’s best thinking is locked inside one or two people right now? That is the question worth sitting with this week.

Curious what this looks like in practice for your environment? Come talk it through in our Reddit community, r/SentinelOneXDR. Practitioners there trade real detection logic, ask the SentinelOne team direct questions, and compare notes on what’s actually working in their SOCs.

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

A recovery key was required to unlock the drive.

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a

Introduction

In February 2026, we discovered a set of malicious activities that had been ongoing since late 2025. These activities involved a RAT module written in Go with proxy capabilities, which served as the main stage of the attack. The attack targeted government and diplomatic entities in Southeast Asia and showed a level of sophistication that caught our attention.

During the attack, the main malware, dubbed GoSerpent, received an encrypted argument and started communicating with a remote server. It was also used to deploy further malicious tools to collect sensitive data and dump credentials 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: a new RAT and proxy tool, Stowaway, which resembled the initial malware, as well as an additional stealthy tool to exfiltrate sensitive data collected in the previous few months through network shares.

We found earlier versions of the GoSerpent backdoor used since 2021 against victims in Southeast Asia with relatively simpler code that received command-line arguments in plain text. Even though the newer variant is stealthier, the attackers continued using the simpler version alongside the latest one in their recent attacks.

What makes this threat particularly concerning is the strategic deployment of various tools with sophisticated data collection and exfiltration capabilities.

In this article, we introduce the malicious tools uncovered by us, which have been used since late 2025.

Technical details

Initial phase of the attacks

The initial phase of the attacks involved deployment of the GoSerpent backdoor, followed by additional malicious tools. During this phase, the main goal was to collect sensitive files and store them for future exfiltration, which was done by a data collecting tool, ThumbcacheService. The attackers also needed system credentials to exfiltrate the collected data through network drives at a later stage. This was achieved through a number of credential dumping tools deployed in this phase via the GoSerpent backdoor.

GoSerpent backdoor

The primary weapon in this campaign is the GoSerpent backdoor, a sophisticated Go-based remote access Trojan that has been active since at least 2021, with the most recent variant deployed in 2026.

This malware receives encrypted and base64-encoded command-line arguments containing a C2 server address and communication password, which are decrypted using AES-CBC mode with a fixed IV (31323334353637383930616263646566) and keys derived from predefined strings.

The backdoor connects to command-and-control servers using ChaCha20 encryption for communications, with the SHA256 hash of the communication password serving as the encryption key.

GoSerpent supports multiple C2 commands by receiving special command values. The commands include the following:

Command	Symbol (as derived from corresponding function names)	Description
2BA1	Sync	Respond to the server to show the infection is active
3BA2	Exit	Exit process
4BA3	Ls	Start listening on a port
5BA4	Connect	Connect to a remote server
6BA5	Hello	Create a shell on the infected machine
7BA6	Ul	Upload a file or directory to the server
8BA7	Dl	Download from the server
9BA8	Ss5	Start a SOCKS5 proxy on the infected machine
ABA9	Cl	Close a listening port
CBAB	RF	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. 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. The malware exhibits strong persistence mechanisms and uses filenames that mimic legitimate system processes such as lass.exe and updates.exe to evade detection.

McMx RAT

McMx is a basic Go-based proxy and remote access tool that represents a simpler variant of the GoSerpent backdoor, apparently compiled from a different GitHub repository path.

Unlike the latest variant of GoSerpent, which uses encrypted command-line arguments, McMx receives input parameters from text files in plaintext format — in a way that resembles older versions of GoSerpent. The malware features similar function names with apparent typos present in both tools.

Before executing McMx, attackers manipulate batch files to generate configuration files containing C2 parameters. The patterns observed show the use of echo commands to create configuration files with parameters like remote host addresses, ports, and secret keys. The McMx malware is then deployed with this configuration.

The tool shares core functionalities with GoSerpent, including:

• SOCKS5 proxying
• port forwarding
• file transfer
• remote shell capabilities

Data collection and credential dumping tools

Following initial deployment of the GoSerpent backdoor, attackers typically wait several days before utilizing it to download and execute additional malware components for data collection and credential dumping.

ThumbcacheService

ThumbcacheService is a malicious DLL deployed as a Windows service that functions as a sophisticated file collection mechanism within the GoSerpent ecosystem. The malware employs XOR encryption with a single-byte key of 0x13 for string obfuscation. It decrypts embedded strings and creates a database file named thumbcache_605a.db in the C:\Users\Public\ directory to store collected sensitive files. It specifically targets documents with the following extensions: .doc, .docx, .pdf, .xls and .xlsx.

The targeted files are then archived using 7-Zip and protected with a predefined password @vx0a9n5W2M0c3D6.#, enforcing a 20MB size limit for archives.
The malicious service also monitors the $Recycle.Bin directory for deleted files with the extensions of interest, ensuring comprehensive data collection.

Credential dumping tools

The threat actor deploys the following tools via GoSerpent backdoor to dump credentials:

1. Mimikatz — dumps memory from the LSASS process to extract credential material, including cached credentials and Kerberos tickets.
2. QuarksDumpLocalHash — extracts local account password hashes from the SAM registry hive, allowing for offline password cracking attacks.

These tools work together to maximize information extraction from compromised systems. The stolen credentials were used in later stages of the attack to facilitate the exfiltration of sensitive files collected by ThumbcacheService.

Second stage of the attacks

After the initial phase of the malware deployments, the attackers allowed a few weeks for the ThumbcacheService to silently collect sensitive files without exfiltrating them. In the meantime, the credential dumping tools also continued to steal credentials. In May 2026, the threat actor came back with a set of new tools. The main malware of this round of activity was another Go-based RAT and proxy tool, Stowaway. It was used to deploy the two-stage data exfiltration tool TmcLoader/TmcPayload, which was the last piece of the data theft puzzle.

Stowaway

Stowaway is a proxy and remote access tool compiled from an open-source framework with customized functions to make the infection stealthier. This malware features both network admin and agent capabilities, enabling attackers to establish chained proxy paths across multiple hosts with the following functionalities:

• SOCKS5 proxying
• port forwarding
• reverse tunneling
• remote shell access
• file transfer
• SSH-based tunneling

Communications are transported over TCP, HTTP, or WebSocket channels protected by AES-256-GCM or TLS encryption.
As the next step, the attackers deliver two files to the victim machine via Stowaway:

• TmcLoader with an embedded payload
• {BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db — an encrypted configuration file

TmcLoader/TmcPayload

TmcLoader is a stealthy C++ loader module registered as a Windows service. The malware embeds an encrypted payload dubbed TmcPayload within its .data section, which is decrypted and loaded into the memory space of the svchost process to maintain persistence and avoid detection.

TmcLoader employs dynamic API resolution through a circular XOR encryption, where each byte is XORed with the value of the subsequent byte, combined with Base64 encoding for string obfuscation to hide API names.

The loader creates a unique event to prevent multiple infections on the same system. After that, it extracts and decrypts the embedded TmcPayload. This payload component is responsible for exfiltrating sensitive data from the victim’s machine.

TmcPayload generates a file path from an obfuscated string: C:\Users\Public\Libraries\{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db.

It then checks for the existence of this configuration file. If the file doesn’t exist, it delays execution for a random period of time before rechecking. The configuration file contains encrypted network share credentials and destination paths for data exfiltration. It specifically references the thumbcache_605a.db file created by ThumbcacheService as the file to be exfiltrated, demonstrating the integrated nature of the attack chain.

Toolset integration

What distinguishes this threat actor’s approach is the deliberate integration between different components of their toolset. The chain from ThumbcacheService to TmcLoader/TmcPayload demonstrates sophisticated operational planning:

1. ThumbcacheService: deployed via GoSerpent, collects and archives sensitive files into the thumbcache_605a.db database file.
2. Credential dumping tools: deployed via GoSerpent to retrieve system credentials.
3. Configuration file: delivered via Stowaway, contains credentials and file paths for data exfiltration.
4. TmcLoader/TmcPayload: deployed via Stowaway, reads the configuration file for data exfiltration.
5. Data transfer: using network credentials and destination paths from the configuration file, TmcPayload transfers the exact same thumbcache_605a.db.

This integration shows that the threat actor has carefully orchestrated their tools to work together seamlessly, ensuring that data collected by one component is available for exfiltration by another component.

Infrastructure

The malware operators leverage legitimate hosting providers, including Alibaba Cloud and UCLOUD HK, for their command-and-control infrastructure. The use of legitimate hosting platforms demonstrates operational security awareness, making detection more challenging.
The technical similarities between GoSerpent and the newer Stowaway tools strongly suggest the threat actor’s deep familiarity with network proxy technologies. The consistent use of legitimate domain names as secret keys, with GoSerpent employing www.microsoft.com and www.spacex.com and Stowaway utilizing github.code, indicates a standardized operational methodology.

Attribution

While the exact attribution of the GoSerpent campaign remains uncertain, there are indications of a potential link to the TetrisPhantom threat actor. The similarities in victim targeting, technical capabilities, and operational methodologies suggest a possible connection. However, further investigation is necessary to confirm this association.

Conclusion

The GoSerpent campaign represents a sophisticated and evolving threat to government and diplomatic entities in Southeast Asia. The threat actor’s use of customized tools, such as the GoSerpent backdoor, Stowaway, and TmcLoader, demonstrates a high degree of technical expertise and operational planning. The integration of these tools to collect and exfiltrate sensitive data highlights the actor’s focus on long-term access and intelligence gathering. As the threat landscape continues to shift, it is essential for organizations to remain vigilant and implement robust security measures to detect and prevent such attacks. By understanding the tactics, techniques, and procedures (TTPs) employed by this threat actor, defenders can better prepare themselves to counter similar threats in the future.

Indicators of compromise

File hashes

GoSerpent
EBFFD5A76AAA690BCDB922F82E0BACC5
DC506FF7BB72735444FB3703A6BEE6D8

McMx
D6E86BF8A90E9B632ADD5FA495F97FBC

ThumbcacheService
CB6C4C70A3B171FA3404B8E1A3382116
64E9D1950E42BC98486DFD9919463D1C

Stowaway
CBBB6D483737EA3566726E51752DFF40
7F223EE0716CE2AD56F55D3744419449
19F8BEFCB035F52BF70094E6B4F5779A
846EF7C1C7323849B2A778C5E4CDA162

TmcLoader
D08A059E8B815E3B891505BC8777FC28
93A1569D5D5AB2C4761FEDF84F83709E

C2 IP addresses

152.32.160[.]239
8.220.194[.]108
8.220.214[.]132
8.220.209[.]155
8.220.193[.]189
101.36.104[.]87
144.48.6[.]46
103.138.13[.]30
47.80.22[.]58
152.32.222[.]113
43.106.30[.]226