The developer security company has raised a total of more than $84 million in funding.

The post Aikido Security Raises $60 Million at $1 Billion Valuation appeared first on SecurityWeek.

Novee provides continuous AI-driven penetration testing to uncover and address novel vulnerabilities.

The post Novee Emerges From Stealth With $51.5 Million in Funding appeared first on SecurityWeek.

Some attackers are increasingly moving away from simple redirects in favor of more “selective” methods of payload delivery. This approach filters out regular human visitors, allowing attackers to serve malicious content to search engine crawlers while remaining invisible to the website owner.

What did we find?

During a malware investigation, we identified a selective content injection attack inside the main index.php file of a WordPress website.

Instead of always loading WordPress normally, this modified file checks who is visiting the site.

Continue reading Malware Intercepts Googlebot via IP-Verified Conditional Logic at Sucuri Blog.

AI will assist companies in finding their external attack surface, but it will also assist bad actors in locating and attacking the weak points.

The post Cyber Insights 2026: External Attack Surface Management appeared first on SecurityWeek.

Thanks to the convenience of NFC and smartphone payments, many people no longer carry wallets or remember their bank card PINs. All their cards reside in a payment app, and using that is quicker than fumbling for a physical card. Mobile payments are also secure — the technology was developed relatively recently and includes numerous anti-fraud protections. Still, criminals have invented several ways to abuse NFC and steal your money. Fortunately, protecting your funds is straightforward: just know about these tricks and avoid risky NFC usage scenarios.

What are NFC relay and NFCGate?

NFC relay is a technique where data wirelessly transmitted between a source (like a bank card) and a receiver (like a payment terminal) is intercepted by one intermediate device, and relayed in real time to another. Imagine you have two smartphones connected via the internet, each with a relay app installed. If you tap a physical bank card against the first smartphone and hold the second smartphone near a terminal or ATM, the relay app on the first smartphone will read the card’s signal using NFC, and relay it in real time to the second smartphone, which will then transmit this signal to the terminal. From the terminal’s perspective, it all looks like a real card is tapped on it — even though the card itself might physically be in another city or country.

This technology wasn’t originally created for crime. The NFCGate app appeared in 2015 as a research tool after it was developed by students at the Technical University of Darmstadt in Germany. It was intended for analyzing and debugging NFC traffic, as well as for education purposes and experiments with contactless technology. NFCGate was distributed as an open-source solution and used in academic and enthusiast circles.

Five years later, cybercriminals caught on to the potential of NFC relay and began modifying NFCGate by adding mods that allowed it to run through a malicious server, disguise itself as legitimate software, and perform social engineering scenarios.

What began as a research project morphed into the foundation for an entire class of attacks aimed at draining bank accounts without physical access to bank cards.

A history of misuse

The first documented attacks using a modified NFCGate occurred in late 2023 in the Czech Republic. By early 2025, the problem had become large scale  and noticeable: cybersecurity analysts uncovered more than 80 unique malware samples built on the NFCGate framework. The attacks evolved rapidly, with NFC relay capabilities being integrated into other malware components.

By February 2025, malware bundles combining CraxsRAT and NFCGate emerged, allowing attackers to install and configure the relay with minimal victim interaction. A new scheme, a so-called “reverse” version of NFCGate, appeared in spring 2025, fundamentally changing the attack’s execution.

Particularly noteworthy is the RatOn Trojan, first detected in the Czech Republic. It combines remote smartphone control with NFC relay capabilities, letting attackers target victims’ banking apps and cards through various technique combinations. Features like screen capture, clipboard data manipulation, SMS sending, and stealing info from crypto wallets and banking apps give criminals an extensive arsenal.

Cybercriminals have also packaged NFC relay technology into malware-as-a-service (MaaS) offerings, and reselling them to other threat actors through subscription. In early 2025, analysts uncovered a new and sophisticated Android malware campaign in Italy, dubbed SuperCard X. Attempts to deploy SuperCard X were recorded in Russia in May 2025, and in Brazil in August of the same year.

The direct NFCGate attack

The direct attack is the original criminal scheme exploiting NFCGate. In this scenario, the victim’s smartphone plays the role of the reader, while the attacker’s phone acts as the card emulator.

First, the fraudsters trick the user into installing a malicious app disguised as a banking service, a system update, an “account security” app, or even a popular app like TikTok. Once installed, the app gains access to both NFC and the internet — often without requesting dangerous permissions or root access. Some versions also ask for access to Android accessibility features.

Then, under the guise of identity verification, the victim is prompted to tap their bank card to their phone. When they do, the malware reads the card data via NFC and immediately sends it to the criminals’ server. From there, the information is relayed to a second smartphone held by a money mule, who helps extract the money. This phone then emulates the victim’s card to make payments at a terminal or withdraw cash from an ATM.

The fake app on the victim’s smartphone also asks for the card PIN — just like at a payment terminal or ATM — and sends it to the attackers.

In early versions of the attack, criminals would simply stand ready at an ATM with a phone to use the duped user’s card in real time. Later, the malware was refined so the stolen data could be used for in-store purchases in a delayed, offline mode, rather than in a live relay.

For the victim, the theft is hard to notice: the card never left their possession, they didn’t have to manually enter or recite its details, and the bank alerts about the withdrawals can be delayed or even intercepted by the malicious app itself.

Among the red flags that should make you suspect a direct NFC attack are:

• prompts to install apps not from official stores;
• requests to tap your bank card on your phone.

The reverse NFCGate attack

The reverse attack is a newer, more sophisticated scheme. The victim’s smartphone no longer reads their card — it emulates the attacker’s card. To the victim, everything appears completely safe: there’s no need to recite card details, share codes, or tap a card to the phone.

Just like with the direct scheme, it all starts with social engineering. The user gets a call or message convincing them to install an app for “contactless payments”, “card security”, or even “using central bank digital currency”. Once installed, the new app asks to be set as the default contactless payment method — and this step is critically important. Thanks to this, the malware requires no root access — just user consent.

The malicious app then silently connects to the attackers’ server in the background, and the NFC data from a card belonging to one of the criminals is transmitted to the victim’s device. This step is completely invisible to the victim.

Next, the victim is directed to an ATM. Under the pretext of “transferring money to a secure account” or “sending money to themselves”, they are instructed to tap their phone on the ATM’s NFC reader. At this moment, the ATM is actually interacting with the attacker’s card. The PIN is dictated to the victim beforehand — presented as “new” or “temporary”.

The result is that all the money deposited or transferred by the victim ends up in the criminals’ account.

The hallmarks of this attack are:

• requests to change your default NFC payment method;
• a “new” PIN;
• any scenario where you’re told to go to an ATM and perform actions there under someone else’s instructions.

How to protect yourself from NFC relay attacks

NFC relay attacks rely not so much on technical vulnerabilities as on user trust. Defending against them comes down to some simple precautions.

• Make sure you keep your trusted contactless payment method (like Google Pay or Samsung Pay) as the default.
• Never tap your bank card on your phone at someone else’s request, or because an app tells you to. Legitimate apps might use your camera to scan a card number, but they’ll never ask you to use the NFC reader for your own card.
• Never follow instructions from strangers at an ATM — no matter who they claim to be.
• Avoid installing apps from unofficial sources. This includes links sent via messaging apps, social media, SMS, or recommended during a phone call — even if they come from someone claiming to be customer support or the police.
• Use comprehensive security on your Android smartphones to block scam calls, prevent visits to phishing sites, and stop malware installation.
• Stick to official app stores only. When downloading from a store, check the app’s reviews, number of downloads, publication date, and rating.
• When using an ATM, rely on your physical card instead of your smartphone for the transaction.
• Make it a habit to regularly check the “Payment default” setting in your phone’s NFC menu. If you see any suspicious apps listed, remove them immediately and run a full security scan on your device.
• Review the list of apps with accessibility permissions — this is a feature commonly abused by malware. Either revoke these permissions for any suspicious apps, or uninstall the apps completely.
• Save the official customer service numbers for your banks in your phone’s contacts. At the slightest hint of foul play, call your bank’s hotline directly without delay.
• If you suspect your card details may have been compromised, block the card immediately.

Forty years ago, The Mentor—Loyd Blankenship—published “The Conscience of a Hacker” in Phrack.

You bet your ass we’re all alike… we’ve been spoon-fed baby food at school when we hungered for steak… the bits of meat that you did let slip through were pre-chewed and tasteless. We’ve been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us willing pupils, but those few are like drops of water in the desert.

This is our world now… the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt-cheap if it wasn’t run by profiteering gluttons, and you call us criminals. We explore… and you call us criminals. We seek after knowledge… and you call us criminals. We exist without skin color, without nationality, without religious bias… and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it’s for our own good, yet we’re the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

In an era marked by escalating cyber threats and evolving risk landscapes, organisations face mounting pressure to strengthen their security posture whilst maintaining seamless user experiences. At Thales, we recognise that robust security must be foundational – embedded into products and services by design, not bolted on as an afterthought. This principle underpins our commitment to the U.S. Cybersecurity and Infrastructure Security Agency (CISA)’s Secure-by-Design pledge, which calls on software manufacturers to establish security features like multi-factor authentication (MFA) as standard across their product portfolios.

As digital transformation accelerates and attack surfaces expand, the gap between security capabilities and emerging threats continues to widen. According to the 2025 Thales Data Threat Report, organisations are grappling with unprecedented challenges: 69% regard the fast-moving ecosystem as the most concerning GenAI security risk, whilst 83% report that strong MFA is used more than 40% of the time. This indicates both progress and significant opportunity for improvement. These findings underscore a critical reality: whilst security tools and technologies have advanced, comprehensive deployment and consistent enforcement remain essential challenges that demand immediate attention.

This blog examines the pivotal role of multi-factor authentication in modern cybersecurity strategies. We explore the fundamentals of MFA, analyse the evolving threat landscape that necessitates its adoption, and provide practical guidance on implementation. Whether you are a security professional seeking to strengthen your organisation’s defences or an individual user looking to protect personal accounts, this resource offers the insights and actionable steps needed to embrace MFA with confidence and rigour.

Understanding Multi-Factor Authentication: The Basics

Multi-factor authentication verifies your identity using two different forms of identification. Typically this involves something you know (like a password) and something you have (like a code on your phone). Think of it like using an ATM: you need both your bank card and your PIN to withdraw cash.

This dual-layer approach creates a significant barrier for attackers. Even if someone steals your password, they still can’t log in without that second factor. It’s elegantly simple, yet remarkably powerful – your password alone is no longer enough to unlock the door.

The Growing Threat Landscape: Why MFA Is No Longer Optional

Cyberattacks have grown increasingly sophisticated, with stolen passwords at the heart of many breaches. According to the 2023 Verizon Data Breach Investigations Report, nearly 49% of data breaches involved the use of stolen credentials.

MFA directly addresses this vulnerability. Our own research at Thales demonstrates the critical importance of strong authentication measures. According to the 2025 Thales Data Threat Report, 83% of organisations report that strong MFA is used more than 40% of the time, yet significant challenges remain in achieving comprehensive deployment. This data underscores both the growing recognition of MFA’s importance and the continued need for organisations to strengthen their authentication posture.

Furthermore, our 2025 Digital Trust Index – Third-Party Edition reveals a concerning reality: 40% of users reset passwords once or twice a month, highlighting the inherent weakness of password-only authentication systems. These frequent password resets not only frustrate users but also create security vulnerabilities that MFA effectively mitigates.

How MFA Defeats Common Attack Methods

MFA thwarts the most prevalent attack techniques:

Brute-force and credential stuffing attacks: These automated attacks become practically futile with MFA enabled because guessing the password isn’t enough to break in.

Phishing attacks: Even if you unwittingly hand over your password to a phisher, they still can’t access your account without the one-time code or second factor that MFA requires.

It’s no surprise that CISA’s Secure-by-Design guidelines explicitly call for making MFA a built-in, default security feature. In today’s threat landscape, MFA has evolved from a nice-to-have extra to an essential safeguard.

Thales’ Commitment: Security by Design and by Default

At Thales, we build security into our products by design, baked into our products and services. Our commitment to CISA’s Secure-by-Design pledge is reflected in how we develop features like MFA.
We already implement robust MFA across our cloud services to help safeguard your accounts and data. By requiring two forms of identification to access the Thales Cloud Security Console, we add an extra layer of protection that makes it “much harder for unauthorised users to access sensitive information”. This significantly reduces the risk of breaches and builds trust.

The Principle of Shared Responsibility

Thales’ approach recognises shared responsibility. “Security by default” means we provide secure settings and features right out of the box. However, security is also a partnership – we provide the tools, whilst you play a crucial role by using them.
We’ve made MFA available and straightforward to configure, and we actively encourage customers to use advanced authentication methods. Whilst MFA might not be mandated on all accounts by default today, we strongly recommend that you activate it. By choosing to enable MFA now, you’re not only protecting yourself immediately but also aligning with best practices that Thales and the cybersecurity community advocate globally.

Getting Started: How to Set Up MFA

Enabling multi-factor authentication on your Thales account is quick and straightforward. Here’s how:

1. Log in and navigate to your user settings. Go to Account Settings or Profile, where you’ll find security settings for MFA management. You can find these options in the Thales Cloud Security Console setup checklist.
2. Locate the Multi-Factor Authentication option and click to begin setup.
3. Select your preferred MFA method: authenticator app, SMS, or email.
4. Configure the chosen method:
   • For an authenticator app, scan the displayed QR code with your app ( MobilPASS+, Google Authenticator, Microsoft Authenticator, Authy, etc.).
   • For SMS, enter your mobile number to receive a verification code.
   • For email, a code will be sent to your registered email address.
5. Save your backup codes. These are your safety net if you lose access to your MFA device. Store them in a secure location like a password manager.
6. Complete and test the setup. Once verified, MFA will be enabled. Log out and log in again to ensure everything works properly.

That’s it! You’ve added a powerful extra layer of security in just a few minutes.

Choosing Your MFA Method: A Comparison

For organisations seeking a comprehensive overview of authentication options, Thales offers an extensive portfolio of MFA tokens and authenticators. Our OneWelcome Authenticators Portfolio includes FIDO2 passkeys, hardware tokens, smart cards, and software authenticators, ensuring secure access across different environments and devices . This breadth of choice allows organisations to select the authentication method best suited to their security requirements and user needs

When setting up MFA, you have several authentication options:

Authenticator App (recommended): Generates a new 6-digit code every 30 seconds. This method is very secure, works offline, and is significantly more phishing-resistant. Pros: High security, no network dependency. Cons: Requires your phone.

Text Message (SMS): Sends a one-time code to your mobile phone. Pros: Easy to use, no app required. Cons: Slightly less secure than authenticator apps due to potential SIM-swapping attacks, but still greatly improves security over no MFA. CISA recommends SMS-based authentication only as a “last resort” when more secure options aren’t available

Email Codes: Sends verification codes to your registered email. Pros: No extra device needed. Cons: Least secure option if your email is compromised. Use only if other methods aren’t feasible, and ensure your email itself has MFA.

Hardware Security Keys: Physical devices, such as Thales FIDO Security Keys that you plug in or tap to verify login. Pros: Highest level of security, phishing-resistant. Cons: Requires purchasing a device.

Which should you choose? If possible, use an authenticator app or hardware key, as these are most secure. For most users, an authenticator app strikes an excellent balance. SMS is a solid fallback, and email can work if necessary – just be aware of the security trade-offs.

Moving Beyond Passwords: Passwordless Authentication

Whilst MFA significantly strengthens security, the most forward-thinking organisations are taking the next step: eliminating passwords altogether. Passwordless authentication removes the vulnerabilities inherent in password-based systems – no passwords to steal, phish, or reuse.

Thales’ SafeNet Trusted Access empowers organisations to build comprehensive passwordless policies using FIDO2 passkeys, biometrics, and hardware authenticators. Our Passwordless 360 approach provides a detailed framework for implementing passwordless authentication across your organisation, combining security, user experience, and regulatory compliance.

Troubleshooting and Frequently Asked Questions

Q: Do I have to enter an MFA code every single time I log in?
A: Often not every time. Many systems offer the option to “remember” a device for a certain period (e.g., 14 days). This means you won’t need to enter a code each time on that trusted device. However, use this feature only on personal devices you control, not shared or public computers.

Q: I’m not receiving the MFA code, or it says the code is wrong. What should I do?
A: Common solutions include: For SMS, check your signal and that your phone number is correct in account settings. Wait a moment and click “Resend code” if available. For authenticator apps, ensure your phone’s clock is accurate, as codes are time-based. For email, check your spam folder.

Q: What if I lose access to my phone or MFA device?
A: Use your saved backup codes to log in. If you’ve lost those as well, contact Thales support for account recovery assistance.

Q: Can we use our own IdP?
A: Yes, you can leverage external IdPs like SafeNet Trusted Access by Thales, which allows you to build adaptive authentication policies and leverage a broad range of MFA options.

Q: Can I switch MFA methods?
A: Yes. You can disable MFA and re-enable it with a new method anytime through your account settings.

Q: Is MFA required?
A: Whilst not mandatory on all accounts today, we strongly recommend enabling it. It’s one of the most effective ways to protect your account.

Understanding Digital Trust: Research from Thales

Thales’ research demonstrates the critical importance of strong identity and access management. Our 2025 Digital Trust Index – Third-Party Edition reveals that 96% of third-party users face issues logging into partner systems, wasting 48 minutes a month on average. Additionally, 40% reset passwords once or twice a month – highlighting the need for more secure, passwordless methods like MFA.

The 2025 Data Threat Report further emphasises this urgency. According to our research, 83% of organisations report that strong MFA is used more than 40% of the time, yet challenges remain. As organisations adopt AI and face evolving quantum threats, robust authentication becomes even more critical.

Thales’ comprehensive Identity and Access Management solutions provide organisations with the capabilities needed to improve user experiences whilst strengthening security. From Multi-Factor Authentication and Single Sign-On to passwordless authentication and passkeys, Thales delivers the tools to make IAM processes straightforward and dependable.

Final Thought

Cybersecurity is a shared responsibility. We design secure systems, and you make them stronger by turning on protections like MFA. Enable MFA today in your Thales account settings. It takes just a few minutes and makes a significant difference.

Secure by design starts with secure choices.

The post Security by Design: Why Multi-Factor Authentication Matters More Than Ever appeared first on Blog.

The surge in AI-driven traffic is transforming how websites manage their content. With AI bots and agents visiting sites at unprecedented rates (often scraping without permission, payment, or attribution) content owners face a critical challenge: how to protect their intellectual property while capitalizing on legitimate AI use cases.

Today, we’re excited to announce Imperva’s integration with TollBit, a groundbreaking solution that enables our Cloud Web Application Firewall (CWAF) customers to monetize traffic from AI bots and crawlers that would otherwise scrape their content without permission or compensation.

Meeting the AI Traffic Challenge

The traditional ad-supported and subscription-based content models are being disrupted by AI. This integration provides a new economic model where value flows fairly between content creators and AI developers, transforming unauthorized scraping into a sustainable revenue stream.

How Imperva and TollBit Work Together

The integration leverages Imperva’s industry-leading Web Application Firewall capabilities alongside TollBit’s analytics and monetization platform to create a comprehensive solution:

1. Detection & Enforcement: Imperva CWAF identifies AI bot traffic at the edge, providing the critical first layer of protection.
2. Intelligent Redirection: Using Imperva’s redirect rules, requests from AI bots are automatically redirected to a TollBit subdomain (e.g., tollbit.example.com), with CWAF returning an HTTP 302 response.
3. Payment Gateway: The TollBit subdomain returns an HTTP 402 response code (payment required), prompting AI bot operators to obtain valid TollBit tokens for authorized access.
4. Analytics & Insights: Through SIEM log integration, Imperva Access and Security logs flow to TollBit’s analytics engine, providing executives with clear, AI-specific analytics that show how bots are engaging with their content and the business impact of that traffic both within Tollbit and Imperva’s UMC.

Implementation Architecture

The integration requires a straightforward setup process:

• Onboard your domain to Imperva Cloud WAF
• Create a TollBit account and verify domain ownership via DNS TXT records
• Configure a TollBit subdomain with appropriate DNS NS records
• Create redirect rules in Imperva’s management console to route AI bot traffic
• Set up AWS S3 bucket integration for log processing and analytics

To ensure compatibility with TollBit’s requirements, an AWS Lambda function prefixes dates to Imperva log file names, enabling seamless ingestion into TollBit’s analytics platform.

A Shared Vision for Fair Compensation

This partnership represents a fundamental shift in how content owners approach AI traffic. Rather than simply blocking all bots or allowing unrestricted scraping, sites now have granular control to enforce access rules and pricing on their own terms.

Content owners deserve fair compensation for how their content powers the AI ecosystem. By combining Imperva’s security capabilities with TollBit’s monetization tools, we’re enabling the transition from unauthorized scraping to sustainable, licensed transactions.

What This Means for Imperva Customers

With this integration, Imperva CWAF customers gain:

• Robust protection against unauthorized AI scraping at the application layer
• Complete visibility into AI traffic patterns and behaviors through dedicated analytics
• Flexible control to decide which AI agents can access content and under what conditions
• New revenue streams that turn scraping attempts into legitimate, paid transactions

The agent economy is here, and autonomous AI visitors are becoming a permanent fixture of web traffic. With Imperva and TollBit, you can ensure these interactions happen on your terms—fairly, transparently, and profitably.

Get Started

If you’re an Imperva Cloud WAF customer and want to activate the integration:

• Create your own Tollbit account on the TollBit platform https://app.tollbit.com/sign-up.
• Create custom rules in the Imperva Cloud WAF platform as instructed in the TollBit Docs.

TollBit is free for publishers and websites so you can be up and running in no time.

Learn more about how Imperva’s integration with TollBit can help you protect and monetize your content in the AI era.

The post Imperva Partners with TollBit to Power AI Traffic Monetization for Content Owners appeared first on Blog.

The more critical APIs become, the more sensitive data they carry identities, payment details, health records, customer preferences, tokens, keys, and more.

And this is where organizations face a painful, often invisible problem:

To protect APIs, many organizations end up exposing the very data they are trying to secure.

Most API security tools still rely on raw-payload logging, traffic replay, or shipping full request bodies into external analytics systems. That means sensitive customer data:

• Leaves controlled environments
• Gets stored in multiple systems
• Crosses borders without intention
• Lands in tools not designed to hold PII
• Multiplies breach risk and regulatory pressure

This creates a direct conflict between security, privacy, and compliance, and businesses are caught in the middle.

The Real-World Impact: When Privacy Becomes a Security Liability

Across industries – financial services, retail, healthcare, travel, public sector, the story repeats:

1. Breach blast radius expands

The more systems that hold raw API payloads, the bigger the impact when any one of them is compromised.

2. Compliance becomes harder, not easier

GDPR, CCPA, HIPAA, PCI, and emerging data-sovereignty regulations penalize:

• unnecessary data retention
• cross-border data transfers
• third-party exposure
• lack of data-minimization controls

Most API security tools inadvertently violate all four.

3. Data residency rules block API security deployments

Organizations operating in multiple regions can’t centralize raw API data in a single cloud service, but many tools require doing exactly that.

4. Dev and QA environments become privacy risks

When security tests are based on production payload replays, sensitive data leaks into non-production systems.

5. Security teams lose visibility if they avoid raw logging

Many leaders try to “lock down” data flows, but that often leaves API blind spots, making it harder to detect business logic abuse, scraping, or session-based attacks.

This is the API privacy paradox:
You either weaken privacy to strengthen security or weaken security to preserve privacy.

The Industry Approach Is Broken

The traditional API security model makes three flawed assumptions:

1. You must log or store raw payloads to get visibility.
2. You must centralize traffic for analytics.
3. You must replay production data to test API security.

These assumptions create privacy exposure, compliance failure, and operational friction.

Imperva Solves This by Rethinking the Architecture

Imperva’s privacy-first, local-first platform was built around a core belief:

API security should not require exposing sensitive data, ever.

The architecture flips the traditional model:

1. Inspect at the PoP (where traffic lives)

Traffic is parsed in-memory at the Point-of-Presence closest to the application, SaaS PoP or on-prem.

Raw values never leave the PoP.

2. Convert sensitive values into privacy-safe artifacts

Classification + hashing replaces raw payloads with:

• label
• schema fragments
• one-way irreversible hashes
  This is the only data that ever moves upstream.

3. Detect and respond using metadata only

Anomaly detection uses metadata such as:

• data labels
• schema context
• session identifiers
• hashed tokens

No raw content is needed or exposed.

4. Enforce using hashes, not identities

Hash-based enforcement enables:

• per-session blocking
• token-level mitigation
• behavior-based decisions
  without seeing or sharing the sensitive value behind the hash.

5. Same privacy guarantees across all deployments

Cloud, on-prem, hybrid – the mechanics never change.

What This Means for the Business

This is where Imperva’s architecture translates directly into measurable, enterprise-wide value:

Smaller blast radius = lower breach liability

Fewer systems hold PII, drastically reducing what attackers can steal and what you must disclose.

Faster compliance alignment

Local data processing and zero raw persistence align with GDPR, HIPAA minimum-necessary, and sovereignty rules.

Real-time protection with zero added exposure

Inline, in-PoP inspection gives detection teams full visibility without raw payload retention.

Safer automation in Dev/QA

Privacy-aware test artifacts eliminate the risk of production PII leaking into pipelines.

Reduced third-party risk

Vendors never receive raw payloads, only metadata and hashes.

A future-proof privacy posture

As regulatory pressure increases, architectures like this become mandatory, not optional.

Why This Whitepaper Matters

This whitepaper breaks down exactly how Imperva delivers production-grade API protection while preserving privacy, with clear explanations and practical examples.

You’ll learn:

• How to get deep visibility without storing raw payloads
• Why in-PoP processing reduces exposure and simplifies compliance
• How hash-based enforcement protects identities while enabling precise blocking
• How to design a privacy-first architecture that works across hybrid/multi-cloud

In other words:
If you need to secure APIs and meet privacy, residency, or compliance requirements – this is essential reading.

Ready to See How Privacy-First API Security Really Works?

Download the whitepaper and learn how Imperva protects APIs without exposing sensitive data.

The post The Privacy Gap in API Security: Why Protecting APIs Shouldn’t Put Your Data at Risk appeared first on Blog.

The holiday shopping season is the busiest time of year for online retailers, and increasingly the most dangerous. As traffic surges and customers rush to place orders, cybercriminals use the distraction and volume to blend in. Account Takeover (ATO) attacks spike sharply in November and December, targeting shoppers’ saved payment details, loyalty points, wish-lists, and personal data.

Most retailers focus on keeping sites fast and campaigns running smoothly, but this seasonal pressure creates blind spots in authentication, login flows, and Application Programming Interface API endpoints. Attackers know this and use automated tools and AI-driven bots to slip into accounts with little resistance.

During peak season, it doesn’t take long for an unnoticed credential-stuffing surge, or a burst of suspicious login attempts to translate into real financial loss and customer frustration. For many retailers, the challenge isn’t a dramatic breach, it’s the quiet, persistent account abuse that goes undetected until the damage is already done.

The Escalation of Account Takeover Attacks

According to the 2025 Imperva Bad Bot Report, Account Takeover attacks increased by 40 percent in 2024 and by more than 50 percent since 2022. The rise reflects the expanding attack surface of modern digital businesses and the increasing availability of stolen credentials.

ATO attacks are rarely brute force assaults in the traditional sense. Most rely on automation and intelligence. Attackers use:

• Credential stuffing to test stolen username and password pairs obtained from prior data breaches
• Credential cracking to predict likely passwords using AI or dictionary-based guessing techniques
• Brute force attacks to systematically attempt all possible combinations where no prior credential data exists

Each of these techniques is enhanced by bot networks capable of emulating legitimate traffic and distributing attacks across thousands of IP addresses to avoid detection.

Once an account is compromised, attackers can alter stored payment details, redeem loyalty points, exfiltrate personal data, or pivot into connected systems through single sign on integrations. The damage can be widespread and difficult to undo, making remediation costly, complex, and often too late to fully protect the victim.

The Cost of Compromise

A successful Account Takeover is not just a security failure; it is a business crisis. The consequences cascade across financial, regulatory, and reputational dimensions.

• Financial loss from fraud, chargebacks, and stolen assets
• Operational disruption as security and customer support teams manage lockouts and resets
• Regulatory exposure under privacy and data protection laws such as GDPR, CCPA, and PCI DSS
• Legal costs and compensation claims from affected customers or partners
• Reputational damage leading to customer attrition and reduced trust

Regulators increasingly view inadequate protection of user credentials as a preventable failure. In industries such as financial services, retail, and telecom, where digital identity underpins customer engagement, the stakes are exceptionally high.

The AI Advantage for Attackers

Artificial intelligence is amplifying both the scale and sophistication of ATO campaigns. Where brute force once relied purely on volume, AI brings adaptive learning and behavioural mimicry.

Modern credential stuffing bots now simulate human navigation, introduce artificial pauses, and mirror typing patterns to bypass rate limits and behavioural detection systems. Machine learning

models trained on breached data can predict likely password sequences based on language, demographics, and prior password resets.

This capability turns traditional defences into speed bumps rather than barriers. The result is faster, more evasive attacks that require intelligent, context aware countermeasures.

The Expanding API Attack Surface

As organizations modernize applications, APIs have become both essential and exposed. They connect services, mobile clients, and third-party integrations, and they now represent a primary conduit for identity and data access.

According to Imperva telemetry, around 12 percent of all API attacks in 2024 were Account Takeovers. Many of these attacks are low volume and high value, designed to evade detection. Attackers harvest sensitive information in small increments such as user identifiers, loyalty balances, and payment tokens, and use that data later for large scale fraud or identity theft.

During the holiday shopping season, attackers take advantage of the fact that retail systems are under more pressure and handling far more automated traffic than usual. Bots are designed to blend seamlessly into this activity. They mimic real customers using legitimate browsers, realistic headers, and correctly formatted API calls, which makes them difficult to distinguish from genuine shoppers.

Instead of triggering obvious high-volume spikes, attackers quietly test stolen credentials across login APIs, probe authentication flows, and map out which accounts are valid. They reuse tokens, exploit weak session handling, and launch credential stuffing campaigns at a pace that fits naturally within peak season traffic. Because the requests look structurally correct, they often bypass volumetric detection and slip past basic rate limits.

Once inside an account, automated scripts extract loyalty balances, change delivery addresses, modify stored payment methods, or pivot through single sign on to gain access to additional services. For many retailers, these subtle API driven attacks are now the fastest growing source of credential-based compromise, and they reach their highest risk in November and December.

Thales recommends:

1. Improve visibility across login traffic this holiday season

During peak shopping periods, login volumes surge and attackers use the noise to hide. Monitor login attempts, unusual session behaviour, device changes, and repeated failures so you can spot suspicious activity early.

2. Strengthen authentication without slowing real customers

Shoppers expect fast checkout experiences, especially during sales events. Use smarter authentication controls that react to risk signals such as new devices or sudden spikes in login attempts, while keeping the journey seamless for genuine users.

3. Protect high value pages such as login and checkout

These are the most heavily targeted points during the holiday rush. Account Takeover attacks often begin on the login page and escalate at checkout. Ensure these flows have the strongest monitoring and protection in place to detect unusual behaviour before accounts are compromised.

4. Secure all APIs involved in customer accounts and orders

Retailers rely on APIs for login, checkout, loyalty, order history, and account management. These endpoints see huge traffic increases in November and December, making them prime targets for automated abuse. Apply full visibility and security controls across them.

5. Deploy Advanced Bot Protection to stop automated ATO attempts

Bots spike dramatically during holiday promotions. Advanced bot protection identifies and blocks automated credential testing, scripted login attempts, and account probing in real time without adding friction for real shoppers. This is critical for preventing ATO during your busiest weeks.

Visit Imperva.com Account Takeover Protection.

The post ’Tis the Season to Be Cyber-Wary: How Thales Protects Against Account Takeover During Peak Shopping Season appeared first on Blog.

Every November and December, online retailers gear up for their biggest revenue surge of the year. But while the traffic and transactions climb, so does the threat level. Cybercriminals know exactly when customer activity (and the pressure on retail systems) is at its highest and they’re automating their attacks to exploit it.

Why retailers are especially vulnerable during peak season

Large-scale bot attacks thrive in seasonal retail: high traffic, elevated checkout volume, heavy promotional activity, and a short window for disruptions. It’s precisely when your monitoring may be stretched. According to the 2025 Thales Bad Bot Report, Retail was the second most attacked industry in 2024 (15% of all bot attacks). 33% of web traffic to retail sites was driven by bad bots. But the most recent data shows that now an astounding 53% of web traffic to retail sites is bots!

Key Findings relevant for eCommerce and Online Retail

• 53% – the percentage of bot traffic (good and bad) to retail websites in 2025.
• 39% – the percentage of bad bot traffic to online retail in 2025
• 64% – the percentage of bot attacks on retail sites targeting business logic.
• 283% – The increase in Account Takeover attacks (ATO) on Black Friday 2024
• 18,813 – The number of hours of downtime prevented by Thales in November and December 2024
• 71 Million – The number of requests per day from AI tools in 2025

Chart based on data from November 2024 to November 2025

Retailers going into peak retail season without strong bot- and account-abuse defences are exposing a key part of their business to automated fraud and exploitation.

How bad bots target Online Retailers

Retailers often focus on obvious fraud vectors (payment fraud, card testing), but bots bring subtler, higher-volume risks that can erode margins, trust, and availability:

• Account Takeover (ATO). Attackers leverage stolen credentials or credential-stuffing campaigns to hijack customer accounts — often right before a major shopping event when accounts have stored payment details, loyalty points, or wish-lists. According to the 2025 Thales Bad Bot Report Account takeover (ATO) attacks increased by around 40% in 2024, a surge attributed to improved automation and AI-driven tools.
• Price Scraping. Bots scrape pricing, and product data at scale (often just before or during promotions), enabling grey-market resale, and competitive undercutting.
• Automated Checkout Abuse / Scalper Bots. Limited-release items (sneakers, consoles, luxury goods) are bought by bots in seconds, creating inventory hoarding or resale markets.
• API & Business Logic Attacks. As retailers expose more APIs (for checkout, loyalty, account management), bots attack those endpoints rather than just classic web pages. In 2024 API attacks shifted: 44 % of advanced bot traffic targeted APIs while in 2025, 64% of all bot attacks on the retail sector targeted API business logic.

These are not threats to be taken lightly. Modern bots imitate human behaviour (headless browsers, residential proxies, AI/cloud-driven automation) and can bypass many legacy defences.

Why holiday shopping season means a high return for cybercriminals

There are a few compounding factors that intensify the risk for retailers during peak season, making it easier for attackers to exploit traffic spikes and harder for security teams to keep up:

• Timing & value. As account histories build up (wish-lists, stored cards, loyalty points), the value of each account rises. Attackers know that e-commerce traffic surges around major events like Black Friday, Cyber Monday, and year-end deals.
• Promotion & checkout complexity. Retailers often deploy lots of new scripts or micro-services for promotions giving more surface area for bot abuse or skimming.
• Availability expectations. Customers expect 24/7 performance during peak season; disruptions (even small) risk damaging brand trust and revenue. A bot-driven DDoS or checkout-flow abuse during these days can have outsized impact.
• Compliance & customer data. With peak volumes, stored-card payments, cross-border activity and new flows, the risk of data breach or regulation (e.g., PCI-DSS, GDPR) becomes more acute.

What online retail security teams should prioritise now

1. Gain visibility into automated traffic

   You cannot protect what you cannot see. Modern bot behaviour includes leveraging headless browsers, residential proxy networks to mimic normal web traffic behaviors and AI has only served to increase the effectiveness of automated abuse making it easier for cyber criminals to repeat their abuse until they infiltrate their target. Ensure you have full visibility of your entire application and API infrastructure.

2. Prioritize high-value endpoints (login, APIs, checkout)

   Ensure your bot protection covers more than just the homepage. High-value targets such as Login pages and account flows, checkout APIs, and loyalty endpoints are prime targets for attack.

3. Protect customer accounts proactively

   Credential-stuffing and Account Takeover attacks will increase during peak shopping season. Traditional security measures such as good password hygiene and MFA are effective, but they are not enough for today’s AI-empowered attackers. True Account Takeover protection will immediately and accurately detect and block attacks at the edge. Always-on Account Takeover Protection will deter attackers by lowering their return on investment.

4. Secure APIs and microservices

   Retail platforms increasingly rely on APIs which is why an Advanced Bot Protection and Advanced API Security solution is recommended to offer full visibility of all your APIs and to ensure your most risky APIs are protected.

Peak-season eCommerce is a double-edged sword: while it presents huge revenue upside, the risk of bot-driven fraud, ATO and automation abuse is also at its highest. If you treat bot threats as an afterthought, you’re leaving the door wide open for attackers who already know your calendar, traffic patterns and the weakest links in your stack.

By integrating our full application security stack from Advanced Bot Protection and API security to Client-Side Protection and WAAP visibility, retailers shift from reactive detection to proactive prevention, turning the holiday surge into a secure growth opportunity instead of a season of risk.

Our application security suite delivers best-of-breed protection in a single platform, offering superior performance with lower latency, unified visibility through Attack Analytics to uncover coordinated campaigns, and with the backing of our world-class Threat Research team.

Learn more about our Application Security products today.

The post How Thales Protects Online Retail Sites from AI-Driven Bots during Holiday Shopping Season appeared first on Blog.

We recently handled a case where a customer reported strange SEO behavior on their website. Regular visitors saw a normal site. No popups. No redirects. No visible spam.

However, when they checked their site on Google, the search results were flooded with eBay-type-looking websites and “Situs Toto” gambling spam.

This is a professional-grade SEO cloaking attack. The malware turns the application into a double agent: it serves your genuine website content to real people but swaps it for a massive list of gambling ads the second a search engine bot crawls the page.

Continue reading Google Sees Spam, You See Your Site: A Cloaked SEO Spam Attack at Sucuri Blog.

We recently investigated a case involving a WordPress website where a customer reported persistent fake pop-up notifications appearing on their site. The warnings were urging them to update their browser (Chrome or Firefox), even though their software was already fully up-to-date.

What made this case particularly unique was the targeting. The fake alerts were not visible to regular visitors on the public-facing site. They only appeared when the site owner was logged into the wp-admin dashboard.

Continue reading Fake Browser Updates Targeting WordPress Administrators via Malicious Plugin at Sucuri Blog.

Simplifying Cloud Network Security When securing cloud landscapes, it’s critically important to eliminate any downtime or performance degradation that firewall or gateway implementation may cause. To address these challenges, Check Point is proud to announce our support for Google Cloud Network Security Integration. This innovation creates a nondisruptive approach to cloud firewall deployment, increasing network security without negatively impacting performance. Scaling Hybrid Cloud Network Security Network security and performance are critical to any organization, but this is especially true for industries under heavy regulations like financial services, healthcare, and government. So over time these organizations gain comfort, expertise, and confidence […]

The post Check Point Supports Google Cloud Network Security Integration appeared first on Check Point Blog.

The story you are reading is a series of scoops nestled inside a far more urgent Internet-wide security advisory. The vulnerability at issue has been exploited for months already, and it’s time for a broader awareness of the threat. The short version is that everything you thought you knew about the security of the internal network behind your Internet router probably is now dangerously out of date.

The past few months have witnessed the explosive growth of a new botnet dubbed Kimwolf, which experts say has infected more than 2 million devices globally. The Kimwolf malware forces compromised systems to relay malicious and abusive Internet traffic — such as ad fraud, account takeover attempts and mass content scraping — and participate in crippling distributed denial-of-service (DDoS) attacks capable of knocking nearly any website offline for days at a time.

More important than Kimwolf’s staggering size, however, is the diabolical method it uses to spread so quickly: By effectively tunneling back through various “residential proxy” networks and into the local networks of the proxy endpoints, and by further infecting devices that are hidden behind the assumed protection of the user’s firewall and Internet router.

Residential proxy networks are sold as a way for customers to anonymize and localize their Web traffic to a specific region, and the biggest of these services allow customers to route their traffic through devices in virtually any country or city around the globe.

The malware that turns an end-user’s Internet connection into a proxy node is often bundled with dodgy mobile apps and games. These residential proxy programs also are commonly installed via unofficial Android TV boxes sold by third-party merchants on popular e-commerce sites like Amazon, BestBuy, Newegg, and Walmart.

These TV boxes range in price from $40 to $400, are marketed under a dizzying range of no-name brands and model numbers, and frequently are advertised as a way to stream certain types of subscription video content for free. But there’s a hidden cost to this transaction: As we’ll explore in a moment, these TV boxes make up a considerable chunk of the estimated two million systems currently infected with Kimwolf.

Kimwolf also is quite good at infecting a range of Internet-connected digital photo frames that likewise are abundant at major e-commerce websites. In November 2025, researchers from Quokka published a report (PDF) detailing serious security issues in Android-based digital picture frames running the Uhale app — including Amazon’s bestselling digital frame as of March 2025.

There are two major security problems with these photo frames and unofficial Android TV boxes. The first is that a considerable percentage of them come with malware pre-installed, or else require the user to download an unofficial Android App Store and malware in order to use the device for its stated purpose (video content piracy). The most typical of these uninvited guests are small programs that turn the device into a residential proxy node that is resold to others.

The second big security nightmare with these photo frames and unsanctioned Android TV boxes is that they rely on a handful of Internet-connected microcomputer boards that have no discernible security or authentication requirements built-in. In other words, if you are on the same network as one or more of these devices, you can likely compromise them simultaneously by issuing a single command across the network.

THERE’S NO PLACE LIKE 127.0.0.1

The combination of these two security realities came to the fore in October 2025, when an undergraduate computer science student at the Rochester Institute of Technology began closely tracking Kimwolf’s growth, and interacting directly with its apparent creators on a daily basis.

Benjamin Brundage is the 22-year-old founder of the security firm Synthient, a startup that helps companies detect proxy networks and learn how those networks are being abused. Conducting much of his research into Kimwolf while studying for final exams, Brundage told KrebsOnSecurity in late October 2025 he suspected Kimwolf was a new Android-based variant of Aisuru, a botnet that was incorrectly blamed for a number of record-smashing DDoS attacks last fall.

Brundage says Kimwolf grew rapidly by abusing a glaring vulnerability in many of the world’s largest residential proxy services. The crux of the weakness, he explained, was that these proxy services weren’t doing enough to prevent their customers from forwarding requests to internal servers of the individual proxy endpoints.

Most proxy services take basic steps to prevent their paying customers from “going upstream” into the local network of proxy endpoints, by explicitly denying requests for local addresses specified in RFC-1918, including the well-known Network Address Translation (NAT) ranges 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12. These ranges allow multiple devices in a private network to access the Internet using a single public IP address, and if you run any kind of home or office network, your internal address space operates within one or more of these NAT ranges.

However, Brundage discovered that the people operating Kimwolf had figured out how to talk directly to devices on the internal networks of millions of residential proxy endpoints, simply by changing their Domain Name System (DNS) settings to match those in the RFC-1918 address ranges.

“It is possible to circumvent existing domain restrictions by using DNS records that point to 192.168.0.1 or 0.0.0.0,” Brundage wrote in a first-of-its-kind security advisory sent to nearly a dozen residential proxy providers in mid-December 2025. “This grants an attacker the ability to send carefully crafted requests to the current device or a device on the local network. This is actively being exploited, with attackers leveraging this functionality to drop malware.”

As with the digital photo frames mentioned above, many of these residential proxy services run solely on mobile devices that are running some game, VPN or other app with a hidden component that turns the user’s mobile phone into a residential proxy — often without any meaningful consent.

In a report published today, Synthient said key actors involved in Kimwolf were observed monetizing the botnet through app installs, selling residential proxy bandwidth, and selling its DDoS functionality.

“Synthient expects to observe a growing interest among threat actors in gaining unrestricted access to proxy networks to infect devices, obtain network access, or access sensitive information,” the report observed. “Kimwolf highlights the risks posed by unsecured proxy networks and their viability as an attack vector.”

ANDROID DEBUG BRIDGE

After purchasing a number of unofficial Android TV box models that were most heavily represented in the Kimwolf botnet, Brundage further discovered the proxy service vulnerability was only part of the reason for Kimwolf’s rapid rise: He also found virtually all of the devices he tested were shipped from the factory with a powerful feature called Android Debug Bridge (ADB) mode enabled by default.

ADB is a diagnostic tool intended for use solely during the manufacturing and testing processes, because it allows the devices to be remotely configured and even updated with new (and potentially malicious) firmware. However, shipping these devices with ADB turned on creates a security nightmare because in this state they constantly listen for and accept unauthenticated connection requests.

For example, opening a command prompt and typing “adb connect” along with a vulnerable device’s (local) IP address followed immediately by “:5555” will very quickly offer unrestricted “super user” administrative access.

Brundage said by early December, he’d identified a one-to-one overlap between new Kimwolf infections and proxy IP addresses offered for rent by China-based IPIDEA, currently the world’s largest residential proxy network by all accounts.

“Kimwolf has almost doubled in size this past week, just by exploiting IPIDEA’s proxy pool,” Brundage told KrebsOnSecurity in early December as he was preparing to notify IPIDEA and 10 other proxy providers about his research.

Brundage said Synthient first confirmed on December 1, 2025 that the Kimwolf botnet operators were tunneling back through IPIDEA’s proxy network and into the local networks of systems running IPIDEA’s proxy software. The attackers dropped the malware payload by directing infected systems to visit a specific Internet address and to call out the pass phrase “krebsfiveheadindustries” in order to unlock the malicious download.

On December 30, Synthient said it was tracking roughly 2 million IPIDEA addresses exploited by Kimwolf in the previous week. Brundage said he has witnessed Kimwolf rebuilding itself after one recent takedown effort targeting its control servers — from almost nothing to two million infected systems just by tunneling through proxy endpoints on IPIDEA for a couple of days.

Brundage said IPIDEA has a seemingly inexhaustible supply of new proxies, advertising access to more than 100 million residential proxy endpoints around the globe in the past week alone. Analyzing the exposed devices that were part of IPIDEA’s proxy pool, Synthient said it found more than two-thirds were Android devices that could be compromised with no authentication needed.

SECURITY NOTIFICATION AND RESPONSE

After charting a tight overlap in Kimwolf-infected IP addresses and those sold by IPIDEA, Brundage was eager to make his findings public: The vulnerability had clearly been exploited for several months, although it appeared that only a handful of cybercrime actors were aware of the capability. But he also knew that going public without giving vulnerable proxy providers an opportunity to understand and patch it would only lead to more mass abuse of these services by additional cybercriminal groups.

On December 17, Brundage sent a security notification to all 11 of the apparently affected proxy providers, hoping to give each at least a few weeks to acknowledge and address the core problems identified in his report before he went public. Many proxy providers who received the notification were resellers of IPIDEA that white-labeled the company’s service.

KrebsOnSecurity first sought comment from IPIDEA in October 2025, in reporting on a story about how the proxy network appeared to have benefitted from the rise of the Aisuru botnet, whose administrators appeared to shift from using the botnet primarily for DDoS attacks to simply installing IPIDEA’s proxy program, among others.

On December 25, KrebsOnSecurity received an email from an IPIDEA employee identified only as “Oliver,” who said allegations that IPIDEA had benefitted from Aisuru’s rise were baseless.

“After comprehensively verifying IP traceability records and supplier cooperation agreements, we found no association between any of our IP resources and the Aisuru botnet, nor have we received any notifications from authoritative institutions regarding our IPs being involved in malicious activities,” Oliver wrote. “In addition, for external cooperation, we implement a three-level review mechanism for suppliers, covering qualification verification, resource legality authentication and continuous dynamic monitoring, to ensure no compliance risks throughout the entire cooperation process.”

“IPIDEA firmly opposes all forms of unfair competition and malicious smearing in the industry, always participates in market competition with compliant operation and honest cooperation, and also calls on the entire industry to jointly abandon irregular and unethical behaviors and build a clean and fair market ecosystem,” Oliver continued.

Meanwhile, the same day that Oliver’s email arrived, Brundage shared a response he’d just received from IPIDEA’s security officer, who identified himself only by the first name Byron. The security officer said IPIDEA had made a number of important security changes to its residential proxy service to address the vulnerability identified in Brundage’s report.

“By design, the proxy service does not allow access to any internal or local address space,” Byron explained. “This issue was traced to a legacy module used solely for testing and debugging purposes, which did not fully inherit the internal network access restrictions. Under specific conditions, this module could be abused to reach internal resources. The affected paths have now been fully blocked and the module has been taken offline.”

Byron told Brundage IPIDEA also instituted multiple mitigations for blocking DNS resolution to internal (NAT) IP ranges, and that it was now blocking proxy endpoints from forwarding traffic on “high-risk” ports “to prevent abuse of the service for scanning, lateral movement, or access to internal services.”

Brundage said IPIDEA appears to have successfully patched the vulnerabilities he identified. He also noted he never observed the Kimwolf actors targeting proxy services other than IPIDEA, which has not responded to requests for comment.

Riley Kilmer is founder of Spur.us, a technology firm that helps companies identify and filter out proxy traffic. Kilmer said Spur has tested Brundage’s findings and confirmed that IPIDEA and all of its affiliate resellers indeed allowed full and unfiltered access to the local LAN.

Kilmer said one model of unsanctioned Android TV boxes that is especially popular — the Superbox, which we profiled in November’s Is Your Android TV Streaming Box Part of a Botnet? — leaves Android Debug Mode running on localhost:5555.

“And since Superbox turns the IP into an IPIDEA proxy, a bad actor just has to use the proxy to localhost on that port and install whatever bad SDKs [software development kits] they want,” Kilmer told KrebsOnSecurity.

ECHOES FROM THE PAST

Both Brundage and Kilmer say IPIDEA appears to be the second or third reincarnation of a residential proxy network formerly known as 911S5 Proxy, a service that operated between 2014 and 2022 and was wildly popular on cybercrime forums. 911S5 Proxy imploded a week after KrebsOnSecurity published a deep dive on the service’s sketchy origins and leadership in China.

In that 2022 profile, we cited work by researchers at the University of Sherbrooke in Canada who were studying the threat 911S5 could pose to internal corporate networks. The researchers noted that “the infection of a node enables the 911S5 user to access shared resources on the network such as local intranet portals or other services.”

“It also enables the end user to probe the LAN network of the infected node,” the researchers explained. “Using the internal router, it would be possible to poison the DNS cache of the LAN router of the infected node, enabling further attacks.”

911S5 initially responded to our reporting in 2022 by claiming it was conducting a top-down security review of the service. But the proxy service abruptly closed up shop just one week later, saying a malicious hacker had destroyed all of the company’s customer and payment records. In July 2024, The U.S. Department of the Treasury sanctioned the alleged creators of 911S5, and the U.S. Department of Justice arrested the Chinese national named in my 2022 profile of the proxy service.

Kilmer said IPIDEA also operates a sister service called 922 Proxy, which the company has pitched from Day One as a seamless alternative to 911S5 Proxy.

“You cannot tell me they don’t want the 911 customers by calling it that,” Kilmer said.

Among the recipients of Synthient’s notification was the proxy giant Oxylabs. Brundage shared an email he received from Oxylabs’ security team on December 31, which acknowledged Oxylabs had started rolling out security modifications to address the vulnerabilities described in Synthient’s report.

Reached for comment, Oxylabs confirmed they “have implemented changes that now eliminate the ability to bypass the blocklist and forward requests to private network addresses using a controlled domain.” But it said there is no evidence that Kimwolf or other other attackers exploited its network.

“In parallel, we reviewed the domains identified in the reported exploitation activity and did not observe traffic associated with them,” the Oxylabs statement continued. “Based on this review, there is no indication that our residential network was impacted by these activities.”

PRACTICAL IMPLICATIONS

Consider the following scenario, in which the mere act of allowing someone to use your Wi-Fi network could lead to a Kimwolf botnet infection. In this example, a friend or family member comes to stay with you for a few days, and you grant them access to your Wi-Fi without knowing that their mobile phone is infected with an app that turns the device into a residential proxy node. At that point, your home’s public IP address will show up for rent at the website of some residential proxy provider.

Miscreants like those behind Kimwolf then use residential proxy services online to access that proxy node on your IP, tunnel back through it and into your local area network (LAN), and automatically scan the internal network for devices with Android Debug Bridge mode turned on.

By the time your guest has packed up their things, said their goodbyes and disconnected from your Wi-Fi, you now have two devices on your local network — a digital photo frame and an unsanctioned Android TV box — that are infected with Kimwolf. You may have never intended for these devices to be exposed to the larger Internet, and yet there you are.

Here’s another possible nightmare scenario: Attackers use their access to proxy networks to modify your Internet router’s settings so that it relies on malicious DNS servers controlled by the attackers — allowing them to control where your Web browser goes when it requests a website. Think that’s far-fetched? Recall the DNSChanger malware from 2012 that infected more than a half-million routers with search-hijacking malware, and ultimately spawned an entire security industry working group focused on containing and eradicating it.

XLAB

Much of what is published so far on Kimwolf has come from the Chinese security firm XLab, which was the first to chronicle the rise of the Aisuru botnet in late 2024. In its latest blog post, XLab said it began tracking Kimwolf on October 24, when the botnet’s control servers were swamping Cloudflare’s DNS servers with lookups for the distinctive domain 14emeliaterracewestroxburyma02132[.]su.

This domain and others connected to early Kimwolf variants spent several weeks topping Cloudflare’s chart of the Internet’s most sought-after domains, edging out Google.com and Apple.com of their rightful spots in the top 5 most-requested domains. That’s because during that time Kimwolf was asking its millions of bots to check in frequently using Cloudflare’s DNS servers.

It is clear from reading the XLab report that KrebsOnSecurity (and security experts) probably erred in misattributing some of Kimwolf’s early activities to the Aisuru botnet, which appears to be operated by a different group entirely. IPDEA may have been truthful when it said it had no affiliation with the Aisuru botnet, but Brundage’s data left no doubt that its proxy service clearly was being massively abused by Aisuru’s Android variant, Kimwolf.

XLab said Kimwolf has infected at least 1.8 million devices, and has shown it is able to rebuild itself quickly from scratch.

“Analysis indicates that Kimwolf’s primary infection targets are TV boxes deployed in residential network environments,” XLab researchers wrote. “Since residential networks usually adopt dynamic IP allocation mechanisms, the public IPs of devices change over time, so the true scale of infected devices cannot be accurately measured solely by the quantity of IPs. In other words, the cumulative observation of 2.7 million IP addresses does not equate to 2.7 million infected devices.”

XLab said measuring Kimwolf’s size also is difficult because infected devices are distributed across multiple global time zones. “Affected by time zone differences and usage habits (e.g., turning off devices at night, not using TV boxes during holidays, etc.), these devices are not online simultaneously, further increasing the difficulty of comprehensive observation through a single time window,” the blog post observed.

XLab noted that the Kimwolf author shows an almost ‘obsessive’ fixation” on Yours Truly, apparently leaving “easter eggs” related to my name in multiple places through the botnet’s code and communications:

ANALYSIS AND ADVICE

One frustrating aspect of threats like Kimwolf is that in most cases it is not easy for the average user to determine if there are any devices on their internal network which may be vulnerable to threats like Kimwolf and/or already infected with residential proxy malware.

Let’s assume that through years of security training or some dark magic you can successfully identify that residential proxy activity on your internal network was linked to a specific mobile device inside your house: From there, you’d still need to isolate and remove the app or unwanted component that is turning the device into a residential proxy.

Also, the tooling and knowledge needed to achieve this kind of visibility just isn’t there from an average consumer standpoint. The work that it takes to configure your network so you can see and interpret logs of all traffic coming in and out is largely beyond the skillset of most Internet users (and, I’d wager, many security experts). But it’s a topic worth exploring in an upcoming story.

Happily, Synthient has erected a page on its website that will state whether a visitor’s public Internet address was seen among those of Kimwolf-infected systems. Brundage also has compiled a list of the unofficial Android TV boxes that are most highly represented in the Kimwolf botnet.

If you own a TV box that matches one of these model names and/or numbers, please just rip it out of your network. If you encounter one of these devices on the network of a family member or friend, send them a link to this story and explain that it’s not worth the potential hassle and harm created by keeping them plugged in.

Chad Seaman is a principal security researcher with Akamai Technologies. Seaman said he wants more consumers to be wary of these pseudo Android TV boxes to the point where they avoid them altogether.

“I want the consumer to be paranoid of these crappy devices and of these residential proxy schemes,” he said. “We need to highlight why they’re dangerous to everyone and to the individual. The whole security model where people think their LAN (Local Internal Network) is safe, that there aren’t any bad guys on the LAN so it can’t be that dangerous is just really outdated now.”

“The idea that an app can enable this type of abuse on my network and other networks, that should really give you pause,” about which devices to allow onto your local network, Seaman said. “And it’s not just Android devices here. Some of these proxy services have SDKs for Mac and Windows, and the iPhone. It could be running something that inadvertently cracks open your network and lets countless random people inside.”

In July 2025, Google filed a “John Doe” lawsuit (PDF) against 25 unidentified defendants collectively dubbed the “BadBox 2.0 Enterprise,” which Google described as a botnet of over ten million unsanctioned Android streaming devices engaged in advertising fraud. Google said the BADBOX 2.0 botnet, in addition to compromising multiple types of devices prior to purchase, also can infect devices by requiring the download of malicious apps from unofficial marketplaces.

Google’s lawsuit came on the heels of a June 2025 advisory from the Federal Bureau of Investigation (FBI), which warned that cyber criminals were gaining unauthorized access to home networks by either configuring the products with malware prior to the user’s purchase, or infecting the device as it downloads required applications that contain backdoors — usually during the set-up process.

The FBI said BADBOX 2.0 was discovered after the original BADBOX campaign was disrupted in 2024. The original BADBOX was identified in 2023, and primarily consisted of Android operating system devices that were compromised with backdoor malware prior to purchase.

Lindsay Kaye is vice president of threat intelligence at HUMAN Security, a company that worked closely on the BADBOX investigations. Kaye said the BADBOX botnets and the residential proxy networks that rode on top of compromised devices were detected because they enabled a ridiculous amount of advertising fraud, as well as ticket scalping, retail fraud, account takeovers and content scraping.

Kaye said consumers should stick to known brands when it comes to purchasing things that require a wired or wireless connection.

“If people are asking what they can do to avoid being victimized by proxies, it’s safest to stick with name brands,” Kaye said. “Anything promising something for free or low-cost, or giving you something for nothing just isn’t worth it. And be careful about what apps you allow on your phone.”

Many wireless routers these days make it relatively easy to deploy a “Guest” wireless network on-the-fly. Doing so allows your guests to browse the Internet just fine but it blocks their device from being able to talk to other devices on the local network — such as shared folders, printers and drives. If someone — a friend, family member, or contractor — requests access to your network, give them the guest Wi-Fi network credentials if you have that option.

There is a small but vocal pro-piracy camp that is almost condescendingly dismissive of the security threats posed by these unsanctioned Android TV boxes. These tech purists positively chafe at the idea of people wholesale discarding one of these TV boxes. A common refrain from this camp is that Internet-connected devices are not inherently bad or good, and that even factory-infected boxes can be flashed with new firmware or custom ROMs that contain no known dodgy software.

However, it’s important to point out that the majority of people buying these devices are not security or hardware experts; the devices are sought out because they dangle something of value for “free.” Most buyers have no idea of the bargain they’re making when plugging one of these dodgy TV boxes into their network.

It is somewhat remarkable that we haven’t yet seen the entertainment industry applying more visible pressure on the major e-commerce vendors to stop peddling this insecure and actively malicious hardware that is largely made and marketed for video piracy. These TV boxes are a public nuisance for bundling malicious software while having no apparent security or authentication built-in, and these two qualities make them an attractive nuisance for cybercriminals.

Stay tuned for Part II in this series, which will poke through clues left behind by the people who appear to have built Kimwolf and benefited from it the most.

Vulnerability reports and responsible disclosures are essential for website security awareness and education. Automated attacks targeting known software vulnerabilities are one of the leading causes of website compromises.

To help educate website owners about potential threats to their environments, we’ve compiled a list of important security updates and vulnerability patches for the WordPress ecosystem this past month.

The vulnerabilities listed below are virtually patched by the Sucuri Firewall and existing clients are protected.

Continue reading Vulnerability & Patch Roundup — December 2025 at Sucuri Blog.