A threat cluster targeting government bodies and state-affiliated infrastructure turned a trusted Linux administration routine into a password-stealing trap. Rather than exploit a defect in sudo, the attackers changed shell startup files so that a counterfeit prompt captured a user’s password and then passed it to the genuine command. The requested task still worked, making the theft much easier to overlook.

Unit 42 tracks the related activity as CL-UNK-1211 and observed it between October 2025 and April 2026. The “UNK” label means researchers have not determined whether the cluster belongs to a state-backed group or financially motivated criminals. The evidence supports a coordinated campaign, but not a confident attribution to a named actor or government.

A malicious alias hid inside Bash configuration

The attackers replaced a user’s .bashrc file with a modified version containing an alias for sudo. When the victim entered an administrative command, the alias presented a familiar-looking password request. It saved the submitted secret to an attacker-controlled file before forwarding it to the legitimate utility, preserving the expected behavior and reducing the chance of suspicion.

The stolen credentials were written to a file called Solarwinds.StatusLog.txt, apparently chosen to resemble an ordinary system artifact. Unit 42 found no indication that SolarWinds products or infrastructure were involved. That filename is camouflage, not evidence of a SolarWinds compromise.

This technique is important operationally because a conventional patch cycle will not remove it. There was no flaw in sudo to fix. Responders must inspect user profiles, aliases and startup scripts, compare them with known-good configurations, and determine how the unauthorized change was introduced.

Credential collection extended beyond the command line

The campaign also modified a PHP login page to collect administrator usernames and passwords. Operators searched configuration files and command histories for email, SMTP and database secrets, then examined government mailboxes for messages related to social-media accounts. Researchers observed attempts to archive mailbox contents and retrieve database information, although at least one collection script contained a syntax error and would not have worked as written.

For persistent remote access, the attackers deployed web shells and a custom Go-based remote-access Trojan named SysGoRAT. The malware runs on Linux and Windows, communicates over WebSocket, and supports command execution, interactive shells, file operations and persistence. Binaries used names such as sys-control-client, pip2.7 and ea_install to blend into a system.

AI traces appeared in parts of the toolkit

Several scripts included conversational comments and step-by-step reasoning notes that Unit 42 assessed as consistent with AI-generated code or work performed with an automated coding agent. The toolkit also moved among PHP, JavaScript, Bash and Python and used encoded commands. These characteristics suggest AI helped create or modify parts of the operation; they do not prove that a model independently selected targets or directed the campaign.

The practical lesson is less about novelty than speed and accessibility. An operator can use an assistant to translate techniques between languages, repair scripts and document procedures. Yet the campaign also displayed ordinary mistakes, reinforcing that AI-assisted malicious code can be inconsistent and should be evaluated by behavior, not mystique.

What defenders should inspect

• Compare .bashrc and other shell profiles against approved baselines, looking for unexpected aliases and password-handling logic.
• Review PHP settings, prepend directives and login pages for unauthorized changes.
• Search for suspiciously named binaries, web shells and unusual WebSocket connections from servers.
• Preserve logs and histories during response, especially when evidence suggests timestamp changes or cleanup attempts.
• Rotate exposed administrative, email and database credentials from a trusted system after containment.

The operators tried to stop endpoint-security processes, erase logs and shell history, delete temporary scripts and alter timestamps. They also planted labels such as “RedTeamOps2025” to make activity look authorized. Defenders should verify claimed testing with change records and named owners; a red-team-style marker is not proof of permission. Configuration integrity monitoring, careful privilege review and centralized logs can reveal the kind of tampering that a vulnerability scanner alone will miss.