Modern cyberattacks have evolved beyond mass phishing and brute-force attempts on external services. The UAC-0145 campaign, active since at least May 2026 according to CERT-UA, demonstrates a new level of targeted social engineering. The targets are experienced IT professionals—system administrators, developers, and architects with high-level access to corporate infrastructure.
The primary danger lies in the use of legitimate tools masked as real business processes, such as recruitment. When a qualified engineer executes malicious code under the guise of a technical assignment, traditional perimeter defense systems prove ineffective. No IT architecture can completely eliminate the human factor, so security must be built on the architectural limitation of trust in devices and users.
Anatomy of the UAC-0145 attack: how social engineering bypasses technical barriers
The success of the UAC-0145 campaign is based on long-term trust building. Attackers create realistic recruiter profiles, engage in professional correspondence, and conduct video interviews via Zoom. Once the candidate is convinced of the employer's legitimacy, they are sent a "test assignment" with instructions to connect to a test environment.
The technical compromise mechanism is as follows:
- The candidate is asked to download an archive containing software to connect to the infrastructure. These are often modified versions of legitimate WireGuard or SopraVPN clients.
- According to the CERT-UA report, these modified clients support an unauthorized SymmetricKey option. This allows attackers to execute arbitrary PowerShell code on the victim's device or interact with their servers via the cURL utility.
- After execution, the malware establishes persistence by creating scheduled tasks to regularly download additional payloads.
Because the engineer voluntarily installs the software and performs initial authentication, the system often perceives these actions as authorized. This requires CISO teams to shift to a model where the mere fact of a VPN connection is no longer a guarantee of security.
Why perimeter defense is powerless against compromised devices
Traditional corporate security has historically focused on perimeter defense, trusting everything inside the network or connecting via VPN. However, when an employee connects to the infrastructure from a personal (BYOD) or corporate device already running UAC-0145 malware, attackers gain a direct access channel. They use the legitimate session for lateral movement to locate critical databases or repositories.
According to the Cisco Cybersecurity Readiness Index 2025, based on a survey of 8,000 cybersecurity leaders across 30 markets, only 27.7% of companies have a sufficient level of comprehensive readiness for modern threats. Most organizations remain vulnerable precisely due to insufficient control over identity and access within the network.
Transitioning to Zero Trust: implementing contextual access
To counter threats of this level, the architecture must rely on a Zero Trust model. In accordance with Microsoft's IAM (Identity and Access Management) recommendations, identity becomes the primary security perimeter. Trust is not granted by default but is continuously verified.
A basic requirement for protecting sensitive access, according to NIST SP 800-63 Digital Identity Guidelines, is robust multi-factor authentication (MFA). However, MFA will not stop an attacker if the device itself is compromised. Therefore, it is critical to implement contextual access, which verifies:
- Device Health: Connection is permitted only from managed corporate devices (MDM) with an active EDR (Endpoint Detection and Response) solution, as recommended by CERT-UA.
- Network context and geolocation: Analysis of IP addresses, use of authorized VPN pools, and detection of anomalous geolocations.
- Behavioral patterns: Monitoring for atypical activity hours or sudden changes in interaction with application systems.
Matrix of transition from perimeter security to Zero Trust architecture
| Control parameter | Traditional approach (Vulnerable) | Zero Trust approach (Resilient) |
|---|---|---|
| VPN access | Allowed from any device with credentials | Only from managed devices with active EDR and corporate certificate |
| Authentication | Single Sign-On (SSO) without further checks during the session | Continuous contextual verification (IP, device, behavior) |
| User privileges | Broad rights (Admin/Dev) by default on a permanent basis | Just-In-Time access and blast radius limitation via micro-segmentation |
| Action audit | Logging system events in files (can be deleted by an administrator) | Unalterable history (DataHistory) at the application level for every transaction |
The principle of least privilege at the application level
If an attacker bypasses initial barriers and gains network access, the next line of defense is limiting the blast radius. This is achieved through the principle of least privilege directly within business systems.
For reliable access control in an enterprise environment, it is worth using platforms with deeply integrated security models. For example, the low-code platform UnityBase (a joint development by the Intecracy Group alliance; InBase is a key, but not the only developer of the platform) supports access control at the metadata level. In commercial editions (EE/DE), security mechanisms such as Row-Level Security (RLS) and Access Control Lists (ACL) are applied. This allows systems built on the platform—such as the Megapolis.DocNet electronic document management system—to ensure that each user or process receives access exclusively to the data required to perform a specific task.
In such an architecture, even a compromised account with certain administrative privileges will not be able to instantly copy or modify all company databases.
Continuous audit and DataHistory: how to detect anomalies
One of the attacker's key steps after a successful breach is attempting to delete system logs to hide their tracks. Traditional file logs are often vulnerable to manipulation by compromised accounts with high privileges.
The solution is to use unalterable audit tools. Systems based on the UnityBase platform implement a built-in DataHistory mechanism. It automatically records any changes to data, configurations, or access rights directly at the ORM (Object-Relational Mapping) level. This log is protected from modification or deletion, even if the attacker gains access to the system administrator interface.
The availability of an unalterable audit allows cybersecurity officers to:
- Detect atypical changes in access rights to critical domain models.
- Conduct detailed retrospective analysis during incident investigations.
- Automatically export application security events to corporate SIEM (Security Information and Event Management) systems for immediate response.
Infrastructure built on the principles of Zero Trust, multi-factor authentication, and architectural control at the application level creates a deeply layered defense. While it is impossible to guarantee absolute protection against sophisticated attacks like UAC-0145, this approach minimizes the blast radius and prevents the adversary from establishing a persistent, undetected presence in the corporate network.
FAQ
How can a company be protected from UAC-0145 attacks if employees use personal devices (BYOD)?
It is recommended to restrict access to critical corporate resources from unmanaged devices. According to CERT-UA recommendations, access should be granted only from managed devices (MDM) with an active EDR solution and continuous monitoring, or through fully isolated VDI environments with strict contextual access.
Which contextual access parameters are critical for IAM configuration?
Key parameters include device health (presence of a certificate, EDR, OS updates), IP address and geolocation verification, and behavioral factor analysis (connection time, atypical application activity). These factors complement the multi-factor authentication (MFA) requirement according to the NIST SP 800-63 standard.
How can administrator action audits be implemented so that an attacker cannot delete traces of their presence?
It is necessary to use an architecture with an unalterable history of changes at the platform level and centrally transmit logs to an isolated storage (SIEM/WORM). For example, the DataHistory mechanism at the UnityBase platform's ORM level records every transaction, making hidden deletion impossible even with system administrator privileges.