A new campaign attributed to a Sandworm-linked threat actor demonstrates how sophisticated attackers are combining personalized recruitment fraud with trojanized security software to compromise exactly the people organizations trust to administer their infrastructure. The campaign targets system administrators and other IT professionals through apparently legitimate employment opportunities, studies information contained in candidates’ publicly available résumés, conducts realistic recruitment conversations and even arranges video interviews before delivering a malicious technical assignment. Victims are eventually instructed to connect to what appears to be the prospective employer’s corporate VPN using a modified WireGuard client. Instead of merely establishing a secure network connection, the trojanized application executes attacker-controlled code and installs additional malware. The campaign is particularly concerning because it weaponizes behaviours that experienced IT professionals normally consider responsible: evaluating a potential employer, participating in a technical interview and installing VPN software supplied for accessing an isolated test environment. 

The Ukrainian Computer Emergency Response Team attributes the activity to UAC-0145, which it assesses as a sub-cluster associated with Sandworm, also widely tracked as APT44. Sandworm has a long history of operations against governments, telecommunications providers, energy infrastructure and other strategically important organizations, including destructive attacks. Targeting IT professionals through fake recruitment consequently provides the group with a potentially valuable route into organizations that may otherwise have mature perimeter and endpoint security. A compromised system administrator can offer something much more useful than an ordinary employee workstation: access to VPN credentials, administrative consoles, SSH keys, cloud environments, source repositories and knowledge about how critical infrastructure is configured.

The social-engineering preparation in this campaign deserves as much attention as the malware. Attackers reportedly study résumés uploaded to employment websites and use information contained in them to identify suitable targets and build convincing approaches. A message discussing the candidate’s actual technical skills, professional experience and employment interests is considerably harder to dismiss than a generic phishing email. This is the same principle used in business email compromise and executive impersonation, but recruitment provides an unusually effective pretext because candidates expect to communicate with people and domains they have never encountered before.

The attackers initially pose as IT companies or recruiters and then move the discussion to Telegram, where informal communication between recruiters and technology candidates may not appear unusual. A video interview is arranged through Zoom and conducted in English, adding another layer of legitimacy. A victim who has spoken face-to-face with someone claiming to represent an employer is far more likely to trust subsequent technical instructions than someone receiving an unexpected attachment from a stranger.

In one incident observed by CERT-UA, the attackers impersonated international IT company Sopra Steria and used email addresses designed to resemble legitimate Bulgarian operations associated with the company. They also created a look-alike domain that reinforced the appearance of authenticity. This illustrates why users cannot rely exclusively on visual familiarity with a company name or domain. Attackers increasingly register domains that differ subtly from legitimate corporate infrastructure and then surround those domains with enough supporting details that victims rarely inspect them closely.

The technical interview itself becomes the delivery mechanism. Candidates receive an assignment requiring them to connect to a supposed corporate VPN using WireGuard on Windows or Linux. This is an extremely effective pretext for targeting administrators because installing networking software and importing VPN configuration are normal activities during technical testing, consulting assignments and onboarding. Security awareness training that simply warns employees not to open suspicious documents does little when the malicious file is presented as a legitimate tool required to complete a professional task.

The attackers first provide a VPN configuration designed to generate an apparent connection error. The failure creates a natural reason for the recruiter to offer an alternative VPN application, directing the victim toward a modified WireGuard client named SopraVPN hosted through SourceForge. The SourceForge page contains additional references to the attacker-controlled Sopra Steria look-alike domain, making the download appear consistent with the rest of the recruitment process.

This staged failure is a clever social-engineering technique because troubleshooting assistance strengthens the relationship between victim and attacker. Instead of abruptly asking someone to execute an unfamiliar program, the attacker creates a problem and then conveniently provides the solution. The candidate is focused on completing the interview rather than evaluating whether the troubleshooting process itself is malicious.

The trojanized application remains based on WireGuard, which makes it particularly dangerous from a trust perspective. WireGuard is a widely respected VPN technology and is routinely used by technical professionals. The attacker does not need to convince the victim to run something obviously unfamiliar; they need only convince them that this customized client is the employer’s version of software they already recognize.

The malicious client introduces a non-standard configuration parameter named `SymmetricKey`. When processed, this field decrypts embedded content and ultimately executes PowerShell code. This represents an important malware-development strategy: modify legitimate open-source software sufficiently to add malicious functionality while preserving enough of the original behaviour and interface to remain believable to the victim.

On Windows systems, the embedded command creates a scheduled task and downloads an additional payload from attacker-controlled infrastructure. Scheduled tasks provide straightforward persistence because Windows will execute the configured command again according to the attacker’s chosen trigger. The malicious VPN client therefore serves primarily as an initial loader rather than needing to contain every capability required for the intrusion.

The Linux version follows a similar objective but uses tools expected in that environment. It invokes cURL to retrieve another executable from attacker infrastructure through the VPN connection. The cross-platform implementation is particularly relevant because system administrators and DevOps professionals frequently use Linux workstations even when the rest of an enterprise is predominantly Windows-based.

Targeting both Windows and Linux substantially expands the value of the campaign. Linux workstations used by administrators may contain SSH private keys, Kubernetes configuration files, cloud credentials, automation secrets and access to production servers. Compromising one such endpoint can provide an attacker with privileged access that traditional lateral movement from an ordinary employee workstation might take considerably longer to obtain.

CERT-UA also found that the modified WireGuard implementation changes the way Base64 encoding is handled. Instead of using WireGuard’s normal Base64 decoding routine, the malicious version employs a dynamically generated custom alphabet. As a result, embedded strings cannot simply be copied into an ordinary Base64 decoder to reveal their contents.

This kind of modification is intended primarily to slow investigation and automated analysis. Security tools and analysts frequently look for encoded PowerShell or other recognizable payloads and decode them automatically. A custom alphabet means the data still resembles encoded content but requires knowledge of the attacker’s transformation before it becomes readable.

The campaign demonstrates why security teams should inspect behavioural chains rather than depending solely on static signatures. A process resembling WireGuard that unexpectedly launches PowerShell, creates a scheduled task or downloads executable content should be suspicious regardless of whether the installer itself has already been catalogued as malicious. Similarly, a VPN client invoking cURL to retrieve an unrelated executable on Linux is behaviour that deserves scrutiny even when the application carries a convincing name and graphical interface.

Application allowlisting can reduce this risk for corporate devices. Employees should not normally be able to install arbitrary VPN clients simply because a recruiter or third party supplies one. Approved software should come through managed repositories or software-deployment systems where publishers, hashes and versions can be verified centrally.

This is especially important for administrators. Ironically, IT professionals are often given broad local administrative rights because they need flexibility to perform technical work. Attackers deliberately exploit that freedom. A developer or administrator who can install drivers, networking applications and command-line utilities without restriction can also execute a malicious technical assessment with very few security barriers.

Privileged users should therefore operate through managed workstations even when they are technically capable of securing their own devices. Administrative access should originate from dedicated, continuously monitored systems rather than arbitrary personal laptops. This reduces the probability that compromise of a recruitment exercise or unrelated personal activity becomes compromise of production infrastructure.

CERT-UA specifically recommends that telecommunications providers and IT companies restrict corporate-resource access to managed devices protected by EDR and continuous monitoring, including when employees are using personally owned equipment. That recommendation reflects the real objective of the campaign: the attackers are interested not simply in infecting one person’s laptop but in using the professional privileges and connectivity associated with that individual.

Device trust should therefore complement user authentication. Possession of the correct VPN password or MFA token should not automatically allow access from a completely unknown computer. Enterprises can require that remote connections originate from devices enrolled in management, running required endpoint controls and presenting a valid device identity.

This becomes increasingly important because malware on a privileged user’s personal computer can steal legitimate authentication information after the user completes MFA. The organization may see a valid username, password and second factor without realizing that the endpoint performing the authentication is already controlled by an attacker.

Phishing-resistant MFA remains valuable but should not be considered sufficient. If malware executes on the administrator’s machine, attackers may steal active sessions, browser tokens or locally stored SSH and cloud credentials rather than defeating MFA directly. High-value systems need continuous authorization based on device state and session behaviour.

Privileged access should also be separated from everyday activity. Administrators should not browse employment websites, conduct interviews or read ordinary email from the same privileged session used to administer production infrastructure. Separate administrative identities and workstations dramatically reduce the value of compromising the user’s everyday environment.

The campaign also demonstrates why organizations need to consider employees’ activities outside formal corporate workflows. Security policies often concentrate on phishing sent to the company mailbox, while recruiters may approach candidates through LinkedIn, personal email, Telegram or other channels that enterprise mail security cannot inspect. A technically capable employee may consequently receive and execute malware entirely outside the organization’s traditional security controls before later connecting the infected device to corporate resources.

Organizations should establish clear rules for using personal equipment to reach sensitive environments. If personal devices are allowed, access should be strongly limited and isolated. Highly privileged administration should generally require managed corporate endpoints regardless of convenience.

Security awareness for technical personnel also needs to become more sophisticated. IT staff are frequently assumed to be less vulnerable to social engineering because they understand malware and phishing. Attackers compensate by designing scenarios specifically around technical credibility. Asking a system administrator to troubleshoot a VPN connection is vastly more convincing than sending them a fake invoice.

Recruitment-related technical assignments should therefore be treated as untrusted code. Candidates should avoid executing supplied binaries or scripts on machines containing corporate credentials or personal sensitive information. Where testing requires unknown software, it should be performed inside an isolated disposable virtual machine with no access to corporate networks or credentials.

Even virtual machines require caution when the exercise involves VPN software because network configuration can deliberately route traffic in unexpected ways. Host-only or carefully controlled lab environments are preferable, and organizations may wish to provide employees with disposable sandbox environments for analysing unfamiliar software safely.

The malicious use of SourceForge provides another reminder that hosting platform reputation does not establish file trust. GitHub, SourceForge and other legitimate repositories are frequently abused because users recognize the domains and enterprise networks often allow access to them. A file being hosted on a well-known development platform means only that somebody uploaded it there.

Software authenticity needs to be established through publisher signatures, known hashes and trusted distribution channels. A recruiter providing a custom binary should therefore create more suspicion than a recruiter directing the candidate to the official WireGuard project.

Code signing provides useful protection when properly enforced. An unsigned or incorrectly signed VPN client should generate strong warnings, particularly because network software typically operates with significant privileges. Enterprises can configure application-control policies to permit security-sensitive tools only when they are signed by approved publishers.

However, signatures should not be interpreted blindly. Attackers occasionally steal code-signing certificates or obtain certificates under deceptive identities. Signature verification should therefore be combined with checking the expected publisher, download source and version.

DNS and web filtering can provide additional detection around look-alike corporate domains. Newly registered domains resembling major technology companies should receive higher risk scores, particularly when visited immediately before executable downloads. Security systems can detect subtle character substitutions and suspicious domain age more effectively than users reviewing URLs manually.

Recruitment teams themselves can help reduce impersonation risk. Large companies should publish clear information explaining the domains and platforms used for recruitment and stating whether candidates will ever be asked to install proprietary networking software. Candidates can then verify unusual requests through an independently located company contact.

Organizations whose brands are impersonated should monitor for look-alike domains and fake recruitment pages. Rapid takedown will not stop every attacker, but it can reduce the lifetime of infrastructure used to deceive candidates.

The campaign also highlights a broader supply-chain risk involving human talent. Attackers targeting an administrator do not necessarily need to compromise the administrator’s current employer directly. They can approach the individual through an unrelated job opportunity and use the resulting endpoint compromise as an indirect path into the organization.

This resembles conventional third-party compromise at the human level. The employment process exists outside the enterprise’s security boundary, yet the victim’s workstation and credentials connect directly back into that boundary.

Behavioural monitoring after initial infection is therefore essential. Security teams should alert when processes associated with VPN clients launch PowerShell, scheduled-task utilities or unexpected download tools. Parent-child process relationships often reveal malicious activity that file-based detection misses.

Scheduled task creation should receive particular attention on privileged workstations. Legitimate software does create scheduled tasks, but a newly downloaded VPN application immediately creating one and retrieving additional content is a strong anomaly.

On Linux, administrators should monitor unusual outbound connections from command-line download utilities and creation of executable files in temporary or user-writable directories. Process telemetry should identify when a graphical networking application unexpectedly invokes shell commands or cURL.

Network controls can restrict secondary payload delivery. Managed workstations rarely need unrestricted outbound communication to arbitrary newly created domains or IP addresses. Secure web gateways and DNS security can interrupt malware even after initial execution by preventing contact with attacker infrastructure.

EDR remains particularly valuable because the modified VPN client is only the first stage. Detecting persistence, scripting activity and additional payload execution can stop the intrusion even if the original application initially bypasses static antivirus scanning.

Organizations should also review credentials stored on privileged endpoints. SSH keys should use passphrases and hardware-backed authentication where possible, while cloud credentials should be short-lived rather than permanently stored in configuration files. Kubernetes access should similarly use workload or identity-based authentication wherever feasible.

A compromised administrator endpoint should never automatically provide permanent credentials to every system that person manages. Temporary privileged access dramatically reduces the value of credentials stolen during one workstation compromise.

Secrets stored in shell histories, scripts or plaintext configuration files create especially obvious opportunities for malware. Development and operations teams should use secrets-management platforms rather than embedding credentials directly into automation.

The campaign reinforces why privileged access management should focus on the complete administrator workflow. Protecting the target server with strong authentication offers limited benefit if the administrator accesses that server from an endpoint already controlled by Sandworm.

Dedicated privileged-access workstations provide one of the strongest architectural solutions. Ordinary browsing, messaging, personal communications and software testing occur on another system, while administrative devices are restricted to approved management functions.

For smaller organizations unable to maintain separate hardware, virtualization and remote administrative jump hosts can provide partial separation. The objective is to prevent one malicious download from inheriting every privilege associated with the employee.

The campaign also illustrates the convergence between cyber espionage and ordinary criminal social-engineering techniques. Fake job interviews have previously been used by several threat actors because they provide natural opportunities to exchange files, perform technical assignments and build rapport over multiple conversations. State-sponsored groups adopting the same techniques demonstrate that organizations should not assume sophisticated attackers will rely on sophisticated technical exploits when persuasion works more reliably.

Social engineering can bypass expensive perimeter controls because the victim voluntarily executes the attacker’s software. The security architecture must therefore assume that even trained employees occasionally make incorrect trust decisions and limit what one decision can compromise.

The use of a legitimate open-source VPN project as the malware foundation also raises the importance of software provenance. Open-source software itself is not the problem. The security failure occurs when users accept a modified build from an untrusted distributor without verifying whether the binary corresponds to the official project.

Organizations should educate technical users to distinguish between an official open-source project and arbitrary binaries derived from that project. Source code availability does not guarantee that a downloaded executable was built from the published source.

Where practical, software should be retrieved from trusted package repositories or official project channels and verified using published cryptographic signatures or checksums. A bespoke client provided during a recruitment interview should be treated as untrusted regardless of the project from which it claims to derive.

Incident responders discovering SopraVPN or related campaign artifacts should assume more than one-stage infection. The initial binary can create persistence and retrieve additional payloads, meaning deleting the VPN application alone does not restore trust in the endpoint.

Affected systems should be isolated and investigated for scheduled tasks, PowerShell activity, downloaded binaries, unusual network connections and credential access. Privileged credentials present on the system should be considered potentially exposed.

Active sessions should be invalidated, and administrative secrets should be rotated from a known-clean device after containment. If the victim had access to production systems, cloud platforms or source repositories, those environments should be reviewed for subsequent activity originating from the compromised identity.

Because the campaign targets professionals with elevated access, the threshold for rebuilding infected machines should be low. Once unknown second-stage payloads execute with the user’s privileges, proving that every malicious component has been removed may be considerably harder than rebuilding from a trusted corporate image.

Security teams should correlate endpoint activity with authentication logs to determine whether attackers used stolen credentials after infection. Unusual VPN logins, SSH connections, cloud sessions and repository access following the fake interview can reveal how far the intrusion progressed.

The larger lesson from the Sandworm campaign is that the identity of the victim matters as much as the technical vulnerability. Attackers are deliberately targeting the people who know how the organization works and who possess legitimate authority to change it.

System administrators, DevOps engineers and security professionals therefore need protections proportional to their potential blast radius. They should be treated similarly to privileged service accounts: tightly controlled, continuously monitored and separated from unnecessary exposure.

The campaign is also an argument for reducing permanent privilege. If administrators receive elevated authority only when needed and from approved devices, compromising their ordinary workstation provides significantly less immediate value.

Organizations should consider recruitment-themed attacks within their threat models, particularly where employees are attractive targets for nation-state groups. Security teams cannot prevent employees from exploring career opportunities, nor should they attempt to, but they can ensure that personal recruitment activity cannot easily become an enterprise intrusion path.

The safest policy is straightforward: unknown interview software should never be executed on a production administrative workstation, personal devices should not have unrestricted privileged access to corporate infrastructure, and authentication should depend on both user identity and device trust.

WireGuard itself is not compromised by this campaign. The attackers created and distributed a modified client based on the legitimate technology. That distinction matters because replacing or abandoning legitimate WireGuard deployments would not address the underlying issue.

The real security failure being exploited is trust in software supplied through a convincing human interaction. The victim believes the recruiter, therefore trusts the technical assignment, therefore trusts the VPN configuration, and ultimately trusts the binary. Each step appears reasonable in isolation until the complete chain is visible.

Security architecture needs to assume that attackers will increasingly build these chains patiently rather than depending on one obviously malicious email.

The strongest defence is not expecting every administrator to detect every sophisticated fake recruiter. It is ensuring that when one technically capable employee makes one incorrect trust decision, the resulting software still cannot silently obtain persistence, steal privileged credentials and become a route into the enterprise.

Sandworm’s use of a trojanized VPN client makes the irony unusually clear: the victim installs software believing it will provide secure access to somebody else’s corporate network, while the attacker uses that same software to obtain access to the victim’s environment.

Trust in a security tool must come from its provenance, not from the security function written on its label.

Hackers associated with the Russian threat group Sandworm have been targeting system administrators and IT professionals through fake job offers since at least May. [...]

Source: Sandworm hackers target IT pros with trojanized WireGuard VPN client via Bleeping Computer — published 11 Aug 2026.