CSOonline

Threat actors exploiting the React2Shell vulnerability in components of React servers are using their access to compromise web domains and divert web traffic for malicious purposes. That’s the conclusion of researchers at Datadog Security Labs, who said in a blog Wednesday that the primary targets are sites running the NGINX open-source web server managed with Boato Panel. These include Asian organizations with top level domains ending in .in, .id, .pe, .bd, .edu, .gov, and .th, as well as Chinese hosting infrastructure. The danger, said blog author Ryan Simon, a senior security researcher at Datadog Security Labs, is that a hacker can use a compromised site to do a number of nasty things such as fingerprint an organization’s web traffic, insert malware onto users’ computers, or divert traffic to a threat actor-controlled landing page that tries to trick users into giving up login credentials. These last two tactics also end up damaging a website’s reputation, Simon added, if the word gets around that the site hosts malware. NGINX is a “foundational element of contemporary web infrastructure,” the Datadog blog notes. The routing and processing of traffic by NGINX is governed by its configuration files. Poor configuration or a successful breach allow it to be used for web traffic hijacking. For CSOs, the defense against these attacks is to lock down those configuration files to resist their being tampered with. React2Shell is the exploitation of a vulnerability (CVE-2025-55182) in the React 19 library for building application interfaces that was discovered late last year. The hole allows attackers to execute arbitrary code on affected servers. Related content: Anatomy of React2Shell Researchers at Greynoise said this week that exploitation activity targeting React Server Components has consolidated significantly. Two IP addresses now account for 56% of all observed exploitation attempts, down from 1,083 unique sources earlier. Unpatched versions of React are at risk of compromise. Initial abuse “What we saw in a lot of our honeypots and threat intelligence early on with React2Shell is attackers were using it for cryptomining,” said Simon. Others have seen exploitation used to deploy reverse shells. But more recently, Simon said, Datadog Security is seeing threat actors, once in an IT network, going after web servers to highjack their traffic. An analysis of the scripts used by threat actors on compromised NGINX web servers shows they use a multi-stage and automated approach to attacking the environments. The toolkits contain target discovery plus several scripts designed to establish persistence and for the creation of malicious configuration files containing instructions intended to redirect web traffic, says the Datadog blog. There is no commonality among the targeted organizations, Simon noted. Hijacking web traffic is an old tactic for threat actors. In fact David Shipley, head of Canadian security awareness training provider Beauceron Security, called these attacks on NGINX servers “a return to old-school hacking in the era of stronger identity controls like password managers, MFA and passkeys.” “If you’re up against a more robustly defended user, you go back to attacking the infrastructure so you can go back into attacker-in-the-middle mode for some good old session cookie capture and other hijinks on the NGINX,” he said. Finding and exploiting server side vulnerabilities or network security vulnerabilities is fast, cheap, and easy with AI, he added. Simon said CSOs can help protect NGINX servers from being exploited by monitoring configuration file integrity, including keeping records of their server configurations so any changes can be spotted. It’s vital that web servers have the latest security patches, he added. And admins should also monitor the NGINX security advisory website. View the full article

Threat actors exploiting the React2Shell vulnerability in components of React servers are using their access to compromise web domains and divert web traffic for malicious purposes. That’s the conclusion of researchers at Datadog Security Labs, who said in a blog Wednesday that the primary targets are sites running the NGINX open-source web server managed with Boato Panel. These include Asian organizations with top level domains ending in .in, .id, .pe, .bd, .edu, .gov, and .th, as well as Chinese hosting infrastructure. The danger, said blog author Ryan Simon, a senior security researcher at Datadog Security Labs, is that a hacker can use a compromised site to do a number of nasty things such as fingerprint an organization’s web traffic, insert malware onto users’ computers, or divert traffic to a threat actor-controlled landing page that tries to trick users into giving up login credentials. These last two tactics also end up damaging a website’s reputation, Simon added, if the word gets around that the site hosts malware. NGINX is a “foundational element of contemporary web infrastructure,” the Datadog blog notes. The routing and processing of traffic by NGINX is governed by its configuration files. Poor configuration or a successful breach allow it to be used for web traffic hijacking. For CSOs, the defense against these attacks is to lock down those configuration files to resist their being tampered with. React2Shell is the exploitation of a vulnerability (CVE-2025-55182) in the React 19 library for building application interfaces that was discovered late last year. The hole allows attackers to execute arbitrary code on affected servers. Related content: Anatomy of React2Shell Researchers at Greynoise said this week that exploitation activity targeting React Server Components has consolidated significantly. Two IP addresses now account for 56% of all observed exploitation attempts, down from 1,083 unique sources earlier. Unpatched versions of React are at risk of compromise. Initial abuse “What we saw in a lot of our honeypots and threat intelligence early on with React2Shell is attackers were using it for cryptomining,” said Simon. Others have seen exploitation used to deploy reverse shells. But more recently, Simon said, Datadog Security is seeing threat actors, once in an IT network, going after web servers to highjack their traffic. An analysis of the scripts used by threat actors on compromised NGINX web servers shows they use a multi-stage and automated approach to attacking the environments. The toolkits contain target discovery plus several scripts designed to establish persistence and for the creation of malicious configuration files containing instructions intended to redirect web traffic, says the Datadog blog. There is no commonality among the targeted organizations, Simon noted. Hijacking web traffic is an old tactic for threat actors. In fact David Shipley, head of Canadian security awareness training provider Beauceron Security, called these attacks on NGINX servers “a return to old-school hacking in the era of stronger identity controls like password managers, MFA and passkeys.” “If you’re up against a more robustly defended user, you go back to attacking the infrastructure so you can go back into attacker-in-the-middle mode for some good old session cookie capture and other hijinks on the NGINX,” he said. Finding and exploiting server side vulnerabilities or network security vulnerabilities is fast, cheap, and easy with AI, he added. Simon said CSOs can help protect NGINX servers from being exploited by monitoring configuration file integrity, including keeping records of their server configurations so any changes can be spotted. It’s vital that web servers have the latest security patches, he added. And admins should also monitor the NGINX security advisory website. View the full article

Russia-linked attackers are reportedly using a new Microsoft vulnerability as part of a coordinated espionage and malware campaign, Operation Neusploit. The campaign was spotted in January 2026 by Security researchers at ZScaler ThreatLabz, three days after Microsoft issued an urgent patch for the flaw. “In this campaign, the threat actor leveraged specially crafted Microsoft RTF files to exploit CVE-2026-21509 and deliver malicious backdoors in a multi-stage infection chain,” the researchers said in a blog post. “ThreatLabz observed active in-the-wild exploitation on January 29, 2026.” The campaign targeted users in parts of Central and Eastern Europe, including Ukraine, Slovakia, and Romania, with custom social engineering lures. The crafted rich text format (RTF) files triggered the Office vulnerability the moment they were opened, initiating a multi-stage infection chain leading to backdoors and malware implants. Owing to the significant overlap between the tools, techniques, and procedures (TTPs) between the campaign and those of Russia’s General Staff Main Intelligence Directorate (GRU)-affiliated threat group APT28 (aka Fancy Bear), ZScaler attributed the campaign to the advanced persistent threat (APT) group. Neusploit hooked users through Office Operation Neusploit relies heavily on CVE-2026-21509, a high-severity bug in Microsoft Office that Microsoft patched on January 26 after reports of active exploitation. The infection begins with victims receiving an email with an RTF attachment that contains a weaponized exploit. When opened, the RTF file causes Microsoft Office to execute code that reaches out to threat actor infrastructure and downloads a dropper DLL. The DLL then executes the rest of the malicious chain. “The threat actor employed server-side evasion techniques, responding with the malicious DLL only when requests originated from the targeted geographic region and included the correct User-Agent HTTP header,” the researchers said. The campaign used two different variants of the dropper DLL, deploying different components for different purposes. One campaign, two infection paths ZScaler found that exploitation of CVE-2026-21509 did not lead to a single uniform payload. Instead, the initial RTF-based exploit branched into two distinct infection paths, each serving a different operational purpose. The choice of dropper reportedly determined whether the attackers prioritized near-term intelligence collection or longer-term access to compromised systems. In one path, the exploit delivered MiniDoor, a lightweight DLL that focused on email theft. The malware modified Windows registry settings to weaken Microsoft Outlook security controls, allowing it to quietly collect and exfiltrate email data to an attacker-controlled infrastructure. The design and functionality of MiniDoor closely resemble earlier APT28 tooling, aligning with the group’s established espionage-focused attacks. The second path involved a more elaborate chain that began with PixyNetLoader, which deployed additional payloads and established persistence using techniques such as DLL proxying and COM object hijacking. This loader ultimately installed a Covenant Grunt implant, used specifically in .NET command and control (c2) framework, giving the attackers sustained remote access through cloud-hosted C2 infrastructure. Mitigation efforts ZScaler recommended that organizations prioritize patching for CVE-2026-21509, noting that APT28 exploited the flaw within days of Microsoft releasing fixes. Systems running unpatched versions of Microsoft Office remain exposed to weaponized RTF documents that require little user interaction beyond opening the file, significantly raising the risk of compromise in email-driven attack scenarios. For defensive analysis, ZScaler shared GitHub repositories, including the Windows scheduled task configuration file and the MiniDoor macro code, illustrating the attack paths used in Operation Neusploit. Additionally, the disclosure shared a list of indicators of compromise (IOCs) to support detection efforts, which included file hashes, malicious domains, and URLs. CISA had added the flaw to its known exploited vulnerabilities (KEV) database, giving Federal Civilian Executive Branch (FCEB) agencies until February 16 to patch their systems. View the full article

Romina Mineralbrunnen GmbH Der Getränke-Abfüller Romina mit Sitz in Reutlingen-Rommelsbach wurde kürzlich von einer Cyberattacke getroffen. Wie das Unternehmen auf seiner Website erklärt, sei man deshalb weder telefonisch noch per E-Mail erreichbar. Laut einem Bericht des Reutlinger General-Anzeiger steht auch die Produktion aktuell still. Weitere Details zu dem Vorfall gibt es bisher nicht. Daher ist unklar, wie der Angriff genau abgelaufen ist. Ebenfalls ist nicht bekannt, ob Daten gestohlen wurden. Der Regionalzeitung Südwest Presse zufolge ermittelt die Polizei Reutlingen bereits in dem Fall. Romina Mineralbrunnen beschäftigt nach eigenen Angaben 130 Mitarbeiterinnen und Mitarbeiter. 2024 hatte das Unternehmen 180,7 Millionen Füllungen verzeichnet und einen Umsatz von mehr als 40 Millionen Euro erwirtschaftet. View the full article

Over the past three years, I’ve led passwordless migration initiatives at three Fortune 500 companies, and I can tell you with confidence that eliminating passwords from a hybrid Active Directory and Microsoft Entra ID environment is one of the most rewarding — and most underestimated — technical challenges in modern identity management. The theoretical appeal is obvious: no passwords means no credential compromise, phishing becomes exponentially harder and your security posture fundamentally shifts from “prevent breaches” to “assume breach.” But the reality of implementation in environments spanning on-premises and cloud infrastructure? That’s where the genuine complexity lives. Most organizations I’ve worked with start this journey with romantic notions of flipping a switch and sailing into a passwordless future. What they discover instead is that achieving true passwordless authentication requires rethinking identity architecture from the ground up. It’s not about swapping one authentication method for another — it’s about fundamentally restructuring how you verify identity across every layer of your infrastructure. The transition demands careful planning, technical rigor and unwavering commitment to security principles over convenience. Prerequisites: Building the foundation before the migration Before we can talk about passwordless authentication, we need to address what I call the “prerequisite triangle”: cloud Kerberos trust, device registration and Conditional Access policies. Skip any one of these, and your migration will stall before it gains momentum. Cloud Kerberos trust is the unsung hero of hybrid passwordless deployments. When I started working on my first full migration, I underestimated how critical this piece was. Traditional Kerberos assumes a managed network with domain controllers you control. Cloud Kerberos allows your cloud-based services to issue Kerberos tickets to hybrid-joined devices without requiring a domain controller on the internet. This is your bridge between on-premises and cloud identity, and it’s non-negotiable for seamless hybrid authentication. The mechanics of Kerberos itself haven’t changed significantly since its introduction in the 1980s, but extending it to cloud environments required a fundamental rethinking of how authentication tickets are issued and validated across trust boundaries. Getting cloud Kerberos working requires Azure AD Connect to run version 2.0 or later with the cloud sync agent configured for password hash synchronization (even if you’re not using it for authentication — this remains a prerequisite). Your hybrid-joined devices need to be running Windows 10 20H2 or later, and they must have reliable network connectivity to both your on-premises domain controllers and Azure. In one deployment, my team spent two weeks troubleshooting authentication failures before discovering that a firewall rule was blocking the necessary communication on port 88. This single finding reinforced why network validation should occur before pilot rollout, not during. Device registration and management come next. Every device attempting passwordless authentication must be either Azure AD joined, hybrid AD joined or registered with Entra ID. I’ve found that hybrid-joined devices work best in truly hybrid environments because they maintain connection to on-premises infrastructure while gaining cloud identity benefits. Your Intune Mobile Device Management deployment becomes critical here — devices must be compliant with your policies before they’re trusted for passwordless sign-in. This means ensuring that disk encryption is enabled, that antivirus is running and that devices meet your organization’s baseline security posture. The compliance baseline isn’t punitive; it’s the minimum acceptable security threshold. Conditional Access policies form the final leg of the prerequisite triangle. These aren’t optional — they’re how you enforce the “trust zero, verify always” principle of Zero Trust. The National Institute of Standards and Technology defines Zero Trust architecture as requiring continuous verification and explicit access grants based on all available data points. I configure policies that require device compliance, enforce multi-factor authentication for sensitive operations, and block legacy authentication entirely. The policy I typically recommend as a starting point requires hybrid-joined devices, compliant Intune status and MFA for all access to on-premises resources, while allowing seamless sign-in for fully compliant devices. This creates a virtuous cycle where security and user experience reinforce each other. Architecture decisions: Hybrid authentication flows and Windows Hello for Business Once your prerequisites are in place, you face critical architectural decisions that will shape your deployment for years to come. The primary decision point is whether to use Windows Hello for Business, FIDO2 security keys or phone sign-in as your primary authentication mechanism. In my experience, Windows Hello for Business is the foundation for hybrid environments. It leverages biometric or PIN authentication on the device itself, preventing credentials from ever being transmitted across the network. When a user signs in with Windows Hello, they’re not sending a password or even a credential — they’re using a private key stored in the device’s Trusted Platform Module (TPM) to prove their identity. For hybrid-joined devices, this works seamlessly because the device can authenticate both to your on-premises domain controller (using cloud Kerberos) and to Entra ID in a single operation. This eliminates the attack surface that traditional password-based authentication creates. Organizations seeking more information on passwordless authentication approaches can review guidance from the Cybersecurity and Infrastructure Security Agency, which has published extensive recommendations on moving beyond passwords. However — and this is crucial — not all devices have TPM 2.0, which is required for the most secure implementations. In one organization where we deployed to 15,000 devices, we discovered that 12% didn’t meet hardware requirements. We ended up implementing a phased approach: Windows Hello for Business on compliant devices, with FIDO2 security keys as the backup for devices that couldn’t support it. FIDO2 keys, which conform to the open FIDO2 standard, are also your answer for scenarios where you need physical authentication tokens — particularly useful for privileged accounts or high-risk scenarios. They’re resistant to phishing and account takeover because possession of the physical token is required. Research from the Identity Defined Security Alliance has shown that organizations using FIDO2-compliant authenticators reduce account compromise incidents by over 90% compared to password-dependent systems. The architectural decision also includes determining how you handle legacy applications that still require passwords. Your options are limited: implement a passwordless-compatible application gateway, deprecate the application entirely or use Entra ID’s smart lockout and password protection features to reduce risk while you transition. I typically recommend treating legacy application support as a temporary bridge, not a permanent architecture. Organizations that treat this as permanent inevitably find themselves maintaining password infrastructure indefinitely, undermining the entire security posture you’re building. Migration workflows: The step-by-step reality The migration itself needs to follow a structured approach that I’ve refined across multiple organizations. Start with a pilot group — I recommend between 50 and 200 users who are willing to accept some friction in exchange for security improvements. This group should include IT staff and security-conscious users who can provide meaningful feedback without becoming frustrated with early-stage issues. For the pilot phase, configure Windows Hello for Business using Group Policy on your on-premises infrastructure for domain-joined devices, while using Intune policies for cloud-managed devices. Configure Entra ID to require Windows Hello as the preferred authentication method. During this phase, maintain traditional password authentication as a fallback — not because you lack confidence, but because user trust in the system matters. I typically see a three to four week period where you’re supporting both methods while users adapt. This period provides invaluable data about real-world usage patterns and edge cases. The second phase involves expanding to department-level groups. At this point, you should have identified and documented all the troubleshooting patterns that emerged in your pilot. Common issues I’ve encountered include PIN complexity policies that conflict with Windows Hello configuration, credential caching issues on hybrid-joined devices and confusion around how to recover access when a device is lost or compromised. A well-designed help desk knowledge base at this stage prevents the third phase from becoming a support crisis. The final phase is organization-wide rollout with password authentication disabled. This is where you must have complete confidence in your fallback mechanisms and your support team’s ability to handle edge cases. I recommend maintaining password authentication for break-glass scenarios (though heavily restricted and logged) for at least 90 days after full rollout. This safety net provides psychological comfort to leadership and creates a genuine escape hatch if something unexpected occurs at scale. Troubleshooting patterns and lessons learned After guiding three large-scale deployments, I’ve compiled a list of issues that deserve attention before they become production problems rather than documented solutions. Device compliance checking often becomes a bottleneck. If your Intune policies are too strict, you’ll have users locked out of passwordless authentication because their devices are non-compliant. The solution isn’t to loosen policies — it’s to automate compliance remediation. Use Intune’s remediation scripts to automatically enable required features and update settings rather than blocking access. When a device becomes non-compliant due to a missing security update, remediation scripts can deploy that update silently, restoring access without support interaction. Cloud Kerberos ticket refresh failures occur when devices lose network connectivity. I’ve found that users appreciate understanding that brief network outages might require them to use an alternative authentication method temporarily. Documenting this expectation and providing clear error messages reduces support burden significantly. One organization I worked with created a simple status dashboard showing cloud connectivity health, which dramatically improved user confidence in the system. The Windows Hello PIN reset flow needs careful planning. Users will forget PINs — not because they’re careless, but because they now have one less password to remember and are redirecting that cognitive effort elsewhere. Implement Entra ID’s self-service PIN reset capability, but test it thoroughly in various network conditions. I discovered in one deployment that users couldn’t reset their PIN while offline, which created support tickets even though the feature was technically available online. A simple offline reset option would have eliminated those tickets. Recovery mechanisms deserve special attention. What happens when a user’s device is stolen? What if the TPM fails? What if they forget their PIN and can’t reach your self-service portal? Document these scenarios and test them with your help desk before full rollout. I’ve found that help desk confidence in recovery procedures directly correlates with user confidence in passwordless authentication. The endpoint: A genuinely passwordless enterprise Reaching true passwordless authentication in a hybrid environment means accepting that you’re building a new security model, not just changing how users authenticate. The effort required is substantial, but the security improvement is profound. I’ve watched organizations move from breach-heavy authentication scenarios to Zero Trust architectures where every access request is evaluated in context, and where the compromise of a single device doesn’t cascade into wholesale account takeover. The passwordless journey isn’t a destination you reach in months — it’s a direction you move in consistently. The organizations that succeed view passwordless migration not as a project with an end date, but as a fundamental shift in how they think about identity and trust. They maintain that momentum by continuously updating policies, expanding coverage to new applications and use cases, and refining their architecture as technology evolves. The view from the other side is worth the journey. Once you’ve lived in a passwordless environment, going back to password-based authentication feels like removing your seatbelt during a drive. The risk seems obvious in retrospect, and the safety you’ve gained becomes non-negotiable. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Eye Security’s 2026 State of Incident Response Report shows that cyberattacks on companies are increasingly going undetected, and the damage occurs within minutes. According to the report, attackers are now focusing less on hacking systems and more on exploiting existing access points. Identity-based attacks dominate the field, with passwords being involved in 97% of incidents tracked by Eye Security. Abuse of legitimate accounts is a primary cause of cloud security incidents and drives the business of initial access brokers. However, the study’s results show that attackers’ fundamental methods remain unchanged. “Even in 2026, compromise will still begin with phishing, exploiting misconfigured or vulnerable internet-enabled systems, social engineering, or attacks via the software supply chain,” explains Lodi Hensen, VP of security operations at Eye Security. BEC attacks are particularly common Business email compromise (BEC) is the most common form of attack, according to the study: More than 70% of incidents fall into this category. In 40% of these cases, phishing served as the initial point of entry. Analysts say that BEC attacks can remain undetected for weeks without continuous monitoring. Furthermore, the study highlights that ransomware remains one of the biggest threats. “The proliferation of Ransomware-as-a-Service (RaaS), BuilderLeaks, and access broker marketplaces has lowered the barriers to entry and created a professional ecosystem,” the authors explain. The report reveals a dangerous trend: the commercialization of insider knowledge. “Groups like ShinyHunters are actively recruiting employees to buy access credentials. This blurs the line between external attacks and insider threats,” the security researchers explain. “For ransomware actors, this purchased access is often faster and more reliable than technical hacking.” Companies in the industrial, construction, and transport and logistics sectors are particularly affected. Many ransomware attackers exploit everyday vulnerabilities: unprotected applications, insecure remote access, or phishing emails through which employees unknowingly disclose login credentials. The analysis evaluated a total of 630 security incidents in Europe from 2023 to 2025. View the full article

Even the most seasoned CISOs sometimes run into insurmountable roadblocks at their organizations. Despite their best efforts at building relationships, and even with their technical depth and business acumen, they can’t garner the support needed to protect their organizations — and themselves — from pending disaster. In the big picture, CISO roles are hard, and so the majority of CISOs switch jobs every two to three years or less. Lack of support from senior leadership and lack of budget commensurate with the organization’s size and industry are top reasons for this CISO churn, according to The life and times of cybersecurity professionals report from the ISSA. More specifically, CISOs leave on account of limited board engagement, high accountability with insufficient authority, executive misalignment, and ongoing barriers to implementing risk management and resilience, according to an ISSA spokesperson. Many of these roadblocks are common across industries, so how does a CISO know when it’s time to move on? They look for the flags. Red flag: Playing lip service A common red flag and reason CISO’s leave their jobs is because leadership is paying “lip service” to auditors, customers and competitors, says FinTech CISO Marius Poskus, a popular blogger on security leadership who posted an essay about resigning from “security‑theater roles.” So, even before signing onto a new job, Poskus suggests looking for recent events proceeding the organization hiring its first-ever CISO. “I see this often. Usually after an impactful breach, they negotiate fines down by saying they’ll hire their first CISO. In fact, a friend in New Zealand reached out to me today with just such a story,” he tells CSO. Other indicators that executives are playing lip service to security include constant resource denials, lack of risk ownership, and failure to sign off on identified risks at the top level, leaving the CISO vulnerable. To this end, Poskus shared a security executive charter that outlines responsibilities of senior executives’ accountability around the cybersecurity program. And, since lack of access to the board is a top-cited reason for leaving, Poskus says to look for problematic reporting lines that block access to executives, such as through a boss who refuses to report issues and requests to executives. Red flag: Cognitive disconnect Lack of access to executives and the board comes up repeatedly in Cybersecurity Ventures reports as a top reason CISO’s decide to leave their jobs, according to Steve Morgan, founder of Cybersecurity Ventures. He cites lack of support as another top reason CISO’s leave. Splunk’s 2025 CISO report found 29% of respondents had adequate budget compared to 41% of boards who felt cybersecurity budgets were adequate. This cognitive disconnect was clear in Nawab Kabir’s case. He declined on the prospect of taking a full-time CISO role to become a fractional CISO after a merger left him reporting to an IT director rather than the CEO as he previously had reported to. “One of the key red flags for CISO’s is if their boss, usually the CIO or CTO, repeatedly blocks attempts to escalate missions to the CEO by downplaying the real risk, asking the CISO to accept that risk, and saying that the CEO simply doesn’t care. So, the risk never gets mentioned in executive leadership meetings,” Kabir says. After the merger, the initiatives and intervention strategies he developed never got past the director of IT (who came from the merger) to executive leadership. So, Kabir knew it was time to leave. “That’s one of the reasons I became a fractional cybersecurity leader, which I love because now I’m being hired to make a difference at my client companies.” Red Flag: Pushing ethical boundaries Above all these, the biggest red flag is when leadership pushes against your professional and personal ethics. For example, when a CEO or board wants to conceal compliance gaps, cover up reportable breaches, and refuse to sign off on responsibility for gaps and reporting failures they’ve been made aware of. “This happens more often than we know because most CISOs won’t make public what happened behind the scenes that made them quit, especially when they’re looking for new jobs,” Poskus explains. “Your integrity is your most important asset, so that’s the biggest red flag when we talk about leaving a role rather than staying and fighting.” In these types of scenarios, the CISO likely lacks critical allies within the organization. Acknowledge this sense of vulnerability, Poskus advises, because it’s a huge red flag. Human resources and legal teams in these situations won’t help because they owe their loyalty to the business, he adds. Such was the case with former Uber CISO Joe Sullivan who was thrown under the bus by Uber’s shady leadership after a 2016 breach. In contrast, SolarWinds CISO Tim Brown felt fully supported after a historic supply chain hack in 2020 spread to 18,000 business clients through its Orion network management product patch update system. “Joe was in such a difficult situation. The company was aggressive towards him, which was so different from my experience at SolarWinds,” says Brown, who had responded to the breach. Green flag: They have your back In contrast to Sullivan’s employer, Brown shares that everyone involved in responding to the SolarWinds breach — from IT responders to communications, legal, and executives — felt the same way he did in terms of making things right for clients and regulators. “My situation was difficult, but manageable in many ways because of that support from my team. From day one, we had no question about doing the right thing. We decided on transparency to our customers all the way through the SEC filings,” Brown explains. Even as a new CEO came onboard under a planned transition shortly after the breach, and as the SEC charged SolarWinds and Brown with fraud for certifying compliance with SolarWinds security shortly before the sophisticated supply-chain hack occurred, Brown has felt ongoing support. Given his access to the board and CEO, Brown knew well before the breach that the company had his back. He also points to another green flag: The company’s commitment to tabletop exercises of impactful breaches. Throughout the practice scenarios, teams worked together under a customer-centric mandate that advocated transparency and education, the same playbook that they followed in the 2020 breach. Ultimately, the SEC dropped its charges against Brown, and in November, he attended a virtual toast in his honor to celebrate the SEC dropping the case against him “without prejudice.” More than 200 CISOs of top companies joined, including co-host Joe Sullivan. Ultimately, as Brown had hoped, the entire experience provided teachable moments to help push the CISO role up the maturity curve. Changing internal mindsets As CISOs burn out or leave under stressful circumstances, many turn to fractional work as Kabir has. And, in his case, working with new clients gives him plenty of opportunities to turn red flags into green flags. For example, he points to lack of board access and resources. In many cases he steps into, the former cybersecurity leaders didn’t understand the business and talked technically over their executives’ heads. As a result, he’s had to convert fatigued, resistant executive teams that don’t want to repeat those experiences with a new cybersecurity leader. For these clients, he likes to call “all hands” to a meeting and conduct what he calls interactive “business continuity stress tests” in table-top scenarios that impact a revenue-generating activity. “Take manufacturing, if this machine is down for six to eight hours what would be our revenue costs associated with this downtime? That gets attention,” Kabir says. “Then finance starts talking within their teams and it goes beyond that to the CEO because now it’s seen as a business issue.” CISOs, then, can change culture to turn a red flag into a green flag. But knowing when and how to do so depends on the indicators mentioned. Even with a fractional role, CISOs should still expect some of their clients to try and compromise ethics by covering up findings for example. Fortunately, that red flag usually reveals itself early in the audit, when the executives and business units appear afraid to answer questions as if trying to hide something. “A lot of red flags have to do with lack of security culture or mismatch in understanding the risk tolerance of the company and what the actual risks are. This red flag goes beyond: If they don’t want to be questioned about what they’ve done so far, that is a huge red flag that they’re covering something up,” Kabir explains. To be safe, he carries indemnity insurance and retains his own legal counsel — as should all CISO’s with large enough salaries who are reporting to the board and C-suite. Because, as in the case with Joe Sullivan and many other examples that go unreported, CISO’s can’t count on their organizations to have their backs legally or professionally should the big one hit — especially if those executives, by virtue of their unresponsiveness and lack of support, are the cause of it. View the full article

Chim | shutterstock.com Die Softwarelieferkette – respektive ihre Schwachstellen – haben in den vergangenen Jahren für viel Wirbel gesorgt. Ein besonders schlagzeilenträchtiges Beispiel ist der Angriff auf den IT-Dienstleister SolarWinds, bei dem mehr als 18.000 Kundenunternehmen betroffen waren. Zwar war die Attacke beileibe nicht die einzige auf Softwarelieferketten – sie führte jedoch zu einer Neubewertung der Frage, wer dafür verantwortlich zeichnet. Eine Reaktion auf den SolarWinds-Angriff war beispielsweise Ex-US-Präsident Bidens “Executive Order on Improving the Nation’s Cybersecurity“. Der Erlaß hob nicht nur hervor, wie bedeutsam die Absicherung der Lieferketten ist, sondern stellt auch ausdrücklich die Verantwortung der Entwickler heraus, wenn es darum geht, sichere Software zu liefern. Zwar gilt die Anordnung ausschließlich für US-Regierungsbehörden und deren Geschäftspartner. Sie steht jedoch stellvertretend dafür, dass alle beteiligten Organisationen ihre Softwareanbieter überprüfen müssen, um sicheren Code bereitzustellen – unabhängig davon, ob ein Unternehmen nur Programme und Anwendungen für sich selbst entwickelt oder Teil der Softwarelieferkette Dritter ist. Das größte Problem dabei: Softwareentwickler wurden viele Jahre lang nahezu ausschließlich danach beurteilt, wie schnell sie programmieren können. Security war dabei entweder ein nachgelagerter Gedanke oder der Verantwortungsbereich Anderer. Zwar bilden sich viele Entwickler inzwischen in Sachen Cybersecurity fort, sie brauchen jedoch Hilfe, um sicherzustellen, dass ihr Code frei von Sicherheitslücken ist. Dazu können Tools für Dynamic Application Security Testing (DAST) und Static Application Security Testing (SAST) einen wertvollen Beitrag leisten. DAST- & SAST-Tools – was ist das? Es ist nicht überraschend, dass sowohl SAST- als auch DAST-Tools in Zusammenhang mit der Absicherung von Softwarelieferketten wieder an Bedeutung gewinnen. Schließlich geben sie den Entwicklern die Werkzeuge an die Hand, um sicheren Code bereitzustellen – entweder als Teil eines offiziellen DevSecOps-Programms oder um die Verantwortung für die Security näher an den Ort der Anwendungsentwicklung zu verlagern. Sowohl SAST- als auch DAST-Tools haben das Ziel, den Code sicherer zu machen. Im Idealfall geschieht das lange bevor eine Anwendung in eine Produktionsumgebung gelangt und Teil der Softwarelieferkette wird. Dabei verfolgen die Tools dasselbe Ziel, gehen das Problem aber aus unterschiedlichen Blickwinkeln an: SAST-Tools analysieren den Quellcode von Programmen und Anwendungen, die sich noch in der Entwicklung befinden. Sie lassen sich in eine CI/CD-Pipeline integrieren oder so konfigurieren, dass sie automatisch aktiv werden, wenn ein Entwickler eine Pull-Anfrage stellt. So können Tools für Static Application Security Testing sicherstellen, dass mit neuen Änderungen an einer Anwendung nicht unbeabsichtigt Schwachstellen hinzugefügt werden oder anderweitige Fehler entstehen. Einige SAST-Tools können auch Teil integrierter Entwicklungsumgebungen (IDE) werden. In diesem Fall warnt die Plattform die Entwickler während der Programmierarbeit vor Fehlern – ähnlich wie eine moderne Textverarbeitung mit Rechtschreibprüfung. DAST-Tools werden im Gegensatz dazu eingesetzt, nachdem eine Applikation kompiliert ist. Ein Tool für Dynamic Application Security Testing ist weniger dazu gedacht, Schwachstellen im Code aufzudecken (die ein SAST Tool im Idealfall bereits beseitigt hat), sondern fungiert als externer Tester, der versucht, ein Programm beispielsweise über offene http- oder HTML-Schnittstellen zu hacken. Einige DAST-Tools können auch konfiguriert werden, um nach Schwachstellen für gängige Angriffe in bestimmten Branchen wie dem Finanzwesen oder dem Einzelhandel zu suchen. Wegen der genannten Unterschiede müssen SAST-Tools die von Ihnen gewählte Programmiersprache unterstützen. Das Gros der DAST-Tools erfordert das nicht, obwohl diese Tools unter Umständen auch mit Quellcode arbeiten können, um Probleme zu lokalisieren. Während einige Unternehmen entweder ausschließlich ein DAST- oder ein SAST-Tool verwenden, empfiehlt es sich, eine Kombination aus beiden einzusetzen oder mit einem Tool zu arbeiten, das beide Komponenten enthält. Unternehmen, die das tun, sind in der Lage, ihre Applikationen besser zu schützen, was der Sicherheit der Softwarelieferkette insgesamt zuträglich ist. Dynamic Application Security Testing Tools: Top 4 Im Folgenden finden Sie einige der wichtigsten DAST- und SAST-Tools, die heute zum Einsatz kommen. 1. Acunetix DAST Die Acunetix DAST-Plattform nutzt DAST und IAST (Interactive Application Security Testing), um nach über 7.000 Schwachstellen in fertigem Code, Website-Designs oder Anwendungen zu suchen. Bei IAST wird der Scan- und Testcode in ein kompiliertes Programm eingebettet, ähnlich wie bei Debug-Symbolen. Somit kann Acunetix seine Scans starten, während ein Programm aktiv ausgeführt wird. auf diese Weise werden potenziell mehr Schwachstellen aufgedeckt als bei der Untersuchung einer Anwendung im Ruhezustand. IAST sollte auch die Zahl der Fehlalarme (im Vergleich zu SAST) verringern. Der Code für die Plattform ist aus Speed-Gründen in C++ geschrieben. Dabei exportiert die Plattform bis zu 90 Prozent ihrer Ergebnisse bereits, während der Scan noch nicht einmal zur Hälfte abgeschlossen ist. Die Benutzer können die Acunetix-Plattform so konfigurieren, dass sie einmalig ausgeführt wird oder Zeitpläne für wiederholte Tests im Laufe der Zeit einrichten. Und weil die Plattform so schlank ist, kann sie sogar mehrere Umgebungen gleichzeitig scannen, ohne dabei an Geschwindigkeit einzubüßen. 2. Opentext Fortify WebInspect Die ehemalige Fortify-WebInspect-Plattform von Micro Focus firmiert nach der Übernahme des Unternehmens durch Opentext unter dem Namen Fortify WebInspect. Sie ist als On-Premises-Installation, als Service oder als Kombination aus beidem innerhalb einer hybriden Umgebung verfügbar. Obwohl es als isoliertes DAST-Tool arbeitet, lässt es sich in CI/CD-Pipelines integrieren und kann auch von Entwicklern genutzt werden, die normalerweise nur SAST-Tools verwenden. Das Tool kann auch nur nach besonders kritischen Schwachstellen suchen und die Entwickler so vor schwerwiegenden Fehlern warnen, damit diese schon lange vor Bereitstellung behoben werden. Darüber hinaus ist dieses DAST-Tool auch in der Lage zu prüfen, ob der Code im Einklang mit staatlichen Regularien steht (NIST 800-53, PCI DSS, OWASP, HIPAA, etc.). Wird eine Schwachstelle entdeckt, visualisiert die Plattform das Problem mit einer grafischen Oberfläche und unterbreitet iterative Lösungsvorschläge. 3. Black Duck (ehemals Synopsis) Die DAST-Plattform von Black Duck ist auch als Managed Service verfügbar. Dadurch entfällt nicht nur interne Wartung und Management – das Unternehmen steht bei Bedarf auch mit Rat und Tat zur Seite, beispielsweise wenn Scan ein Problem aufwirft, mit dem das Entwicklungsteam überfordert ist. Das Tool deckt nicht nur alle gängigen Schwachstellen auf, die viele Programme plagen (etwa SQL-Injection oder Cross-Site-Scripting), sondern verfügt auch über einen manuellen Scan-Modus, mit dem Sie auch komplexeren Problemen gezielt auf dioe Spur kommen. Auch Sicherheitslücken in Zusammenhang mit Authentifizierungs-, Zugriffskontroll- und Session-Management-Fehlern, die bei herkömmlichen Scans nicht auftauchen, findet das Tool. 4. Tenable.io Web App Scanning Tenable ist unter den Sicherheitsanbietern eine Art Urgestein und ist in erster Linie für seine robuste, Cloud-basierte Vulnerability-Management-Plattform bekannt. Web App Scanning ist ein Teil dieser Plattform und fungiert als leistungsfähiges DAST-Tool. Die Tenable-App arbeitet nur mit Webanwendungen, führt aber einen tiefgehenden Scan durch, der sowohl HTML5 als auch Standard-HTML und AJAX abdeckt. Die App verfügt über eine simple Benutzeroberfläche, die auch für Teams zugänglich ist, die ohne Application-Security-Spezialisten auskommen müssen. Automatisierungen sind einfach einzurichten und die Benutzer können genau konfigurieren, welche Abschnitte des Programmcodes gescannt werden sollen. Davon abgesehen lässt sich der Web App Scanner auch als Standalone-Lösung verwenden – oder in eine andere Cybersecurity-Lösung von Tenable integrieren. Static Application Security Testing Tools: Top 5 1. Checkmarx SAST Das SAST-Programm von Checkmarx kombiniert fortschrittliche Funktionen mit einer der besten webbasierten Benutzeroberflächen für SAST-Tools. Die Benutzeroberfläche ermöglicht es auch Security-Unkundigen, sich zurechtzufinden. Checkmarx identifiziert nicht nur Schwachstellen, sondern erklärt auch, warum eine entdeckte Schwachstelle besonders riskant ist. Zudem erhalten Entwickler Tipps, wie die gefundenen Probleme am einfachsten und effektivsten beseitigt werden können. Standardmäßig unterstützt das Checkmarx-Tool über 25 Programmiersprachen. Zudem lässt sich die Anwendung so konfigurieren, dass sie automatisch als Teil einer CI/CD-Pipeline ausgeführt wird. Natürlich dürfen Sie auch benutzerdefinierte Abfragen einrichten und nach Bedarf ausführen und das Tool in alle gängigen IDE- oder Quellcode-Management-Plattformen integrieren. 2. Opentext Fortify Static Code Analyzer Sowohl SAST- als auch DAST-Elemente kombiniert Fortify Static Code Analyzer von Opentext. Als SAST-Plattform verwendet die Lösung eine übersichtliche, visuelle Schnittstelle, um Entwicklern die spezifischen Schwachstellen im Code (und Statistiken über die Art der regelmäßig aufgedeckten Schwachstellen) aufzuzeigen, die in 810 verschiedene Schwachstellenkategorien unterteilt sind. Anschließend werden die Entwickler zu einer Schulungsoberfläche weitergeleitet, die laut Anbieter interessante und unterhaltsame Lektionen über Security und sicheren Code bereithalten soll. Die Plattform unterstützt 27 Programmiersprachen und Frameworks und kann On-Premises oder als Service eingesetzt werden. Zudem lässt sie sich in die meisten gängigen IDEs wie Eclipse und Visual Studio integrieren. 3. Perforce Klocwork SAST Das SAST-Tool Klocwork setzt den Fokus auf Geschwindigkeit – selbst in den größten Umgebungen. Es funktioniert mit Anwendungen, die in C, C++, Java, JavaScript und Python kodiert sind – sogar innerhalb von Docker-Containern – und kann in jede größere IDE wie Visual Studio Code, IntelliJ und viele andere integriert werden. Laut Anbieter wurde Klocwork entwickelt, um ein SAST-Tool für komplexe Umgebungen zu realisieren. Mit Klocwork können Anwender riesige Codebasen scannen, die Millionen von Zeilen beinhalten. Um die Scan-Dauer zu verkürzen, werden beispielsweise nur die geänderten Codebereiche gescannt und nicht jedes Mal das gesamte Programm. Darüber hinaus hilft das SAST-Tool dabei, Entwickler in Sachen Security zu schulen: Es ist vollständig in die Schulungsplattform Secure Code Warrior integriert, die sich auf Sicherheits- und Awareness-Schulungen konzentriert. 4. Spectral SpectralOps-Plattform Check Point hat vor kurzem Spectral übernommen, aber das neue Unternehmen unterstützt weiterhin aktiv die SpectralOps-Plattform, wahrscheinlich auch wegen ihrer einzigartigen SAST-Funktionen. SpectralOps findet sensible Informationen wie API-Schlüssel, Anmeldeinformationen und Token, die Entwickler bei der Entwicklung von Programmen oft fest einkodieren. Die Idee dahinter: Fehlkonfigurationen aufzudecken, die den Zugriff auf geheime Informationen ermöglichen könnten, während sich ein Programm noch in der Entwicklung befindet. SpectralOps scannt kontinuierlich jeden Schritt im Lebenszyklus der Softwareentwicklung und nutzt Künstliche Intelligenz, um über 2.000 Erkennungs-Engines im Auge zu behalten. Um Fehlalarme in Zaum zu halten, finden auch nachgelagerte Tests statt. Im Anschluss kann das Tool seine Ergebnisse an Slack melden, ein Jira-Ticket ausstellen oder Entwickler über fast jede beliebige Kommunikationsplattform alarmieren. 5. Veracode Static Analysis SAST Die SAST-Plattform von Veracode ist ein Cloud Service – die komplexe Wartung einer SAST-Anwendung in Ihrer Umgebung entfällt damit. Sicherheitsanbieter Veracode arbeitet nach dem Prinzip des Just-in-Time-Learnings. Das bedeutet, anfälliger Code kann bereits bei der Programmierarbeit erkannt werden. Ist der Code korrigiert, erstellt die Veracode-Plattform ein Reporting, so dass Unternehmen sicherheitsbewusste Entwickler fördern und ermutigen können. Neben der Integration in eine IDE liegt der Schwerpunkt von Veracode auf Geschwindigkeit: Jeder Build eines Programms oder einer Anwendung kann automatisch gescannt werden, wobei die durchschnittliche Scan-Zeit bei lediglich 90 Sekunden liegt. Dabei wird durchgängig jede Aktion erfasst, was wiederum Audits erleichtert. 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

vectorfusionart – shutterstock.com Zwar stellen Cyberkriminelle und staatlich unterstützte Angreifer gerade für den Industriesektor eine enorme und steigende Gefahr dar. Dennoch besteht die größte Bedrohung derzeit im mangelnden Wissenstransfer, was OT-Sicherheit und -Organisation (Operational Technology) angeht. Das Hauptproblem sind vertrauenswürdige Mitarbeiter, die in Rente gehen. Diese Personen sind in der Regel engagiert, sachkundig und unersetzlich. Sie wissen, auf welchem unbeschrifteten Server das System zur Erfassung historischer Daten läuft, das die Aufsichtsbehörden verlangen. Sie erinnern sich daran, warum ein bestimmtes VLAN mit scheinbar zufälligen IP-Adressen konfiguriert wurde. Sie wissen, welche Netzwerkrouten nur unter Produktionsstillstand geändert werden können. Ihr institutionelles Wissen umfasst somit Tausende von IP-Adressen, undokumentierte Netzwerkrouten und versteckte VLANs, die in der offiziellen Dokumentation fehlen. Ihre Nachfolger hingegen bringen Erwartungen an moderne, gut dokumentierte Netzwerkarchitekturen mit. Stattdessen erben sie ein komplexes Geflecht aus Altsystemen, proprietären Protokollen und undokumentierten Konfigurationen, die das Ergebnis jahrzehntelanger schrittweiser Änderungen und Notfallkorrekturen sind. Die Diskrepanz zwischen Erwartungen und Realität führt zu einer Wissenslücke, die sowohl die Betriebskontinuität als auch die Cybersicherheit gefährdet. Hierbei handelt es sich jedoch um eine Art „Single Point of Failure“, den die meisten Unternehmen erst erkennen, wenn es bereits zu spät ist. Der Weggang erfahrener OT-Fachkräfte birgt drei kritische Risiken, die weit über einfache Personalprobleme hinausgehen und bei herkömmlichen Risikobewertungen meist unterschätzt werden: 1. Systemausfälle während der Modernisierung Das unmittelbare und schwerwiegendste Risiko besteht in unbeabsichtigten Folgen während System-Upgrades oder Modernisierungsmaßnahmen. Ältere OT-Netzwerke enthalten das, was Branchenexperten als „archäologische Schichten“ bezeichnen: Jahrzehntelange inkrementelle Modifikationen, Notfallkorrekturen und undokumentierte Konfigurationen, die versteckte Abhängigkeiten schaffen. Die größten Risiken: Nicht dokumentierte Altsysteme: Die meisten Produktionsstätten verfügen über mindestens ein Windows-NT- oder Windows-XP-System, auf dem unverzichtbare historische Daten gespeichert sind oder zentrale Prozesse gesteuert werden. Diese Systeme sind oft nicht hinreichend dokumentiert. Ihre Entfernung im Zuge von Modernisierungsmaßnahmen kann zum Verlust der Produktionsdaten von Jahrzehnten führen, die für die Einhaltung gesetzlicher Vorgaben erforderlich sind. Versteckte Netzwerkabhängigkeiten: IP-Routing-Tabellen, VLAN-Konfigurationen und Firewall-Regeln enthalten oft scheinbar willkürliche Einstellungen, die jedoch tatsächlich Netzwerkkonflikte verhindern oder die Kommunikation kritischer Systeme aufrechterhalten. Eine Änderung dieser Konfigurationen ohne institutionelles Wissen kann zu einem Dominoeffekt über mehrere Produktionslinien hinweg führen. Anforderungen an proprietäre Protokolle: Viele ältere Industriesysteme kommunizieren über proprietäre oder modifizierte Standardprotokolle. Die spezifischen Konfigurationsparameter, die diese Kommunikation ermöglichen, sind selten dokumentiert und existieren nur im institutionellen Wissen ausscheidender Mitarbeiter. Lesetipp: CISOs müssen OT-Risiken stärker adressieren 2. Verlängerte Time-to-Value für neue Geräte und Prozesse Der Verlust von spezifischem Know-how verlängert die Implementierungszeiten für neue Geräte, Prozessverbesserungen und Systemintegrationen erheblich. Dieser Effekt verstärkt sich mit der Zeit und führt zu Wettbewerbsnachteilen und verpassten Optimierungsmöglichkeiten. Herausforderungen bei der Implementierung: Komplexe Netzwerkintegration: Die Installation neuer Geräte, die früher nur wenige Tage dauerte, nimmt nun Wochen oder Monate in Anspruch. Der Grund: Die neuen Mitarbeitenden müssen die bestehenden Netzwerkkonfigurationen zunächst zurückentwickeln, um die Kompatibilität sicherzustellen. Ineffiziente Fehlerbehebung: Wenn Integrationsprobleme auftreten, müssen unerfahrene Mitarbeitende häufig Trial-and-Error-Ansätze anwenden, anstatt auf historische Kenntnisse ähnlicher Probleme und deren Lösungen zurückgreifen zu können. Abhängigkeit von Anbietern: Unternehmen sind zunehmend auf externe Systemintegratoren und Gerätehersteller angewiesen, um ihre eigenen Netzwerke zu verwalten. Das erhöht die Projektkosten und -laufzeiten erheblich. 3. Unbeabsichtigte Cybersicherheitslücken Ein verstecktes Risiko liegt in gut gemeinten Verbesserungen der Cybersicherheit, die tatsächlich die Angriffsfläche vergrößern. Das neue Personal, das in modernen IT-Sicherheitspraktiken geschult ist, implementiert häufig Lösungen, die für OT-Umgebungen ungeeignet sind oder unbeabsichtigt zuvor isolierte Systeme offenlegen. Häufige Muster für die Schaffung von Schwachstellen: Fehlerhafte Netzwerksegmentierung: Versuche, eine moderne Trennung in Netzwerksegmente zu implementieren, verbinden versehentlich zuvor isolierte Netzwerkteile miteinander. So entstehen neue Angriffspfade, die in der alten Konfiguration nicht existierten. Fehlkonfigurationen von Firewalls: Durch mangelnde Kenntnisse von Legacy-Protokollen können moderne Firewall-Implementierungen legitime industrielle Kommunikationen blockieren und gleichzeitig unbefugte Zugriffe nicht verhindern. Diese drei Hauptrisiken verstärken sich gegenseitig, wenn sie gleichzeitig auftreten. Dies ist immer häufiger der Fall, da Unternehmen versuchen, veraltete Infrastrukturen zu modernisieren und gleichzeitig den Wandel in der Belegschaft zu bewältigen. (jm) Lesetipp: KI schafft neue Sicherheitsrisiken für OT-Netzwerke View the full article

vectorfusionart – shutterstock.com Zwar stellen Cyberkriminelle und staatlich unterstützte Angreifer gerade für den Industriesektor eine enorme und steigende Gefahr dar. Dennoch besteht die größte Bedrohung derzeit im mangelnden Wissenstransfer, was OT-Sicherheit und -Organisation (Operational Technology) angeht. Das Hauptproblem sind vertrauenswürdige Mitarbeiter, die in Rente gehen. Diese Personen sind in der Regel engagiert, sachkundig und unersetzlich. Sie wissen, auf welchem unbeschrifteten Server das System zur Erfassung historischer Daten läuft, das die Aufsichtsbehörden verlangen. Sie erinnern sich daran, warum ein bestimmtes VLAN mit scheinbar zufälligen IP-Adressen konfiguriert wurde. Sie wissen, welche Netzwerkrouten nur unter Produktionsstillstand geändert werden können. Ihr institutionelles Wissen umfasst somit Tausende von IP-Adressen, undokumentierte Netzwerkrouten und versteckte VLANs, die in der offiziellen Dokumentation fehlen. Ihre Nachfolger hingegen bringen Erwartungen an moderne, gut dokumentierte Netzwerkarchitekturen mit. Stattdessen erben sie ein komplexes Geflecht aus Altsystemen, proprietären Protokollen und undokumentierten Konfigurationen, die das Ergebnis jahrzehntelanger schrittweiser Änderungen und Notfallkorrekturen sind. Die Diskrepanz zwischen Erwartungen und Realität führt zu einer Wissenslücke, die sowohl die Betriebskontinuität als auch die Cybersicherheit gefährdet. Hierbei handelt es sich jedoch um eine Art „Single Point of Failure“, den die meisten Unternehmen erst erkennen, wenn es bereits zu spät ist. Der Weggang erfahrener OT-Fachkräfte birgt drei kritische Risiken, die weit über einfache Personalprobleme hinausgehen und bei herkömmlichen Risikobewertungen meist unterschätzt werden: 1. Systemausfälle während der Modernisierung Das unmittelbare und schwerwiegendste Risiko besteht in unbeabsichtigten Folgen während System-Upgrades oder Modernisierungsmaßnahmen. Ältere OT-Netzwerke enthalten das, was Branchenexperten als „archäologische Schichten“ bezeichnen: Jahrzehntelange inkrementelle Modifikationen, Notfallkorrekturen und undokumentierte Konfigurationen, die versteckte Abhängigkeiten schaffen. Die größten Risiken: Nicht dokumentierte Altsysteme: Die meisten Produktionsstätten verfügen über mindestens ein Windows-NT- oder Windows-XP-System, auf dem unverzichtbare historische Daten gespeichert sind oder zentrale Prozesse gesteuert werden. Diese Systeme sind oft nicht hinreichend dokumentiert. Ihre Entfernung im Zuge von Modernisierungsmaßnahmen kann zum Verlust der Produktionsdaten von Jahrzehnten führen, die für die Einhaltung gesetzlicher Vorgaben erforderlich sind. Versteckte Netzwerkabhängigkeiten: IP-Routing-Tabellen, VLAN-Konfigurationen und Firewall-Regeln enthalten oft scheinbar willkürliche Einstellungen, die jedoch tatsächlich Netzwerkkonflikte verhindern oder die Kommunikation kritischer Systeme aufrechterhalten. Eine Änderung dieser Konfigurationen ohne institutionelles Wissen kann zu einem Dominoeffekt über mehrere Produktionslinien hinweg führen. Anforderungen an proprietäre Protokolle: Viele ältere Industriesysteme kommunizieren über proprietäre oder modifizierte Standardprotokolle. Die spezifischen Konfigurationsparameter, die diese Kommunikation ermöglichen, sind selten dokumentiert und existieren nur im institutionellen Wissen ausscheidender Mitarbeiter. Lesetipp: CISOs müssen OT-Risiken stärker adressieren 2. Verlängerte Time-to-Value für neue Geräte und Prozesse Der Verlust von spezifischem Know-how verlängert die Implementierungszeiten für neue Geräte, Prozessverbesserungen und Systemintegrationen erheblich. Dieser Effekt verstärkt sich mit der Zeit und führt zu Wettbewerbsnachteilen und verpassten Optimierungsmöglichkeiten. Herausforderungen bei der Implementierung: Komplexe Netzwerkintegration: Die Installation neuer Geräte, die früher nur wenige Tage dauerte, nimmt nun Wochen oder Monate in Anspruch. Der Grund: Die neuen Mitarbeitenden müssen die bestehenden Netzwerkkonfigurationen zunächst zurückentwickeln, um die Kompatibilität sicherzustellen. Ineffiziente Fehlerbehebung: Wenn Integrationsprobleme auftreten, müssen unerfahrene Mitarbeitende häufig Trial-and-Error-Ansätze anwenden, anstatt auf historische Kenntnisse ähnlicher Probleme und deren Lösungen zurückgreifen zu können. Abhängigkeit von Anbietern: Unternehmen sind zunehmend auf externe Systemintegratoren und Gerätehersteller angewiesen, um ihre eigenen Netzwerke zu verwalten. Das erhöht die Projektkosten und -laufzeiten erheblich. 3. Unbeabsichtigte Cybersicherheitslücken Ein verstecktes Risiko liegt in gut gemeinten Verbesserungen der Cybersicherheit, die tatsächlich die Angriffsfläche vergrößern. Das neue Personal, das in modernen IT-Sicherheitspraktiken geschult ist, implementiert häufig Lösungen, die für OT-Umgebungen ungeeignet sind oder unbeabsichtigt zuvor isolierte Systeme offenlegen. Häufige Muster für die Schaffung von Schwachstellen: Fehlerhafte Netzwerksegmentierung: Versuche, eine moderne Trennung in Netzwerksegmente zu implementieren, verbinden versehentlich zuvor isolierte Netzwerkteile miteinander. So entstehen neue Angriffspfade, die in der alten Konfiguration nicht existierten. Fehlkonfigurationen von Firewalls: Durch mangelnde Kenntnisse von Legacy-Protokollen können moderne Firewall-Implementierungen legitime industrielle Kommunikationen blockieren und gleichzeitig unbefugte Zugriffe nicht verhindern. Diese drei Hauptrisiken verstärken sich gegenseitig, wenn sie gleichzeitig auftreten. Dies ist immer häufiger der Fall, da Unternehmen versuchen, veraltete Infrastrukturen zu modernisieren und gleichzeitig den Wandel in der Belegschaft zu bewältigen. (jm) Lesetipp: KI schafft neue Sicherheitsrisiken für OT-Netzwerke View the full article

Threat actors tore through an Amazon Web Services environment in under eight minutes, chaining together credential theft, privilege escalation, lateral movement, and GPU resource abuse with the help of large language models, an attack so fast that defenders had virtually no time to react. According to new findings from Sysdig’s Threat Research Team, the intruders turned a single exposed credential in a public S3 bucket into full administrative control, demonstrating how AI‑assisted automation has collapsed the cloud attack lifecycle from hours to mere minutes. The operation, observed in November 2025, reportedly combined a cloud misconfiguration with large language models (LLMs) to compress the entire attack lifecycle. “The cybersecurity world today is brand new,” said Ram Varadarajan, CEO at Acalvio. “In this threat environment, organizations have to accept that the speed of the breach has shifted from days to minutes. Autonomous intruders can now escalate from initial access to full administrative control in minutes.” Defending against this class of attacks, he added, demands “AI-focused technology” that can reason and respond at the same speed as automated attackers.” Public Buckets to privilege escalation in minutes The compromise began with valid AWS credentials left exposed in public S3 buckets. Those buckets contained AI-related data, and the associated IAM user had permissions to interact with Lambda and limited access to Amazon Bedrock. “This user was likely intentionally created by the victim organization to automate Bedrock tasks with Lambda functions across the environment,” Sysdig researchers said in a blog post shared with CSO ahead of its publication on Tuesday. With read access across the environment, the attacker rapidly enumerated AWS services, then escalated privileges by modifying an existing Lambda function. By injecting malicious code into a function that already had an overly permissive execution role, the attacker was able to create new access keys for an administrative user and retrieve them directly from the Lambda execution output. Jason Soroko, senior fellow at Sectigo, said the root cause was depressingly familiar. “We must look past the novelty of AI assistance to recognize the mundane error that enabled it,” he said. “The entire compromise began because the victim left valid credentials exposed in public S3 buckets. This failure represents a stubborn refusal to master security fundamentals.” The Lambda code showed signs of LLM generation, including comprehensive exception handling, iterative targeting logic, and even non-English comments. Lateral movement, LLMjacking, and GPU abuse Once administrative access was obtained, the attacker moved laterally across 19 distinct AWS principals, assuming multiple roles and creating new users to spread activity across identities. This approach enabled persistence and complicated detection, the researchers noted. The attackers then shifted focus to Amazon Bedrock, enumerating available models and confirming that model invocation logging was disabled. The researchers said multiple foundation models were invoked, a pattern consistent with “LLMjacking”. Then, the operation escalated into resource abuse. After preparing keys and security groups, the attackers attempted to initiate high-end GPU instances for machine learning workloads. While most powerful instances failed due to capacity limits, a costly GPU instance was eventually launched, with scripts to install CUDA, deploy training frameworks, and expose a public JupyterLab interface. Some of the code was found referencing nonexistent repositories and resources, which Sysdig researchers attributed to LLM hallucinations. Experts argue that the most unsettling takeaway isn’t that AI introduced a new attack technique. It is that AI removed hesitation.“When you strip this attack down to its essentials, what stands out isn’t a breakthrough technique,” said Shane Barney, CISO at Keeper Security. “It’s how little resistance the environment offered once the attacker obtained legitimate access.” He warned that AI collapses reconnaissance, privilege testing, and lateral movement into “a single, rapid sequence,” eliminating the buffer time defenders have historically relied on. To reduce exposure, Sysdig researchers advised enforcing least privilege across IAM users, roles, and Lambda execution roles, tightly limiting permissions such as “UpdateFunctionCode” and “PassRole”, and ensuring sensitive S3 buckets are never public. Enabling Lambda versioning, turning on Amazon Bedrock model invocation logging, and monitoring for large-scale enumeration activity are also critical, they added. View the full article

Threat actors tore through an Amazon Web Services environment in under eight minutes, chaining together credential theft, privilege escalation, lateral movement, and GPU resource abuse with the help of large language models, an attack so fast that defenders had virtually no time to react. According to new findings from Sysdig’s Threat Research Team, the intruders turned a single exposed credential in a public S3 bucket into full administrative control, demonstrating how AI‑assisted automation has collapsed the cloud attack lifecycle from hours to mere minutes. The operation, observed in November 2025, reportedly combined a cloud misconfiguration with large language models (LLMs) to compress the entire attack lifecycle. “The cybersecurity world today is brand new,” said Ram Varadarajan, CEO at Acalvio. “In this threat environment, organizations have to accept that the speed of the breach has shifted from days to minutes. Autonomous intruders can now escalate from initial access to full administrative control in minutes.” Defending against this class of attacks, he added, demands “AI-focused technology” that can reason and respond at the same speed as automated attackers.” Public Buckets to privilege escalation in minutes The compromise began with valid AWS credentials left exposed in public S3 buckets. Those buckets contained AI-related data, and the associated IAM user had permissions to interact with Lambda and limited access to Amazon Bedrock. “This user was likely intentionally created by the victim organization to automate Bedrock tasks with Lambda functions across the environment,” Sysdig researchers said in a blog post shared with CSO ahead of its publication on Tuesday. With read access across the environment, the attacker rapidly enumerated AWS services, then escalated privileges by modifying an existing Lambda function. By injecting malicious code into a function that already had an overly permissive execution role, the attacker was able to create new access keys for an administrative user and retrieve them directly from the Lambda execution output. Jason Soroko, senior fellow at Sectigo, said the root cause was depressingly familiar. “We must look past the novelty of AI assistance to recognize the mundane error that enabled it,” he said. “The entire compromise began because the victim left valid credentials exposed in public S3 buckets. This failure represents a stubborn refusal to master security fundamentals.” The Lambda code showed signs of LLM generation, including comprehensive exception handling, iterative targeting logic, and even non-English comments. According to an AWS spokesperson, AWS services and infrastructure are not affected by this issue, and they operated as designed throughout the incident described. “The report describes an account compromised through misconfigured S3 buckets. We recommend all customers secure their cloud resources by following security, identity, and compliance best practices, including never opening up public access to S3 buckets or any storage service, least-privilege access, secure credential management, and enabling monitoring services like GuardDuty, to reduce risks of unauthorized activity. AWS customers who suspect or become aware of malicious activity within their AWS accounts should follow guidance for remediating potentially compromised AWS credentials or contact AWS Support for assistance.” Lateral movement, LLMjacking, and GPU abuse Once administrative access was obtained, the attacker moved laterally across 19 distinct AWS principals, assuming multiple roles and creating new users to spread activity across identities. This approach enabled persistence and complicated detection, the researchers noted. The attackers then shifted focus to Amazon Bedrock, enumerating available models and confirming that model invocation logging was disabled. The researchers said multiple foundation models were invoked, a pattern consistent with “LLMjacking”. Then, the operation escalated into resource abuse. After preparing keys and security groups, the attackers attempted to initiate high-end GPU instances for machine learning workloads. While most powerful instances failed due to capacity limits, a costly GPU instance was eventually launched, with scripts to install CUDA, deploy training frameworks, and expose a public JupyterLab interface. Some of the code was found referencing nonexistent repositories and resources, which Sysdig researchers attributed to LLM hallucinations. Experts argue that the most unsettling takeaway isn’t that AI introduced a new attack technique. It is that AI removed hesitation.“When you strip this attack down to its essentials, what stands out isn’t a breakthrough technique,” said Shane Barney, CISO at Keeper Security. “It’s how little resistance the environment offered once the attacker obtained legitimate access.” He warned that AI collapses reconnaissance, privilege testing, and lateral movement into “a single, rapid sequence,” eliminating the buffer time defenders have historically relied on. To reduce exposure, Sysdig researchers advised enforcing least privilege across IAM users, roles, and Lambda execution roles, tightly limiting permissions such as “UpdateFunctionCode” and “PassRole”, and ensuring sensitive S3 buckets are never public. Enabling Lambda versioning, turning on Amazon Bedrock model invocation logging, and monitoring for large-scale enumeration activity are also critical, they added. View the full article

The popular open-source text editor Notepad++ was targeted in a sophisticated supply chain attack that allowed Chinese state-sponsored hackers to deliver malware through compromised software updates, the project’s maintainer disclosed in a blog post. The attack, which ran from June through December 2025, involved infrastructure-level compromise of Notepad++’s shared hosting provider that enabled threat actors to selectively intercept and redirect update traffic to servers under their control, Notepad++ author Don Ho said in the statement. “Multiple independent security researchers have assessed that the threat actor is likely a Chinese state-sponsored group, which would explain the highly selective targeting observed during the campaign,” Ho wrote. The incident highlights a critical blind spot in enterprise security. Attackers prize distribution points like update servers because one successful insertion delivers access to thousands of environments at once, according to a Forrester analysis also published Sunday. The compromise is particularly concerning because Notepad++ is widely used by developers, analysts, and IT operators, yet “does not require an enterprise contract or license, and does not include usage tracking by default and therefore may not be tracked in an enterprise software inventory,” Forrester analysts Jeff Pollard, Allie Mellen, Jess Burn, Janet Worthington, and Tope Olufon wrote in their blog post. How the attack unfolded The compromise occurred at the hosting provider level rather than through vulnerabilities in Notepad++ code, Ho said in the note. Attackers gained access to the shared hosting server and redirected traffic from the update endpoint to attacker-controlled servers. “The bad actors specifically searched for the Notepad++ domain to intercept the traffic to your website, as they might know the then-existing Notepad++ vulnerabilities related to insufficient update verification controls,” the hosting provider said in a statement shared by Ho. The name of the hosting provider, however, is not disclosed in the blog post. A detailed query seeking comments from Ho remains unanswered. The server was initially compromised until September 2, 2025, when scheduled maintenance included kernel and firmware updates. However, attackers maintained stolen credentials to internal services until December 2, 2025, allowing continued traffic interception, according to the provider’s statement. The targeting was highly selective — traffic from certain users was redirected while most legitimate updates proceeded normally, Ho said. Rapid7 identifies custom malware Cybersecurity firm Rapid7 also published a detailed technical analysis corroborating Ho’s disclosure and identifying the attack as part of a broader campaign deploying previously undocumented malware. Rapid7’s investigation uncovered a custom backdoor the firm dubbed “Chrysalis,” alongside Cobalt Strike and Metasploit frameworks. “Forensic analysis conducted by the MDR team suggests that the initial access vector aligns with publicly disclosed abuse of the Notepad++ distribution infrastructure,” Rapid7 researcher Ivan Feigl wrote. The Chrysalis backdoor supports 16 distinct command capabilities ranging from interactive shell access to complete self-removal. One loader variant exploited Microsoft Warbird, an internal code protection framework, to execute shellcode while masquerading as a legitimate Microsoft-signed binary. Rapid7 attributed the campaign to Lotus Blossom, also known as Billbug, a Chinese APT group active since 2009, known for espionage operations targeting government, telecommunications, and critical infrastructure sectors across Southeast Asia and Central America. The attribution is based on strong similarities to previously published Symantec research, particularly the use of a renamed Bitdefender executable to side-load malicious DLLs. Why detection proved difficult The sophisticated malware evaded detection for months largely because a compromised utility blends into normal developer behavior, making it challenging to identify. “Most EDR programs are blind by design to ‘expected’ developer behavior,” the Forrester analysts wrote. “A compromised utility does not need exploits, LOLBins, or exotic malware. It just needs to look boring—like something a dev would do.” Ho noted that his incident response team was unable to extract concrete indicators of compromise despite analyzing roughly 400 GB of server logs. In an edit posted Sunday, Ho acknowledged Rapid7’s more detailed findings. “Last evening I received an email from Ivan Feigl (Rapid7) to share their excellent investigation story—it seems to be the same story, and obviously, they have more tangible information (including IoCs) than I do,” he wrote. Rapid7 identified network infrastructure, including IP addresses in Malaysia and China, along with command and control URLs, including api.skycloudcenter.com and api.wiresguard.com. Security enhancements and broader implications In response, Notepad++ has migrated to a new hosting provider and enhanced WinGup (the updater component) in version 8.8.9 to verify both certificate and signature of downloaded installers, Ho said. Certificate and signature verification will be enforced starting with version 8.9.2, expected within approximately one month. “I deeply apologize to all users affected by this hijacking,” Ho wrote. “I recommend downloading v8.9.1 and running the installer to update your Notepad++ manually.” For enterprise security teams, the incident underscores the need for comprehensive software inventories that include widely used utilities, cryptographic verification of all updates, and what Forrester described as a “shift from implicit trust to continuous verification.” The Forrester analysts also warned that AI agents could amplify similar risks. “The same supply chain blind spots that let a compromised tool blend into developer noise will let a compromised agent establish persistence and elevate privileges at scale,” they wrote. Organizations that cannot strictly define what should execute and communicate are “structurally conceding this class of attack.” View the full article

Early experimentation with agentic AI has given CISOs a preview of the possible cybersecurity nightmares ahead. But with autonomous agent adoption expected to soar throughout 2026, CISOs’ lack of visibility into agentic identities, activities, and decision-making is set to get far worse in quick measure. Agentic use will vary by enterprise, but analysts, consultants, and security vendors agree that their numbers will expand far beyond CISOs’ ability to maintain control as they simultaneously navigate the price of decades of identity governance neglect for non-human identities (NHIs), including service accounts, OAuth tokens, embedded API keys, and automation credentials. Ishraq Khan, CEO of coding productivity tool vendor Kodezi, sees most enterprises today housing 8 to 10 million such identities, a figure he projects will hit 20 to 50 million by year’s end. Jason Sabin, CTO at DigiCert, predicts an even steeper rise, with enterprises’ identity role calls increasing 10 times by January 2027. “We need to rethink how identity and data provisioning is done and put in place the right processes that can scale with the growth of agentic identities,” says Justin Greis, CEO of consulting firm Acceligence and former head of the North American cybersecurity practice at McKinsey. “You simply cannot apply human processes to something that will scale at this rate.” Visibility is the bigger problem As bad as that massively expanding identity universe is, the bigger problem may be how little visibility CISOs have into NHIs, with AI agents offering not just the fastest growth but the least visibility. Jason Andersen, principal analyst for Moor Insights & Strategy, estimates 25% NHI visibility for enterprise CISOs today. “The remaining 75% is in the shadows,” he adds. Those shadows include “semi-shadow” activities, such as third parties or lines of business that have been given permission to experiment with agentic AI but have not necessarily alerted IT or security teams about what they are doing. Still, Andersen sees that number getting a lot worse, projecting visibility to drop to about 12% by year-end and then into the single digits by January 2028. “And then they’ll likely fix it,” he says, adding, “It’s a big frickin’ problem.” Gartner analysts Jeremy D’Hoinne and Akif Khan agree CISOs face urgent problems in this area today. NHIs are going to be “several orders of magnitude larger than human identities and most organizations do not have a strong enough foundation to manage both machine and agentic identities,” Gartner’s Khan says. Enterprise CISOs are “blind to what is happening. The numbers are going to be overwhelming,” D’Hoinne adds. Forrester expects similar outcomes for CISOs. “There is going to be an explosion of non-human identities,” says Forrester analyst Geoff Cairns. “The exponential growth is indisputable.” Kodezi’s Khan notes that the lack of a robust base for NHI governance — now including agentic AI — is a critical problem. “Enterprises never solved non-human authentication so we don’t have the systems in place for a good secure environment. At its core, we never had the right foundation. That means that we will never have that perfect inventory,” he explains. Cost effective fix: Do nothing Kodezi’s Khan offers an interesting fix for that foundational problem: Don’t even try. He argues it’s a money pit that will never be fully resolved. Instead, he suggests pouring resources into creating a strict identity strategy for every NHI going forward. “Aim for containment rather than for perfection. You can’t really govern every identity, but if you start now, you can govern future actions,” he says, adding that, over the years, the percentage of uncontrolled identities will slowly drop as millions more identities are added. Nik Kale, principal engineer at Cisco and member of the Coalition for Secure AI (CoSAI) and ACM’s AI Security (AISec) program committee, agrees with that assessment. “If you are drowning, you don’t start by draining the ocean.” “The ratios tell you why this is so ungovernable. These identities are growing much faster than the discovery capabilities,” Kale notes. “It becomes a math problem at that point.” As for the path forward, Kale advises not to try to fix the legacy situation. “You just have to contain it, segment it, assume it’s compromised and that it’s hostile territory,” he says. “The plan needs to be containment plus a clean slate going forward. Inventory all non-human identities. Identify which have standing versus just-in-time access. Assign ownership to every one of them. No product required — just a terrifying spreadsheet.” Kale adds that cleaning IDs from now on will deliver a better benefit to CISOs. “In my opinion, the ratio matters less than the governance gap. Whether it’s 200:1 or 500:1, if IAM [identity access management] only manages 44% of them, the attack surface is already unmanageable,” he says. But he stresses that NHIs — especially when agentic — can be particularly difficult to find, let alone control. “Most organizations are undercounting by two to three times because machine identities are scattered across cloud consoles, repos, config files, and secrets managers that nobody’s aggregating,” Kale says. “Agentic AI is a multiplier, not an addition. Agents spawn subagents, create credentials dynamically, and establish agent-to-agent auth chains. One agent deployment can generate dozens of new machine identities.” Sanchit Vir Gogia, chief analyst at Greyhound Research, sees a reckoning ahead. “The enterprise control plane has quietly shifted from humans to machines, while governance stayed behind,” he says. “Once nonhuman identities outnumber humans by hundreds to one, identity stops being an administrative discipline and becomes the operating system of trust. The failure mode is not that there are too many identities; it is that enterprises cannot assert intent, ownership, and accountability for what those identities are doing at runtime.” Moreover, the situation is intensifying thanks to today’s business environment. “This is compounded by incentive structures that reward speed and uptime while penalizing breakage, which leads teams to overpermission machines by default,” Gogia says. “Overpermission is invisible until it is catastrophic. At that point, audits, roles, and reviews offer comfort but not control.” Agentic didn’t start the fire None of this situation was caused by agentic AI, Gogia underscores. “Enterprises did not enter a machine identity crisis because of agentic AI. They entered it years ago through service accounts, embedded API keys, long lived tokens, and automation credentials that were created to keep systems moving and then quietly forgotten,” he says. “What agents change is velocity and reach. They inherit trust and then operationalize it at machine speed. A legacy identity that once represented a contained risk now becomes an execution layer across systems, vendors, and workflows.” Gogia adds: “The most dangerous assumption in enterprise security today is that valid identity implies safe behavior. In machine-driven environments, credentials are often correct and activity is authorized, yet outcomes are harmful. Machines do not follow joiner-mover-lever models. They do not pause for approvals. They operate continuously and propagate actions automatically.” As a result, decision-making agents, layered into operations, achieve a rate of action that “collapses the window for detection,” he says. “The failure shifts from prevention to detection lag. By the time humans understand what happened, the agent already did it.” This should — and likely will — cause a rethinking from both enterprise CISOs and CIOs, he says. “This moment tests leadership alignment. CIOs are under pressure to deploy agents for productivity and scale. CISOs are staring at accountability gaps, forensic complexity, and cascading blast radius. If these agendas diverge, the enterprise ends up with autonomy without responsibility. Boards will ask who owns an agent, who sets its boundaries, and who answers when it causes harm,” Gogia explains. “The next phase of governance will require responsibility mapping for agents, separation of duties for high impact actions, and clear human checkpoints where judgment truly matters,” he adds. “Incident response must also evolve toward reconstructing chains of machine decisions, not just tracing logins.” View the full article

Today’s applications are based on numerous components, each of which, along with the development environments themselves, represents an attack surface. Regardless of whether companies develop code in-house or rely on third-party vendors, CISOs, security experts, and developers should pay particular attention to the software supply chain. These risks include, for example, React2Shell, Shai-Hulud, and XZ Utils — all vulnerabilities in the software supply chain that started small and later had massive repercussions. Shai-Hulud stands out in particular, signaling the end of the “passive era” of supply chain attacks and the beginning of the “active worm” era. This shift promises devastating consequences for software pipelines. Traditionally, supply chain attacks were passive traps. An attacker would upload a misspelled package (typosquatting), such as “reqeusts” instead of “requests,” sit back, and wait for a complacent developer to make a mistake. The blast radius was linear and rather slow. Shai-Hulud changed the rules of the game by introducing a worm-like propagation method. Once it lands on a developer’s machine, it actively collects credentials (NPM tokens, GitHub secrets). It uses these stolen credentials to automatically publish infected versions of other legitimate packages managed by the victim. Unlike spyware, which aims to remain hidden, variants of Shai-Hulud include a “dead man switch.” If it detects that it is being blocked or analyzed, it attempts to wipe the victim’s system, completely erasing all traces of itself. The goal is no longer just the application, but the developer’s identity and the automated CI/CD pipelines that implicitly trust them. What if the next iteration of Shai-Hulud affected other coding languages? Programming languages ​​as ticking time bombs One example of this is Python, the language of AI and data science. The next evolutionary stage of the supply chain worm will likely not only steal AWS keys but also leverage the rise of AI coding assistants. Security researchers are already observing “hallucination hijacking,” in which attackers register packets whose existence AI tools falsely predict. A worm like Shai-Hulud could infect a data scientist’s laptop, scan their local LLM chat history for private packet names, and automatically register malicious versions publicly. A worm in this ecosystem would not only crash a website but could also subtly poison financial models, alter medical research data, or insert backdoors into corporate AI training sets — damage that could potentially go undetected for years. Other examples could involve the coding languages ​​Java/JVM or Rust/Go; here too, the effects would be catastrophic. The polyglot supply chain attack The most frightening prospect, however, is the convergence of these threats in a polyglot supply chain attack. Currently, security teams operate in isolation. AppSec monitors the code, CloudSec monitors the cloud, NetworkSec monitors the perimeter. A polyglot attack is designed to seamlessly break through these silos. This happens as follows: A worm infiltrates a frontend developer’s laptop via a low-level JavaScript dependency. It detects that the developer also has access to the company’s backend Rust repository, steals these credentials, and injects malicious build scripts into the Rust CI pipeline. The Rust pipeline then deploys a compromised binary to a Kubernetes cluster. The attack could begin in NPM but end as a compiled binary backdoor in the production cloud infrastructure. The JavaScript security team won’t detect it because it immediately left their domain. The cloud security team would also miss the threat because it was delivered from a trusted CI pipeline using valid credentials. CISOs need to be aware of this and take appropriate precautions Recommendations for CISOs The EU Cyber ​​Resilience Act (CRA) provides recommendations for CISOs. It mandates the protection of digital products for manufacturers, importers, and distributors, encouraging them to invest in secure design during development and maintenance. The requirements outlined therein must be implemented gradually by the end of 2027, and include the security of networked hardware and software through the handling of vulnerabilities and their publication or notification to the relevant authorities. Furthermore, the three aforementioned stakeholders must also document the components of the software in software bills of materials (SBOMs). The NIS2 Directive, which has now entered into force, contains similar requirements for operators of critical infrastructure (KRITIS) to those stipulated in the NIS2 Implementation Act (NIS2UmsuCG) and the KRITIS Umbrella Act regarding products and suppliers. OpenKRITIS provides a worthwhile overview. To protect themselves from Shai-Hulud and similar threats, CISOs and their teams should implement the following steps: You must end the “implicit trust” in identities. In the scenarios described earlier involving Shai-Hulud, the problem was that CI/CD systems were too often blindly trusted. Therefore, CISOs should ensure their teams critically examine their pipeline security. CI/CD systems must not automatically assume an activity is legitimate simply because it was signed with a valid developer token. Instead, they must prioritize identity protection. Attackers have already been observed specifically stealing credentials such as NPM tokens and GitHub secrets to automatically publish infected packages. Measures to protect these identities must therefore be given top priority. Security silos should be broken down. Many security aspects still aren’t consolidated under a single, overarching management structure. Tools and departments dedicated to application security, infrastructure security, cloud security, network security, and many others create numerous islands within the vast sea of ​​security strategy. They all need to collaborate more closely and be coordinated by the CISO. A key risk is the previously described polyglot supply chain attack, which seamlessly transcends these silos. Therefore, CISOs must implement cross-departmental and cross-functional monitoring. To further illustrate the danger: An attack could begin with a JavaScript file, propagate through build scripts, and ultimately result in a backdoor in the cloud. Often, there’s no integrated visibility to track this entire process. The JavaScript team might lose sight of the attack once it leaves its sphere, while the cloud team relies on the CI pipeline. CISOs must therefore establish systems that monitor the entire path from software development to build and all the way to runtime. SBOMs, which document all software used, provide a solution. Prepare for active worms and ensure the protection of AI tools. To mitigate AI-driven risks, it’s crucial to prevent the hijacking and manipulation of AI tools. Numerous software developers rely on these tools to write their software. Security researchers are already observing attackers using packets that cause AI tools to hallucinate. Active worms represent the next level of threat. Therefore, security strategies should extend beyond simply protecting against typos. Threats like Shai-Hulud spread exponentially, like a worm. At this speed, manual packet inspection processes are no longer sufficient. This type of supply chain worm also features a “dead man switch” that wipes the victim’s system if an analysis is detected. CISOs should ensure that logs are secured even outside the developer’s machine to preserve traces of the attack for forensic investigations. View the full article

intersoft consulting services AG Montagmorgen, 8:00 Uhr. Die Mitarbeitenden können sich nicht einloggen. Die Produktionsbänder stehen still, und auf den Bildschirmen prangen digitale Erpresserschreiben. Der Albtraum eines jeden CIOs ist wahr geworden: Ein Ransomware-Angriff hat den Betrieb lahmgelegt. Jetzt endet der Regelbetrieb, und der Ausnahmezustand beginnt. Für Joanna Lang-Recht, Director IT Forensics und Prokuristin bei der intersoft consulting services AG in Hamburg, ist dies der Alltag. Sie leitet eine hochspezialisierte Eingreiftruppe, die den Tathergang rekonstruiert und den Schaden eindämmt, während die anderen tief im Chaos versinken. „Man kann sich das tatsächlich ähnlich vorstellen wie in der kriminalistischen Forensik“, erklärt Lang-Recht. Doch die Realität habe dann doch wenig mit grellen Taschenlampen in dunklen Räumen zu tun, auch wenn die Parallelen in der Vorgehensweise zu erkennen seien. „Wir sammeln keine Schmauchspuren oder Fußabdrücke, wie konzentrieren uns auf Spuren im digitalen Raum“, so die Forensikerin. Wenn Cyberkriminelle zuschlagen, hinterlassen sie trotz aller Verschleierungstaktiken digitale Fragmente. Das können Logfiles sein, veränderte Zeitstempel oder Fragmente im Arbeitsspeicher. All das sind Puzzleteile, aus denen Lang-Recht und ihr Team das Bild des Angriffs zusammensetzen. Ihr Motto: Rekonstruieren statt Spekulieren. Doch bevor die detektivische Arbeit beginnen kann, müssen Unternehmen erst einmal aus der Schockstarre herausfinden. Zwischen Panik und Paralyse Ransomware-Angriffe folgen meist einem perfiden Timing. Beispielsweise wissen die Täter genau, wann IT-Abteilungen besonders verwundbar sind. „Häufig finden solche Angriffe über das Wochenende oder an Feiertagen statt“, berichtet die Expertin aus Hamburg in dem Podcast TechTalk Smart Leadership von COMPUTERWOCHE und CIO-Magazin. Die „Encryption-Phase“, in der die Daten des Opfers verschlüsselt werden, laufe dann von Freitag- bis Sonntagabend durch. Wenn die Belegschaft am Montag ins Büro kommt, sei das Unheil bereits geschehen. Die erste Reaktion in den betroffenen Unternehmen beschreibt Lang-Recht als einen Zustand absoluter Panik. „Wir reden hier von einem wirklichen Ausnahmezustand“, betont sie. Keine E-Mails, kein Zugriff auf Kundendaten, keine Produktion. In diesem ersten „Stadium der Akzeptanz“, wie Lang-Recht es nennt, würden oft die größten Fehler gemacht, die eine spätere Aufklärung massiv erschweren könnten. Der menschliche Impuls sei verständlich: Man möchte retten, was zu retten ist. Doch die Forensikerin warnt eindringlich vor Aktionismus. „Wir sehen häufig, dass IT-Teams gleich versuchen, zu bereinigen oder Backups einzuspielen, bevor sie überhaupt wissen, was passiert ist.“ Warum der Stecker nicht gezogen werden darf Lang-Recht empfiehlt, die Systeme vom Internet zu trennen, aber nicht auszuschalten. Das Herunterfahren eines Servers könne einen „forensischen Suizid“ bedeuten. „Das vernichtet wertvolle Hinweise“, erklärt sie. Viele Angreifer hinterlassen demnach Spuren im RAM-Speicher. Wird der Strom gekappt, sind diese Informationen unwiederbringlich verloren. Die Daten sind aber essenziell, um zu verstehen, wie die Hacker sich im Netzwerk bewegt haben (Lateral Movement) und ob sie noch aktiv sind. Die korrekte Vorgehensweise, so die Expertin, sei die Isolierung. „Die Verbindungen zu Dienstleistern, Kunden und Lieferanten sollten gekappt werden, um die Supply Chain nicht zu gefährden.“ Erst wenn die Infrastruktur in sich gesichert sei, beginne die eigentliche Arbeit der Forensik. Und diese erfordere oft das Auffahren schwerer Geschütze. Die Dimension von Cyberangriffe sprenge nämlich nicht selten die verfügbaren Speicherkapazitäten vor Ort. Um forensische Images – exakte 1:1-Kopien der Datenträger – zu erstellen, müssen laut Lang-Recht riesige Datenmengen gesichert und analysiert werden. Sind aber hunderte Server und tausende Clients zu untersuchen, werden die Verantwortlichen an physikalische Grenzen stoßen. Wer steckt hinter den Angriffen? Das Bild vom einsamen Hacker im Hoodie, der zwischen Pizzaschachteln im Keller hockt, ist laut Joanna Lang-Recht unrealistisch. „Wir haben es mit hochprofessionellen Tätergruppen zu tun“, stellt sie klar. Die Cyberkriminalität hat sich industrialisiert. Das Geschäftsmodell „Ransomware-as-a-Service“ (RaaS) dominiert den Markt. Die Gruppierungen seien wie mittelständische Betriebe aufgestellt. Sie verfügten oft sogar über Personalabteilungen, die Entwickler anwerben, und über Marketingabteilungen, die den Brand der Hackergruppe pflegten. Nicht selten hätten sie sogar einen mehrsprachigen Kundensupport installiert. „Wenn man in die Verhandlung geht, hat man es tatsächlich teilweise mit einem First-Level- und einem Second-Level-Support zu tun“, sagt Lang-Recht. Es gebe Preislisten, Rabattaktionen und Ticket-Systeme. Diese Professionalisierung mache die Angriffe effizient und besonders gefährlich, biete aber auch Ansatzpunkte für Verhandlungen. Für die Angreifer gehe es um ein Geschäft und nicht etwa um eine persönliche Vendetta. Das einzige Ziel ist der Profit. Doch genau hier entsteht oft ein moralisches Dilemma für die betroffenen Unternehmen: Zahlen oder nicht zahlen? Das Dilemma der Lösegeldzahlung Während Behörden wie das BSI empfehlen, grundsätzlich nicht zu zahlen, ist die Realität in den Vorstandsetagen eine andere: Wenn die Existenz des Unternehmens auf dem Spiel steht, wird die Moral zur Nebensache. „Es ist am Ende eine rein wirtschaftliche Entscheidung“, sagt sie nüchtern. Geschäftsführern rät sie dringend davon ab, selbst in den Chat mit den Erpressern zu gehen. Hier seien Emotionen absolut fehl am Platz. Besser sei es, auf spezialisierte Unterhändler zu setzen. Ziel müsse sein, zunächst Zeit zu gewinnen, die Forderung zu drücken und herauszufinden, ob die Täter überhaupt in der Lage sind, die Daten wiederherzustellen. Besonders ärgerlich aus Sicht des angegriffenen Unternehmens ist die sogenannte Double Extortion. Dabei verschlüsseln die Täter nicht nur die Daten, sondern sie drohen auch mit deren Veröffentlichung. Wenn sich also das Opfer weigert zu zahlen, erhöhen die Kriminellen den Druck und kündigen die Veröffentlichung sensibler Kundendaten oder Konstruktionspläne an. Die Hausaufgaben für den C-Level „Die Haupteinfallstore sind schwache Passwörter, die per Brute-Force geknackt werden, ungesicherte Fernwartungszugänge (VPN/RDP) und klassisches Phishing“, resümiert Lang-Recht. Versäumnisse in der „IT-Hygiene“ öffneten den Tätern Tür und Tor. Dazu zählen insbesondere veraltete Systeme, unzureichendes Patch-Management und eine fehlende Netzwerksegmentierung. Wenn ein Angreifer einmal im Netz ist, sollte er sich nicht ungehindert bewegen können. In vielen Unternehmen seien die Netzwerke aber „flach“, so die Forensikerin, wer drin sei, komme überall hin. „Wenn ein Angreifer in einen Teilbereich eindringt, darf er nicht die gesamte Infrastruktur verschlüsseln können“, fordert Lang-Recht. Die Segmentierung des Netzwerks sei die wirksamste Maßnahme, um den Schaden zu begrenzen. Der Faktor Mensch und Organisation Technik ist aber nur die eine Seite der Medaille. Die Expertin betont, wie wichtig es sei, auf den Notfall vorbereitet zu sein. Ein Unternehmen muss wissen, an wen es sich im Notfall wendet. Verträge, die garantieren, dass bei einem Angriff ein Expertenteam bereitstehen, sind für sie unverzichtbar. Zudem müssten Verantwortlichkeiten klar geregelt sein. In der Krise sei keine Zeit für Kompetenzgerangel. Wer entscheidet, ob der Internet-Zugang gekappt wird? Wer kommuniziert mit Kunden, Lieferanten und gegebenenfalls der Presse? Wer informiert den Datenschutzbeauftragten? „Es gibt in der Regel immer eine Person, die kommunikativ die Führung übernimmt“, beobachtet Lang-Recht. Diese Rolle müsse nicht nur definiert, sondern auch trainiert sein – durch Krisenstabsübungen und Notfallsimulationen. Ein Wettrüsten mit KI Der Blick in die Glaskugel zeigt keine Entspannung. Das Katz-und-Maus-Spiel zwischen Angreifern und Verteidigern geht nicht nur weiter, es wird durch den Einsatz von künstlicher Intelligenz auf ein höheres Niveau gehoben. Angreifer nutzen KI, um bessere Phishing-Mails zu schreiben und um Schwachstellen schneller zu finden. Verteidiger nutzen sie, um Anomalien im Netzwerkverkehr in Echtzeit zu erkennen. Lang-Recht bleibt trotz der bedrohlichen Lage Optimistin. Hundertprozentige Sicherheit gibt es nicht, aber man könne es den Angreifern schwer machen. Sie empfiehlt: Investieren Sie in saubere Backups (offline!), Netzwerksegmentierung und Mitarbeiterschulung, und haben Sie einen Plan für den Tag X. (mb) width="100%" height="152" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy" src="https://open.spotify.com/embed/episode/76glj1FbyI6DYwhk4Z8Nw8?utm_source=oembed"> View the full article

intersoft consulting services AG Montagmorgen, 8:00 Uhr. Die Mitarbeitenden können sich nicht einloggen. Die Produktionsbänder stehen still, und auf den Bildschirmen prangen digitale Erpresserschreiben. Der Albtraum eines jeden CIOs ist wahr geworden: Ein Ransomware-Angriff hat den Betrieb lahmgelegt. Jetzt endet der Regelbetrieb, und der Ausnahmezustand beginnt. Für Joanna Lang-Recht, Director IT Forensics und Prokuristin bei der intersoft consulting services AG in Hamburg, ist dies der Alltag. Sie leitet eine hochspezialisierte Eingreiftruppe, die den Tathergang rekonstruiert und den Schaden eindämmt, während die anderen tief im Chaos versinken. „Man kann sich das tatsächlich ähnlich vorstellen wie in der kriminalistischen Forensik“, erklärt Lang-Recht. Doch die Realität habe dann doch wenig mit grellen Taschenlampen in dunklen Räumen zu tun, auch wenn die Parallelen in der Vorgehensweise zu erkennen seien. „Wir sammeln keine Schmauchspuren oder Fußabdrücke, wie konzentrieren uns auf Spuren im digitalen Raum“, so die Forensikerin. Wenn Cyberkriminelle zuschlagen, hinterlassen sie trotz aller Verschleierungstaktiken digitale Fragmente. Das können Logfiles sein, veränderte Zeitstempel oder Fragmente im Arbeitsspeicher. All das sind Puzzleteile, aus denen Lang-Recht und ihr Team das Bild des Angriffs zusammensetzen. Ihr Motto: Rekonstruieren statt Spekulieren. Doch bevor die detektivische Arbeit beginnen kann, müssen Unternehmen erst einmal aus der Schockstarre herausfinden. Zwischen Panik und Paralyse Ransomware-Angriffe folgen meist einem perfiden Timing. Beispielsweise wissen die Täter genau, wann IT-Abteilungen besonders verwundbar sind. „Häufig finden solche Angriffe über das Wochenende oder an Feiertagen statt“, berichtet die Expertin aus Hamburg in dem Podcast TechTalk Smart Leadership von COMPUTERWOCHE und CIO-Magazin. Die „Encryption-Phase“, in der die Daten des Opfers verschlüsselt werden, laufe dann von Freitag- bis Sonntagabend durch. Wenn die Belegschaft am Montag ins Büro kommt, sei das Unheil bereits geschehen. Die erste Reaktion in den betroffenen Unternehmen beschreibt Lang-Recht als einen Zustand absoluter Panik. „Wir reden hier von einem wirklichen Ausnahmezustand“, betont sie. Keine E-Mails, kein Zugriff auf Kundendaten, keine Produktion. In diesem ersten „Stadium der Akzeptanz“, wie Lang-Recht es nennt, würden oft die größten Fehler gemacht, die eine spätere Aufklärung massiv erschweren könnten. Der menschliche Impuls sei verständlich: Man möchte retten, was zu retten ist. Doch die Forensikerin warnt eindringlich vor Aktionismus. „Wir sehen häufig, dass IT-Teams gleich versuchen, zu bereinigen oder Backups einzuspielen, bevor sie überhaupt wissen, was passiert ist.“ Warum der Stecker nicht gezogen werden darf Lang-Recht empfiehlt, die Systeme vom Internet zu trennen, aber nicht auszuschalten. Das Herunterfahren eines Servers könne einen „forensischen Suizid“ bedeuten. „Das vernichtet wertvolle Hinweise“, erklärt sie. Viele Angreifer hinterlassen demnach Spuren im RAM-Speicher. Wird der Strom gekappt, sind diese Informationen unwiederbringlich verloren. Die Daten sind aber essenziell, um zu verstehen, wie die Hacker sich im Netzwerk bewegt haben (Lateral Movement) und ob sie noch aktiv sind. Die korrekte Vorgehensweise, so die Expertin, sei die Isolierung. „Die Verbindungen zu Dienstleistern, Kunden und Lieferanten sollten gekappt werden, um die Supply Chain nicht zu gefährden.“ Erst wenn die Infrastruktur in sich gesichert sei, beginne die eigentliche Arbeit der Forensik. Und diese erfordere oft das Auffahren schwerer Geschütze. Die Dimension von Cyberangriffe sprenge nämlich nicht selten die verfügbaren Speicherkapazitäten vor Ort. Um forensische Images – exakte 1:1-Kopien der Datenträger – zu erstellen, müssen laut Lang-Recht riesige Datenmengen gesichert und analysiert werden. Sind aber hunderte Server und tausende Clients zu untersuchen, werden die Verantwortlichen an physikalische Grenzen stoßen. Wer steckt hinter den Angriffen? Das Bild vom einsamen Hacker im Hoodie, der zwischen Pizzaschachteln im Keller hockt, ist laut Joanna Lang-Recht unrealistisch. „Wir haben es mit hochprofessionellen Tätergruppen zu tun“, stellt sie klar. Die Cyberkriminalität hat sich industrialisiert. Das Geschäftsmodell „Ransomware-as-a-Service“ (RaaS) dominiert den Markt. Die Gruppierungen seien wie mittelständische Betriebe aufgestellt. Sie verfügten oft sogar über Personalabteilungen, die Entwickler anwerben, und über Marketingabteilungen, die den Brand der Hackergruppe pflegten. Nicht selten hätten sie sogar einen mehrsprachigen Kundensupport installiert. „Wenn man in die Verhandlung geht, hat man es tatsächlich teilweise mit einem First-Level- und einem Second-Level-Support zu tun“, sagt Lang-Recht. Es gebe Preislisten, Rabattaktionen und Ticket-Systeme. Diese Professionalisierung mache die Angriffe effizient und besonders gefährlich, biete aber auch Ansatzpunkte für Verhandlungen. Für die Angreifer gehe es um ein Geschäft und nicht etwa um eine persönliche Vendetta. Das einzige Ziel ist der Profit. Doch genau hier entsteht oft ein moralisches Dilemma für die betroffenen Unternehmen: Zahlen oder nicht zahlen? Das Dilemma der Lösegeldzahlung Während Behörden wie das BSI empfehlen, grundsätzlich nicht zu zahlen, ist die Realität in den Vorstandsetagen eine andere: Wenn die Existenz des Unternehmens auf dem Spiel steht, wird die Moral zur Nebensache. „Es ist am Ende eine rein wirtschaftliche Entscheidung“, sagt sie nüchtern. Geschäftsführern rät sie dringend davon ab, selbst in den Chat mit den Erpressern zu gehen. Hier seien Emotionen absolut fehl am Platz. Besser sei es, auf spezialisierte Unterhändler zu setzen. Ziel müsse sein, zunächst Zeit zu gewinnen, die Forderung zu drücken und herauszufinden, ob die Täter überhaupt in der Lage sind, die Daten wiederherzustellen. Besonders ärgerlich aus Sicht des angegriffenen Unternehmens ist die sogenannte Double Extortion. Dabei verschlüsseln die Täter nicht nur die Daten, sondern sie drohen auch mit deren Veröffentlichung. Wenn sich also das Opfer weigert zu zahlen, erhöhen die Kriminellen den Druck und kündigen die Veröffentlichung sensibler Kundendaten oder Konstruktionspläne an. Die Hausaufgaben für den C-Level „Die Haupteinfallstore sind schwache Passwörter, die per Brute-Force geknackt werden, ungesicherte Fernwartungszugänge (VPN/RDP) und klassisches Phishing“, resümiert Lang-Recht. Versäumnisse in der „IT-Hygiene“ öffneten den Tätern Tür und Tor. Dazu zählen insbesondere veraltete Systeme, unzureichendes Patch-Management und eine fehlende Netzwerksegmentierung. Wenn ein Angreifer einmal im Netz ist, sollte er sich nicht ungehindert bewegen können. In vielen Unternehmen seien die Netzwerke aber „flach“, so die Forensikerin, wer drin sei, komme überall hin. „Wenn ein Angreifer in einen Teilbereich eindringt, darf er nicht die gesamte Infrastruktur verschlüsseln können“, fordert Lang-Recht. Die Segmentierung des Netzwerks sei die wirksamste Maßnahme, um den Schaden zu begrenzen. Der Faktor Mensch und Organisation Technik ist aber nur die eine Seite der Medaille. Die Expertin betont, wie wichtig es sei, auf den Notfall vorbereitet zu sein. Ein Unternehmen muss wissen, an wen es sich im Notfall wendet. Verträge, die garantieren, dass bei einem Angriff ein Expertenteam bereitstehen, sind für sie unverzichtbar. Zudem müssten Verantwortlichkeiten klar geregelt sein. In der Krise sei keine Zeit für Kompetenzgerangel. Wer entscheidet, ob der Internet-Zugang gekappt wird? Wer kommuniziert mit Kunden, Lieferanten und gegebenenfalls der Presse? Wer informiert den Datenschutzbeauftragten? „Es gibt in der Regel immer eine Person, die kommunikativ die Führung übernimmt“, beobachtet Lang-Recht. Diese Rolle müsse nicht nur definiert, sondern auch trainiert sein – durch Krisenstabsübungen und Notfallsimulationen. Ein Wettrüsten mit KI Der Blick in die Glaskugel zeigt keine Entspannung. Das Katz-und-Maus-Spiel zwischen Angreifern und Verteidigern geht nicht nur weiter, es wird durch den Einsatz von künstlicher Intelligenz auf ein höheres Niveau gehoben. Angreifer nutzen KI, um bessere Phishing-Mails zu schreiben und um Schwachstellen schneller zu finden. Verteidiger nutzen sie, um Anomalien im Netzwerkverkehr in Echtzeit zu erkennen. Lang-Recht bleibt trotz der bedrohlichen Lage Optimistin. Hundertprozentige Sicherheit gibt es nicht, aber man könne es den Angreifern schwer machen. Sie empfiehlt: Investieren Sie in saubere Backups (offline!), Netzwerksegmentierung und Mitarbeiterschulung, und haben Sie einen Plan für den Tag X. (mb) width="100%" height="152" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy" src="https://open.spotify.com/embed/episode/76glj1FbyI6DYwhk4Z8Nw8?utm_source=oembed"> View the full article

Even as they become ever more stealthy with AI-driven tools, threat actors are not giving up on simple, tried-and-true phishing — because it still works. According to new research, attackers are still making mischief with PDFs, the old business standby, and are exploiting growing trust in services like Dropbox. Forcepoint’s X-Labs team has uncovered a multi-stage phishing campaign that exploits PDF files and Dropbox storage through a layered redirection attack. After clicking on what looks like a legitimate PDF, victims are rerouted to a Dropbox logon impersonation page designed to harvest their credentials for internal access, account takeover, or other fraud. “This is a perfect example of why phishing is still the number one way for criminals to get at organizations,” said David Shipley of Beauceron Security. “This attack works because it mimics normal business behavior.” Anatomy of a multi-layered PDF attack In this campaign, victims first receive a professional-sounding email that seems to be part of a normal procurement or tender process and asks them to review an attached document. The type of wording is “commonly used in tender or procurement fraud, where urgency and legitimacy are deliberately created to encourage quick action,” wrote Forcepoint researcher Prashant Kumar. The PDF serves as the primary malware delivery mechanism. Unbeknownst to the victim, the sender address is spoofed or associated with a compromised account. Once they click on the attachment, they are directed to a second PDF hosted on a trusted cloud service (public.blob[.]vercel-storage[.]com), which further redirects them to a fake Dropbox login page. If they take the bait, they’ll log in with their email address and password, and those credentials will be exfiltrated to attacker-controlled command and control (C2) infrastructure. “The first [document] passed the email filter because it’s perfectly legitimate and links to a trusted service,” said Beauceron’s Shipley. “There’s no way to stop that without lots of negative business consequences.” The second one works because it’s not the trusted cloud service’s job to vet content hosted in it. These types of email also often pass standard authentication checks such as sender policy framework (SPF), DomainKeys Identified Mail (DKIM), and domain-based message authentication, reporting, and conformance (DKIM). “The minimal and business-like content helps avoid keyword-based detection, making the message look and feel more like a routine operational request,” Kumar wrote. Thus, attackers are able to convince victims that they need to authenticate to view the documents. This phishing campaign is interesting in that it’s multi-faceted and has been “very well thought out,” noted Erik Avakian, technical counselor at Info-Tech Research Group. And it’s effective because “nothing looks obviously wrong to the end user at any single stage. The original email is clean and gets by most filters, the first PDF opens normally and seems to be hosted on a legitimate cloud service, and the Dropbox login page looks real. “Each step, by itself, passes the sniff test,” he said. “The danger only becomes obvious when you zoom out and look at the entire chain, and most users don’t think about chains. They think in clicks.” Masquerading as a safe document format But after so many warnings about this over time — why are people still so trusting of PDFs and Dropbox? “Because, historically, they’ve actually been trained to be,” said Avakian. PDFs are routinely used in the business world and have been positioned as a safe, read-only document format for invoices, contracts, HR forms, and statements. This applies to Dropbox, too; it’s become a mainstream business tool that employees have been encouraged to use, and has been positioned so that its services “are not some sketchy file-sharing site anymore.” “When people see a PDF or a Dropbox logo, their guard naturally drops,” said Avakian. Familiarity and the need for speed prevent them from pausing and taking a closer look. Attackers know this, and “exploit it perfectly.” On top of this, Avakian pointed out, cloud infrastructure has become a “shield” for attackers. Security awareness has conditioned users to be wary of shady domains, but not of reputable platforms. It’s a mental model that’s outdated, and “attackers are way ahead of it.” ‘Don’t click links’ is not enough Hackers know that many employees tend to touch payment processes and documents, noted Lionel Menchaca, content marketing and technical writing specialist at Forcepoint, so they must be trained to verify that invoices, purchase orders (POs), and contracts are coming from confirmed vendors, affiliates, and agencies. “If they cannot verify, they should report suspicious emails to IT or security teams,” he said. But the precautions don’t stop there, Shipley noted. Employees must develop good e-mail processing habits, such as by taking frequent breaks; simulations can help, as they allow people to break out of routine. Many email clicks (he estimates about 40%) occur when people are on autopilot and aren’t processing at the deep thinking level, “they’re just acting on instinct.” Avakian agreed that email security awareness training must evolve beyond “don’t click links.” Employers and leaders at all levels must understand that modern phishing is increasingly “multi-stage, cloud-hosted, brand-impersonating, and intentionally boring-looking.” PDFs are no longer “safe by default,” and cloud services are no longer “trusted by default.” “This type of incident becomes a great example, and [an] opportunity to build more sophisticated phishing testing,” said Avakian. “The goal is not to embarrass users, but to build security minded habits as to how attacks unfold today.” While the basics still matter, they need to be framed honestly, he said. Hover over links, but understand that cloud-hosted URLs can still be malicious; check the sender’s “from” address and domain, but recognize that compromised or look-alike domains exist; be cautious of unexpected attachments, even PDFs, especially when they lead you somewhere else; treat any login prompts as a moment to pause, “especially when they’re triggered indirectly,” Avakian advised. “Security awareness has to grow up, just like the threats did,” he said. Still, clicks will happen, and effective multi-layered controls limit the damage. Multi-factor authentication (MFA), conditional access, and anomaly detection are critical, and a zero-trust mindset embeds security into a culture where the “trust by default” mindset goes away, said Avakian. “At the end of the day, PDFs and Dropbox aren’t the problem; unquestioned trust is,” he said. View the full article

Even as they become ever more stealthy with AI-driven tools, threat actors are not giving up on simple, tried-and-true phishing — because it still works. According to new research, attackers are still making mischief with PDFs, the old business standby, and are exploiting growing trust in services like Dropbox. Forcepoint’s X-Labs team has uncovered a multi-stage phishing campaign that exploits PDF files and Dropbox storage through a layered redirection attack. After clicking on what looks like a legitimate PDF, victims are rerouted to a Dropbox logon impersonation page designed to harvest their credentials for internal access, account takeover, or other fraud. “This is a perfect example of why phishing is still the number one way for criminals to get at organizations,” said David Shipley of Beauceron Security. “This attack works because it mimics normal business behavior.” Anatomy of a multi-layered PDF attack In this campaign, victims first receive a professional-sounding email that seems to be part of a normal procurement or tender process and asks them to review an attached document. The type of wording is “commonly used in tender or procurement fraud, where urgency and legitimacy are deliberately created to encourage quick action,” wrote Forcepoint researcher Hassan Faizan. The PDF serves as the primary malware delivery mechanism. Unbeknownst to the victim, the sender address is spoofed or associated with a compromised account. Once they click on the attachment, they are directed to a second PDF hosted on a trusted cloud service (public.blob[.]vercel-storage[.]com), which further redirects them to a fake Dropbox login page. If they take the bait, they’ll log in with their email address and password, and those credentials will be exfiltrated to attacker-controlled command and control (C2) infrastructure. “The first [document] passed the email filter because it’s perfectly legitimate and links to a trusted service,” said Beauceron’s Shipley. “There’s no way to stop that without lots of negative business consequences.” The second one works because it’s not the trusted cloud service’s job to vet content hosted in it. These types of email also often pass standard authentication checks such as sender policy framework (SPF), DomainKeys Identified Mail (DKIM), and domain-based message authentication, reporting, and conformance (DKIM). “The minimal and business-like content helps avoid keyword-based detection, making the message look and feel more like a routine operational request,” Faizan wrote. Thus, attackers are able to convince victims that they need to authenticate to view the documents. This phishing campaign is interesting in that it’s multi-faceted and has been “very well thought out,” noted Erik Avakian, technical counselor at Info-Tech Research Group. And it’s effective because “nothing looks obviously wrong to the end user at any single stage. The original email is clean and gets by most filters, the first PDF opens normally and seems to be hosted on a legitimate cloud service, and the Dropbox login page looks real. “Each step, by itself, passes the sniff test,” he said. “The danger only becomes obvious when you zoom out and look at the entire chain, and most users don’t think about chains. They think in clicks.” Masquerading as a safe document format But after so many warnings about this over time — why are people still so trusting of PDFs and Dropbox? “Because, historically, they’ve actually been trained to be,” said Avakian. PDFs are routinely used in the business world and have been positioned as a safe, read-only document format for invoices, contracts, HR forms, and statements. This applies to Dropbox, too; it’s become a mainstream business tool that employees have been encouraged to use, and has been positioned so that its services “are not some sketchy file-sharing site anymore.” “When people see a PDF or a Dropbox logo, their guard naturally drops,” said Avakian. Familiarity and the need for speed prevent them from pausing and taking a closer look. Attackers know this, and “exploit it perfectly.” On top of this, Avakian pointed out, cloud infrastructure has become a “shield” for attackers. Security awareness has conditioned users to be wary of shady domains, but not of reputable platforms. It’s a mental model that’s outdated, and “attackers are way ahead of it.” ‘Don’t click links’ is not enough Hackers know that many employees tend to touch payment processes and documents, noted Lionel Menchaca, content marketing and technical writing specialist at Forcepoint, so they must be trained to verify that invoices, purchase orders (POs), and contracts are coming from confirmed vendors, affiliates, and agencies. “If they cannot verify, they should report suspicious emails to IT or security teams,” he said. But the precautions don’t stop there, Shipley noted. Employees must develop good e-mail processing habits, such as by taking frequent breaks; simulations can help, as they allow people to break out of routine. Many email clicks (he estimates about 40%) occur when people are on autopilot and aren’t processing at the deep thinking level, “they’re just acting on instinct.” Avakian agreed that email security awareness training must evolve beyond “don’t click links.” Employers and leaders at all levels must understand that modern phishing is increasingly “multi-stage, cloud-hosted, brand-impersonating, and intentionally boring-looking.” PDFs are no longer “safe by default,” and cloud services are no longer “trusted by default.” “This type of incident becomes a great example, and [an] opportunity to build more sophisticated phishing testing,” said Avakian. “The goal is not to embarrass users, but to build security minded habits as to how attacks unfold today.” While the basics still matter, they need to be framed honestly, he said. Hover over links, but understand that cloud-hosted URLs can still be malicious; check the sender’s “from” address and domain, but recognize that compromised or look-alike domains exist; be cautious of unexpected attachments, even PDFs, especially when they lead you somewhere else; treat any login prompts as a moment to pause, “especially when they’re triggered indirectly,” Avakian advised. “Security awareness has to grow up, just like the threats did,” he said. Still, clicks will happen, and effective multi-layered controls limit the damage. Multi-factor authentication (MFA), conditional access, and anomaly detection are critical, and a zero-trust mindset embeds security into a culture where the “trust by default” mindset goes away, said Avakian. “At the end of the day, PDFs and Dropbox aren’t the problem; unquestioned trust is,” he said. View the full article

Microsoft has announced that the phase-out of NT LAN Manager (NTLM) is now transitioning to disabling the protocol by default, in an effort to increase security in Windows 11 and Windows Server. NTLM is a series of security protocols that were introduced in the 1990s, but since Kerberos became the default protocol in Windows 2000, its use has declined with each passing year. Still, many legacy enterprise systems still support or use NTLM, making them vulnerability to NTLM relay attacks, for example. And while Microsoft administrators have been preparing for the demise of NTLM for years, many still struggle to rid their networks of the protocol. In recent years, hackers have exploited NTLM flaws to gain full access to networks, so the disadvantages of supporting it outweigh the advantages. Microsoft now considers NTLM deprecated. A timetable for the deactivation can be found on the Windows IT Pro Blog. View the full article

FAMILY STOCK – shutterstock.com Unternehmen investieren Millionen von Dollar in Firewalls, Endpunktsicherheit oder Verschlüsselung. Doch eine einzige Person kann eine Katastrophe auslösen. Es reicht, wenn sie eine infizierte Datei herunterlädt oder auf einen betrügerischen Link klickt. Analysen zeigen: Zwischen 70 und 90 Prozent aller Sicherheitslücken entstehen, weil Menschen Fehler machen. Sie fallen auf Social Engineering herein oder nutzen riskante Dienste ohne Erlaubnis der IT. Zudem verschärft sich die Lage, da Angreifer zunehmend künstliche Intelligenz und Deepfakes einsetzen. Das Problem ist bekannt. Deshalb gaben Organisationen im Jahr 2025 etwa sechs Milliarden Dollar für Security Awareness Trainings (SAT) aus. Manche Firmen tun dies freiwillig. Die meisten beugen sich jedoch Vorschriften wie der Datenschutz-Grundverordnung oder dem Health Insurance Portability and Accountability Act. Letzterer verpflichtet etwa alle Beschäftigten im Gesundheitswesen rechtlich zu solchen Programmen. Experten erwarten, dass die Ausgaben für diese Maßnahmen jährlich um 15 Prozent steigen. Warum das klassische Training scheitert Obwohl diese Schulungen zum Standard gehören, bleibt ihr Nutzen fragwürdig. Viele Firmen haken das Thema nur ab, um Regeln einzuhalten. Den eigentlichen Mehrwert ignorieren sie dabei. Die Angestellten wiederum spielen das Spiel mit. Sie klicken sich so schnell wie möglich durch die Tutorials, damit sie weiterarbeiten können. Selbst wer aufpasst, vergisst das Gelernte oft schnell wieder, wenn er es im Alltag nicht aktiv anwendet. Manchmal schaden die Kurse sogar. Studien belegen: Wer in den Tests besonders gut abschneidet, wird oft leichtsinnig. Diese Personen wiegen sich in falscher Sicherheit. Meiner Meinung nach stecken wir in einem Paradoxon. Trotz hoher Investitionen und strenger Regeln bleibt der Nutzen minimal. Das System ist defekt. Wir brauchen deshalb einen radikalen Kurswechsel: weg von sporadischen Kursen, hin zum Human Risk Management. Was bedeutet Human Risk Management? Dieser Ansatz verfolgt eine klare Strategie: Er identifiziert menschliches Verhalten als Risiko und versucht, dieses gezielt zu senken. Während herkömmliche Schulungen nur theoretisches Wissen vermitteln, konzentriert sich das Human Risk Management darauf, wie Menschen tatsächlich handeln. Das System verbindet sich direkt mit E-Mail-Programmen oder Identitäts-Management-Systemen. So erkennt es menschliche Schwachstellen sofort. Es nutzt Daten, um riskante Nutzer aufzuspüren. Danach greift es gezielt ein – etwa durch kurze Lerneinheiten oder automatisierte Kontrollen. Am Ende überwacht das System, ob sich das Verhalten wirklich verbessert. Manche glauben, man müsse für beides separat bezahlen. Das stimmt nicht. Tatsächlich sind führende HRM-Lösungen von Anbietern wie Fable Security, KnowBe4 und Mimecast vollgepackt mit Standard-SAT-Material. Sie bieten sogar spezifische Schulungsunterstützung für regulatorische Compliance-Anforderungen. Lesetipp: Menschenzentrierte Cybersicherheit gewinnt an Bedeutung Demokratisierung durch künstliche Intelligenz Klingt das nach neuem Marketing-Hype? Vielleicht. Aber diese Methode nutzt künstliche Intelligenz als Partner. Anders als bei vielen Trends sind sich Experten hier einig: KI wird die Bildung grundlegend verändern. KI agiert wie ein persönlicher Tutor. Sie gibt kleine Stöße in die richtige Richtung. Klickt jemand auf einen gefährlichen Link, erhält er sofort eine passende Lerneinheit. So verfestigt sich das richtige Verhalten im Moment des Fehlers. Zudem lernt das System, wie einzelne Personen am besten begreifen. Die eine Person liest lieber Texte, die andere schaut lieber Videos. Die Werkzeuge können sogar Rollenspiele durchführen und den Wettbewerb unter Kollegen anspornen. Das demokratisiert Expertenwissen auf eine völlig neue Weise. Für Unternehmen lohnt sich das finanziell. Verantwortliche berichten nicht mehr nur, wie viele Leute ein Video geschaut haben. Sie belegen stattdessen, wie sich die digitale Hygiene im Betrieb verbessert. Wer ständig Fehler macht, bekommt individuelle Hilfe. So lässt sich direkt nachweisen, dass das Training die Zahl der echten Sicherheitsvorfälle senkt. Aristoteles sagte einmal: „Wir sind das, was wir wiederholt tun. Vorzüglichkeit ist also keine Handlung, sondern eine Gewohnheit.“ Genau hier setzt das Human Risk Management an. Es verändert Gewohnheiten. Wäre Aristoteles heute Sicherheitschef, würde er diesen logischen Schritt sicher befürworten. (jm) View the full article

FAMILY STOCK – shutterstock.com Unternehmen investieren Millionen von Dollar in Firewalls, Endpunktsicherheit oder Verschlüsselung. Doch eine einzige Person kann eine Katastrophe auslösen. Es reicht, wenn sie eine infizierte Datei herunterlädt oder auf einen betrügerischen Link klickt. Analysen zeigen: Zwischen 70 und 90 Prozent aller Sicherheitslücken entstehen, weil Menschen Fehler machen. Sie fallen auf Social Engineering herein oder nutzen riskante Dienste ohne Erlaubnis der IT. Zudem verschärft sich die Lage, da Angreifer zunehmend künstliche Intelligenz und Deepfakes einsetzen. Das Problem ist bekannt. Deshalb gaben Organisationen im Jahr 2025 etwa sechs Milliarden Dollar für Security Awareness Trainings (SAT) aus. Manche Firmen tun dies freiwillig. Die meisten beugen sich jedoch Vorschriften wie der Datenschutz-Grundverordnung oder dem Health Insurance Portability and Accountability Act. Letzterer verpflichtet etwa alle Beschäftigten im Gesundheitswesen rechtlich zu solchen Programmen. Experten erwarten, dass die Ausgaben für diese Maßnahmen jährlich um 15 Prozent steigen. Warum das klassische Training scheitert Obwohl diese Schulungen zum Standard gehören, bleibt ihr Nutzen fragwürdig. Viele Firmen haken das Thema nur ab, um Regeln einzuhalten. Den eigentlichen Mehrwert ignorieren sie dabei. Die Angestellten wiederum spielen das Spiel mit. Sie klicken sich so schnell wie möglich durch die Tutorials, damit sie weiterarbeiten können. Selbst wer aufpasst, vergisst das Gelernte oft schnell wieder, wenn er es im Alltag nicht aktiv anwendet. Manchmal schaden die Kurse sogar. Studien belegen: Wer in den Tests besonders gut abschneidet, wird oft leichtsinnig. Diese Personen wiegen sich in falscher Sicherheit. Meiner Meinung nach stecken wir in einem Paradoxon. Trotz hoher Investitionen und strenger Regeln bleibt der Nutzen minimal. Das System ist defekt. Wir brauchen deshalb einen radikalen Kurswechsel: weg von sporadischen Kursen, hin zum Human Risk Management. Was bedeutet Human Risk Management? Dieser Ansatz verfolgt eine klare Strategie: Er identifiziert menschliches Verhalten als Risiko und versucht, dieses gezielt zu senken. Während herkömmliche Schulungen nur theoretisches Wissen vermitteln, konzentriert sich das Human Risk Management darauf, wie Menschen tatsächlich handeln. Das System verbindet sich direkt mit E-Mail-Programmen oder Identitäts-Management-Systemen. So erkennt es menschliche Schwachstellen sofort. Es nutzt Daten, um riskante Nutzer aufzuspüren. Danach greift es gezielt ein – etwa durch kurze Lerneinheiten oder automatisierte Kontrollen. Am Ende überwacht das System, ob sich das Verhalten wirklich verbessert. Manche glauben, man müsse für beides separat bezahlen. Das stimmt nicht. Tatsächlich sind führende HRM-Lösungen von Anbietern wie Fable Security, KnowBe4 und Mimecast vollgepackt mit Standard-SAT-Material. Sie bieten sogar spezifische Schulungsunterstützung für regulatorische Compliance-Anforderungen. Lesetipp: Menschenzentrierte Cybersicherheit gewinnt an Bedeutung Demokratisierung durch künstliche Intelligenz Klingt das nach neuem Marketing-Hype? Vielleicht. Aber diese Methode nutzt künstliche Intelligenz als Partner. Anders als bei vielen Trends sind sich Experten hier einig: KI wird die Bildung grundlegend verändern. KI agiert wie ein persönlicher Tutor. Sie gibt kleine Stöße in die richtige Richtung. Klickt jemand auf einen gefährlichen Link, erhält er sofort eine passende Lerneinheit. So verfestigt sich das richtige Verhalten im Moment des Fehlers. Zudem lernt das System, wie einzelne Personen am besten begreifen. Die eine Person liest lieber Texte, die andere schaut lieber Videos. Die Werkzeuge können sogar Rollenspiele durchführen und den Wettbewerb unter Kollegen anspornen. Das demokratisiert Expertenwissen auf eine völlig neue Weise. Für Unternehmen lohnt sich das finanziell. Verantwortliche berichten nicht mehr nur, wie viele Leute ein Video geschaut haben. Sie belegen stattdessen, wie sich die digitale Hygiene im Betrieb verbessert. Wer ständig Fehler macht, bekommt individuelle Hilfe. So lässt sich direkt nachweisen, dass das Training die Zahl der echten Sicherheitsvorfälle senkt. Aristoteles sagte einmal: „Wir sind das, was wir wiederholt tun. Vorzüglichkeit ist also keine Handlung, sondern eine Gewohnheit.“ Genau hier setzt das Human Risk Management an. Es verändert Gewohnheiten. Wäre Aristoteles heute Sicherheitschef, würde er diesen logischen Schritt sicher befürworten. (jm) View the full article

The first time you’ll hear, “We’re always in incident mode,” it won’t be said with drama. It will be said the way you mention the weather. Grey again. Pager again. And that’s the problem. When a constant alarm becomes normal, your team stops asking the only question that matters. Why do we keep ending up here? You can buy more tools. You can hire more analysts. You can hang more dashboards. You’ll still end up sprinting after the last breach, the last misconfiguration, the last vendor surprise, the last “minor” change that ate your weekend. The best cyber teams we’ve worked with didn’t win because they ran faster. They won because they were adaptive and changed the risk landscape. They built a culture where weak signals had a microphone, and action didn’t require heroics. Forecasting in cybersecurity is not fortune-telling. It’s disciplined habits, clear choices and a team that treats risk as daily practice, not an annual slide. The trap: When ‘busy’ replaces ‘aware’ Reactive teams don’t choose chaos. Chaos chooses them, one small compromise at a time. A rushed change goes in late Friday. A privileged account sticks around “temporarily” for months. A patch slips because the product has a deadline, and security feels like the polite guest at the table. A supplier gets fast-tracked, and nobody circles back. Each event seems manageable. Together, they create a pattern. The pattern is what burns you. Most teams drown in noise because they treat every alert as equal and security’s job. You never develop direction. You develop reflexes. Reflexes feel useful. They look good on incident bridges. They can also keep you blind. Forecasting begins when you stop rewarding the “save” and start rewarding the “see and act.” Risk culture: What it is when you strip the slogans People talk about culture like it’s soft. Posters. Values. A town hall with applause on cue. Culture is harder. Culture is what people do when nobody is watching, and when the clock is loud. Culture is what gets you the truth at 4 p.m., not at 4 a.m. In cybersecurity, risk culture answers four questions. Do people notice risk early? Do they name it clearly? Do they know who can decide? Do they act without fear? If anyone fails, you get silence. Silence is the most dangerous gap in the building. We’ve seen teams with expensive tooling and miserable outcomes because engineers learned one lesson. “If I raise a risk, I’ll get punished, slowed down or ignored.” So they keep quiet, and you get surprised. We’ve also seen teams with average tooling but strong habits. They didn’t pretend risk was comfortable. They made it speakable. Speakable risk is the start of foresight. Foresight enables the right action or inaction to achieve the best result! Signal discipline: Give weak signals a place to land Forecasting is not about seeing everything. It’s about seeing the right things early enough to act. Top teams collect near misses like pilots collect flight data. Not for blame. For pattern. A near miss is the attacker who almost got in. The bad change that almost made it into production. The vendor who nearly exposed a secret. The credential that nearly shipped in code. Most organizations throw these away. “No harm done.” Ticket closed. Then harm arrives later, wearing the same outfit. So you need a place for near misses to land. A lightweight log. A channel people trust. A small weekly ritual where you ask, “What almost happened?” Not “Who messed up.” You also need shared language. Not ten pages of taxonomy. Just words that mean the same thing across teams. When someone says “critical,” do they mean “drop everything,” or “put it in the next release?” Ambiguity breeds delay. Delay breeds surprise. Decision rights: Speed dies in committees We’ve seen incident calls where 20 people had opinions, and nobody had authority. It’s like watching a committee try to steer a ship mid-storm. Forecasting requires speed, and speed requires decision rights and Risk Intelligence. Many programmes invest in detection and forget the human bottleneck. Even perfect visibility is useless if every decision needs a meeting, and every meeting needs a senior leader who is “in back-to-backs.” Top teams make risk-intelligent decisions before the heat. Who can block a release? Who can isolate a system? Who can force key rotation? Who can accept risk, and under what conditions? When an issue jumps a level, and what triggers that jump. If you want forecasting, fix your approval grid. Make it short. Make it usable at 2 a.m. Then protect it. One override for convenience, and people learn the real rules. The real rules always win. Behavioral standards: What ‘good’ looks like on Tuesday You can’t ask people to “care about risk” and expect it to stick. People run on what gets rewarded and what gets them in trouble. So strong teams set behavioral standards. Not as a lecture. As an operating agreement. Security’s job is to reduce harm while keeping work moving, not to act as a gatekeeper. That means rules people can follow, and guardrails that make the right path easier than the wrong one. Engineering’s job is to own what they ship, not to “help security.” If you build it, you own the blast radius. Product’s job is to make exposure part of design, not to treat security as a late-stage checklist. If you can’t explain why a feature is worth the risk, you don’t understand the feature. Vendor owners have a job too. They can’t outsource supplier risk to a questionnaire. They own the follow-up when a supplier says, “We’ll fix it next quarter.” A small practice I love. Ask each team for three “no surprises” rules. No privileged access without expiry. No production change without rollback. No new vendor without an owner and an exit plan. Short list. Clear verbs. Real enforcement. That’s culture. Operating rhythm: The week is where risk becomes real If you only talk about risk during audits and incidents, you don’t have a culture of risk. You have a seasonal sport. Forecasting lives in cadence. In the meetings you actually attend. Weekly, run a short review with three questions. What changed that affects exposure? What almost went wrong? What needs a decision? Keep it tight. If it turns into status theatre, kill it and start again. Monthly, practice one scenario. Plain, no fancy decks. If ransomware hits this service, what happens in the first hour? Who decides. What do you shut down, and what must stay alive? Quarterly, test what you claim. Backups. Access controls. Vendor escalation. If you can’t test it, you don’t know it. This rhythm teaches people that risk isn’t a surprise visitor. Risk is a resident. You don’t panic when you see it. You deal with it. Imagine you once joined a team’s weekly review as a guest. Ten minutes in, an ops lead said, “We changed the identity provider settings yesterday. It felt odd.” No panic. No blame. Just a raised hand. Security asked two questions, engineering checked logs and they rolled back a risky toggle before lunch. Nothing made the news. Nobody got a medal. Everyone went home on time. That’s what a good rhythm buys you. Most weeks, quietly. Measures that point forward: Count what moves before damage Many dashboards tell you what already happened. Incidents. Downtime. Loss. Useful, but late. If you want forecasting, track measures that move before the mess. Let’s shift to being a little more proactive and presilience-focused, instead of testing our reactions and resilience as the go-to responses. How long do critical patches sit on systems that matter? How often do privileged access exceptions expire on time? How many urgent changes bypass checks, and where? How many near misses get reported, and how fast you learn? Watch a team celebrate fewer incidents while near-miss reporting fell to zero. They thought they improved. In reality, people stopped speaking. Six weeks later, they got hit. The silence was the signal. You don’t want perfect numbers. You want honest trends that trigger choices, not slides. Leadership: The culture you reward is the culture you get Leaders say they want transparency. Then they punish the first person who brings bad news. That one moment teaches the organization more than any policy ever could. If you want forecasting and Presilience, protect the messenger. Praise early escalation. Treat risk as a trade, not as a personal failure. Also, stop romanticising heroics. The midnight save feels good. It makes a great story. It also hides the root issue: poor planning, weak controls, unclear ownership and a habit of postponing boring work. Boring work buys calm, discipline buys reliability but risk intelligence enables the right balance of compliance, resilience and presilience to manifest. Think of board conversations where someone asked, “Why spend on resilience when nothing happened this quarter?” And you answered with a question. “Would you rather pay for brakes or for ambulances?” It landed because it was true. A simple 90-day shift: Small moves, real change If your team feels stuck, don’t start with a massive program. Start with a few moves that change behavior fast. First 30 days. Map your top repeat failures. Pick five signals to watch weekly. Name owners. Days 31 to 60. Fix one decision bottleneck. Write the rule. Use it. Days 61 to 90. Run one scenario practice a month. Learn one thing. Change one playbook. Close one gap. You’re not chasing perfection. You’re building a habit. Habits compound. If you do this well, something shifts. You stop being surprised by the same problems. People raise issues earlier. Engineers stop hiding bad news. Security stops shouting into the void. The organization feels calmer. Not complacent. Calm. That calm is not luck. It’s culture. The right balance between prevention, reaction and proactivity ensures sustainable high performance. And here’s the quiet mic-drop. When risk becomes a daily conversation, you don’t need to guess the future. You stop being shocked by the present. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security researchers at Point Wild have disclosed a new Windows malware campaign that uses a multi-stage infection chain to establish persistent, memory-resident access on compromised systems and steal sensitive data. The analysis found the malware relying on standard Windows components for execution and persistence, limiting the number of artifacts written to disk. The activity, analyzed by the company’s Lat61 team, involves a .NET-based, modular remote access trojan (Pulsar RAT) that supports live, interactive operator control. The malware’s reliance on in-memory execution and living-off-the-land techniques limits the effectiveness of file-based detection tools, the researchers noted in a blog post. “The malware exhibits advanced anti-analysis techniques, including anti-VM, anti-debugging, and process injection detection, alongside extensive credential harvesting, surveillance capabilities, and remote system control,” they said. “Stolen data is exfiltrated as ZIP archives over Discord webhooks and Telegram bots.” Initial access and memory-resident execution The infection chain begins with a small batch script that establishes persistence through a per-user Registry Run key. Rather than deploying a full executable, the script launches a PowerShell-based loader, reducing the likelihood of immediate detection by traditional endpoint security tools. This PowerShell loader decodes and executes shellcode generated using Donut, an open-source framework commonly used to convert. NET assemblies into position-independent shellcode. The shellcode injects the payload directly into memory, avoiding the need to write a portable executable to disk. By operating entirely in memory after initial execution, the malware limits the effectiveness of file-based scanning and static analysis. Point Wild researchers noted that the attack blending into normal Windows activity calls for behavioral or memory-focused telemetry. Once loaded, the malware deploys a heavily obfuscated .NET component that serves as the core execution framework for the operation. RAT capabilities and stealer functionality The .NET payload implements a remote access trojan that allows operators to interact directly with compromised systems. Unlike many commodity RATs that rely on periodic check-ins, this malware supports live command handling, enabling attackers to issue instructions and receive responses in near real-time. This interactive design allows operators to perform reconnaissance, manipulate files, execute commands, and manage persistence dynamically based on what they observe on the infected host. Alongside the RAT functionality, the malware includes an information-stealing component that collects sensitive system data. While the disclosure did not attribute the Stealer to a specific malware family, the researchers noted that it operates in parallel with the RAT, allowing data collection to continue while operators actively engage with the system. Persistence, evasion, and mitigation Persistence is maintained through Registry-based autorun entries and reinforced by the malware’s ability to re-establish execution if disrupted. The use of obfuscation across the .NET payload further complicates reverse engineering and slows analysis. Point Wild emphasized that the campaign’s effectiveness stems from disciplined execution of Living-off-the-land binaries, in-memory payloads, and obfuscated managed code. Together, they make detection difficult. The researchers noted that detecting the activity requires monitoring process and memory behavior rather than relying on file-based indicators, which include watching for suspicious PowerShell execution, shellcode injection into running processes, and suspicious persistence via Registry Run keys. Rapid host isolation and live response were emphasized to contain interactive activity and limit data theft once a compromise is suspected. View the full article

Last month, while running a routine access audit on our Azure environment, I came across a service account called svc-dataloader-poc. It had not been touched in 793 days — two years of sitting dormant. When I checked its permissions, my stomach dropped: Owner-level access to three production subscriptions, including our customer database. The account had been spun up for a proof-of-concept migration that never went live. The contractor who created it left 18 months ago. Nobody knew it existed. This was not a one-off. I found 47 similar accounts in that same audit. Forty-seven doors left wide open. Here is the uncomfortable reality facing every security leader in 2026: while we spent the last decade perfecting MFA rollouts and zero-trust architectures for our human users, something else was quietly multiplying across our environments. Service accounts. API keys. Automation credentials. AI agents. These non-human identities now outnumber actual employees in most enterprises by ratios that would have seemed absurd five years ago. ManageEngine’s 2026 Identity Security Outlook found that organisations reported machine-to-human ratios of 100:1; some hit 500:1. And the vast majority of these identities sit completely outside our governance programmes. We locked the front door. The back door has been open this whole time. Why the NHI explosion is different this time Machine identities are not new. What changed is the velocity. Five years ago, a typical enterprise application was a monolith talking to a database. Today, that same application is 50 microservices, each needing credentials to talk to the others. Every Kubernetes pod that spins up during auto-scaling creates workload identities. Every GitHub Actions workflow generates tokens. Every Terraform run provisions service principals. I watched a single deployment pipeline create more machine identities in 20 minutes than our entire company had human users. Then came agentic AI, and the problem accelerated again. These are not chatbots answering questions. They are systems authorised to execute commands, move production data, modify configurations and trigger downstream workflows autonomously. Microsoft Copilot has access to your SharePoint. GitHub Copilot can commit to your repos. The AI assistant your marketing team just deployed can pull customer records from Salesforce. One Identity is predicting 2026 will see the first major breach traced back to an over-privileged AI agent. The terrifying part? It will not look like an attack. It will look exactly like the system doing what it was designed to do. Our IAM systems were never built for this. They assume identities belong to people with managers who respond to access review emails and eventually resign or retire. Machine identities have no manager. They never respond to certification campaigns. They do not quit. The OWASP Non-Human Identities Top 10 ranks improper offboarding as the number one risk. When a project gets cancelled, when a vendor integration gets deprecated, when a developer leaves — does anyone remember to delete the service accounts? In my experience running IAM programmes across multiple organisations, the answer is almost never. The three blind spots I keep finding After years working in cloud security and identity management, certain patterns show up everywhere I look. Three problems in particular appear in nearly every environment I assess. Secrets where they should never be. I still find API keys hardcoded in source files. Still. In 2026. Last year, GitGuardian detected 13 million secrets exposed in public GitHub repositories. Google API keys, MongoDB credentials, AWS access keys — sitting in plaintext for anyone to harvest. But the public repos are not even the biggest problem. In my own assessments, I have found production database passwords in Jira tickets, Slack messages, Confluence runbooks and shared Google Docs. A colleague once discovered an admin token for a payment gateway pasted into a Teams chat from 2023, still valid, still granting full access. Once secrets escape into collaboration tools, you have lost control. They get copied, forwarded, indexed, archived. They never truly disappear. Service accounts with absurd privilege levels. This one makes me angry because it is so preventable. A developer needs a service account for a new Lambda function. They are under deadline pressure. Figuring out the exact minimum permissions takes time, so they attach AdministratorAccess and move on. The function works. Nobody revisits it. That account now has god-mode access to your entire AWS environment for a task that needed read access to one S3 bucket. Multiply this across every team, every sprint, every year. The 2025 State of Non-Human Identities report from Entro Security found 97% of NHIs have excessive privileges. Ninety-seven percent. Even more alarming: just 0.01% of machine identities control 80% of cloud resources. Compromise one of those accounts and the attacker owns your environment. No lifecycle ownership whatsoever. When an employee leaves, HR triggers offboarding. Access gets revoked. There is a process. When a service account is no longer needed, what happens? Nothing. It sits there. I routinely find accounts untouched for six months, twelve months, sometimes three years — all still holding production access. Veza’s research found dormant accounts nearly doubled year over year. Orphaned identities grew 40%. Former employees — 78,000 of them in one dataset — still had active credentials because HR systems flagged them as inactive but nobody revoked their service accounts. These are not theoretical vulnerabilities. These are live credentials waiting for someone to find them. A practical path forward for security leaders Acknowledging the problem is step one. Fixing it requires treating machine identities with the same governance discipline we finally learned to apply to human users. Based on what I have seen actually work, here is where I would focus. Build a real inventory. You cannot protect what you cannot see. Before anything else, discover every non-human identity in your environment. Every service account across your cloud platforms. Every API key in your applications. Every secret in your vaults, config files, CI/CD pipelines. Every third-party integration with access to your systems. Most organisations I work with drastically underestimate their footprint. The actual number is typically three to five times what teams expect. This cannot be a manual exercise or an annual audit. Identities are created faster than humans can count them. Automate discovery and make it continuous. Enforce least privilege without exceptions. Every NHI needs to be scoped to the minimum access required for its function. Yes, this takes work. Yes, developers will push back. Do it anyway. Start with new deployments and make least privilege the default from day one. For existing accounts, compare assigned permissions against actual usage patterns. You will find plenty of accounts with broad access that only ever touch one or two resources. Those are quick wins. Require security approval before any NHI gets elevated privileges. Make it a gate, not a suggestion. Eliminate static credentials wherever possible. Long-lived secrets are the root cause behind most NHI breaches. The goal should be eliminating them entirely. Replace permanent API keys with short-lived tokens that expire automatically. Implement just-in-time access that grants permissions for a specific task and revokes them immediately after. Automate credential rotation on a defined schedule — weekly, daily, even hourly for sensitive systems. Research shows 71% of non-human identities are not rotated within recommended timeframes. Every day a credential sits unchanged is another day an attacker could be using it without detection. The security industry is converging on a clear consensus for 2026: machine identities will become the primary breach vector in cloud environments. Tenable predicts it. Delinea predicts it. One Identity predicts it. Attackers already know that compromising a service account is often easier and quieter than targeting humans. They are not breaking down doors anymore. They are walking through the ones we forgot to lock. The organisations that get ahead of this threat will be the ones treating their non-human identities with the same seriousness they apply to their executive accounts. Full visibility. Strict governance. No exceptions. The ones who keep treating NHIs as an afterthought will be the ones explaining to their boards how a forgotten service account from a cancelled project brought down the house. We locked the front door years ago. It has been a long time since we secured the back. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article