- Unit 42 reports campaign CL-UNK-1211 against government Linux servers from October 2025 to April 2026. Chatty script comments suggest AI-written code, which Unit 42 presents as an inference.
- In the same campaign, attackers tried to erase logs, backdate files and plant fake red-team markers. Server traces may be incomplete or misleading.
- Review PHP configuration and sudo changes, restrict outbound traffic and copy logs off servers. Keep records of every authorized security test.
Palo Alto Networks' Unit 42 describes a campaign in which the attackers' own scripts explained themselves in plain English, like an assistant briefing a manager. That is one finding. A second sits beside it: the attackers also worked to muddy the evidence. The two should not be merged. Unit 42 points to the code and the pace of work as the AI signs. The evidence tampering follows a long-established anti-forensic playbook, seen in the same campaign.
What Unit 42 reported
Unit 42 tracks the activity as CL-UNK-1211. It targeted government entities and state-affiliated infrastructure. The researchers observed it from October 2025 to April 2026, and it focused on Linux servers.
The attackers ran reconnaissance, kept long-term access and tried to dump databases. Mail servers were a second target. They tried to steal mailboxes and searched inboxes for clues to social media accounts held under government addresses.
Several scripts held conversational, step-by-step notes explaining the code's logic to the operator. Unit 42 says this suggests the code was copied from an AI prompt output or run by an automated AI agent. That is an inference, not proof.
Unit 42 uses the label UNK for clusters it cannot yet tie to a nation-state or to cybercrime. So the report does not say who is behind this.
How the intrusion worked
The attackers placed web shells on Linux servers. A web shell is a small hidden page that lets an intruder run commands through the web server. Some were custom. Others were open-source tools found on GitHub.
To make them stick, the attackers changed a PHP setting called auto_prepend_file across configurations under /etc/php/ and /opt/plesk/php/. Whatever file that setting names runs before every other PHP script. In one case the file was called /usr/lib/php/plesk_sys_driver.php, a name chosen to look like part of the Plesk hosting panel.
They also stole passwords in several ways. They swapped a user's .bashrc file for a copy that aliased the sudo command. Each time someone typed sudo, the alias captured the password, then passed it to the real command. The victim saw nothing odd.
The log file for those passwords was named Solarwinds.StatusLog.txt. Unit 42 has no evidence that SolarWinds was compromised. The attackers borrowed the name to blend in.
A line added to a PHP login page forwarded administrator usernames and passwords to the attackers. They also searched configuration and command-history files for cleartext passwords.
For remote control, they used a Go-based remote access Trojan that Unit 42 named SysGoRAT. It runs on Windows and Linux. It talks to its operator over a WebSocket connection and accepts seven command types.
Fast, but not flawless
On the mail servers, the attackers counted stored emails per user. Then they ran a PHP script, search_social.php, to find social media messages in email headers. They also tried to build a script, zip_mails.sh, to compress whole mailboxes.
That script had syntax errors, including a broken variable assignment, and would have failed. Unit 42 found it that way.
Unit 42 says the attackers used AI to generate, adapt and deploy scripts quickly, with less manual developer effort. The lesson here is about cost. When new code is cheap to produce, one broken script matters less to the attacker. Sloppy output is a weak reason for comfort.
A classic cover-up in the same campaign
Unit 42 calls anti-forensics a core part of the attackers' playbook. The report does not say AI produced these steps. They are familiar techniques.
The attackers tried to delete logs, then ran cleanup scripts. They also tried to confirm that their IP addresses were gone from the remaining logs. They used touch -t to backdate files so they looked older than the attack.
They also tried to plant a false story. One script held the key RedTeamOps2025. They created a user with the password pentest123. Unit 42 says both were meant to make the activity look like an authorized security assessment.
Evidence still survived. Unit 42 observed and analysed the cleanup scripts, the planted markers and the web shells. Even so, traces on a compromised server may be incomplete or misleading.
Unit 42 also saw attempts to stop endpoint protection with pgrep and pkill commands aimed at Cortex XDR processes. Unit 42 says Cortex XDR detected and blocked those attempts. This is a vendor describing its own product, so read it as one company's account.
What leaders should ask
The attack ideas here are not new. Web shells, password theft and log deletion are old tools. What changed, according to Unit 42, is the pace at which payloads can be made and adapted.
Put these questions to your security team:
First, can we see who changes PHP configuration, including auto_prepend_file, and are those changes reviewed? Second, do we alert on new sudo aliases or edits to .bashrc on servers? Third, is outbound traffic restricted, and do we flag standard utilities that open interactive shells? Unit 42 names both as defenses against the reverse shell techniques.
Fourth, are server logs copied off the machine quickly? A copy held elsewhere is out of reach of a local cleanup script. Finally, how would we tell a real red team from a fake one? Check that every authorized test has a record created before it starts.
The attacker's code may now explain itself. The defender's records should be able to do the same.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Palo Alto Networks Unit 42.
