200 Android Flaws, Browser-Built Phishing, 119K Scam Shops + 23 More Stories – CYBERDEFENSA.MX
admin Noticias, Trending
200 Android Flaws, Browser-Built Phishing, 119K Scam Shops + 23 More Stories – CYBERDEFENSA.MX

A lot of this week’s security news has the same awkward answer to one question: “Why was that allowed to work?”

An extension asks for access and takes too much. A trusted service becomes part of a phishing chain. An old bug still gets results. An exposed system stays exposed. A package looks useful right up until it isn’t. Different stories, same basic problem: the path in was often already there.

Nothing here needed magic. Mostly access, trust, weak edges, and someone willing to keep poking. That’s the week.

The threats change every week. Subscribe, and we’ll alert you when each new ThreatsDay Bulletin is out.

  1. Malicious extensions steal crypto data

    A set of four malicious Google Chrome and Mozilla Firefox extensions has been found to target Axiom Trade and Padre users to steal session tokens and wallet data. The extensions are J7Tracker (Chrome), VREO (Chrome and Firefox), and Orbit Tracker (Firefox). While the first three contain the same Axiom and Padre collection module, the fourth implements a different collector but targets the same data, while retaining some artifacts from J7Tracker. «The module is byte-identical across all three analyzed extensions. It automatically retrieves authenticated user information, wallet-related bundle data, Firebase access tokens, and application state, then sends the information to threat actor-controlled Vercel deployments,» Socket said. The same Chrome publisher has been traced back to two earlier extensions, GhostApe and GhostApe Color, impersonating the MockApe trading add-on.

The lesson this week is smaller than “patch faster.” Stop giving ordinary things unlimited trust. Extensions, packages, redirects, sessions, AI tools, exposed services — most of the trouble begins when something familiar is allowed to do too much.

Security still breaks at the boring handoffs: what gets access, what stays exposed, what gets inherited, and what nobody checks twice. Attackers do not need every door open. One lazy hinge is enough. That is probably the part worth remembering after the headlines disappear.

Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores – CYBERDEFENSA.MX
admin Noticias, Trending
Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores – CYBERDEFENSA.MX

Attackers are exploiting a new unpatched vulnerability in Magento Open Source and Adobe Commerce that lets them run malicious code on an online store’s server without logging in, Dutch e-commerce security company Sansec said in an advisory published on September 5.

Sansec, which discovered the flaw and named it StyleSmuggler, said attacks started on September 4. «Sansec is publishing early because stores are being compromised right now,» the company said.

As of September 6, Adobe has not published an advisory, a CVE identifier, a patch, or a workaround, and its Adobe Commerce security bulletin index lists nothing after the August 11 update.

A successful attack gives the attacker code execution on the store’s server and installs a persistent backdoor. Sansec said all current versions are affected, including 2.4.9, and that it reproduced the full unauthenticated chain on clean Magento Open Source installations of 2.4.7, 2.4.8, and 2.4.9.

Its first victim ran 2.4.6-p15 with Adobe’s July and August 2026 security updates applied, which is the latest patch level Adobe offers for that release line and one that Adobe’s August bulletin labels 2.4.6-2026-aug.

Sansec has not published a reproduction on Adobe Commerce or on Adobe Commerce on Cloud, and Adobe has not confirmed which versions are affected. Sansec has not said how many stores have been compromised.

The researchers’ interim advice for stores not running its Shield product is to temporarily disable GraphQL until Adobe releases a fix.

Disrex Group, a Magento hosting and development company that hosts and responded to two of the compromised stores, notes that headless and progressive web app storefronts require GraphQL, whereas most classic and Hyvä storefronts do not.

Adobe’s next scheduled security release is on September 8, Sansec said, and it is not yet known whether that release will cover this bug.

Disrex’s findings are independent evidence of exploitation from outside Sansec. In an incident-response repository published on September 5, the company said it handled two compromised stores and a third that was attacked but not breached, and that its web-server rules are based on attack traffic captured on one of the compromised stores. In answers to questions from The Hacker News, Disrex said both stores ran Magento Open Source rather than Adobe Commerce, and that it hosts them itself through its hosting brand RexHosting.

The store Disrex labels Store A ran Magento Open Source 2.4.8 and was a Sansec Shield customer, with the module installed, enabled, and licensed. It was hit at 23:10 UTC on September 4, hours before Sansec’s first blocking rules for this flaw went live, and Disrex said Shield was active and blocking other malicious traffic against the store at the time.

Store B, which was not a Shield customer, ran Magento 2.4.7-p2, a security patch level that Adobe’s version history dates to August 2024, eight levels behind the current 2.4.7-p10. It was first hit at 00:55 UTC on September 5, Disrex said, and it is the store from which the company’s web-server rules and its reading of the vulnerable code were taken.

Both stores were breached inside the roughly eight-hour window between the first exploitation Sansec observed and the moment any defence for it existed, Disrex said. «Patch status was irrelevant here, which is the part merchants most need to hear,» the company told The Hacker News.

The repository carries its own warning. «This repository was written with AI assistance, during a live incident, in a few hours,» its README says, adding that it has not been reviewed, that its Apache rules were never run against a live Apache server, and that most of its cleanup commands were written rather than executed.

Sansec’s indicators describe the implant as a background process disguised under [kworker/u:8:0], a name that belongs to a Linux kernel thread, with a binary installed at ~/.local/share/.gvfsd/gvfsd-user under the site user’s home directory rather than the web root, and a cron entry that restarts it every five minutes.

Disrex described the binary as a stripped, statically linked Rust program of roughly 1.9 MB built for x86-64 and arm64, and said the cron entry is written straight to the spool file under /var/spool/cron/crontabs/, so the system log shows no crontab replacement.

One store carried the same line 1,728 times, and the implant re-added it within a second of removal.

On one of the two stores, the implant made no outbound connection at all. It held 28 connections to the store’s own Redis instance on port 6379 and read Magento’s session storage from it, Disrex said, and neither of its two packet captures, each over 200 MB and taken while the implant was live, contained a single packet to the download host or the command-and-control address that Sansec listed.

Disrex told The Hacker News over email that each store ran in its own isolated account with a single site owner, no sudo rights, and no path to any other customer, that the implant ran as the unprivileged site user and could reach nothing beyond that store, and that it confirmed no lateral movement and no other affected site on its platform.

Both stores were contained the same day, roughly eleven and fourteen hours after first contact, the company said, and it found no evidence of data exfiltration, no rogue admin accounts, no injected payment skimmer, and no database backdoor. All sessions were invalidated, and credential rotation is underway as a precaution.

Because it runs a number of Magento stores on its own platform and found the first compromise quickly, Disrex said, it swept its whole estate within the hour and found the second store the same afternoon. The company has also published an incident write-up.

Sansec said that for Shield customers attacked before its rules went live, it has no indication that the backdoor was actually used, and recommended rotating Magento credentials wherever the process has been identified.

The attack works in two stages, according to Sansec’s outline. It first plants PHP code in a file that Magento itself writes, for example, when generating a failure report. Then it makes Magento execute that file by triggering the platform’s standard «Payment Transaction Failed Reminder» email. The code runs while Magento renders the message, so no one has to open it, and the attack can succeed even if email delivery fails.

Sansec has not yet published the full exploit chain and said a breakdown of the chain, the dropper, and the implant will follow in an update.

Disrex’s reading of the chain, published in a mechanism write-up alongside its rules, is that a directive within the injected text drives a sequence of Magento’s own classes into code that exists solely to serve the command-line dependency-injection compiler.

That code ends by including a file path the attacker chose: the log poisoned a moment earlier. The executed PHP dropper attempts six PHP functions in turn to start a process, then downloads and launches the implant. Disrex names three files under setup/src/Magento/Setup/Module/Di/Code/ as the point where the chain ends, and told The Hacker News it identified that sink on its own by reading Magento source on the compromised store. Sansec has not confirmed that reading, and Disrex does not publish the assembled request.

Two locations matter for the first stage. Sansec’s published check searches var/report/ for the marker X_TRACE_. Disrex said both of its infections were poisoned through var/log/system.log instead and would have been missed by that check, so both directories need searching.

The marker has already drifted: Disrex saw a trigger header of the form X-TRACE- followed by ten hex characters on the morning of September 5 and the same header without the word TRACE by the afternoon, so a search should match the shape rather than the exact string.

A TypeError from array_merge() with an integer argument in system.log, immediately after the include, is evidence that the exploit succeeded, Disrex said. However, a stealthier variant returns an empty array and leaves nothing in the log.

For the process, Disrex said that a genuine kernel thread is owned by root and has no resident memory, so a bracketed name on the site user with real memory usage is the implant. The implant sets its command line to the literal bracketed string, so a check written against the process’s comm field matches nothing.

Disrex also found that the binary running in memory on one store was a different build from the file on disk, and advises hashing the running process from /proc//exe as well as the file. Unexpected bursts of «Payment Transaction Failed Reminder» emails are a reason to investigate, Sansec said, although legitimate declined payments generate the same notification.

The following indicators have been published by Sansec and in Disrex’s indicator list –

  • Process: [kworker/u:8:0] owned by a non-root user
  • File: ~/.local/share/.gvfsd/gvfsd-user
  • File: ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
  • File: /tmp/.gvfsd_<8hex>.lock
  • File: /tmp/.kw_
  • Cron: */5 * * * * exec /.local/share/.gvfsd/gvfsd-user, with a variant pointing at /tmp/.kw_
  • SHA-256: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (Sansec’s sample)
  • SHA-256: 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (on disk on both Disrex stores)
  • SHA-256: 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (running in memory on one Disrex store)
  • Domain: 247.cdnflare[.]xyz (malware download host)
  • IP: 99.84.67[.]186:443 (command-and-control over WebSocket and TLS, per Sansec)
  • IP: 88.216.72[.]181 (attacker source, per Sansec)
  • IP: 5.181.86[.]133 (attacker source sending in bulk, per Disrex)

Sansec recommends its eComscan scanner to detect the implant, and said version 1.9.7 will terminate the process for Shield customers.

Disrex reported a clean result on Store A. eComscan ran there at 10:00 UTC on September 5, roughly eleven hours after the implant first ran and while 1,728 cron lines were present, and reported the store clean. The cause was scope rather than a scanner fault, Disrex told The Hacker News: the scheduled scan was pointed at the store’s document root, and the implant had installed one directory above it, under the account’s home directory. Disrex has since widened the scan path and said it would confirm the eComscan build number separately.

There is no vendor fix to install. Until Adobe ships one, the options are Sansec’s temporary GraphQL shutdown; three unofficial mitigations published by Disrex, ProxiBlue, and Graycore; and two server settings that do not depend on the flaw.

Disrex published nginx and Apache rules that block requests carrying the exploit’s parameters in the URL query string. Its own test on a live store showed the limit: the same parameters sent in a POST body reached PHP, as did a JSON body, because nginx and Apache inspect only the query string, Disrex said. Disrex describes the rules as stopping the campaign as it currently runs rather than the vulnerability.

Disrex’s main mitigation adds a check to three methods in Magento’s dependency-injection code scanners, preventing them from running outside the command line. The hand edit is reverted by every composer install, so Disrex also ships it as a composer-patches source patch that reapplies on deploy and, it says, applies unchanged from 2.4.6 through 2.4.9.

One of the three files, ClassesScanner.php, is called over HTTP by at least one third-party module, mageplaza/module-admin-permissions, and guarding it breaks that module’s admin screen, so Disrex tells administrators to search their vendor directory before touching it.

The guard was tested on a harness rather than inside a running store, and Disrex says it is not a complete fix on its own. Disrex told The Hacker News the guard is its own work, written during the response, and was not developed with anyone else. A GitHub user, ProxiBlue, separately published the same guard on September 5 as three unofficial patches. Neither Sansec nor Adobe has confirmed that these scanners are where the chain ends.

Graycore, LLC published a Magento module on GitHub and Packagist on September 5 whose current code, Graycore says, hardens three points on the chain: the email template block directive refuses backend blocks, the grid row URL generator checks a class before building it, and PHP opening tags in Web API fatal error reports are broken.

The version on Packagist at the time of writing was an earlier release whose only mitigation targeted a PayPal GraphQL resolver that has since been removed. The README says «That is hardening, not a fix» and warns that other paths through the vulnerability remain open and that a store may already be compromised.

Two server settings do not depend on knowing the chain at all, Disrex said. At one of its two stores, the first four of the six PHP functions the dropper tried were disabled; proc_open was not, and the dropper used it to start the implant, with open_basedir doing nothing to contain the child process.

Adding proc_open to PHP’s disable_functions, and mounting /tmp, /var/tmp and /dev/shm with noexec so a downloaded binary cannot run, are the layers Disrex puts ahead of every rule in its repository.

For a store that is already infected, Disrex’s cleanup guide sets the order: preserve evidence first, remove the cron entry before killing the process because the process restores it, do not reboot because the copy under /proc may be the only remaining binary, and do not run composer install to clean up because it overwrites the timestamps that show what was touched.

It then recommends flushing session storage since the implant read it, and rotating the crypt/key in app/etc/env.php, as well as every admin password, every payment provider API key, and every other integration credential in that file.

Hosting providers Nexcess and Liquid Web posted identical incident notices on September 5, stating they were reviewing their server environments and implementing precautionary measures.

Neither claims a confirmed customer compromise or its own reproduction of the flaw. Disrex recorded 26 distinct source addresses across its two stores, taken from the stores’ own nginx access logs and deduplicated, two of them hosting infrastructure sending in bulk and the rest a residential proxy pool sending two to six requests each, and said that blocking the single attacker address in Sansec’s advisory would have stopped less than a quarter of the traffic it saw. An earlier count of 28 included two of Disrex’s own servers making verification requests during the response, which it removed. No source has named the attackers.

The Hacker News has reached out to Adobe, Sansec, and Graycore for comment, and will update the story if we hear back.

CEO Phishing Kits, 5K Dropbox Account Hacks, OAuth Traps + 17 More Stories – CYBERDEFENSA.MX
admin Noticias, Trending
CEO Phishing Kits, 5K Dropbox Account Hacks, OAuth Traps + 17 More Stories – CYBERDEFENSA.MX

The worst part is how normal these attacks look. A call from IT. A shared file. A trusted app. A simple request to click “Allow.” Why break in when someone might open the door?

That idea runs through this edition. Attackers use real tools, fake login pages, old account links, and software guides that point to unsafe downloads. One wrong letter in a web address can be enough.

There is also ransomware, stolen ID data, hidden attack servers, and weak settings that should have been fixed long ago. Here’s the full list.

The threats change every week. Subscribe, and we’ll alert you when each new ThreatsDay Bulletin is out.

  1. Fake IT, Real Access

    Microsoft has warned of a human-operated intrusion campaign that leverages Microsoft Teams external collaboration to impersonate IT or help desk personnel and socially engineer users into granting an interactive remote session. «Once remote control is established via RMM tools, the threat actor uses PowerShell to download and silently install a malicious MSI package, which in turn stages a portable Node.js runtime and an obfuscated JavaScript implant that provides persistent command execution and command and control (C2),» the tech giant said. «After the implant is deployed, the threat actor performs extensive host and Active Directory reconnaissance, periodically captures screenshots of the victim’s desktop, executes follow-on payloads through trusted Windows binaries, and pivots across the enterprise over Windows Remote Management (WinRM) toward high-value assets such as domain controllers.» Microsoft has described the «intrusion pattern» as high-impact as it grants an external operator interactive access to internal infrastructure.

One point is easy to miss: changing a password may not shut every door. A bad app approval or remote session can give attackers access without the password. Recovery should also end open sessions, remove unknown app access, and check remote tools.

Better security settings are slowly becoming the default, which helps. But old account links, weak sign-in options, and trusted software still give attackers room to work. The safest rule this week is simple: check what already has access before adding anything new.

From Adoption to Incident Readiness – CYBERDEFENSA.MX
admin Noticias, Trending
From Adoption to Incident Readiness – CYBERDEFENSA.MX

The debate about whether AI delivers business value is over. The challenge now is implementing it at scale and securely across every function while meeting board-level pressure to move fast. Organizations must focus on adopting AI at business speed without losing control of cyber risk. Download the full eBook here.

The Business Reality

In Sygnia’s 2026 CISO Survey Report, which surveyed 600 senior IT and security leaders worldwide, nearly one-third already report extensive AI use across threat detection and IR, with 63% expecting it to be fully embedded in their organization by 2027.1 Yet 73% of IT security decision makers say their organization would not be fully ready if a significant cyberattack occurred tomorrow.1

Security teams feel they do not have adequate time to adapt. The tools are being deployed. The governance, controls, and incident readiness to support them are not. Security leaders are now tasked with enabling AI adoption while reducing the inheritance of unmanaged risk.

The AI Security Gap

AI is already inside the enterprise, but does not always enter through the front door. It comes through approved platforms, employee workarounds, SaaS plugins, vendor tools, internal experiments, and development teams trying to move faster. How deeply and quickly AI should be embedded depends heavily on which type of AI is used – Generative AI or Agentic AI. The more AI moves from fully- or semi-autonomously assisting people to acting across systems, the less it can be treated as a productivity tool alone. It significantly expands the enterprise attack surface and introduces new security risks.

The rapid adoption of enterprise AI is being driven from both the top down and the bottom up. Leadership typically recognizes the need for oversight, but does not have a proven playbook to swear by, and employees are rarely equipped to assess the security implications of the tools they adopt on their own. As organizations prioritize speed, security reviews, vendor assessments, and data governance often become secondary concerns, creating an environment where AI adoption outpaces control.

With only 38% of organizations reporting a comprehensive AI policy2, adoption is outpacing oversight, leaving security teams to manage the consequences after the fact. The result is a rapidly expanding attack surface fueled by widespread shadow AI and AI-powered threats that lower the barrier to sophisticated attacks while enabling adversaries to identify and exploit vulnerabilities faster and at greater scale.

The Hidden AI Risks

The assumption has taken hold that limited AI usage means manageable AI risk and that because the program is early, the exposure is minimal. It isn’t. The AI attack surface is not a fixed perimeter. It expands wherever AI is adopted, integrated, or built. 67% of executives believe their organization has already suffered a breach as a result of unapproved AI tools.3

The entry points multiplying fastest are rarely the ones under active security review, which leaves room for more and faster exploitation: (1) ungoverned AI (including shadow AI), (2) ad hoc integrations, and (3) AI agents with excessive permissions.

And on the attacker side, the threat landscape has shifted in ways that make this exposure increasingly beneficial for them and in turn consequential for their enterprise victims. Their underlying tactics and techniques often remain the same, but AI enables attackers to execute them faster, at greater scale, and with higher levels of automation, ultimately increasing their effectiveness against existing weaknesses within an enterprise environment – as seen in a recent AI-enabled attack investigated and remediated by Sygnia incident responders.

The Need for a Lifecycle Approach

AI security needs to be addressed across each tool’s complete lifecycle. The control requirements change at each stage, but the priorities stay consistent: identify usage, classify risk, assign ownership, limit access, validate controls, and prepare for incident scenarios before AI is deployed and becomes embedded into critical workflows.

It’s imperative to prepare for the different lifecycle stages and understand their associated security challenges.

Strategy and Use Case Definition

Organizations need clearly defined ownership, decision rights, oversight, and escalation across business, technology, security, legal, privacy, compliance, and risk functions. This ensures AI use remains aligned with organizational objectives, policies, risk appetite, and regulatory obligations before the business becomes dependent on these tools.

Common challenge: Organizations often adopt AI without defining who owns the use case, who is authorized to approve it, who oversees its continued operation, and who is accountable when its use produces business consequences.

Design and Development

AI adds design questions that are easy to miss: how prompts are handled, what data is retrieved, how embeddings are stored, how vector databases are protected, how model outputs are validated, and what happens if the system is manipulated. AI-specific security requirements need to be defined before the system is built.

Common challenge: AI applications regularly reach production without security requirements being defined, tested, or validated at any stage of development.

Adoption and Vendor Selection

Whether evaluating a SaaS AI platform, integrating a third-party model, or building on a foundation model via API, the security implications of that choice need to be assessed before the contract is signed. Evaluate whether to build, buy, or integrate and treat it as a security decision, not just a capability and cost question.

Common challenge: Organizations typically adopt AI capabilities without performing adequate security and risk assessments. Speed of procurement consistently outpaces due diligence.

Deployment and Integration

An application that passed security review at design can still be deployed insecurely. The most consistent failure at this stage is excessive permissions: where AI systems are connected to sensitive data with access that reflects what was convenient rather than what the function requires.

Common challenge: AI systems routinely go into production with access that was never formally reviewed and rarely gets revisited.

Operations, Monitoring, and Scaling

AI systems evolve after deployment as models are updated, integrations are added, and use cases expand, potentially changing the risk profile without a deliberate decision to do so. Maintain a current inventory of AI applications, services, and integrations, and periodically reassess use cases and risk classifications as capabilities and usage patterns change.

Common challenge: AI adoption scales faster than the governance and monitoring capabilities designed to manage it.

Incident Response and Recovery

Most organizations have incident response plans, but they are not built for AI. Prompt injection, agent compromise, and third-party model failures require different forensic capabilities, containment strategies, and stakeholder coordination than conventional attacks. Add AI-specific response procedures to existing IR playbooks and integrate AI incidents into broader cyber crisis management processes.

Common challenge: Incident response plans are written for the threats organizations faced when they were last updated. AI-specific scenarios are absent from most plans.

Operationalizing an AI Plan with Security in Mind

Understanding where AI risk lives is one thing. Building the organizational structures, controls, and processes to manage it is another. Most organizations lack an actionable program that connects the dots. There are six components to consider when operationalizing a best practice AI plan.

Establish Executive Alignment and Business Objectives

89% of security leaders cite limited executive or board involvement in IR readiness and decision-making as a key challenge.4 The only thing that resolves this is executive ownership – and not in the sense of awareness, but in the sense of defined accountability, formal sponsorship, and a clear organizational mandate that AI security is a business requirement.

Recommendations:

  • Define the business drivers for AI adoption
  • Align AI initiatives with business goals and risk appetite
  • Identify stakeholders across Security, IT, Legal, Compliance, Privacy, and business teams
  • Establish executive sponsorship and accountability

Build an AI Governance Program

75% of security leaders agree that delays and uncertainty around legal and communications involvement slow down decision-making during incidents.5 When an incident occurs and the organization needs to know who owns a given AI system, what data it has access to, and who has the authority to take it offline, governance is what makes those questions answerable in minutes rather than hours.

Recommendations:

  • Define acceptable AI use policies and standards
  • Establish decision-making and approval processes
  • Define ownership and accountability for AI systems and risks
  • Align governance with regulatory and compliance requirements
  • Develop an AI risk management framework

Implement Enforceable Security and Operational Guardrails

Effective AI governance must be translated into enforceable security and operational controls. Otherwise, policies become guidance that teams interpret and apply differently. These guardrails should apply across the main ways AI enters the organization: public GenAI use, copilots, SaaS AI features, internal applications, retrieval-augmented generation (RAG) systems, autonomous agents, cloud AI services, and vendor-managed platforms.

Recommendations:

  • Define identity and access management requirements
  • Define data protection, privacy, and information handling controls
  • Define monitoring, logging, audit, and record retention needs
  • Define standards for AI development, procurement, integration, and deployment
  • Define controls for third-party AI services, models, platforms, and vendors

Foster Workforce Awareness and Preparedness

Technical controls address what systems can and can’t do. Workforce preparedness addresses what people will and won’t do – which is a different problem requiring a different approach. Effective AI awareness programs must go beyond annual, generic compliance training and provide practical, role-specific guidance; giving people the knowledge they need to make better decisions in the normal course of their work.

Recommendations:

  • Train employees on responsible, approved, and prohibited AI usage
  • Educate developers on secure AI design and development practices
  • Raise awareness of data handling, privacy, output, and security risks
  • Provide role-specific guidance on AI governance expectations
  • Communicate clear avenues for exception requests and reporting suspected AI misuse

Validate Security Before Adoption and Across the Lifecycle

Validation should happen before deployment and continue throughout the lifecycle as usage expands. AI systems change through new features, new integrations, data sources, vendor updates, model changes, expanded permissions, and broader business reliance. A review performed at launch may not reflect the system’s risk profile six months later.

Recommendations:

  • Conduct AI security posture assessments before approval
  • Perform AI application penetration testing and adversarial testing
  • Assess third-party AI solutions, models, integrations, and supply chains
  • Validate access controls, data flows, monitoring, and human oversight
  • Continuously evaluate AI deployments as capabilities evolve

Prepare for AI Security Incidents

Existing incident response (IR) plans may not address the scenarios that AI introduces, including prompt abuse, agent compromise, data leakage, unsafe outputs, third-party AI exposure, unauthorized model use, or incidents where AI-generated activity becomes part of the evidence trail. The implementation of AI-specific incident response procedures and decision criteria into an existing IR plan is critical.

Recommendations:

  • Update your IR plan to include the following components:
  • How security, privacy, legal, technology, business owners, model providers, and other third parties should coordinate during an incident
  • Define AI-related ownership, escalation paths, and responsibilities
  • Conduct AI-focused tabletop exercises and operational readiness assessments
  • Train staff on AI-driven logging, monitoring, and forensic capabilities
  • Practice AI-themed scenarios across the wider incident response and crisis management program

ACTION: Proactively Secure Your AI Solutions

Organizations that wait for a threat to expose their AI security posture are already behind. 65% of organizations say they are likely to switch IR providers at the end of their contract – the top driver being the need for more proactive readiness support.6

The demand is clear. What’s less clear, for most organizations, is what a proactive AI security approach looks like when it’s properly executed.

There are three areas of primary focus in a proactive security approach that can be performed in any order and should continue across the AI lifecycle:

(1) Assess the organization’s AI cyber posture across infrastructure, applications, data flows, and prompt behavior.

(2) Establish a comprehensive AI governance and usage framework or evaluate the organization’s existing one.

(3) Test the security and functionality of internally developed and externally adopted AI applications against real-world adversarial behaviors.

Closing

Organizations must not only capture the business value of AI adoption but also prioritize how to mitigate the introduction of unmanaged cyber risk. To do this, a solid lifecycle approach is required that integrates security, governance, and risk management across AI strategy, development, vendor selection, deployment, monitoring, and incident response – particularly when systems access sensitive data, connect to enterprise environments, or support critical workflows.

Because AI threats and security frameworks are still evolving, organizations must regularly assess their posture, governance, controls, and preparedness. Those that secure AI proactively will reduce exposure across an expanding attack surface while gaining the ownership, visibility, and confidence needed to adopt it safely at scale.

Work with Sygnia

Sygnia understands firsthand how adversaries are using AI attack surfaces to accelerate their exploitation capabilities and what cyber defenders must do to get in front of this growing security risk. Learn more about Sygnia’s AI Cybersecurity Services.

Citations:

[1] Sygnia CISO Survey, 2026

[2] ISACA AI Pulse Poll, 2026

[3] Writer Enterprise AI Adoption Report, 2026

[4] Sygnia CISO Survey, 2026

[5] Sygnia CISO Survey, 2026

[6] Sygnia CISO Survey, 2026

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

Threat Actors Don’t Want Better Attacks. They Want Repeatable Ones – CYBERDEFENSA.MX
admin Noticias, Trending
Threat Actors Don’t Want Better Attacks. They Want Repeatable Ones – CYBERDEFENSA.MX

The most common way into a company last year was to ask.

A web page tells the visitor to prove they are not a robot. While they read the instructions, it quietly places a command on their clipboard. Then it talks them through opening a terminal and pasting it in. The technique is called ClickFix, and it was the most common initial access method Microsoft’s team observed last year, accounting for 47% of the attacks in their notifications. Nothing arrives as an attachment, so there is nothing to scan. No vulnerability is used, so there is nothing to patch.

What happens next is just as ordinary. When Bitdefender analyzed 700,000 security incidents, 84% of the high-severity ones involved binaries that were already on the machine – the same administrative tools your IT team uses every day. Nothing malicious was installed, because nothing malicious was needed.

Neither technique is clever, but both are winning. And the reason is not that attackers have run out of ideas. It is that they are not looking for ideas. They are looking for something that works the same way at the next company, and the one after that.

This is a business, and businesses standardize

A criminal group that has to invent something new for every victim does not scale. One that has a procedure – a formula it can run against a list of targets, with predictable steps and a predictable result – can grow as fast as it can find targets.

You can watch that preference in the data. Verizon’s most recent Data Breach Investigations Report makes the exploitation of vulnerabilities “the most prominent initial access vector in our dataset this year, reaching the height of 31%, up from 20% last year” – a 55% increase in a single year, in the one category that rewards scanning over skill.

Edge devices are not popular because they are interesting. They are popular because the procedure is short enough to write on a card.

Watch for new CVEs in internet-facing devices. Filter for the ones that give remote code execution and require no authentication – the easy ones. Then wait. Someone will publish a working proof of concept on GitHub, usually within days. When they do, scan the internet at scale and take whatever has not been patched yet.

Notice what is absent from that procedure. Nobody in that chain develops anything. The exploit arrives free, from a researcher, on a public repository, on a schedule somebody else sets. The only capability required is the ability to run other people’s code quickly and at volume. Exposure becomes the selection criterion, and who the victim turns out to be stops mattering very much.

There is a version of this in the legitimate economy. A generics manufacturer does not discover drugs. It waits for someone else’s research to become public, then produces a known formula at volume, competing on cost and speed to market rather than on invention. That is what this is. Not a research operation – a generics business, where the patent expires the day the proof of concept lands on GitHub.

You can also see the preference in who wins. For more than a year, the top position on the ransomware leak-site rankings belonged to Qilin, which claimed roughly 1,600 victims across that span, usually more than a hundred a month. In June it was displaced by The Gentlemen, with 121 claimed victims against Qilin’s 80. These are figures the groups publish about themselves, so they are claims rather than audited numbers – but the two have been trading the top position, and what they are competing on is throughput. The leaderboard counts victims, it does not count technical achievement.

The more telling detail is where the challenger came from. The Gentlemen branched out from a former Qilin affiliate, and as Bitdefender’s own threat debrief put it, they have demonstrated how successful ransomware “playbooks” are being recycled and improved. The procedure walked out of one organization and into another and worked just as well in new hands.

That is the clearest available statement of what these groups actually own. Not an exploit, not a tool, not a secret. A method that can be written down, handed over, and run again.

ClickFix is a playbook for getting in

Look at ClickFix through that lens and its appeal is obvious.

There is no payload to rebuild when a detection lands, because there is no payload. There is no exploit to re-develop when a vendor ships a patch, because no vulnerability is being used. When a lure stops working, you rewrite the text on a web page. The technique degrades gracefully, which is exactly what you want from something you intend to run thousands of times.

It also works identically everywhere, because it does not depend on the target’s technology stack at all. It depends on a person being willing to follow instructions, and that is the one component present in every environment on earth, in the same version, with no patch available.

The fact that it also removes every artifact a defense is designed to catch – nothing to scan, no exploit to detect, no signature to match – is a genuine advantage. But I would not put it first. Attackers did not choose this because it evades detection. They chose it because it repeats, and the evasion came free.

Living off the land is the same idea, one step further in

Initial access is just the beginning of the operation. The work that follows – the part that ends in stolen data or encrypted systems – runs on the same logic: a playbook that produces the same result wherever it is pointed. Only this time the tools are the ones already on the machine.

Rather than bringing tooling of their own, they use what is already installed: the scripting engines, remote management utilities, archive tools and administrative binaries that ship with the operating system. That is what the 84% describes – those binaries were involved in the large majority of high-severity incidents we analyzed.

The reason is not primarily stealth. It is that these tools are familiar, they are present in every environment, and – this is the part that matters – they are identical in every environment. An operator who learns the sequence once can run it at the next victim without adaptation. There is nothing to port, nothing that depends on the target’s build, and nothing that needs testing against an unfamiliar stack. Command and control follows the same instinct, routed through cloud services the organization already trusts and already permits.

That these tools are also hard to distinguish from legitimate administration is a considerable bonus. It is not the reason they were picked.

It is, however, the part defenders find hardest, and it is worth being honest about why. When an attacker introduces nothing, there is nothing to find.

The economics look exactly like you would expect

If cybercrime really is a volume business built on repeatable procedure, the financial picture should look like a volume business under pressure. And it does.

Verizon’s most recent report has ransomware growing again, to 48% of all breaches, up from 44% the year before. Over the same period, the money moved the other way: 69% of ransomware victims didn’t pay, and the median ransom that was paid fell to $139,875 from $150,000. Bitdefender’s own tracking of ransomware leak sites counted 704 organizations claimed as victims in June 2026 alone.

More victims, less money. That is falling revenue per attempt, and the rational response to falling revenue per attempt is not to make each attempt more elaborate. It is to make each attempt cheaper and more repeatable, and to run more of them.

This is also where the AI argument meets arithmetic. The playbook approach costs an attacker close to nothing per attempt: the scanning is cheap, the exploit was free, and the tools were already installed on the victim’s machine. Putting a model in that loop adds a real cost to every attempt, in a business that has spent years driving that cost towards zero. It also adds it in the wrong place. This is a volume operation aimed at whoever happens to be exposed, not a small number of large organizations where a bigger investment per target could be justified. Against a handful of high-value victims, paying for intelligence might well pay back. Against a list of several thousand small businesses, it does not.

Which is why autonomy is the wrong shape for this business

That is the arithmetic objection. The structural one runs deeper.

An autonomous agent improvises. It explores an environment, finds a path, and the path it finds is particular to that environment. Run it against the next company and it does something different. That is genuinely impressive, and it is precisely the opposite of a playbook.

Ransomware operates as an affiliate model. The whole point of a franchise is that a procedure written once produces the same result in unfamiliar hands. Variance is the enemy of that model – you cannot document an improviser, cannot train an affiliate on it, and cannot predict what it will do at a victim you have not seen. A tool that solves each problem differently is not an asset to a business whose entire advantage is doing the same thing every time.

There is a version of AI adoption here that is entirely rational, and I expect it is already happening: using a model offline to help develop the playbook – research a technique, write the tooling, refine the lure – and then running the resulting procedure deterministically, the way it has always been run. That is AI as author. What does not follow the money is AI as executor, live at each victim, improvising its way in.

The same reasoning applies to the claim that AI will let attackers find novel vulnerabilities. They already decline to invest there, and they decline for a reason. The edge-device procedure works precisely because someone else does that work and publishes it, free, on a predictable cadence. A capability that discovers original vulnerabilities solves a problem this business does not currently have – and it would have to be cheaper than waiting, which is hard to beat when waiting costs nothing.

None of this holds permanently, and I have said so in January as well as here. Attackers adopted ransomware-as-a-service and double extortion the moment those made business sense, quickly and without sentiment, and they will adopt autonomy on the same terms. But the signal to watch is not a capability announcement. It is the point at which running a model against a victim becomes cheaper than running the playbook – because cost is the only threshold this business has ever responded to.

What actually helps

The encouraging consequence of all this is that a standardized attack is a standardized defense problem. You are not defending against unlimited creativity. You are closing a small number of doors that the playbook depends on, and the playbook cannot afford to be redesigned for every victim.

Patch smart. You cannot patch everything quickly, and you do not have to. The attacker’s filter is public: internet-facing, remote code execution, no authentication required. Run that same filter over your own estate, and you have your list. The window is the gap between the advisory being published and the first working proof of concept appearing on GitHub – often only days. Patch inside that window and the procedure described earlier never reaches you.

Reduce what can run at all. Application control and script execution policy break the ClickFix chain at the point where a pasted command becomes a running process.

Scope the built-in tools. Most users have no legitimate need for the remote management and scripting utilities that turn up in the 84%. They cannot be removed, but who can invoke them is a decision you get to make.

Treat identity as the real perimeter. Shared credentials, over-broad service accounts and keys that are administrative everywhere are what convert one compromised machine into an incident. The least fashionable item on this list, and consistently the most decisive.

Look at events together, not one at a time. Nothing in a living-off-the-land attack looks wrong on its own. A remote management tool running is normal. That account being signed in is normal. That machine talking to cloud storage is normal. What is not normal is those three things happening in that order, on that host, at that hour. A tool that checks each one on its own will clear all three.

And make sure somebody is actually watching. This is the one I would put money on. In the investigations Bitdefender’s own incident response and MDR teams run, the same two findings come up again and again: either there was no endpoint detection deployed at all, or it was deployed and nobody was monitoring it – no security operations team, no managed service, nothing at the other end. A third version is the most frustrating, because it looks like success from the outside: the tooling works, the alert is raised, and it reaches nobody with the authority to stop what is happening. Detection that nobody is watching is not detection. It is a log file you will read afterward.

What they are actually shopping for

I would put it this way. Attackers are not shopping for a Lamborghini. They want a Toyota – something that starts every morning, that anyone on the crew can drive, that can be serviced anywhere, and that does the same job tomorrow as it did today. That is what ClickFix is. That is what living off the land is. Neither is impressive, and both are dependable, which is the only specification that matters when you are doing this ten thousand times.

Whatever attackers eventually do with AI, they will adopt it on exactly those terms: not when it becomes capable, but when it becomes cheaper than what already works. Until then, the doors they are actually walking through are the ones we can close.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.