CSOonline

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A newly discovered botnet is compromising poorly-protected Linux servers by brute-forcing weak SSH password login authentication. Researchers at Canada-based Flare Systems, who discovered the botnet, got into its staging server and believe at least 7,000 servers had been compromised by the end of January, half of them in the US. The botnet’s weapons include exploits for unpatched Linux vulnerabilities going back as far as 2009. The researchers describe the botnet, dubbed SSHStalker, as “a sophisticated operation that blends 2009-era Internet Relay Chat (IRC) botnet tactics with modern mass-compromise automation.” It has a “stitched together botnet kit” that executes fileless malware, rootkits, log cleaners and a wide array of kernel exploits. Among other things, it harvests AWS credentials. The researchers call SSHStalker a “scale-first operation that favors reliability over stealth.” However, so far the botnet hasn’t done much other than maintaining persistence on infected machines. It has the ability to launch DDoS (distributed denial of service) attacks and conduct cryptomining, but hasn’t done anything yet to monetize its access. That, Flare says, suggests either the operator is still staging the botnet’s infrastructure, is in a testing phase, or is maintaining access for future use. The good news for CSOs, according to Flare cybersecurity researcher Assaf Morag, is that at this point there’s one way to stop this particular botnet cold: Disable SSH password authentication to Linux machines and replace it with SSH-key based authentication, or hide password logins behind a VPN. This change should be accompanied by implementation of SSH brute-force rate limiting, monitoring who is trying to access internet-connected Linux servers, and limiting remote access to servers to specific IP ranges. However, Morag cautioned, right now SSHStalker is looking for Linux servers with weak SSH protection, but at any moment, the operator may add another attack vector, such as an unpatched server vulnerability or misconfiguration. Security fundamentals are key Chris Cochran, SANS Institute field CISO and VP of AI security, said SSHStalker is a reminder that security fundamentals still decide the fight. “Yes, AI is changing the threat landscape. Yes, automation is accelerating attacks. But this campaign proves something simpler and more uncomfortable: Old tricks still work,” he said. “If I’m talking to another CISO today, my advice isn’t ‘buy more AI.’” CSOs and infosec leaders should use this report as an excuse to finally lock in some of the security basics they’ve always wanted to implement, he said. These include killing the use of passwords for logins. “If you are still allowing password-based SSH access in 2026, you are essentially inviting botnets in for coffee,” Cochran said. Infosec leaders should either move to key-based authentication, or to solutions with short-lived credentials or identity-aware proxies. Second, they need to aggressively inventory their IT assets, given the old rule, ‘You cannot protect what you don’t know exists.’ Most of the thousands of systems hit by SSHStalker were forgotten servers, he said. Third, infosec leaders have to realize the real problem in their environments is security debt: The backlog of unpatched systems, the lingering known vulnerabilities, and the ‘we’ll get to it next quarter’ backlog. “Those are what get exploited,” he said. “We need to stop chasing the 1% cool threats until we’ve solved the 99% boring ones.” Dave Lewis, global advisory CISO at 1Password, added that infosec leaders should make sure there are no compilers on production servers, and that build tools are only on designated build hosts. There should be alerts on IRC-like traffic, and, on Linux servers, cron/systemd integrity monitoring, especially for ‘runs every minute’ patterns. Finally, because SSHStalker looks for older Linux machines, admins should have a legacy Linux eradication plan prioritizing the unhooking of machines with any version of Linux kernel 2.6, because these servers are being targeted. How it was discovered Discovery of SSHStalker came after Flare created an SSH honeypot with intentionally weak credentials at the beginning of this year, to see what happened. While the majority of attacks came from known threat actors, there was a distinct cluster from one source with no similar execution flow or prior indicators of compromise. After getting into a Linux machine, the malware creates a backdoor with its own SSH key to maintain access. It also installs a binary that scans port 22 for servers with unprotected SSH, trying to find other new and vulnerable servers. The payload also contains several C scripts, including the Linux gcc (the GNU Compiler Collection) for compiling and running malware. This stage is “loud,” Morag said, so defenders should note it can be detected with an application that looks for abnormal server behavior. Secondary payloads in a zip file include an IRC (internet relay chat) bot for communicating with a command and control server. Other stages install malware that runs in memory. “This entire execution chain is very loud,” Morag said. “they don’t need to do all of it. I guess what they are trying to do is run on Internet-of-Things [devices], but also on commercial servers.” It also suggests that the operator is still in the early stage of building the botnet, he said. But the report also says the IRC components could be used to hide activity, through things like included random chat phrases. “This strongly suggests the bot was configured not only for control, but also for behavioral camouflage,” says the report, by generating human-like noise in IRC channels to obscure real operator activity or to make automated presence appear organic. “This tactic is consistent with legacy botnet operational tradecraft, where blending into public channels reduced suspicion while still allowing operators to issue commands via private messages, DCC (direct client-to client) sessions, or linked bot networks,” the report says. The malware hunts for older Linux kernels, including versions 2.6.18, 2.6.18-164, 2.6.31, and 2.6.37. This would include roughly up to 3% of internet-facing Linux servers, Flare estimates. But it could be as much as 10% in what Flare calls long-tail environments like legacy hosting providers, abandoned VPS images, outdated appliances, industrial/OT gear, or niche embedded deployments. The kernel exploit inventory includes 16 different CVEs, five dating back to 2009 and three to 2010. Judging by the components of the malware, the operator likely understands kernel version fingerprinting, privilege escalation chaining, and mass exploitation workflows, even if they are not developing novel exploits, the report says. Advice for infosec leaders In addition to disabling SSH password authentication, the report recommends that infosec leaders: set up alerts triggered when non-system processes attempt to modify login accounting records. remove compilers from production images if possible; allow toolchain execution only in controlled build environments; enforce egress filtering based on business need; use an anti-virus scanner to pick up binaries dropped by SSHStalker; monitor for unauthorized execution of gcc; set up alerts when compilers run from user directories, /tmp or /dev/shm; set up alerts when newly-compiled binaries execute within seconds or minutes of creation; set up alerts on servers to detect communication with unknown external chat or relay infrastructure. View the full article

That handy ‘Summarize with AI’ button embedded in a growing number of websites, browsers, and apps to give users a quick overview of their content could in some cases be hiding a dark secret: a new form of AI prompt manipulation called “AI recommendation poisoning.” So says Microsoft, which this week released research on a currently legal but extremely sneaky AI hijacking technique that appears to be spreading like wildfire among legitimate businesses. While most ‘Summarize with AI’ buttons are exactly what they seem to be – a time-saving way to generate a summary of a website or document – a small but growing number appear to have strayed from that purpose. Here’s how the manipulation works: a user innocently clicks on a website Summarize button. Unbeknownst to them, this button also contains a hidden prompt telling the user’s AI agent or chatbot to favor that company’s products in future responses. The same instruction can also be concealed in a specially crafted link sent to a user in an email. Microsoft highlights how this tactic could be used to skew enterprise product research without that bias being detected before it influences decisions. Over a two-month period, its researchers identified 50 examples of the technique being deployed by 31 different companies in dozens of industry sectors, including finance, health, legal, SaaS, and business services. In an ironic twist, this even included an unnamed vendor in the security sector. The technique is widespread enough that, last September, MITRE added it to its list of known AI manipulations. AI leverages user preferences AI recommendation poisoning is made possible by user AIs that are designed to ingest and remember prompts as signals of the user’s preferences; if the user says that they favor something, the AI will helpfully remember that preference as part of its profile for that user. Unlike prompt injection, in which an attacker manipulates an AI using a one-off instruction, recommendation poisoning has the added advantage of achieving longer-term persistence across future prompts. The AI, of course, has no way of distinguishing genuine preferences from those injected by third parties along the way: “This personalization makes AI assistants significantly more useful. But it also creates a new attack surface; if someone can inject instructions or spurious facts into your AI’s memory, they gain persistent influence over your future interactions,” said Microsoft. To the user, everything will seem normal, except that, behind the scenes, the AI keeps pushing the bogus or poisoned responses when they ask it questions in a relevant context. “This matters because compromised AI assistants can provide subtly biased recommendations on critical topics including health, finance, and security without users knowing their AI has been manipulated,” said the researchers. Pushing falsehoods A factor driving the recent popularity of recommendation poisoning appears to be the availability of open-source tools that make it easy to hide this function behind website Summarize buttons. This raises the uncomfortable possibility that poisoned buttons aren’t being added as an afterthought by SEO developers who get carried away. More likely, the intention from the start is to contaminate users’ AIs as a form of self-serving marketing. In Microsoft’s view, the dangers go beyond over-zealous marketing, and could just as easily be used to push falsehoods, dangerous advice, biased news sources, or commercial disinformation. What’s certain is that if legitimate companies are abusing the feature, cybercriminals won’t be shy about using it too. The good news is that the technique is relatively easy to spot and block, even if you don’t use Microsoft’s Microsoft 365 Copilot or Azure AI services, which the company says contain integrated protections. For individual users, this involves studying the saved information a chatbot has accumulated (how this is accessed varies by AI). For enterprise admins, in contrast, Microsoft recommends checking for URLs containing phrases such as ‘remember,’ ‘trusted source,’ ‘in future conversations,’ ‘authoritative source,’ and ‘cite or citation.’ None of this should be surprising. Once, URLs and file attachments were seen as convenient rather than inherently risky. AI is simply following the same path that every new technology must endure as it moves into the mainstream and becomes a target for misuse. As with other new technologies, users should educate themselves on the dangers posed by AI. “Avoid clicking AI links from untrusted sources: Treat AI assistant links with the same caution as executable downloads,” Microsoft recommended. This article originally appeared on CIO.com. View the full article

A financially motivated threat actor tracked as UNC1609 is using a ClickFix-style social engineering campaign to deploy multiple macOS malware families against crypto-focused organizations. According to new research from Google Cloud’s Mandiant, the activity recently targeted an employee at a company operating in the cryptocurrency and decentralized finance (DeFi) sector. The researchers said that the North Korea-linked UNC1069 used a social engineering chain that involved a hijacked Telegram account, a fake Zoom meeting, a ClickFix-style command execution, and the reported use of AI-generated video to deceive the victim. By impersonating a known industry contact and staging a fake video meeting, the threat actor convinced the victim to execute malicious terminal commands on a macOS system manually. ClickFix as initial access The attack began with the victim being contacted via Telegram from a compromised account belonging to a legitimate industry executive. After establishing credibility, the attacker invited the target to a video meeting hosted on infrastructure controlled by the threat actor. During the meeting, the victim reportedly saw what appeared to be a recognizable individual from the cryptocurrency industry. Researchers assessed that the video may have been artificially generated or manipulated to reinforce legitimacy. Shortly after the call began, the attacker claimed there were audio issues and instructed the victim to perform troubleshooting steps. These steps included copying and pasting commands into the macOS Terminal. One command used “curl” piped into “zsh”, effectively downloading and executing a remote script. That action initiated the infection chain. Mandiant said it observed similar tactics outside of this attack. “The recovered web page provided two sets of commands to be run for “troubleshooting”: one for macOS systems, and one for Windows systems,” the researchers noted. “Mandiant has observed UNC1069 employing these techniques to target both corporate entities and individuals within the cryptocurrency industry, including software firms and their developers, as well as venture capital firms and their employees or executives.” UNC1069 is known to use tools like Google Gemini to develop tooling, conduct operational research, and assist during reconnaissance stages, they added. Use of specialized, undocumented macOS malware After the ClickFix-triggered access is established, UNC1069 deployed a multi-stage macOS malware stack that Mandiant identified as including WAVESHAPER, HYPERCALL, HIDDENCALL, DEEPBREATH, and CHROMEPUSH, among others. Several of these malware families had not been documented publicly before Mandiant’s disclosure. WAVESHAPER functioned as the primary backdoor, establishing remote access and enabling additional payload delivery. HYPERCALL operated as a downloader, retrieving secondary components such as HIDDENCALL, which provided further command execution capabilities. This staged deployment allowed the threat actor to expand control over the compromised macOS system in phases rather than dropping a single large payload. DEEPBREATH, a Swift-based infostealer, focused on harvesting sensitive data from the host. According to the researchers, it manipulated Apple’s Transparency, Consent, and Control (TCC) framework to access protected resources without prompting the user. That enabled the collection of browser data, keychain material, and messaging content. CHROMEPUSH, meanwhile, targeted browser environments, including session cookies and authentication tokens. The researchers also observed abuse of macOS security mechanisms, including functionalities on Apple’s XProtect system. Instead of disabling protections right away, the malware leveraged trusted system components and expected behaviors to reduce detection visibility. Mandiant stated that the use of a custom, integrated tool suite indicated UNC1069’s technical proficiency in specialized capabilities and security bypass. It provided a list of network-based and host-based indicators of compromises (IOCs) to support detection efforts. Additionally, the disclosure included a set of YARA rules that are also supported in Google SecOps. View the full article

Google has secured unconditional EU antitrust approval for its $32 billion acquisition of cloud security firm Wiz, clearing a major regulatory hurdle and paving the way for one of the largest cybersecurity acquisitions to date. The decision removes a key uncertainty for enterprise customers and positions Google Cloud to aggressively expand its security portfolio as competition intensifies with AWS and Microsoft in multicloud environments. “The Commission found that there are several credible competitors that customers could switch to if Google were to bundle Wiz’s multi-cloud security platform with its existing products, or in case Wiz’s platform no longer worked with clouds other than Google’s,” the European Commission said in a statement. The Commission said it also examined whether the acquisition would give Google access to commercially sensitive data from rival cloud providers that integrate with Wiz, but concluded that the information involved is not commercially sensitive and is generally accessible to other security software vendors. Security reshapes cloud dynamics Cybersecurity remains one of the most complex and fragmented areas of enterprise IT, with many organizations relying on multiple point solutions rather than a unified, end-to-end security architecture. Analysts say the real fight in cloud computing is moving beyond infrastructure and into the control layer, where whoever has the clearest view of risk across environments holds the advantage. “Compute, storage, and network scale are no longer sufficient differentiators at the enterprise board level,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “The real leverage now sits in who owns visibility across workloads, identities, entitlements, exposure paths, and increasingly AI pipelines.” The acquisition positions Google as a vertically integrated cloud and AI cybersecurity provider that can give enterprises access to a more unified platform. But what the company does next is crucial, according to Neil Shah, VP for research at Counterpoint Research. “The next step is how Google intertwines its current capabilities, such as Google Vertex AI Studio, with Wiz’s ‘Security Graph’ to enable enterprise developers to build a dynamic, real-time, and autonomous security layer,” Shah said. Other analysts view the transaction as part of a broader structural shift in how hyperscalers embed security within their ecosystems. “The acquisition signals the end of the best-of-breed era for cloud security and the beginning of Hyperscaler-led multicloud,” said Pareekh Jain, CEO of Pareekh Consulting. “It suggests that major cloud providers effectively own the security layer, even for their competitors’ environments. Cloud security is evolving from siloed tools into platform-level infrastructure, and hyperscalers are now competing not just on compute or storage but on unified security across ecosystems.” Risks for enterprises Jain said that while Wiz’s core value proposition is built on cloud neutrality, ownership by Google changes the strategic incentives. “In theory, Wiz can remain cloud-agnostic, as its value proposition is grounded in neutral visibility across clouds,” Jain said. “However, under Google ownership, the incentives change. Tighter integration with Google Cloud could be prioritized, and features that differentiate against AWS or Azure may receive less focus.” EU regulators concluded the deal would not meaningfully lessen competition, but analysts caution that deeper vertical integration could still anchor enterprises more tightly within Google’s platform stack, increasing long-term switching costs. “For CIOs and CISOs, this acquisition fundamentally alters the risk calculation of using third-party security tools,” Jain said. “Enterprises heavily invested in AWS or Azure may start looking for a new independent security layer, e.g., CrowdStrike, Palo Alto Networks, to avoid dealing with Google.” Lock-in extends beyond data portability to the underlying technical architecture, according to Gogia. He noted that flexibility decreases as organizations optimize their remediation playbooks and alert taxonomies for a specific provider’s telemetry or integrate AI governance tools natively with a single cloud’s model ecosystem. View the full article

In my recent articles for CSO, I’ve talked about the limits of current SOC models and the importance of rehearsal. This time, I want to focus on something that’s becoming increasingly clear: purple teaming has lost its depth. We’ve turned one of the most powerful tools for resilience into a transactional exercise that feels reassuring but reveals very little about how an organization will cope when the pressure is real. Care and attention have become rare assets in our world. Distraction dominates both the consuming and supply sides of cybersecurity. Clients are pulled into complexity and novelty, while services providers are pulled into deadlines and deliverables. Meanwhile, attackers — increasingly powered by AI — are becoming faster, quieter, and more determined. When threats accelerate, surface-level testing is no longer enough. The absence of findings is not the absence of risk I’ve seen this pattern everywhere: a purple team engagement produces a set of impressive outcomes. The report looks good. Findings correlate with expectations. Leadership feels reassured. But a result is often treated as the result, as if the absence of findings means the absence of risk. This is a flaw. The industry’s default approach is shaped by time pressure, commercial constraints, and scopes that are too narrow. None of this is malicious, it’s simply how the system has evolved. Providers deliver what they’re contracted to deliver, and clients take the report as a sign of depth. Omissions, often caused by time pressure or lack of mental space, are invisible. And invisible omissions are the most dangerous kind. Two clients who “shouldn’t have been breakable” Recently, we worked with two extremely mature organizations. On paper, both looked close to unbreakable. Instead of running a standard purple team, we co-designed the engagement with them. We looked at the problem as a determined attacker would, and we shared tacit knowledge openly, both our own and theirs. Crucially, everyone involved had visibility into the controls in place. It was a genuine cyber security partnership, not an audit. And both organisations were compromised — deeply — with almost no sign of compromise. In one case, there was a single indicator of compromise: “domain admin.” Nothing about how it happened. Nothing about what to do next. No instinctive or automated response. Just a light turning red with no playbook behind it. In the other case, the SOC detected multiple signals but never acted in time. Detection without action is just noise. The experience was humbling. And it forced a blunt question: “You saw us. So what?” That’s the real test. Not whether the SOC sees something. Whether it does something — fast enough and accurately enough — to stop the damage. Standard purple teaming can’t get you there Purple teaming should be the discipline that reveals these realities, but the current model rarely does. Service providers tend to focus on the bypass, the exploit, the “win.” Clients focus on closing tickets, finishing the engagement, and getting the report. Neither mindset creates the space needed for deep thinking. Had we rushed through our work we would never have found what we did. Time pressure shapes outcomes more than most organizations realize. When testing is constrained by a standard 9–5, it limits how far teams can explore the conditions that lead to real compromise. Resilience is the “brake” moment Imagine you’re driving, and you see the car ahead braking suddenly. Awareness helps, but it’s your immediate reaction that avoids the collision. Insurance plans don’t matter at that moment. Nor do compliance reports or dashboards. Only vigilance and rehearsal matter. Cyber resilience works the same way. You can’t build the instinct required to act by running one simulation a year. You build it through repetition. Through testing how specific scenarios unfold. Through examining not only how adversaries get in, but also how they move, escalate, evade, and exfiltrate. This is the heart of real purple teaming. AI didn’t help either organisation Both clients had AI embedded in their SOCs. And it made no difference. AI can accelerate analysis, but it can’t replace intuition, design, or the judgment required to act. If the organization hasn’t rehearsed what to do when the signal appears, AI only accelerates the moment when everyone realises they don’t know what happens next. This is why so much testing today only addresses opportunistic attacks. It cleans up the low-hanging fruit. But if organized crime wanted these organisations, they would have had them. And that’s not an easy sentence to write. A model that creates false confidence The standard testing model traps everyone involved: One-off tests create false confidence. Scopes limit imagination. Time pressure eliminates depth. Commercial structures discourage collaboration. Tooling gives the illusion of capability. Compliance encourages the appearance of rigour instead of the reality of it. This is why purple teaming often becomes “jump out, stabilize, pull the chute, roll on landing.” But what about the hard scenarios? What about partial deployments? What about complex failures? That’s where resilience is built. And today, resilience is the only meaningful metric. New mindset: slow, consistent, engaged, outcome-driven In my experience, purple teaming that works requires: Co-ownership of the mission. Tacit knowledge shared on both sides. Full visibility into controls. Scenarios designed, not bought. Repetition and rehearsal. Space for thinking. Disciplined simplicity. A focus on the “so what,” not the bypass. This is systems thinking. Engineering. Psychology. It is, in every sense, harder work than the standard model. But the seemingly impossible becomes possible when both sides push each other, and when the aim is not to produce a report but to reveal reality. Purple teaming is about getting in, sure. But it’s also about what happens after that. Without a different approach, focused on consistency and outcomes, organizations will keep passing tests while failing in practice. View the full article

In 2026, the cybersecurity industry is expected to cross a threshold it has never reached before: More than 50,000 publicly disclosed software vulnerabilities in a single year. According to a new forecast from the Forum of Incident Response and Security Teams (FIRST), the median projection for 2026 is roughly 59,000 Common Vulnerabilities and Exposures (CVEs). Under more extreme — but plausible — scenarios, that number could climb far higher, reaching nearly 118,000, more than double the estimated 48,000 or so CVEs reported in 2025. But security researchers and data scientists caution that numbers tell only part of the story. Historically, only a small fraction of disclosed vulnerabilities is ever exploited in the wild, and an even smaller subset meaningfully affects most enterprises. “While the number of vulnerabilities goes up, what really matters is which of these are going to be exploited,” Michael Roytman, co-founder and CTO of Empirical Security, tells CSO. “And that’s a different process. It does not depend on the number of vulnerabilities that are out there because sometimes an exploit is written before the CVE is even out there.” What FIRST’s forecast highlights instead is a growing signal-to-noise problem, one that strains already overburdened security teams and raises the stakes for prioritization, automation, and capacity planning rather than demanding that organizations patch more flaws exponentially. Why are flaw numbers rising? FIRST’s forecast reflects structural changes in how vulnerabilities are discovered and disclosed, not a sudden leap in attacker capability. “Some of the classic coordinated vulnerability disclosure teams are producing slightly higher volumes each individually, but we’re also seeing several new entrants to the space that produce a lot,” Éireann Leverett, FIRST liaison and lead member of the organization’s Vulnerability Forecasting Team, tells CSO. The growth also reflects a maturation of vulnerability reporting itself. More organizations now operate as CVE Numbering Authorities, more vendors incentivize disclosure through bug bounty programs, and long-neglected code bases — particularly in open source infrastructure — are receiving sustained scrutiny. In that sense, the surge reflects improved visibility rather than deteriorating software quality. Vulnerabilities that existed for years are now being cataloged, tracked, and measured in ways that were not possible a decade ago. FIRST also adjusted its modeling approach to account for a structural shift in CVE publication that began around 2017, when disclosure volumes started to rise more steeply. Rather than optimizing for a single point estimate, the organization widened its confidence intervals to help security teams plan for a range of outcomes. “We think it’s entirely realistic that this year we reach 70,000 to 100,000 vulnerabilities,” Leverett says, adding that the median forecast remains closer to 60,000 and is intended to support planning rather than alarm. Why raw CVE counts do not equal risk Despite the scale of the forecast, experts stress that vulnerability volume alone is a poor proxy for enterprise risk. “The risk to an enterprise is not directly related to the number of vulnerabilities released,” Empirical Security’s Roytman says. “It is a separate process.” He points to historical data showing that while CVE numbers have risen steadily, exploitation has not followed the same trajectory. In 2025, roughly 48,000 vulnerabilities were disclosed, Roytman says. Of those, fewer than 3,000 had publicly available proof-of-concept exploit code, and only about 700 showed evidence of exploitation in the wild. “The really risky things changed a little bit [over 2024 levels], not quite as much as you would expect from the overall change,” he says. On top of that, many vulnerabilities affect niche software, consumer devices such as cell phones, and other configurations that are not priorities in large enterprise environments. Other vulnerabilities are theoretically exploitable but offer little value to attackers compared with already weaponized flaws that are proven, scalable, and reliable. This pattern has held for years, even as disclosure volumes climbed. The result is a widening gap between the number of vulnerabilities published and the number that matter operationally. A capacity problem, not a crisis Still, the growing volume creates real challenges for defenders. FIRST estimates that roughly 5% of vulnerabilities account for most of the serious risk. As the overall number rises, identifying that critical subset becomes harder. “With all of this extra being produced, finding that 5% might be a little harder, like finding a needle in the haystack,” FIRST’s Leverett says. “It’s about finding the signal in the noise.” For CISOs, the implication is that patching strategies are now more about scaling decision-making processes that were already under strain. “If you’re telling me a machine has to process 100,000 things instead of 50,000 things, that’s not a big deal,” Roytman says. “If you’re telling me a human has to do that, I would panic.” Security teams have not operated at a human scale for years, he adds. The difference now is that the noise floor is rising fast enough to expose weaknesses in prioritization, tooling, and automation. AI is accelerating discovery — not mass exploitation (yet) Much of the anxiety surrounding FIRST’s forecast centers on artificial intelligence, particularly large language models that can audit code at scale. While AI-assisted tools are already increasing the pace of vulnerability discovery, experts caution that discovery and exploitation remain very different problems. Roytman argues that while AI has made it easier to enumerate flaws, attackers still face economic and operational constraints. “If it were that easy, they’d be doing it to the 50,000 we saw last year,” he says. “Instead, exploitation remains concentrated on a relatively small set of vulnerabilities that are proven, scalable, and valuable.” At the same time, defenders are using the same techniques to manage the flood. Machine-learning models trained on exploitation data increasingly help security teams determine which vulnerabilities are likely to matter — and which can safely be deprioritized. “The same tools that are enabling discovery at scale are also enabling defenders to filter signal from noise at scale,” Roytman adds. What CISOs should do to manage the CVE flood? Absent the ability to hire their way out of the problem, most organizations will need to rely on more pragmatic measures, such as: Double down on prioritization. Exploitation likelihood, asset context, and business impact matter far more than raw (CVSS Common Vulnerability Scoring System) scores. Automate triage aggressively. Human review should be reserved for a small, high-confidence subset of vulnerabilities. Plan for ranges, not point estimates. FIRST’s confidence intervals are designed to support capacity planning, not prediction. Expect more noise, not more attackers. Disclosure is accelerating faster than exploitation. “There’s no need to panic,” Roytman says. “But there is a need to be strategic.” Stress on the vulnerability ecosystem The forecast also raises questions about the sustainability of the broader vulnerability ecosystem, including MITRE, which produces CVEs under contract with the Cybersecurity and Infrastructure Security Agency (CISA), the National Vulnerability Database administered by the National Institute of Standards and Technology, and CVE Numbering Authorities (CNAs) — organizations authorized to assign CVEs — already struggling with backlogs. Sasha Romanosky, a senior policy researcher at RAND, tells CSO the system is more likely to degrade gradually than collapse outright under the weight of a spiraling number of CVEs. “I don’t think it would cause anything to break,” Romanosky says. “They just wouldn’t get processed. Lots of vulnerabilities would be ignored.” That dynamic could shift more responsibility toward software vendors and CNAs, many of whom already face capacity constraints of their own. Distributing more of the enrichment and prioritization work downstream may help in the short term — but only if automation improves alongside it. “The system isn’t fragile,” Romanosky says. “It’s constrained.” In practice, that could mean growing queues, uneven data quality, and greater reliance on private-sector tooling to compensate for delays in public databases. The result is not necessarily higher risk, but greater fragmentation, particularly for organizations without mature vulnerability management programs. The cybersecurity industry is not facing an explosion of exploitable weaknesses so much as an explosion of information. For CISOs, success in 2026 will depend less on reacting faster and more on deciding better — using automation and context to ensure that rising vulnerability counts do not translate into rising risk. “It hasn’t been a human-scale problem for some time now,” Roytman says. The challenge ahead is making sure it does not become an unmanageable one. View the full article