Rhysida in Germany - From an Early Ransomware Payload to the 2026 Stuttgart and Berlin Threat Landscape
Technical analysis, threat profiling, and hunting opportunities for the Vanilla Tempest / Rhysida ecosystem
In May 2026, Rhysida listed the city of Stuttgart on its data-leak site and demanded 5 BTC. Three months later, Berlin disclosed a significantly more serious compromise of parts of its state administration, with confirmed data exfiltration occurring before affected systems were disconnected from the Berlin state network. The technical details publicly available for the two incidents are very different.
Stuttgart initially stated that it had no evidence confirming a cyber incident. The Rhysida leak-site entry therefore has to be treated as an attacker claim rather than proof of a particular intrusion chain. Public reporting dates the listing to 19 May 2026 and describes an extortion demand of five Bitcoin.
Berlin is different. The State of Berlin confirmed that data exfiltration occurred between 7 and 12 August 2026, before affected Senate administrations were disconnected from the state network on 14 August. Forensic investigations subsequently found additional data loss.
Leaked via https://x.com/DerKaterX/status/2095873457716109522/photo/1There are currently no publicly confirmed Stuttgart- or Berlin-specific Rhysida payload hashes or C2 addresses in the authoritative reporting reviewed for this analysis. What we do have, however, is increasingly detailed visibility into the wider Vanilla Tempest → Rhysida ecosystem, including malicious code signing, fake software installers, Endico, Broomstick/Oyster, Vidar, Supper, and infrastructure active close to the Stuttgart timeframe.
That gives defenders something more valuable than a single ransomware hash. A chain of behaviors to hunt before impact.
Starting point is the Rhysida sample
The sample that triggered this investigation is:
SHA-256
67a78b39e760e3460a135a7e4fa096ab6ce6b013658103890c866d9401928ba5
FortiGuard independently lists this exact hash as Rhysida ransomware.
It belongs to the early generation of Rhysida binaries first observed in 2023. That matters because the ransomware payload itself should not be confused with the much more dynamic intrusion infrastructure now surrounding it.
Technically, early Rhysida binaries are Windows PE executables compiled using MinGW and make use of LibTomCrypt for cryptographic operations. Avast’s reverse engineering provides one of the clearest descriptions of the actual encryption implementation. Contrary to simplified descriptions that sometimes state that Rhysida encrypts files directly using ChaCha20, ChaCha20 is used as the pseudo-random-number generator. File data itself is encrypted with AES-256 in CTR mode. Per-file AES keys and IVs are then protected using RSA-4096 with OAEP padding.
The encryptor supports several command-line options, including:
-d encrypt a specified directory
-sr self-remove after encryption
-nobg do not modify the desktop background
-S create a scheduled task running as SYSTEM
-md5 calculate an MD5 for files before encryption
Rhysida also implements partial encryption for larger files. Rather than encrypting an entire multi-gigabyte file, the malware divides larger files into blocks and encrypts selected portions. This is a familiar ransomware optimization: the goal is not cryptographic elegance but maximum operational damage in minimum time.
Characteristic impact artifacts remain:
Encrypted extension:
.rhysida
Ransom note:
CriticalBreachDetected.pdf
The ransom-note filename and extension are useful high-confidence endpoint indicators, although at that stage the defender is already very late in the attack chain.
Why the 2023 encryptor is no longer the most interesting artifact
IBM X-Force tracks Rhysida actors using a combination of Endico downloader, Broomstick/Oyster, Supper and the Tomb crypter. Microsoft separately tracks one important Rhysida-associated threat cluster as Vanilla Tempest.
The result is a modular cybercrime ecosystem rather than a single self-contained ransomware operation.
A simplified representation looks like this:
User searches for trusted software
│
▼
Malvertising / SEO poisoning
│
▼
Trojanized, fraudulently signed installer
│
▼
Endico downloader
protected by Tomb
│
▼
Broomstick / Oyster
│
┌────┴────┐
▼ ▼
Vidar Supper
│
▼
Hands-on-keyboard
post-exploitation
│
▼
Rhysida deployment
Every stage above potentially produces telemetry before encryption begins.
Fox Tempest changed the trust problem
Microsoft’s May 2026 investigation into Fox Tempest adds another layer to the Rhysida ecosystem.
Fox Tempest operated what Microsoft describes as a malware-signing-as-a-service operation. Instead of simply distributing unsigned malware and hoping endpoint security missed it, customers could submit malicious binaries and receive files signed with fraudulently obtained certificates.
Microsoft says Fox Tempest created more than one thousand certificates and hundreds of Azure tenants and subscriptions. The service abused Microsoft’s Artifact Signing infrastructure to make malicious executables appear trustworthy.
This is significant because signing is normally part of a defender’s trust model.
Fox Tempest’s service operated through:
signspace[.]cloud
Microsoft reports that Vanilla Tempest began using the service as early as June 2025. Vanilla Tempest submitted malicious payloads including trojanized Microsoft Teams installers, which were then distributed through legitimate advertising and fraudulent download pages. Execution could deploy the Oyster backdoor, and Microsoft observed Rhysida ransomware later in some of the same attack flows.
Source https://www.microsoft.com/en-us/security/blog/2026/05/19/exposing-fox-tempest-a-malware-signing-service-operation/Relevant Fox Tempest hunting indicators include
Microsoft last observed
signspace[.]cloud
11af4566539ad3224e968194c7a9ad7b596460d8f6e423fc62d1ea5fc0724326
f0a6b89ec7eee83274cd484cea526b970a3ef28038799b0a5774bb33c5793b55
These are Fox Tempest ecosystem indicators, not Stuttgart IOCs. The dates nevertheless make them interesting for retrospective hunting around the Stuttgart event because Fox Tempest activity was still being observed immediately before Stuttgart appeared on Rhysida’s leak site on 19 May.
Temporal correlation is a hunting lead. It is not attribution!
The Rhysida infection chain: fake Teams to Broomstick
IBM X-Force documented a particularly useful late-2025 Rhysida-related infection chain.
A malicious Microsoft Teams installer was delivered from:
microsoft-teams[.]icu/files/MSteamsV7.80.exe
The installer was signed under the name:
LES LOGICIELS SYSTAMEX INC.
The Tomb-protected Endico downloader then retrieved Broomstick/Oyster from:
scs-techresources[.]com
and created persistence through a scheduled task called:
AlphaSecurity
IBM observed these Broomstick SHA-256 hashes:
0edfad6a8b34b2b419fd254a99394b8f2303d144dbeba7148ef5343e2929fe76
f34cfdc950124d26b4f2f99b192a4ab7a4163af3143c3b18bc2271ca08d6c899
Broomstick then communicated with:
coretether[.]com
nucleusgate[.]com
registrywave[.]com
Approximately three minutes later, IBM observed deployment of a Tomb-protected Vidar infostealer:
55a02d14de13134e77eb9cc787ac622791b38b74931d1588bb5750b06951c8c0
A Supper backdoor followed shortly afterwards.
This is exactly why a “Rhysida IOC list” that contains only ransomware hashes is strategically weak.
By the time the ransomware binary exists on disk, the attacker may already have performed reconnaissance, credential theft, persistence, lateral movement and data theft.
Supper: one of the most interesting hunting pivots
Supper deserves particular attention because it provides operators with persistent post-compromise access.
In IBM’s analyzed Rhysida chain, the first observed Supper instance communicated with:
151.241.99[.]169:8080
46.183.25[.]6:1080
213.139.77[.]167:4043
Five days later the operators deployed a second Tomb-protected Supper sample:
604f7aa77a14f07baa21e76b73ceb7970037bfbdcc2040bf2e445702e99587a0
That variant communicated with:
193.104.58[.]42:8080
5.226.141[.]216:1080
178.32.224[.]221:4043
IBM’s IOC repository provides an even more interesting temporal pivot for German defenders.
The repository identifies the following as a Supper C2 observed in May 2026:
213.232.236[.]211:80
and several additional Supper addresses from April:
185.233.166[.]26:8443
194.61.120[.]130:443
37.72.168[.]146:53
38.134.148[.]147:443
51.222.96[.]58:1080
51.222.96[.]58:4043
51.222.96[.]58:8080
95.169.180[.]113:80
IBM explicitly labels the first address as May 2026 and the others above as April 2026 Supper infrastructure.
This creates a useful retrospective hunting window for Stuttgart:
1 April 2026 ────────────── 19 May 2026 ───── 31 May 2026
│ │
│ └─ Rhysida leak-site listing
│
├─ April Supper infrastructure
│
├─ Fox Tempest signer activity
│
└─ May Supper C2
Again, none of these indicators proves that Stuttgart communicated with Supper infrastructure.
But if historical Stuttgart telemetry produced a match to 213.232.236[.]211:80, a Fox Tempest signing certificate, an AlphaSecurity scheduled task, or a known Broomstick hash, that would materially change the investigation.
Hunt the commands, not just the C2
IP addresses can expire and domains disappear.
Certificates get revoked and o perator behavior usually changes more slowly. One of the strongest pieces of defensive intelligence in IBM’s reporting is the actual command sequence issued through Supper.
The operators used PowerShell and native Windows utilities to identify the domain, enumerate machines, discover domain controllers and examine privileged groups. Observed commands included variants of:
net user <username> /domain
systeminfo
ipconfig
nltest /dclist:<domain>
nltest /trusted_domains
nltest /domain_trusts
net group "domain admins" /domain
net group "domain computers" /domain
net localgroup administrators
hostname
IBM also observed PowerShell using:
DirectoryServices.DirectorySearcher
to enumerate domain computers.
None of those commands is malicious on its own.
The detection value lies in density and sequence.
Consider a workstation on which, within ten minutes, the following appears:
powershell.exe
↓
DirectoryServices.DirectorySearcher
↓
nltest /trusted_domains
↓
nltest /dclist
↓
net group "domain computers" /domain
↓
net group "domain admins" /domain
That is much more valuable than an alert that simply says:
nltest.exe executed
The first describes adversary behavior.
The second describes Windows.
Berlin changes the threat profile
The Berlin incident materially changes how Rhysida should be prioritized by German public-sector defenders.
The State of Berlin confirmed that data was exfiltrated between 7 and 12 August 2026 and that affected administrations were separated from the state network on 14 August. The forensic investigation subsequently identified additional exfiltration.
Which host suddenly performed domain discovery?
Which previously unseen external destination received traffic?
Which systems created large archive files?
Which remote-management software appeared shortly before the exfiltration?
Which administrative accounts moved laterally?
Which servers transferred unusually large data volumes between 7 and 12 August?
Applying threat profiling rather than IOC collecting
Adversary Behavioral Threat Profiling approach provides a useful framework here.
The process starts with organizational context, identifies relevant adversaries and capabilities, maps those capabilities to ATT&CK, quantifies the threats and then translates the prioritized behaviors into defensive action.
For German public administration, Stuttgart and Berlin change the proximity dimension.
Rhysida is no longer simply an international ransomware family with generic public-sector targeting. Berlin demonstrates direct impact against German state administration, while Stuttgart provides another nearby extortion claim.
The Tidal guide also introduces the useful concept of capability density: techniques recurring across multiple actors, campaigns and malware components should generally receive more defensive weight than isolated indicators.
Applied to Rhysida, the dense behaviors are ATT&CK TTPs:
- T1036 Trusted-software masquerading
- T1553.002 Code-signing trust abuse
- T1059.001 PowerShell
- T1053.005 Scheduled task persistence
- T1087.002 Domain account discovery
- 1069.002 Domain group discovery
- T1482 Domain trust discovery
- T1082 System information discovery
- T1016 Network configuration discovery
- T1490 Inhibit system recovery
- T1486 Data encrypted for impact
- T1070.001Windows event-log clearing
Detection opportunity 1: AlphaSecurity
The AlphaSecurity scheduled task is unusually specific and therefore worth hunting directly.
A simple Sigma-style analytic could look like:
title: Rhysida Related AlphaSecurity Scheduled Task
status: experimental
logsource:
category: process_creation
product: windows
detection:
process:
Image|endswith:
- '\schtasks.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\cmd.exe'
indicator:
CommandLine|contains: 'AlphaSecurity'
condition: process and indicator
falsepositives:
- Legitimate internal software using the same task name
level: critical
tags:
- attack.persistence
- attack.t1053.005
A production deployment should also inspect Task Scheduler Operational logs rather than relying only on process creation.
Detection opportunity 2: fake Teams execution
A genuine Teams installer should not routinely launch suspicious LOLBins from a user’s Downloads directory.
A useful correlation is:
MSTeamsSetup.exe / MSteamsV7.80.exe
│
▼
powershell.exe / cmd.exe
│
▼
rundll32 / regsvr32 / mshta
│
▼
scheduled task
The strongest version of the detection additionally evaluates download origin and Authenticode metadata.
The crucial lesson from Fox Tempest is that:
Signed == trusted
is no longer a safe detection assumption.
A better model is:
signed
+
rare signer
+
recent certificate
+
user-download location
+
unexpected child process
+
unusual network destination
=
high-confidence suspicious execution
Detection opportunity 3: Active Directory discovery burst
For Microsoft Defender XDR, defenders can look for a rapid combination of Rhysida/Supper-style discovery behavior:
DeviceProcessEvents
| where FileName in~ (
"nltest.exe",
"net.exe",
"net1.exe",
"systeminfo.exe",
"ipconfig.exe",
"hostname.exe",
"powershell.exe",
"pwsh.exe"
)
| extend DiscoveryType = case(
ProcessCommandLine has "dclist", "DC Discovery",
ProcessCommandLine has "trusted_domains", "Trusted Domains",
ProcessCommandLine has "domain_trusts", "Domain Trusts",
ProcessCommandLine has "domain admins", "Domain Admin Discovery",
ProcessCommandLine has "domain computers", "Computer Discovery",
ProcessCommandLine has "DirectoryServices.DirectorySearcher", "LDAP Discovery",
FileName =~ "systeminfo.exe", "System Discovery",
FileName =~ "ipconfig.exe", "Network Discovery",
""
)
| where DiscoveryType != ""
| summarize
DiscoveryTypes = make_set(DiscoveryType),
Commands = make_set(ProcessCommandLine, 30)
by DeviceName, AccountName, bin(Timestamp, 10m)
| where array_length(DiscoveryTypes) >= 4
This analytic intentionally detects behavioral clustering instead of treating native administrative tools as malware.
Detection opportunity 4: impact tripwires
Impact-stage artifacts remain useful because they provide extremely high confidence.
A hunt for:
CriticalBreachDetected.pdf
should be a high-severity incident.
A burst of:
*.rhysida
file creations should trigger emergency containment.
An especially strong correlation would be:
vssadmin / shadow deletion
+
event log clearing
+
mass file modification
+
.rhysida extension creation
At that point, manual analyst review may be too slow. Organizations with mature EDR operations should evaluate whether this combination is appropriate for automatic host isolation.
The most important technical conclusion
The supplied Rhysida hash remains useful:
67a78b39e760e3460a135a7e4fa096ab6ce6b013658103890c866d9401928ba5
But it is not where defenders should spend most of their attention in 2026.
The most valuable detection surface is now upstream:
malvertising / search manipulation
↓
trojanized trusted software
↓
fraudulent code signing
↓
Endico
↓
Broomstick / Oyster
↓
Supper
↓
AD reconnaissance
↓
credential / privilege discovery
↓
lateral movement
↓
collection and exfiltration
↓
Rhysida
Microsoft’s Fox Tempest investigation demonstrates how attackers can weaponize software trust. IBM’s Rhysida research shows what can happen immediately after that initial execution. Stuttgart provides a May 2026 German public-sector extortion context occurring while parts of this ecosystem were active. Berlin demonstrates the real consequence when an intrusion progresses to large-scale data theft.
That means prioritizing identity anomalies, trusted-software abuse, unusual code signing, rare scheduled tasks, Broomstick/Supper activity, rapid Active Directory enumeration, abnormal remote administration, data staging and exfiltration.
The .rhysida extension is confirmation.
The real opportunity exists hours or days earlier.
Conclusion
Rhysida’s 2026 activity in Germany shows why defenders should look beyond the ransomware payload itself. Stuttgart provides a relevant May 2026 extortion context, while Berlin demonstrates the potential end result: prolonged access, large-scale data exfiltration, extortion, and public release of stolen information.
For defenders, the highest-value hunting opportunities sit before encryption:
- suspicious software installers,
- fraudulent signing,
- Broomstick/Oyster and
- Supper activity,
- unusual scheduled tasks,
- Active Directory reconnaissance,
- remote-access abuse,
- data staging,
- and anomalous outbound transfers.
- Static Rhysida hashes remain useful, but behavioral correlation offers a much better chance of disrupting the intrusion before .rhysida files and CriticalBreachDetected.pdf appear.
For background on the earlier Rhysida malware variants, technical behavior, and initial detection opportunities, see my previous analysis:
Rhysida Ransomware and the Detection Opportunities
And more how to emulate Rhysida you can find here:
<a href="https://medium.com/media/a0e88f071b8cab7a93f8c0b388db66fd/href">https://medium.com/media/a0e88f071b8cab7a93f8c0b388db66fd/href</a>Rhysida in Germany - From an Early Ransomware Payload to the 2026 Stuttgart and Berlin Threat… was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.