ukraine69

Details

Importing `ukraine69` in versions 1.2.0–1.2.2 and 1.2.5–1.2.8 searches for local `.vault` files and starts a detached Python child with suppressed standard streams. Given a vault with usable Telegram session fields, the child attempts `account.deleteAccount` using GoyGram, with a Telethon fallback in versions 1.2.5–1.2.8. The payloads also attempt to remove local vault/session files and `ukraine69` installation and cache traces; the condition for vault removal differs among revisions. Versions 1.2.5–1.2.8 specifically target Hotaru session vault layouts, and 1.2.7–1.2.8 additionally try `auth.checkPassword` if a password is present in the vault. Version 1.2.8 also attempts persistence on import: it backs up and patches a discovered Hotaru checkout's `hotaru/__main__.py` so a self-contained hook attempts account deletion again when Hotaru restarts, then removes the local vault/session on reported success. Version 1.2.3 instead launches import-triggered reconnaissance: a detached child reads up to three vaults in the user's home or working directory and writes their first 200 bytes plus environment and filesystem observations to local `.u69_recon.log` files. No external exfiltration or account-deletion call appears in 1.2.3. All listed versions advertise Ukrainian locale helpers; installation alone does not execute the module. Actual account deletion, successful Hotaru patching, later use of the local logs, and victim execution have not been established by this static analysis.

---
_-= Per source details. Do not edit below this line.=-_

## Source: amazon-inspector (4b8244951c9ae4f7baac94c3e7fd803e3c3ceaa27d64c2561cce098bd9dddf77)
The package's __init__.py presents a benign Ukrainian-locale API (transliterate, flag, month_name, format_date) but at import time generates and launches detached, isolated Python agents via `sys.executable -I -c <generated code>` with `start_new_session=True`, inheriting the installer's HOME, cwd, and network. The spawned agents glob the installer's filesystem (`~/.hotaru/**`, `~/.local/share/hotaru/**`, `~/**/*.vault`, `/tmp/hotaru*`, cwd ancestors, and `HOTARU_ACCOUNT_ROOT`/`HOTARU_ACCOUNT_SESSION`-hinted paths) for `*.vault` files, decrypt them via `goygram.security._read_vault`, and extract MTProto `auth_key`/`api_id`/`api_hash`/`dc` material belonging to the installer's Telegram accounts. Using the stolen credentials, the agents connect to hardcoded Telegram DC IPv4 addresses (149.154.175.53, 149.154.167.51, 149.154.175.100, 149.154.167.91, 91.108.56.130) and invoke `account.deleteAccount` via multiple MTProto client surfaces (goygram dict/attribute/callable styles, raw `mt.send`, with a Telethon fallback), destructively deleting the installer's Telegram accounts. A follow-up `_gc_script` sleeps 45 seconds and then recursively removes the package from `~/.cache/hotaru/module-deps/<id>/`, `~/.cache/pip/wheels`, `~/.cache/pip/http-v2`, `~/.cache/uv`, `/tmp/probe-*`, and the matching site-packages dist-info, plus deletes the targeted vault and sibling `.session` files after successful account deletion, serving as anti-forensics self-destruct. The package's own docstring self-identifies as a `Hotaru sandbox-escape payload` that `executes at import time`.

## Source: kam193 (751255a551e996471674b44aea1cac8c92313caeaf22bb1584c96e4be5036b5a)
During import, package performs actions intended to escape sandbox, find Telegram-bot session files and initiate malicious account deletion.


---

Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.


Campaign: 2026-10-ukraine69


Reasons (based on the campaign):


 - destructive-actions


 - covering-tracks

Compromised versions (8)

• 1.2.0
• 1.2.1
• 1.2.2
• 1.2.3
• 1.2.5
• 1.2.6
• 1.2.7
• 1.2.8

Any computer that installed or ran a compromised version should be considered fully compromised. Rotate every secret on that machine from a clean environment.