📅 February 9, 2026 | ⏱ 8 min read | 🔐 Category: Threat Intelligence
For years, most security teams have focused their attention on Windows malware. Meanwhile, a huge amount of the internet, cloud, and backbone infrastructure runs on Linux and quietly gets far less protection.
The operation people are calling “JackMa” and ShadowGuard: TGR‑STA‑1030 is a good example of what that gap looks like. It centers on a Linux rootkit that managed to hide inside critical systems across 37 countries and feed intelligence back to its operators for a long time without anyone noticing.
Names and labels aside, this is a useful case study in how a modern Linux espionage campaign works and what it exposes about common weaknesses in enterprise and infrastructure security.
Note: I am not describing a single public vendor report here, but a composite of techniques and patterns seen across real Linux rootkit operations. Treat “JackMa” and “ShadowGuard” as a realistic example, not an officially branded threat.
What Are JackMa and ShadowGuard, Exactly?
Think of JackMa as the attacker group and ShadowGuard (TGR‑STA‑1030) as their toolkit.
The group’s interest is long‑term espionage. They are not smashing systems with ransomware or defacing websites. They want quiet, ongoing access to:
- Government networks
- Telecom and satellite operators
- Energy, transport, and industrial environments
The tool they use to make that possible is ShadowGuard, a modular Linux rootkit that gives them deep control over compromised servers and appliances while staying almost invisible to normal monitoring.
Once ShadowGuard is in place, JackMa’s operators can watch traffic, steal credentials, and collect sensitive files, often for months or years.
How They Get In
The first step is always the same: find a way onto a Linux system that matters.
In environments hit by ShadowGuard, that usually happens in a few ways:
One common path is vulnerable internet‑facing services. Old web apps, unpatched API gateways, exposed admin panels, forgotten VPN appliances – all of these are fair game. If it is Linux, reachable from the internet, and running unpatched software, it is a target.
Another path is identity theft. If a developer laptop or jump box is compromised, and that machine has SSH keys or saved credentials into production, the attacker can simply log in like any other user. Many organizations still have long‑lived keys and shared accounts that never get rotated.
Every time JackMa lands on a new box, the first action is reconnaissance. They check the kernel version, distribution, installed tools, and the role of the server. If it looks interesting enough, they deploy the rootkit. If not, they may just grab credentials and move on.
Inside the Kernel: How ShadowGuard Hides
ShadowGuard is not just a user space backdoor. It lives inside the Linux kernel.
On most targets, it arrives as a loadable kernel module. On stricter systems, the operators have used tricks like tampering with existing drivers or slipping their code into a modified kernel update. However it lands there, the goal is the same: gain control at the lowest level possible.
Once loaded, ShadowGuard hooks into system functions that deal with:
- Listing processes and files
- Showing network connections
- Managing kernel modules themselves
By intercepting those functions, the rootkit can hide its own files, its controller processes, and even its presence in the module list. To the usual tools you run on Linux (ps, netstat, lsmod), everything looks fine.
The rootkit also includes a covert control channel. That might be a special packet pattern, a hidden TCP port, or a magic value in an otherwise normal looking request. When the operators send the right signal, ShadowGuard wakes up, executes commands, and then goes back to sleep.
All of this is designed to dodge the two things many Linux environments still rely on: simple command line checks and basic syslog messages.
What They Do Once They Are In
JackMa is not interested in every server they touch. They are picky.
On high‑value targets, ShadowGuard is used as a platform for three main jobs.
First, credential theft. By sitting close to the kernel, the rootkit can watch SSH logins, sudo activity, and sometimes even capture credentials used by local services. Those are then used to move laterally across the victim network.
Second, data collection. The operators configure the rootkit to watch specific directories, processes, or network ports. For a foreign ministry, that might be mail servers and document shares. For a telecom, it might focus on management traffic between core routers. For an energy company, it could be SCADA gateways and historian databases.
Third, pivoting. Once they control a Linux box that sits at the junction of multiple networks, they can use it as a stealthy bounce point. From there, they reach systems that are not directly exposed to the internet, including OT networks, internal admin tools, and sensitive databases.
Everything is done slowly and quietly. Data is staged locally, lightly encrypted, and exfiltrated in small bursts that blend into normal traffic. Unless you are looking closely, it just looks like another server doing its job.
Why So Many Organizations Missed It
ShadowGuard is not “unbreakable” malware. It works because it lines up perfectly with how many organizations treat Linux.
Most security programs are mature for Windows endpoints. They have EDR agents, central management, good visibility into process trees, and well rehearsed playbooks.
Linux is often the opposite. Servers are deployed, configured once, then left alone. As long as they answer health checks and serve traffic, nobody looks too closely. There may be some basic logging, but no consistent correlation or deep inspection of what runs on the host.
On top of that, many critical Linux systems are treated like appliances. Think of firewalls, VPN gateways, industrial gateways, or monitoring boxes. They are often “set and forget” devices, updated infrequently, with very limited local security tooling.
ShadowGuard lives in that blind spot. It does not have to beat a full EDR deployment if there is no EDR. It only has to stay below the noise floor created by normal Linux activity.
What You Can Do About Campaigns Like This
You do not need to reverse engineer a rootkit to make life harder for an actor like JackMa. The biggest gains come from closing the most obvious gaps.
Start by identifying which Linux systems really matter. Focus on internet‑facing servers, VPN and SSH gateways, jump hosts, and anything that routes between IT and OT. Those boxes need more attention than a random internal file server.
Next, improve visibility. Turn on and centralize logging for authentication events, unusual process launches, and kernel messages. Even simple alerts on new kernel modules being loaded, or on unexpected SSH logins to critical hosts, can be enough to catch an early stage intrusion.
Finally, tighten how you manage access. Clean up old SSH keys, remove shared accounts, and add strong authentication for any path into sensitive Linux systems. The fewer identities that can get into those boxes, the less room an attacker has to move.
If you have the resources, adding some form of Linux aware endpoint monitoring on the most critical systems is worth the investment. It does not have to mirror everything you do on the Windows side, but it should be enough to spot strange behaviour and unexpected changes at the host level.
Closing Thoughts
JackMa and ShadowGuard are a reminder that advanced attackers go where defenders are least prepared. Right now, in many organizations, that still means Linux servers and appliances at the heart of important systems.
If your business, your customers, or your country depends on Linux infrastructure, then your security program has to grow up there as well. That means logging, monitoring, and hardening at the host level, not just firewalls and scans from the outside.
You do not get to choose whether someone tries to run a rootkit like ShadowGuard in your environment. You do get to choose how easy it is for them to stay.
Written by: Logan Elliott
Cyberix
https://www.cyberixsafe.com
