UAC-0145 Fake Recruiters: Verify Before Sharing Access
CERT-UA says the UAC-0145 threat cluster is using job recruitment as a tailored social-engineering channel against Ukrainian IT specialists. The agency says attackers study a candidate's résumé on employment sites, pose as an IT company and approach likely targets such as system administrators and other technical professionals.
Independent reporting describes a fake interview workflow that pushes VPN software capable of executing commands. The lesson is broader than one installer: a plausible recruiter can create enough trust to make unfamiliar software, configuration files and access requests look like normal onboarding.
What the sources establish
CERT-UA attributes the activity to UAC-0145, which it describes as a subcluster of UAC-0002 and associates with the names Sandworm, APT44 and Seashell Blizzard. The primary notice gives ATLAS Business Group as an example of an IT-company identity used in the approach. The attribution should be presented as CERT-UA's assessment, not as an independently proven identity for every message or account.
The Record reports that the campaign has operated since at least May, based on the Ukrainian agency's disclosure. The Hacker News separately reports the use of a VPN-themed payload that can execute commands. These publications are editorially independent, but their central technical account depends on CERT-UA rather than on separate public victim telemetry.
No verified victim count or complete organizational impact is public in the sources reviewed here. Organizations should not convert a campaign warning into a claim that a particular candidate, employer or recruitment platform was breached.
Why technical candidates are valuable targets
A system administrator may legitimately expect a new employer to discuss remote access, device management, VPN connectivity or a technical assessment. That context gives an attacker a believable reason to request installation and creates a path toward credentials, configuration material or access from a device that may also reach the candidate's current employer.
The recruitment channel may sit outside normal corporate controls. A personal mailbox, messaging account or job platform can introduce a file that is later opened on a managed workstation. The trust decision happens before security tooling sees the process: is this recruiter real, does this company control the domain, and is this software actually required?
Do not use recruiter chat as an access-delivery channel
- Verify the organization independently. Navigate to the company's official site yourself and contact a published address or telephone number rather than relying on details supplied in the conversation.
- Confirm the recruiter and interview path. Ask the company to validate the person, role, meeting domain and software requirement through a second channel.
- Keep assessments off production devices. Do not run recruiter- supplied code, installers or VPN clients on a workstation that holds employer sessions, source access, cloud credentials or password-manager data.
- Reject secrets in informal messages. Recovery codes, API keys, SSH keys, VPN profiles and administrator credentials should not be pasted into a job-platform or personal-chat history.
- Use managed distribution after identity is established. An employer should provide approved software and narrow onboarding access through its controlled device and identity workflow, with a named owner and revocation path.
- Escalate unusual pressure. Requests to disable security controls, bypass a warning or install software immediately are reasons to pause and verify, not signs that the candidate is failing a technical test.
Separate identity proof from secret delivery
An encrypted transfer protects content in transit only after the parties decide who should receive it. It cannot prove that a recruiter profile belongs to the claimed company. Recipient verification must happen first, through an independently obtained contact path or a managed corporate identity.
After verification, an expiring one-time link can reduce durable plaintext copies when a legitimate team must deliver a temporary password, enrollment token or recovery code. High-impact credentials should be least-privilege and short-lived; access should be logged without recording the secret itself, then revoked or rotated when onboarding is complete.
This does not make a malicious installer safe. A compromised endpoint can capture a secret before encryption or after decryption, and software capable of command execution can expose active sessions regardless of how a credential arrived. Device trust, software provenance and identity verification remain separate controls.
A compact verification checklist
- Did you obtain the company contact details independently?
- Does the recruiter's identity match a verified corporate channel?
- Is the interview software published and signed by the expected vendor?
- Can the task run in an isolated environment with no employer credentials?
- Does the requested access have a clear owner, scope, expiry and revocation path?
- Would a second employee approve the same handoff after seeing the evidence?
The campaign shows why secure secret sharing begins before encryption. A protected link sent to an attacker is still a successful social-engineering outcome. Verify the person and the channel, isolate untrusted software, and only then deliver the minimum access required for the legitimate task.
