Technical Breakdown:
1. File Extension & Renaming Patterns
Confirmation of File Extension: .odveta
Renaming Convention: Each file is renamed to the pattern
original_name.ext.email=*[email protected]*id=***.odveta
(The *** section is a short, victim-specific identifier—usually 4–6 upper-case letters or digits—so two machines in the same organisation will share the same ID.)
2. Detection & Outbreak Timeline
- First public samples: mid-January 2022 (earliest uploads to VirusTotal and ID-Ransomware).
- First large-scale outbreaks: February–March 2022 (reported in Western-Europe and North-America).
- Activity still on-going: small waves continue to be reported through 2023/2024, indicating the group is still monetising the build.
3. Primary Attack Vectors
- Phishing e-mails carrying ISO, ZIP or 7-Z attachments that contain a .NET loader (“QueReceptor”) which, in turn, drops the ODVETA payload.
-
Compromised RDP / VPN credentials – brute-forced or bought on underground markets; the actors move laterally with Cobalt-Strike beacons then deploy
odveta.exeviaPsExec. -
Exploitation of unpatched vulnerabilities used to get initial foothold (observed:
– Log4j (CVE-2021-44228) in VMware Horizon / Citrix
– ProxyLogon (CVE-2021-26855) on on-prem Exchange).
After foothold the same lateral movement & PSExec ritual follows.
There is NO evidence that the malware relies on SMB-v1 / EternalBlue propagation; infection is always a manual “hands-on-keyboard” deployment by the affiliates.
Remediation & Recovery Strategies:
1. Prevention
✔ Patch externally facing services immediately (Log4j, Exchange, SonicWall, Fortinet, etc.).
✔ Enforce 2-factor authentication on all remote-access paths (VPN, RDP-gateway, Citrix, Horizon).
✔ Disable or heavily restrict RDP exposure to the Internet; use lock-out & allow-listing.
✔ E-mail gateways: block ISO, IMG, 7-Z, password-protected ZIP, VHD at the perimeter; strip macro-enabled Office docs by policy.
✔ Windows Defender / reputable EDR: activate ASR rules “Block credential stealing”, “Block process creations from Office”, “Block executable files running unless they meet a prevalence, age, or trusted-list criteria”.
✔ Segment networks: separate user-VLAN, server-VLAN, OT; apply L3-L7 deny-all-by-default ACLs.
✔ Maintain at least 3 copies of business-critical data (1 off-line / air-gapped, 1 off-site immutable).
2. Removal (step-by-step)
- Unplug / power-off visibly encrypted machines to limit additional file damage.
-
Start incident from a clean device—collect the ransom note (
HOW_TO_RESTORE_FILES.odveta.txt) and a few encrypted files for later identification. - Rebuild at least ONE completely clean domain controller or management workstation first; isolate it from production LAN (use separate switch or USB-tether to laptop) and create a new, clean admin account.
- Download a quality offline scanner (Kaspersky Rescue Disk, ESET SysRescue, Bitdefender) or boot infected endpoints from Windows PE + portable AV.
- Delete the ransomware binary (usually
%Temp%\odveta.exe,C:\PerfLogs\odveta.exe, orC:\Windows\NTDS\algebra.exe). - Remove persistence:
– Scheduled task\Microsoft\Windows\ upkeep\AlgebraUpdater
– Run-keyHKCU\Software\Microsoft\Windows\CurrentVersion\Run\value “AlgebraEngine”
– WMI Event SubscriptionQuery = “SELECT * FROM __InstanceModificationEvent WITHIN 60 …”
- Update every host to the latest cumulative patch before reconnecting it to the production VLAN.
- Only after every binary, persistence artefact and back-door (Cobalt-Strike) has been eradicated, proceed with data-recovery steps below.
3. File Decryption & Recovery
The ODVETA strain uses Curve25519 + ChaCha20 for file encryption and the private key is stored only on the actor’s server. At the time of writing there is no free public decryptor and the cipher implementation is error-free (no bugs comparable to “EternalPetya” or “DarkSide” that would allow key leakage).
Recovery options:
- Paying the ransom is not recommended (supports criminal enterprise, no guarantee).
- Use clean backups (Veeam, Acronis, Commvault) on air-gapped media; verify the repository was not mounted at the time of infection.
-
Volume-Shadow copies are usually wiped (
vssadmin delete shadows /all) but occasionally one or two survive on servers—check withvssadmin list shadowsor ShadowExplorer before OS reinstall. - File-carving tools (PhotoRec, R-Studio) can recover fragments from pre-allocated disk areas when no backup exists; expect partial success only.
Essential Tools / Patches (all free):
- Exchange – Mar 2021 cumulative (or newer) security rollup.
- VMware Horizon – updater build that disables JNDI look-ups (or move to 22xx).
- Microsoft MSERT, Kaspersky Virus Removal Tool, Emsisoft EDR standalone.
- Cisco, Fortinet, SonicWall advisories (Log4j hot-fixes).
4. Other Critical Information
-
Payment / leak site – the “Odveta” crew publish a staggered countdown on their TOR portal (
http://odvetacomp….onion) and threaten to publish 5% of stolen data each day; this “double-extortion” is one of their key differentiators. -
Data-exfiltration precedes encryption (sometimes up to 3-4 weeks) with Rclone/MEGASync to transfer archives named
archive.<victim_id>.7zto file-hosting services. Assume that even if you restore from backup, confidential files may still be leaked—plan breach notifications accordingly. -
The mailbox address in the extension (
[email protected]) is used only for initial negotiation; if negotiations stall, the operator provides a second ProtonMail address and moves to Tox chat. -
Rejected extensions: ODVETA avoids encrypting files with extensions
.exe,.dll,.sys,.odveta,.coveware,.txt(ransom notes), and paths containingwindows,programdata,program files,boot,tor browser, so the machine remains bootable to allow ransom payment.
Keep calm, prioritise eradication of persistence, restore from clean, verified backups, and treat the event as a data-breach until proven otherwise. Good luck, and stay safe!