AI-Assisted Linux Intrusions Combine SysGoRAT, Web Shells and Data Theft

AI-associated code comments, a cross-platform Go backdoor and extensive Linux persistence formed the core of an intrusion operation that Unit 42 tracked as CL-UNK-1211. Activity ran from October 2025 through April 2026 and targeted public-sector organizations and related infrastructure. The operators sought durable access, credentials, email and database contents, while trying to erase traces of their work.

The case stands out less for a single novel exploit than for the breadth of its post-compromise toolkit. The operators combined custom malware with open-source utilities, web shells, credential theft and network pivoting. Several scripts also contained conversational notes that read like explanations generated for a person following instructions. Unit 42 says this material is consistent with code produced using large language models or deployed by an automated AI agent, though it does not establish which process was used.

That distinction matters. The evidence points to AI-assisted payload development, not autonomous control of the full operation. The observed work still involved familiar Linux administration tools, manual targeting decisions and, at times, scripts that would not run as intended.

AI fingerprints in operational scripts

Malicious PHP and shell scripts appeared across the intrusion, handling reconnaissance, persistence and data collection. Rather than conventional comments aimed at future maintainers, some included step-by-step conversational explanations of what the code did. Those annotations are the clearest sign Unit 42 cites for AI involvement.

AI can reduce the effort needed to draft or adapt routine scripts, particularly when operators need variations for different environments. But comments alone cannot show whether a model wrote the code, whether a person edited generated output, or whether an agent executed a prompt-driven workflow. The researchers describe the artifacts as suggestive, not definitive proof of an AI-operated intrusion.

Unit 42 uses “UNK” for activity clusters whose connection to state-backed or criminal activity has not been determined. CL-UNK-1211 is therefore a tracking label, not a conclusion about who was behind the operation. The group’s attribution framework explains how Unit 42 assigns such labels.

Persistence through PHP and Linux access

On compromised Linux servers, the operators deployed a mix of custom and open-source web shells. Unit 42 observed interactive shell activity associated with a php-fpm parent process. A more durable route involved changing PHP configuration: the attackers altered auto_prepend_file values under /etc/php/ and /opt/plesk/php/.

PHP automatically loads a file named in that setting before running other PHP scripts. By pointing the setting at a malicious file, an operator can cause its code to execute repeatedly as PHP applications run. In one observed case, the planted file was /usr/lib/php/plesk_sys_driver.php, named to resemble a routine component. The altered configuration caused it to load persistently. The second directory also contains configuration associated with Plesk, a hosting control panel.

The operators also tried to obtain elevated access. They ran the open-source LinPEAS tool to search for local privilege-escalation opportunities, then used PwnKit, an exploit associated with CVE-2021-4034, in an attempt to gain root privileges. Afterward, they deployed additional binaries intended to retain privileged access.

Reconnaissance scripts scanned for SQL servers, enumerated databases and collected information about users, computers and open shares. A custom Go scanner checked for systems vulnerable to CVE-2025-55182, known as React2Shell. The combination of broad discovery scripts and a scanner aimed at a specific flaw suggests the operators were mapping the environment while also looking for opportunities to extend access.

SysGoRAT and routes across the network

The custom remote-access Trojan Unit 42 named SysGoRAT was first seen under the filename sys-control-client. Written in Go, it can run on Linux and Windows and supports several persistence methods. Its command-and-control connection uses WebSocket at wss://<addr>/ws. The default endpoint is the hardcoded address 104.194.158[.]65:443, though an operator can change it with a command-line parameter.

SysGoRAT supports seven command types, with further actions available through its control mechanism. Its persistence options include six installation methods for cross-platform environments, using filenames chosen to look like legitimate software. The binary itself was also renamed on affected systems, another attempt to blend into ordinary operations.

Access did not depend on the RAT alone. The operators used reverse shells across at least seven command-and-control servers, often running largely in memory through built-in utilities to reduce files left behind. They also used proxy and tunneling tools to route traffic into internal network segments.

One method chained execution across database servers. After using a web shell to place Base64-encoded PHP scripts, the operators enabled command execution on an internal Microsoft SQL Server through XP_CMDSHELL. They then routed commands from the compromised web server through one SQL server to a second server on another subnet, checking connectivity and running operating-system commands on the destination.

For another route, they used sshpass with hard-coded administrative credentials to connect to internal SSH targets. After pivoting, they ran follow-up commands and added a public key to a user’s authorized_keys file. That change provides passwordless shell access for whoever holds the corresponding private key, making it a persistent access path even if a password changes.

These methods show why a compromised web server can become a staging point rather than the final target. Database features, existing credentials and proxy utilities can carry activity across network boundaries, so defenders need visibility into server-to-server connections as well as activity on the initial host.

Credential collection and mailbox searches

The operators used several routes to collect credentials. They replaced users’ .bashrc files with altered versions that included a malicious command. In one case, they created an alias for sudo that intercepted a password before passing it to the legitimate command. The user could proceed without seeing the interception.

Collected passwords were written to a file named Solarwinds.StatusLog.txt, a name intended to resemble activity associated with SolarWinds. Unit 42 says it found no evidence that SolarWinds systems or infrastructure were compromised; the name was used as camouflage, not as an indication of involvement.

In another approach, the operators added code to a PHP login page, apparently within a database authentication routine. When an administrator entered credentials, the added code recorded the username and password. They also searched configuration files and command histories for email, SMTP and database passwords stored in clear text.

Email accounts were useful both as a source of messages and as a path toward linked social-media accounts. The operators enumerated /var/qmail/mailnames/ across several domains and counted messages in selected users’ Maildir/cur/ directories to identify likely targets.

A PHP script named search_social.php searched message headers for social-media-related terms. It presented matching results with the file path, sender, recipient and subject, giving the operators a way to locate relevant messages before collecting them. The intended next step was broader: a Bash script called zip_mails.sh was designed to traverse user directories and compress entire mailboxes, rather than just the matching messages.

That mailbox script contained syntax errors, including a broken variable assignment, and would fail if run as written. This is a useful counterpoint to the operation’s apparent scale: a broad toolkit and AI-like annotations do not guarantee reliable code. Defenders may find failures and inconsistencies, but should not treat them as evidence that other parts of an intrusion are harmless.

Database collection and attempted exfiltration

Unit 42 found indications that the operators intended to take data from multiple databases. They first printed limited samples to the terminal, using SQL TOP clauses to restrict the number of returned rows. They then attempted to write four tables, capped at 100 rows each, into a local SQLite database named dump.sqlite.

After reviewing sample data, they moved toward fuller collection. Commands dumped all rows from the four tables into local CSV files, which the operators compressed before trying to send them to a command-and-control server using netcat. The observed sequence—from small samples to a structured local archive and then a larger export—indicates an effort to inspect and stage data before transmission.

The operators also tried to make outbound transfers resemble ordinary web activity. They used curl to upload data to legitimate file-hosting services rather than relying only on a dedicated command-and-control connection. A separate script searched for WordPress configuration files named wp-config.php, extracted embedded database credentials and attempted to send output to the catbox[.]moe service.

The source describes attempts and intended workflows; it does not establish that every targeted mailbox or database was successfully transferred. In particular, the syntax error in the mailbox-archiving script shows that at least one planned collection step was faulty. The distinction between attempted theft and confirmed theft is important when assessing impact.

Hiding activity and removing evidence

Anti-forensics featured throughout the operation. The attackers ran Bash scripts using pgrep and pkill to try to stop Cortex XDR-related processes. Cortex XDR detected and mitigated those attempts, and telemetry indicated that endpoint protection remained active.

For short-lived scripts, the operators combined execution and deletion in single commands. For files intended to remain in place, they used touch -t to change access and modification times, making malicious files appear older than the intrusion. These timestamps can mislead an investigation if analysts rely on file dates without comparing them with other evidence.

The operators also planted markers that could make the activity look like an authorized security test. One script contained the key RedTeamOps2025, and a created user had the password pentest123. These strings were deceptive indicators, not evidence that a legitimate assessment took place.

After data collection attempts, the operators deleted system logs and other residual files. They ran cleanup scripts that revisited logs and removed files from /tmp/, where malicious scripts had been stored. They then checked whether their own IP addresses had disappeared from log files. This repeated cleanup suggests that concealing traces was part of the operating procedure, not an afterthought.

What defenders can take from the case

The activity spans web application persistence, credential interception, Linux privilege escalation, database pivoting and data staging. No single indicator captures that chain. Practical monitoring should connect changes to PHP configuration with unexpected web-shell execution, shell utilities spawning interactive sessions, unusual database command execution, SSH key changes and outbound transfers to file-hosting services.

Outbound firewall restrictions can limit reverse-shell connections, while endpoint monitoring can flag familiar system utilities being used to create interactive shells. Linux server and database telemetry is especially important here: a web-facing host may be the entry point, but the operators’ objectives extended into mailboxes, internal database servers and other network segments.

Unit 42 reports that Cortex XDR detected and blocked the attempts to terminate its endpoint processes. Palo Alto Networks says it updated detection content in Advanced WildFire and related network services based on the findings. These are vendor descriptions of its own products, rather than independent performance assessments. The broader lesson is to validate that controls cover Linux hosts, database activity and suspicious process behavior, not just known malware files.

Unit 42 also says it used the Cortex Agentic Assistant, powered by Cortex AgentiX, to query investigation data in natural language and help researchers identify context and next steps. That use of AI in analysis is separate from the suspected AI assistance in the attackers’ scripts: the report describes both, but does not claim they are equivalent workflows.

The cluster’s attribution remains unresolved, and the evidence for AI involvement remains based on script artifacts. What is clearer is the operational pattern: familiar tools can be assembled into a broad access-and-theft workflow, while AI may lower the effort required to write some of the glue code. For defenders, the most useful next step is to watch behavior across the full chain—and to treat unusual configuration changes, credential capture and cleanup activity as connected signals.

Unit 42’s technical appendices describe additional SysGoRAT actions, scanning and data-transfer methods. Its broader guidance and incident response services are available through the Unit 42 AI Security Assessment, Unit 42 Frontier AI Defense and Unit 42 Incident Response team.