Visualização de leitura

PoisonedRefresh: A Fileless Linux Rootkit That Injects PHP Web Shells Into F5 BIG-IP APM Server Memory

PoisonedRefresh rootkit injects PHP web shells into F5 BIG-IP APM Apache memory, leaving no disk artifacts.

SophosLabs published a detailed technical analysis on September 8, 2026, of a Linux implant, dubbed PoisonedRefresh by ESET, they found in compromised F5 BIG-IP Access Policy Manager environments. Sophos tracks it as Linux/Agnt-IC. F5 has confirmed exploitation of the underlying vulnerability and links the activity to a cluster it tracks internally as c05d5254.

“The malware targets deployments featuring Apache, libphp, APR module loading, BIG-IP APM webtop components, and BIG-IP upgrade workflows, suggesting it was developed for specific environments. F5 associates the related c05d5254 activity with BIG-IP APM systems affected by CVE-2025-53521, an exploited unauthenticated RCE in BIG-IP APM when an access policy is configured on a virtual server.” reads the report published by SophosLabs. “If you believe you are, or have been, using affected BIG-IP APM versions, follow F5’s remediation and compromise-assessment guidance before applying generic Apache or PHP hardening recommendations.”

The short version: the web shell is real and works as expected, but the implementation removes almost every artifact defenders normally use to find it.

The initial access vector is CVE-2025-53521, an unauthenticated remote code execution flaw in BIG-IP APM when an access policy is configured on a virtual server. The Shadowserver Foundation observed 795 internet-exposed endpoints vulnerable to this CVE at the time of disclosure. The vulnerability was previously classified as a denial-of-service issue before F5 confirmed it as an RCE.

PoisonedRefresh is the second-stage payload. The first stage, which Sophos found hidden inside a modified Linux umount binary, infects /usr/sbin/httpd, modifies SELinux configuration, and embeds itself in BIG-IP upgrade images to survive device updates. Whatever the first stage does to gain persistence, the second stage is what gives the attacker operational capability.

The second-stage malware is a standalone Linux ELF binary that includes its own loader instead of relying on the normal Linux loader. When it starts, it intercepts libc_start_main, the function that normally starts Apache. This lets the malware run its own setup before Apache begins normal work, before logging systems fully start, and before some security tools can monitor the process.

“The second-stage sample hides key operational strings with RC4, gains execution before the host application main() function is invoked by intercepting __libc_start_main, targets Apache’s PHP module by hooking the Apache Portable Runtime (APR) module loader (apr_dso_load), and injects a PHP web shell into memory. It does the latter by manipulating mmap behavior inside libphp at runtime – so that only the infected process sees the malicious content and nothing ever touches the disk.” continues the report. “Alongside this web‑based access, the implant also creates a local UNIX domain socket and can redirect a connection into /bin/bash, enabling interactive access without opening a TCP listening port.”

The malware then waits instead of immediately changing the Apache process. It hooks apr_dso_load, the Apache function that loads shared libraries, and waits for Apache to load the PHP module (libphp). Once PHP loads, the malware checks /proc/self/maps to find where libphp sits in memory.

It then temporarily changes the memory permissions and redirects calls to file functions such as open, close, and mmap. After making the changes, it restores the original protections. From that point on, the malware can control how PHP handles files inside the Apache process.

The web shell delivery is where the analysis is most distinctive. The implant watches for PHP opening any of three specific BIG-IP APM webtop script files: apm_css.php3, full_wt.php3, and webtop_popup_css.php3. These are legitimate files that exist on the device. When PHP opens one and then maps it into memory, the implant intercepts that mmap() call and returns a modified view: the original script content preceded by the embedded PHP web shell. The on-disk file is never changed. The running process sees different content than what ls or a file integrity scanner would report.

The injected web shell reads raw data from php://input and looks for a special prefix, BSOHAzPB. It then decrypts the rest with a stream cipher using the key wSLjN1beuR and executes the result. To make its traffic look normal, it responds with HTTP status 201 and sets the content type to text/css. This makes the response look like a successful CSS file request on a BIG-IP APM device.

The implant also creates a local UNIX socket at /run/bigtlog.pipe. After a short authentication step using the token Kzwd6jM5, it connects the shell’s input, output, and error streams to the socket and starts /bin/bash. This gives the attacker an interactive shell without opening a TCP port, making the activity harder for network monitoring tools to detect.

The malware uses Apache’s apr_time_now function as a delayed trigger. It waits until the server has fully started before launching the socket worker, reducing the risk of disrupting Apache during startup.

The binary also encrypts its operational strings with RC4 using the hardcoded key TrswBWIl90Z5e38n. It decrypts them only when needed. As a result, static analysis mainly reveals function names and gives little information about what the malware is actually designed to do.

“Web shell detection mechanisms should include runtime behavior and memory inspection, not just file scanning.” continues the report. “For this class of threat, it is entirely possible for the on‑disk PHP file to appear benign, while the in‑memory mapping contains malicious code.”

Sophos recommends checking several indicators that could point to this malware. These include unusual mmap() or mprotect() calls shortly after libphp loads inside Apache worker processes, access to /proc/self/maps followed by changes to memory permissions, and the presence of the local socket /run/bigtlog.pipe.

Teams should also look for HTTP 201 responses with Content-Type: text/css when they do not match legitimate CSS or other asset requests. Other signs include unexpected changes to SELinux settings or modified BIG-IP upgrade images.

The SHA-256 hash of the analyzed sample is 26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9.

F5 has published remediation and compromise assessment guidance for CVE-2025-53521 and should be the first stop for affected BIG-IP APM operators, before applying any generic Apache or PHP hardening.

“This implant demonstrates how modern Linux malware can deliver familiar attacker capabilities through sophisticated delivery mechanisms.” concludes the report. “While the embedded PHP ultimately behaves like a traditional web shell, the surrounding infrastructure is considerably more advanced: custom ELF loading, early startup interception, APR-aware module monitoring, relocation patching, and memory-only payload delivery.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, PoisonedRefresh)

North Korea-linked Hackers Hide a Backdoor Inside HAProxy

North Korea-linked hackers hid a backdoor inside HAProxy, masking C2 traffic and stealing data while keeping the load balancer working normally.

North Korean-linked hackers found a genuinely clever hiding spot for their malware: inside the actual source code of HAProxy, the load balancing software running at the edge of two South Korean companies’ networks. Rapid7’s research documents a previously undocumented Linux toolkit hitting South Korea’s automotive and media sectors, and the depth of integration here goes well beyond a typical backdoor bolted onto a system.

“A new Linux toolkit, identified by Rapid7 Labs, has been targeting organizations across South Korea’s automotive and media industries with minimal detection. The campaign made use of a HAProxy instance named “ted backdoor”, alongside trojanized versions of crond, agetty, atd, sshd, and polkitd.” reads the report published by Rapid7. “This previously undocumented framework enabled threat actors to execute remote commands on compromised servers, inject malicious scripts into web traffic, perform credential harvesting, and engage in long-term surveillance.”

The implant, which Rapid7 calls the “ted backdoor” based on debug strings the attackers left behind, isn’t a separate process running alongside HAProxy. It’s compiled directly into HAProxy’s own source code as a custom plugin, using the software’s native filter API, internal memory management, and event scheduler to intercept HTTP traffic while completely legitimate load balancing keeps running normally on top of it.

“The standout feature of this toolkit is its depth of integration with the target environment. The ted backdoor is compiled as part of the victim’s existing HAProxy version 2.8.12.” continues the report. “It uses its native filter API, internal memory pools, event scheduler, and process management infrastructure to intercept traffic and hide from monitoring, while genuine load balancing traffic operates as expected.”

Rapid7 explains, which is really the whole thesis of why this backdoor is so hard to spot: it’s not an addition to the software, it’s woven into it.

The backdoor receives commands through a surprisingly simple trick. The attackers send a request for a fake image at /favorite_list_2x_m500_ico.jpg. This switches the HAProxy filter into command-and-control mode.

The malware then saves the command in a named pipe and removes traces of the request from HAProxy’s internal counters. It also clears the forwarding buffers, so the request never reaches the backend server. The command ends at the load balancer, leaving nothing in the application logs to show that it happened.

This ability to erase its own traces makes the backdoor very different from a normal web shell. The C2 requests never reach the backend server and are also removed from HAProxy’s statistics.

As a result, neither the application logs nor HAProxy’s connection logs show that the attack happened. A security team checking the logs could find nothing suspicious because the backdoor has already erased the evidence.

Beyond remote command execution, the backdoor can quietly inject malicious scripts or entirely swap out page content for specific victims matched by IP address, browser fingerprint, or even a hidden authentication credential smuggled inside the Accept-Language header, effectively turning a company’s own load balancer into a watering hole against its own visitors. It also hooks response bodies carefully enough to hide the size difference caused by injected content, stripping the header that would let a browser notice the byte-range mismatch. That’s a level of protocol-level care that suggests real HAProxy internals expertise, not a quick copy-paste job.

The main backdoor also comes with a separate toolkit that modifies common Linux system daemons such as crond, agetty, atd, and sshd. These programs continue to work normally but also carry malicious features.

One component acts as an SSH keylogger. It captures passwords that administrators enter in plain text and quietly records them. Another tool, called curlRAT, contacts a remote server every 12 hours by default, or every 30 seconds when the attacker enables its fast-poll mode.

curlRAT also checks whether the system runs inside a virtual machine. If it does not find the expected signs, it refuses to run. This behavior suggests the attackers designed the malware to avoid sandboxes and other analysis environments.

Attribution here sits at medium confidence, and Rapid7 is upfront about the limits of what the evidence actually shows. The targeting pattern, simple XOR-based encryption, a custom substitution cipher, and command-server infrastructure already linked to APT37 by other threat intelligence feeds all point toward North Korean state involvement, with some technical overlap also drawing comparisons to a concurrent Lazarus Group campaign against South Korean media sites.

“Further evidence is necessary to make a more definitive assessment. Moreover, the presence of ngx_* prefixed routines within the ted backdoor suggest code reused from an nginx backdoor. The ngx_* prefixed routines were observed during the latest Funnull campaign, where (similar to our case) a custom nginx filter was registered to hook HTTP traffic, and simple XOR encryption was applied to the configuration file.” Rapid7 states. “However, other than a similar naming convention, no significant code-level overlaps exist to support a stronger linkage.”

If your organization runs HAProxy, or really any edge component handling SSL termination and traffic routing, the practical lesson here is uncomfortable but simple: that software deserves the same scrutiny as your actual application servers, not less. The Hacker News confirmed in early September that the specific command domains used in this campaign have already gone dark, returning no DNS records at all, which is useful for reviewing historical logs but does nothing to stop whatever comes next from the same operators. Checking a load balancer’s own logs isn’t enough anymore when the backdoor’s entire design goal is making sure those logs never see it in the first place.

“ted backdoor and curlRAT were designed to persist during long-term espionage operations with the ability to steal cookie sessions, credentials, redirect selected users, conduct drive-by download attacks, and hide evidence of the tampered page to a specific range of IPs to evade detection.” concludes the report. “Defenders should treat any edge component managing user traffic, SSL, or runtime modules with the same strict security standards as their main application servers. Relying on the component’s own logs is not enough; securing these systems requires independent network correlation, memory behavioral analysis, and binary integrity checks.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, North Korea)

StyleSmuggler: The Magento Zero-Day Behind New Store Attacks

StyleSmuggler Magento zero-day is under active attack, letting unauthenticated attackers execute code and install backdoors on stores that may already be patched.

A new zero-day flaw, dubbed StyleSmuggler, in Magento and Adobe Commerce is under active attack, giving unauthenticated attackers a path to run code on vulnerable online stores. Sansec researchers say it affects current Magento Open Source releases, including 2.4.7, 2.4.8 and 2.4.9. According to the experts, exploitation began on September 4.

“Sansec discovered StyleSmuggler, an unpatched Magento and Adobe Commerce zero-day that gives unauthenticated attackers remote code execution. All current versions are affected, including 2.4.9.” reads the report published by Sansec. “Attacks started September 4th. Sansec is rolling out emergency mitigation.”

This is not a routine patch-cycle problem. Sansec reproduced the full attack chain on clean installations and observed a first victim running Magento 2.4.6-p15 with July and August 2026 patches already applied and a clean patch-status result. In plain terms, a store could be fully updated according to its normal process and still be exposed.

“StyleSmuggler injects malicious code into Magento’s template system.” states Sansec. “By using the styles properties, it can evade existing safeguards. It works in two stages:

  1. Inject (poison) PHP code, for example by generating a failure report.
  2. Let Magento execute the poisoned code via a failed payment email

The attack is especially dangerous because it does not require a victim to open an attachment, click a link or even receive a successful email. Magento can execute the injected code while it renders its standard “Payment Transaction Failed Reminder” notification, and the chain can still work if email delivery itself fails.

That makes unusual spikes in failed-payment reminders a useful detection clue, although not conclusive proof of compromise. Legitimate payment failures happen. A sudden burst of them combined with strange system activity is a different conversation.

StyleSmuggler works by placing PHP code into Magento’s templating path and later causing the platform to evaluate it. The first stage creates or poisons a record, while the second stage turns a routine email-rendering process into remote code execution.

The attack reportedly uses GraphQL-related handling and the styles property to evade safeguards that would normally reject dangerous input. Sansec says moving sessions to Redis or a database does not stop the attack, because operators have already adapted their methods when one delivery route fails.

“Moving sessions to Redis or the database does not stop the attack. One merchant reported an attempt that failed against session storage and, eight seconds later, a second attempt that succeeded by using a file uploaded through Magento’s custom options instead.” continues the report. “Both came from the same operator.”

That detail matters because it shows an active operator, not a static proof-of-concept circulating online. Defenders should assume attackers are testing several paths, watching failures and changing tactics quickly.

Once the exploit succeeds, Sansec observed a lightweight Rust backdoor that connects to attacker-controlled infrastructure and waits for commands. At the time of the report, Sansec had not seen evidence that operators had yet used the implant for follow-on actions, but a backdoor that is installed and waiting is not an idle technical curiosity.

The malware initially hid behind a process name resembling [kworker/u:8:0], then appeared as fc-cache on September 6 and as chronyd on September 7.

These names are designed to blend into Linux environments, where administrators may expect to see kernel workers, font-cache utilities and Network Time Protocol daemons.

The fc-cache variant copies itself into a font-cache directory, writes a PID lock file and uses cron to restart twice an hour. The chronyd version can persist through cron as well, but Sansec also observed a build that relaunched itself without relying on a visible cron entry. An empty crontab is not proof that a host is clean.

The command channel is disguised as time synchronisation traffic. The implant sends 48-byte UDP packets to port 123, the standard NTP port, and uses domains that resemble time servers.

“Command and control is disguised as time sync. Every 60 seconds it resolves ntp.timesync.to and sends 48-byte UDP packets to port 123 that look like NTP server replies.” continues the report.

Only the first four bytes look like a normal NTP message; the remaining data can carry the agent ID, hostname, username, operating-system version, memory and disk use, uptime, root status and implant version.

That is a smart concealment choice. Many networks allow NTP traffic without close inspection because reliable time synchronisation is a normal operational requirement. Calling your malware chronyd and making it speak something that resembles NTP is not subtle genius. It is just clever enough to pass a lazy allowlist.

Sansec also found signs of a second, apparently unrelated attacker operating against stores compromised through StyleSmuggler. This actor deployed a compact PHP dropper that placed a web shell inside the product-image cache, using hash-like directory names to make the extra PHP file less obvious.

The web shell returns a normal-looking 404 response unless a request contains the correct X-Cache-Token header. With the header present, it can execute PHP supplied through a POST parameter. That design helps the attacker keep the shell invisible during casual checks and automated scans.

“Before writing that file, the dropper calls out to 457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site, a subdomain of a public service that developers and testers use to confirm that injected code ran.” states the report. “This actor came in through StyleSmuggler. We recovered the dropper from a Store: request header, and its PHP tags are still JSON-escaped from the record Magento logged it into.”

The lesson is not merely to remove the obvious background process. Stores need a full compromise assessment, including a review of PHP files under pub/media, cron spool files, unexpected processes, altered templates, report records, web-server logs and outbound connections.

Adobe was working on a patch as of September 7, according to Sansec, but no release date had been confirmed. A scheduled Adobe security release was due on September 8, although it was not known whether it would address StyleSmuggler.

Until an official fix is available and applied, merchants should consider temporarily disabling GraphQL if they do not have a compensating control capable of blocking this exploit. This can affect storefront and integration functions, so it should be treated as a risk decision rather than a casual configuration change.

Operators should also hunt for processes named [kworker/u:8:0], fc-cache and chronyd that run from unusual paths such as temporary directories, user cache directories or hidden folders. A legitimate chronyd process does not normally emit nine NTP server-mode packets in rapid succession every minute.

Security teams should inspect outbound traffic to suspicious NTP-like domains and UDP port 123 destinations, particularly 185.157.160.251, which Sansec linked to the observed domains on September 7. They should also search authentication and system logs for repeated crontab command not allowed messages generated by the web-service user, such as www-data.

If compromise indicators appear, treat the system as compromised, not merely vulnerable. Isolate the host, preserve logs and forensic evidence, rotate Magento administrator credentials, API tokens, database credentials, payment-provider secrets and cloud keys, then search for secondary backdoors before restoring normal operations.

The Sansec StyleSmuggler report includes current indicators of compromise, malware hashes, C2 infrastructure, suspicious process names and file paths. Its guidance will likely change as the campaign develops, because the attackers have already changed payload names and persistence methods within days.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, StyleSmuggler)

GoldFactory Weaponizes Open-Source Vwork App Cloner in Gigabud Banking Malware Attacks

GoldFactory has expanded the evasion capabilities of its Gigabud Android banking trojan by deploying Vwork, a weaponized fork of the open-source Shelter application. The companion tool abuses Android Work Profile isolation to clone banking apps into a separate managed environment, weakening the link between malware signals detected in a victim’s personal profile and fraudulent activity […]

The post GoldFactory Weaponizes Open-Source Vwork App Cloner in Gigabud Banking Malware Attacks appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

JSCeal Hides Crypto Malware in V8 Bytecode

JSCeal hides crypto-stealing malware in V8 bytecode, but researchers built a tool to decompile it and expose its advanced theft capabilities.

JSCeal is a cryptocurrency stealer that Check Point Research has tracked since early 2025. Unlike most malware, it hides its code in a format that makes analysis much harder. Check Point presented its latest research at Black Hat USA 2026 and showed how its team built a tool that converts the hidden code into a form analysts can understand.

JSCeal uses a clever trick. Instead of delivering normal JavaScript, its creators compile the malware into V8 bytecode, the format that Chrome and Node.js use to run JavaScript efficiently. They then package the bytecode with a Node.js runtime that executes it.

The original JavaScript never reaches the victim’s computer. As a result, most tools designed to analyze JavaScript have little useful code to work with.

“JSCeal is a stealer delivered as compiled V8 bytecode (.jsc) and executed by a bundled Node.js runtime, targeting cryptocurrency applications (other vendors also tag it with the names WEEVILPROXY or MeadowLocust). ” states the report. “Unlike ordinary JavaScript malware, JSCeal reaches the analyst after two transformations have already removed much of the information that source-oriented tools depend on. First, the JavaScript is heavily obfuscated. Then it is compiled into V8’s internal bytecode representation and shipped as cached data rather than source code. The resulting format is version-specific, poorly served by mature reverse-engineering tooling, and unsuitable for most standard JavaScript deobfuscation workflows.”

Before compilation even happens, the JavaScript source gets run through a commercial-grade obfuscator too, adding a second wall on top of the first. Function and variable names get replaced with meaningless strings, important text gets split into encrypted chunks reconstructed only at runtime, and the program’s actual logic gets scrambled into a state machine that hides the real order operations execute in.

Stack two separate obfuscation techniques on top of each other, and you get a payload that’s expensive to analyze but was genuinely cheap for the attacker to produce, since none of these tools are custom-built; they’re just assembled from existing open-source components.

Check Point’s answer was building on top of View8, an existing open-source V8 bytecode decompiler, and extending it with a purpose-built pipeline specifically tuned to JSCeal’s patterns. The process has to happen in a strict sequence, because each layer of deobfuscation exposes information the next layer needs: recovering encrypted strings reveals dictionary keys, those keys unlock proxy function relationships, and cleaning up the proxies finally exposes what the code is actually doing underneath. Applied across 23 different JSCeal samples collected over several months, the pipeline produced usable, readable output in every single case.

What that recovered code actually shows is a genuinely broad toolkit built for financial theft. JSCeal steals saved passwords and cookies from eight different Chromium-based browsers, harvests Telegram session data, logs keystrokes, takes screenshots, and installs a locally generated, attacker-controlled certificate to intercept and modify HTTPS traffic in transit. That last capability lets it silently rewrite what a victim actually sees from real financial platforms, swapping login QR codes on Binance, injecting fake security challenges on Bybit, and replacing legitimate scripts served by Ledger’s own website with content the attacker controls.

One capability goes well beyond passive data theft into something closer to automated account takeover. The malware can launch a victim’s own installed browser, inject stolen session cookies, and navigate through Google’s actual account authentication flow using automation tooling built specifically to avoid looking like a bot.

“The proxy is not limited to passive interception. The recovered code contains dedicated handlers that modify selected requests and responses for specific services.” continues the report. “A configuration function exposes separate overrides for Binance, Bybit, and Ledger, as well as generic handlers for replacing HTML, blocking hosts, and clearing selected cookies.”

When it hits a password prompt, it tries every credential it previously stole from that same machine until one works, then walks away with a fresh, valid OAuth token, essentially replaying a stolen identity rather than just filing away a list of passwords for later.

Once Check Point recovered the code, another problem appeared: thousands of functions had meaningless names, making the code almost impossible to understand manually.

To help, the team added an optional AI step that used Claude and GPT to suggest clearer names for the functions. They tested the results on 142 function trees. Claude produced useful and accurate names in 128 cases, while GPT did so in only 30.

Check Point stresses that AI-generated names are only suggestions. Analysts still need to check the actual code before trusting them.

JSCeal hasn’t stood still since this research began either. Later samples upgraded to a newer Node.js runtime that broke compatibility with the team’s existing disassembler, added a fresh AES encryption layer wrapped around the compressed payload with the decryption key supplied externally rather than baked into the file, and expanded targeting to macOS for the first time.

“The authors introduced another obstacle by adding an AES-256-CBC encryption layer around the Brotli-compressed payload. The first encrypted payload we observed was generated on 2025-11-11 (581e2e2265d0c1509b3799c5a9039374). The AES key is not stored in the malware bundle itself. Instead, another stage of the deployment chain provides it through an environment variable.” continues the report. “Recovering the underlying V8 code cache therefore requires obtaining the corresponding key from the surrounding infection chain, which is not always possible when only an isolated bundle or payload is available. Protecting a payload with an encryption key supplied by an earlier deployment stage is an effective anti-analysis technique, consistent with patterns seen in other mature malware frameworks.”

That’s a malware family under active, well-resourced development, not a one-off campaign, and it’s specifically going after anyone running a crypto exchange account, a browser full of saved passwords, or a Ledger hardware wallet connected to a compromised machine.

If your organization touches cryptocurrency infrastructure in any capacity, this is worth reading past the technical deep dive, because the local proxy and certificate installation technique here works regardless of which specific exchange your team happens to use.

“JSCeal combines two forms of analysis friction: a version-specific compiled V8 format and several layers of JavaScript obfuscation applied before compilation.” concludes the report. “Neither makes the malware impossible to reverse, but together they move it outside the workflows that analysts normally rely on.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)

Berlin Ransomware Leak Exposes State Secrets

Berlin refused a 30 Bitcoin ransom, leading hackers to leak 6TB of sensitive state administration and national defense data on the dark web.

When a ransomware gang dumps nearly six terabytes of state administration files onto the dark web, ignoring them does not make the problem go away. The Rhysida ransomware group recently carried out this exact threat against Berlin after local authorities refused to pay a thirty Bitcoin ransom.

At the end of August, Berlin’s state government confirmed it was dealing with an extortion attempt following an August cyberattack on the city-state’s administrative network, and officials have already refused the requested ransom. The ransomware group Rhysida claimed responsibility on its leak site August 28, posting an entry titled simply “Berlin, Germany” and claiming 5.79 terabytes of data across roughly 1.44 million files, with personal information on 12,076 individuals allegedly included.

Rhysida claimed it stole 5.79 TB of data, covering around 1.44 million files. The alleged dataset includes:

  • Personal data: 12,076 individuals, 16,389 email addresses, 11,963 phone numbers and 148 IBANs.
  • Sensitive records: more than 5,000 personnel files, more than 5,000 administrative-offence files, payroll data and leadership information.
  • Credentials: plaintext passwords and credentials for systems including GebäudAtlas, the ePayment PAYONE database and Z_ADMIN accounts.
  • Government and legal material: disciplinary proceedings, court cases, supervisory documents, NDA records and Bundesrat committee protocols.
  • Classified information: data related to classified-material handling and documents allegedly containing state secrets.
  • Critical infrastructure: vulnerability analyses concerning Berlin’s water supply.
  • Identity documents: passports and ID cards from personnel records.
  • Other material: contracts, financial documents, HR records, infrastructure files, health data, password stores and SQL/PST archives.

The group also claimed that the material could involve violations of GDPR, German classified-information rules, criminal law and KRITIS/BSIG requirements. These are Rhysida’s claims and have not been independently verified.

The scale of the breach is staggering. Investigators are now looking at roughly 1.4 million files containing personal details of civil servants, internal infrastructure records, and critical government data.

The fallout goes far beyond routine data theft. Investigative journalist Lars Winkelsdorf pointed out the gravity of the situation on social media.

Die absolute Vollkatastrophe ist eingetreten

Dieses Datenleck ist schlimmer als alle bisherigen Terroranschläge zusammen 1/xhttps://t.co/epU4mCYgew

— Lars Winkelsdorf (@winkelsdorf) September 4, 2026

“In addition to LKA documents related to investigations, the files also include plans concerning national defense—ranging from the federal government’s secret communication channels in the event of an apocalypse to defense-related companies and emergency plans developed by government agencies,” Winkelsdorf wrote.

Exposing crisis response plans and secret communication channels turns a financial shakedown into a national security headache.

Worse still, the leaked material includes files concerning chemical, biological, radiological, and nuclear threats.

“Among the published files is a folder titled “AG CBRN-Rahmenplanung.” CBRN stands for chemical, biological, radiological and nuclear threats,” notes the Euronews report

Having that kind of operational data floating around public forums gives hostile actors a blueprint for disaster.

Refusing to pay ransoms is the right policy, but it rarely stops the bleeding once the network is compromised. Governments keep treating cybersecurity like an IT expense rather than an existential line of defense.

Until boards start treating network segmentation with the same seriousness as physical security, we will keep watching expensive countdown timers tick down to zero.

Berlin’s state government announced the launch of a crisis response after the threat actors published the stolen data.

“A ‌central ⁠crisis unit will oversee the review, verification and assessment of the leaked data and support efforts to inform affected citizens and ​businesses, said the ​city.” Reuters reports.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Berlin)

SECURITY AFFAIRS MALWARE NEWSLETTER ROUND 113

Security Affairs Malware newsletter includes a collection of the best articles and research on malware in the international landscape

Malware Newsletter

Hackers Steal Claude Login Sessions With Infostealer Malware to Hijack Accounts

Fire Ant Evolves: From Hypervisors to Trusted Infrastructure      

Gryxa: The AI-Built Toolkit That Watches How You Remove It

ValleyRAT masquerading as adware  

13 Malicious Packagist Themes Deliver iOS Spyware That Steals Crypto Wallet Seeds  

Mirage Kitten targeting aviation and FinTech sectors across the Middle East and Africa with a new malware set

Uncovering StreamRat: From Meta Ads to Full Device Takeover  

Counterfeit installers to system compromise: Tracking a deceptive software download campaign

Gaming the system: how a Chinese-speaking actor turned Brazilian government sites into an SEO weapon September 2, 2026

Mini Shai-Hulud’s Latest Wave: 280 New Places It Hunts for Your Secrets  

Pegasus Spyware Infection of Serbian Pro-Democracy Student Activist 

Chinese-Speaking Operator Uses AI Agents to Target Government and Education Systems Across Asia

DPRK APTs: Ted backdoor and curlRAT target South Korean media and automotive sectors

Anatomy of BraZetsu: How Cybercriminals Fuel the Underground Ecosystem

Peer Pressure: Inside the Sality Botnet Disruption Operation

Graph-Based Learning for Android Authorship Attribution: A Comparative Analysis of GNN Models

Stability and Hopf Criteria in a Malware Dissemination Model for Wireless Sensor Networks with Distributed Recovery Delays

PhantomCall: Evading ML Malware Detectors via Function Call Graph Perturbation

REPLICANT: Learning Policies for Evading and Hardening Malware Detectors

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

❌