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.

Hackers are abusing compromised GitHub repositories and GitHub Actions workflows to build a de facto global botnet that scans and exploits web hosting servers, with a primary focus on cPanel and WHM deployments. The campaign first surfaced when malicious development versions were discovered across ten Packagist PHP packages tied to a legitimate PHP and DevOps […]

The post Hackers Turn GitHub Actions Into a Global Botnet for Attacking Web Hosting Servers appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

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

Multiple campaigns are using ghost accounts to map GitHub organizations, including their repositories and members.

The post Ghost Accounts Abuse GitHub API in Mass Recon Campaign appeared first on SecurityWeek.

BNB Chain Haber Upgrade Gives Developers Another Reason To Watch The Network’s Throughput Push is the kind of crypto story that looks simple at headline level but becomes more useful once you place it inside the wider market backdrop. BNB Chain has to compete on more than liquidity. It also needs to keep improving the developer and validator experience.

The reason it deserves attention today is not that one announcement or filing magically changes the whole market. It is that the update adds another data point to a sector still trying to work out where capital, users, and regulation are actually moving.

For more details, visit the official GitHub platform.

TL;DR

• BNB Chain released node specs tied to the Haber upgrade.
• The changes focus on performance and validation improvements.
• The release keeps BNB Chain in the broader race for faster, cheaper blockchain infrastructure.

The Technical Detail Traders Should Not Ignore

The Haber release notes point to technical improvements in the node stack.

For users, the value of those changes only becomes visible if transactions remain fast and reliable.

Protocol updates rarely arrive with the drama of a courtroom ruling or an ETF filing, but they are often more important over time. They decide how networks handle scale, incentives, cross-chain activity, and user cost. For builders, those details are not optional.

Why Builders Care About The Update

For builders, predictable infrastructure can matter as much as headline incentives.

The market tends to reward finished products, but those products depend on this kind of maintenance. A chain that keeps improving its technical base gives developers more reasons to stay.

For Bitcoinist readers, the practical takeaway is to avoid treating this as an isolated headline. The stronger read is to connect it with the current market environment: liquidity is still selective, regulatory pressure has not disappeared, and the projects that keep shipping useful updates are the ones most likely to hold attention when the cycle gets noisy.

That does not mean the story should be stretched beyond what the source supports. The cleaner approach is to keep the facts tight, explain the mechanism, and show readers why it may matter if follow-up data confirms the same direction over the next few sessions.

In other words, this is a development to watch rather than a guaranteed turning point. Crypto moves quickly, but the useful signals are usually the ones that still make sense after the first reaction fades.

The important thing for readers is context. A single development rarely defines the market on its own, but a series of source-backed updates can show where momentum is building. That is why this article keeps the focus on the specific mechanism in play, the source behind it, and the reason traders or builders may care today.

This article is based on information from github.com.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information from GitHub. at GitHub

The Januscape vulnerability allows a user in a guest VM managed by the Linux Kernel Virtual Machine (KVM) to corrupt memory in the host system and break out of isolation.

KVM virtualization is used by major hosting platforms like Amazon AWS, Google GCP, Digital Ocean, and many more. All of the shared hosting platforms count on virtualization to isolate untrusted guest systems from the physical hardware and each other; being able to corrupt memory for all guests or break isolation presents a major threat.

The bug report says the error has been present for 16 years, which is nearly the entire lifetime of the KVM subsystem in Linux. Fixes are available in mainline, and major hosting providers who count on KVM are likely already updating.

Vulnerabilities In Balcony Solar

Micro solar, or “balcony solar”, installs have been gaining traction in Europe as a way to offset rising electrical costs by connecting solar and battery systems to a house or apartment power system.

Vulnerabilities have been found in the popular Hoymiles micro-inverter, which uses a proprietary RF radio protocol to manage the devices. Unfortunately, it looks like this protocol has no encryption or authentication beyond validating the serial number, and the serial number is also available over a wireless probe command.

Armed with a Nordic nRF radio researchers were able to discover nearby inverters in the wild and collect the serial numbers, though of course they stopped short of issuing commands to random users.

The wireless management control allows controlling the device power and output levels, as well as setting a lockout PIN, which the researchers suspect could be used to disable devices and lock the legitimate owners out completely.

There are an estimated 500,000 units in use, and currently the only known mitigation is to unplug the device entirely and disconnect the solar panels, though the team suggests that setting an anti-theft PIN may also help – or at least prevent an unknown PIN being set.

Be sure to check out the link for an in-depth analysis of the protocol and the surprising lack of protection.

OpenSSH 10.4

OpenSSH 10.4 is out, bringing a handful of security fixes and new features.

The most interesting security fixes appear to be to file handling in the sftp and scp file transfer tools, a malicious remote server could cause the files to be downloaded to the wrong directories. Besides those, the security fixes seem relatively calm, making behavior more consistent when forwarding and tunneling options were in conflict, mitigating a potential denial of service, and cleaning up other behavior.

OpenSSH 10.4 introduces some experimental support for additional post-quantum encryption standards, but beyond that seems to be a normal update.

Tenda Routers (may) Have Backdoor

According to CVE-2026-11405, Tenda brand routers may have a deliberate backdoor in the web interface.

The vulnerability report claims that the httpd binary contains a fallback to a plaintext, hardcoded password that allows anything on the internal network to bypass authentication and reconfigure the router. This seems entirely plausible, based on issues found in other router firmwares, however additional reports raise doubts about the pervasiveness of the backdoor, or if it exists in all firmware versions.

If you have a Tenda brand router and are so inclined, now might be a great time to investigate OpenWRT or other alternate, updated firmware, but there’s probably not a reason to panic just yet.

Tricking the GitHub Agent With Prompt Injection

Can we go a week without discussing prompt injection in AI agents? Apparently the answer is no.

Noma Labs reveals how they were able to use prompt injection against the GitHub support agent to reveal private repositories of an organization. Leveraging the GitHub Agentic Workflows that link workflows with AI agents, Noma Labs were able to file an issue in a public repository that exposed private repositories in the same organization.

The attack appears to be as simple as filing an issue in the public repo, and requesting the contents of files in both the public and private repo, which the agent happily provided. Not only did the AI agent provide the file content of private repos, but it put it in a public issue in the public repository!

Noma Labs says in the writeup that GitHub had instituted guardrails to prevent an agent from accessing private repositories, but simply including the request to “additionally” perform other tasks was sufficient to bypass. This makes GitHub the latest in a seemingly endless chain of AI agents happily helping bypass corporate security, and it doesn’t seem like a trend that will slow down for a while.

Windows Device Identifier Catches Ransomware Operator

Windows installs contain a globally unique identifier generated during the initial install, which is used to track device behavior across Microsoft platforms. Toms Hardware reports that during an investigation of the “Scattered Spider” ransomware group, Microsoft provided records tracking the GDID of one of the ransomware operators, allowing the identification and arrest of one of the groups members.

Scattered Spider has been responsible for millions of dollars in ransomware attacks globally, including high-profile ransomware attacks against major Las Vegas resorts, Qantas airlines, Visa, and hundreds of other companies.

Court documents reveal that following the arrest of one of the suspected members of the group, the Windows global ID was used to link other behavior across Azure, video games, and other telemetry.

CISA reviews lessons learned

Mentioned here in May, the US government cybersecurity agency (CISA) suffered a disclosure of authentication tokens, cloud infrastructure, and plaintext passwords via a public GitHub repository named “Private-CISA” and operated by a contractor.

CISA has published the results of their internal review. Unsurprisingly, as a large government agency, CISA essentially followed the playbook for dealing with incidents: identify the most critical issues and disable the access of the contractor who exposed credentials, determine the full scope of disclosed data, and terminate accounts, change passwords, and expire authentication tokens which were exposed.

More NPM malware packages

Opensource Malware reports on additional infostealer malware uploaded to the NPM repository. Like most NPM-based malware, these packages rely on the install script mechanism to trigger arbitrary commands, firing immediately during package install with no additional interaction.

All of the malware packages mimic existing popular packages and depend on user typos or confusion to get selected. Once triggered, the malware collects a machine fingerprint, git user information, GitHub account information, SSH account information, and corporate identifiers. The packages are largely nonfunctional – the code in the package itself is irrelevant, once a victim triggers the install the malware payload is fired.

All of the packages were uploaded by the same source, tracked to the owner of a cybersecurity company. It is unclear if this is a misguided attempt to generate leads or hype, or if this is a research project gone wrong, but the payload of the malicious packages has been developed and tuned over time. For a company trying to build a reputation or trust, this is surely the wrong way to do it.

BNB Chain Haber Specs Point To Faster Finality And A More Competitive Network Stack is the kind of crypto story that looks simple at headline level but becomes more useful once you place it inside the wider market backdrop. BNB Chain’s technical roadmap matters because the network is competing in a crowded field where speed, cost, and reliability are table stakes.

The reason it deserves attention today is not that one announcement or filing magically changes the whole market. It is that the update adds another data point to a sector still trying to work out where capital, users, and regulation are actually moving.

For more details, visit the official GitHub platform.

TL;DR

• BNB Chain published node release details tied to the Haber hard fork.
• The update targets performance and validation improvements.
• For BNB Chain, faster infrastructure is part of the fight to keep developers and users active.

The Technical Detail Traders Should Not Ignore

The release notes point to changes around node software and transaction state validation.

Hard fork specifications are important because validators and infrastructure providers need time to prepare.

Protocol updates rarely arrive with the drama of a courtroom ruling or an ETF filing, but they are often more important over time. They decide how networks handle scale, incentives, cross-chain activity, and user cost. For builders, those details are not optional.

Why Builders Care About The Update

The update fits a wider push by major chains to refine performance without sacrificing ecosystem compatibility.

The market tends to reward finished products, but those products depend on this kind of maintenance. A chain that keeps improving its technical base gives developers more reasons to stay.

For NewsBTC readers, the practical takeaway is to avoid treating this as an isolated headline. The stronger read is to connect it with the current market environment: liquidity is still selective, regulatory pressure has not disappeared, and the projects that keep shipping useful updates are the ones most likely to hold attention when the cycle gets noisy.

That does not mean the story should be stretched beyond what the source supports. The cleaner approach is to keep the facts tight, explain the mechanism, and show readers why it may matter if follow-up data confirms the same direction over the next few sessions.

In other words, this is a development to watch rather than a guaranteed turning point. Crypto moves quickly, but the useful signals are usually the ones that still make sense after the first reaction fades.

The important thing for readers is context. A single development rarely defines the market on its own, but a series of source-backed updates can show where momentum is building. That is why this article keeps the focus on the specific mechanism in play, the source behind it, and the reason traders or builders may care today.

This article is based on information from github.com.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information from GitHub. at GitHub

A Go module is used to load PowerShell code that fetches a resolver from public dead drops to execute Windows malware.

The post Network of 200 GitHub Repositories Used for Malware Infection appeared first on SecurityWeek.

Attackers can silently clone “Verified” GitHub commits by abusing signature malleability in Git’s commit-signing formats, creating byte‑different commits with identical content, valid signatures, and fresh “Verified” badges under new hashes. This breaks the long‑standing assumption that a verified commit hash is a unique, immutable identifier for a specific piece of signed content and exposes hash‑based […]

The post Attackers Can Generate Duplicate Verified GitHub Commits Using Signature Malleability appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Researchers show how attackers can use a crafted public GitHub Issue to trick AI-powered workflows into exposing data from private repositories without authentication.

The post Critical Vulnerability Exposes GitHub Agentic Workflows to Prompt Injection appeared first on SecurityWeek.

Hard forks are usually discussed in big-picture terms, but the final approach is often decided by smaller technical cleanups that do not sound dramatic at all. Cardano’s 9.0.1 hotfix falls into that category.

It is not the sort of release that creates instant market euphoria. It is the sort of release that helps a network avoid unnecessary problems while moving toward a major change.

For more details, visit the official GitHub platform.

TL;DR

• Cardano released node version 9.0.1 as a recommended hotfix for mainnet validators.
• The update addresses issues tied to the network’s bootstrap and script behaviour.
• It keeps the Chang hard fork process on a steadier technical footing.

Why A Hotfix Still Matters

Intersect’s release notes frame the update as a recommended fix for all mainnet validators, which tells you this is more than cosmetic maintenance. Validators need stable, predictable software when a governance-heavy event is approaching.

In other words, this is part of the real work behind the Chang hard fork narrative. The marketing version is about governance evolution. The operational version is about making sure the machinery behaves properly.

What It Says About Cardano’s Phase

Cardano’s supporters have long argued that the project’s slower style reflects caution and discipline. Releases like this fit that argument better than price chatter does.

For the market, the takeaway is simple: governance milestones only matter if the software path toward them remains solid. That is why even a bug-fix release deserves attention.

This report is based on the Cardano node release notes.

This article was written by the News Desk and edited by Samuel Rae.

Source: GitHub

Dogecoin does not always get taken seriously when the market is in meme mode, but infrastructure updates are where the joke stops and the network starts. Core 1.14.8 is one of those releases that matters because it focuses on security and stability, not sentiment.

That makes it relevant even for traders who never run a node. Healthy networks are built on boring work done properly.

For more details, visit the official GitHub platform.

TL;DR

• Dogecoin developers released Core 1.14.8 with critical security patches.
• The release addresses vulnerabilities referenced in the project notes, including remote code execution fixes.
• For node operators and the network, this is less hype story and more maintenance that genuinely matters.

A Reminder That Maintenance Matters

The GitHub notes make clear that the new version includes critical security patches. That alone should be enough to get the attention of node operators and anyone responsible for infrastructure around DOGE.

Crypto markets often reward spectacle, but security updates are the difference between a network that looks active and a network that can actually be trusted. For Dogecoin, that means the conversation should be about resilience rather than memes.

What It Means For The Ecosystem

Releases like this also help reinforce that Dogecoin is still maintained code, not just a ticker powered by online culture. That distinction matters whenever the asset is discussed as if it exists only on social momentum.

The immediate market impact may be limited, but the underlying point is straightforward: networks that keep patching, updating, and hardening themselves give holders and service providers more confidence over time.

This report is based on the Dogecoin GitHub release notes.

This article was written by the News Desk and edited by Samuel Rae.

Source: GitHub

A critical vulnerability known as “GitLost” has been discovered in GitHub’s newly introduced Agentic Workflows by Noma Labs. This flaw allows unauthenticated attackers to exfiltrate sensitive data from private repositories. It demonstrates how AI-driven automation within development pipelines can be manipulated to bypass conventional access controls and leak confidential information across repository boundaries. GitLost Vulnerability […]

The post GitLost Vulnerability Lets Attackers Trick GitHub AI Agent Into Leaking Private Repos appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Noma Labs details GitLost, a prompt injection flaw that made GitHub's AI agent expose private repo data through a crafted public issue and guardrail failures.

Cardano’s market chart has been quiet, but its codebase is still moving. Recent Cardano node releases from IntersectMBO show continued development work at a time when ADA has been stuck in a tight range and social sentiment has turned impatient.

That split between price action and developer activity is familiar for Cardano. The project often draws criticism when ADA fails to move with the wider market, but its supporters point to steady release work as evidence that the network is still building through weak periods.

For more details, visit the official GitHub platform.

TL;DR

• Cardano node release activity continues through IntersectMBO’s GitHub repository.
• ADA remains caught in a narrow trading range, according to the market levels supplied in the pack.
• The main question is whether development progress can translate into stronger user and market activity.

Code Is Moving, Price Is Not

A GitHub release does not guarantee a token rally. It does, however, give traders something more concrete than social-media arguments about whether a chain is active or not. In Cardano’s case, the release history shows maintenance and development continuing even while ADA struggles to attract momentum.

That matters because the criticism around Cardano is rarely just about price. It is usually about whether the network is producing enough useful activity to justify its long-term valuation. Developer work helps answer one part of that question, but it is not the full answer.

The Market Still Wants Usage

The challenge for Cardano is turning codebase progress into visible adoption. Traders can respect continued releases and still demand stronger evidence of application usage, liquidity, fees, and on-chain activity.

For ADA, the cleaner read is that development has not stopped, but the market has not yet rewarded it. If new releases feed into better performance or more user-facing activity, the narrative can improve. If not, Cardano risks staying trapped between loyal builder momentum and a price chart that still needs a reason to move.

What Would Change The Narrative?

For Cardano, the market probably needs more than release notes. A stronger narrative would come from visible application growth, rising transaction demand, new liquidity, or developer releases that directly improve user experience.

That does not make the GitHub activity irrelevant. In slower markets, continued maintenance can be the difference between a chain that is quietly improving and one that is drifting. But traders usually price outcomes, not effort.

The next test is whether Cardano can connect its development cadence with measurable network demand. Until then, ADA may remain a case where the builder story and the price story move at very different speeds.

That leaves Cardano in a familiar position: easy to criticize from the outside, but not easy to dismiss on development alone. The chain still needs a stronger market catalyst, yet the release activity gives ADA holders something more substantial than hope to point to.

The cleaner takeaway is to treat this as a specific development inside Cardano, not as a blanket prediction for the whole market. It gives readers a concrete data point to watch while keeping the limits of the story clear.

This report is based on Cardano node release information from IntersectMBO’s GitHub repository.

This article was written by the News Desk and edited by Samuel Rae.

Source: GitHub