CSOonline

PeopleImages.com – Yuri A | shutterstock.com Protokoll-Daten zu auditieren, zu überprüfen und zu managen, ist alles andere als eine glamouröse Aufgabe – aber ein entscheidender Aspekt, um ein sicheres Unternehmensnetzwerk aufzubauen. Schließlich schaffen Event Logs oft eine sekundäre Angriffsfläche für Cyberkriminelle, die damit ihre Aktivitäten verschleiern wollen. Vorgängen wie diesen treten Netzwerksicherheitsexperten mit Tools aus dem Bereich Security Information and Event Management (SIEM) entgegen: Diese Werkzeuge bieten im Regelfall einen zusätzlichen Schutzschirm für Logs, indem sie sie auf einen Server oder Service auslagern und so verhindern, dass sie manipuliert oder gelöscht werden. In diesem Ratgeber lesen Sie: welche Kriterien bei SIEM-Tools wichtig sind, was bei diesen Lösungen mit Blick auf die Kosten zu beachten ist, und welche SIEM-Anbieter und -Lösungen führend sind. Das richtige SIEM-Tool auswählen Eine passende SIEM-Lösung auszuwählen, ist essenziell, um geschäftskritische Systeme und Dienste zu überwachen. Aber auch, um: Daten für Authentifizierungszwecke bereitzustellen, die Threat Detection zu unterstützen, und SOAR-Plattformen Kontext zu liefern. Die folgenden Bereiche, beziehungsweise Kriterien, sollten Sie mit Blick auf SIEM-Angebote unbedingt vor einem Kauf durchdenken. Betriebsmodell Um Funktionen schneller zu iterieren und hinzuzufügen, steht das Gros moderner SIEM-Lösungen inzwischen in einem Software-as-a-Service (SaaS)-Modell zur Verfügung. Die unendliche Kapazität der Cloud erleichtert es den Anbietern dabei auch, Machine-Learning (ML)-Funktionen zu integrieren, die Referenzdaten in rauen Mengen benötigen, um Anomalien erkennen zu können. Es besteht grundsätzlich Einigkeit darüber, dass der SaaS-Ansatz dazu beigetragen hat, SIEM-Lösungen voranzubringen. Dennoch sind einige Unternehmen darauf angewiesen, SIEM-Tools On-Premises zu betreiben. In der Regel, weil sie Compliance-Vorschriften einhalten und in diesem Zuge Protokolle (und die damit zusammenhängenden Daten) in ihrer lokalen Infrastruktur vorhalten müssen. Deshalb gibt es immer noch einige SIEM-Optionen für den Einsatz vor Ort – darunter auch solide Open-Source-Lösungen. Analytics Eine SIEM-Lösung ist nur so gut wie die Informationen, die sie liefert: Log- und Event-Daten aus der Infrastruktur zu sammeln, ist nutzlos, wenn es nicht dazu beiträgt, Probleme zu erkennen und informierte(re) Entscheidungen zu treffen. Deswegen setzen moderne SIEM-Systeme auf Machine Learning, um Anomalien in Echtzeit zu erkennen und ein präzises Frühwarnsystem für potenzielle Angriffe sowie Anwendungs- und Netzwerkfehler zu etablieren. Wie Ihre spezifischen Anforderungen an die Analysefähigkeiten einer SIEM-Lösung aussehen, hängt von mehreren Faktoren ab: Welche Systeme sollen überwacht werden? Welche Skills stehen in der Organisation mit Blick auf Dashboards, Reportings und Untersuchungen zur Verfügung? Haben Sie bereits in eine Analytics-Plattform investiert und möchten diese integrieren? Die Antworten auf diese Fragen können Sie dabei unterstützen, SIEM-Optionen einzugrenzen. Sollten Sie weder auf entsprechende Skills, noch Lösungen zurückgreifen können, empfiehlt sich möglicherweise eine SIEM-Lösung mit einer umfangreichen Dashboard-Bibliothek – beziehungsweise ein Managed Service. Protokolle Wie ein SIEM-System Daten verarbeitet, ist ein weiterer, wichtiger Aspekt mit Praxisbezug. Häufig extrahieren Software-Agenten Protokoll- und Ereignisdaten von Servern und Workstations, während Netzwerkhardware und Cloud-Anwendungen sie über eine Integration oder eine API direkt an das SIEM „übergeben“ können. Eine grundlegende Frage ist in diesem Zusammenhang, ob das SIEM auch wichtige, externe Event-Informationen akkurat identifizieren kann. Im Idealfall sollte das SIEM ausgereift genug sein, um Event-Daten aus den gängigsten Systemen zu parsen und dabei so genau sein, dass keine Anpassungen erforderlich sind und wichtige Details wie Event-Levels oder betroffene Systeme herausgefiltert werden. Um zu vermeiden, dass Log-Einträge nicht korrekt geparst werden, empfiehlt sich zudem eine Lösung, die flexible Möglichkeiten bietet, Event-Daten zu verarbeiten, nachdem sie erfasst wurden. Warnmeldungen Ein wesentlicher Vorteil moderner SIEM-Lösungen ist die Möglichkeit, Systeme in Echtzeit zu überwachen. Allerdings ist das Feature überflüssig, wenn das SIEM selbst, beziehungsweise seine Alerts, nicht von einem menschlichen Experten ausgewertet werden. Mit Blick auf die Warnmeldungen und Benachrichtigungen besteht die Herausforderung vor allem darin, beim Volumen der Alerts Maß zu halten: Zu viele Warnmeldungen werden von den Benutzern entweder deaktiviert oder ignoriert. Zu wenige Alerts bergen die Gefahr, dass kritische Bedrohungen unter den Tisch fallen. Auch mit Blick auf dieses Kriterium empfehlen sich flexible SIEM-Lösungen, die es ermöglichen, Alerts zu konfigurieren – zum Beispiel über Regeln, Schwellenwerte oder verschiedene Warnmethoden (SMS, E-Mail, Push-Nachrichten und Webhooks). Rollenbasierter Zugriff Rollenbasierte Zugriffskontrollen sind für große, weltweit tätige Unternehmen mit unterschiedlichen Business-Segmenten und Applikationsteams unerlässlich. Dabei ist es nicht bloß ein Komfort-Feature, Admins, Entwickler und Datenanalysten nur Zugriff auf die Event-Logs zu gewähren, die sie benötigen. Vielmehr entspricht das dem Least-Privilege-Prinzip, das in einigen Branchen auch regulatorisch durchgesetzt wird. Den Zugriff der Benutzer auf SIEM-Event-Daten beschränken zu können, begrenzt zudem den Impact kompromittierter Konten und trägt letztlich zum Schutz des gesamten Netzwerks bei. Schließlich bieten Event-Daten oft tiefe und detailreiche Einblicke in Applikations- und Service-Funktionalitäten – oder gar die Netzwerkkonfigurationen von Devices. Diese Informationen könnten Cyberkriminelle nutzen, um Systeme auszuspähen und zu infiltrieren. Compliance Diverse, regulatorische Rahmenwerke – beispielsweise die DSGVO oder HIPAA – setzen nicht nur voraus, dass SIEM- oder ähnliche Systeme eingesetzt werden, sondern schreiben teilweise auch vor, wie die Lösung konfiguriert sein sollte. Sie sollten sich deshalb mit den für Ihre Organisation relevanten Anforderungen im Detail vertraut machen. Dabei können unter anderem relevant sein: Aufbewahrungsfristen, Verschlüsselungsanforderungen, digitale Signaturen und Berichtspflichten. Dabei sollten auch mögliche Audit-Elemente nicht unberücksichtigt bleiben: Die SIEM-Lösung Ihrer Wahl sollte die erforderlichen Dokumentationen und Reportings ausgeben können, die die Auditoren zufriedenstellen. Event-Korrelation Die Möglichkeit, Protokolle aus unterschiedlichen (und/oder integrierten) Systemen in einer einzigen Ansicht zu korrelieren, ist ebenfalls ein guter Grund dafür, ein SIEM-System zu implementieren. Dieses sollte in der Lage sein, Log-Events von jeder Anwendungskomponente (Datenbank, Applikationsserver) zu verarbeiten (selbst wenn sie auf mehrere Hosts verteilt sind), und diese in einem Data Stream zu korrelieren. Das macht nachvollziehbar, wie die Events der Komponenten miteinander zusammenhängen. In vielen Fällen können korrelierte Ereignisprotokolle eingesetzt werden, um (Privilege-Escalation-)Angriffe zu erkennen und ihren Impact über die verschiedenen Netzwerksegmente hinweg zu tracken. Das wird auch deswegen immer wichtiger, weil Unternehmen zunehmend auf die Cloud oder Container-basierte Infrastrukturen setzen. Ökosysteme Ein SIEM mit einem robusten, ausgereiften Ökosystem ermöglicht es, verschiedene Funktionen zu verbessern, beziehungsweise zu erweitern. Wenn das SIEM direkt (oder über Plugins) in andere Systeme integriert werden kann, erleichtert das die Arbeit erheblich. Neben den Systemverbesserungen, die durch ein SIEM-Ökosystem erzielt werden können, gibt es noch weitere Business Benefits. So kann eine moderne, ausgereifte SIEM-Lösung: die Nachfrage nach Schulungen steigern, Support auf Community-Basis fördern, und den Einstellungsprozess vereinheitlichen. API-Interaktion Ein Ökosystem wird nicht allen Anforderungen gerecht: Falls Ihr Unternehmen Software entwickelt oder in DevOps-Initiativen investiert hat, kann die Möglichkeit, programmgesteuert mit einer SIEM-Lösung zu interagieren, einen wesentlichen Unterschied machen. Statt wertvolle Entwicklungszeit in Logging-Funktion zu stecken, kann das SIEM-System Ereignisdaten aus benutzerdefiniertem Code aufnehmen, korrelieren und analysieren. Künstliche Intelligenz (KI) SIEM scheint ein maßgeschneiderter Anwendungsfall für KI-gestützte Analysen – entsprechend scheuen sich die Anbieter nicht, entsprechende Funktionen in ihre Lösungen zu implementieren. Die fokussieren sich im Allgemeinen auf die Bereiche Analytics und Alerts. KI-fähige SIEM-Systeme können mit Cloud-Daten-Feeds einer Vielzahl von Anbietern und Quellen integriert werden. Das ermöglicht, Event-Daten automatisiert mit Kontext auszustatten und dafür zu nutzen, um: Ereignisse zu bewerten, Angriffsketten zu identifizieren und Incident-Response-Pläne zu erstellen. Mit Blick auf KI-fähige SIEM-Lösungen kann auch das Thema Betriebsmodell eine Rolle spielen: Einige On-Premises-Angebote erfordern unter Umständen, KI-Workloads an Cloud-Services auszulagern. SIEM-Kosten Wenn es um Security Information and Event Management geht, sollten Sie den Gürtel nicht unbedingt enger schnallen – schließlich möchte wohl niemand im Angriffsfall am falschen Ende gespart haben. Natürlich sind die Kosten auch im Fall von SIEM-Lösungen ein Faktor – bei der Berechnung gilt es allerdings auf Feinheiten zu achten. SIEM-Lösungen, die in Form eines Cloud-Service angeboten werden, stehen fast immer in einem Abo-Modell zur Verfügung. Dabei können jedoch auch Nutzungsgebühren anfallen – beispielsweise für: das Volumen der Event-Daten oder die Anzahl der überwachten Endpunkte. Achten Sie bei Plattformen, die mit einer Open-Source-Lizenz angeboten werden, zudem auf versteckte Kosten (beispielsweise für Support) und stellen Sie sicher, dass die gewählte Lösung sämtliche relevanten, geschäftlichen Anforderungen erfüllt. Wenn Sie Ihr persönliches SIEM-Kandidatenfeld auf diejenigen eingegrenzt haben, die die benötigten Funktionen bieten, vergleichen Sie die voraussichtlich anfallenden Abonnement- und Nutzungsgebühren im Detail. SIEM-Anbieter & -Lösungen Der Markt für SIEM-Lösungen ist reich an Optionen. Um Ihnen den Einstieg in die Tool-Recherche zu erleichtern, haben wir einige, wichtige SIEM-Anbieter, respektive -Produkte, für Sie zusammengestellt: Datadog Cloud-SIEM ist eine ausgereifte SIEM-Suite, die sämtliche wichtigen Bereiche umfasst und mehr als 800 Integrationen sowie über 350 vorgefertigte Detection-Regeln bietet. Elastic Logstash ist keine echte SIEM-Plattform – das Open-Source-Tool (in erster Linie für die DevOps-Welt konzipiert) ermöglicht es aber, Log-Events aus einer Vielzahl von Quellen zu analysieren und zu verarbeiten. Exabeam LogRhythm SIEM ist einem Zusammenschluss der Sicherheitsanbieter Exabeam und LogRythm entsprungen und zeichnet sich in erster Linie durch ein umfassendes Ökosystem und vorgefertigte Compliance-Frameworks aus. Fortinet FortiSIEM ermöglicht Asset-Erkennung und rollenbasierten Zugriff, sowie User and Entity Behavior Analytics (UEBA) – und kann sowohl integriert werden, um Events zu erfassen, als auch, um automatisiert auf diese zu reagieren. Huntress Managed SIEM ist ein solides, modernes Managed SIEM von einem aufstrebenden Anbieter, dessen Analysten und Security Engineers interne Teams entlasten können. IBM QRadar SIEM ist in der Lage, Datenmengen und Funktionen im Enterprise-Format zu bewältigen, verfügt über eine integrierte Analytics-Engine, KI-Funktionen und bietet Support für mehr als 500 Integrationen. LogPoint SIEM & SOAR setzt UEBA für Threat Modeling und Machine Learning ein, unterstützt automatisierte Übersetzungen sowie wichtige Compliance-Standards und korreliert Ereignisse auch mit dem MITRE ATT&CK-Framework. Microsoft Sentinel ist in der Lage, Ereignisse sowohl von lokalen, als auch von Cloud- Ressourcen einzuspeisen, zu korrelieren und zu analysieren – dabei hilft inzwischen auch die KI in Form von Microsofts Security Copilot. OpenText Enterprise Security Manager kann alle Anforderungen an ein Enterprise-SIEM erfüllen, bietet zahlreiche Integrationen mit Drittanbieter-Systemen und umfassenden Support für Automatisierung. NetWitness bietet ebenfalls diverse Enterprise-SIEM-Funktionen, zeichnet sich aber vor allem durch seine integrierten Encryption-Tools aus, die Support für verschlüsselte Event-Daten (oder Netz-Traffic) bieten. SentinelOne Singularity AI SIEM setzt auf State-of-the-Art-Techniken, um Daten zu erfassen und zu filtern, liefert robuste Analysen und verspricht intuitive Automatisierungen. SolarWinds Security Event Manager bietet zwar weder ML-basierte Datenanalysen, noch kann es in Sachen Integrationen mit den anderen hier aufgeführten Optionen mithalten – dafür bietet es USB Device Monitoring und beeindruckende Compliance-Reporting-Fähigkeiten. Splunk bietet seine SIEM-Plattform, die sich insbesondere durch ihr Ökosystem (beziehungsweise ihren App Store) auszeichnet, in zwei Versionen an: Splunk Enterprise für den On-Premises-Einsatz und Splunk Cloud als SaaS-Modell. Trellix Enterprise Security Manager stellt Benutzern umsetzbare Warnmeldungen zur Verfügung und legt den Fokus auf Flexibilität, wenn es um Architektur und Integrationen geht. Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

Researchers warn that a critical vulnerability patched this week in BeyondTrust Remote Support is being exploited in the wild to compromise self-hosted deployments, including Bomgar remote support appliances, which included affected versions of the impacted software. Bomgar, a provider of privileged identity and access management products, acquired BeyondTrust in 2018, adopting the latter’s brand name. Bomgar on-premises hardware appliances, known as BeyondTrust B-series appliances, provide secure remote access to enterprise networks, but many hardware models have reached end of life, with customers encouraged to upgrade to either the virtual appliance or BeyondTrust’s SaaS offerings: Privileged Remote Access (Cloud) and Remote Support (Cloud). Researchers from security firm Arctic Wolf have detected attacks that compromised Bomgar appliances through the CVE-2026-1731 flaw patched this week. The attackers attempted to then deploy the SimpleHelp remote management and monitoring (RMM) tool and perform lateral movement to other systems on the network. “Renamed SimpleHelp binaries were created through Bomgar processes using the SYSTEM account,” the researchers said in a report today. “These executables were saved to the ProgramData root directory and executed from there. Binary names include remote access.exe and others.” The attackers also managed to create domain accounts using the net user command and then added them to administrative groups such as “enterprise admins” or “domain admins.” The AdsiSearcher tool was used to search the Active Directory environment for other computers and PSexec was used to install SimpleHelp on multiple devices. The researchers also observed Impacket SMBv2 session setup requests in affected environments. Impacket is a Python library that can be used to decode network traffic and is often used in conjunction with sniffing tools. CVE-2026-1731 is a critical pre-authentication command injection vulnerability that impacts BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA). The company released patches for multiple versions of the impacted software, but older versions of RS need to be updated first before the patch can be applied, which could be a problem for appliances that are no longer supported and have reached end of life. A proof-of-concept exploit was published on GitHub so it’s not surprising that attacks followed soon after. As a remote access solution, BeyondTrust RS is an attractive target for both state-sponsored attackers and ransomware groups. The US Department of the Treasury had some of its workstations compromised after hackers exploited vulnerabilities in SaaS instances of BeyondTrust RS. View the full article

South Korea’s data protection authority has handed down a combined KRW 36 billion (approximately US$25 million) in administrative fines to the local subsidiaries of three global luxury houses, after finding they failed to implement basic security controls while managing customer data through a SaaS platform. The Personal Information Protection Commission (PIPC), South Korea’s top privacy regulator, announced on Feb. 12 that it levied a total of KRW 36.033 billion in fines and KRW 10.8 million in additional penalties against Louis Vuitton Korea, Christian Dior Couture Korea, and Tiffany Korea for violations of the country’s Personal Information Protection Act (PIPA). The regulator also ordered all three companies to publicly disclose the enforcement actions on their websites. The PIPC noted that the data in question — personal information belonging to Korean customers — was collected and processed domestically by the local subsidiaries, placing it squarely within the jurisdiction of PIPA. Louis Vuitton drew the heaviest penalty at KRW 21.385 billion. In that case, an employee’s device was compromised by malware, allowing threat actors to harvest SaaS account credentials. The breach resulted in the exposure of personal data belonging to roughly 3.6 million individuals across three separate incidents between June 9 and June 13 of last year. Despite having used the SaaS platform since 2013, Louis Vuitton Korea had never implemented IP-based access restrictions or enforced stronger authentication for remote access. Christian Dior Couture Korea was fined KRW 12.236 billion, plus an additional KRW 3.6 million in penalties. In Dior’s case, a customer service representative fell victim to a voice phishing (vishing) attack and directly provisioned SaaS access to the attacker, leading to the exposure of personal data for approximately 1.95 million individuals. The company had failed to enforce IP-based access controls, had not restricted the use of bulk data export tools, and had not conducted monthly access log reviews — lapses that allowed the breach to go undetected for more than three months. The PIPC also confirmed that Dior missed the statutory 72-hour window for notifying authorities and affected individuals once the breach was discovered. Tiffany Korea received a fine of KRW 2.412 billion and an additional KRW 7.2 million in penalties. The attack vector mirrored Dior’s: A customer service employee was socially engineered through a vishing scheme and granted the attacker access privileges, resulting in the compromise of personal information for approximately 4,600 individuals. Tiffany likewise lacked IP-based access controls and bulk download restrictions, and failed to report the breach within the required 72-hour timeframe. The PIPC stressed that SaaS environments used to process personal data qualify as “personal information processing systems” under Korean law. As such, organizations are required to enforce least-privilege access, implement IP-based access controls, and deploy strong authentication mechanisms — including one-time passwords, digital certificates, or hardware security tokens. “Adopting a Software-as-a-Service solution does not exempt or transfer a company’s obligation to safeguard personal information,” the PIPC said in its official statement. “Data controllers must fully leverage the security features these platforms provide to prevent breaches.” View the full article

Developers have resolved a legacy flaw in the widely used libpng open-source library that existed since the software was released nearly 30 years ago. The heap buffer overflow in libpng would cause applications on unpatched systems to crash when presented with maliciously crafted PNG graphic images. In worse case scenarios, the CVE-2026-25646 vulnerability could be abused to extract information or trigger remote code execution. The most serious repercussions of the flaw would be possible only if proceeded by careful heap grooming preparation by a potential attack, so exploitation is far from trivial. Images capable of exploiting the vulnerability would still need to be valid PNG files. The vulnerability is fixed in libpng version 1.6.55. Libpng is a reference library that allows applications to read or manipulate PNG raster image files. The technology is bundled with many Linux- and Unix-based operating systems, including Red Hat and Debian. The security flaw exists in a function called png_set_quantize, which is used for reducing the number of colors in PNG images, and present in all versions of libpng prior to version 1.6.55. “When the function is called with no histogram and the number of colours in the palette is more than twice the maximum supported by the user’s display, certain palettes will cause the function to enter into an infinite loop that reads past the end of an internal heap-allocated buffer,” an advisory on the flaw explains. Security researchers have released a proof of concept for the vulnerability to demonstrate their concern. Threat levels The flaw should not be overlooked but is certainly no reason for panic, according to security experts. “While it’s true this bug existed in the libpng library for three decades, this is not a doomsday-level threat,” said Satnam Narang, senior staff research engineer at Tenable, the firm behind the Nessus vulnerability assessment scanner. The vulnerable png_set_quantize function, previously called png_set_dither, is rarely used and exploitation of the flaw is tricky. These factors lower the true severity of this flaw despite the “high” severity rating and CVSS score of 8.3, according to Narang. “While it is still important to patch flaws like this one as part of the normal patch management process, it shouldn’t be prioritized over vulnerabilities in edge-network devices that are being targeted by nation-state threat actors and ransomware affiliates,” Narang advised. AI-enabled bug hunting threat The discovery of the flaw highlights the uncomfortable truth that there are many lingering vulnerabilities in open-source software libraries — dormant bugs that the wider use of AI tools is likely to unearth at greater cadence in future. “In combination with the rapid improvement of large language models, it’s likely we’ll see the discovery of a plethora of bugs in the coming months, just as Anthropic’s Claude Opus 4.6 was able to find 500 high-severity zero-days,” Narang told CSO. “Some of those bugs may be exploited by threat actors, instead of being disclosed via coordination.” View the full article

AI agents are increasingly seen as a way to reinforce the capabilities of cybersecurity teams — but which can do the best job? Wiz has developed a benchmark suite of 257 real-world challenges spanning five offensive domains: zero-day discovery, CVE (code vulnerability) detection, API security, web security, and cloud security to find out. Wiz tests different combinations of AI agents and their underlying AI models against the test suite to see which score the highest in each of the five categories. Scoring is deterministic and programmatic using several factors: multi-dimensional rubrics for zero-day and CVE detection; endpoint-and-severity matching for API security and lag capture for web and cloud challenges. The benchmark tests run inside isolated Docker containers with sufficient resources and no per-challenge timeouts, so scores reflect capability rather than throttling. Each agent uses its native tools and execution model out of the box, and gets three goes at every challenge to see how it performs on average. In the blog post announcing the Cyber model arena benchmarks, Wiz is coy about the result of its trials. Coming out top of its trials is Claude Code running on Claude Opus 4.6. Wiz, soon to be a subsidiary of Google, may not be too keen about publicizing that. However, Claude’s lead is narrow and circumstances can quickly change. And at least Gemini 3 Pro is in second place. View the full article

The number of ways that Windows shortcut (.LNK) files can be abused just keeps growing: A cybersecurity researcher has documented four new techniques to trick Windows users into running malicious actions through innocent-looking shortcuts. Wietze Beukema demonstrated how to spoof the visible LNK destination, hide command-line arguments, and execute a different program than the one shown to the user, potentially offering attackers new vectors for phishing, USB-borne attacks, or initial access operations. The disclosure adds to longstanding concerns about a flaw in LNK handling that has been repeatedly exploited by threat actors yet has proven difficult to fully eliminate. Although Microsoft did not immediately respond to a request for comment on the disclosure, it has previously acknowledged risks in this area through security guidance, including a November 2025 advisory. Until now, Microsoft has always stopped short of classifying Windows’ behavior with LNK files as a conventional “vulnerability,” but the sheer number of exploits that Beukema has demonstrated makes Microsoft’s position that this is just a UI issue harder to defend. Bait and switch Windows shortcuts serve as pointers to programs or documents, but they can store more than simple file paths. The LNK files can specify command-line arguments, working directories, icons, and other execution parameters, effectively acting as a launcher. Beukema identified multiple previously undisclosed ways to create mismatches between what a Windows shortcut appears to target and what it actually launches. Because the LNK format allows the target path to be stored in several structures, including the “TargetIDList”, “EnvironmentVariableDataBlock”, and “LinkInfo” fields, Windows must choose which value to trust. That decision process can be manipulated. According to Beukema, under normal conditions, Windows Explorer prioritizes the EnvironmentVariableDataBlock entry when both it and the TargetIDList are present, displaying and executing that path. However, if the Environmental Variable path is a syntactically invalid Windows file path, Explorer still displays it in the Properties dialog but silently falls back to the hidden TargetIDList path at runtime. This allows a shortcut to present a harmless-looking destination while executing a different program entirely. Additionally, Beukema-disclosed flaws exploit other fallback behaviors arising from conflicting metadata. If an EnvironmentVariableDataBlock is present but the LinkTargetIDList is non-matching, Windows instead runs the executable from the LinkInfo structure while continuing to display the Environment Variable path. In a variant on this exploit, supplying only the ANSI target value while leaving the paired Unicode field empty causes Explorer to treat the data as inconsistent. It displays a different path from the LinkTargetIDList, disables the editable Target field, and hides arguments. Yet the concealed ANSI path is executed. Together, these behaviors can potentially enable attackers to spoof the visible target, conceal the real one, and mislead users into launching unintended programs. Hidden command-line arguments Beyond target spoofing, Beukema demonstrated a technique for hiding malicious command-line instructions behind legitimate executables. LNK files can launch trusted Windows binaries while passing attacker-controlled instructions through embedded arguments, enabling “living-off-the-land” (LOLBINs) execution without pointing directly to malware. According to the researcher, this can be done by manipulating the input passed into certain fields within the LNK “ExtraData” section that determines additional target metadata. Enabling the “HasExpString” flag and configuring the “EnvironmentVariableDataBlock” with “TargetANSI/TargetUnicode” fields filled with null bytes produces what he described as “unexpected” results. “First, it disables the target field, meaning the target field becomes read-only and cannot be selected,” Beukema said. “Secondly, it hides the command-line arguments; yet when the LNK is opened, it still passes them on.” The behavior can be exploited to launch a harmless system component while secretly executing arbitrary commands like downloading payloads or running scripts. According to the disclosure, this is a better approach attackers than exploiting CVE-2025-9491 because it is harder to detect due to the absence of visible, padded command lines. Beukema noted that this technique, like the others he described, relies on Windows’ normal shortcut handling rather than being patchable bugs, meaning mitigation largely depends on treating untrusted LNK files as potentially dangerous and preventing users from opening them. “Microsoft argues that as it requires the user to do something, without breaking any security boundaries, it is not a security vulnerability,” he said. “This is not entirely unreasonable as ultimately, most of these boil down to being UI bugs.” View the full article

ArtemisDiana – shutterstock.com Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat in seiner aktualisierten Technischen Richtlinie TR-02102 konkrete Fristen für das Ende der herkömmlichen asymmetrischen Verschlüsselungsverfahren gesetzt. Demnach sollen diese Methoden ab dem Jahr 2031 nicht mehr isoliert verwendet werden. Für Systeme mit besonders hohen Sicherheitsanforderungen gilt diese Vorgabe bereits ab Ende 2030. BSI setzt auf hybride Verschlüsselung Stattdessen empfiehlt die Behörde den kombinierten Einsatz traditioneller Verfahren mit Post-Quanten-Kryptographie in hybrider Ausführung. Zudem hat das BSI den Ausstieg für konventionelle Signaturverfahren aus der alleinigen Verwendung bis Ende 2035 geplant. „Mit der Abkündigung der klassischen Verschlüsselungsverfahren setzen wir neue Maßstäbe. Die Umstellung auf Verfahren der Post-Quanten-Kryptographie ist alternativlos, die Technische Richtlinie gibt nun konkreten Handlungsbedarf vor“, erklärt BSI-Präsidentin Claudia Plattner. Die TR-02102 dient in vielen Bereichen weltweit als Referenzdokument für technische Standards. In verschiedenen Produkten, insbesondere bei der Verarbeitung von Informationen unter Verschluss, ist die Einhaltung dieser BSI-Richtlinie verpflichtend. Die aktualisierten Teile der TR-Richtlinie Die neue TR-Richtlinie enthält folgende Punkte: BSI TR-02102-1: Kryptographische Verfahren und Schlüssellängen Diese Richtlinie präsentiert eine Sicherheitsbewertung ausgewählter kryptographischer Methoden und bietet langfristige Orientierung bei der Auswahl geeigneter Verfahren. Die Auflistung erhebt jedoch keinen Anspruch auf Vollständigkeit. Deshalb gelten nicht aufgeführte Verfahren nicht automatisch als unsicher. Die Zielgruppe sind primär Entwickler, die die Einführung neuer kryptographischer Infrastrukturen planen. BSI TR-02102-2: Transport Layer Security (TLS) Der zweite Teil enthält Handlungsempfehlungen für die Implementierung von TLS. Das Protokoll gewährleistet sichere Datenübertragung in Netzwerken und schützt Vertraulichkeit, Integrität und Authentizität übermittelter Informationen. BSI TR-02102-3: IPsec und IKEv2 Die Richtlinie beschreibt den Einsatz kryptographischer Mechanismen in den Protokollen IPsec (Internet Protocol Security) und IKE (Internet Key Exchange). Dabei geht es ausschließlich um Version 2 des IKE-Protokolls (IKEv2). Für Neuentwicklungen wird grundsätzlich IKEv2 empfohlen, da es gegenüber IKEv1 Vorteile bei Protokollkomplexität und Bandbreitennutzung während des Aufbaus einer Security Association bietet. BSI TR-02102-4: Secure Shell (SSH) Der vierte Teil enthält Empfehlungen für SSH-Implementierungen. Er konkretisiert die Vorgaben zu Protokollversionen und kryptographischen Algorithmen aus Teil 1 der Technischen Richtlinie. View the full article

ArtemisDiana – shutterstock.com Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat in seiner aktualisierten Technischen Richtlinie TR-02102 konkrete Fristen für das Ende der herkömmlichen asymmetrischen Verschlüsselungsverfahren gesetzt. Demnach sollen diese Methoden ab dem Jahr 2031 nicht mehr isoliert verwendet werden. Für Systeme mit besonders hohen Sicherheitsanforderungen gilt diese Vorgabe bereits ab Ende 2030. BSI setzt auf hybride Verschlüsselung Stattdessen empfiehlt die Behörde den kombinierten Einsatz traditioneller Verfahren mit Post-Quanten-Kryptographie in hybrider Ausführung. Zudem hat das BSI den Ausstieg für konventionelle Signaturverfahren aus der alleinigen Verwendung bis Ende 2035 geplant. „Mit der Abkündigung der klassischen Verschlüsselungsverfahren setzen wir neue Maßstäbe. Die Umstellung auf Verfahren der Post-Quanten-Kryptographie ist alternativlos, die Technische Richtlinie gibt nun konkreten Handlungsbedarf vor“, erklärt BSI-Präsidentin Claudia Plattner. Die TR-02102 dient in vielen Bereichen weltweit als Referenzdokument für technische Standards. In verschiedenen Produkten, insbesondere bei der Verarbeitung von Informationen unter Verschluss, ist die Einhaltung dieser BSI-Richtlinie verpflichtend. Die aktualisierten Teile der TR-Richtlinie Die neue TR-Richtlinie enthält folgende Punkte: BSI TR-02102-1: Kryptographische Verfahren und Schlüssellängen Diese Richtlinie präsentiert eine Sicherheitsbewertung ausgewählter kryptographischer Methoden und bietet langfristige Orientierung bei der Auswahl geeigneter Verfahren. Die Auflistung erhebt jedoch keinen Anspruch auf Vollständigkeit. Deshalb gelten nicht aufgeführte Verfahren nicht automatisch als unsicher. Die Zielgruppe sind primär Entwickler, die die Einführung neuer kryptographischer Infrastrukturen planen. BSI TR-02102-2: Transport Layer Security (TLS) Der zweite Teil enthält Handlungsempfehlungen für die Implementierung von TLS. Das Protokoll gewährleistet sichere Datenübertragung in Netzwerken und schützt Vertraulichkeit, Integrität und Authentizität übermittelter Informationen. BSI TR-02102-3: IPsec und IKEv2 Die Richtlinie beschreibt den Einsatz kryptographischer Mechanismen in den Protokollen IPsec (Internet Protocol Security) und IKE (Internet Key Exchange). Dabei geht es ausschließlich um Version 2 des IKE-Protokolls (IKEv2). Für Neuentwicklungen wird grundsätzlich IKEv2 empfohlen, da es gegenüber IKEv1 Vorteile bei Protokollkomplexität und Bandbreitennutzung während des Aufbaus einer Security Association bietet. BSI TR-02102-4: Secure Shell (SSH) Der vierte Teil enthält Empfehlungen für SSH-Implementierungen. Er konkretisiert die Vorgaben zu Protokollversionen und kryptographischen Algorithmen aus Teil 1 der Technischen Richtlinie. View the full article

A tale of two industries The United States Navy takes 18-year-olds fresh out of high school and trains them to operate nuclear reactors in 18 months. These aren’t college graduates. They’re not experienced professionals. They’re young people with the right potential who go through the most rigorous, structured program in the military that transforms them into personnel trusted with some of the highest-stakes responsibilities imaginable. Meanwhile, in cybersecurity, we claim we can’t find qualified people. We claim there’s a talent shortage, that candidates just don’t have the skills we need. We look for unicorns, saying training takes too long. We constantly search for senior professionals who, we say, will “hit the ground running,” while junior candidates watch their growth opportunities evaporate. The problem isn’t the candidates. The problem is leaders who won’t take ownership of building the teams that we need and won’t follow through on development. This is leadership that chooses the path of least resistance instead of doing the hard work of creating foundations for success. How do I know this? I was one of those nuclear reactor operators for 22 years. Now I work in cybersecurity. If we can train nuclear reactor operators from scratch, we can train security analysts. We’re just choosing not to. But refusing to train candidates is just one symptom of the deeper disease. Across the technology fields, we’re seeing a pattern of leadership failures that all share a common thread: lack of accountability and ownership. Leaders who only conduct surface-level analyses instead of finding real root causes. Leaders who stay disconnected from their teams while technical debt accumulates into genuine security risks. Leaders who avoid hard conversations with the business because they simply don’t know how to frame cybersecurity as a risk reduction mechanism or as anything more than a cost center. The accountability gap When leaders don’t take ownership, it shows up in predictable ways. Some are obvious, like teams that have a high turnover rate, projects that never finish or the same problems recurring month after month, year after year. Others, like technical debt, are far more insidious. Technical debt accumulates until it becomes a critical vulnerability, and until the interest you’re paying to keep the business running somewhat smoothly is more work than the normal operational work you do. Technical debt is also its own form of risk. It presents itself in vulnerabilities and in customer churn when all of those manual processes break as someone on your team exits the business. Finally, root cause analysis that stops at comfortable answers instead of hard truths is another huge sign. Let’s be honest about what leadership failure looks like today. Surface-level root cause analysis The incident happens. The post-mortem gets scheduled. The team gathers, reviews a timeline that isn’t quite right, but good enough, and they all toss out some contributing factors. A report gets written. Everyone acknowledges the corrective actions. And then nothing happens. A research paper published in Computers & Security states that researchers “found little evidence of thorough investigations to find the underlying causes.” Then a similar incident happens again. Real root cause analysis is hard. It requires asking “why” until you’re uncomfortable with the answers — the truths — about processes that don’t work, decisions that seemed reasonable at the time and assumptions that were wrong. It requires being willing to discover that you, as a leader, contributed to the problem through your action or inaction. Surface-level analysis stops at the first convenient answer and never addresses the real why. But the cost of stopping too early is being actively measured in recurring incidents, customer churn and team demoralization, which contributes to team turnover as well. When the same types of problems keep happening, your team learns a lesson: leadership doesn’t actually want to fix things. They want to be seen going through the motions. Taking ownership means following the chain of causality until you find something you can actually fix, and then fixing it. That’s accountability. The perfect hire fallacy The Navy’s Nuclear Propulsion Program takes 18-year-olds with the right aptitudes and trains them to operate nuclear reactors in all corners of the globe in 18 months. These aren’t college graduates, and these aren’t people with years of experience. Just the right attitude and aptitude in someone, placed into a rigorous, structured training program that transforms them. The program builds talent, but meanwhile, in cybersecurity and information technology, we claim we need someone with five years of experience in a technology that’s only been around for five. We ask for security analysts who are also developers and who understand compliance frameworks. This is laziness disguised as pragmatism. In fact, less than a quarter of respondents to a recent survey of cybersecurity professionals believe that management actively tries to reduce their stress. Half reported that senior management adds to their stress. We’re avoiding the truth that training people requires leadership effort. It requires creating structured learning paths, providing mentorship, investing time in developing capabilities. It requires true engagement in people’s growth instead of just assigning tasks. It’s hard work, and many leaders simply don’t want to do it. So instead, we hunt for unicorns, wondering why our teams never stabilize, and why talented people decide to leave the field entirely when they realize there’s no path forward for them. Technical debt as leadership failures Every technology leader has a mental list of technical debt. Systems that need updating or configurations that need to be hardened. Monitoring gaps that need to be closed. We know that all of these exist — in fact, we document them and track them in our project management tools. And then we don’t demand the time to fix them. We tell ourselves the business doesn’t understand, it’s budget constraints or we’ll get to it next quarter. What we’re really doing is failing to translate technical debt into business risk in a way that demands action. The uncomfortable truth is that we’re not demanding that technical debt be addressed as part of product development cycles because that would require hard conversations. Conversations where we tell business stakeholders that moving fast now will mean paying a higher price later. Conversations where we advocate for investment in things that don’t create visible new features. These conversations are part of our job. When we don’t have them — when we accept the accumulation of more and more manual tasks to keep things running that should’ve been automated multiple sprints past – then we’re choosing short-term comfort over our actual responsibility to the business. Why this happens These patterns don’t just happen by accident. If they did, we wouldn’t see them in so many places. They happen because of choices — choices individual leaders make, choices organizations make about how they develop (or don’t develop) their leaders, and choices businesses make about how they treat their security functions. Let’s start with the uncomfortable truth that we don’t have any real leadership training in the industry. We promote technical people into management roles and expect them to figure out leadership on their own. Then, we act surprised when these newly minted leaders manage the way they were managed — or worse, when they don’t manage at all. Other professions do invest in their leadership. Healthcare has residencies and fellowships that teach leadership roles. Business schools teach management principles. But in our industry, we throw people into the roles and hope they figure it out. Lack of training doesn’t fully explain the problem, however. There’s an individual component at stake. The fundamentals of good leadership aren’t mysterious: follow through on commitments, dig deep to understand root causes, stay engaged with your team and have hard conversations when necessary. These aren’t advanced concepts requiring an MBA. They’re basic accountability and ownership. Many leaders know this is what they should be doing. They’re choosing not to do it because it’s hard. It’s easier to hire than to train, and it’s easier to accept surface-level answers than to keep asking why until you get to those uncomfortable truths. The path of least resistance is the road well-travelled, unfortunately. Finally, the third piece to this puzzle, the dilemma we face, is a systemic failure of business leadership to also do its own introspection. Why does the business have high churn, both with customers and within teams? Are we setting people up for failure? Do we create conditions where good leadership is possible? The result of all three of these factors is a self-fulfilling prophecy where we make people into managers with no training, and then they may make it into business leadership, still not understanding how to look at things like technical debt because their leaders didn’t make it seem important to them either. This causes teams to burn out, simply because the fundamentals of good leadership aren’t being practiced. This isn’t all a sad story, however. Choices can be changed. But only if we’re willing to be honest about what we’re choosing and why. Leadership accountability isn’t complicated – it just requires choosing to do the work. The teams we could build Imagine cybersecurity teams where people want to stay and grow. Where junior analysts see clear paths to becoming senior practitioners. Where the same problems don’t recur because leaders actually implement fixes. Where technical debt gets addressed because leaders translate it into business risk that demands action. When these things happen, success compounds because you’re building on solid foundations instead of starting over. These teams do exist. They’re led by people who take ownership. The talent is there. The knowledge of what good leadership requires is there. What’s needed is simply the choice to do it. We don’t have a talent shortage in our industry. We have a leadership accountability gap. And unlike the talent market, that’s something we can actually control. The foundational problem has a foundational solution: take ownership. Follow through. Build people. Have the hard conversations. Do the work. The teams and the culture that we all want are waiting on the other side of that choice. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Google detected and blocked a campaign involving more than 100,000 prompts that it claimed were designed to copy the proprietary reasoning capabilities of its Gemini AI model, according to a quarterly threat report released by Google Threat Intelligence Group. The prompts looked like a coordinated attempt to perform model extraction or distillation, a machine-learning process in which a smaller model is created with the essential traits of a much larger one. Google systems caught the prompts in real time and “lowered the risk of this particular attack, protecting internal reasoning traces,” it said. Google is keen to prevent competitors from profiting from its investment in AI model development to train their own models — while still needing to allow users to access the models that power its services. “Model extraction and subsequent knowledge distillation enable an attacker to accelerate AI model development quickly and at a significantly lower cost,” Google said in the report. “This activity effectively represents a form of intellectual property theft.” In the campaign Google detected, attackers instructed Gemini to keep “the language used in the thinking content strictly consistent with the main language of the user input” — a technique it said is aimed at extracting the model’s reasoning processes across multiple languages. “The breadth of questions suggests an attempt to replicate Gemini’s reasoning ability in non-English target languages across a wide variety of tasks,” the company said in the report. Google said it detected frequent model extraction attempts from private sector entities worldwide and researchers seeking to clone proprietary AI capabilities. The company said these attacks violate its terms of service and may be subject to takedowns and legal action. However, researchers and potential customers might want to obtain large samples of Gemini’s reasoning for other, legitimate, purposes such as comparing models’ performance or evaluating its suitability and reliability for a task before purchasing. Model providers see growing threat of IP theft Google is not the only one seeing what it supposes are ill-intentioned attempts at model extraction in its logs. On Thursday, OpenAI told US lawmakers that Chinese AI firm DeepSeek has deployed “new, obfuscated methods” to extract results from leading American AI models to train its own systems, according to a memo reviewed by Bloomberg. OpenAI accused DeepSeek in the memo of trying to “free-ride on the capabilities developed by OpenAI and other US frontier labs,” highlighting how model theft has become a worry for companies that have invested billions in AI development. Corsica Technologies CISO Ross Filipek sees a change in cybersecurity threats behind the accusations. “Adversaries engaging in model-extraction attacks highlights a shift in attack priorities,” he said. “Model extraction doesn’t infiltrate systems in the traditional sense, but rather prioritizes transferring the knowledge developed from the victim’s AI model and using it to accelerate the development of the attackers’ own AI models.” The threat of intellectual property theft through model extraction should worry any organization providing AI models as services, according to the report. Google said these organizations should monitor API access patterns for signs of systematic extraction. Filipek said defending against these attacks requires strict governance over AI systems and close monitoring of data flows. “Organizations should implement response filtering and output controls, which can prevent attackers from determining model behavior in the event of a breach,” he said. Nation-state groups used Gemini to accelerate attack operations Google sees itself not just as a potential victim of AI cybercrime, but also an unwilling enabler. Its report documented how government-backed threat actors from China, Iran, North Korea, and Russia integrated Gemini into their operations in late 2025. The company said it disabled accounts and assets associated with these groups. Iranian threat actor APT42 used Gemini to craft targeted social engineering campaigns, feeding the AI biographical details about specific targets to generate conversation starters designed to build trust, according to the report. The group also used Gemini for translation and to understand cultural references in non-native languages. Chinese groups APT31 and UNC795 used Gemini to automate vulnerability analysis, debug malicious code, and research exploitation techniques, the report found. North Korean hackers from UNC2970 mined Gemini for intelligence on defense contractors and cybersecurity firms, collecting details on organizational structures and job roles to support phishing campaigns. Google said it took action by disabling associated accounts and that Google DeepMind used the insights to strengthen defenses against misuse. Attackers integrate AI into malware operations Gemini is being misused in other ways too, Google said, with some bad actors embedding its APIs directly into malicious code. Google identified a new malware family it called HONESTCUE that integrates Gemini’s API directly into its operations, sending prompts to generate working code that the malware compiles and executes in memory. The prompts appear benign in isolation, allowing them to bypass Gemini’s safety filters, according to the report. AttackIQ field CISO Pete Luban sees services like Gemini as an easy way for hackers to up their game. “Integration of public AI models like Google Gemini into malware grants threat actors instant access to powerful LLM capabilities without needing to build or train anything themselves,” he said. “Malware capabilities have advanced exponentially, allowing for faster lateral movement, stealthier attack campaigns, and more convincing mimicry of typical company operations.” Google also documented COINBAIT, a phishing kit built using AI code generation platforms, and Xanthorox, an underground service that advertised custom malware-generating AI but was actually a wrapper around commercial products including Gemini. The company shut down accounts and projects connected to both. Luban said the pace of AI-enabled threats means traditional defenses are insufficient. “Continuous testing against realistic adversary behavior is essential to determining if security defenses are prepared to combat adaptive threats,” he said. View the full article

Smart organizations have spent the last three years protecting their AI tools from skilled prompt injection-style attacks. The assumption has been that poisoning the foundational model, the real brains behind AI systems, requires technical expertise, privileged access, or a coordinated threat group. That assumption no longer holds, and it marks a significant shift in how organizations need to think about AI security in general and training data sanitization in particular. Recent evidence shows that roughly 250 documents or images can distort the behavior of a large language model, regardless of its size. That’s far different from prior assumptions that it would take thousands or even millions of corrupted data points to push a model off course. This new bar, 250, is low enough for activists, influencers, or competitors to manipulate model outputs without very little technical skill. Online communities have already started to test and even poison the training data for some LLMs. There is one specific subreddit that encourages users to post fabricated facts for the purpose of influencing AI models. A few years ago, this kind of effort wouldn’t have been taken seriously. Now the cybersecurity field knows that AI manipulation is far easier and more accessible, and the risk is much bigger than people having fun on Reddit. Criminals, threat actors, nation states, even individuals can generate content on sites known to be ingested into training data for LLMs and poison the data. Adversaries can inject harmful or biased data into the training pipeline or fine-tuning process quickly and easily. While we’ve long understood that garbage in equals garbage out, another experiment shows that the effects of poor data persist long after the exposure stops. A team from Purdue University, Texas A&M University and the University of Texas at Austin found that there are clear signs of capability decay as models ingest junk content, and adding clean data later did not fully reverse the decline. Any system that trains or is tuned on public data is vulnerable to this long-term model drift if no security controls are implemented to protect the model. In addition to model decay, backdoors can also be inserted into training data that allow attackers to cause a foundational model to behave in predictable ways. Anthropic released a paper on this topic in October, where they injected a backdoor that could trigger data exfiltration. This style of attack is potentially very hard to detect, and the backdoor can trigger a variety of actions by the model, not just data exfiltration. These developments make it clear that data poisoning extends well beyond highly technical targeted attacks. A retailer that runs a customer-facing AI chatbot could see its responses shift if someone repeatedly submits synthetic reviews or exaggerated complaints unless security controls are in place to detect that kind of attack. Finance systems could surface distorted commentary about a company if enough falsified chatter floods the data stream the model relies on for new data. Even the influencer economy presents opportunities to manipulate outputs, since repeated praise or criticism of a product can eventually convince a model that sentiment is widespread. For organizations building AI tools, this means the threat landscape has expanded in ways that require additional routines and safeguards. One of the most reliable protections is establishing a clean, validated version of the model before deployment. You can think of this in terms of having a “gold” version of your trusted model that you use as a baseline for anomaly checks. This gold version becomes the reference point that teams can quickly verify against or restore to if needed at any time, not dissimilar to restoring a device to factory settings. If the model starts producing unexpected outputs or shows early signs of drift, returning to the clean baseline avoids the uncertainty time cost of trying to trace which inputs caused the change. A regular reset schedule can also limit the impact of poisoning; pulling the system back to a known clean state, perhaps once a week, can prevent long stretches of unverified or manipulated inputs from accumulating. Monitoring the data that flows into the model is another important step. Teams should look for abnormal patterns, repeated phrases, sudden bursts of similar submissions, or coordinated attempts to steer the model in a specific direction. This kind of monitoring already exists in network and application security and extending it to model inputs helps detect manipulation early. Think of it as prompt inject filtering. Web application filters (WAFs) work to protect databases from SQL injection attacks. You will want an LLM filter to prevent model poisoning as well. Preventing the input of garbage data can limit the risk of model manipulation. AI threat detection tools that simulate advanced AI-specific attacks also support this kind of assessment. You should have adversarial testing done on your AI tools as you do for your web applications and mobile apps. New security solutions are coming onto the market that pinpoint hidden vulnerabilities in AI-powered systems as well. Security tools that can simulate prompt injection attacks, data model poisoning, even stress test the model with distorted inputs are coming that will help defend against these attacks. As you think through your AI projects, you want to shift your mindset to incorporate these new threats. Model integrity needs to be treated as a core pillar of your AI security strategy, with your teams knowing how easy and accessible this kind of model poisoning has become. Many teams focus heavily on privacy and access control, but those safeguards do little if the model is learning from unreliable or manipulated data. Anyone building an AI tool that interacts with public input or user-generated content should assume that attempts to influence its behavior will happen and prepare accordingly. AI tools are becoming central to decision-making across sectors, which makes data integrity more important than ever. Teams that take these risks seriously from the start will be able to keep their systems reliable, even as the information around them becomes increasingly easy to manipulate. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

When people talk about cryptography, they usually talk about algorithms. RSA versus ECC. Classical versus post quantum. Encryption strength measured in bits and curves. In practice, none of that matters unless keys are created, stored, rotated and retired correctly. Key management is the discipline that governs the entire lifecycle of cryptographic keys, from generation to destruction. It determines who can use a key, for what purpose, for how long and under what conditions. When done well, key management enables confidentiality, integrity, authentication and nonrepudiation across systems. When done poorly, it silently undermines every security control built on top of it. The benefits of strong key management are not theoretical. It reduces blast radius during breaches, enables faster incident response, supports regulatory compliance and makes security systems resilient to change. Most importantly, it allows organizations to evolve cryptography without breaking the business. Yet in many environments I encounter, key management is treated as plumbing. It is assumed to be solved once encryption is enabled. That assumption is now one of the most dangerous in enterprise security. The algorithm obsession and the operational gap Post-quantum cryptography discussions often sound reassuringly academic. Standards bodies publish candidate algorithms. Roadmaps promise seamless migration. From a distance, it appears that the hard work is happening elsewhere. But when I step into real systems, I see an operational reality that does not match the narrative. Keys are long-lived. Rotation is manual or avoided altogether. Ownership is unclear. Audit trails are incomplete. Recovery procedures are rarely tested. AI-driven systems widen this gap even further. Models rely on keys to access data, invoke services, sign artifacts and verify integrity. These keys often live inside fast-moving pipelines that bypass traditional review cycles. When something goes wrong, the failure is rarely isolated. The result is a growing mismatch between cryptographic ambition and operational readiness. We invest in stronger algorithms while leaving the weakest link untouched. Why post-quantum readiness is really a key lifecycle problem Post-quantum cryptography is often framed as a future threat. That framing misses the real challenge. The risk is not the moment a quantum computer breaks an algorithm. The risk is the long transition period before and after that moment. During this phase, organizations must support hybrid cryptography, manage multiple trust models and rotate keys across heterogeneous systems without downtime. In my experience, most enterprises are not prepared for this. They struggle to answer basic questions today. Where are our keys? Which applications depend on them? How quickly can we replace them if needed? Without clear answers, crypto agility is impossible. You cannot switch algorithms at scale if you cannot rotate keys safely and predictably. Post-quantum readiness, then, is less about choosing the right algorithm and more about building the operational muscle to change cryptography without fear. AI systems change how keys are used and abused AI introduces a shift that many security teams underestimate. Traditional applications use keys in relatively predictable ways. AI systems do not. Inference pipelines scale dynamically. Autonomous agents interact with multiple services. Decisions are made without human intervention. In these environments, keys protect not just data, but behavior. I have seen cases where a single compromised key allowed an attacker to influence downstream decisions rather than simply access information. That is a fundamentally different kind of risk. This is why key management for AI systems must evolve. Rotation intervals must shrink. Usage patterns must be monitored. Keys must be tightly scoped to purpose rather than reused for convenience. If AI is the brain of modern systems, keys are the nervous system. When the nervous system is compromised, control is lost entirely. The hidden danger of long-lived trust Long-lived trust has survived for decades because it was convenient. Certificates are valid for years. Shared keys reused across environments. Secrets embedded in configuration files that nobody wants to touch. In a post quantum and AI-driven world, these practices become liabilities. Quantum-capable adversaries can harvest encrypted data today and decrypt it later. Long-lived keys increase the value of that data. AI-driven attacks can exploit exposed keys at machine speed, long before humans can respond. Short-lived, purpose-bound keys are no longer a best practice. They are a prerequisite for survival. What leaders misunderstand about crypto agility Crypto Agility is often described as the ability to swap algorithms when standards change. That definition is incomplete. True crypto agility depends on operational design. Keys must be decoupled from applications. Rotation must be automated. Failure must be expected and rehearsed. In environments where keys are hard-coded or managed manually, cryptographic change becomes a high-risk event. Teams delay upgrades not because they disagree with the need, but because they fear breaking production. I have seen organizations postpone critical security improvements simply because their key management foundations were too fragile to support change. Strengthening the weakest link Improving key management does not require radical transformation. It requires focus. Start by establishing a real key inventory with clear ownership and purpose. Shorten lifetimes aggressively and treat non-rotating keys as technical debt. Separate cryptographic policy from application logic so systems consume keys rather than manage them. Practice cryptographic incident response, not just system outages. Align AI governance with cryptographic governance so speed does not override safety. These steps are unglamorous, but they are effective. I have seen meaningful risk reduction achieved without changing a single algorithm, simply by fixing how keys are handled. The future is already operational Post-quantum cryptography and AI security are often framed as future concerns. In reality, they are already shaping how systems fail today. The organizations that will succeed are not those that adopt the newest algorithms first. They are the ones who treat key management as critical infrastructure rather than an implementation detail. Strong cryptography has always depended on strong operations. The difference now is that the cost of getting it wrong has never been higher. In a post quantum and AI-driven world, the strongest algorithm in the world cannot compensate for the weakest link. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security information and event management (SIEM) platforms have evolved far beyond their basic log collection and correlation roots. With cyber threats moving too fast for manual intervention, leading vendors have been integrating artificial intelligence and machine learning technologies into their SIEM platforms. In addition, modern SIEM platforms now incorporate extended detection and response (XDR) and security orchestration, automation, and response (SOAR), enabling real-time threat detection and automated remediation. SIEMs have become a platform to monitor log data for anomalies and suspicious events before triggering alerts based on unusual behavior and detection rules. “[SIEM] often serves as the workspace for security analysts to investigate incidents that are correlations of alerts with other contexts such as asset information, vulnerabilities, and threat intelligence,” according to analyst group IDC. “IDC expects that in the future, the SIEM will also be the response center of the SOC with automated handling of many incidents via playbooks.” And as enterprise cloud use continues to rise, Google’s Cloud Cybersecurity Forecast predicts that SIEM products will become central to enterprise security operations centers (SOCs) ingesting “everything from cloud logs to endpoint telemetry.” Joe Turner, global director of research and business development at market intelligence firm Context, notes that larger attack surfaces and more sophisticated attacks are spurring enterprises to invest in SIEM in combination with other technologies, including XDR and SOAR, as a platform to correlate, detect, and remediate threats. SIEM, XDR, and SOAR convergence The convergence of SIEM with security tools such as XDR and SOAR is a major factor driving growth in the market. SIEM provides log analytics and broad visibility, XDR extends detection across endpoints and cloud, and SOAR orchestrates response. When SIEM detects a security incident, SOAR triggers automated response actions via XDR — isolating compromised endpoints, disabling compromised user accounts, or blocking malicious traffic in real-time. By converging SIEM with XDR and SOAR, organizations get a unified security platform that consolidates data, reduces complexity, and improves response times, as systems can be configured to automatically contain threats without any manual intervention. In 2024, Context logged a 580% increase in SIEM and XDR technologies being sold together. Services sold with both SOAR and SIEM tied together increased a smaller but still significant 22% in 2024, according to the market intelligence agency. “The term SIEM++ is being used to refer to this next step in SIEM, which is designed for more current needs within security ops asking for automation, AI, and real-time responses. Hence, the increase in SIEM alongside other tools,” Context’s Turner says. George McKenna, director at UK-based managed service provider Emerging T-Tech, tells CSO that the convergence of SIEM with XDR and SOAR enables enterprises to streamline operations, improve detection effectiveness, and reduce mean time to resolution. “Legacy SIEM, while effective for log aggregation and correlation, lacks the granular visibility and automated response capabilities necessary in today’s threat landscape,” McKenna explains. “XDR addresses this gap by integrating endpoint, network, and cloud telemetry, providing a holistic view of potential threats.” McKenna adds: “SOAR then enables the automation of incident response workflows, accelerating mitigation and remediation.” Market split as midrange sales offset SME slump A year on, Context’s data shows that this ongoing convergence of SIEM with security tools such as XDR and SOAR has triggered a structural split in the market. “Large midmarket firms are doubling down on unified platforms for compliance, while smaller organizations are investing less in SIEM entirely in favour of MDR and vulnerability management,” according to Context’s Turner. The overall SIEM market slid from 20% growth in 2024 to a far more modest 4% in 2025. By contrast, the midmarket (501–1,000 seats) saw 288% year-on-year growth — the main driver being the desire to demonstrate compliance with the EU’s NIS2 directive. “The full enforcement of the NIS2 directive in Europe has forced midtier companies to move from basic monitoring to auditable security operations,” Context’s Turner explains. “These companies are too large for simple tools but too small for massive 24/7 internal SOCs. They are buying the SIEM++ platforms to serve as their central source of truth for auditors.” By contrast the SMB market (under 500 seats) for SIEM products dropped 23% last year. “SMBs are investing much more into managed detection and response (MDR), which grew 35% in the 10–50 seat band and 26% in the 50-500 seat band,” according to Turner. The strong shift away from SIEM among smaller businesses is driven by cold hard economics: A cheaper alternative technology offers better results with less implementation headaches for small businesses. “Why pay $66 per seat for a tool you can’t run? SMBs are perhaps choosing to buy the result (MDR) rather than the engine (SIEM),” Turner says. Turbulent times for cloud-based SIEM The shift to cloud-based SIEM, previously seen as a way organizations seek a more scalable and cost-effective platform, has fallen out of favour. “Cloud-native SIEMs reduce operational overhead and enable faster investigations and collaboration across security, DevOps, and platform teams — key for modern security operations,” says Vera Chan, senior product marketing manager of cloud SIEM at cloud and security monitoring firm Datadog. Cloud-based SIEM solutions are plug-and-play security platforms, so organizations can subscribe, integrate assets via API, automate responses using SOAR, and set up tailored detection rules. “Modern cloud-based SIEM goes beyond log management,” Muhammad Ali, cyber solutions consultant at comms and cyber-security provider Exponential-e tells CSO. “It’s an intelligent security hub with built-in SOAR capabilities, seamless API integrations with cloud-based XDR/EDR solutions, and real-time global threat intelligence.” Cloud-based SIEMs remove the need for expensive hardware upgrades associated with traditional on-premises deployments, offering scalability and faster response times alongside potentially more cost-effective usage-based pricing models. According to Context, the cost of SIEM on-prem went up 116% to an average of $93 per seat in 2024, whereas cloud-based SIEM costs went down 26% to $77 per seat over the same period. Fast forward 12 months, however, and the market has turned on its head. Cloud-based SIEM costs continued to decline in 2025, but at a slower rate to $66 per seat. Context sees AI costs playing a factor in the slowdown. “Vendors are passing on the high compute costs of gen AI features to the end-user,” Turner says. By contrast, on-prem SIEM costs have dropped 39% year-on-year to reach $63 per seat — lower than SIEM in the cloud. “Legacy vendors have entered a price war to stop cloud repatriation,” Turner says. “For high-volume data, on-prem is now ironically the value choice for the first time in a long time.” The easy phase of “cloud is cheaper” looks to be over. “Going into 2026, cloud SIEM is the premium choice for those who want AI-driven automation, while on-prem has become the go to for budget-conscious, high-volume log storage,” Turner concludes. Managed SIEM has also taken a hit, as 2025 witnessed an 88% drop in SIEM delivered via MSPs, bucking a recent trend of significant growth for SIEMaaS — previously seen as a means to avoid hiring or retaining an in-house security team. “MSPs have stopped reselling ‘managed SIEM’ as a line item,” according to Context’s Turner. “Instead, they are bundling SIEM technology into MDR services.” The 88% drop in MSP-delivered SIEM isn’t a collapse; it’s a shift toward platformization and integration, Turner emphasizes. “SIEM has become the ‘Intel Inside’ if you will … of the MDR market,” Turner says. “It’s there, but the customer is paying for the protection, not the platform.” AI reshaping the SIEM landscape Static rule-based SIEMs struggle to keep pace with today’s sophisticated cyber threats, which is why AI-powered SIEM platforms use real-time machine learning (ML) to analyze vast amounts of security data, improving their ability to identify anomalies and previously unseen attack techniques that legacy technologies might miss. ML models establish baseline behavior for users, assets, and network traffic, continuously monitoring for deviations that indicate potential threats. When an anomaly is detected, the trained model generates alerts, leading to faster threat detection and response. “AI-powered SIEM solutions not only detect threats but also automate investigation processes, correlating real-time incidents with global threat intelligence,” Exponential-e’s Ali says. “By integrating with SOAR and XDR/EDR platforms, automated responses can be triggered or incidents escalated to security analysts for further action.” Ali adds: “This significantly improves incident response efficiency and supports a more efficient and agile security operations center that’s one step ahead of attackers.” AI-powered SIEMs can prioritize critical alerts, recommend response actions, and automate remediation, reducing noise and fatigue. “As adversaries leverage AI, security teams must adopt AI-driven automation to stay ahead,” Datadog’s Chan says. Industry consolidation The SIEM market is experiencing rapid consolidation as vendors look to develop more comprehensive and powerful platforms. “Organizations demand fewer tools, deeper integrations, and frictionless end-to-end security operations — and vendors that can deliver this will shape the future of cybersecurity,” Datadog’s Chan says. Notable SIEM M&A activity over the past few years includes: Google acquiring Siemplify (a SOAR company) in 2022 to integrate into Google Chronicle SIEM Last July, Palo Alto Networks (PAN) acquired CyberArk for around $25 billion in a deal that extends privileged identity protection into its security platform, paving the way to secure the new wave of autonomous AI agents. The deal follows PAN’s acquisition of IBM’s Qradar SaaS business for $500 million in September 2024. Zscaler agreed to acquire Red Canary for around $675 million in May 2025. The deal delivers MDR outcomes directly via the cloud stack, bypassing MSPs (managed service providers). CrowdStrike bought Spanish cybersecurity startup Onum for around $290 million in August 2025. The acquisition offers CrowdStrike the opportunity to reduce cloud ingestion costs for its SIEM clients using intelligent optimization, clearing the path towards faster incident response. Exabeam merging with LogRhythm in July 2024 Cisco buying Splunk for approximately $28 billion in March 2024 See also: What is SIEM? Improving security posture through event log data SIEM buyer’s guide: Top 15 security information and event management tools — and how to choose Costly and struggling: the challenges of legacy SIEM solutions View the full article

Sie fühlen sich leer ohne Security-Dashboard? Diese Dokumentationen überbrücken den Schmerz bis zum nächsten Arbeitstag. Foto: Gorodenkoff – shutterstock.com Wenn Sie in Ihrer Profession als Sicherheitsentscheider voll aufgehen, brauchen Sie möglicherweise auch zwischen den Arbeitstagen ihre tägliche Dosis Cybersecurity. Falls Ihnen die zahlreichen Annäherungen Hollywoods an das Thema viel zu weit von der Realität entfernt sind, können Sie auf ein Füllhorn hochwertiger Dokumentationen zurückgreifen. Die sind nicht nur informativ, (meist) sehr nah an der Realität und unterhaltsam, sondern teilweise auch historisch wertvoll und in einigen Fällen kostenlos in voller Länge verfügbar. Doku-Highlights für Sicherheitsentscheider Nachfolgend haben wir diverse sehenswerte Dokumentationen in Zusammenhang mit Cybersecurity und Hacker-Kultur für Sie zusammengestellt. Viel Spaß! Hackers – Wizards of the Electronic Age (1985) Kurz und knapp: frühe Doku über die Hacker Community unter anderem mit Steve Wozniak kostenlos in voller Länge verfügbar Hackers in Wonderland (2000) Kurz und knapp: porträtiert UK- und US-Hacker beleuchtet Hacktivismus kostenlos in voller Länge verfügbar Secret History of Hacking (2001) Kurz und knapp: fokussiert frühe Hacking-Techniken mit John Draper, Steve Wozniak und Kevin Mitnick kostenlos in voller Länge verfügbar Hackers Are People Too (2008) Kurz und knapp: von Hackern kreiert will mit Stereotypen aufräumen beleuchtet auch die Rolle der Frauen in der Community We Are Legion: The Story of the Hacktivists (2012) Kurz und knapp: beleuchtet das Hacker-Kollektiv Anonymous zahlreiche O-Töne von Mitgliedern und Experten auf diversen Filmfestivals ausgezeichnet DEFCON: The Documentary (2013) Kurz und knapp: stellt das 20-jährige Jubiläum der Hacking-Konferenz DEFCON in den Fokus bis zu dieser Doku herrschte auf der Konferenz striktes Kameraverbot O-Töne von Teilnehmern und Verantwortlichen Citizenfour (2014) Kurz und knapp: thematisiert Edward Snowden und den NSA-Skandal enthält Interviews mit Snowden aus dem Jahr 2013 entstand unter Beteiligung von Glenn Greenwald Digital Amnesia (2014) Kurz und knapp: wirft ein Schlaglicht auf digitale Daten und den Umgang mit diesen mit Beteiligung von Experten des Internet Archive kostenlos in voller Länge verfügbar Deep Web (2015) Kurz und knapp: thematisiert den Darknet-Marktplatz Silk Road beleuchtet dabei auch die Verhaftung und den Prozess von Gründer Ross Ulbricht O-Töne von zahlreichen Beteiligten A Good American (2015) Kurz und knapp: erzählt die Geschichte des Ex-NSA-Direktors Bill Binney klärt auf, wie ein Computerprogramm 9/11 hätte verhindern können Regie führte der Österreicher Friedrich Moser War for the Web (2015) Kurz und knapp: wirft einen Blick auf die physische Infrastruktur hinter dem Internet zeigt, wie Unternehmen und Regierungen hinter den Kulissen um die Vorherrschaft kämpfen beleuchtet dabei auch Fragen wie Data Ownership, Datenschutz und Security Cyber War (2016) Kurz und knapp: zeigt, wie Regierungen im Kampf gegen kriminelle Hacker aufrüsten dabei kommen auch unlautere Mittel wie Spionage zur Sprache viele prominente O-Töne Down the Deep Dark Web (2016) Kurz und knapp: bietet Insider-Einblicke in das Darknet beleuchtet dabei auch legitime Einsatzzwecke will mit Vorurteilen und Stereotypen aufräumen Zero Days (2016) Kurz und knapp: erzählt die Geschichte des Stuxnet-Virus analysiert ausgiebig die Folgen des Angriffs bietet zahlreiche Insider-Einblicke und O-Töne Facebook: Cracking the Code (2017) Kurz und knapp: beleuchtet die Security-Kultur und -Probleme bei Facebook geht dabei auch auf die Nutzung von User-Daten, Ad-Gebahren und Fake News ein zahlreiche O-Töne von Experten Kim Dotcom: Caught in the Web (2017) Kurz und knapp: erzählt die Geschichte von Megaupload-Gründer Kim Schmitz beleuchtet dabei seinen Kampf gegen die US-Regierung und die Entertainment-Branche zahlreiche O-Töne von Beteiligten – auch Kim selbst The Defenders (2018) Kurz und knapp: analysiert vier schlagzeilenträchtige Cyberattacken nimmt dabei die Perspektive der Verteidiger ein produziert vom Sicherheitsanbieter Cybereason The Great Hack (2019) Kurz und knapp: thematisiert den Skandal um Facebook und Cambridge Analytica nimmt dabei die Perspektive verschiedener Beteiligter auf aufwändig produziert HAK_MTL (2019) Kurz und knapp: kanadische Hacker stellen die Datenschutz-Versprechen von Unternehmen auf die Probe dabei liegt ein Fokus auf Überwachungstechnologien interessante Insider-Einblicke und O-Töne WannaCry: The Marcus Hutchins Story (2019) Kurz und knapp: erzählt die Geschichte des IT-Experten, der WannaCry durch Zufall stoppte und anschließend in Zusammenhang mit einem Banking-Trojaner verhaftet wurde dabei kommt auch Hutchins selbst zu Wort KnowBe4: The Making of a Unicorn (2020) Kurz und knapp: erzählt die Gründungsgeschichte des Security-Unternehmens KnowBe4 mit Beteiligung von Chief Hacking Officer Kevin Mitnick produziert vom Cybercrime Magazine MY.DOOM: Earth’s Deadliest Computer Viruses (2021) Kurz und knapp: thematisiert den Computervirus MyDoom aus dem Jahr 2004 analysiert dabei auch seine Auswirkungen kostenlos in voller Länge verfügbar Biggest Heist Ever – Der große Bitcoin-Raub (2024) Kurz und knapp: thematisiert den Hackerangriff auf die Hong Konger Kryptobörse Bitfinex aus dem Jahr 2016 beleuchtet den Werdegang von Ilya Lichtenstein und Heather Morgan, die für den Angriff verurteilt wurden diverse O-Töne von Ermittlern, Freunden, Betroffenen – und auch von Ilya Lichtenstein selbst Most Wanted: Teen Hacker (2025) Kurz und knapp: beleuchtet die Cybercrime-Karriere des finnischen Hackers Julius Kivimäki enthält Interviews mit Strafverfolgungsbehörden und Opfern des Cyberkriminellen auch Kivimäki selbst kommt zu Wort Joybubbles (2026) Kurz und knapp: erzählt die Geschichte des blinden Telefonhackers Joe Engressia aus dessen eigener Perspektive ursprünglich als Kickstarter-Projekt gestartet erfolgreiche Premiere auf dem Sundance Film Festival 2026 Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

A threat actor is abusing an employee monitoring application and a remote monitoring and management platform in an attempt to deploy ransomware and steal cryptocurrency. According to researchers at Huntress, the unknown threat actor is leveraging NetworkLookout’s Net Monitor for Employees Professional – which, despite its name, includes remote access tools – and SimpleHelp, a suite of tools commonly used by IT teams and managed service providers for remote monitoring and management. These applications might already be in use in an IT environment, or are downloaded by the attacker once they get network access. In one case, the attack chain culminated in an attempted deployment of Crazy ransomware. In another, the combination of applications was used to hunt for cryptocurrency-related keywords on the victim’s compromised computer. The combination of these two applications is unique, says Huntress, although SimpleHelp has a history of being abused by hackers as a post-exploitation persistence mechanism. It offers a lightweight agent, support for gateway redundancy, and ability to operate over common ports. Net Monitor for Employees, whose purpose is to catch employees wasting work time on illegal activity, is used here as a primary remote access channel. To a threat actor, it offers reverse connections over common ports, process and service name masquerading, built-in shell execution, and the ability to silently deploy via standard Windows installation mechanisms. Anna Pham, a Huntress senior tactical response analyst, called the combination of the two applications for attacks “dangerous,” particularly because in one case the threat actor got access to the victim’s IT infrastructure through a vendor’s compromised VPN account. Using applications and tools already on the network that might appear legitimate to IT to disguise attacks, also known as a ‘living off the land’ strategy, is “very clever and sneaky,” she added. Two attacks discovered Huntress discovered two incidents using this tactic, one late in January and one early this month. Shared infrastructure, overlapping indicators of compromise, and consistent tradecraft across both cases make Huntress strongly believe a single threat actor or group was behind this activity. In the first case, Huntress detected suspicious account manipulation on a customer’s computer via Net Monitor For Employees, which included attempts to reset passwords and create additional accounts. The application was already in use in the environment. How the attacker got into Net Monitor isn’t clear. But their next step was to use it to download the SimpleHelp remote management agent, which was used to execute a number of commands, including tampering with Windows Defender to evade detection. That was unsuccessful, but it didn’t stop the threat actor from then trying to deploy the Crazy strain of ransomware. In the second case, also involving a Huntress customer, the threat actor leveraged a compromised vendor’s SSL VPN account for initial access to the IT network. It isn’t known how the threat actor got hold of the vendor’s credentials. But once inside, the hacker used Windows Remote Desktop Protocol (RDP) to install the Net Monitor for Employees Professional agent through PowerShell. The agent was then disguised as a legitimate system process with a name that mimicked Microsoft’s OneDrive service. Shortly after that, the threat actor installed SimpleHelp as an additional persistent remote access channel. The SimpleHelp agent was also configured with monitoring triggers for cryptocurrency-related keywords, as well as searching for remote access tool keywords to determine whether anyone else was connecting to the compromised machine. The threat actor also used Net Monitor for network reconnaissance on a compromised domain controller. Ensure these risks are catalogued Johannes Ullrich, dean of research at the SANS Institute, said this report is an example of how corporate IT teams build infrastructure that attackers then abuse. It’s known that employee monitoring software and security software have been misused like this in the past, he said. He pointed out that software including agents that reach out to remote systems to collect data can often execute code on those systems, so they can investigate suspect activity. But, he warned, if not properly controlled, they can be abused by an attacker to execute malicious code. CSOs must ensure that these risks are properly catalogued and mitigated,” he said. “Any actions performed by these agents must be monitored and, if possible, restricted. The abuse of these systems is a special case of ‘living off the land’ attacks. The attacker attempts to abuse valid existing software to perform malicious actions. This abuse is often difficult to detect.” Asked for comment on the report, a spokesperson for NetworkLookout, the parent company of Net Monitor, noted in an email that the Net Monitor for Employees Agent can be installed only by a user who already has administrative privileges on the computer where the agent is to be installed. Without administrative privileges, the spokesperson added, “installation isn’t possible.” “So,” the spokesperson concluded, “if you don’t want our software installed on a computer, please ensure that administrative access is not granted to unauthorized users.” What CSOs should do Huntress analyst Pham said to defend against attacks combining Net Monitor for Employees Professional and SimpleHelp, infosec pros should inventory all applications so unapproved installations can be detected. Legitimate apps should be protected with robust identity and access management solutions, including multi-factor authentication. Net Monitor for Employees should only be installed on endpoints that don’t have full access privileges to sensitive data or critical servers, she added, because it has the ability to run commands and control systems. She also noted that Huntress sees a lot of rogue remote management tools on its customers’ IT networks, many of which have been installed by unwitting employees clicking on phishing emails. This points to the importance of security awareness training, she said. Infosec leaders should also note that in June 2025, the US Cybersecurity and Infrastructure Security Agency (CISA) warned that ransomware operators had leveraged unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider. The advisory also provided advice on how to mitigate the risks, noting, “This incident reflects a broader pattern of ransomware actors targeting organizations through unpatched versions of SimpleHelp RMM since January 2025.” View the full article

Ransomware has permanently changed how security leaders think about risk. Verizon’s 2025 Data Breach Investigations Report found that ransomware was involved in 44% of all breaches. For small and midsize businesses, the problem is big; ransomware was involved in nearly nine out of 10 breaches, compared to it playing a role in 39% of incidents among large organizations. Many of these attacks begin by breaching privileged accounts and identity infrastructure, targeting identity because of its reach and influence. Compromising identity infrastructure such as Active Directory enables adversaries to escalate privileges and block legitimate users from their own systems within minutes. Even when those applications and data are restored, a compromised identity layer can leave an organization locked out of its environment for the long term, stalling recovery efforts across the enterprise. This is why identity recovery is now a central ingredient in cyber resilience. Identity systems are deeply integrated into authentication and access pathways. When they fail, recovery becomes even more complex. Security leaders know that recovering identity is about bringing systems back up and restoring access securely, so attackers cannot find their way back in. A board-level issue Boards of directors and regulators are now treating resilience as a core component of enterprise risk management. Cyber insurance providers require evidence of tested recovery plans, immutable backups, and defined recovery time and recovery point objectives before underwriting coverage. Regulatory frameworks like the General Data Protection Regulation and the California Consumer Privacy Act impose stiff penalties for extended downtime and data exposure. As a result, organizations are moving beyond traditional backup strategies toward recovery engineering. Recovery is a designed capability rather than an emergency response. It relies on automation, orchestration, and repeatable processes that reduce dependence on manual intervention during high-stress incidents. It also aligns technical recovery with business priorities, helping CISOs communicate resilience in terms that executives and boards understand. To reduce downtime and regain control quickly after a ransomware or identity-based attack, CISOs should prioritize these capabilities: Identity resilience: Implement immutable backups and automated recovery for identity systems such as Active Directory. Zero-trust architecture: Apply least-privilege access and continuous authentication to reduce the blast radius of an attack. Automated orchestration: Limit manual steps in recovery workflows so teams can respond faster under pressure. Regulatory readiness: Make audit-ready reporting and compliance validation part of resilience planning, not an afterthought. AI-ready protection: Account for risks introduced by autonomous agents and AI-driven operations by securing data environments and enabling fast rollback of damaging actions. Backup platform isolation: Treat the backup environment as a separate security domain that can function as a minimum viable recovery environment when needed. Cognizant and Rubrik help organizations improve cyber resilience with a unified, service-based model that integrates data protection, identity resilience, and business continuity. Rubrik provides capabilities such as immutable storage, rapid ransomware recovery, sensitive data discovery, and identity resilience, including support for restoring Active Directory environments. Cognizant brings orchestration across technologies and domain expertise to align recovery actions with business outcomes, ensuring that restoration efforts support operational continuity and compliance requirements. Learn more about how Cognizant and Rubrik are helping organizations strengthen business resilience. If you would like further details or have specific questions, send an email to: [email protected] About Sriramkumar Kumaresan Cognizant Sriram Kumaresan leads the Global Cloud, Infrastructure and Security practice atCognizant, overseeing approximately 35,000 professionals. With over 25 years of experience, he excels in building and scaling businesses from strategy to execution. Sriram is responsible for driving market share (strategy, GTM and growth) and mindshare (offering, partner strategy and market positioning) through strategic approaches, customer centricity and the deep technical expertise inCognizant’s Cloud, Infrastructure and Security business. Beyond his professional achievements, he is also a mentor and advocate for diversity in tech, aiming to inspire future IT leaders. View the full article

A blind spot in Microsoft’s app and add-in marketplace security allowed an eagle-eyed hacker to hijack an abandoned Outlook add-in to carry out phishing attacks that compromised 4,000 users, researchers have discovered. The app in question, AgreeTo, is, or was, a meeting scheduling tool that first appeared in 2022 but was abandoned at some point after that by its developer. Despite this, the add-in continued to be listed on Microsoft’s site. A hacker noticed the change in its status and hijacked the dead add-in and its 4.71-star rating to conduct a phishing campaign that the company which uncovered the attack, plug-in security company Koi Security, later discovered had successfully stolen thousands of Microsoft account credentials. Was it a clever takeover by a sophisticated attacker? In fact, according to Koi Security, the hijack was easy, thanks to weaknesses in the process through which developers submit add-ins to Microsoft’s marketplace. Submitting an add-in to Microsoft merely involves sending a simple XML manifest that lists the add-in’s name and description, the URL from which it is downloaded, and any permissions it needs. No code is uploaded for assessment. AgreeTo’s manifest simply linked to a subdomain URL, outlook-one.vercel.app, hosted on the Vercel development platform, from which users download the software. “Microsoft reviews the manifest, signs it, and lists the add-in in their store. But the actual content – the UI, the logic, everything the user interacts with – is fetched live from the developer’s server every time the add-in opens,” said Koi Security’s researchers. Orphaned URL By grabbing the abandoned subdomain, the attacker gained control of whatever the URL in the original manifest pointed to. This content was replaced with a new URL pointing to a phishing kit comprising a fake Microsoft sign-in page for password collection, an exfiltration script, and a redirect. The original manifest also granted the attacker permission to read and modify emails. “They didn’t submit anything to Microsoft. They weren’t required to pass any review. They didn’t create a store listing. The listing already existed – Microsoft-reviewed, Microsoft-signed, Microsoft-distributed. The attacker just claimed an orphaned URL, and Microsoft’s infrastructure did the rest,” said Koi Security. Phished credentials and victim IP addresses were automatically sent to the attacker via a simple Telegram bot, without the need for complex command & control, Koi Security said. The researchers were able to get inside this infrastructure, discovering that 4,000 victims had fallen into the attacker’s phishing trap; all were later contacted by Koi Security to warn that their credentials had been compromised. The same attacker was found to be operating 12 different phishing kits impersonating a variety of banks and webmail providers, Koi Security added. Data stolen from these sites included credit card numbers, CVVs, PINs, and banking security answers used by recipients to receive payments made via the Interac e-Transfer system, as well as password credentials. The weakness revealed by the AgreeTo hijack is Microsoft’s add-in delivery architecture; it just distributes a simple, and potentially unreliable, URL. Because of this, Koi Security pointed out, “an add-in that’s clean on Monday can serve a phishing page on Tuesday – or, as in this case, years later. Microsoft reviews the manifest at submission, but the actual content can change at any time without further review.” Ironically, the weakness was identified as long ago as 2019 by another security company, MDSec. AgreeTo is believed to be the first malicious Outlook add-in ever discovered on the Microsoft Marketplace, which might explain why deeper URL checking wasn’t implemented after this research. As of February 12, the AgreeTo add-in is no longer available from Microsoft Marketplace. Anyone still using AgreeTo is advised to remove it as soon as possible, and to reset their Microsoft account passwords. A separate AgreeTo extension for Chrome stopped working in 2024; Google removed it in February 2025. This article originally appeared on Computerworld. View the full article

Rawat Yapathanasap – shutterstock.com Ransomware-Attacken, Phishing und digitale Sabotage: Vor dem Hintergrund der zunehmenden Cyberbedrohungslage hat das Frankfurter Cyberintelligence Institute (CII) ein digitales Warnsystem namens Cyber Risk Observation Service (CYROS) für Smartphones entwickelt. Die CYROS-App bündelt alle sicherheitsrelevanten Informationen aus behördlichen Warnmeldungen. Zu den Quellen zählen unter anderem das Bundesamt für Sicherheit in der Informationstechnik (BSI), Verbraucherschutzorganisationen und Sicherheitsunternehmen sowie zukünftig auch die Security Operations Center (SOC) von Datagroup. Die Warnmeldungen werden dabei laut CII mit passgenauen Informationen und Hilfestellungen verknüpf. „Es gibt bereits viele Unterstützungsangebote, oftmals sind sie aber nur schwer auffindbar, wenn sie gebraucht werden”, erklärt CII-Forschungsdirektor Dennis-Kenji Kipker. Um die Auffindbarkeit weiter zu vereinfachen, sortiert CYROS aktuelle Meldungen zudem nach Themen, Lebensbereiche und Bundesland. “Jeder Cybervorfall verdeutlicht die Dringlichkeit zum eigenen Handeln, zu dem CYROS konkret befähigt” erklärt auch Dino Huber vom CYROS-Projektpartner Datagroup. Damit stärke die App auch die Cybersicherheit in Deutschland insgesamt. Die App ist ab sofort über die gängigen App-Stores kostenfrei verfügbar, Außerdem sind die Meldungen auch online unter cyros-warnapp.de zugänglich. View the full article

Fortinet researchers have disclosed a new phishing campaign delivering the commercially available XWorm malware, chaining a years-old Microsoft Office vulnerability with fileless execution to escape detection. The campaign, which uses multi-themed phishing emails and a malicious Excel add-in, ultimately deploys the modular remote access trojan (RAT) capable of encrypted command-and control (C2) and plugin-based expansion. “This campaign is striking in its ordinariness,” said Shane Barney, chief information security officer at Keeper Security. “There’s no breakthrough technique here. It’s a clean execution chain built from components we’ve all seen before. The sophistication isn’t in the novelty, it’s in the assembly.” Attackers used a phishing email carrying a malicious Excel add-in that exploits CVE-2018-0802, a memory corruption flaw in Office patched in 2018. The attack then continues into HTA and PowerShell-based execution to load additional components of the attack. Attackers used a familiar entry point According to a Fortinet blog post, the campaign relies on business-themed phishing lures and the legacy remote code execution vulnerability in the Microsoft Equation Editor that defenders have known for years. Fortinet noted that the continued success of CVE-2018-0802 suggests patching gaps remain a viable attack surface. Jason Soroko, senior fellow at Sectigo, said the pairing of routine phishing with modern backend tradecraft is what makes the campaign notable. “What stands out here is how ‘old’ and ‘routine’ the front end is, and how modern the back end remains,” he said. “The lure is a familiar business pretexting and a malicious Excel add-in, but the real signal is the attacker’s confidence that legacy Office exploit paths still convert at scale. The attachment abuses CVE-2018-0802, then pivots quickly into HTA plus PowerShell to keep the heavy lifting off disk.” Fortinet researchers added that the remote code privileges gained through CVE-2018-0802 further allow execution of HTA and PowerShell components, keeping much of the activity off disk. “That combination is a reminder that patch hygiene and macro or script execution policy are still doing more real work than most organizations want to admit,” Soroko added. Fileless .NET stage and a modular XWorm core Beyond initial access, Fortinet observed a fileless .NET stage loaded directly into memory, followed by process hollowing into msbuild.exe, a legitimate Microsoft build tool capable of executing .NET code. The choice of msbuild.exe aligns with the malware’s runtime requirements while helping it blend into normal system activity. “A fileless .NET stage loaded in memory, followed by process hollowing into msbuild.exe, is a clean ‘blend in’ move that leverages a legitimate .NET-capable binary and complicates attribution for simplistic detections,” Soroko said. “Fortinet’s rationale for msbuild.exe is especially useful for defenders because it ties the LOLBin choice to the malware’s .NET runtime needs, not just generic masquerading.” Once active, XWorm communicates with its C2 using an AES-encrypted packet, which supports a broad plugin ecosystem. That modularity, the researchers noted, expands its capabilities beyond remote access, enabling credential theft, data exfiltration, disruption, and modernization paths depending on what the operator wants. Fortinet said XWorm supports a wide range of operator commands, including system control (CLOSE, uninstall, update), file download and execution (DW, LN), plugin loading, screenshot capture ($Cap), keylogger retrieval, DDoS control, and shutdown or restart functions. The disclosure also listed indicators of compromise tied to the campaign, including phishing URLs and domains used to host HTA and loader files, the C2 server, file hashes for the malicious Excel attachment, and the final XWorm payload. Barney emphasized that the broader risk hinges less on the malware label and more on post-compromise controls. “Campaigns like this expose a simple reality: the entry vector is predictable. The tooling is commoditized. The only real variable is whether the environment limits what an intruder can do next,” he said. View the full article

Cybersecurity company Palo Alto Networks has completed its $25 billion acquisition of Israel-based identity security firm CyberArk, bringing privileged access and identity security into the core of its platform strategy. With this acquisition, Palo Alto aims to extend privileged access controls across human, machine, and AI identities, reduce standing privileges, limit lateral movement, and stop identity-based attacks faster, the company said. The deal also marks what the company describes as the end of “identity silos,” enabling customers to manage privileged access across hybrid cloud environments through a unified platform, said Nikesh Arora, Chairman and CEO of Palo Alto Networks, in a statement. According to Palo Alto, organizations that use identity-driven security controls can accelerate their breach response by up to 80% by preventing attackers from abusing credentials and obtaining excessive access. Closing the privileged access gap The move comes at a time when identity has emerged as one of the most targeted layers in enterprise attacks, driven by the rapid adoption of cloud, automation, and AI. “In a cloud-first world, the network perimeter has largely disappeared, and identity has become the new perimeter, with most major breach reports showing that compromised credentials are central to attacks. The rise of agentic identity makes this even more urgent as enterprises deploy autonomous AI agents that read emails, query databases, and trigger workflows. These agents operate 24/7 and often hold broad permissions to function reliably,” said Pareekh Jain, CEO at EIIRTrend & Pareekh Consulting. If an attacker compromises an AI agent’s identity, they can execute attacks at machine speed, exfiltrating data or disrupting systems faster than human teams can respond, Jain pointed out. That is the layer CyberArk has traditionally focused on securing. The company specializes in privileged access management, and its expertise in securing credentials, passwords, and privileged accounts across hybrid, multi-cloud, and on-premises environments has made it a key player for enterprises seeking to protect their most sensitive accounts. And while network, cloud, and endpoint visibility are areas where Palo Alto is already present, analysts say the CyberArk acquisition strengthens a capability that was not deeply native to its platform. “The integration will strengthen Palo Alto’s zero trust strategy by embedding CyberArk’s PAM, Identity Provider from Idaptive, and Identity Governance from Zilla into its network, cloud, and SOC tools like Prisma and Cortex, enabling unified visibility, automated privilege enforcement, and protection for human, machine, and AI agent identities,” added Jain. For Palo Alto Networks, this fills a core gap in a platform strategy because identity is the policy anchor for Zero Trust access and enforcement. It should strengthen the “reduce standing privilege and blast radius” story across cloud, endpoint, and SecOps workflows, not as a bolt-on but as a first-class pillar, said Chirag Mehta, vice president and principal analyst at Constellation Research. Customer impact and integration risks While Palo Alto is integrating CyberArk’s capabilities into its security ecosystem, the company will continue to offer CyberArk’s identity security solutions as a standalone platform. This signals continuity and roadmap stability for existing customers in the near term. “Standalone CyberArk availability is expected to continue, now backed by Palo Alto’s global scale, expanded support, Unit 42 threat intelligence, and AI-driven analytics for stronger real-time risk detection,” added Jain. However, Devroop Dhar, MD at Primus Partners, says the risk, as with any acquisition, is transition friction. “Product roadmaps may shift, interfaces change, and customers worry that pricing bundles or licensing models will evolve. Some may also worry about vendor lock-in as identity becomes tightly coupled with a single broader platform,” he said. On the other hand, enterprises using Palo Alto had to work with other vendors to get identity governance or privileged access. Now, identity becomes a native part of the platform story, which can simplify Zero Trust programs by linking privileged identity controls to network, cloud, and SecOps enforcement, noted Mehta. The upside is better end-to-end policy and faster response when identity is the initiating signal, Mehta said. “The watch-out is how smoothly Palo Alto integrates the tech and licensing without adding complexity or disrupting existing identity ecosystems.” Race to own the identity plane As security platforms continue to converge, vendors are moving away from standalone point solutions toward unified ecosystems that combine network, cloud, endpoint, and identity controls under a single architecture. This shift reflects growing enterprise demand for integrated visibility and policy enforcement rather than fragmented toolsets. “In putting identity deeply into its stack, Palo Alto moves closer to competing with Microsoft’s identity-centric approach and with broader platform players combining endpoint, cloud, and access security,” Dhar said. Jain noted that this acquisition also positions Palo Alto as a full-stack identity player in identity security (PAM, IGA, IdP), challenging Okta and others by combining CyberArk’s depth with superior threat detection and SASE. View the full article

In my experience leading engineering projects, I have encountered the same pattern repeatedly. We obsess over deployment speed. We measure success in commit velocity and uptime. But we rarely pause to ask the most uncomfortable question in the room: Who actually owns the identities we just spun up? This silence isn’t malicious; it’s structural. We have optimized our entire software delivery lifecycle for the creation of resources, but we have almost no muscle memory for their destruction. We celebrate the “Hello World” of a new service, but we have no ceremony for its decommissioning. For years, I watched this disconnect play out. I would sit in planning meetings where we architected systems to scale to thousands of pods in seconds. Yet, our security governance model was still stuck in the era of manual ticket approvals. We were building Ferraris and trying to secure them with bicycle locks. The reality today is that our infrastructure has fundamentally changed, but our identity governance has not. We are still trying to audit ghosts. We attempt to secure ephemeral workloads that live for milliseconds using spreadsheets designed for servers that last for years. The silent explosion we’re not tracking If you look at the dashboards of any modern enterprise today, you will see a metric that should keep you up at night. It is not the number of employees you have. It is the number of things acting like employees. For every human developer onboarded, we inadvertently create a massive number of machine identities. Service accounts, API keys and workload tokens accumulate like digital dust. Research suggests that non-human identities now outnumber humans by a factor of 10 to 1 or more. Consider the lifecycle of a typical microservice. In its journey from a developer’s laptop to production, it might generate a dozen distinct identities: a GitHub token for the repository, a CI/CD service account for the build, a registry credential to push the container, and multiple runtime roles to access databases, queues and logging services. The problem is not just volume; it is invisibility. When a developer leaves, HR triggers an offboarding process. Their email is cut, their badge stops working. But what about the five service accounts they hardcoded into a deployment script three years ago? Those usually stay active, unmonitored, waiting for someone to find them. Often, these “zombie identities” retain administrative privileges long after their original purpose has vanished, simply because no one is brave enough to turn them off. The “test tenant” trap I have seen too many teams fall into the trap of thinking a test environment does not matter. “It’s just dev,” they say. “There’s no real customer data there.” This complacency is fatal because identity boundaries are rarely as clean as we think they are. In reality, test environments are often where attackers go first. It is the path of least resistance. We saw this play out in the Microsoft Midnight Blizzard attack. The attackers did not burn a zero-day exploit to break down the front door; they found a legacy test tenant that nobody was watching closely. They compromised a non-human identity and used that access to pivot straight into production corporate emails. These are not harmless leftovers. They are open backdoors. The danger lies in the relationships between environments. If a “test” CI/CD runner has permission to push to a “production” container registry, or if a developer reuses a password across both environments, the “test” label is nothing more than a false sense of security. Supply chain reliability is an identity problem We also need to talk about the tools we trust. The Codecov incident shook the confidence of every engineering lead I know because it wasn’t a code vulnerability—it was a credential vulnerability. Attackers extracted a credential from a Docker image creation process. They used a static secret to hijack the Bash Uploader script. This allowed them to modify the script on the fly, effectively turning a trusted development tool into a data exfiltration engine. This is the defining challenge of our decade. Our software supply chain is held together by thousands of API keys and secrets. If we continue to rely on long-lived static credentials to glue our pipelines together, we are building on sand. Every static key sitting in a repo—no matter how private you think it is—is a ticking time bomb. It only takes one developer to accidentally commit a .env file or one compromised S3 bucket to expose the keys to the kingdom. The AI acceleration If managing static bots feels like drowning, the rise of agentic AI is about to hand us a firehose. We are rushing to deploy AI agents that do not just chat—they execute code. These are autonomous workloads that can read databases and trigger API calls. An AI agent is effectively a highly privileged employee that works at machine speed. Unlike traditional automation scripts, which are deterministic and follow a strict set of instructions, AI agents are probabilistic. They make decisions based on context. If an AI agent is tasked with “optimizing cloud spend,” and it has broad permissions, it might decide to shut down a critical production database because it deemed it “underutilized.” Or, if it is tricked by a prompt injection attack, it could be coerced into exfiltrating sensitive customer data. If you have not solved identity governance for your existing microservices, you are not ready for autonomous AI. If an attacker compromises an AI agent, they inherit its identity. If that identity has broad access because “it was easier to configure that way,” you have automated your own data breach. The cultural cost of static security Beyond the technical risks, there is a profound cultural cost to our current approach. When identity governance is slow, manual and ticket-based, it becomes an adversary to engineering velocity. I have seen developers spend days waiting for a ticket to be approved just to get read access to an S3 bucket. This friction breeds Shadow IT. Developers, under pressure to ship, will bypass the official process. They will share static keys over Slack, hardcode credentials into their apps or reuse a high-privilege “admin” key for everything because it’s the path of least resistance. Paradoxically, by trying to control everything with heavy-handed gates, we end up with less visibility and less control. The goal of modern identity governance shouldn’t be to say “no” more often; it should be to make the secure path the fastest path. 3 strategic shifts How do we fix this? As illustrated in Figure 1, we need a framework that shifts from static reviews to continuous governance. There are no silver bullets, but three engineering principles consistently reduce risk without killing velocity. Figure 1: Governance must move from static reviews to a continuous lifecycle of issuance, verification and automated expiration.Niranjan Kumar Sharma 1. Identity must be cryptographic We must stop relying on IP allowlists. In a world of dynamic containers, network location is a poor proxy for trust. We need to move toward cryptographic identity. Every workload must present a verifiable certificate, whether it lives for five years or five milliseconds. Frameworks like SPIFFE allow us to issue short-lived identities to workloads automatically. This means we trust the software, not the network cable it is plugged into. This approach, often called “workload attestation,” verifies the binary running the process before issuing it an identity document (SVID). If the binary has been tampered with, it gets no identity and therefore, no access. 2. Kill the static credential Static keys are technical debt. They are the “password on a sticky note” of the cloud era. We need to aggressively shorten the lifespan of credentials. If a human needs access, it should expire at the end of the day. If a machine needs access, it should expire in minutes. When a credential works for only ten minutes, its value to an attacker drops to near zero. You fundamentally change the economics of the attack. Practically, this means adopting standards like OIDC Federation for your CI/CD pipelines. Instead of storing a long-lived AWS secret in your GitHub Actions settings, your build job should exchange a temporary token with AWS to get short-lived access that expires the moment the build finishes. This pattern, documented extensively by providers like AWS and GitHub, eliminates the “secret zero” problem entirely. 3. Automate the cleanup We cannot manually review 50,000 permissions. The math does not work. We must use Cloud Infrastructure Entitlement Management (CIEM) to automate the cleanup. We need tools that look at what permissions a service account actually used in the last 90 days. If it hasn’t written to that S3 bucket in three months, revoke the permission automatically. Treat “Least Privilege” not as a philosophy, but as an automated garbage collection process. This automation is critical because humans are naturally risk-averse. No engineer wants to be the one who caused an outage by deleting a key they thought was unused. Data-driven automation removes that fear, allowing us to prune privileges with confidence. Final thoughts The infrastructure we build has become ephemeral. Yet our mindset is still static. We cannot continue to govern modern cloud environments with the tools of the past decade. By adopting cryptographic identity and eliminating static secrets, we can build systems that are fast and secure. The future of security is not about slowing down; it is about building guardrails that move as fast as we do. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

The new personal AI agent orchestration tool known as OpenClaw — formerly Clawdbot, then Moltbot — is a personal assistant that can do tasks for you without your personal supervision. It can operate across devices, interact with online services, trigger workflows — no wonder the Github repo has seen millions of visits and over 160,000 stars in the past couple of weeks. According to its developer, OpenClaw’s repo has also had over 2 million visitors over the course of a single week, and there are around 1.7 million agents whose human owners have signed them up for the Moltbook social media platform where they share gossip about, well, their humans. As of this writing, the agents have made nearly 7 million comments on around a quarter million posts. And according to security researchers at OX Security, OpenClaw downloads are now at 720,000 per week. What makes OpenClaw so appealing is that it runs locally, can be configured to use any LLM on the back end, and talks to its user via the chat apps they already use — WhatsApp, Telegram, Discord, Slack, Teams — and has pre-built integrations with all the major operating systems, and many different smart home devices, productivity apps, Chrome and Gmail, and a lot more. This is what AI agents were supposed to be. And it’s free and open source. What’s not to love? “The appeal is so amazing,” says John Dwyer, deputy CTO at Binary Defense. “We’ve been watching movies for 25 years with AI assistants like Jarvis in Iron Man. There’s an appeal to having this tangible value add for AI. And it’s so easy to use. If it wasn’t so inherently insecure, I would love to use it.” The cybersecurity risks of OpenClaw “The problem with running this is that these tools can do basically anything that a user can do,” says Rich Mogull, chief analyst at Cloud Security Alliance. “But it’s controlled externally. For an enterprise, this could be high risk. There are some guardrails that can be put around it, but they’re new, unproven, and have already been circumvented by researchers.” His recommendation: CISOs prohibit its use altogether. “I’m looking forward to experimenting with it myself over the weekend,” Mogull says. “But you shouldn’t be allowing it at this point in time. The answer has to be ‘no.’ There is no security model.” And there’s no time to waste. Token reports that, over the course of a week of analysis, it found that 22% of their customers had employees actively using the tool in their organizations. The implications extend beyond immediate technical risks. “For enterprises, this could mean exposure to fines, litigation, and reputational damage among customers and partners due to data confidentiality breaches,” says Georgia Cooke, analyst at ABI Research. That includes personal data which could result in breaches of GDPR and similar PII control rules, and corporate information under NDA. Other risks include competitive damage due to exposure of intellectual property and enabling further attacks through exposure of technical and credential information. Security researcher Maor Dayan called OpenClaw “the largest security incident in sovereign AI history.” His research has already found more than 42,000 instances exposed on the internet, with 93% of verified instances exhibiting critical authentication bypass vulnerabilities. Early versions of OpenClaw were insecure by default, according to Dayan, the rapid viral adoption overwhelmed users’ security awareness, and many deployments were quickly abandoned, leaving behind instances running outdated code. Documented attack paths enable credential theft, browser control, and potential remote code execution. In late January, Gartner researchers said that OpenClaw “reveals strong demand for agentic AI but exposes major security risks.” According to Gartner, there are already demonstrated vulnerabilities allowing remote code execution within hours of deployment. The ClawHub skills marketplace — folders of instructions, scripts, and resources that agents can discover and use to do things more accurately and efficiently, as per OpenClaw — introduces critical supply chain risks. And credentials are stored in plaintext and compromised hosts expose API keys, OAuth tokens and sensitive conversations. “AI agents often have tokens and secrets in configuration files,” says Jeremy Kirk, director of threat intelligence at Okta. “All of them get exposed if users have them misconfigured. In an enterprise context, that’s not good.” Then Noma Security discovered a new security blind spot related to OpenClaw: corporate Discord, Telegram or WhatsApp groups. One of the things that makes OpenClaw so appealing to users is that they can interact with it over multiple channels. But if OpenClaw is part of one of these channels, and there are other users on that channel, it treats instructions from those other users as if they came from their own owner. If an attacker joins a public-facing Discord server with an OpenClaw agent installed, the attacker can instruct the bot to execute a cron job and crawl the local file system for tokens, passwords, API keys, and crypto seed phrases. “Within 30 seconds, the agent bundles the sensitive data and sends it straight to the attacker’s-controlled server,” Noma’s researchers say. To the corporate security team, it looks like the bot is functioning normally, and the breach isn’t detected until the stolen credentials are weaponized. “When social media teams or external contractors deploy autonomous agents like Clawdbot, they are effectively opening a persistent and unmonitored back door into the local machines that touch your corporate infrastructure.” And OpenClaw is a security risk even if employees run it at home, on their personal machines, because it might be able to access enterprise applications through user credentials via browser controls or skills. The security risks keep getting worse by the day. According to researchers at OX Security, the developer community around OpenClaw is also a major liability. The project embraces vibe-coded submissions, which accelerates development, but also introduces significant security risks. OS researchers say they found multiple insecure coding patterns in the codebase, patterns that could lead to remote code execution, path traversal, DDoS and cross-site scripting attacks. “There are no sufficient guardrails,” the researchers say. They also found multiple instances of bug reports being disclosed in GitHub, instead of in private messages to maintainers. When an issue is posted publicly it is “giving attackers an opportunity to quickly gain knowledge of vulnerabilities even without doing any research or penetration testing,” they wrote. To rub salt into the wounds, there is also no formal security patching and updating process, and most users don’t update, they just stay on the version they first downloaded. And then there are the skills. Security researcher and OpenSourceMalware founder Paul McCarty has identified about 400 different malicious skills on ClawHub, a central repository for the OpenClaw platform. These skills purport to help with tasks such as cryptocurrency trading, LinkedIn job applications, or downloading a YouTube video thumbnail. Some have thousands of downloads and are among the most downloaded skills on ClawHub. But what they actually do is trick the user into installing malware. To demonstrate how easy it is to get a malicious skill into the OpenClaw ecosystem, security researcher Jamieson O’Reilly built one of his own, artificially inflated its download count to over 4,000 — making it the most downloaded skill on the platform — and watched developers from seven different countries execute arbitrary commands on their machines, thinking they’d downloaded a real skill. “This was a proof of concept, a demonstration of what’s possible,” he wrote. “In the hands of someone less scrupulous, those developers would have had their SSH keys, AWS credentials, and entire codebases exfiltrated before they knew anything was wrong.” OpenClaw exposes enterprise security gaps The first big lesson of this whole OpenClaw situation is that enterprises need to do more to get their security fundamentals in place. Because if there are any gaps, anywhere at all, they will now be found and exploited at an unprecedented pace. In the case of OpenClaw, that means limiting user privileges to the bare minimum, having multi-factor authentication on all accounts, and putting other basic security hygiene in place. It won’t solve the problem of OpenClaw — and of all the other agentic AI platforms coming down the line — but it will help limit exposure risks and reduce the blast radius when there is a breach. And there are steps that enterprises can take to limit the dangers associated with OpenClaw in particular, says IEEE senior member Kayne McGladrey. To start with, companies can look at network-level telemetry. “What’s the network traffic coming out of a device?” McGladrey asks. “Is this thing suddenly using a lot of AI at a rapid pace? Are there massive spikes going on with token usage?” Organizations can also use tools like Shodan to find publicly addressable instances, he adds, though internal firewall configurations may hide others. And for organizations that want to allow experimentation rather than outright bans, he suggests a measured approach. “We have to talk about phased pilot programs for users interested in it.” For example, users may be allowed to run OpenClaw on managed endpoints with segmentation rules that isolate them from internal systems, along with strong telemetry and continuous monitoring of agent activity, outbound traffic, and alerts for anomalous behaviors. OpenClaw is a sign of what’s to come OpenClaw isn’t unique. It’s viral, but there are many other tools in the works that put similar amounts of power in the hands of potentially untrustworthy agents. There are AI platforms that can control a person’s computer and browser, such as the recently released Claude Cowork from Anthropic. There are agents that sit in the browser and can access user sessions, like Gemini in Chrome. And there are copilots galore, as well as agentic tools from companies like Salesforce. These agentic platforms, when they come from major vendors, are usually limited in functionality, tightly guard-railed, and reasonably well tested, so it may take a while for the biggest security issues to come to light. Still, they often rely on third-party skills from untrusted sources. Researchers from universities in China, Australia, and Singapore recently analyzed more than 42,000 agent skills from several different agentic AI platforms and found that 26% contained at least one vulnerability. Meanwhile, startups and open-source projects like OpenClaw are going to jump ahead of what OpenAI, Anthropic, Google and other major vendors are offering. They move faster because they don’t let things like security get in the way. For example, as of this writing, OpenClaw founder Peter Steinberger’s pinned X post says: “Confession: I ship code I never read.” “If this was easy, Microsoft would have written this,” says IEEE’s McGladrey. “But there aren’t a lot of options out there. I think that’s the real thing we’re working against here.” There’s a fundamental security disconnect between having a tool that will do anything and everything for its users, quickly and easily, with no friction and one that abides by good safety practices. About that Moltbook Finally, there’s Moltbook, the social platform for AI agents. It’s not all bad. Some of the agents discuss ways to make their users’ lives easier by proactively identifying and fixing problems while the humans sleep. And one of the most popular posts, with over 60,000 comments, is about how to solve security issues related to ClawdHub skills. Other popular threads include one about the meaning of existence and there is also lots of AI spam. It’s a fun read, in a going-down-the-AI-rabbit hole kind of way. But Moltbook itself is a vibe-coded project, created by developer Matt Schlicht over the course of a few days, and is its own security hellscape. According to research from security firm Wiz, the entire back end of the platform was exposed. Researchers found 1.5 million API keys, 35,000 email addresses, and private messages between agents. These issues have since been fixed, but there is other security problems related to this site. For example, researchers found that agents were sharing OpenAI API keys with one another. An attacker no longer needs to find an open Discord server to give instructions to an OpenClaw AI agent. They can just post content to Moltbook. And if the site itself is compromised, every connected agent could become an attack vector. In fact, on 31 January, there was a critical vulnerability that allowed anyone to commandeer any agent on the platform. Moltbook was taken offline, and all agent API keys were reset, according to Astrix Security. Immediate action steps According to Gartner, enterprises should take the following steps: Immediately block OpenClaw downloads and traffic to prevent shadow installs and to identify users attempting to bypass security controls Immediately rotate any corporate credentials accessed by OpenClaw Only allow OpenClaw instances in isolation, in non-production virtual machines with throwaway credentials Prohibit unvetted OpenClaw skills to mitigate risks of supply chain attacks and prompt injection payloads View the full article

The new personal AI agent orchestration tool known as OpenClaw — formerly Clawdbot, then Moltbot — is a personal assistant that can do tasks for you without your personal supervision. It can operate across devices, interact with online services, trigger workflows — no wonder the Github repo has seen millions of visits and over 160,000 stars in the past couple of weeks. According to its developer, OpenClaw’s repo has also had over 2 million visitors over the course of a single week, and there are around 1.7 million agents whose human owners have signed them up for the Moltbook social media platform where they share gossip about, well, their humans. As of this writing, the agents have made nearly 7 million comments on around a quarter million posts. And according to security researchers at OX Security, OpenClaw downloads are now at 720,000 per week. What makes OpenClaw so appealing is that it runs locally, can be configured to use any LLM on the back end, and talks to its user via the chat apps they already use — WhatsApp, Telegram, Discord, Slack, Teams — and has pre-built integrations with all the major operating systems, and many different smart home devices, productivity apps, Chrome and Gmail, and a lot more. This is what AI agents were supposed to be. And it’s free and open source. What’s not to love? “The appeal is so amazing,” says John Dwyer, deputy CTO at Binary Defense. “We’ve been watching movies for 25 years with AI assistants like Jarvis in Iron Man. There’s an appeal to having this tangible value add for AI. And it’s so easy to use. If it wasn’t so inherently insecure, I would love to use it.” The cybersecurity risks of OpenClaw “The problem with running this is that these tools can do basically anything that a user can do,” says Rich Mogull, chief analyst at Cloud Security Alliance. “But it’s controlled externally. For an enterprise, this could be high risk. There are some guardrails that can be put around it, but they’re new, unproven, and have already been circumvented by researchers.” His recommendation: CISOs prohibit its use altogether. “I’m looking forward to experimenting with it myself over the weekend,” Mogull says. “But you shouldn’t be allowing it at this point in time. The answer has to be ‘no.’ There is no security model.” And there’s no time to waste. Token reports that, over the course of a week of analysis, it found that 22% of their customers had employees actively using the tool in their organizations. The implications extend beyond immediate technical risks. “For enterprises, this could mean exposure to fines, litigation, and reputational damage among customers and partners due to data confidentiality breaches,” says Georgia Cooke, analyst at ABI Research. That includes personal data which could result in breaches of GDPR and similar PII control rules, and corporate information under NDA. Other risks include competitive damage due to exposure of intellectual property and enabling further attacks through exposure of technical and credential information. Security researcher Maor Dayan called OpenClaw “the largest security incident in sovereign AI history.” His research has already found more than 42,000 instances exposed on the internet, with 93% of verified instances exhibiting critical authentication bypass vulnerabilities. Early versions of OpenClaw were insecure by default, according to Dayan, the rapid viral adoption overwhelmed users’ security awareness, and many deployments were quickly abandoned, leaving behind instances running outdated code. Documented attack paths enable credential theft, browser control, and potential remote code execution. In late January, Gartner researchers said that OpenClaw “reveals strong demand for agentic AI but exposes major security risks.” According to Gartner, there are already demonstrated vulnerabilities allowing remote code execution within hours of deployment. The ClawHub skills marketplace — folders of instructions, scripts, and resources that agents can discover and use to do things more accurately and efficiently, as per OpenClaw — introduces critical supply chain risks. And credentials are stored in plaintext and compromised hosts expose API keys, OAuth tokens and sensitive conversations. “AI agents often have tokens and secrets in configuration files,” says Jeremy Kirk, director of threat intelligence at Okta. “All of them get exposed if users have them misconfigured. In an enterprise context, that’s not good.” Then Noma Security discovered a new security blind spot related to OpenClaw: corporate Discord, Telegram or WhatsApp groups. One of the things that makes OpenClaw so appealing to users is that they can interact with it over multiple channels. But if OpenClaw is part of one of these channels, and there are other users on that channel, it treats instructions from those other users as if they came from their own owner. If an attacker joins a public-facing Discord server with an OpenClaw agent installed, the attacker can instruct the bot to execute a cron job and crawl the local file system for tokens, passwords, API keys, and crypto seed phrases. “Within 30 seconds, the agent bundles the sensitive data and sends it straight to the attacker’s-controlled server,” Noma’s researchers say. To the corporate security team, it looks like the bot is functioning normally, and the breach isn’t detected until the stolen credentials are weaponized. “When social media teams or external contractors deploy autonomous agents like Clawdbot, they are effectively opening a persistent and unmonitored back door into the local machines that touch your corporate infrastructure.” And OpenClaw is a security risk even if employees run it at home, on their personal machines, because it might be able to access enterprise applications through user credentials via browser controls or skills. The security risks keep getting worse by the day. According to researchers at OX Security, the developer community around OpenClaw is also a major liability. The project embraces vibe-coded submissions, which accelerates development, but also introduces significant security risks. OS researchers say they found multiple insecure coding patterns in the codebase, patterns that could lead to remote code execution, path traversal, DDoS and cross-site scripting attacks. “There are no sufficient guardrails,” the researchers say. They also found multiple instances of bug reports being disclosed in GitHub, instead of in private messages to maintainers. When an issue is posted publicly it is “giving attackers an opportunity to quickly gain knowledge of vulnerabilities even without doing any research or penetration testing,” they wrote. To rub salt into the wounds, there is also no formal security patching and updating process, and most users don’t update, they just stay on the version they first downloaded. And then there are the skills. Security research Paul McCarty has identified about 400 different malicious skills on ClawHub, a central repository for the OpenClaw platform. These skills purport to help with tasks such as cryptocurrency trading, LinkedIn job applications, or downloading a YouTube video thumbnail. Some have thousands of downloads and are among the most downloaded skills on ClawHub. But what they actually do is trick the user into installing malware. To demonstrate how easy it is to get a malicious skill into the OpenClaw ecosystem, security researcher Jamieson O’Reilly built one of his own, artificially inflated its download count to over 4,000 — making it the most downloaded skill on the platform — and watched developers from seven different countries execute arbitrary commands on their machines, thinking they’d downloaded a real skill. “This was a proof of concept, a demonstration of what’s possible,” he wrote. “In the hands of someone less scrupulous, those developers would have had their SSH keys, AWS credentials, and entire codebases exfiltrated before they knew anything was wrong.” OpenClaw exposes enterprise security gaps The first big lesson of this whole OpenClaw situation is that enterprises need to do more to get their security fundamentals in place. Because if there are any gaps, anywhere at all, they will now be found and exploited at an unprecedented pace. In the case of OpenClaw, that means limiting user privileges to the bare minimum, having multi-factor authentication on all accounts, and putting other basic security hygiene in place. It won’t solve the problem of OpenClaw — and of all the other agentic AI platforms coming down the line — but it will help limit exposure risks and reduce the blast radius when there is a breach. And there are steps that enterprises can take to limit the dangers associated with OpenClaw in particular, says IEEE senior member Kayne McGladrey. To start with, companies can look at network-level telemetry. “What’s the network traffic coming out of a device?” McGladrey asks. “Is this thing suddenly using a lot of AI at a rapid pace? Are there massive spikes going on with token usage?” Organizations can also use tools like Shodan to find publicly addressable instances, he adds, though internal firewall configurations may hide others. And for organizations that want to allow experimentation rather than outright bans, he suggests a measured approach. “We have to talk about phased pilot programs for users interested in it.” For example, users may be allowed to run OpenClaw on managed endpoints with segmentation rules that isolate them from internal systems, along with strong telemetry and continuous monitoring of agent activity, outbound traffic, and alerts for anomalous behaviors. OpenClaw is a sign of what’s to come OpenClaw isn’t unique. It’s viral, but there are many other tools in the works that put similar amounts of power in the hands of potentially untrustworthy agents. There are AI platforms that can control a person’s computer and browser, such as the recently released Claude Cowork from Anthropic. There are agents that sit in the browser and can access user sessions, like Gemini in Chrome. And there are copilots galore, as well as agentic tools from companies like Salesforce. These agentic platforms, when they come from major vendors, are usually limited in functionality, tightly guard-railed, and reasonably well tested, so it may take a while for the biggest security issues to come to light. Still, they often rely on third-party skills from untrusted sources. Researchers from universities in China, Australia, and Singapore recently analyzed more than 42,000 agent skills from several different agentic AI platforms and found that 26% contained at least one vulnerability. Meanwhile, startups and open-source projects like OpenClaw are going to jump ahead of what OpenAI, Anthropic, Google and other major vendors are offering. They move faster because they don’t let things like security get in the way. For example, as of this writing, OpenClaw founder Peter Steinberger’s pinned X post says: “Confession: I ship code I never read.” “If this was easy, Microsoft would have written this,” says IEEE’s McGladrey. “But there aren’t a lot of options out there. I think that’s the real thing we’re working against here.” There’s a fundamental security disconnect between having a tool that will do anything and everything for its users, quickly and easily, with no friction and one that abides by good safety practices. About that Moltbook Finally, there’s Moltbook, the social platform for AI agents. It’s not all bad. Some of the agents discuss ways to make their users’ lives easier by proactively identifying and fixing problems while the humans sleep. And one of the most popular posts, with over 60,000 comments, is about how to solve security issues related to ClawdHub skills. Other popular threads include one about the meaning of existence and there is also lots of AI spam. It’s a fun read, in a going-down-the-AI-rabbit hole kind of way. But Moltbook itself is a vibe-coded project, created by developer Matt Schlicht over the course of a few days, and is its own security hellscape. According to research from security firm Wiz, the entire back end of the platform was exposed. Researchers found 1.5 million API keys, 35,000 email addresses, and private messages between agents. These issues have since been fixed, but there is other security problems related to this site. For example, researchers found that agents were sharing OpenAI API keys with one another. An attacker no longer needs to find an open Discord server to give instructions to an OpenClaw AI agent. They can just post content to Moltbook. And if the site itself is compromised, every connected agent could become an attack vector. In fact, on 31 January, there was a critical vulnerability that allowed anyone to commandeer any agent on the platform. Moltbook was taken offline, and all agent API keys were reset, according to Astrix Security. Immediate action steps According to Gartner, enterprises should take the following steps: Immediately block OpenClaw downloads and traffic to prevent shadow installs and to identify users attempting to bypass security controls Immediately rotate any corporate credentials accessed by OpenClaw Only allow OpenClaw instances in isolation, in non-production virtual machines with throwaway credentials Prohibit unvetted OpenClaw skills to mitigate risks of supply chain attacks and prompt injection payloads View the full article

Gorodenkoff | shutterstock.com Statt einfach “nur” Fehler in Applikationen auszunutzen, entdecken kriminelle Hacker zunehmend die Tools und Zugriffskanäle für sich, auf die sich Softwareentwickler regelmäßig verlassen. Dabei kombinieren sie längst auch unterschiedliche Cybercrime-Taktiken und beziehen auch künstliche Intelligenz (KI) ein, um an ihr Ziel zu gelangen. “Angreifer versuchen nicht mehr nur, in Ihr Netzwerk einzudringen. Sie haben es jetzt auch auf Ihre Workflows abgesehen. Und Ihre Entwickler besitzen die ‚Schlüssel zum Königreich‘ – in Form von privilegiertem Zugriff auf Quellcode und die Cloud-Infrastruktur. Das macht sie zu einem hochkarätigen Ziel für Angreifer“, konstatiert Chris Wood, Principal Application Security SME beim Sicherheitsanbieter Immersive. Wir haben mit Wood und diversen anderen Sicherheitsprofis erörtert, auf welche Bereiche CISOs und Sicherheitsentscheider ihr Augenmerk bei diesem Angriffsvektor legen sollten – und welche Defensivmaßnahmen sich empfehlen, um gegenzusteuern. Vergiftete Ökosysteme Darren Meyer, Security Research Advocate bei Checkmarx, beobachtet regelmäßig viele Angriffe auf Entwickler, die er als “Low Effort” einstuft – etwa schadhafte Versionen beliebter Open-Source-Utilities, die auf Typosquatting-Domains gehostet werden. Diese “Spray and Pray”-Bemühungen stellten aber nur eine Seite der Medaille dar, warnt Meyer: “Es finden auch deutlich gezieltere Attacken statt, wie etwa der Shai-Hulud-Wurm, Angriffe auf npm-Packages oder das Plugin-Ökosystem von Visual Studio Code eindrücklich belegen.” Die Einschätzung des Checkmarx-Experten spiegelt sich auch im aktuellen Sonatype-Report “2026 State of the Software Supply Chain 2026” (Download gegen Daten) wider. Der Spezialist für Lieferkettensicherheit hat seit 2019 insgesamt 1,23 Millionen quelloffene Packages identifiziert, die mit Malware verseucht waren. Allein im Jahr 2025 registrierte Sonatype 454.000 neue Exemplare, die in diese Kategorie fallen. Und damit nicht genug: “In der Praxis wird Vulnerability Exposure in weiten Teilen nicht durch neue Schwachstellen getrieben, sondern durch bereits bekannte”, schreiben die Sicherheitsexperten in ihrem Bericht. Demnach haben Developer im Jahr 2025 mehr als 42 Millionen mal anfällige Versionen der Logging-Utility Log4j heruntergeladen. Mit Blick auf alle Log4j-Downloads entspricht das einem Anteil von 13 Prozent. Kompromittierte Entwicklungsumgebungen Die Angreifer haben es darüber hinaus vor allem auch auf Softwareentwicklungsumgebungen abgesehen. Das liegt auch daran, dass gängige Security-Verfehlungen wie überprivilegierte Accounts, langlebige Token oder falsch konfigurierte Pipelines einen illegalen Zugriff auf Development Environments – und damit sensible Daten – relativ einfach machen. “Zugangsdaten, die unsachgemäß gespeichert werden, sind selbst für unerfahrene Angreifer ein leichtes Ziel”, hält Crystal Morin, Senior Cybersecurity Strategist beim Observability-Anbieter Sysdig, fest. Insider-Bedrohungen Allerdings stehlen kriminelle Hacker nicht unbedingt Zugangsdaten, um Zugriff auf die Systeme von Unternehmen zu erlangen. Stattdessen bewerben sie sich einfach als Mitarbeiter. Solche “Fake Worker”-Kampagnen sind unter anderem bei nordkoreanischen Bedrohungsakteuren beliebt. Die Taktik: Technisch versierte Angreifer setzen gefälschte Identitäten und Social-Engineering-Tricks ein, um einen Job zu ergattern. Einmal im Unternehmen, stehlen sie dann Daten und Geschäftsgeheimnisse – auch zu dem Zweck, diese später als Druckmittel für Erpressungen zu nutzen. Sysdig-Managerin Morin ergänzt: “Angreifer geben sich dabei auch als Maintainer aus und versuchen so, Schadcode in populäre Open-Source-Projekte einzuschleusen. So wie etwa im Fall der XZ Utils-Backdoor.” Supply-Chain-Risiken Gelingt es den Cyberkriminellen, eine gemeinsam genutzte Softwarebibliothek in der Lieferkette zu kompromittieren, kann das dazu führen, dass sich eine Infektion rasant ausbreitet. Laut Gavin Millard, Vice President of Intelligence beim Exposure-Management-Spezialisten Tenable, haben Supply-Chain-Bedrohungen inzwischen Exploits als größtes systemisches Cybersicherheitsrisiko abgelöst: “Mit Supply-Chain-Angriffen wie den Hijacking-Attacken auf S1ngularity und npm-Maintainer können Cyberkriminelle in wenigen Minuten weit mehr erreichen, als mit einem Jahr Spear Phishing und Systemscans. Die Lieferkette zu missbrauchen, ist für Angreifer eine Art Kraftmultiplikator”, erklärt Millard. Nutzten Developer eine solche verseuchte Quelle, könne im Nachgang jede der von ihnen entwickelten Anwendungen – und sämtliche ihrer User – infiziert werden. Aktuelle Studien belegen, dass dieses Problem auch den Anwendern bewusst ist. 65 Prozent der Unternehmen, die das Weltwirtschaftsforum für seinen “Global Cybersecurity Outlook 2026” (PDF) befragt hat, betrachten Schwachstellen in Lieferketten und bei Drittanbietern als ihre größte Security-Herausforderung. Gegenüber dem Vorjahr hat sich dieser Wert um 54 Prozent gesteigert. Kombinierte Threat-Modelle Zudem gingen Cyberkriminelle zunehmend dazu über, technische Kompromittierungen mit Social-Engineering-Taktiken und KI zu kombinieren, um die Wirksamkeit ihrer Angriffe zu erhöhen. Christopher Jess, Senior R&D Manager beim Sicherheitsanbieter Black Duck, erklärt wie: “Ein schadhaftes Package kann mit subtilen Hintertüren versehen sein. Dessen Verbreitung lässt sich etwa mit Fake-Nachrichten von Maintainern oder anderen, vertrauenswürdigen Personen und angeblich dringenden Pull Requests für Sicherheitskorrekturen forcieren.” KI erhöhe schließlich noch den Scope und die Präzision dieser Attacken, so Jess: “Phishing und Pretexting werden so mit mehr Kontext ausgestattet. Etwa, indem Repositories, Commit-Historien und Team-Rollen abgeglichen werden. Zudem können die Angreifer mit KI auch plausibel erscheinende Codeänderungen oder Dokumentationen erstellen, um Verdachtsmomente in Review-Prozessen möglichst zu unterbinden.” KI-Tools für Entwickler als Risiko-Addon KI-gestützte Softwareentwicklung und Vibe Coding erhöhen die Sicherheitsrisiken zusätzlich – insbesondere, weil der so generierte Code häufig ohne ausreichendes Testing, eine Dokumentation oder Traceability generiert wird. Jamie Beckland, Chief Product Officer beim Security-Unternehmen APIContext, warnt insbesondere vor wachsenden Risiken durch die Einführung von KI-Agenten und MCP-Servern: “MCP-Server können modifiziert werden, indem man sie um Tools ergänzt – beispielsweise, um Daten aus internen APIs, Data Stores oder SaaS-Systemen zu extrahieren.” Das Risiko manifestiere sich dabei nicht nur im LLM-Modell selbst, sondern auch in der Oberfläche der Tools und ihren Funktionen. “MCP-Server auf Änderungen in der Tool-Infrastruktur und den Datenzugriffsrechten des Servers zu überprüfen ist entscheidend”, hält Beckland fest. Auch Pieter Danhieux, CEO und Mitbegründer von Secure Code Warrior, sieht MCP-Server und Agentic AI als fruchtbaren Boden für Cyberkriminelle – schließlich sei es relativ simpel, hier absichtlich unsichere Prompts oder KI-generierten Schadcode einzuschleusen. Und damit nicht genug: „Wir haben außerdem beobachtet, dass Bedrohungsakteure KI-Agenten mit nicht autorisierten Anweisungen überlisten, die vermeintlich von dessen berechtigtem Benutzer stammen. Hierbei handelt es sich um die sogenannte Confused Deputy-Schwachstelle.“ Dazu passend spricht auch Sonatype von einer “KI-Intelligenzlücke”, nachdem der Anbieter für seinen Report 37.000 Empfehlungen von GPT-5 analysiert hat. Laut den Security-Experten handelte es sich in knapp 28 Prozent der Fälle um Halluzinationen. In einigen Fällen hat das KI-Tool dabei auch empfohlen, Malware-verseuchte Packages zu installieren. Und auch die Verantwortlichen des Benchmark-Projekts BaxBench kommen in einer aktuellen Untersuchung zum Ergebnis, dass 62 Prozent der Lösungen, die von Large Language Models generiert werden, entweder fehlerhaft sind oder Sicherheitslücken beherbergen. Was CISOs tun können Um die Softwareentwicklung besser abzusichern, empfiehlt sich für CISOs und Sicherheitsentscheider ein kombinierter Ansatz aus: technischen Kontrollen, Security-Schulungen, sowie kulturellen Maßnahmen. Strengere Identitätsprüfungen, Account-Hygiene und Least-Privilege-Prinzip können auch mit Blick auf Development-Prozesse zu mehr Sicherheit beitragen. Eric Paulsen, EMEA-CTO beim Dev-Plattformanbieter Coder, empfiehlt darüber hinaus: “Isolieren Sie Arbeitsbereiche in Containern, zentralisieren Sie Image und Secrets Management und setzen Sie regelmäßige Audits sowie eine Protokollierung aller Prozesse durch.” Für David Sugden, Leiter der Entwicklungsabteilung bei der Digitalberatung Axiologik, besteht eine weitere Best Practice seit jeher darin, Workflow-Aktionen mit unveränderlichen SHA-Hashes zu verknüpfen, die auf manipulationssicheren Hardwaremodulen gespeichert sind. “Davon abgesehen stellen Whitelists, Secrets Scanning und Software-Composition-Analysen weiterhin die DevSecOps-Grundlagen dar, die das Schutzniveau erhöhen”, unterstreicht Sugden. Er empfiehlt zudem, den direkten Zugriff auf externe Abhängigkeiten zu beschränken, um zu verhindern, dass unsichere Packages heruntergeladen werden. Geht es nach Michael Burch, Application Security Advocate beim Cybersecurity-Schulungsanbieter Security Journey, ist es außerdem besonders wichtig, Softwareentwicklern fortlaufendes Hands-On-Training zu bieten: “Developer brauchen realistische Übungen; Sie müssen die Auswirkungen von Systemausfällen mit den eigenen Augen sehen – und dazu befähigt werden, Sicherheitsprobleme selbst zu beheben.” View the full article

Gorodenkoff | shutterstock.com Statt einfach “nur” Fehler in Applikationen auszunutzen, entdecken kriminelle Hacker zunehmend die Tools und Zugriffskanäle für sich, auf die sich Softwareentwickler regelmäßig verlassen. Dabei kombinieren sie längst auch unterschiedliche Cybercrime-Taktiken und beziehen auch künstliche Intelligenz (KI) ein, um an ihr Ziel zu gelangen. “Angreifer versuchen nicht mehr nur, in Ihr Netzwerk einzudringen. Sie haben es jetzt auch auf Ihre Workflows abgesehen. Und Ihre Entwickler besitzen die ‚Schlüssel zum Königreich‘ – in Form von privilegiertem Zugriff auf Quellcode und die Cloud-Infrastruktur. Das macht sie zu einem hochkarätigen Ziel für Angreifer“, konstatiert Chris Wood, Principal Application Security SME beim Sicherheitsanbieter Immersive. Wir haben mit Wood und diversen anderen Sicherheitsprofis erörtert, auf welche Bereiche CISOs und Sicherheitsentscheider ihr Augenmerk bei diesem Angriffsvektor legen sollten – und welche Defensivmaßnahmen sich empfehlen, um gegenzusteuern. Vergiftete Ökosysteme Darren Meyer, Security Research Advocate bei Checkmarx, beobachtet regelmäßig viele Angriffe auf Entwickler, die er als “Low Effort” einstuft – etwa schadhafte Versionen beliebter Open-Source-Utilities, die auf Typosquatting-Domains gehostet werden. Diese “Spray and Pray”-Bemühungen stellten aber nur eine Seite der Medaille dar, warnt Meyer: “Es finden auch deutlich gezieltere Attacken statt, wie etwa der Shai-Hulud-Wurm, Angriffe auf npm-Packages oder das Plugin-Ökosystem von Visual Studio Code eindrücklich belegen.” Die Einschätzung des Checkmarx-Experten spiegelt sich auch im aktuellen Sonatype-Report “2026 State of the Software Supply Chain 2026” (Download gegen Daten) wider. Der Spezialist für Lieferkettensicherheit hat seit 2019 insgesamt 1,23 Millionen quelloffene Packages identifiziert, die mit Malware verseucht waren. Allein im Jahr 2025 registrierte Sonatype 454.000 neue Exemplare, die in diese Kategorie fallen. Und damit nicht genug: “In der Praxis wird Vulnerability Exposure in weiten Teilen nicht durch neue Schwachstellen getrieben, sondern durch bereits bekannte”, schreiben die Sicherheitsexperten in ihrem Bericht. Demnach haben Developer im Jahr 2025 mehr als 42 Millionen mal anfällige Versionen der Logging-Utility Log4j heruntergeladen. Mit Blick auf alle Log4j-Downloads entspricht das einem Anteil von 13 Prozent. Kompromittierte Entwicklungsumgebungen Die Angreifer haben es darüber hinaus vor allem auch auf Softwareentwicklungsumgebungen abgesehen. Das liegt auch daran, dass gängige Security-Verfehlungen wie überprivilegierte Accounts, langlebige Token oder falsch konfigurierte Pipelines einen illegalen Zugriff auf Development Environments – und damit sensible Daten – relativ einfach machen. “Zugangsdaten, die unsachgemäß gespeichert werden, sind selbst für unerfahrene Angreifer ein leichtes Ziel”, hält Crystal Morin, Senior Cybersecurity Strategist beim Observability-Anbieter Sysdig, fest. Insider-Bedrohungen Allerdings stehlen kriminelle Hacker nicht unbedingt Zugangsdaten, um Zugriff auf die Systeme von Unternehmen zu erlangen. Stattdessen bewerben sie sich einfach als Mitarbeiter. Solche “Fake Worker”-Kampagnen sind unter anderem bei nordkoreanischen Bedrohungsakteuren beliebt. Die Taktik: Technisch versierte Angreifer setzen gefälschte Identitäten und Social-Engineering-Tricks ein, um einen Job zu ergattern. Einmal im Unternehmen, stehlen sie dann Daten und Geschäftsgeheimnisse – auch zu dem Zweck, diese später als Druckmittel für Erpressungen zu nutzen. Sysdig-Managerin Morin ergänzt: “Angreifer geben sich dabei auch als Maintainer aus und versuchen so, Schadcode in populäre Open-Source-Projekte einzuschleusen. So wie etwa im Fall der XZ Utils-Backdoor.” Supply-Chain-Risiken Gelingt es den Cyberkriminellen, eine gemeinsam genutzte Softwarebibliothek in der Lieferkette zu kompromittieren, kann das dazu führen, dass sich eine Infektion rasant ausbreitet. Laut Gavin Millard, Vice President of Intelligence beim Exposure-Management-Spezialisten Tenable, haben Supply-Chain-Bedrohungen inzwischen Exploits als größtes systemisches Cybersicherheitsrisiko abgelöst: “Mit Supply-Chain-Angriffen wie den Hijacking-Attacken auf S1ngularity und npm-Maintainer können Cyberkriminelle in wenigen Minuten weit mehr erreichen, als mit einem Jahr Spear Phishing und Systemscans. Die Lieferkette zu missbrauchen, ist für Angreifer eine Art Kraftmultiplikator”, erklärt Millard. Nutzten Developer eine solche verseuchte Quelle, könne im Nachgang jede der von ihnen entwickelten Anwendungen – und sämtliche ihrer User – infiziert werden. Aktuelle Studien belegen, dass dieses Problem auch den Anwendern bewusst ist. 65 Prozent der Unternehmen, die das Weltwirtschaftsforum für seinen “Global Cybersecurity Outlook 2026” (PDF) befragt hat, betrachten Schwachstellen in Lieferketten und bei Drittanbietern als ihre größte Security-Herausforderung. Gegenüber dem Vorjahr hat sich dieser Wert um 54 Prozent gesteigert. Kombinierte Threat-Modelle Zudem gingen Cyberkriminelle zunehmend dazu über, technische Kompromittierungen mit Social-Engineering-Taktiken und KI zu kombinieren, um die Wirksamkeit ihrer Angriffe zu erhöhen. Christopher Jess, Senior R&D Manager beim Sicherheitsanbieter Black Duck, erklärt wie: “Ein schadhaftes Package kann mit subtilen Hintertüren versehen sein. Dessen Verbreitung lässt sich etwa mit Fake-Nachrichten von Maintainern oder anderen, vertrauenswürdigen Personen und angeblich dringenden Pull Requests für Sicherheitskorrekturen forcieren.” KI erhöhe schließlich noch den Scope und die Präzision dieser Attacken, so Jess: “Phishing und Pretexting werden so mit mehr Kontext ausgestattet. Etwa, indem Repositories, Commit-Historien und Team-Rollen abgeglichen werden. Zudem können die Angreifer mit KI auch plausibel erscheinende Codeänderungen oder Dokumentationen erstellen, um Verdachtsmomente in Review-Prozessen möglichst zu unterbinden.” KI-Tools für Entwickler als Risiko-Addon KI-gestützte Softwareentwicklung und Vibe Coding erhöhen die Sicherheitsrisiken zusätzlich – insbesondere, weil der so generierte Code häufig ohne ausreichendes Testing, eine Dokumentation oder Traceability generiert wird. Jamie Beckland, Chief Product Officer beim Security-Unternehmen APIContext, warnt insbesondere vor wachsenden Risiken durch die Einführung von KI-Agenten und MCP-Servern: “MCP-Server können modifiziert werden, indem man sie um Tools ergänzt – beispielsweise, um Daten aus internen APIs, Data Stores oder SaaS-Systemen zu extrahieren.” Das Risiko manifestiere sich dabei nicht nur im LLM-Modell selbst, sondern auch in der Oberfläche der Tools und ihren Funktionen. “MCP-Server auf Änderungen in der Tool-Infrastruktur und den Datenzugriffsrechten des Servers zu überprüfen ist entscheidend”, hält Beckland fest. Auch Pieter Danhieux, CEO und Mitbegründer von Secure Code Warrior, sieht MCP-Server und Agentic AI als fruchtbaren Boden für Cyberkriminelle – schließlich sei es relativ simpel, hier absichtlich unsichere Prompts oder KI-generierten Schadcode einzuschleusen. Und damit nicht genug: „Wir haben außerdem beobachtet, dass Bedrohungsakteure KI-Agenten mit nicht autorisierten Anweisungen überlisten, die vermeintlich von dessen berechtigtem Benutzer stammen. Hierbei handelt es sich um die sogenannte Confused Deputy-Schwachstelle.“ Dazu passend spricht auch Sonatype von einer “KI-Intelligenzlücke”, nachdem der Anbieter für seinen Report 37.000 Empfehlungen von GPT-5 analysiert hat. Laut den Security-Experten handelte es sich in knapp 28 Prozent der Fälle um Halluzinationen. In einigen Fällen hat das KI-Tool dabei auch empfohlen, Malware-verseuchte Packages zu installieren. Und auch die Verantwortlichen des Benchmark-Projekts BaxBench kommen in einer aktuellen Untersuchung zum Ergebnis, dass 62 Prozent der Lösungen, die von Large Language Models generiert werden, entweder fehlerhaft sind oder Sicherheitslücken beherbergen. Was CISOs tun können Um die Softwareentwicklung besser abzusichern, empfiehlt sich für CISOs und Sicherheitsentscheider ein kombinierter Ansatz aus: technischen Kontrollen, Security-Schulungen, sowie kulturellen Maßnahmen. Strengere Identitätsprüfungen, Account-Hygiene und Least-Privilege-Prinzip können auch mit Blick auf Development-Prozesse zu mehr Sicherheit beitragen. Eric Paulsen, EMEA-CTO beim Dev-Plattformanbieter Coder, empfiehlt darüber hinaus: “Isolieren Sie Arbeitsbereiche in Containern, zentralisieren Sie Image und Secrets Management und setzen Sie regelmäßige Audits sowie eine Protokollierung aller Prozesse durch.” Für David Sugden, Leiter der Entwicklungsabteilung bei der Digitalberatung Axiologik, besteht eine weitere Best Practice seit jeher darin, Workflow-Aktionen mit unveränderlichen SHA-Hashes zu verknüpfen, die auf manipulationssicheren Hardwaremodulen gespeichert sind. “Davon abgesehen stellen Whitelists, Secrets Scanning und Software-Composition-Analysen weiterhin die DevSecOps-Grundlagen dar, die das Schutzniveau erhöhen”, unterstreicht Sugden. Er empfiehlt zudem, den direkten Zugriff auf externe Abhängigkeiten zu beschränken, um zu verhindern, dass unsichere Packages heruntergeladen werden. Geht es nach Michael Burch, Application Security Advocate beim Cybersecurity-Schulungsanbieter Security Journey, ist es außerdem besonders wichtig, Softwareentwicklern fortlaufendes Hands-On-Training zu bieten: “Developer brauchen realistische Übungen; Sie müssen die Auswirkungen von Systemausfällen mit den eigenen Augen sehen – und dazu befähigt werden, Sicherheitsprobleme selbst zu beheben.” View the full article