Junior Hacker Used Tailscale and OpenSSH to Keep Access After His C2 Went Offline

The comment below is based on the reported 33-day intrusion into a small French automotive business, during which the attacker used in-memory malware, a keylogger, scheduled tasks, RustDesk, OpenSSH, and Tailscale to maintain multiple access paths. The key lesson is that disabling command-and-control infrastructure does not remove persistence already established inside the victim’s environment. 

The intrusion involving a junior French-speaking hacker demonstrates that an attacker does not need advanced tools, sophisticated exploits, or nation-state resources to cause serious damage. By combining freely available software, basic scripting, persistence mechanisms, and legitimate remote-access tools, the attacker maintained access to compromised systems for more than a month and stole sensitive banking and email credentials.

The incident affected a small French automotive business and provides an unusually detailed view of the attacker’s actions. Researchers were able to reconstruct 339 commands executed over 33 days after discovering that the operator had accidentally exposed his SSH keys, tools, and step-by-step operational notes in an openly accessible storage bucket.

The attacker, who used the handle Poisson, displayed relatively limited technical skill. He repeatedly exposed his own files, used predictable names for cloud storage, failed in many of his attempted commands, and relied heavily on publicly available tools. Despite these mistakes, he still compromised four computers and established several independent methods of maintaining access.

This is an important warning for smaller organizations that assume they are unlikely to be targeted by capable attackers. The technical sophistication of the attacker is often less important than whether the organization has weak visibility, excessive user privileges, limited endpoint monitoring, and inadequate incident-response procedures.

The initial infection chain relied largely on fileless and memory-resident techniques. A VBScript stager introduced a delay intended to avoid automated sandbox analysis and then decrypted a PowerShell loader. That loader downloaded a .NET component that launched a Havoc Demon command-and-control agent directly in memory.

Running malware in memory reduces the number of obvious executable files written to disk and can make traditional file-based antivirus detection less effective. The absence of a permanent malware file does not mean the endpoint is clean, particularly when scripts, PowerShell, process injection, or remote-management tools are involved.

For privilege elevation, the attacker repeatedly used the Windows RunAs function to request administrator access. This was not a silent bypass of User Account Control. It generated a visible consent prompt that required a user to approve the elevation.

On one compromised machine, the attacker reportedly attempted this process many times over two days before succeeding. This suggests that repeated prompts, user confusion, or eventual approval may be enough to turn limited access into administrative control. Security awareness must therefore include unexpected elevation prompts, not only suspicious email links and attachments.

Once elevated, the attacker created a scheduled task configured to run at every user logon with the highest available privileges. He also injected shellcode into Explorer.exe and installed a customized version of RustDesk as an additional remote-access channel.

These mechanisms provided persistence and redundancy. If one implant failed or was removed, the attacker could continue using another. This is a common feature of modern intrusions: command-and-control malware is only one part of the access architecture, not necessarily the attacker’s only route into the system.

The attacker also deployed a simple Python keylogger consisting of approximately 70 lines of code. The keylogger recorded keystrokes to a local file but did not automatically transmit the data to an external server.

Instead, the attacker logged into the victim’s system periodically and manually downloaded the captured file. This low-technology approach reduced continuous network communication that might otherwise have triggered security monitoring.

The stolen information reportedly included banking logins, email passwords, and credentials for government services. For a small business, such information can lead directly to financial fraud, email account takeover, invoice manipulation, identity theft, and further attacks against customers or suppliers.

The attacker also used the Windows powercfg utility to prevent the compromised systems from entering sleep mode. Keeping the computers awake ensured that the keylogger continued capturing activity and that remote-access channels remained available.

Changes to power-management settings may appear operationally insignificant, but in the context of an intrusion they can be a valuable indicator. Security monitoring should consider how legitimate operating-system tools are being used rather than focusing only on whether the tool itself is malicious.

The most significant stage of the attack occurred when the attacker installed OpenSSH Server and Tailscale on a victim’s Windows computer. He then joined the compromised system to his private Tailscale network and configured key-based SSH access and a reverse tunnel.

This created an encrypted remote-access route that did not depend on the attacker’s primary Havoc command-and-control server. It also did not require a publicly exposed inbound port on the victim’s firewall.

Tailscale is a legitimate networking platform that creates encrypted mesh connections between authorized devices. OpenSSH is also a widely trusted administration tool. Neither product was compromised in this incident. The risk arose because the attacker installed and configured them without authorization.

This distinction is essential. Security teams cannot rely only on identifying known malicious software. Legitimate and digitally signed tools may provide attackers with reliable remote access, encrypted communication, file transfer, tunnelling, and persistence capabilities.

The following day, the attacker’s Havoc command-and-control infrastructure went offline. However, access to the victim continued because the Tailscale and OpenSSH route operated independently.

When the Havoc server returned approximately 18 days later, the agents on the compromised systems automatically reconnected. The attacker did not need to compromise the organization again because the original persistence mechanisms had never been fully removed.

This provides the central lesson from the incident: taking down a command-and-control server is not equivalent to removing the attacker from the environment.

Command-and-control infrastructure is simply one communication path. An attacker may also establish VPN connections, SSH access, reverse tunnels, remote-desktop software, scheduled tasks, cloud-management agents, startup scripts, new user accounts, browser sessions, API tokens, or stolen certificates.

Incident responders must therefore investigate the complete access architecture rather than celebrating when one malicious domain or server becomes unreachable. Apparently, disconnecting one telephone does not remove everyone who already has a key to the building.

The attacker later executed another 145 commands after the Havoc infrastructure returned. He examined smart-card and certificate stores, suggesting possible interest in certificate-based authentication, and ran two unidentified executables from an archive named Thales.zip.

The precise purpose of those executables was not established in the published analysis. This uncertainty demonstrates why incomplete telemetry and limited forensic visibility can leave organizations unable to determine the full impact of an intrusion.

The attacker did not deploy ransomware, use credential-dumping tools such as Mimikatz, or conduct significant lateral movement. He also did not appear to steal the business documents he viewed.

However, the absence of ransomware should not be interpreted as a minor incident. Credential theft alone can create substantial financial and operational exposure, particularly when banking, email, and government-service accounts are involved.

An attacker with access to business email can impersonate employees, redirect payments, reset passwords, monitor negotiations, and conduct highly convincing business-email-compromise attacks. Access to banking credentials can lead directly to unauthorized transfers or fraudulent transactions.

The incident also shows that attackers can succeed through persistence and patience even when their technical execution is poor. Poisson reportedly failed at around half of the actions he attempted, yet repeated attempts eventually produced successful privilege elevation and long-term access.

Security controls must therefore detect repeated suspicious behaviour, not only technically successful exploitation. Multiple failed elevation attempts, repeated script execution, unsuccessful remote-tool installations, and recurring connection attempts may collectively reveal an intrusion before the attacker succeeds.

Organizations should alert when OpenSSH Server is installed or enabled on Windows workstations where it is not part of an approved administrative configuration. A standard employee workstation rarely needs to operate as an SSH server.

The appearance of tailscale.exe, RustDesk, Ngrok, remote-management agents, or similar connectivity tools should also be checked against an approved software inventory. Such applications may be entirely legitimate in one environment and highly suspicious in another.

Application allowlisting can prevent employees or compromised processes from installing unauthorized remote-access software. Where legitimate remote-support products are required, organizations should standardize on approved tools and block competing applications.

Security teams should monitor for SSH reverse tunnels, including commands using the -R option to forward remote ports. Reverse tunnels allow attackers to create outbound connections from the victim’s system and then use those connections to reach internal services.

Outbound tunnels are often more difficult to detect than inbound access because they originate from within the trusted network. Egress filtering and application-aware inspection can help identify unauthorized tunnelling protocols and unexpected encrypted connections.

Organizations should also monitor wscript.exe and cscript.exe when they execute VBScript files from temporary folders, user profile directories, download locations, or other staging areas. Script interpreters are legitimate Windows components but are commonly abused to launch malware.

PowerShell activity should be centrally logged and analysed. Obfuscated commands, encoded scripts, downloads from unfamiliar domains, memory-loading behaviour, and attempts to disable security controls should generate alerts.

Scheduled tasks created with the highest privilege level require particular scrutiny, especially when they launch PowerShell, command shells, scripting engines, binaries from user-writable directories, or files with unusual names.

Power-management changes should also be monitored when they occur unexpectedly. Attackers may disable sleep, hibernation, screensavers, or automatic shutdown to ensure that compromised systems remain continuously accessible.

Dynamic DNS services such as DuckDNS can be useful for legitimate purposes but are also regularly abused by attackers because they provide inexpensive and easily changed domain names. Organizations should restrict or monitor access to dynamic DNS services that are not needed for business operations.

The incident reinforces the value of network visibility. The malware operated largely in memory, and many of the attacker’s tools were legitimate, but network behaviour still included connections to command-and-control infrastructure, remote-access services, dynamic DNS domains, and encrypted tunnels.

DNS security, application identification, intrusion prevention, outbound traffic inspection, and behavioural analytics can help detect these connections even when the endpoint files themselves appear legitimate.

Endpoint detection should focus on chains of behaviour rather than isolated process names. A sequence involving VBScript, PowerShell, a .NET loader, process injection, scheduled-task creation, OpenSSH installation, VPN enrolment, and power-setting changes is highly suspicious even when each component individually has a legitimate use.

Least privilege would also have reduced the impact of the attack. Users should not routinely operate with administrative rights, and administrator credentials should not be entered in response to unexplained elevation prompts.

Organizations should implement controls that prevent standard users from installing system services, remote-access applications, VPN clients, and SSH servers without approval. Privileged actions should require controlled administrator workflows and generate central audit events.

Multi-factor authentication should protect email, banking, cloud, VPN, and administrative accounts. However, credentials captured through keylogging may still create risk if authentication sessions, recovery methods, or approval prompts are accessible from the same compromised endpoint.

Phishing-resistant authentication methods, device-bound credentials, conditional access, and hardware-backed keys provide stronger protection than passwords and SMS codes alone.

Once compromise is discovered, affected systems should be isolated from the network, but isolation must be coordinated carefully. Security teams should preserve evidence and identify all persistence mechanisms before rebuilding or returning the system to service.

Investigators should review installed services, VPN clients, SSH configurations, scheduled tasks, startup entries, authorized SSH keys, local and domain accounts, remote-management tools, browser sessions, certificates, API tokens, and network routes.

Credentials accessed or entered on the compromised computer should be considered exposed. Passwords, SSH keys, certificates, banking credentials, email sessions, and cloud tokens should be revoked or rotated from a separate trusted device.

Merely deleting the initial malware or blocking its command-and-control domain is insufficient. The organization must determine whether alternate access paths remain and whether the attacker compromised additional systems or identities.

Where system integrity cannot be established confidently, rebuilding the endpoint from a verified image is safer than attempting selective cleanup. Restoring an unverified system may preserve hidden services, keys, tunnels, or persistence mechanisms.

For smaller organizations, this incident demonstrates the importance of basic security discipline. Advanced threat-hunting teams may not be available, but practical controls can still make a substantial difference.

These controls include maintaining an approved application inventory, restricting administrator access, enabling endpoint monitoring, centralizing logs, filtering outbound traffic, using strong authentication, patching systems, backing up critical data, and having a documented incident-response process.

Managed security services may be appropriate where internal teams cannot monitor endpoints and network activity continuously. Attackers do not adjust their working hours to match the victim’s IT support schedule, an arrangement they inconsiderately failed to coordinate.

The wider lesson is that legitimate remote-access and networking tools are becoming standard parts of attacker persistence. Their signed binaries and encrypted traffic allow them to blend into ordinary administrative activity.

Security teams must therefore understand what tools are expected on each device, who installed them, which accounts control them, and what external networks they join. Zero-trust access technology does not provide zero-trust outcomes when an attacker is permitted to enrol a compromised device into the attacker’s own trusted network.

The incident also challenges the assumption that only sophisticated threat actors can establish resilient access. Poisson was inexperienced, made repeated operational mistakes, and used inexpensive infrastructure, yet still maintained access through multiple channels.

Attackers do not need to succeed elegantly. They only need to succeed once and remain unnoticed long enough to collect useful information.

For customers, the central takeaway is that incident response must focus on removing access, not merely disabling malware infrastructure. Every compromised system should be examined for alternate tunnels, legitimate remote tools, scheduled persistence, stolen keys, and unauthorized accounts.

The Havoc server going offline did not end this intrusion because OpenSSH, Tailscale, RustDesk, scheduled tasks, and the keylogger remained in place. The command-and-control server was not the compromise itself; it was only one of several doors.

Effective defence requires endpoint, network, identity, and behavioural controls working together. When an attacker can replace a failed malware channel with a legitimate encrypted service, security teams must detect the unauthorized behaviour rather than depend on recognizing a malicious file.

The uncomfortable lesson is that resilience is not limited to defenders. Even an inexperienced attacker can build redundant access using ordinary tools. Organizations must therefore assume that every confirmed intrusion may contain more than one persistence mechanism and continue investigating until all routes back into the environment have been identified and removed.

A French-speaking attacker broke into a small French automotive business, planted a keylogger, and stole banking and email credentials. Ordinary stuff, until one move near the end. Before his command-and-control server went dark, he installed OpenSSH and Tailscale on a victim's machine, building a way back in that did not run through the C2 at all. When the Havoc server went offline the next

Source: Junior Hacker Used Tailscale and OpenSSH to Keep Access After His C2 Went Offline via The Hacker News — published 17 Jun 2026.