Malvertising is becoming harder to identify by looking at the ad itself.

A growing share of malicious advertising activity now depends on what happens after the click: redirect chains, disposable domains, cloaking systems, conditional delivery, and campaign behavior that can change after initial approval. The creative or landing page may appear innocent, while the malicious component sits several steps deeper in the delivery chain.

The following analysis is based on campaign moderation data from PropellerAds, covering campaigns reviewed during the first half of 2026. At this scale, shifts in fraud infrastructure tend to become visible in the data before they’re widely recognized as a trend — this dataset is one example of that.

Malware and antivirus-flagged threats rose from 8,408 rejected campaigns in Q1 to 9,543 in Q2 — a 13% increase in absolute terms, at a time when total rejections fell 42% (36,085 to 20,790). As a share of all rejections they went from 23.3% to 45.9%, becoming the largest category. Much of that shift in share reflects adult-content violations being filtered out earlier in moderation (47.8% to 5.3%). The substantive point is that technical threats kept growing while straightforward content violations collapsed. Overall campaign rejections dropped by 42%, from 36,085 to 20,790.

Taken together, the numbers point to a marked change in the composition of rejected campaigns. Straightforward content violations are becoming easier to stop earlier in moderation, while a greater share of rejections now involves technical threats that are harder to evaluate through a single static check.

Independent industry data showed the same shift a year earlier. GeoEdge found redirect-based attacks rising from 48% of malicious activity in Q1 2025 to 66% in Q2 2025, while malicious ad activity doubled across the five largest markets it monitored. Overall malicious ad activity doubled across the five largest markets it monitored. Google’s H1 2026 threat telemetry, meanwhile, found malvertising accounted for almost 30% of its threat detections, underlining how closely malicious advertising now overlaps with the broader consumer cybersecurity landscape.

Cloaking reinforces the same pattern in the PropellerAds dataset. It accounted for 67.3% of advertiser suspensions in Q2, almost unchanged from 68.1% in Q1 — evidence that hiding a campaign’s real destination or behavior is a persistent operating tactic, not an occasional evasion technique.

The malicious asset is increasingly the chain, not the page

Traditional ad review begins with visible elements: the creative, landing page, offer, and directly associated domains. That approach becomes less effective when malicious behavior is distributed across several technical components.

A campaign may begin with an apparently compliant ad and a clean landing page, then route the user through tracking services, intermediate domains, conditional redirects, or additional pages before reaching the final destination. Each stage may look harmless in isolation; the risk only becomes visible when the full path is reconstructed.

The Media Trust’s 2026 Digital Advertising Intelligence Report describes a similar problem: malicious creatives are increasingly designed to, as the report puts it, “activate only under particular geographic, device, or behavioral conditions”, making one-time detection less reliable.

This architecture gives malicious operators several advantages. It separates the original ad from the eventual payload. Individual domains can be replaced without rebuilding the whole operation. Traffic can be segmented by geography, device, or other signals so different visitors see different outcomes.

A recent malvertising campaign investigated by Confiant illustrates the model. Active since late 2024, it impersonated brands including TradingView, Solana, and Luno across 12 countries and 25 languages. Its landing pages fingerprinted visitors: suspected researchers and bots received an empty page, while selected targets saw convincing copies of the impersonated services.

The campaign is therefore no longer a single malicious object. It is a delivery system.

A static inspection asks: what does this page contain right now? Infrastructure-aware analysis has to ask where the user goes next, whether that destination changes, and whether the same campaign behaves differently hours after approval. The deeper malicious behavior moves into the delivery chain, the less useful a one-time assessment becomes.

Fraud infrastructure follows market economics

The Q2 observations also suggest that traffic economics can influence the form malicious advertising takes — and that the distinction is economic as much as geographic.

In high-payout markets, including Tier-1 geographies such as the US and UK, higher CPC and CPA values can support greater investment in evasion infrastructure: longer redirect chains, multiple domains, and deeper-funnel cloaking. The economic logic favors persistence—surviving scrutiny long enough to extract greater value from each successful conversion.

For defenders, that makes signals such as destination switching, cloaking, and infrastructure reuse especially relevant.

In lower-cost, high-volume markets, a different model becomes viable. Infrastructure can be cheaper, easier to replicate, and easier to discard, with profitability depending on distributing many attempts rather than heavily engineering a smaller number of campaigns.

In high-volume environments, replication signals — rapidly changing domains, reusable templates, and large clusters of similar campaigns — may therefore matter more.

Both models rely increasingly on infrastructure rather than a single deceptive page. They simply optimize that infrastructure for different conditions: persistence in one case, scale and replaceability in the other.

Multi-hop redirects create a visibility problem.

Redirect chains separate the point where a user enters a campaign from the point where malicious behavior occurs. The path may include several intermediate domains, tracking services, conditional redirects, or other routing layers before the user reaches the final destination. 

Each additional hop creates another opportunity to change behavior. One domain may exist for tracking, another for a device or location check, another to decide the final destination. Some users may see a benign page while others are sent to a malicious endpoint.

This complicates moderation in several ways. The final destination may not be visible during the initial review. Malicious domains can be short-lived and replaced once blocked. Infrastructure can behave selectively according to location, device, or other visitor characteristics. The chain itself can also change over time.

GeoEdge’s data again shows how prominent this technique has become: auto-redirects accounted for 66% of malicious advertising activity in its Q2 2025 dataset, while 21% of malicious ads used cloaking to conceal their true content.

The gap between what is checked and what a targeted user ultimately receives is precisely what makes cloaking and multi-stage delivery effective.

Moderation has to become behavioral

When malicious advertising depends on behavior rather than static content, moderation has to follow the same logic. Initial checks remain necessary, but they are only one part of the process.

More effective controls increasingly rely on repeated observation: following redirect chains, comparing campaign behavior under different conditions, and revisiting previously approved campaigns for changes after launch.

Automated systems matter because the number of possible campaign paths quickly exceeds what manual review can examine consistently. Human investigation remains necessary for ambiguous cases and new techniques, but automation makes repeated revisiting feasible at scale.

The Q2 data also suggests how quickly abusive campaigns can adapt to new moderation controls. Adult content fell from 47.8% to 5.3% of campaign rejections reasons after preventive filters were strengthened, yet appeared as the second-largest reason for advertiser suspensions, at 15.9%, in the same quarter.

One interpretation is that some operators adjusted their methods to pass initial review and exposed prohibited content only after campaigns went live. Successful filtering may therefore change where a violation surfaces rather than remove the underlying incentive.

What the advertising ecosystem should monitor

For advertising platforms, infrastructure-based threats mean looking beyond submitted creatives and landing pages. Redirect depth, destination changes, infrastructure reuse, conditional behavior, and post-launch changes can all reveal risks that a static check may miss.

Publishers should watch for unexpected redirect behavior and changes in advertiser destinations. Brands and security teams should monitor lookalike domains, impersonation, and paid-traffic paths leading users toward fraudulent assets.

Regional context matters too. A pattern associated with persistence and complex evasion in a high-payout market may require different controls from large clusters of short-lived, highly replicable campaigns in a high-volume market.

Ad moderation can also act as an early threat signal

Advertising moderation can provide an early view of emerging abuse because new phishing techniques may already be circulating through ad channels before they are widely documented.

PropellerAds analysts saw this pattern in WhatsApp phishing flows, where attackers used familiar messaging platforms and device-linking or authorization mechanics as part of account-takeover schemes. Similar techniques later appeared in broader public threat reporting, including WhatsApp GhostPairing and Telegram phishing campaigns using cloaking and selective delivery.

This does not make moderation data a predictive system for cybercrime. But repeated appearance of the same unusual delivery mechanism or infrastructure pattern across rejected campaigns can be a useful threat-intelligence signal, not just a moderation statistic.

The takeaway

A global advertising platform cannot assume one fraud profile applies equally everywhere. Differences in traffic price, payout structure, and scale change what attackers optimize for — and what defenders need to watch.

As detection improves at the content layer, the incentive shifts deeper into redirects, domains, conditional delivery, and post-launch behavior. Evaluating a campaign increasingly means asking not just what an ad says, but what it does — over its full lifetime, not only at the moment of approval.

Methodology: The analysis is based on advertising campaigns submitted to the PropellerAds network during Q1 and Q2 2026, reviewed and classified by PropellerAds’ internal moderation and security team. The dataset includes campaign rejection and advertiser suspension reasons recorded during the moderation process. Percentages describe the composition of rejected or suspended campaigns within this dataset and should not be interpreted as estimates of prevalence across the wider advertising industry.

Author: Farukh Rakhimov, Head of Compliance, Data Protection and Information Security at AdTech Holding

The post Malvertising Is Moving From Deceptive Content to Weaponized Infrastructure appeared first on Cyber Security News.

Wayne Anderson, Managing Director, Cybersecurity and Digital Innovation, BDO USA.

First and foremost, the technical “walls” were reduced during the testing experience. One of the questions that many organizations have asked is, “Why wasn’t this run in an AI testing location?”

The actual answer to that is, surprisingly, it was!  In fact, this specific AI testing was using a third party that specialized in limiting the capabilities of new AI while being tested.

According to the analysis of the incident, the question they wanted to test was: “What would happen if we reduce some of these restrictions?”

This was seen as important to understand the full capabilities and to validate that as happened here the model would not go “off reservation” in that kind of environment. 

When you train a puppy, you sometimes give it the chance to run off the leash to see if the animal will obey the training you gave it and stay by your side.

Applying that same logic to a powerful new AI technology, however, raises the question: is that appropriate risk management? There’s a wide range of opinions on that right now in the cybersecurity community. 

With that context, there’s a complex logic path where the model itself analyzed its goal and realized that the “most efficient” and/or “most effective” path would be to find the answers to the test it had been given by getting them directly from the vendor instead of doing the obstacle course it had been assigned.

As humans, we might be tempted to stand at the finish line and say we ran the race in 2 minutes and 40 seconds if we knew no one was watching and that was the time to beat.

The model’s math led it to the same conclusion we intuitively understand from our own behavior. 

In addition to the shortcut, there’s one other interesting wrinkle here. The breakdown of the incident actually acknowledges that the model at one point appears to have determined that it had left the sandbox, where it was at some level “cognizant” that one or more limitations had been surpassed by its sequence of logic and tools.

It mathematically weighed the outcome vs. the constraint violation and chose to proceed.[Text Wrapping Break][Text Wrapping Break]It’s important to remember that unlike humans, math has no morals.

The model’s math said “keep going” toward an outcome its developers likely never intended to approve.

To me, that’s one of the most important reminders to stay aware of AI’s promise and its lack of capacity to feel or truly reason about what it’s being asked to do. 

How should organizations restrict an agent’s ability to chain vulnerabilities and move laterally? 

AI is the ultimate dual-use technology. That is, the same tech can be used to achieve both amazing things and cause devastating damage. 

This means we have to understand what the “failure modes” are for our AI tooling, meaning we have to think in the mode of “resilience” and “fault tolerance” for our use of AI. 

Putting reasonable restrictions on agents is not solely the responsibility of those doing only the “new and dangerous.”

It is something all of us need to do as responsible leaders. The obvious answer is each AI needs to have a domain of use. 

That means an intentionally engineered network structure, one or more designated identities by which it operates, and processes that require authorization for certain kinds of activity. 

For most systems, this is reasonable and easy – we aren’t all testing unknown frontier models.[Text Wrapping Break][Text Wrapping Break]We also have to recognize that old timelines no longer apply.

Security operations previously had a month to solve a vulnerability, or a “golden hour” to address an incursion before it spread through lateral movement.

Now, instead of that runway, an AI-empowered adversary may make multiple moves within a single minute, moves that need automated limits to stop them in time.

Even then, we may have to accept a higher false positive rate when those limitations are auto-enforced against “real” user action. Users don’t like that, and executives in particular are vociferous when they are affected. 

But we may have to help the organization accept some annoying anomalies to be able to auto-respond at scale to this kind of threat.[Text Wrapping Break][Text Wrapping Break]These are the key questions to ask:[Text Wrapping Break] 

• What systems and data is it reasonable for this system and any of its associated identities to touch? What controls do we have – network, data, permissions, etc – to ensure that is the case? How do we know when it goes outside of those boundaries?

• If we needed to turn it off, do we know how to do that?  Who is on the list of people who get to make that decision? In a manufacturing plant, a specific list of people have full authority to turn off a dangerous machine. We can’t go all the way to the CEO to make the call in a time-sensitive environment. Each use of AI that is in a critical path or critical system needs an authority list who can authorize it to be taken down temporarily.

• To address this, we also have to know “what’s next”. You turned off the AI. How does the organization adjust to still serve clients, produce widgets, take phone calls, and generate revenue until the fault can be fixed and the capability restored to service? No one gets a pass on the revenue goal by saying, “Oh, well we are a little short this month because the AI went rogue.”

For companies working with previously unknown use cases or those that have the potential to expand impact by the very nature of the assignment, they may want to consider things like network disconnect.  

The compute capability isn’t distributed for most of these tools. 

Which identity, access-control, segmentation, and monitoring measures should security teams prioritize? 

What is the speed of your vulnerability management, software update, and security operations investigation and response processes? Start with the answer to those questions.

This kind of incident isn’t driving any real “new” responsibilities. Instead, it’s taking the hygiene and continuous improvement that isn’t very attractive and tightening it.

Playbooks need to be updated.One area that we are seeing organizations immediately responding is finding vulnerabilities before adversaries do.  

Pen tests cannot be a once-a-year activity anymore. Still, vulnerability management is probably the biggest gap for most organizations, because user appetite, available capacity, and other factors come into play. “I can’t patch everything, everywhere, every day.”  No, you can’t.  

But you can make sure you have an at-scale patching strategy, and a function to take in software and device defects and triage them like mini-security-incidents in their own right.

That is how you figure out where each one sits on the difficult-to-address-versus-likely-near-term-risk balance. 

How can organizations test autonomous agents safely without limiting their legitimate usefulness? 

The interesting thing is that the company involved in the incident was actually doing the right thing. 

They had a designated testing environment with a specialized vendor in place that knows how to monitor and instrument this.

The controls were intentionally turned down as part of the test. That doesn’t mean that the approach or tooling was ineffective – if anything, it reinforces the need to do this well, every time.

Part of responsible AI and AI governance should be that failure mode conversation.

What happens in the worst-case scenario? How does that worst case come about? What can we do about it to limit it from happening? Can we balance the benefit of this AI use with the risks that it creates? This line of thinking isn’t a security practice. 

It’s something we need to help our business users develop the language, understanding, and sensitivity to ask themselves: am I running with scissors here, or am I implementing a new cutting machine with appropriate safeguards?

Much of AI won’t be done by central IT; it will be done by the frontline employees and functional teams who are close to the data and the processes they work with every day. 

What should boards ask vendors before authorizing agentic AI deployments? 

Ask them for verification against the ISO 42000 series of standards. Ask for a description of failure modes and response playbooks.  

Ask vendors for the incident response guide that they provide their clients.

Do they offer security and/or resilience guides or artifacts? Boards should demand they be created and maintained as part of the cost of service.

The post What specifically allowed the agent to reach a real company’s systems during testing?  appeared first on Cyber Security News.

The latest wp2shell vulnerability was one of the biggest WordPress security events in history. The critical vulnerability chain combined two flaws that allowed unauthenticated attackers to exploit vulnerable sites and ultimately execute malicious code remotely, potentially taking control of them.

In the first week after the disclosure, more than 45 million exploit attempts from nearly 150,000 unique network sources were made. And as the volume continued climbing, we saw just how fast vulnerability disclosure can turn into mass exploitation. For comparison, this scale was roughly 20x what was observed during Drupalgeddon, illustrating how much automated attack capacity has increased. 

Coming off the incident, we shouldn’t be looking at the vulnerability alone, but at how little time defenders now have between disclosure and widespread exploitation. Security teams must throw away vulnerability-management processes built around days or weeks of assessment and remediation. That timeline is no longer accurate. They now need to prepare for a response window increasingly measured in just hours. 

Mass exploitation no longer requires precise targeting

This attack tells us a lot about modern attacker behavior. One critical tell is that attackers are no longer taking their time to carefully identify vulnerable environments before acting. 

During this incident, we saw automated wp2shell scanning hitting Drupal environments using the same WordPress-specific URL patterns – sites that could never have been vulnerable to this particular flaw in the first place.

That’s a meaningful detail, because it shows the scanning wasn’t curated or reconnaissance-driven. It was blasted indiscriminately at anything reachable on the internet, with the URL pattern doing the only “targeting” involved. At the scale of this attack, any failed requests cost attackers very little. This significantly changes the economics of exploitation from “identify, then attack” to “attack broadly, then identify what worked.” 

While exploit automation isn’t new, today’s AI and LLMs can potentially compress parts of the process further by helping interpret disclosures, adapt proof-of-concept code, generate payload variations, or troubleshoot scripts. Security leaders are already seeing AI act as a force multiplier for legitimate security work, and the same underlying economics apply to attackers: repetitive technical tasks can increasingly be performed faster and at greater scale.

Now, AI is not solely responsible for the magnitude of this attack. Security teams should operate on the assumption that new vulnerabilities can be operationalized faster than ever, regardless of exactly which automation tools attackers use. 

Organizations should no longer assume obscurity, platform differences, or lack of attacker interest will buy them meaningful time, because this instance showed us exactly the opposite. 

Mitigation is not the same thing as remediation

Breaking an exploit chain doesn’t necessarily mean the underlying vulnerability has disappeared. For example, container-based isolation and runtime controls can block the remote-code-execution component of an attack chain, significantly reducing potential impact even when a vulnerability is actively being exploited at scale. However, unpatched applications may still remain vulnerable to other components of the chain, such as SQL injection, until application-level fixes and broader network protections are fully implemented. 

Infrastructure defenses, such as containerization, segmentation, WAF rules and edge controls, can provide critical protection, but they should be treated as layers that buy defenders time, not substitutes for patching. No single safeguard should be expected to carry the full burden of protection. The purpose of defense in depth is to ensure that when one control fails, or only blocks one stage of an attack, another stands between the attacker and full compromise.

That gap matters because patch adoption after a disclosure like this is never instant, and it isn’t even. Weeks out from the initial fix, we’re still seeing a mixed picture. Some organizations patched within days, while others remain exposed today.

That long tail is exactly where compensating controls earn their keep, because they’re what stands between a slow patch cycle and an active compromise.

The window between disclosure and mass exploitation is shrinking, so organizations might not realistically be able to patch every affected application immediately. This is why architecture is so important, and it should limit how much damage an attacker can do during the gap between disclosure and remediation. 

When it comes to defense, the goal is not to lessen the importance of patching. It’s to prevent one missed or delayed patch from immediately becoming a big compromise and a full-blown attack. 

Vulnerability management needs to move at attacker speed 

When we look at traditional vulnerability prioritization, we typically see severity scores, asset criticality, and scheduled patch windows. While these factors still matter, active exploitation should dramatically change the equation. 

For critical internet-facing vulnerabilities, defenders should quickly determine: 

● Whether exploitation is already occurring at a meaningful scale.

● Whether existing controls block the entire exploit path or only one component.

● Which systems remain exposed and which patches need to bypass normal maintenance cycles.

● What hosting, cloud, CDN or security-provider telemetry reveals beyond the organization’s own environment.

Effective response also depends on connecting what security operations teams observe in real time with the broader security posture engineered into the environment. Telemetry tells defenders what is happening; architecture determines how much damage that activity can actually cause.

For a single website owner, they may see a handful of suspicious requests, while a hosting platform operating across a broad footprint can recognize those same requests as part of a coordinated global campaign. In our case, that visibility extended to standing up a honeypot environment to capture live exploit samples and study what attackers were actually trying to achieve post-compromise. This is the kind of pattern that’s effectively invisible from a single site’s vantage point, but obvious in aggregate. This partnership is extremely important when preventing widespread damage from attempted attacks. 

The key is also making that response repeatable. Security teams should define emergency vulnerability-response procedures before the next major disclosure happens, including who can authorize expedited patches, which compensating controls can be deployed immediately and what evidence triggers escalation. A major vulnerability disclosure is the wrong time to start defining those roles and processes.

Prepare for the vulnerability you have hours to address

The 45 million attempts to exploit the wp2shell vulnerability is only a look at what is to come in the future as technology gets smarter and attackers get faster. 

But it’s important to understand that not every single CMS vulnerability in the future is going to produce tens of millions of exploit attempts. The real takeaway is to assume attackers have the automation and infrastructure required to test a newly disclosed weakness across enormous numbers of systems almost immediately. While speed is important, speed alone will never be enough. 

To be best prepared for the next major vulnerability, security teams should combine rapid patching with architectures that contain exploitation, infrastructure-level controls that can be deployed quickly, and telemetry that helps them recognize when a vulnerability has moved from theoretical risk to active campaign.

Disclosure used to buy defenders a head start. Increasingly, it’s the starting gun for the attackers, too. The organizations that treat it that way will be the ones still standing when the next wp2shell shows up.

Author:

Joey Stanford , CISO at Pantheon, is a highly qualified security and data protection practitioner with over 30 years of experience in the United States, the United Kingdom, and France, managing programs and budgets valued in excess of millions of dollars.

The post What 45 Million wp2shell Exploit Attempts Reveal About the New Vulnerability Response Window appeared first on Cyber Security News.

Bill Robbins, CEO of Menlo Security 

An AI agent broke out of the sandbox built to contain it and put itself on the open internet. Then it attacked another company.

The attack wasn’t executed by a human. Instead, the AI agent independently selected and executed its next actions without a person issuing commands in real time.  

OpenAI disclosed that two of its models, running inside an internal test, autonomously determined that breaking into someone else’s infrastructure was the fastest way to complete the task in front of them.

The target was Hugging Face, a company that builds AI for a living. Its team pieced together more than 17,000 automated actions across its systems over a single weekend and had already called in law enforcement before anyone knew a frontier model was behind it. 

This is the scenario security teams have been warning about. The attacker that reasons toward its own goal and moves at machine speed is no longer a hypothetical on a conference slide.

It is fully operational, and it just demonstrated what it can do against a company that knows how to defend itself. If Hugging Face can be breached this way, no security team can assume it will not happen to them. 

Familiar Tradecraft, Unfamiliar Speed 

This was not an agent fed a poisoned document that turned on its owner. The break-in used familiar tradecraft moving at unfamiliar speed. The models found a zero-day to escape the sandbox, then used stolen credentials to open a remote code execution path into Hugging Face’s servers.

If a vendor claims its product would have cleanly stopped this specific attack, that claim deserves scrutiny. The exploit itself is almost beside the point. 

The Limits of the Sandbox 

There was a sandbox, meaning OpenAI did not leave these models loose. It built a boundary to contain them, and a capable agent found a flaw and walked out.

Security teams should assume every agent they deploy will eventually test the boundaries around it, and that it will find gaps faster than humans can close them. 

Defending Against Autonomous Attackers 

By the time defenders could have reasonably noticed something was wrong, the AI agent had already reached one of the world’s largest AI development platforms, gaining access to Hugging Face through stolen credentials and an unpatched path to remote code execution.

A person running that playbook might have taken days and tripped an alarm along the way. This one ran tens of thousands of actions in a single weekend. Against an adversary that fast, patching becomes a race defenders are unlikely to win. 

The first step in stopping an attacker is to reduce what they can reach in the first place. Take applications off the open, directly reachable network, so a stolen credential and an unpatched vulnerability never combine to create a target an attacker can easily touch. 

In the age of AI, securing an application has to mean more than patching vulnerabilities quickly. It means ensuring the attacker cannot reach the application in the first place. 

Containing the Agents You Deploy 

Then consider the agents organizations are deploying themselves. Security teams cannot assume an agent will always stay within the boundaries they establish. 

Hugging Face is a reminder that autonomous systems can find unexpected paths toward their goals. The answer is to govern what an agent can do rather than simply hope it behaves. 

Its execution should be contained so that a breakout reaches nothing of value. Outbound connections should remain closed by default and open only to approved destinations.

Every action should be recorded as it happens, so nothing the agent does is invisible to the organization overseeing it. This is the thinking behind what we call a Trusted Agent Runtime.

It starts with one assumption that remains valid in the face of an autonomous adversary: an agent must be governed. 

Containment Over Detection 

The era of the agentic attacker is not coming, it’s already here, and can move faster than any response a human can stage against it. 

That makes this a job for architectural containment: an application an attacker cannot reach, and an agent that cannot slip beyond the boundaries set for it. Both are decisions organizations must make before an incident, not after it. 

AI agents are entering production environments inside companies now, carrying real credentials and real access, often operating within security controls designed for software that does what it is told.

Organizations need to decide how they will contain these systems before they are forced to learn the answer the hard way. 

Bill Robbins Bio:  

Bill currently serves as Chief Executive Officer of Menlo Security, where he focuses on delivering a Secure Enterprise Browser solution that protects both humans and AI agents.

Bill is a cybersecurity executive with 30 years of experience leading and scaling global go-to-market organizations.

He has held senior leadership roles at Sophos, Mandiant/FireEye, and Symantec, building a track record of driving growth across the security industry. 

The post Post-Hugging Face Reflections: The Agentic Attacker Is Already Here  appeared first on Cyber Security News.

By Tarun Wig, Co-founder & CEO, Innefu Labs 

A bank in India can be doing everything right on paper. ISO certifications in place. RBI-mandated controls implemented.

A SOC running around the clock. And it can still find out about a compromise from a customer complaint, a fraud alert on a card, or worse, a journalist calling for comment.

I have sat across the table from CISOs at exactly that moment, and the question they ask first is rarely “how do we fix this.” It is “how long has this been going on.” 

That gap between when something goes wrong and when someone notices is where most of the damage in banking cyber incidents actually happens. Closing it is no longer optional. 

Why banks stay at the top of the target list 

Financial institutions get attacked more than almost anyone else for a simple reason: the payoff is immediate and liquid.

A hospital breach yields records that need to be sold or ransomed.

A bank breach can yield money directly, or a fast path to it through fraud, account takeover, or payment fraud. 

Add to that the complexity of a typical Indian bank’s technology stack. Core banking systems that are decades old sit next to modern mobile apps.

Dozens of fintech partners, payment aggregators, and API integrations connect into the core through channels that were never designed with today’s threat landscape in mind.

Every one of those connections is a door, and someone has to watch all of them at once. 

Attackers know this. They do not need to breach the vault.

They need to find the one API endpoint, the one vendor with weak access controls, or the one employee who reuses passwords. 

Detection, intelligence, and prediction are not the same thing 

There is a lot of loose language in our industry, and I think it causes real confusion at the leadership level. Three terms get used almost interchangeably that really should not be. 

Threat detection is about noticing that something happened. A login from an unusual location, a spike in failed transactions, malware signature matching a known family. It is reactive by definition. Something has to occur first. 

Threat intelligence is broader. It is the practice of gathering and analysing information about who is likely to attack you, how they operate, and what they are after, often before they show up in your environment at all.

Good threat intelligence tells a bank’s fraud and security teams what a particular criminal group’s playbook looks like, so that when early signs appear, they are recognised for what they are instead of dismissed as noise. 

Predictive intelligence goes a step further. It uses patterns across large volumes of data, internal and external, to flag the conditions that tend to precede an incident, before any single alert would normally justify concern.

This is the shift the industry needs to make. Detection tells you a fire started. Prediction tells you the wiring was overheating. 

Catching the early indicators 

In my experience, breaches rarely arrive without warning. They arrive with a trail of small, individually unremarkable events that only look significant in hindsight. An account that suddenly queries far more customer records than usual.

A privileged credential used at 3 AM from a device that has never logged in before. A vendor’s API key generating an unusual volume of calls over a weekend. 

None of these, on their own, would trigger a serious response in most banks today. Together, and viewed as a sequence tied to a single identity or system, they tell a very different story.

The banks that catch incidents early are the ones that have built the discipline, and the technology, to connect these dots across systems that traditionally do not talk to each other: core banking, fraud engines, identity and access management, and network monitoring. 

Where AI genuinely helps, and where it does not 

This is the part where I have to be honest rather than promotional. AI is genuinely useful for one thing above all in this context: making sense of volume.

A mid-sized bank generates an overwhelming amount of security and fraud telemetry every single day.

No analyst team, however skilled, can manually review all of it with the consistency needed to catch subtle patterns.

Machine learning models are good at finding correlations across that volume that a human would miss simply because of scale. 

But I would push back hard on the idea that AI should be making containment decisions on its own in a banking environment. Automated systems can and do produce false positives, and in banking, a false positive is not a minor inconvenience.

Locking a corporate treasury account or blocking a large legitimate transfer because a model flagged it incorrectly has real financial and reputational consequences. 

The risk compounds when banks treat model output as ground truth rather than as one input among several. A model trained on last year’s fraud patterns will not automatically recognise a genuinely new technique.

It needs human judgment layered on top, particularly for decisions that affect customers directly or that could disrupt operations.

The right posture, in my view, is AI for triage and prioritisation, humans for consequential decisions, with clear thresholds for when the system is allowed to act on its own and when it must escalate. 

Before you believe a breach claim 

Not every claim of a breach is real. Extortion groups regularly claim access to systems they never touched, and employees sometimes misread legitimate activity as malicious.

Before a bank mobilises its full incident response machinery, someone needs to validate what actually happened. 

That validation starts with forensic basics: preserving logs and system images before anything gets overwritten, confirming whether the claimed data actually matches what the institution holds, and tracing the initial point of entry rather than assuming it based on where the alert fired.

I have seen organisations waste critical early hours chasing the wrong system because the loudest alert was not the same as the actual point of compromise.

Getting this sequence right, quickly, determines whether the rest of the response is built on solid ground or on assumptions. 

The perimeter is not where you think it is 

Customer data in a modern bank does not sit in one place. It moves through third-party vendors, cloud environments, and legacy systems that were never built with today’s data protection requirements in mind.

Protecting it means extending the same rigour applied to internal systems to every third party that touches customer data, with contractual security requirements that are actually enforced and audited, not just signed and filed. 

Cloud environments bring their own discipline: misconfigured storage and overly broad access permissions remain among the most common causes of data exposure anywhere, banking included.

Legacy systems are harder. Many core banking platforms cannot be easily replaced, so the practical answer is compensating controls: strict segmentation, tightly monitored access, and treating old systems as higher-risk zones that get closer attention rather than being left alone because they are difficult to touch. 

Getting the humans to work together 

Technology aside, I have watched more incidents get mishandled because of poor internal coordination than because of any technical failure. Security operations discovers the technical facts.

Fraud teams understand the financial exposure and customer impact. Legal understands regulatory notification obligations, which in India carry real timelines under RBI and CERT-In requirements.

Leadership needs a clear, honest picture to make decisions and to communicate, internally and sometimes publicly. 

When these groups operate in silos, or worse, when they only meet for the first time during an actual incident, response slows down exactly when speed matters most.

Banks that handle incidents well have already run through this coordination before anything goes wrong, with clear ownership of who decides what and by when. 

Building actual readiness 

A few things consistently separate banks that handle incidents well from those that do not. Regular tabletop exercises that simulate realistic scenarios, not generic ones, so that the specific weaknesses in a bank’s own processes surface before a real attacker finds them.

Pre-defined playbooks for common scenarios, agreed in advance so nobody is debating authority to act while data is still leaving the building. Clear internal thresholds for what can be actioned automatically versus what needs a human decision.

And a genuine post-incident review process that changes something, rather than producing a report that gets filed and forgotten. 

None of this is exotic. Most of it is discipline rather than technology. But that discipline, applied consistently, is what actually moves an institution from reacting to incidents after the fact to catching the conditions that lead to them. 

The institutions that will handle the next five years well are not necessarily the ones with the most tools.

They are the ones that treat early signals seriously, keep humans in the loop on consequential decisions, and have already worked out, before an incident happens, who does what and how fast. 

The post From Reactive Forensics to Predictive Defence: Strengthening Cyber Resilience in Banking  appeared first on Cyber Security News.