CSOonline

Keylogger sind Malware der alten Schule. Lesen Sie, wie die Tools zur Tastaturüberwachung funktionieren und warum sie nicht nur etwas für Cyberkriminelle sind. IM_photo | shutterstock.com Auch wenn Keylogger schon etliche Jahre auf dem Buckel haben: Sie sind immer noch beliebt und werden häufig im Rahmen großangelegter Cyberangriffe eingesetzt. Keylogger – Definition Der Begriff Keylogger bezeichnet eine Art von Überwachungssoftware, die die Tastatureingaben eines Benutzers aufzeichnet. Die Schadsoftware sendet die Daten, die beim Keylogging erfasst werden, an einen Dritten. Cyberkriminelle nutzen Keylogger, um an persönliche Daten oder sensible Finanzinformationen zu gelangen, die sie dann verkaufen oder anderweitig gewinnbringend nutzen können. Es gibt jedoch auch legitime Verwendungszwecke für Keylogger in Unternehmen – zum Beispiel beim Troubleshooting, dem Optimieren der Benutzerfreundlichkeit oder um Mitarbeiter legal zu überwachen (je nachdem, welchen Gesetzen sie dabei unterliegen). Darüber hinaus nutzen Strafverfolgungsbehörden und Geheimdienste Keylogging zu Überwachungszwecken. Mehr dazu lesen Sie im Absatz “Einsatzzwecke”. Keylogger – Funktionsweise “Keylogger sind Programme, die Algorithmen nutzen, um die Tastaturanschläge durch Mustererkennung und andere Techniken zu überwachen”, erklärt Tom Bain, Vice President Security Strategy bei Morphisec. Der Umfang der von der Keylogger-Software gesammelten Informationen kann dabei variieren: Einfache Formen erfassen nur die Informationen, die auf einer (einzigen) Website oder in einer Anwendung eingegeben werden. Hochentwickelte Keylogging-Programme zeichnen hingegen alles auf (einschließlich der Daten, die bei Copy-Paste-Aktionen anfallen), unabhängig von der Anwendung. Einige Keylogger-Varianten – insbesondere solche, die auf mobile Geräte abzielen – gehen noch weiter und erfassen auch Anrufe (sowohl Anrufverlauf als auch Audio), Informationen aus Messaging-Anwendungen, GPS-Standorte, Screenshots und sogar Mikrofon- und Kameraaufnahmen. Keylogger können hardware- oder softwarebasiert aufgebaut sein: Hardwarebasierte Keylogger werden einfach zwischen Tastatur und Computer geschaltet. Bei softwarebasierten Keyloggern kann es sich um Applikationen oder Tools handeln, die legal oder illegal installiert werden, in letzterem Fall also das Gerät unwissentlich mit Malware infizieren. Die beim Keylogging erfassten Daten werden von der Software per E-Mail oder durch den Upload von Protokolldaten in vordefinierte Websites, Datenbanken oder FTP-Server an den Angreifer zurückgesendet. Ist der Keylogger Instument in einem großen Cyberangriff, ist es sehr wahrscheinlich, dass die Kriminellen sich per Fernzugriff einloggen können, um die Tastaturanschlagsdaten herunterzuladen. Keylogger – Einsatzzwecke Die ersten Keylogger wurden bereits in den 1970er Jahren vom sowjetischen Geheimdienst eingesetzt (mehr dazu später). Auch diese frühen Keylogger zeichneten auf, was getippt wurde und schickten die Informationen über Funksignale an den KGB zurück. Wie Cyberkriminelle Keylogger einsetzen Heute gehören Keylogger zum gängigen Instrumentarium Cyberkrimineller, um finanzielle Informationen wie Bank- und Kreditkartendaten, persönliche Informationen wie E-Mail-Adressen, Passwörter oder sensible Geschäftsinformationen über Prozesse und geistiges Eigentum zu entwenden. Je nach Art der gesammelten Daten (und den Motiven der Angreifer) werden die Informationen auf Darknet-Marktplätzen feilgeboten oder im Rahmen eines größeren Angriffs wiederverwendet. “Wenn ein Keylogger in der Lage ist, die Tastenanschläge eines Datenbankadministrators in einem großen Unternehmen aufzuzeichnen, eröffnet das dem Angreifer Zugang zu Endpunkten und Servern, die wiederum viele sensible Informationen preisgeben können, die sich zu Geld machen lassen“, erklärt Security-Spezialist Bain. Keylogger am Arbeitsplatz Es gibt auch einen großen Markt für legale Keylogging-Apps, wenngleich diese meist ethisch fragwürdig sind. Sie können etwa genutzt werden, um Familienmitglieder, Partner oder Arbeitnehmer auszuspionieren. Wenn der Benutzer eines Geräts davon weiß, dass Spyware auf seinem Gerät läuft, ist das in vielen Ländern legal. Anwendungen, die Informationen über das Arbeitsverhalten sammeln, sind allerdings nicht nur aus moralischen, sondern auch aus Sicherheitsgründen mit Vorsicht zu genießen. Der Spyware-Anbieter mSpy wurde beispielsweise überführt, in mehreren Fällen unabsichtlich Millionen Datensätze von Opfern einer Ausspähung veröffentlicht zu haben. Überwachungssoftware dieser Art, die manchmal auch als “Corporate Keylogging” bezeichnet wird, kann indes für Testing, Debugging und die Verbesserung der User Experience nützlich sein. “In einer seriösen Umgebung werden Keylogger beispielsweise eingesetzt, um zu überprüfen, ob IT-Sicherheits- und Compliance-Vorschriften eingehalten werden”, weiß Simon Sharp, International Vice President beim Sicherheitsanbieter ObserveIT. “Ein Administrator kann dann sofort feststellen, wer ein bestimmtes Wort oder einen bestimmten Wert eingegeben hat, der mit einem Sicherheitsvorfall in Verbindung steht. So kann er verstehen, wer wann und warum gegen eine Richtlinie verstoßen hat.” Die IT-Abteilung kann die Tastaturanschlagsdaten nutzen, um Benutzerprobleme zu identifizieren und zu beheben. Darüber hinaus können die Keylogging-Daten möglicherweise zusätzliche forensische Informationen nach einem Sicherheitsvorfall bereitstellen. Keylogger können auch dazu genutzt werden, potenzielle Innentäter zu erkennen, die Produktivität der Mitarbeiter zu überwachen oder um sicherzustellen, dass die IT-Ressourcen des Unternehmens nur für berufliche Zwecke genutzt werden. Sämtliche erfassten Keylogging-Daten sollten verschlüsselt werden. Keylogger – Infektionswege Es gibt verschiedene Wege, wie Keylogger auf einem Zielsystem platziert werden können. Hardwarebasierte Keylogger erfordern eine physische Handlung des Angreifers vor Ort. Das ist meist schwierig zu bewerkstelligen – aber nicht unmöglich. Auch drahtlose Tastaturen können übrigens aus der Ferne ausspioniert werden. Software-basierte Keylogger sind weiter verbreitet und eröffnen mehrere Zugangswege: Infizierte Domains sind eine gängige Angriffsmethode – im Oktober 2018 wurden die .com- und .eu-Domains der Online-Bürosoftware Zoho gesperrt, nachdem sie Keylogging-Malware an Nutzer ausgeliefert hatten. Auch Tausende von WordPress-Webseiten wurden bereits über gefälschte Google-Analytics-Skripte mit Keyloggern infiziert. Mit Malware infizierte Apps sind ebenfalls ein Problem. Der Google Play Store hatte in der Vergangenheit bereits des öfteren mit Apps zu kämpfen, die Keylogger enthielten. Wie viele andere Arten von Malware sind auch Keylogger oft in Phishing-E-Mails eingebettet. Eine Version des HawkEye-Keyloggers wurde beispielsweise über eine E-Mail-Kampagne mit infizierten Word-Dokumenten verbreitet. Einige andere Keylogger-Varianten, wie etwa Fauxspersky, können sich über infizierte USB-Laufwerke verbreiten. “Die größte Innovation bei Keyloggern sind integrierte Ausweichtechniken, die es ermöglichen, die Malware an Erkennungsmechanismen wie Antivirus-Software vorbeizuschleusen”, sagt Bain. Viele Keylogger würden inzwischen in Kombination mit Ransomware, Cryptominer Malware oder Botnet-Code geliefert, so der Experte. 6 Wege, um Keylogger zu erkennen und entfernen Die folgenden Ratschläge stellen die nach allgemeiner Auffassung wirksamsten Schritte dar, um die Auswirkungen unerwünschter Keylogger zu minimieren: 1. Ressourcen, Prozesse und Daten überwachen Um einen Keylogger zu finden, kann es hilfreich sein, einen Blick auf die Ressourcenzuweisung, die Hintergrundprozesse und die Daten zu werfen, die vom betreffenden Gerät übertragen werden. Um zu funktionieren, benötigen Keylogger in der Regel Root-Zugriff auf den Zielrechner – ebenfalls ein verräterisches Anzeichen für eine Keylogger-Infektion. 2. Schutz aktualisieren Da Keylogger oft mit anderen Formen von Malware gebündelt werden, kann die Entdeckung von Keylogger-Malware ein Hinweis auf einen umfassenderen Angriff sein. Aktuelle Virenschutz- und Anti-Rootkit-Lösungen entfernen bekannte Keylogger-Malware. Dennoch empfehlen sich weitere Untersuchungen, um festzustellen, ob der Vorfall Teil eines größeren Angriffs war. 3. Anti-Keylogger-Software einsetzen Spezielle Anti-Keylogger-Software verschlüsselt Tastaturanschläge, sucht nach bekannten Keyloggern und entfernt sie. Bei ungewöhnlichem Keylogger-ähnlichem Verhalten schlägt sie Alarm. Hilfreich ist es auch, den Root-Zugriff für nicht autorisierte Anwendungen zu sperren und bekannte Spyware in die IT-Blacklist aufzunehmen. 4. Virtuelle Tastaturen nutzen Virtuelle Onscreen-Keyboards vermindern das Keylogger-Risiko, weil sie Informationen auf andere Weise weitergeben als physische Tastaturen. Das kann sich allerdings auf die Produktivität der Benutzer auswirken. Außerdem wirkt es nicht gegen alle Arten von Keylogger und beseitigt auch nicht die Ursache des Problems. 5. Selbstausführende Dateien deaktivieren Indem selbstausführende Dateien auf extern angeschlossenen Geräten wie etwa USB-Devices deaktiviert werden und Dateien lediglich eingeschränkt auf und von externen Rechnern kopiert werden können, lässt sich das Risiko einer Keylogger-Infektion ebenfalls verringern. 6. Strikte Richtlinien durchsetzen Der beste Weg für Unternehmen, sich vor Keylogger-Malware zu schützen, besteht in vielschichtigen Kennwortrichtlinien und einer Mehr-Faktor-Authentifizierung für alle Unternehmenskonten und -geräte. Auch im Fall von Keylogging reicht durchschnittliche Antivirus-Technologie nicht mehr aus. Keylogger-Historie – berühmte Beispiele Der älteste bekannte Keylogger entstammt dem Prä-Computerzeitalter: Der sowjetische Geheimdienst entwickelte in den 1970er Jahren ein Device, das in elektrischen IBM-Schreibmaschinen versteckt werden konnte und Informationen über Tastenanschläge per Funk übermittelte. Diese frühen Keylogger wurden in US-Botschaften in Moskau und Leningrad eingesetzt. Der erste Computer-Keylogger wurde 1983 vom damaligen Doktoranden Perry Kivolowitz als Proof of Concept entwickelt. Ein besonders bemerkenswertes Beispiel für einen Keylogger “in freier Wildbahn” wurde 2015 “im Bundle” mit einer Modifikation für das Videospiel Grand Theft Auto V verbreitet. Im Jahr 2017 wurde bekannt, dass Hunderte von Laptop-Modellen aus dem Hause Hewlett-Packard mit einem Keylogger ausgeliefert wurden. Das Unternehmen bestand allerdings darauf, dass es sich um ein Tool zur Diagnose der Tastaturleistung handelte, das vor der Auslieferung hätte gelöscht werden müssen. View the full article

Threat actors are abusing extension dependency relationships in the Open VSX registry to indirectly deliver malware in a new phase of the GlassWorm supply-chain campaign. Researchers at Socket said they have identified at least 72 additional malicious Open VSX extensions linked to the campaign since January 31, 2026. The extensions appear to target developers by posing as helpful tools, such as linters, formatters, database utilities, or integrations for AI coding assistants, while serving as delivery vehicles for a malware loader linked to the GlassWorm operation. “Instead of requiring every malicious listing to embed the loader directly, the threat actor is now abusing ‘extensionPack’ and ‘extensionDependencies’ to turn initially standalone-looking extensions into transitive delivery vehicles in later updates, allowing a benign-appearing package to begin pulling separate GlassWorm-linked extension only after trust has already been established,” Socket researchers said in a blog post. The new campaign technically retains the same core GlassWorm tradecraft while improving survivability and evasion, the researchers added. Supply-chain attack hiding in extension relationships extensionPack and extensionDependencies are two features commonly used by Visual Studio Code extensions to bundle or require other extensions. According to Socket, threat actors are publishing clean-looking extensions that, after gaining user trust and passing marketplace checks, are later updated to include dependencies on separate extensions that contain the GlassWorm loader. When installed or updated, the editor automatically installs all referenced extensions, including the malicious payload. This transitive delivery model creates a supply-chain pathway similar to dependency abuse in package ecosystems like npm. A recent abuse included a maintainer’s compromise, leading to malicious updates spreading a backdoor malware. The infamous Shai-Hulud campaign that compromised over 800 packages by November, 2025 is another instance of self-propagating dependency abuse. The new approach likely lowers operational overhead for attackers. Instead of embedding the loader in every malicious extension, they can maintain a smaller number of payload extensions while distributing them through a wider network of dependency relationships. The evolving GlassWorm Earlier research into the GlassWorm operation has revealed techniques such as heavy code obfuscation, the use of Unicode characters to hide malicious logic, and infrastructure that retrieves command-and-control servers through blockchain transactions, making the campaign more resilient to takedowns. The latest wave also mimics widely used developer tools to maximise installation chances. “The extensions overwhelmingly impersonate widely installed developer utilities: linters and formatters like ESLint and Prettier, code runners, popular language tooling for Angular, Flutter, Python, and Vue, and common quality-of-life extensions like vscode-icons, WakaTime, and Better Comments,” the researchers said. “Notably, the campaign also targets AI developer tooling, with extensions targeting Claude Code, Codex, and Antigravity.” The researchers added that as of March 13, Open VSX has removed the majority of the transitively malicious extensions, yet a few remain live, indicating ongoing takedowns. Socket published indicators of compromise (IOCs) tied to the campaign, including the names of dozens of malicious Open VSX extensions and associated publisher accounts believed to be linked to the operation. Additionally, the researchers recommend treating extension dependencies with the same scrutiny typically applied to software packages. Organizations should monitor extension updates, audit dependency relationships, and restrict installation to trusted publishers where possible, as attackers increasingly exploit the developer tooling ecosystem as a supply-chain entry point. View the full article

Security researchers at Qualys have disclosed nine vulnerabilities in AppArmor, the Linux Security Module that ships enabled by default across Ubuntu, Debian, and SUSE distributions. An unprivileged local attacker can exploit the flaws to gain full root access, break out of container isolation, and crash systems, all without requiring administrative credentials, the researchers said in a blog post. Dubbed “CrackArmor” by the Qualys Threat Research Unit (TRU), the vulnerabilities have existed since Linux kernel version 4.11, released in 2017. Qualys’s own asset management telemetry puts the exposed attack surface at over 12.6 million enterprise Linux instances running AppArmor by default, a figure that grows further when Kubernetes clusters, IoT deployments, and edge environments are counted, the blog post said. “As the default mandatory access control mechanism for Ubuntu, Debian, SUSE, and numerous cloud platforms, its ubiquity across enterprise environments, Kubernetes, IoT, and edge environments amplifies the threat surface significantly,” the researchers wrote in the blog post. A fundamental design flaw At the heart of CrackArmor is what Qualys describes as a “confused deputy” problem, a class of vulnerability in which a privileged process is tricked into performing unauthorized actions on behalf of an unprivileged user. In the advisory, Qualys likened it to “an intruder convincing a building manager with master keys to open restricted vaults that the intruder cannot enter alone.” In practice, the researchers said, a standard local user account is sufficient to manipulate AppArmor’s security profiles – the rules that govern what individual applications are permitted to do on a Linux system. “By routing commands through trusted system tools, an unprivileged attacker can load, replace, or remove those profiles entirely. An attacker can strip protections from critical system services, lock all users out of remote access by targeting the SSH daemon, or bypass Ubuntu’s restrictions on unprivileged user namespaces, even after all previously known workarounds were closed,” the advisory said. From profile manipulation to root shell The blog post detailed a full privilege escalation chain demonstrated on a default Ubuntu Server installation with the Postfix mail server. By loading a crafted security profile that blocks a specific privilege-dropping capability in Sudo, the researchers said they forced Sudo into a “fail-open” condition: unable to shed its root privileges before invoking the system’s mail agent, Sudo runs the process as root while preserving the attacker’s environment. The result is arbitrary command execution as root, the researchers wrote. “These findings expose critical gaps in our reliance on default security assumptions,” the blog post said. “It fundamentally undermines system confidentiality, integrity, and availability globally.” “CrackArmor proves that even the most entrenched protections can be bypassed without admin credentials,” Qualys CTO Dilip Bachwani said in the blog post. “For CISOs, this means patching alone isn’t enough; we must re-examine our entire assumption of what ‘default’ configurations mean for our infrastructure.” This is not the first time Qualys researchers have uncovered serious privilege escalation vulnerabilities in default Linux components. In 2022, the company disclosed two flaws in Snap, Ubuntu’s universal application packaging system, that similarly allowed a low-privileged user to execute malicious code as root. Kernel-level bugs compound the risk Beyond the profile-manipulation vector, Qualys said it identified four kernel-level vulnerabilities within AppArmor’s own code. One flaw can be exploited to crash the entire system by forcing a reboot, the advisory said. Another one allows an attacker to read protected kernel memory, exposing internal addresses that security mitigations are designed to hide and making follow-on exploits easier to execute. Two other vulnerabilities were each demonstrated as independent paths to full root access, even on systems with modern exploit mitigations enabled by default, the blog post said. AppArmor has previously been cited as a key mitigating control against other Linux vulnerabilities. When the Dirty Pipe privilege escalation flaw threatened container environments in 2022, AppArmor was among the hardening measures recommended to limit exposure. No CVE numbers, but patches are available No CVE identifiers have been assigned to any of the nine vulnerabilities as of publication. The Linux kernel CVE assignment process intentionally delays issuing identifiers until one to two weeks after a fix lands in a stable release, the researchers said in the blog post. “Don’t let the absence of a CVE number downplay the significance,” the researchers wrote in the blog post. “If you’re running affected versions, treat this advisory seriously and update accordingly.” The company added that patches were published in Linus Torvalds’ upstream kernel tree on March 12, following a coordinated disclosure process involving Ubuntu’s security team, Canonical’s AppArmor developers, Debian, SUSE, and Sudo’s maintainer that stretched over eight months. “Immediate kernel patching remains the non-negotiable priority for neutralizing these critical vulnerabilities,” the researchers wrote in the blog post. View the full article

Cybercriminals are combining compromised websites with increasingly sophisticated ClickFix social engineering lures to deliver new infostealer malware, with one campaign alone weaponizing more than 250 WordPress sites across 12 countries. The campaign leads to stealthy in-memory payloads, while a separate attack detected by Microsoft targets Windows Terminal for payload execution instead of the traditional Run dialog. The WordPress campaign has been active since December 2025 and targets visitors with fake Cloudflare CAPTCHA challenges, researchers from security firm Rapid7 revealed in a report this week. The compromised WordPress websites span regional news outlets, local business websites, and even a US Senate candidate’s official webpage. “The large-scale execution of the compromise across completely unrelated WordPress instances suggests a high level of automation by the threat actor and is likely part of an organized long-term criminal effort,” the researcher said. Detection evasion The WordPress ClickFix campaign delivers three separate infostealer payloads — two of them previously unknown — and uses domain infrastructure that appears to have been set up since July 2025. The attackers disguise their injected JavaScript snippet as a performance optimizer that triggers only if the visitor’s browser doesn’t have a WordPress admin cookie. This technique is intended to hide the malicious behavior from website administrators. The script fetches a fake Cloudflare CAPTCHA verification challenge from one of 14 attacker-controlled domains, all resolving to a single IP address. The fake CAPTCHA instructs visitors to copy and paste a command in the Windows Run dialog. The rogue command consists of obfuscated JavaScript and PowerShell code that launches an in-memory shellcode loader dubbed DoubleDonut Loader. The loader injects payloads directly into legitimate Windows processes and uses reflected code loading. “The malware chain is executed almost entirely in memory and in the context of inconspicuous Windows processes, making traditional file-based detection ineffective,” Rapid7 wrote. The compromised sites didn’t share the same vulnerable WordPress version or plugin, suggesting that the attackers may be exploiting weak credentials or using exploits for multiple vulnerabilities. New payloads The DoubleDonut Loader was observed delivering a new variant of Vidar Stealer, a well-known infostealer, that uses a dead drop resolver technique to retrieve its command-and-control configuration and dynamic API resolution. In addition to Vidar, two previously undocumented infostealers have been observed, one written in .NET and one in C++. Rapid7 has named these new programs Impure Stealer and VodkaStealer and both use detection evasion techniques, including non-standard data encoding and symmetric encryption for command-and-control communications or sandbox environment detection using system and time-based checks. ClickFix is a growing threat In addition to new payloads, attackers are also evolving their ClickFix lures. A separate campaign identified by Microsoft’s Threat Intelligence team replaced the common Windows Run dialog (Win+R) with the Windows Terminal app (Win+X) for command execution. That campaign delivered the well-known Lumma Stealer and NetSupport RAT. A second payload involved a VBScript chain executed through MSBuild that used a technique known as etherhiding to download credential harvesting code. Security firm ESET estimated that ClickFix attacks surged 517% last year, with multiple variations dubbed CrashFix, ConsentFix, and PhantomCaptcha, each with different lures and delivery mechanisms. This basic social engineering tactic has proved so effective that even nation-state groups such as North Korea’s Lazarus group, Iran’s MuddyWater, and Russia’s APT28 have adopted it. In January, researchers from Sekoia reported that a separate ClickFix framework dubbed IClickFix had been injected into over 3,800 WordPress sites since 2024. WordPress site operators should ensure their admin login panels are not publicly exposed, since Rapid7 noted that nearly all sites compromised in the campaign it discovered had accessible admin pages. Rapid7 published indicators of compromise and YARA detection rules on its public GitHub repository. View the full article

Das Open Web Application Security Project (OWASP) gibt Unternehmen eine Checkliste für (mehr) GenAI-Sicherheit an die Hand. Foto: Gannvector | shutterstock.com Während Unternehmen wie OpenAI, Anthropic, Google oder Microsoft aber auch Open-Source-Alternativen bei ihren Generative-AI– und Large-Language-Model-Angeboten exponentielle User-Zuwächse verzeichnen, sind IT-Sicherheitsentscheider bemüht, mit der rasanten KI-Entwicklung in ihren Unternehmen Schritt zu halten. Die Non-Profit-Organisation OWASP trägt dieser Entwicklung mit einer neuen Veröffentlichung Rechnung: der “LLM AI Cybersecurity & Governance Checklist“. LLM-Bedrohungskategorien Das Thema KI ist ziemlich umfangreich, weswegen die OWASP-Checkliste vor allem darauf abzielt, Führungskräfte dabei zu unterstützen, die wesentlichen Risiken im Zusammenhang mit generativer KI und großen Sprachmodellen möglichst schnell zu identifizieren und entsprechende Abhilfemaßnahmen einzuleiten. Das soll gewährleisten, dass Unternehmen über die nötigen, grundlegenden Sicherheitskontrollen verfügen, um generative KI und LLM-Tools, -Services und Produkte sicher einzusetzen. Dabei betont OWASP, dass die Checkliste keinen Anspruch auf Vollständigkeit erhebt und sich mit zunehmender Reife der Technologie und Tools ebenfalls weiterentwickeln wird. Die Sicherheitsexperten ordnen LLM-Bedrohungen in verschiedene Kategorien ein, wie die nachfolgende Abbildung veranschaulicht: Die OWASP KI-Bedrohungs-Map. Foto: OWASP Geht es darum, eine LLM-Strategie festzulegen, müssen Unternehmen vor allem mit den einzigartigen Risiken umgehen, die generative KI und LLMs aufwerfen. Diese müssen durch organisatorische Governance und entsprechende Security-Kontrollen minimiert werden. Im Rahmen ihrer Veröffentlichung empfehlen die OWASP-Experten Unternehmen einen sechsstufigen Ansatz, um eine wirksame LLM-Strategie zu entwickeln: Mit OWASP in sechs Schritten zum LLM-Deployment. Foto: OWASP Auch hinsichtlich der Deployment-Typen in Sachen LLM empfiehlt OWASP, ganz genau hinzusehen und entsprechende Überlegungen anzustellen: Welche Art von KI-Modell ist für Sie die richtige? Foto: OWASP Die OWASP-KI-Checkliste Im Folgenden haben wir die von OWASP veröffentlichte Checkliste etwas “aufgedröselt”. Folgende Bereiche sollten Sie im Rahmen Ihrer Generative-AI- respektive LLM-Initiativen unbedingt prüfen. Adversarial Risk Dieser Bereich umfasst sowohl Wettbewerber als auch Angreifer und konzentriert sich nicht nur auf die Angriffs-, sondern auch auf die Unternehmenslandschaft. In diesen Bereich fällt beispielsweise, zu verstehen, wie die Konkurrenz KI einsetzt, um bessere Geschäftsergebnisse zu erzielen und die internen Prozesse und Richtlinien (beispielsweise Incident-Response-Pläne) zu aktualisieren, um für Cyberangriffe und Sicherheitsvorfälle im Zusammenhang mit generativer KI gewappnet zu sein. Threat Modeling Die Bedrohungsmodellierung gewinnt im Zuge des von zahlreichen Security-Institutionen propagierten “Secure-by-Design”-Ansatzes zunehmend an Bedeutung. In diesen Bereich fallen etwa die Überlegungen, wie Angreifer LLMs und generative KI für schnellere Exploits nutzen können, wie Unternehmen schadhafte KI-Nutzung erkennen können und wie sich die Technologie über interne Systeme und Umgebungen absichern lässt. KI-Bestandsaufnahme “Man kann nichts schützen, von dessen Existenz man nichts weiß” greift auch in der Generative-AI-Welt. Im Bereich der KI-Bestandsaufnahme geht es darum, Assets für intern entwickelte Lösungen und externe Tools und Plattformen zu erfassen. Dabei ist nicht nur wichtig, die Tools und Services zu kennen, die genutzt werden, sondern auch über die Verantwortlichkeiten Bescheid zu wissen. OWASP empfiehlt zudem, KI-Komponenten in SBOMs zu erfassen und Datenquellen nach Sensibilität zu katalogisieren. Darüber hinaus sollte es auch einen Prozess geben, der gewährleistet, dass zukünftige Tools und Services aus dem unternehmerischen Inventar sicher ein- und ausgegliedert werden können. KI-Security- und -Datenschutz-Schulungen Der Mensch ist das schwächste Glied in der Sicherheitskette – heißt es oft. Das muss allerdings nicht so sein – vorausgesetzt, Unternehmen integrieren KI-Sicherheits- und Datenschutztrainings in ihre GenAI-Journey. Das beinhaltet beispielsweise, der Belegschaft ein Verständnis über aktuelle AI- und LLM-Initiativen zu vermitteln – genauso wie zur Technologie an sich und den wesentlichen Problemen im Bereich Security. Darüber hinaus ist in diesem Bereich eine Kultur unabdingbar, die von Trust und Transparenz geprägt ist. Das ist auch ein ganz wesentlicher Punkt, um “Schatten-KI” zu verhindern. Anderenfalls werden Plattformen heimlich genutzt und die Security untergraben. Business Cases für KI etablieren Ganz ähnlich wie zuvor bei der Cloud erstellen die meisten Unternehmen keine kohärenten, strategischen Geschäftsmodelle für den Einsatz neuer Technologien – auch nicht, wenn es um generative KI und LLMs geht. Sich von Hype und FOMO anstecken zu lassen, ist relativ schnell geschehen – ohne soliden Business Case riskieren Unternehmen aber nicht nur, schlechte Ergebnisse zu erzielen. Governance Ohne Governance ist es nahezu unmöglich, Rechenschaftspflicht und klare Zielsetzungen zu realisieren. In diesen Bereich der OWASP-Checkliste fällt beispielsweise, ein RACI-Diagramm zu erstellen, dass die KI-Initiativen eines Unternehmens dokumentiert, Verantwortlichkeiten zuweist und unternehmensweite Richtlinien und Prozesse etabliert. Rechtliches Die rechtlichen Auswirkungen von KI sollten keinesfalls unterschätzt werden – sie entwickeln sich rasant weiter und können Reputation und finanziellem Gefüge potenziell beträchtliche Schäden zufügen. In diesen Bereich können diverse Aspekte fallen – zum Beispiel: Produktgarantien im Zusammenhang mit KI, KI-EULAs oder Intellectual-Property-Risiken. Kurzum: Ziehen Sie Ihr Legal-Team oder entsprechende Experten hinzu, um die verschiedenen rechtsbezogenen Aktivitäten zu identifizieren, die für Ihr Unternehmen relevant sind. Regulatorisches Aufbauend auf den juristischen Diskussionen entwickeln sich auch die regulatorischen Vorschriften schnell weiter – ein Beispiel ist der AI Act der EU. Unternehmen sollten deshalb die für sie geltenden KI-Compliance-Anforderungen ermitteln. LLM-Lösungen nutzen oder implementieren Der Einsatz von LLM-Lösungen erfordert spezifische Risiko- und Kontrollüberlegungen. Die OWASP-Checkliste nennt in diesem Bereich unter anderem die Aspekte: Access Control umsetzen, KI-Trainings-Pipelines absichern, Daten-Workflows mappen und bestehende oder potenzielle Schwachstellen in LLMs und Lieferketten identifizieren. Darüber hinaus sind kontinuierliche Audits durch Dritte, Penetrationstests und auch Code-Reviews für Zulieferer empfehlenswert. Testing, Evaluierung, Verifizierung, Validierung (TEVV) Der TEVV-Prozess wird vom NIST in seinem AI Framework ausdrücklich empfohlen. Dieser beinhaltet: Continuous Testing, Evaluierungen, Verifizierungen und Validierungen sowie Kennzahlen zu Funktionalität, Sicherheit und Zuverlässigkeit von KI-Modellen. Und zwar über den gesamten Lebenszyklus von KI-Modellen hinweg. Modell- und Risikokarten Für den ethischen Einsatz von großen Sprachmodellen sieht die OWASP-Checkliste Modell- und Risiko-“Karten” vor. Diese können den Nutzern Verständnis über KI-Systeme vermitteln und so das Vertrauen in die Systeme stärken. Zudem ermöglichen sie, potenziell negative Begleiterscheinungen wie Bias oder Datenschutzprobleme offen zu thematisieren. Die Karten können Details zu KI-Modellen, Architektur, Trainingsmethoden und Performance-Metriken beinhalten. Ein weiterer Schwerpunkt liegt dabei auf Responsible AI und allen Fragen in Zusammenhang mit Fairness und Transparenz. Retrieval Augmented Generation Retrieval Augmented Generation (RAG) ist eine Möglichkeit, die Fähigkeiten von LLMs zu optimieren, wenn es darum geht, relevante Daten aus bestimmten Quellen abzurufen. Dazu gehört, vortrainierte Modelle zu optimieren und bestehende auf neuen Datensätzen erneut zu trainieren, um ihre Leistung zu optimieren. OWASP empfiehlt, RAG zu implementieren, um den Mehrwert und die Effektivität großer Sprachmodelle im Unternehmenseinsatz zu maximieren. KI-Red-Teaming Last, but not least empfehlen die OWASP-Experten auch, KI-Red-Teaming-Sessions abzuhalten. Dabei werden Angriffe auf KI-Systeme simuliert, um Schwachstellen zu identifizieren und existierende Kontroll- und Abwehrmaßnahmen zu validieren. OWASP betont dabei, dass Red Teaming für sich alleine keine umfassende Lösung respektive Methode darstellt, um Generative AI und LLMs abzusichern. Vielmehr sollte KI-Red-Teaming in einen umfassenderen Ansatz eingebettet werden. Essenziell ist dabei jedoch laut den Experten insbesondere, dass im Unternehmen Klarheit darüber herrscht, wie die Anforderungen für Red Teaming aussehen sollten. Ansonsten sind Verstöße gegen Richtlinien oder gar juristischer Ärger vorprogrammiert. (fm) View the full article

Threat actors are exploiting two high severity zero day vulnerabilities in the Chrome browser that experts say IT teams must patch immediately. Google has issued emergency patches for the two holes, CVE-2026-3909 and CVE-2026-3910. This comes just days after the release of 29 fixes for holes as part of March Patch Tuesday, and a zero day patch released in February. Affected are browsers before version 146.0.7680.75. These exploits provide yet another reason why infosec leaders need to ensure there’s a corporate patching strategy in place for all authorized browsers and plugins. “If you’re not managing browser patches, your odds of getting pwned are increasing daily,” said David Shipley of Canadian-based security awareness training provider Beauceron Security. CVE-2026-3910 allows a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page, because of an inappropriate implementation within Chrome’s V8 JavaScript and WebAssembly engine. CVE-2026-3909 allows a remote attacker to perform out of bounds memory access via a crafted HTML page; the cause is an out of bounds write in Chrome’s Skia graphics library. Accessing browser memory could result in the loss of sensitive corporate information, noted Shipley. Following company policy, Google isn’t releasing details about the bugs until a majority of users are updated with a fix. Browsers a prime target Browsers are a prime target for threat actors because they are a tool everyone online uses. A 2025 report by Omdia for Palo Alto Networks estimated that, in a 12 month period, 95% of organizations suffered a security incident originating from an employee’s browser. Because of this, one expert has noted that adversaries now target the browser directly, with attacks like cross-site scripting (XSS), session hijacking via stolen tokens, and advanced phishing that bypasses traditional MFA. A browser-centric zero trust framework is the necessary response, he argued. [Related content: Picking a secure enterprise browser] These new flaws underscore the reason why browser engines remain among the most attractive targets for attackers, noted Jack Bicer, director of vulnerability research at Action1. “With active exploitation already confirmed, organizations that delay updates risk exposing users to drive-by attacks delivered through compromised or malicious websites.” Chromium and all Chromium-based browsers, including Chrome, Edge, and others, must be updated to the latest security versions as soon as possible, he said. Admins should also ensure that automatic updates are enabled across enterprise endpoints, monitor for outdated browser versions, and consider browser isolation technologies to reduce exposure to web-based attacks. Scott Caveza, senior staff research engineer at Tenable, agreed that the latest two zero days should be on the radar of any organization where Chrome is actively installed. While Google hasn’t provided details on the abuse of these flaws, he noted that most browser-related exploits do require a victim to visit a crafted website, making attacks more likely to be targeted. Fortunately, he added, updating Chrome is fast and easy, and many installations leave automatic updates enabled. “We know attackers are opportunistic, and when they set their sights on one of the most widely installed browsers in the market, it’s imperative that teams are taking action now to ensure updates are applied as soon as possible,” he said. View the full article

The FBI is so concerned about the threat of residential proxy attacks and the dangers posed by cyber criminals using the technique that it has posted guidance on its website. Residential proxies are used by cybercriminals to reroute traffic between individuals and the websites they visit to make it appear to originate elsewhere? By taking over IoT devices, smartphones, or home routers, cybercriminals can mask their illegal online activities. But it’s not just consumers who are at risk: Enterprises can be the targets of those illegal activities — and their devices can be taken over too. Older devices are particularly soft targets. The FBI urged enterprises to install software updates as they become available to help protect devices from being infected, and to enforce strong device policies to stop employees connecting unauthorized devices to corporate networks. It also encouraged them to segment networks, block IP addresses known to be associated with residential proxy networks, and implement stronger firewall rules. There has been one major proxy attack already this year. In January, nine million Android devices were exposed. The threat to enterprises is deep-seated. Last month, cyber security company Spur identified vulnerable proxy exposure across 671 government entities, 263 energy and utility organizations, and nearly 1,900 education environments. “Residential proxies are effective because they let bad actors blend into normal internet traffic. A lot of security teams know how to look for suspicious infrastructure. It gets harder when the traffic comes through real residential connections that appear legitimate on the surface,” Spur co-founder Riley Kilmer said via email. View the full article

Backup vendor Veeam has released security updates to patch multiple vulnerabilities in its widely used Backup and Replication platform, including three critical flaws that could allow authenticated users to execute code on backup servers. Detailed in the company’s advisory KB4830, the vulnerabilities affect Veeam Backup & Replication 12.3.2.4165 and earlier version 12 builds, with fixes now available in build 12.3.2.4465. The disclosure covers five security issues in total, including three remote code execution (RCE) bugs and two high-severity vulnerabilities enabling file manipulation or privilege escalation. Each of the three critical flaws carries a CVSS score of 9.9 out of 10 and allows authenticated users to execute code on backup infrastructure components under certain conditions. Backup systems have become increasingly valuable targets for attackers, particularly ransomware operators, because compromising them can undermine recovery capabilities and enable data destruction or exfiltration at scale. Flaws allow privilege escalation and RCE The most serious issues addressed in the advisory are the RCE bugs that an authenticated domain user can exploit to execute code on the Veeam Backup Server or associated components. In practice, this means an attacker who already has some level of access within the environment, such as through compromised credentials, could leverage the flaws to take control of backup infrastructure. The three bugs are tracked as CVE-2026-21666, CVE-2026-21667, and CVE-2026-21708. The advisory also details two high-severity flaws. CVE-2026-21668 allows attackers with repository access to manipulate arbitrary files on backup infrastructure, potentially affecting stored backup data, and CVE-2026-21672, a local privilege escalation flaw, could enable attackers who already have limited access to elevate their privileges on the Veeam servers. The advisory said that some vulnerabilities were reported through Veeam’s bug bounty program on HackerOne, while others were discovered during internal testing. While Veeam did not mention any in-the-wild exploitation, the Backup and Replication bugs have been repeatedly weaponized in the past. Patches are available Veeam warned that organizations should apply the patched build promptly, noting that vulnerability disclosures frequently trigger attempts by attackers to reverse-engineer patches and develop exploits for unpatched systems. The issues were fixed in Veeam Backup & Replication 12.3.2.4465, and organizations running unsupported or older builds should assume they are vulnerable and upgrade immediately. The urgency around the latest bugs is amplified by the fact that Veeam Backup & Replication has repeatedly faced critical vulnerabilities in recent years, some of which have been actively exploited by attackers. In 2024, security agencies warned that ransomware groups were exploiting CVE-2024-40711, a critical flaw in the platform that allowed remote code execution without authentication. Attackers used the vulnerability to compromise backup servers and delete recovery data as part of ransomware campaigns. The pattern continued in 2025, when Veeam patched CVE-2025-23120, another critical RCE bug that allowed any authenticated domain user to execute code on a backup server in domain-joined environments. The steady stream of high-severity bugs, along with the history of real-world exploitation, makes timely patching critical for organizations running Veeam Backup & Replication. Organizations must treat backup systems as highly privileged infrastructure requiring strong access controls and isolation. View the full article

I used to think hybrid incidents would get easier once we standardized on “one tool”: one monitoring platform, one ticketing system, one on-call process. After a few real outages, I changed my mind. Hybrid response fails at the seams between ownership models: on-prem teams, cloud teams, security, vendors. Each group can be correct inside its boundary and still miss the end-to-end truth. What follows is the operating model I use to keep incident response predictable across on-prem, cloud and SaaS. It is designed for the world most CIOs actually run: mixed environments, mixed tooling, mixed control. Start with one incident language, not one tool Tool consolidation is slow. A shared incident language is fast. I treat it as a contract: the minimum set of rules and artifacts that must exist in every major incident, regardless of the stack. When I need a canonical lifecycle, I loosely align the phases with the NIST Computer Security Incident Handling Guide and then translate them into our operational reality. My non-negotiables are simple: Severity is driven by customer impact, not by who is paged We maintain one current hypothesis, even if it is wrong We keep one shared timeline that captures decisions, not just symptoms We communicate on a predictable cadence, even when answers are incomplete Every action has a named owner and an explicit “time we expect to learn” The biggest behavior change is eliminating parallel war rooms. Hybrid incidents love to spawn them: the on-prem team on a bridge, the cloud team in chat, the SaaS vendor in email. All of them produce plausible narratives and none of them converge. I now insist on one incident channel, one incident commander and domain leads (on-prem, cloud, SaaS, identity, network, security) participating in the same thread. If your organization is new to incident command, keep roles lightweight: Incident commander: drives process and timeboxing Operations lead: coordinates mitigations and verifies outcomes Communications lead: writes customer and executive updates Domain leads: provide diagnosis and execute changes in their area For communications, I use the same four lines every update: What we know (facts, scope, user impact) What we suspect (hypotheses and confidence) What we are doing next (actions, owners) Next update time This prevents two common failure modes: false certainty early, and vague reassurance that sounds good but does not enable decisions. The litmus test is whether someone joining late can understand impact, direction and next learning step in under a minute. Incident #1: A hybrid latency event where on-prem storage, cloud services and a SaaS dependency each looked “healthy” locally, and only the user journey signal exposed the shared failure. Make telemetry portable across domains In hybrid environments, the most expensive minute in an incident is the one where each team shows a dashboard proving their component is fine. The fix is not buying a better tool. The fix is defining a minimum viable telemetry standard that every domain must provide so signals can cross boundaries. I standardize on three layers. 1) User journey signals (shared truth) Pick a small set of end-to-end journeys that matter to the business and instrument them aggressively. User journeys cut through domain bias because they measure outcomes, not infrastructure. I typically start with Authentication or login A primary transaction (purchase, submit, enroll) A key read path (search, browse, view) For each, I want latency, error rate and a volume signal. If a SaaS provider sits in that path, the journey must explicitly include it. These metrics become the court of record for severity, blast radius and recovery. 2) Correlation (faster triage than perfect visibility) Distributed tracing is ideal, but I do not wait for it. I prioritize any identifier that can be propagated across environments. If you are standardizing tracing, the OpenTelemetry documentation is a practical starting point because it focuses on portable primitives rather than a single vendor’s toolchain. Trace and span IDs when available Request or transaction IDs that traverse services Session IDs for user journeys If you cannot correlate, you cannot respond quickly. I also treat clock discipline as operational risk. Misaligned time zones and imprecise timestamps turn correlation into guesswork, especially when SaaS logs arrive late or at coarse granularity, so I require basic NTP hygiene anchored to the Network Time Protocol (NTP) specification (RFC 5905). 3) Change signals (the missing bridge) Most hybrid “mystery incidents” are change-related, but change evidence is fragmented. Cloud has a deploy history, on-prem has maintenance tickets and SaaS has a status note hours later. During incidents, I maintain a single change table in the timeline with: What changed, where and when How reversible it is Whether it is suspected, ruled out or confirmed This is enough to support decisions like “rollback now” or “pause releases for 24 hours” without relying on memory. Incident #2: A cross-environment authentication failure where a network change, a token validation dependency and a vendor-side issue created competing narratives until correlation IDs and journey metrics aligned the timeline. Design escalation paths for on-prem and SaaS like they are part of your team Hybrid response is often limited by control. If the fix lives behind a vendor queue or a data center operations process, escalation becomes your critical path. I treat escalation as an engineering problem to solve before the incident. Here are the three practices that consistently reduce dead time. Define “time to human” targets Contractual response times are not the same as reaching an empowered engineer. For each critical SaaS provider and on-prem operations group, I document expected time to human and escalation ladders. If the realistic time is longer than your tolerance for a Sev 1, you need a mitigation strategy that does not depend on immediate vendor action. The details that always burn minutes Every escalation starts with the same friction: account validation, environment identifiers, proof of impact. I maintain a one-page escalation card for each critical provider with contacts, entitlements, service names we consume and the evidence we can provide fast (timestamps, correlation IDs, screenshots). For on-prem, I do the equivalent hands and eyes card so access or physical checks do not stall on shift coverage. Use a rollback, failover and degradation decision matrix Hybrid incidents create false debates. Teams argue “fail over or roll back” when the real question is “what action gives us the fastest learning with the least irreversible risk.” My decision matrix scores options on: Reversibility (can we undo it quickly) Scope (blast radius) Time to learn (how fast we will know if it worked) This also formalizes graceful degradation as a resilience tool. If you can preserve a read path while write is impaired, or reduce authentication throughput safely, you protect the business while you learn. If you want a month-one sequence that works without a replatform, implement it in order: publish the incident contract and enforce one war room, instrument three user journeys across environments, standardize correlation IDs and time discipline, then build escalation cards for top dependencies and adopt the decision matrix. Hybrid resilience is not a technology project. It is seam management. The goal is to reduce ambiguity under pressure by aligning language, signals and escalation before you need them. If you do only three things next month, do these: Instrument end-to-end user journeys and treat them as shared truth. Enforce one incident contract with one timeline and one incident commander. Engineer escalation with targets, cards and a rollback or failover decision matrix. Disclosure: The views expressed are my own and do not necessarily reflect the views of my employer. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Microsoft has warned enterprises that cybercriminal group Storm-2561 is hijacking search engine results to serve trojanized VPN clients, stealing corporate credentials, and then covering its tracks before victims suspect anything is wrong. The group pushes spoofed websites to the top of results for queries such as “Pulse VPN download” or “Pulse Secure client,” redirecting users to digitally signed malware hosted on GitHub, Microsoft Threat Intelligence said in an advisory. “The techniques they used in this campaign highlight how threat actors continue to exploit trusted platforms and software branding to avoid user suspicion and steal sensitive information,” the advisory said. Microsoft Defender Experts first detected the activity in mid-January 2026, though the threat actor has been active since May 2025 and is known for distributing malware through search engine optimization (SEO) poisoning and impersonating popular enterprise software vendors, the advisory said. The campaign comes as infostealers grow more dangerous. Security researchers have noted that infostealers are increasingly paired with remote access trojans, giving attackers both stolen credentials and persistent network access from a single infection. Storm-2561 follows that pattern precisely. Inside the attack chain Microsoft observed fake pages impersonating Fortinet, Ivanti, Cisco, SonicWall, Sophos, Checkpoint, and WatchGuard, along with two domains — vpn-fortinet[.]com and ivanti-vpn[.]org — hosting malicious ZIP files on GitHub, the advisory said. The malware itself arrives as a ZIP file containing a Windows Installer package. When a user launches the downloaded installer, it drops a fake Pulse Secure application into a directory that closely mimics a legitimate Pulse Secure installation path, Microsoft said. “This installation path blends in with legitimate VPN software to appear trustworthy and avoid raising user suspicion,” the advisory noted. The installer side-loads two malicious DLL files alongside the fake application. One acts as an in-memory loader. The other, inspector.dll, is a variant of the Hyrax infostealer. It extracts stored VPN credentials and URI data and exfiltrates them to attacker-controlled infrastructure, the advisory added. “The malicious ZIP files that contain fake installer files are hosted on GitHub repositories, which have since been taken down,” the advisory noted. The delivery method closely resembles tactics seen in recent campaigns. In August 2025, researchers at Arctic Wolf uncovered GPUGate malware distributed via GitHub repositories and Google Ads, using MSI-packaged payloads and credential exfiltration in a near-identical delivery chain, suggesting threat actors are converging on a common playbook. Signed certificates used to evade detection The MSI file and malicious DLLs are signed with a valid digital certificate from “Taiyuan Lihua Near Information Technology Co., Ltd.,” Microsoft said. It allowed the malware to bypass Windows security warnings for unsigned code, potentially circumvent application whitelisting policies, and reduce alerts from tools focused on unsigned executables. That certificate has since been revoked, the advisory added. Microsoft identified several additional files signed with the same certificate, all masquerading as VPN software from different vendors. Attackers cover their tracks after credential theft After capturing them, the fake client displays an error message indicating installation has failed, the advisory said. It then directs the user to download the legitimate VPN client from the official vendor site. “In certain instances, opens the user’s browser to the legitimate VPN website,” Microsoft said. If the real VPN installs and works as expected, the victim has no indication of compromise. Storm-2561 also establishes persistence through the Windows RunOnce registry key, ensuring the malware runs on every reboot, the advisory noted. The post-credential redirection strategy eliminates behavioral anomalies that might otherwise trigger a security review. SEO poisoning campaigns have long relied on misdirection to avoid leaving forensic footprints. Storm-2561 takes that further by redirecting victims to legitimate software after the theft, leaving no obvious trace of compromise. Mitigations Microsoft recommended organizations enforce multifactor authentication on all accounts without exception. Enterprise credentials should not be stored in browser-based password vaults secured with personal credentials. Organizations should also disable browser password syncing on managed devices through Group Policy, the advisory added. On the endpoint side, Microsoft advised running endpoint detection and response in block mode and enabling network protection and web protection in Microsoft Defender for Endpoint. “Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware,” the advisory said. View the full article

Industry has comforted itself with the idea that the perimeter is dead. It is not. What happened is far worse. We ignored the edge, let unsupported hardware decay in place, and effectively donated our perimeter to adversaries who were more than willing to accept it. The FBI’s Winter SHIELD effort is the operational side of the coin aimed at flipping the script and improving cyber resilience, showing how attackers exploit weak authentication, excessive privileges, and unpatched edge devices to gain their footholds. CISA’s BOD 26‑02 is the structural side, forcing the removal of the outdated edge hardware that makes those footholds possible. Together this advisory and directive are the US federal government’s acknowledgment that security leaders have been lagging on the fundamentals of cyber resiliency, and now we all need to catch up. Because, to be blunt, the picture is not just bad; it is untenable. BOD 26‑02 exposes a massive governance failure across all sectors: Organizations in every industry have treated asset lifecycles as an IT preference rather than a strategic requirement. As we all know, the federal government is rarely ahead of the modernization curve. And it still isn’t ahead today — but it is taking steps to catch up. In doing so, it has noted that far too many private sector entities are also lagging in securing their perimeters, and those organizations — and their security leaders — now need to catch up as well. Institutional failure: The place-to-stand problem The fallacy of the faded perimeter has taken hold in part due to a shift in security strategy due to the rise of the cloud. Here, the cybersecurity industry splits itself between architectural theory and tactical reality. One side insists that in a cloud-native world, identity is the only perimeter that matters. They argue that if you verify the user, the wire becomes irrelevant. But this ignores a brutal truth. For an adversary to log in, they first need a place to stand. We have confused the user’s mobility with the infrastructure’s stability. While a remote user needs a temporary session to work, an adversary needs a persistent foothold to stay. By neglecting the edge, organizations have inadvertently provided that staging ground. Our mounting technology debt is the prime evidence of this failure. We have chased zero trust software while leaving unpatched, end-of-life hardware to rust at the gate. These devices are not just old gear. They are donated assets that allow state-aligned actors to bypass identity controls entirely and sit, unmonitored, on the very fabric of the network. The tactical audit: Winter SHIELD and BOD 26‑02 The FBI’s Operation Winter SHIELD is a two-month national blitz focused on hardening the basics that attackers continue to exploit. It is not a routine awareness campaign. It is a concentrated push to expose weak authentication, excessive administrator rights, unpatched edge devices, and the lack of crisis readiness across organizations. The Bureau is using this short window to force attention on the fundamentals that have been ignored for too long. CISA’s BOD 26‑02 completes the pincer by mandating the removal of the very devices the FBI is highlighting as compromised. CISA gives government entities 18 months to comply. When these agencies move at the same time to address the edge, it is not a routine update. It is an admission that the lag has become a liability. The CISO’s reality: From awareness to execution This alignment demands a reorientation of the CISO’s posture. If the government can no longer tolerate the risk of unsupported edge gear, enterprises have no defensible reason to keep it plugged in. This is a survival requirement that demands total edge visibility and aggressive risk elimination. To meet the expectations set by Winter SHIELD, CISOs must take the following actions: Use strong, hardware-based authentication for all privileged and remote access. Limit administrator rights to temporary use only and monitor every elevation. Patch all internet-facing systems within 72 hours when a critical flaw appears. Remove permanent vendor access and require monitored, time-limited connections. Store device logs in a protected location where they cannot be altered or deleted. Keep at least one offline backup that cannot be changed by an attacker. Shut down unnecessary internet-exposed services, especially remote desktop and file sharing. Block email spoofing by enforcing strict domain authentication. Remove local administrator rights from users and require temporary elevation. Run regular crisis exercises with leadership to improve decision-making under pressure. BOD 26‑02 adds structural requirements that define the federal expectation for perimeter stewardship: Maintain a complete inventory of all edge devices, including firewalls, routers, and remote access appliances. Identify every device that is unsupported or past its service life. Remove or replace unsupported edge devices on a defined schedule and document completion. Establish a lifecycle process that tracks each device from purchase to retirement. Ensure all replacement devices meet current security standards before deployment. Provide ongoing confirmation that no unsupported devices remain on the perimeter. The straightforward reality The perimeter never disappeared. It was ignored. Unsupported firewalls, routers, remote access appliances, and edge boxes have always been predictable entry points. Attackers use them for footholds, lateral movement, and persistence. A neglected perimeter undermines every other investment you may have made. The FBI may be running a two-month sprint, but for a CISO these expectations do not end when the blitz ends. Strong authentication, tight privilege control, rapid patching, and disciplined logging are not short-term activities. They are lifetime responsibilities. And CISA has pulled the band aid off and exposed the reality of the risks of using equipment beyond their end of life. If your perimeter is running end-of-life gear, you are no longer defending. You are donating access. View the full article

Geht es um Security-Kennzahlen, sollten CISOs sich auf das Wesentliche fokussieren. Foto: Vadym Nechyporenko – shutterstock.com Die Security-Performance zu messen, gehört vielleicht nicht zu den aufregendsten Aufgaben eines CISOs – kann allerdings sehr nützlich sein, um eine ganze Reihe von Herausforderungen zu bewältigen. Neben der Erkenntnis darüber, wie effektiv ihre Security-Bemühungen sind, können Sicherheitsentscheider mit den richtigen Kennzahlen unter anderem auch strategisches Alignment mit dem Business demonstrieren. Um jedoch einen echten Nutzen aus den Metriken ziehen zu können, ist das oberste Gebot, sich auf diejenigen zu konzentrieren, die belegen, dass die Security das Business stützt. Kennzahlen, denen es an Bedeutung oder Kontext mangelt, sind hingegen zu vernachlässigen, wie Richard Absalom, Principal Research Analyst beim Information Security Forum, unterstreicht: “Man kann unzählige Dinge in Sachen Security Performance messen – was mit Blick auf Extraktion und Reporting viel Zeit, Mühe und Ressourcen kostet. Fragen Sie sich: Warum messen wir das? Wie hilft uns das? Welche Frage können wir damit beantworten? Wenn die Messung nicht dazu beiträgt, Stakeholdern oder Entscheidern wichtige Informationen zu liefern, wird sie sehr wahrscheinlich ignoriert.” 10 Security-Metriken, von denen CISOs profitieren Im Folgenden haben wir im Gespräch mit Experten und Entscheidern zehn Benefits identifiziert, die CISOs mit den jeweils richtigen Security-Metriken realisieren können. 1. Incident-Response-Metriken Mean Time to Detect (MTTD) oder Mean Time to Respond (MTTR) liefern beispielsweise quantitative Daten, die CISOs dabei unterstützen, objektive Entscheidungen zu treffen. Frank Kim, Fellow am SANS Institute, erklärt: “Indem sie wichtige Sicherheitsindikatoren analysieren und nachverfolgen, können CISOs Prioritäten setzen, Ressourcen zuweisen und sich auf die Bereiche konzentrieren, die am dringendsten optimiert werden müssen.” 2. Security-Investment-Metriken Beispielsweise zu wissen, wie hoch der Prozentsatz wichtiger Business-Initiativen mit eingebetteten Sicherheitsprozessen ist, kann CISOs dabei unterstützen, den Return on Investment (ROI) von Security-Initiativen gegenüber der Geschäftsleitung und den Stakeholdern nachzuweisen. Insofern aufgezeigt wird, wie diese Bemühungen zur Risikominderung und dazu beitragen, Zwischenfälle zu verhindern. “Die Stakeholder interessieren sich nicht für die Cyberrisiken, sondern die Geschäftsrisiken, die sich aus dem Cyberbereich ergeben”, konstatiert Brian Contos, ehemals CSO bei Sevco Security. Er fügt hinzu: “Genauer gesagt geht es dabei um Risiken im Zusammenhang mit Umsatz, Brands, Operations sowie ESG – Environmental, Social, Governance.” 3. Security-Awareness-Metriken In diesen Bereich fällt beispielsweise der Prozentsatz der Fachabteilungen, die an entsprechenden Programmen beteiligt sind. Diese Kennzahlen unterstützen dabei, zu ermitteln, ob im Unternehmen eine Security-Kultur existiert – oder entsteht. So lässt sich darstellen, wie effektiv entsprechende Initiativen auf die allgemeine Sicherheitslage des Unternehmens einzahlen – was für Sicherheitsentscheider traditionell eine Herausforderung darstellt. Fred Rica, ehemals Head of Cyber Practice bei KPMG und Partner beim Wirtschaftsprüfungsunternehmen BPM, erläutert: “CISOs, die dem Vorstand technische Kennzahlen präsentieren, schießen oft am Ziel vorbei, weil der Kontext fehlt. Dem Board mitzuteilen, dass 100.000 Events per Firewall blockiert wurden, wird ohne entsprechenden Kontext nicht fruchten.” 4. Vulnerability-Management-Metriken Metriken im Bereich Schwachstellenmanagement, wie das “Window of Exposure”, können CISOs dabei unterstützen, das Risikoprofil ihrer Organisationen besser zu verstehen und Bedrohungen aktiv zu begegnen. “Letztlich geht es darum, die zerbrochenen Fenster und unverschlossenen Türen eines Unternehmens anzugehen”, verbildlicht SANS-Experte Kim. “Vulnerability-Management-Metriken geben Aufschluss darüber, wie lange die Türen potenziell offenstehen und unterstützen dabei, tägliche Arbeitsabläufe zu etablieren, zum Beispiel im Bereich Scanning oder Patching.” 5. Security-Process-Improvement-Metriken Metriken zur Verbesserung von Sicherheitsprozessen erfassen den Fortschritt im Zeitverlauf und ermöglichen CISOs, spezifische Ziele zu setzen beziehungsweise zu verfolgen. Ein Beispiel für eine Kennzahl in diesem Bereich wäre der Prozentsatz von Vorfällen mit derselben wiederkehrenden Grundursache. “Dieser datengesteuerte Ansatz trägt zur kontinuierlichen Verbesserung der Sicherheitspraktiken bei und fördert eine Kultur der Verantwortlichkeit”, hält Kim fest. Anschließend könnten risikobasierte Metriken in Jahresberichte oder Corporate-Governance-Dokumente einfließen. 6. Security-Maturity-Metriken Metriken zum Security-Reifegrad – beispielsweise Capability Maturity Scores – lassen sich mit Branchen-Benchmarks (beispielsweise denen des Center for Internet Security) oder auch früheren Ergebnissen abgleichen. Das ermöglicht Sicherheitsentscheidern, den Security-Reifegrad ihrer Organisation zu verstehen, um im Anschluss realistische Sicherheitsziele und -strategien zu entwickeln. Laut Richard Absalom, Chefanalyst beim Internet Security Forum (ISF), sollten Sicherheitsverantwortliche nach Indikatoren und Metriken Ausschau halten, die Aufschluss darüber geben, wie gut die Organisation: Bedrohungen und gefährdete Assets identifiziert; die identifizierten Assets schützt; Bedrohungsereignisse erkennt; auf erkannte Ereignisse reagiert; sich nach Vorfällen erholt und deren Auswirkungen begrenzen kann. 7. Compliance-Metriken Da viele Vorschriften und Standards auch ein Reporting zu bestimmten Security-Metriken erfordern, ist es sinnvoll, über Compliance-Metriken zu verfügen – beispielsweise den Prozentsatz der Systeme, die mit bestimmten Anforderungen im Einklang stehen. Kim bringt es auf den Punkt: “Das erleichtert es, Compliance-Anforderungen zu erfüllen und potenzieller Strafzahlungen zu vermeiden.” 8. Threat-Detection-Metriken Kennzahlen im Bereich Bedrohungserkennung – wie die Anzahl der erkannten Vorfälle oder False-Positive/Negative-Raten – können als Frühwarnzeichen für potenzielle Sicherheitsvorfälle oder Schwachstellen in der Infrastruktur dienen. Das ermöglicht CISOs, Probleme aktiv anzugehen und größeren Sicherheitsverletzungen vorzubeugen. 9. Ressource-Utilization-Metriken Metriken zur Ressourcennutzung wie der prozentuale Anteil der Zeit, der für aktive gegenüber reaktiven Sicherheitsaufgaben aufgewendet wird, können CISOs in die Lage versetzen, ineffiziente Bereiche oder redundante Sicherheitskontrollen zu identifizieren. Das kann in der Konsequenz zu einer besseren Ressourcenzuweisung und damit zu Kostenoptimierungen führen. In Zeiten des immer noch ausgeprägten Security-Fachkräftemangels könnte das eine entscheidende Unterstützung für Sicherheitsverantwortliche darstellen. 10. Security-Transparency-Metriken Kennzahlen zur Security-Transparenz – etwa die Anzahl der dem Unternehmen mitgeteilten Sicherheitsvorfälle oder die Bewertungen der internen Stakeholder zur Security-Kommunikation – können das Vertrauen zwischen Security-Team und anderen Geschäftseinheiten stärken. “Wenn die Wirksamkeit von Sicherheitsmaßnahmen quantifiziert und transparent kommuniziert wird, stärkt das das Vertrauen in das Sicherheitsprogramm”, konstatiert SANS-Experte Kim. (fm) View the full article

Telus Digital, which provides business process outsourcing (BPO) services to a range of organizations worldwide, has been hit with a massive cyberattack conducted by extortion group ShinyHunters The group, which has been in operation since 2020, specializes in stealing data from Salesforce and other SaaS vendors, and has also recently been conducting voice phishing (vishing) attacks, impersonating IT staff to persuade employees to enter their credentials on malicious sites that harvest them. In a statement to CSO on Thursday, Telus Digital said it is “investigating a cybersecurity incident involving unauthorized access to a limited number of our systems. Upon discovery, we took immediate steps to address the unauthorized activity and secure our systems against further intrusion. We are actively managing the situation and continue to monitor it closely.” The statement went on to say, “all business operations within Telus Digital remain fully operational and there is no evidence of disruption to customer connectivity or services. As part of our response, we have engaged leading cyber forensics experts to support our investigation, and we are working with law enforcement.” The company added that it has implemented additional security measures “to further safeguard our systems and environment. As our investigation progresses, we are notifying any impacted customers, as appropriate. The security of our customers’ information continues to be our highest priority.” One published report stated that ShinyHunters claims to have stolen upwards of one petabyte of data from both the company and its customers, many of whom use Telus Digital as a BPO provider for their customer support operations. A company spokesperson was asked to confirm that number, but refused comment. Attackers now ‘better at being trusted’ Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, said the incident was not a perimeter failure, even though “when breaches of this magnitude occur, the instinct is often to ask which vulnerability was exploited and which malware got through.” He added that the Telus Digital data theft “increasingly points to a different problem, in that attackers no longer need to ‘break in’ if they can blend in. The hallmarks of this breach, like the multi-month dwell time, massive data volumes, and delayed detection, suggest the abuse of legitimate access rather than overt technical exploitation.” In other words, he said, the systems likely trusted the attacker, noting that, based on publicly available details, this incident aligns with a growing class of data theft first operations that include: Long-term persistence using valid credentials or trusted pathways Lateral movement across internal systems once inside Slow, controlled data staging to avoid triggering alerts Large-scale exfiltration disguised as normal encrypted traffic Public disclosure or extortion signaling once data is secured. According to Jean-Louis, “this is not smash-and-grab ransomware. It is strategic, disciplined, and optimized for maximum leverage. The [attack] actually exposes a blind spot many organizations still have: [they] are good at detecting ‘bad behavior,’ but not abnormal trusted behavior.” Priorities for mitigation This incident, he pointed out, reinforces the importance of several priorities for organizations, including: Regard identity as the new perimeter. If credentials are compromised, everything downstream is at risk. Enforce MFA everywhere, especially for admins and third parties. Data-centric monitoring is non-negotiable if organizations must know when data is accessed, aggregated, and moved. Set alerts for bulk access patterns, not just downloads, and set reasonable data movement thresholds by role Flat networks, he said, enable big breaches, and once attackers move laterally, scale becomes their advantage. His advice to CSOs is that they segment environments aggressively, isolate high-value data stores from general access, invest in behavioral analytics and threat hunting, and look for subtle anomalies over weeks, not just spikes over minutes. A strategic lesson from this breach is that organizations should prepare for data theft, not just ransomware, he said. “Many incident response plans still assume encryption equals impact and build playbooks for silent data exfiltration.” The biggest risk today, said Jean-Louis, “is not that attackers are getting better at breaking in; it’s that they’re getting better at being trusted. Organizations that continue to focus primarily on perimeter defenses and malware prevention will remain vulnerable to this class of attack.” View the full article

A major cyberattack on US medical supplies giant Stryker has resulted in thousands of devices being remotely wiped, after a pro-Iranian hacking group may have compromised the company’s Microsoft Intune management system. Details remain sketchy, but what appears to have happened on Wednesday at one of the world’s largest medical supplies companies could, if confirmed, yet rival the scale of the infamous 2012 Shamoon incident in which 30,000 computers belonging to Saudi Aramco were wiped. Stryker has 56,000 employees worldwide. In Ireland, thousands of Stryker employees were unable to log into their computers, while others around the globe took to Reddit and X to complain that multiple devices had been wiped. ‘No indication of malware’ “At this time, there is no indication of malware or ransomware and we believe the situation is contained to our internal Microsoft environment only,” read the company’s Thursday update. A day earlier, the severity of the ongoing disruption caused Stryker to file a more detailed report with the US Securities and Exchange Commission (SEC). “The incident has caused, and is expected to continue to cause, disruptions and limitations of access to certain of the Company’s information systems and business applications,” Stryker said. “While the Company is working diligently to restore affected functions and systems access, the timeline for a full restoration is not yet known.” Such a filing is only a requirement where a publicly-traded company suffers an attack that investors might consider to be materially significant. The fact that multiple devices were affected, including BYOD mobile devices, points to a compromise of the company’s Microsoft Intune management system. While this has not been confirmed, a successful Intune compromise would have allowed the attackers to wipe devices remotely, without having to deploy malware. Handala claims credit The Handala threat group quickly claimed responsibility for the attack. While the group’s involvement is just a claim for now, Stryker employees reportedly saw a version of the Handala logo – a cartoon of a Palestinian boy with his back turned and hands crossed behind him – on affected devices. Handala’s identity is hard to ascertain. Palo Alto has connected it to Iran’s Ministry of Intelligence and Security (MOIS) via a second identity, Void Manticore. Other security vendors use different names, including Banished Kitten, and Storm-842. The group’s political motivation is less mysterious. In a website statement, the group styled the cyberattack as a response to the February 28 attack on a school in the Iranian city of Minab, which killed up to 170 children and adults. “We announce to the world that in retaliation for the brutal attack on the Minab school and in response to ongoing cyber assaults against the infrastructure of the Axis of Resistance, our major cyber operation has been executed with complete success,” it said. “In this operation, over 200,000 systems, servers, and mobile devices have been wiped and 50 terabytes of critical data have been extracted.” Critical flaw If Intune was the route to compromise, the first job for Stryker’s forensics team will be to work out how attackers got into the system. “Stryker uses Entra for authentication, which integrates everything into this with single sign-on, including the software that builds and updates all devices, including servers, laptops, and phones,” commented Rob Demain, CEO of security managed security company, e2e-assure. “This is a best practice design pattern, but with a critical flaw: if it’s compromised, the attacker has access to wipe all devices, which seems to be what has happened here. Initial access is likely to be via credential theft, typically Adversary-in-the-Middle (AitM).” Compromising such a critical system suggests a significant security failure, said Jon Abbott, CEO and co-founder of security management company ThreatAware. “The attackers have either tricked the helpdesk into resetting admin credentials, as we saw with the Scattered Spider attacks, taken over an admin’s machine, or spear phished an admin directly,” said Abbott. “It seems unlikely the attackers could have pulled this off without someone making a critical basic mistake. Anyone granting access to an admin account needs to step up their verification checks. Many of our clients now require three-way video calls before resetting admin credentials, bringing together the admin, their manager, and the service desk operator.” Security companies predicted that pro-Iranian groups would target US companies with wiping attacks when the war started. This is a rise in threat level with a clear message: Iranian nation state actors are now aggressively targeting US companies and their supply chains, and will spare nobody. Every weakness and mistake will be leveraged. View the full article

Last year’s “PhantomRaven” supply-chain campaign is back, with security researchers uncovering 88 new malicious packages in what they describe as the second, third, and fourth waves of the operation. According to Endor Labs findings, the newly discovered packages were published between November 2025 and February 2026, with 81 of them still available on npm along with two active command and control (c2) servers. “PhantomRaven is a software supply chain attack that uses Remote Dynamic Dependencies (RDD) to hide credential-stealing malware in non-registry dependencies that bypass standard security scanning,” the researchers said in a blog post. “The first wave affecting 126+ packages with over 86,000 downloads, was first described by Koi Security in October 2025.” The evolution of the campaign was tracked by correlating the infrastructure indicators, code similarities, and attacker operational patterns, the blog noted. However, in an update to the blog, Endor Labs said the packages were alleged to be part of a legitimate research experiment, a claim it contends, citing operational irregularities. Dependency trick hides the malware RDD allows malicious code to be delivered outside the package itself. Instead of embedding the malware directly in the npm package, attackers specify an HTTP URL dependency in the package’s “package.json” file. When a developer runs “npm install,” npm automatically retrieves the dependency from the attacker-controlled server. The package hosted on npm appears harmless, often containing little more than a basic script, while the actual malicious payload is downloaded in parallel during the installation process. Once executed, the malware gathers a range of sensitive information from the developer’s environment. This includes email addresses, system details, and credentials from CI/CD platforms such as GitHub Actions, GitLab CI, Jenkins, and CircleCI. The stolen data is then transmitted to attacker-controlled servers using multiple redundant techniques, including HTTP GET, POST requests, and even WebSocket connections, ensuring exfiltration across different network environments. Because the malicious code never appears directly in the npm package itself, traditional scanning tools that focus on package contents fail to flag it. Operational patterns challenge “research experiment” claim Despite the new waves, PhantomRaven’s core functionality has remained largely unchanged, the researchers said. They found that 257 out of 259 lines of the malware payload are identical across all waves, with the only significant modification being the command-and-control domain used to receive stolen data. Instead, the attacker focused on operational changes designed to stay ahead of takedowns. These include rotating npm accounts, modifying package descriptions and metadata, and registering new domains with similar naming patterns such as “storeartifact,” “jpartifacts,” and “artifactsnpm.” Additionally, the campaign employed Slopsquatting to publish packages mimicking Babel plugins, GraphQL tooling, ESLint presets, and other widely used development utilities. Endor Labs’ blog post was later updated to reflect claims that the packages were part of a legitimate research experiment intended to study malicious package detection. “Allegedly, the packages have been produced by a security researcher known in the community,” the update read. “However, several characteristics strongly support classifying these packages as malware rather than legitimate research artifacts.” Endor Labs’ contention with the claim included the presence of active command-and-control servers, credential harvesting routines targeting developer environments, and active data exfiltration mechanisms. “In addition, the packages provide no indication whatsoever that they are part of a research experiment — neither in a README nor through console messages or package metadata — leaving affected users without any transparency,” the researchers said. View the full article

In July 2025, McDonald’s had an unexpected problem on the menu, one involving McHire, its AI-powered platform used to recruit and screen job applicants. The system, developed by Paradox.ai, featured a rookie-level security flaw: the backend for restaurant operators accepted “123456” as both username and password, and lacked multi-factor authentication. As a result, the personal data of around 64 million applicants was in danger. Luckily, the flaw was uncovered by security researchers Ian Carroll and Sam Curry, who notified the company. With organizations rushing to deploy AI tools without fully auditing them, incidents like this are not uncommon. AI adoption is moving faster than AI security and governance, according to an IBM report. Last year, 13% of organizations reported breaches involving AI models or applications, while another 8% said they don’t even know whether those systems have been compromised. And insurers know that. Many have tightened policy language, raised premiums, and carved out explicit exclusions for certain AI-related incidents, an effort that aims to limit exposure to risks that are poorly understood. A survey by Delinea found that 42% of respondents said their cyber insurance policies now include exclusions tied to AI misuse and liability. Yet the picture is not entirely one-sided. Insurers are also rewarding stronger defenses: 86% of organizations say they have received premium discounts or credits for using AI-based security tools that bolster their security posture. “AI is both a risk and an opportunity,” says Nate Spurrier, vice president of insurance and counsel strategy at GuidePoint Security. Cyber insurers are changing how they judge risk As AI becomes more deeply embedded across business operations — and increasingly exploited by attackers — cyber insurers are rethinking how they evaluate risk. Many are now moving beyond checkbox questionnaires and self-attestations, asking for evidence that security controls are actively monitored, tested and enforced. According to the Delinea report, 77% of insurers now require formal reviews by internal and IT security teams before issuing or renewing coverage, up from 56% a year ago. But even those reviews are no longer enough on their own. “Leading cyber insurers have moved away from moment-in-time application forms toward continuous assessment of an organization’s attack surface and controls,” says Michael Phillips, Coalition’s head of global cyber portfolio underwriting. In addition to underwriting and settling claims, Coalition also bundles cybersecurity services with its cyber insurance offerings. Policyholders gain access to tools that continuously monitor internet-facing systems for vulnerabilities and alerts, alongside expert guidance and threat intelligence. The idea is to reduce the frequency and severity of claims, by linking a company’s security posture directly to its insurance coverage. And as AI touches many corners of modern business operations, that heightened scrutiny now extends to how companies use and govern the technology. “Insurance carriers are wanting to know how policyholders and applicants are using AI within their organization: what controls are in place, how AI is being used and for what specific tasks, who is allowed to use it, and whether it’s simply an efficiency tool or a core part of the end solution being offered to clients,” says Spurrier. Changes to coverage and language Now that AI is everywhere, insurers are rewriting their contracts to be much more specific about what’s covered and what’s not. Some have introduced affirmative AI endorsements, others have added exclusions, because AI risks can be unpredictable and potentially large-scale, and insurers don’t want to be on the hook for losses they can’t accurately price. Crafting the right policy language for a fast-evolving technology is a complex task. “Right now, insurers don’t have enough claims data to fully understand what language and components of AI risk should be targeted, so some carriers are using broad exclusions out of caution,” Spurrier says. Yet that caution can be detrimental for organizations. “AI is now an expected component of a successful cyber attack, and it’s not always easy to discern what was created by AI or not,” says Philips. “If a policy excludes any AI‑related loss, an insurer could argue that a classic ransomware claim is out of scope simply because AI was used as part of the attack process.” The issue is compounded by how policies have evolved. Many were written before generative AI went mainstream. Insurers later added AI-related language, layering new terms onto older contracts. This patchwork approach can create confusion. “If that wording isn’t explained clearly, policyholders may assume they have the same protection as before, but they do not,” Philips says. Businesses and their brokers need to read policy language closely and talk through how it would actually work in practice. That means discussing specific AI-related scenarios with their brokers before renewal and seeing how they might affect different types of coverage. “One scenario may not impact some lines of insurance and then show up as excluded in another line of insurance,” Spurrier says. “The time to clarify your AI coverage isn’t during a claim, but during renewal and other pre-incident scenarios.” Bringing costs down for companies Some companies that prove they have a good security posture can lower their insurance costs. To do that, they need to demonstrate that they’re using AI-driven tools to spot anomalies early or cut response times from hours to minutes. “For insurers, that means smaller claims and faster recovery,” Spurrier says. Discounts are usually offered to businesses that have strong, round-the-clock security in place. “Detection solutions like EDR (endpoint detection and response) are now widely expected by insurance carriers, and the next step is to continuously monitor the alerts generated so that action can be taken quickly,” Spurrier adds. In the near future, AI-powered defenses may become mandatory for coverage, much like multi-factor authentication and endpoint detection and response tools are today. This means that companies that lag behind may find themselves at a disadvantage. “If you’re relying on legacy tools, expect higher premiums or limited coverage,” he says. View the full article

Mithilfe sogenannter Zombie-ZIPs lassen sich fast alle Virenscanner austricksen. Pressmaster | shutterstock.com Eine neue Technik mit dem Namen „Zombie ZIP“ ist in der Lage, Payloads in komprimierten Dateien zu verbergen. Sicherheitslösungen wie Antiviren- und EDR-Produkte (Endpoint Detection and Response) können sie nicht entdecken, denn die digitalen Untoten wurden speziell geschaffen, um die Security zu umgehen. Entwickelt wurden sie von Chris Aziz, einem Sicherheitsforscher beim Security-Consulting-Unternehmen Bombadil Systems. Header täuschen Software Das Ganze läuft wie folgt ab, so Aziz: Werden die Dateien mit Standardprogrammen wie WinRAR oder 7-Zip extrahiert, kommt es zu Fehlermeldungen oder korrumpierten Daten. Grund ist, dass die ZIP-Header so manipuliert sind, dass sie die entsprechenden Programme täuschen. Sie sorgen dafür, dass komprimierte Daten als unkomprimiert behandeln werden. Anstatt das Archiv als potenziell gefährlich zu kennzeichnen, vertrauen Sicherheits-Tools dem Header und scannen die Datei, als wäre sie eine Kopie des Originals in einem ZIP-Container. Konkret sollen sich laut Aziz 50 der 51 Antivirenprogramme, darunter auch der Microsoft Defender, ausgetricken lassen. Wie das möglich ist, erklärt er so: „Antivirenprogramme vertrauen dem Feld „Method“ der ZIP-Datei. Liegt „Method=0“ (STORED) vor, scannen sie die Daten als unkomprimierte Rohdaten. Tatsächlich sind die Daten aber DEFLATE-komprimiert – der Scanner sieht also komprimiertes Rauschen und findet keine Signaturen“. Dem Experten zufolge könne ein Angreifer auf diese Weise einen Loader erstellen, der den Header ignoriert und das Archiv als das behandelt, was es ist: Daten, die mit dem in modernen ZIP-Dateien üblichen DEFLATE-Algorithmus komprimiert wurden. Falsch-negative Ergebnisse Aziz hat einen Proof-of-Concept (PoC) auf GitHub veröffentlicht und dort Beispielarchive sowie weitere Details zur Funktionsweise der Methode bereitgestellt. Um bei gängigen Entpackungsprogrammen einen Fehler zu provozieren, müsse der CRC-Wert, der die Datenintegrität sicherstellt, auf die Prüfsumme der unkomprimierten Payload gesetzt werden, so der Sicherheitsforscher. „Ein speziell entwickelter Loader, der die angegebene Methode ignoriert und als DEFLATE dekomprimiert, stellt die Nutzdaten jedoch einwandfrei wieder her“, so Aziz. Für ihn besteht die Schwachstelle deshalb darin, dass die Scanner umgangen werden, denn Sicherheitskontrollen behaupten, dass „no malware present“ sei. In Wirklichkeit sei sie aber vorhanden und könne mit Hilfe von Angreifer-Tooling trivial wiederhergestellt werden. Als Reaktion auf die Ergebnisse veröffentlichte das CERT Coordination Center (CERT/CC) eine Warnung vor „Zombie-ZIPs“. Die offizielle Kennzeichnung dieser Sicherheitslücke lautet CVE-2026-0866 und ähnelt der vor über zwanzig Jahren bekannt gewordenen Schwachstelle CVE-2004-0935. Hierbei handelte es sich um eine Schwachstelle, die eine frühe Version des ESET-Antivirenprogramms betraf. Tipps für die Security Die Experten des CERT/CC schlagen als Gegenmaßnahme vor, dass Anbieter von Sicherheitstools die Felder für die Komprimierungsmethode anhand der tatsächlichen Daten validieren, Mechanismen zur Erkennung von Inkonsistenzen in der Archivstruktur hinzufügen und strengere Archivprüfungsmodi implementieren. Benutzer sollten Archivdateien mit Vorsicht behandeln, insbesondere wenn sie von unbekannten Absendern stammen. Erscheint beim Entpacken die Fehlermeldung „unsupported method“, sollten die Dateien umgehend gelöscht werden. View the full article

Mithilfe sogenannter Zombie-ZIPs lassen sich fast alle Virenscanner austricksen. Pressmaster | shutterstock.com Eine neue Technik mit dem Namen „Zombie ZIP“ ist in der Lage, Payloads in komprimierten Dateien zu verbergen. Sicherheitslösungen wie Antiviren- und EDR-Produkte (Endpoint Detection and Response) können sie nicht entdecken, denn die digitalen Untoten wurden speziell geschaffen, um die Security zu umgehen. Entwickelt wurden sie von Chris Aziz, einem Sicherheitsforscher beim Security-Consulting-Unternehmen Bombadil Systems. Header täuschen Software Das Ganze läuft wie folgt ab, so Aziz: Werden die Dateien mit Standardprogrammen wie WinRAR oder 7-Zip extrahiert, kommt es zu Fehlermeldungen oder korrumpierten Daten. Grund ist, dass die ZIP-Header so manipuliert sind, dass sie die entsprechenden Programme täuschen. Sie sorgen dafür, dass komprimierte Daten als unkomprimiert behandeln werden. Anstatt das Archiv als potenziell gefährlich zu kennzeichnen, vertrauen Sicherheits-Tools dem Header und scannen die Datei, als wäre sie eine Kopie des Originals in einem ZIP-Container. Konkret sollen sich laut Aziz 50 der 51 Antivirenprogramme, darunter auch der Microsoft Defender, ausgetricken lassen. Wie das möglich ist, erklärt er so: „Antivirenprogramme vertrauen dem Feld „Method“ der ZIP-Datei. Liegt „Method=0“ (STORED) vor, scannen sie die Daten als unkomprimierte Rohdaten. Tatsächlich sind die Daten aber DEFLATE-komprimiert – der Scanner sieht also komprimiertes Rauschen und findet keine Signaturen“. Dem Experten zufolge könne ein Angreifer auf diese Weise einen Loader erstellen, der den Header ignoriert und das Archiv als das behandelt, was es ist: Daten, die mit dem in modernen ZIP-Dateien üblichen DEFLATE-Algorithmus komprimiert wurden. Falsch-negative Ergebnisse Aziz hat einen Proof-of-Concept (PoC) auf GitHub veröffentlicht und dort Beispielarchive sowie weitere Details zur Funktionsweise der Methode bereitgestellt. Um bei gängigen Entpackungsprogrammen einen Fehler zu provozieren, müsse der CRC-Wert, der die Datenintegrität sicherstellt, auf die Prüfsumme der unkomprimierten Payload gesetzt werden, so der Sicherheitsforscher. „Ein speziell entwickelter Loader, der die angegebene Methode ignoriert und als DEFLATE dekomprimiert, stellt die Nutzdaten jedoch einwandfrei wieder her“, so Aziz. Für ihn besteht die Schwachstelle deshalb darin, dass die Scanner umgangen werden, denn Sicherheitskontrollen behaupten, dass „no malware present“ sei. In Wirklichkeit sei sie aber vorhanden und könne mit Hilfe von Angreifer-Tooling trivial wiederhergestellt werden. Als Reaktion auf die Ergebnisse veröffentlichte das CERT Coordination Center (CERT/CC) eine Warnung vor „Zombie-ZIPs“. Die offizielle Kennzeichnung dieser Sicherheitslücke lautet CVE-2026-0866 und ähnelt der vor über zwanzig Jahren bekannt gewordenen Schwachstelle CVE-2004-0935. Hierbei handelte es sich um eine Schwachstelle, die eine frühe Version des ESET-Antivirenprogramms betraf. Tipps für die Security Die Experten des CERT/CC schlagen als Gegenmaßnahme vor, dass Anbieter von Sicherheitstools die Felder für die Komprimierungsmethode anhand der tatsächlichen Daten validieren, Mechanismen zur Erkennung von Inkonsistenzen in der Archivstruktur hinzufügen und strengere Archivprüfungsmodi implementieren. Benutzer sollten Archivdateien mit Vorsicht behandeln, insbesondere wenn sie von unbekannten Absendern stammen. Erscheint beim Entpacken die Fehlermeldung „unsupported method“, sollten die Dateien umgehend gelöscht werden. View the full article

Ground Picture | shutterstock.com Security-Anbietern stehen viele Wege offen, um CISOs und Sicherheitsentscheider mit Lobpreisungen und Angeboten zu ihren jeweils aktuellen Produkten und Lösungen zu penetrieren. Und die nutzen sie auch: Manche Sicherheitsverantwortliche erhalten mehr als 30 solcher Anfragen pro Woche – per Telefon, E-Mail oder auch über LinkedIn. Um erkennen zu können, ob das potenzielle neue Produkt auch tatsächlich geeignet ist, müssen CISOs vor allem eines tun: die richtigen Fragen stellen. Für diesen Artikel haben wir mit mehreren erfahrenen Security-Entscheidern gesprochen, die genau wissen, welche das sind. 5 Fragen, die Sie (Security-)Anbietern stellen sollten 1. Wissen Sie über mein Business Bescheid? Potenzielle Anbieter zu fragen, ob sie die spezifischen Herausforderungen des jeweiligen Unternehmens verstehen, gibt Aufschluss darüber, ob diese ihre “Hausaufgaben” erledigt haben, erklärt Amit Basu, CISO und CIO beim Logistikdienstleister International Seaways: “Ich erwarte, dass ein Anbieter Lösungen für die geschäftlichen Probleme meines Unternehmens vorweisen kann – und nicht nur eine Reihe generischer Funktionen für Probleme, mit denen andere Unternehmen konfrontiert sind.” Dabei legt Basu nicht nur besonderen Wert darauf, dass die Anforderungen seines Unternehmens erfüllt werden. Für ihn sei auch essenziell, dass ein neues Tool keine technische Überlastung verursache: “Ein neues Produkt ist nur dann relevant, wenn es die Sicherheit eindeutig verbessert, vorzugsweise ein oder mehrere bestehende Tools ersetzt und einen echten betrieblichen Bedarf erfüllt.” In der Wahrnehmung des Sicherheitsentscheiders verlagerten sich viele Anbieter eher darauf, magische Features anzupreisen, statt zu demonstrieren, wie ihr Produkt reale Security-Probleme löst: “Ich schätze Klarheit und Ehrlichkeit. Wenn ein Tool zwei Anwendungsfälle gut löst, ist das überzeugender als die vage Behauptung, es könne zwanzig lösen.” In seiner Doppelrolle als CISO und CIO von International Seaways fokussiert sich Basu nach eigener Aussage vor allem darauf, sicherzustellen, dass Security integraler Bestandteil jeder neuen Technologie ist – und keine nachträgliche Überlegung. “Sie können mir kein Security-Produkt verkaufen, das auf veralteter Technologie basiert, die unser Tech-Stack nicht unterstützt. Die Integration muss nahtlos sein”, hält Basu fest. 2. Ist Ihr Produkt in der Lage, zu entlasten und den Betrieb zu optimieren? Wichtig zu wissen ist für CISOs außerdem, ob und wie ein potenzielles neues Tool die Arbeitsbelastung für die Mitarbeiter reduzieren, Risiken minimieren, die Ausfallsicherheit verbessern oder Prozesse vereinfachen kann. So fragt Basu etwa konkret bei Anbietern nach, ob ihr Produkt in der Lage ist, Funktionen zu konsolideren: “Ist das nicht der Fall, handelt es sich nur um eine weitere, punktuelle Lösung, die die Kosten treibt und den Wartungsaufwand erhöht”, erklärt der Sicherheits- und IT-Chef. Auch Joshua Scott, CISO beim Plattformanbieter Hydrolix, kennt dieses Problem: “Ich sehe allzu oft Produkte, die scheinbar Mehrwert bieten, aber letztendlich nur Lärm verursachen. Etwa Tools, um Schwachstellen zu erkennen oder andere Scan-Werkzeuge, die dem Team letztlich nur mehr Arbeit bescheren.” Entsprechend fokussiert Scott nach eigener Aussage seine Fragen an Anbieter insbesondere auf die Bereiche: Risikominimierung, Ausfallsicherheit, und Business Impact. Das war jedoch nicht immer so, wie der CISO zugibt: “Anfangs habe ich solche Fragen nicht gestellt. Das kann dazu führen, dass Sie am Ende eine technisch beeindruckende Lösung haben, die kein Problem löst.” 3. Wie hoch ist der Integrations- und Wartungsaufwand? Für Vasanth Madhure, CISO beim Softwareunternehmen Couchbase, zählen mit Blick auf neue Tools nicht nur die anfallenden Lizenzkosten, sondern auch die Implementierungs- und Schulungsanforderungen für das Security-Team. Deshalb möchte der Sicherheitsentscheider es ganz genau wissen: “Ich frage nach, wieviel Zeit und Aufwand für Konfiguration und Betrieb des Produkts konkret einzuplanen sind. Einige Produkte sind recht unkompliziert, andere erfordern jedoch umfangreiche Konfigurationen.” Wie Madhure hinzufügt, sei es auch wichtig zu wissen, ob Updates automatisiert oder manuell erfolgen – schließlich wirke sich die laufende Wartung direkt auf die Arbeitsbelastung für die Mitarbeiter aus. “Ich schätze vor allem Tools, die klare, umsetzbare Reportings und aussagekraftige Dashboards bieten – und es idealerweise ermöglichen, den Reifegrad des Sicherheitsprogramms im Zeitverlauf zu tracken”, erklärt der CISO. Darüber hinaus stellt der Couchbase-Manager auch sicher, keine bösen Überraschungen im Nachgang zu erleben: “Man will nicht in eine Lösung investieren, nur um dann navchträglich festzustellen, dass ein Upgrade auf eine Enterprise-Version nötig ist oder ein zusätzliches Produkt angeschafft werden muss, damit ein bestimmtes Feature funktioniert.“ 4. Wie sieht Ihr Update-Zyklus aus? Hydrolix-CISO Scott befragt Anbieter ausgiebig zu ihren Update-Zyklen – und das aus gutem Grund, wie er erklärt: “Ich möchte verstehen, wie Anbieter mit neuen Frameworks, Compliance-Vorschriften und Security-Herausforderungen Schritt halten. Insbesondere in sich schnell verändernden Bereichen wie Vulnerability Scanning oder GRC.” 5. Können Sie Ihre Aussagen mit praktischen Anwendungsfällen belegen? Es empfiehlt sich zudem, Anbieter nach konkreten Beispielen dafür zu fragen, wie ihre Lösung bereits die Probleme gelöst hat, mit denen Sie selbst konfrontiert sind. “Support für etablierte Frameworks wie NIST CSF oder MITRE ATT&CK sind zwar nützlich. Noch wichtiger ist allerdings ein Nachweis über optimierten Schutz, verkürzte Erkennungs- und schnellere Reaktionszeiten oder auch geringere Kosten”, konstatiert Basu. Um sicherzustellen, dass das potenzielle neue Tool keine Vaporware ist, eine schlechte Benutzeroberfläche aufweist oder mit umständlichen Funktionen enttäuscht, setzt Scott in erster Linie auf Live-Demos – und bezieht dabei auch sein Team mit ein: “CISOs verstehen vielleicht auf einer höheren Ebene, warum ein Produkt einen Mehrwert bietet. Aber es kann technische Details geben, die wir übersehen haben – oder etwas anderes, dass die Praktiker einfach besser einordnen können.” 4 Warnsignale, auf die Sie achten sollten In einer Sache sind sich alle CISOs, mit denen wir gesprochen haben, einig: Es gibt Dinge, die im Rahmen von Sales Pitches oder anderen Angeboten sofort die Alarmglocken schrillen lassen sollten. Dazu zählen demnach insbesondere: vage oder abwegige Behauptungen, Panikmache, die darauf beruht Angst, Unsicherheit und Zweifel zu schüren (etwa, wenn ein Sicherheitsvorfall zur Verkaufstaktik wird), die gehäufte Verwendung von Buzzwords ohne wirkliche Erklärung, und eine mangelnde Bereitschaft des Anbieters, Feedback zu seinen Verkaufsgesprächen anzunehmen (kein gutes Signal für die künftige Zusammenarbeit). (fm) View the full article

Threat actors are still having success tricking human resources staff into opening malware-infected phishing emails. The latest example is detailed by researchers at Aryaka, who this week described a campaign by an unnamed threat actor who is distributing resumés containing a malicious ISO file to HR departments. It’s delivered through recruitment channels, and hosted on what an employee, or an email gateway’s filters, would see as trusted cloud infrastructure. When the victim mounts the ISO, which is an archive of an optical disc such as a DVD, and opens its contents, a malicious shortcut (.lnk) is executed, launching obfuscated PowerShell commands that extract hidden payloads embedded within a steganographic image. A malicious DLL is then sideloaded using a legitimate signed application, allowing the attacker’s code to run under the guise of trusted software. The goal is to harvest data from the infected computer. The malware’s most alarming feature, says Aryaka, is an internal module dubbed BlackSanta which shuts down endpoint detection and response (EDR) agents that would detect this attack. It deploys a Bring-Your-Own Vulnerable Driver (BYOVD) technique that loads legitimate but exploitable kernel drivers, gaining low-level system access, then systematically turns off security tools. While it’s a sophisticated attack, what CSOs might consider more important is preventing the attack from the start through HR employee security awareness training to help them spot phishing lures. Among the priorities for that training: Emphasizing that files ending in .iso can execute malware. A resumé or job application file should end in .docx, .pdf or .txt. [Related content: Fake resumés have updated backdoor] “Your HR team should be among your most trained and protected employees,” says Roger Grimes, CISO advisor at awareness training provider KnowBe4. “HR departments are strongly in the crosshairs of all sorts of scammers. If they aren’t trying to get their malware installed or steal logon credentials, they are trying to get fake employees into the recruitment process.” In fact, he added, a scam that makes it past the HR team may make it be seen as more trustworthy as it moves to other departments. HR staff should be trained to only accept normal resumé submission document types, such as .pdf or .docx, Grimes said, and to not to click on URLs inside either unless necessary. Some organizations decrease the risk of malware being sent through fake resumés by asking for all submissions to go to their HR hiring portal, which only accepts text inputs to supplied web forms, he added. At the very least, all HR staff members have to understand that they are at high risk of receiving scams, he said. They must be educated about common scams targeting HR departments, coached when they perform high-risk actions, and given simulated phishing testing that mimics phishing that commonly targets HR employees. Not just malware Fake job applications don’t just come with malware. At a time when many jobs are filled by employing online interviews, they’re a way nation-states can infiltrate sensitive organizations like defense or government contractors. Last month, a Ukrainian man was sentenced by a US judge to 60 months in prison for stealing the identities of Americans, which were then used by North Koreans to fraudulently get work at US firms. In 2025, Amazon said that over a 17 month period it blocked over 1,800 job applications suspected of coming from North Korean agents. Lures impersonating HR According to researchers at Cofense, most HR-related phishing messages are sent in the second half of the year, although specific message themes will change based on current events (for example: ‘Because of COVID, revenue has fallen, so we have to lay off staff’). One theme that regularly works: Termination messages. Employees won’t ignore an email with a termination subject line, and the messages will appear legitimate, particularly if they spoof the company’s email address. Other common themes, Confense says, include notices of compensation adjustments, company benefits or the ability to enroll in benefits, handbook and policy updates, employee assessments and surveys, and income tax information. [Related content: Phishers know everyone is afraid of HR] “Impersonating HR provides many benefits to threat actors,” the Cofense report notes. “Tasks from HR are typically mandatory, so HR emails carry authority. Legitimate HR tasks can also have strict deadlines, which a threat actor can use to impose urgency. Finally, regular HR tasks are expected by employees. Sent at the right time, employees may not recognize an email as phishing and automatically click on any link to resolve the HR issue.” AI makes detection harder Christopher Kayser, head of Canadian consulting firm Cybercrime Analytics and author of a book on social engineering, said that thanks to generative AI technology, it’s becoming increasingly difficult to recognize malicious communications. And because, for years, the job of HR staff has been to receive responses to ads for positions, they tend to open documents without question. On top of that, many employees trust that IT is doing everything possible to ensure that any communications that make it to devices have been scanned and are safe. For their part, he added, bad actors use the common triggers for any type of phishing campaign: Playing on fear, guilt, helpfulness, obedience, and urgency in subject lines and messages. [Related content: 5 ways to spot phishing emails] Defensive strategies “It is virtually impossible to instill sophisticated levels of knowledge for every user of technology to be able to correctly identify malicious communications,” Kayser told CSO. “But what can be taught is to make people realize there is never a communication that we receive that we should feel compelled to respond to immediately, until we have verified that what we are being asked or told to do is valid.” All employees should be told that, if skeptical about an email or text, they should immediately ask their IT department to review it, he said. Another defensive strategy, Kayser suggested, is having all incoming communications for HR redirected to a specific folder on the corporate email system where full checks for viruses and corrupted files are run. Some argue these files may contain personally identifiable information, which shouldn’t be seen by anyone outside HR; that, Kayser said, is a valid concern. But this step shouldn’t require IT to inspect file content, just look for malware and suspicious activity. View the full article

The US Cybersecurity and Infrastructure Security Agency (CISA) has warned that an authentication bypass vulnerability patched in Ivanti Endpoint Manager (EPM) last month is now being exploited in the wild. The agency has also updated its directive related to two Cisco Catalyst SD-WAN flaws that were also fixed last month after being used in zero-day attacks. The Ivanti EPM vulnerability, tracked as CVE-2026-1603, impacts EPM versions prior to 2024 SU5. It allows a remote, unauthenticated attacker to leak stored credential data and was patched on Feb. 9 along with another EPM SQL injection flaw tracked as CVE-2026-1602. At the time, Ivanti credited a researcher working with Trend Micro’s Zero Day Initiative program for reporting the vulnerabilities and said that it was not aware of customers being exploited by those vulnerabilities. That situation appears to have changed with CISA adding CVE-2026-1603 to its Known Exploited Vulnerabilities (KEV) catalog this week along with two others: a remote code execution flaw in the SolarWinds Web Help Desk (CVE-2025-26399) and a server-side request forgery (SSRF) issue in VMware Workspace ONE UEM (Unified Endpoint Management), now part of Omnissa (CVE-2021-22054). While the SolarWinds Web Help Desk flaw was patched in September last year, it’s worth noting that it was a bypass to an older Java deserialization flaw, CVE-2024-28986, that was exploited in the wild soon after being patched. Because of this, researchers warned that CVE-2025-26399 will likely follow a similar path, something that CISA has now confirmed. SolarWinds WHD is a product that has been targeted before, including this year in January via two zero-day vulnerabilities. Also this week, CISA updated its emergency directive related to CVE-2026-20127 and CVE-2022-20775 — an authentication bypass flaw and a privilege escalation issue in Cisco SD-WAN Controller and software. Cybersecurity agencies from the Five Eyes alliance issued a joint advisory about CVE-2026-20127 last month after the flaw was identified in active attacks. What makes it worse is that there were signs the vulnerability had been exploited since 2023, so the attacks managed to fly under the radar for almost 3 years. CISA issued a directive to federal government agencies to identify impacted systems on their networks, patch the flaws, and hunt for compromises. The updated version of the directive issued this week adds requirements regarding reporting and actions. Specifically, federal agencies must submit collected logs from SD-WAN deployments to CISA by March 26. View the full article

Amazon Web Services is expanding AWS Security Hub to function as a centralized security operations platform capable of aggregating risk signals across multicloud environments. With the updated Security Hub, the company said it will introduce a unified operations layer that provides security teams with near real-time risk analytics, automated analysis, and prioritized insights. As enterprise workloads have spread across multiple cloud providers, the expansion of Security Hub aims to address the growing complexity faced by CISOs and help them focus on managing risks rather than tools, the company said in a blog post. AWS Security Hub reimagined As security teams struggle to manage multiple tools, the expanded Security Hub introduces a common data layer designed to unify security signals from across enterprise workloads. It will then offer a single view of risk to security teams instead of a fragmented collection of consoles. Security teams will also be able to manage their cloud security posture using Security Hub CSPM checks, which provide posture visibility and extend vulnerability management through expanded Amazon Inspector capabilities, including virtual machine scanning, container image scanning, and serverless workload scanning, the company said. Security Hub originally played a narrower role. But in December last year, AWS pulled together signals from its security services into a single interface to automatically analyze threats, vulnerabilities, misconfigurations, and sensitive data exposures. This list of services includes Amazon GuardDuty, Inspector, Security Hub Cloud Security Posture Management, and Amazon Macie. The latest multicloud expansion will be built on that foundation, as well as AWS’s earlier launch of AWS Security Hub Extended, which allows enterprises to deploy and manage third-party security tools directly through Security Hub at pre-negotiated pay-as-you-go pricing without long-term commitments. The curated portfolio includes vendors such as CrowdStrike, Okta, Proofpoint, SailPoint, Splunk, and Zscaler, enabling organizations to extend security visibility beyond AWS environments. Cross-cloud security monitoring While AWS has not provided technical details on how it will identify vulnerabilities outside its native environment, Sanchit Vir Gogia, chief analyst at Greyhound Research, said multicloud visibility typically works by collecting signals from multiple security systems and translating them into a consistent format so they can be analysed together. A key enabler of this approach is the Open Cybersecurity Schema Framework, which defines a common structure for representing security events and vulnerabilities. “When it comes to monitoring external environments beyond AWS, Security Hub is likely to rely on integrations and standardized telemetry. Most multicloud security solutions retrieve data through APIs from other cloud vendors, security platforms, and enterprise monitoring tools,” explained Devroop Dhar, co-founder and CEO at Primus Partners. “For example, Security Hub would ingest data from vulnerability management platforms, endpoint security tools, identity systems, and configuration management solutions. AWS has a robust partner ecosystem, so integration with existing security technologies will likely be an important factor,” Dhar added. Gogia noted that Security Hub can also analyse assets that are reachable from the internet and add context about exposure pathways. This technique works across infrastructure boundaries because internet exposure can be observed externally, regardless of where the infrastructure is hosted. “If a workload is visible externally, the risk exists regardless of which cloud hosts it,” he said. Operational security impact For CSOs and security leaders, the expansion of AWS Security Hub reflects a broader shift in enterprise security operations. Aggregating security signals into a unified platform could help security teams correlate threats, prioritize risks, and streamline incident response across distributed environments. “As enterprises use multiple clouds and hybrid environments for their workloads, there is a constant toggle between various dashboards and logs. Having a central view of all risks across all clouds is highly desirable because it helps reduce operational costs. The idea is not only to have visibility but also to understand what vulnerabilities represent the highest level of risk for the organization,” added Dhar. Gogia noted that managing multiple cloud environments also contributes to alert fatigue, which has become one of the defining characteristics of modern security operations centres. Teams frequently process enormous volumes of alerts while having limited resources to investigate them thoroughly. Platforms that combine telemetry from multiple sources into a single operational view can help reduce that friction. However, while the idea of centralization is attractive, there are practical considerations as well. Visibility is only as strong as the integrations behind it. If some workloads or tools are not integrated properly, it can create a false sense of completeness. When security teams rely on a single interface to interpret telemetry and coordinate response, the availability of that interface also becomes critical. “Organisations need to ensure they can still access telemetry and respond to incidents even if their primary console becomes unavailable. Maintaining alternate access paths and independent telemetry pipelines becomes an essential part of sound security architecture,” Gogia added. Dhar noted that integrating dozens of tools into a single platform is not always straightforward. CISOs will also weigh the risk of vendor lock-in, since security workflows that become tightly tied to one vendor’s platform can be difficult to move away from later. The move also reflects a broader industry trend toward consolidated security platforms that bring multiple capabilities under a single operational layer. As enterprise environments grow more complex, vendors are increasingly combining threat detection, posture management, and vulnerability analysis into unified security architectures. “The industry has seen multicloud capabilities from pure-play security vendors for years. Microsoft Defender for Cloud and Google Cloud Security Command Center have also extended their reach beyond their native cloud environments,” said Amit Jaju, global partner/senior managing director – India at Ankura Consulting. View the full article

Amazon Web Services is expanding AWS Security Hub to function as a centralized security operations platform capable of aggregating risk signals across multicloud environments. With the updated Security Hub, the company said it will introduce a unified operations layer that provides security teams with near real-time risk analytics, automated analysis, and prioritized insights. As enterprise workloads have spread across multiple cloud providers, the expansion of Security Hub aims to address the growing complexity faced by CISOs and help them focus on managing risks rather than tools, the company said in a blog post. AWS Security Hub reimagined As security teams struggle to manage multiple tools, the expanded Security Hub introduces a common data layer designed to unify security signals from across enterprise workloads. It will then offer a single view of risk to security teams instead of a fragmented collection of consoles. Security teams will also be able to manage their cloud security posture using Security Hub CSPM checks, which provide posture visibility and extend vulnerability management through expanded Amazon Inspector capabilities, including virtual machine scanning, container image scanning, and serverless workload scanning, the company said. Security Hub originally played a narrower role. But in December last year, AWS pulled together signals from its security services into a single interface to automatically analyze threats, vulnerabilities, misconfigurations, and sensitive data exposures. This list of services includes Amazon GuardDuty, Inspector, Security Hub Cloud Security Posture Management, and Amazon Macie. The latest multicloud expansion will be built on that foundation, as well as AWS’s earlier launch of AWS Security Hub Extended, which allows enterprises to deploy and manage third-party security tools directly through Security Hub at pre-negotiated pay-as-you-go pricing without long-term commitments. The curated portfolio includes vendors such as CrowdStrike, Okta, Proofpoint, SailPoint, Splunk, and Zscaler, enabling organizations to extend security visibility beyond AWS environments. Cross-cloud security monitoring While AWS has not provided technical details on how it will identify vulnerabilities outside its native environment, Sanchit Vir Gogia, chief analyst at Greyhound Research, said multicloud visibility typically works by collecting signals from multiple security systems and translating them into a consistent format so they can be analysed together. A key enabler of this approach is the Open Cybersecurity Schema Framework, which defines a common structure for representing security events and vulnerabilities. “When it comes to monitoring external environments beyond AWS, Security Hub is likely to rely on integrations and standardized telemetry. Most multicloud security solutions retrieve data through APIs from other cloud vendors, security platforms, and enterprise monitoring tools,” explained Devroop Dhar, co-founder and CEO at Primus Partners. “For example, Security Hub would ingest data from vulnerability management platforms, endpoint security tools, identity systems, and configuration management solutions. AWS has a robust partner ecosystem, so integration with existing security technologies will likely be an important factor,” Dhar added. Gogia noted that Security Hub can also analyse assets that are reachable from the internet and add context about exposure pathways. This technique works across infrastructure boundaries because internet exposure can be observed externally, regardless of where the infrastructure is hosted. “If a workload is visible externally, the risk exists regardless of which cloud hosts it,” he said. Operational security impact For CSOs and security leaders, the expansion of AWS Security Hub reflects a broader shift in enterprise security operations. Aggregating security signals into a unified solution could help security teams correlate threats, prioritize risks, and streamline incident response across distributed environments. “As enterprises use multiple clouds and hybrid environments for their workloads, there is a constant toggle between various dashboards and logs. Having a central view of all risks across all clouds is highly desirable because it helps reduce operational costs. The idea is not only to have visibility but also to understand what vulnerabilities represent the highest level of risk for the organization,” added Dhar. Gogia noted that managing multiple cloud environments also contributes to alert fatigue, which has become one of the defining characteristics of modern security operations centres. Teams frequently process enormous volumes of alerts while having limited resources to investigate them thoroughly. Solutions that combine telemetry from multiple sources into a single operational view can help reduce that friction. However, while the idea of centralization is attractive, there are practical considerations as well. Visibility is only as strong as the integrations behind it. If some workloads or tools are not integrated properly, it can create a false sense of completeness. When security teams rely on a single interface to interpret telemetry and coordinate response, the availability of that interface also becomes critical. “Organizations need to ensure they can still access telemetry and respond to incidents even if their primary console becomes unavailable. Maintaining alternate access paths and independent telemetry pipelines becomes an essential part of sound security architecture,” Gogia added. Dhar noted that integrating dozens of tools into a single solution is not always straightforward. CISOs will also weigh the risk of vendor lock-in, since security workflows that become tightly tied to one vendor’s platform can be difficult to move away from later. The move also reflects a broader industry trend toward consolidated security solutions that bring multiple capabilities under a single operational layer. As enterprise environments grow more complex, vendors are increasingly combining threat detection, posture management, and vulnerability analysis into unified security architectures. “The industry has seen multicloud capabilities from pure-play security vendors for years. Microsoft Defender for Cloud and Google Cloud Security Command Center have also extended their reach beyond their native cloud environments,” said Amit Jaju, global partner/senior managing director – India at Ankura Consulting. View the full article

Amazon Web Services is expanding AWS Security Hub to function as a centralized security operations solution capable of aggregating risk signals across multicloud environments. With the updated Security Hub, the company said it will introduce a unified operations layer that provides security teams with near real-time risk analytics, automated analysis, and prioritized insights. As enterprise workloads have spread across multiple cloud providers, the expansion of Security Hub aims to address the growing complexity faced by CISOs and help them focus on managing risks rather than tools, the company said in a blog post. AWS Security Hub reimagined As security teams struggle to manage multiple tools, the expanded Security Hub introduces a common data layer designed to unify security signals from across enterprise workloads. It will then offer a single view of risk to security teams instead of a fragmented collection of consoles. Security teams will also be able to manage their cloud security posture using Security Hub CSPM checks, which provide posture visibility and extend vulnerability management through expanded Amazon Inspector capabilities, including virtual machine scanning, container image scanning, and serverless workload scanning, the company said. Security Hub originally played a narrower role. But in December last year, AWS pulled together signals from its security services into a single interface to automatically analyze threats, vulnerabilities, misconfigurations, and sensitive data exposures. This list of services includes Amazon GuardDuty, Inspector, Security Hub Cloud Security Posture Management, and Amazon Macie. The latest multicloud expansion will be built on that foundation, as well as AWS’s earlier launch of AWS Security Hub Extended, which allows enterprises to deploy and manage third-party security tools directly through Security Hub at pre-negotiated pay-as-you-go pricing without long-term commitments. The curated portfolio includes vendors such as CrowdStrike, Okta, Proofpoint, SailPoint, Splunk, and Zscaler, enabling organizations to extend security visibility beyond AWS environments. Cross-cloud security monitoring While AWS has not provided technical details on how it will identify vulnerabilities outside its native environment, Sanchit Vir Gogia, chief analyst at Greyhound Research, said multicloud visibility typically works by collecting signals from multiple security systems and translating them into a consistent format so they can be analysed together. A key enabler of this approach is the Open Cybersecurity Schema Framework, which defines a common structure for representing security events and vulnerabilities. “When it comes to monitoring external environments beyond AWS, Security Hub is likely to rely on integrations and standardized telemetry. Most multicloud security solutions retrieve data through APIs from other cloud vendors, security platforms, and enterprise monitoring tools,” explained Devroop Dhar, co-founder and CEO at Primus Partners. “For example, Security Hub would ingest data from vulnerability management platforms, endpoint security tools, identity systems, and configuration management solutions. AWS has a robust partner ecosystem, so integration with existing security technologies will likely be an important factor,” Dhar added. Gogia noted that Security Hub can also analyse assets that are reachable from the internet and add context about exposure pathways. This technique works across infrastructure boundaries because internet exposure can be observed externally, regardless of where the infrastructure is hosted. “If a workload is visible externally, the risk exists regardless of which cloud hosts it,” he said. Operational security impact For CSOs and security leaders, the expansion of AWS Security Hub reflects a broader shift in enterprise security operations. Aggregating security signals into a unified solution could help security teams correlate threats, prioritize risks, and streamline incident response across distributed environments. “As enterprises use multiple clouds and hybrid environments for their workloads, there is a constant toggle between various dashboards and logs. Having a central view of all risks across all clouds is highly desirable because it helps reduce operational costs. The idea is not only to have visibility but also to understand what vulnerabilities represent the highest level of risk for the organization,” added Dhar. Gogia noted that managing multiple cloud environments also contributes to alert fatigue, which has become one of the defining characteristics of modern security operations centres. Teams frequently process enormous volumes of alerts while having limited resources to investigate them thoroughly. Solutions that combine telemetry from multiple sources into a single operational view can help reduce that friction. However, while the idea of centralization is attractive, there are practical considerations as well. Visibility is only as strong as the integrations behind it. If some workloads or tools are not integrated properly, it can create a false sense of completeness. When security teams rely on a single interface to interpret telemetry and coordinate response, the availability of that interface also becomes critical. “Organizations need to ensure they can still access telemetry and respond to incidents even if their primary console becomes unavailable. Maintaining alternate access paths and independent telemetry pipelines becomes an essential part of sound security architecture,” Gogia added. Dhar noted that integrating dozens of tools into a single solution is not always straightforward. CISOs will also weigh the risk of vendor lock-in, since security workflows that become tightly tied to one vendor’s platform can be difficult to move away from later. The move also reflects a broader industry trend toward consolidated security solutions that bring multiple capabilities under a single operational layer. As enterprise environments grow more complex, vendors are increasingly combining threat detection, posture management, and vulnerability analysis into unified security architectures. “The industry has seen multicloud capabilities from pure-play security vendors for years. Microsoft Defender for Cloud and Google Cloud Security Command Center have also extended their reach beyond their native cloud environments,” said Amit Jaju, global partner/senior managing director – India at Ankura Consulting. View the full article

Salesforce is urging its customers to review their Experience Cloud ‘guest’ configurations as cybercrime group ShinyHunters claims a new campaign involving data theft and extortion tied to exposed Salesforce environments. The group recently posted screenshots on its leak site claiming breaches of “several hundreds” of organizations, including around 400 websites and roughly 100 “high profile companies.” The claims come amid a broader campaign targeting Salesforce deployments through misconfigured public-facing portals, rather than vulnerabilities in the platform itself. In a new blog post, Salesforce warned that attackers are exploiting overly permissive guest user settings in Experience Cloud environments to harvest data that organizations never intended to expose. “Our Cyber Security Operations Center (CSOC) has been monitoring a campaign by a known threat actor group,” the company said without identifying the actor. “Evidence indicates the threat actor is leveraging a modified version of the open-source tool Aura Inspector (originally developed by Mandiant) to perform mass scanning of public-facing Experience Cloud sites.” The ShinyHunters post, which came hours after the Salesforce warning, called the new campaign “Salesforce Aura Campaign.” The warning lands against a backdrop of earlier incidents attributed to ShinyHunters, which, since mid-2025 has targeted Salesforce instances through phishing, social engineering, and abuse of integrations. In some cases, these attacks led to millions of records being compromised. Overly permissive guest access The warning concerns the Salesforce Experience Cloud platform used by organizations to build public portals for customers, partners, and communities. These sites rely on a shared “guest user profile” that allows unauthenticated visitors to view certain information. When configured correctly, that profile exposes only the minimal data required for the site to function. But if permissions are too broad, attackers can directly query backed CRM objects, effectively pulling data without needing credentials. According to Salesforce, threat actors are automating this process using a modified version of Mandiant’s open-source AuraInspector tool, which probes the “/s/sfsites/aura” API endpoint exposed by Experience Cloud sites. In the attacker-altered form, the tool moves beyond detection and actively extracts accessible data. Jason Soroko, senior fellow at Sectigo, described the approach as the “path of least resistance” for attackers. Rather than engineering sophisticated exploits, he said, threat actors increasingly target configuration gaps where “a single overly permissive guest setting leaves the data accessible to anyone who asks.” According to the advisory, the campaign specifically targets environments where three conditions exist. These include instances with guest profiles having excessive object or field permissions, organization-wide default access for external users is not set to private, and guest users are allowed to access public APIs. These conditions allow attackers to query data through Experience Cloud guest profiles. Why Salesforce environments make tempting targets Salesforce deployments are particularly attractive because of the sensitive data they hold and the complexity of their access models. “Salesforce instances often contain highly sensitive customer data, including credentials and secrets that can be used for lateral movement,” said Vincenzo lozzo, CEO and cofounder of SlashID. At the same time, he added, the platform’s layered permissions architecture, including profiles, permissions sets, sharing rules, and integrations, which are not very well understood and can make accidental overexposure easy. The attack surface expands further when organizations connect Salesforce with third-party applications and APIs. “Trust relationships, and long-lived and poorly monitored credentials grant access to treasure troves of systems and data,” said Trey Ford, chief strategy and trust officer at BugCrowd. Once attackers compromise a trusted integration, he noted, it can create cascading risk across the entire ecosystem. Salesforce guidance focuses on tightening the responsible configuration controls. Recommended steps include auditing guest user permissions, disabling public API access where possible, restricting object visibility, and enforcing least-privilege access. View the full article