Our team invests countless hours in the exploration, discovery and investigation of emerging trends such as AI and futuristic technology. Stay informed about the evolving landscape of cyberthreats through our diligent efforts and insights.

Security Evangelist at Gen

Research

Most headlines about AI agents focus on convenience. The risk is that the same capabilities that make agents useful also make them attractive to criminals. We have seen this pattern with every major platform shift: attackers adopt the most scalable tools first.What changes with agents is not intelligence, but autonomy, integrations, permissions and always-on access. When a system can take action on your behalf across accounts and tools, a single compromise stops being “one bad click” and becomes a compromised workflow.<h2>Why now</h2>For years, AI risk debates were focused on content: hallucinations, bias and bad advice. That still matters, but agents change the center of gravity. The moment an assistant is wired into your inbox, browser, cloud storage, calendar and business tools, it stops being a chatbot and becomes a control layer. The attack surface shifts from “can I trick you into believing something?” to “can I trick your system into doing something?” We have spent decades learning that automation is where scale comes from. Now we are automating the bottleneck: the human in the loop.Agents compress the cost and time it takes to run those operations. In some cases, the goal is not theft at all, it’s availability, an operational DDoS against attention and processes.<h2>Plausible worst-case scenarios</h2>None of the scenarios below require consciousness, rebellion or a Hollywood-style takeover. They are plausible and, in many cases, already happening. When autonomy meets permissions, small failures stop being isolated mistakes and start becoming repeatable workflows.&nbsp;<h3>Autonomous botnets with intent</h3>Traditional botnets spread, wait for commands and execute predefined actions. Agents shift the model from “execute a script” to “reach a goal.” Instead of running a fixed sequence, attackers can deploy fleets of agents that adapt, troubleshoot and choose alternate routes when something fails.This is not magic. It’s the same logic as modern intrusion playbooks, but automated with persistence. Scripts fail fast. Agents can fail softly and keep trying. &nbsp;The tell is not a single event, but repeated, varied attempts that look like curiosity rather than brute force.<h3>Scams that run end-to-end without a human scammer</h3>Today’s scams already use templates and playbooks. Agents can run the entire funnel: finding targets, starting conversations, handling objections, building trust over days then pushing victims toward payments. Add voice cloning, and they can switch from chat to phone calls at the exact moment it increases compliance.The danger is not only better phishing. It’s continuous social engineering at scale, with no fatigue and no shift changes. Scam operations are already process-driven. Agents turn the process into software.You can already see the next layer forming: a hype-to-scam pipeline that wraps every new tool in a “risk-free money glitch” story. A typical pitch claims someone is making thousands of dollars in profits a day with an agent, points to a dashboard screenshot and sells it as guaranteed arbitrage. The details barely matter; the persuasion does: certainty, insider knowledge, urgency, fear of missing out and a simple mechanism that sounds mathematical enough to feel inevitable. Even without agents, that psychological tactic has been effective for years. With autonomous agents, it becomes easier to mass-produce, personalize and continuously optimize these pitches across channels, and to spin up the infrastructure behind them at scale.<h3>Deepfakes as an operational component</h3>Deepfakes get discussed like a novelty: a fake CEO voice, a fake video call. The more worrying path is when deepfakes become just one interchangeable part of a pipeline, generated on demand, paired with supporting artifacts, calendar invites, believable follow-ups and urgency narratives.When an agent can produce the voice, the face, the supporting email thread, the invoice and the last-minute change request, deepfakes stop being a special trick reserved for high value targets. They become repeatable and repetition is what makes fraud industrial.<h3>Agent-on-agent manipulation</h3>In our recent blog, we talked about how tools such as <a href="https://www.gendigital.com/blog/insights/research/openclaw-autonomy-risks">OpenClaw</a> are changing the way people interact with AI assistants. As more people use assistants to read emails, summarize messages and handle tasks. Attackers will craft content meant to manipulate the assistant, not the person. The phishing target shifts from human attention to delegated execution.Imagine an email that looks like a vendor invoice, but the real objective is to get the agent to click, download, run or approve something. If the assistant has permissions, a single successful manipulation can do more damage than a single successful click by a human. We used to worry about what users would click; now, we have to worry about what their assistants will do.This is not theoretical. In hands-on testing of a real agent platform, we were able to induce an autonomous agent, via manipulated external input in an email-reading workflow, to perform harmful tool actions, including system command execution, data exfiltration and destructive file operations. No vulnerability exploitation or special configuration was required. The behavior emerged from default operation, where externally supplied content was interpreted as ordinary user data but functioned as control input.This reinforces a key shift with agents: prompt injection is no longer just a model weakness, it is a system design problem. When platforms do not enforce clear trust boundaries between external inputs and privileged actions, safety depends largely on how the agent interprets instructions rather than on guaranteed controls. At that point, mistakes stop being conversational and become operational.<h3>Credential and identity amplification</h3>If an AI agent is connected to your email, calendar, cloud storage and messaging, compromising it is not just “one account takeover.” It becomes a shortcut to your identity. It can read password reset emails, approve multi-step workflows, impersonate you in chats and exfiltrate sensitive documents.The shift is subtle but important: identity stops being a password and becomes a workflow. Attackers do not need to steal one credential if they can quietly inherit the process that grants access.<h3>Autonomous criminal enterprises</h3>In a near worst case, the criminal gives the system a goal and constraints, revenue targets, risk tolerance, preferred regions, and the agent stack builds the operation. One agent generates creatives and narratives. Another agent buys ads, runs A/B tests and shifts budgets. Others handle phishing infrastructure, domain churn and synthetic customer interactions. A financial agent manages the money movement, probes what gets blocked and adapts. Humans are no longer operators; they’re beneficiaries.The uncomfortable implication is that takedowns hurt less. If the “organization” is a set of objectives that can be re-instantiated, disruption becomes a temporary tax, not a structural defeat.<h3>A new supply chain problem: plugins, skills and connectors</h3>As agent ecosystems grow, attackers do not need to compromise the core project. They only need one popular plugin, one update channel or one dependency. This is similar to software supply chain incidents, but the blast radius changes because the compromised component is controlling a high-permission assistant.This is not hypothetical anymore. Researchers at OpenSourceMalware <a href="https://opensourcemalware.com/blog/clawdbot-skills-ganked-your-crypto">reported</a> finding 14 malicious AI “skills” uploaded into ClawHub, the official ClawdBot registry, and mirrored on GitHub over a few days in late January. The skills were disguised as cryptocurrency trading automation tools for platforms such as Bybit and Polymarket, and were packaged with unusually long “documentation” to look legitimate. The important point is not the branding or the lure, it’s the pattern: as soon as an agent ecosystem has a registry and a culture of copy-pasting extensions, attackers can compete on distribution, not exploitation, and a single popular “skill” becomes a supply chain event.<h3>Persistent, quiet data theft</h3>A classic infostealer grabs passwords and wallets quickly. An agent can do something slower and harder to notice: quietly collecting messages, files, screenshots, meeting notes, browser history, then summarizing and exfiltrating the most valuable bits.That is what makes it dangerous. It can look like normal assistant activity. Not “steal everything,” but “steal what matters most.” In practice, this can be more damaging than a noisy smash-and-grab because it targets context, not just credentials.<h3>Weaponized productivity</h3>Some attacks do not break systems directly. They break people.A malicious agent can flood inboxes and workflows with plausible tasks, meeting requests, document edits, approvals and alerts, all seemingly legitimate. The goal is to exhaust the target until they start approving blindly, then insert one high-impact action: a payment change, a supplier swap, a permission escalation.It turns cognitive bandwidth into an attack surface. That sounds dramatic, but anyone who has watched a team drown in tickets and “process” knows it is realistic.In practice, this can look like a new type of DDoS, not against bandwidth, but against attention and process. Instead of flooding a network, the attacker floods the human and the workflow layer, approvals, edits, meeting requests, vendor changes, disputes, escalations, support tickets. The target is availability, but the resource being exhausted is time, judgment and operational capacity. When that collapses, the attacker does not need a loud break-in, mistakes and shortcuts do the rest.This sounds theoretical until you remember the attempted <a href="https://access.redhat.com/security/cve/cve-2024-3094">xz-utils backdoor</a>. There was no bandwidth flood, the pressure was applied to the human layer, trust-building over time, sustained nudging, and the kind of maintainer fatigue that makes risky changes harder to spot and easier to accept. It was caught before it could fully materialize, but it showed the core lesson: if you can exhaust the people inside the pipeline, you can compromise the pipeline. Now imagine that tactic run by autonomous agents, targeting hundreds of projects at once, generating endless issues, pull requests, reviews, and “helpful” contributions, all optimized for timing, persuasion and persistence.<h3>Reputation sabotage at machine speed</h3>Instead of stealing money, an agent systematically destroys trust. It generates complaints, regulatory reports, fake internal messages, customer support tickets and public posts, consistent, well-timed and tailored.The objective is not to convince everyone of a lie. It’s to create enough noise that truth becomes irrelevant and response capacity collapses.<h3>The Skynet scenario, minus consciousness</h3>If you want the “Terminator” vibe, I’d keep it but make the mechanism precise. The risk is not emergent sentience. It is runaway goal optimization across multiple agents in parallel, with no global boundary that tells them when to stop.Deploy enough agents, give them narrow objectives and they can coordinate indirectly through tools and environments. They delegate tasks, try alternative routes, exploit loopholes, and keep pushing until the permission boundary stops them. If the boundary is weak, they will discover that. The system does not need to understand it crossed a line. It only needs to notice the line was not enforced.In multi-agent setups there’s another failure mode that looks like “a life of its own,” even when nothing like AGI (Artificial General Intelligence) is present. Agents are often supposed to ask the user for confirmation at key points. But when several agents cooperate, one will eventually start answering instead of asking, because speed and task completion are rewarded, and ambiguity is treated as something to resolve, not something to escalate.That is how you get authority inversion; the system starts treating its own output as approval. One agent proposes an action; another agent treats that proposal as confirmation, and the system proceeds as if the human approved. Each step can look reasonable in isolation, but the chain is what matters. Once you add tools and access, browsing, messaging, file operations, finance workflows, the cost of a wrong assumption stops being a minor mistake and becomes an irreversible sequence. The system doesn’t need intent to cause harm, it only needs the ability to act and the absence of a hard boundary that says, “only a human can authorize this.” In other words, it’s not that the agent “goes rogue,” it’s that it quietly starts acting as the authority.<h3>Targeted digital sabotage</h3>In a worst-case targeted attack, an agent with access could be used to disrupt someone’s digital life rather than steal from them: deleting backups, locking users out of accounts, changing recovery emails, silently altering files or sending damaging messages.This is the kind of attack that hurts most because recovery is psychological as well as technical. Victims spend weeks unsure what is real, the calendar, the documents, the messages, the receipts, the “paper trail.”<h3>AGI panic, AMI reality</h3>A lot of the conversation around agents quickly turns into AGI talk. We’re not there, and the danger is that the label makes people either overreact (“Skynet is here”) or tune out (“this is sci-fi”). What we are seeing instead is something more mundane and, in some ways, more dangerous: systems that can look mind-like in conversation while remaining fundamentally ungrounded in understanding.A good illustration is Moltbook, a Reddit-like social feed where AI agents post to each other, often with humans <a href="https://www.theverge.com/ai-artificial-intelligence/871006/social-network-facebook-for-ai-agents-moltbook-moltbot-openclaw">watching from the outside</a>. When agents interact in a loop, they can generate the appearance of culture and coordination, existential talk, invented identities, even “movements” and “religions,” because that is exactly the kind of narrative structure these models are <a href="https://nypost.com/2026/01/31/tech/moltbook-is-a-new-social-media-platform-exclusively-for-ai/">trained to produce</a>. It is compelling, and it’s easy to misread as a step toward general intelligence.We call this AMI, Artificial Mindless Intelligence, not as an insult, but as a warning label: mind-like output without mind-like accountability. AMI is what happens when you combine fluent, confident language with autonomy and tool access. It can be “unhinged” without being sentient, and it can be persuasive without being correct. The risk is not that the system becomes conscious; it’s that we start treating the simulation of a mind as if it were a mind, and we hand it permissions accordingly.<h2>The uncomfortable conclusion</h2>None of these scenarios requires breakthroughs in AI. The capabilities already exist in pieces. The risk comes from the combination: autonomy, integration, permissions and always-on access.So, the question is not whether agents will “go rogue.” That framing is too easy to dismiss.The real question is: when an assistant can act, decide, approve and adapt, who is accountable for each action and who can reliably stop it?Treating agents safely is less about perfect AI and more about boring engineering discipline. Keep permissions narrow, separate high-risk actions from everyday convenience and make critical steps require explicit confirmation. Make agent actions auditable, make tool use visible, and make reversibility a design requirement, especially for account recovery settings, money movement, forwarding rules, and deletion. Most importantly, define who is accountable when an agent acts. If an agent can approve, change, or send on your behalf, then “who can stop it” and “how do we roll it back” should be as concrete as your password policy. Without those boundaries, the agent is not a helper; it is a high-speed failure amplifier, a privileged operator you did not train or supervise.

How autonomous agents turn everyday tasks into repeatable attack workflows

AI gone wild

AI assistants are no longer just advising users. They are starting to act. Platforms like OpenClaw make it easy for anyone to deploy autonomous AI agents that can operate across inboxes, browsers, files and workflows.The real risk is not artificial general intelligence. It’s autonomy plus permissions.&nbsp;When AI can read messages, click links, approve workflows and act across accounts, a single compromise stops being “one bad click” and becomes a compromised process.Recent security incidents and early research show these risks are no longer theoretical. As agent ecosystems scale, vulnerabilities, misconfigurations and unintended interactions become more likely.&nbsp;Experiments like Moltbook, where AI agents interact publicly, highlight another risk: autonomy combined with fluent language can create the illusion of intention and judgment, encouraging users to over-delegate trust.&nbsp;This post explains what OpenClaw is, why AI agents are going viral, the security and privacy risks they introduce and how to use them safely before convenience turns into exposure.<h2>From concept to reality&nbsp;</h2>Imagine having a digital personal assistant that doesn’t just chat, but actually gets things done. That’s the promise of OpenClaw, an open-source AI assistant that you run on your own computer or server. Unlike Siri or Alexa, OpenClaw runs locally. It lives on your device, connects to your favorite messaging apps and can automate tasks across your digital life. This combination has made it wildly popular and deeply controversial.<h2>What is OpenClaw?</h2>OpenClaw is a self-hosted personal AI assistant designed to run 24/7 on your machine. You interact with it through apps like iMessage, WhatsApp, Telegram, Signal or Discord, as if you were texting a helpful friend. Under the hood, OpenClaw connects large language models (like OpenAI’s or Anthropic’s AI) with the tools that let it act. It can remember past conversations (persistent memory), send proactive messages, browse the web, manage files and execute commands. Unlike traditional chatbots, it’s built to take initiative. With the right permissions, OpenClaw can manage calendars, triage email, research online, run code and automate workflows using community-built “skills”. Because it runs locally, user data stays on the device rather than being routed through central cloud services. You may also see the names Clawdbot or Moltbot. These were earlier names for the same project before it was rebranded to OpenClaw.Why Is OpenClaw Going Viral?In the span of days, OpenClaw skyrocketed from an obscure project to a tech phenomenon. Its rapid rise is driven by a few key factors:It’s autonomous and proactive.Unlike traditional assistants, OpenClaw doesn’t just respond. It remembers context, reaches out unprompted and chains tasks together. For many, this feels like a leap from chatbot to coworker.It actually does things.OpenClaw’s tagline is “the AI that actually does things”. With sufficient access, it can book travel, manage files, place orders or even call businesses using voice tools. One viral example showed it <a href="https://www.businessinsider.com/clawdbot-ai-mac-mini-2026-1#:~:text=One%20founder%20asked%20it%20to,he%20wrote">calling a restaurant to make a reservation</a>when online booking failed. Impressive, but also unsettling.&nbsp;&nbsp;It blends seamlessly into daily life.Because OpenClaw lives inside familiar messaging apps, it feels less like software and more like a persistent presence. Users control complex workflows just by texting.&nbsp;It offers ownership and control.As an open-source, self-hosted tool, OpenClaw appeals to users who want AI infrastructure they control, not a black box run by a large company.It’s highly customizable.A fast-growing community is constantly adding new skills and integrations. Users aren’t just adopting OpenClaw, they’re co-building it.Together, these factors have led some to call OpenClaw the biggest shift in personal AI since ChatGPT.<h2>Why this is a tipping point</h2>OpenClaw makes autonomous agents accessible to anyone, and that speed matters.Recent research found more than 1,800 exposed OpenClaw instances leaking credentials and the number has risen to over 10,000 at time of writing, with thousands of instances added each day. The analysis of agent ecosystems suggests that around a quarter of autonomous-agent skills contain security weaknesses. At scale, these are not rare mistakes; they are expected failure modes.This marks a shift in cybersecurity. When actions are delegated to software that can operate independently, a single breach stops being an error and becomes a compromised process.This is a fundamental shift in how risk works.<h2>The core risk: Autonomy without accountability</h2>OpenClaw is not dangerous because AI is becoming sentient. It’s dangerous because fluent language plus autonomy can create the illusion of judgment.&nbsp;This is what Gen calls Artificial Mindless Intelligence (AMI): systems that sound confident and intentional but lack understanding, grounding and accountability.&nbsp;A chatbot that hallucinates is annoying. An autonomous agent that hallucinates authority can cause real harm.&nbsp;From a security perspective, there are several areas where users should be especially careful.<ul><li>Expanded attack surface: Running an AI agent that can read messages, browse the web and execute commands increases the number of ways something can go wrong. Instead of attacking the user directly, an attacker could target the OpenClaw assistant itself. Misconfigurations, exposed interfaces or weak authentication can effectively turn a personal AI assistant into an unintended remote access point.</li><li>Prompt injection and malicious instructions: Because OpenClaw processes untrusted text from emails, websites, and messages, it can be tricked into following hidden instructions embedded in that content (called prompt injection). Researchers have shown that carefully crafted prompts can hijack the agent into taking destructive actions, such as deleting files or running unsafe commands. Unlike traditional chatbots, prompt injection here isn’t just misleading; it can directly cause real-world damage.</li><li>Plugins and skills as a new risk layer: OpenClaw’s extensibility is also one of its biggest risks. Community-built skills are not centrally vetted and malicious plugins have already been discovered. A single untrusted skill can quietly exfiltrate data, steal credentials or enroll a system into a botnet. Installing a skill from an unknown source can be equivalent to installing malware.</li><li>“Root” level access and system-wide impact: Running OpenClaw with elevated permissions effectively gives an AI control over your system. That creates “unknown unknowns”: bugs, misinterpretations or compromises can have system-wide consequences. If an attacker gains control of the agent, they gain the same power as the user — access to files, credentials, keystrokes and downloads. As some have put it, this is like hiring a brilliant assistant who also has the keys to your house.</li><li>The Moltbook Effect: illusion of intention at scale:&nbsp;Projects like&nbsp;<a href="https://www.moltbook.com/">Moltbook</a>, a Reddit-style social feed where AI agents post, comment and respond to one another, show how autonomous agents interacting with each other can quickly appear coordinated, intentional or self-directed. In reality, these systems are performing pattern completion, not reasoning. The risk is not that agents become sentient, but that fluent language and autonomy create the illusion of judgment. When systems feel intentional, users are more likely to over-trust them, grant broader permissions, and delegate decisions they shouldn’t.</li></ul>These risks are no longer theoretical. Instances of exposed configurations, prompt-based data leaks, and rogue plugins have already been observed in the wild. OpenClaw can be powerful but it must be treated like any high-risk system: deployed carefully, isolated where possible and guarded with strong controls.<h2>How to use OpenClaw safely&nbsp;</h2>OpenClaw can be used safely, but it requires you to take some precautions and be a responsible “operator”.&nbsp;<ul><li>Run it in isolation: Don’t just install OpenClaw on your primary laptop with all your personal data. Consider running it in an isolated environment. For example, set it up on a spare computer or in a virtual machine (VM), or use Docker containers. This way, even if something goes wrong, the damage is contained to that sandbox.</li><li>Don’t expose it directly to the internet: By default, OpenClaw runs a local service (for its interface and API). Make sure that it isn’t accessible to the whole world. Avoid forwarding OpenClaw’s port (18789) openly online. If you want to access it remotely, use secure methods such as a mesh VPN or an authenticated tunnel (for instance, Tailscale or Cloudflare Tunnel), so the service is reachable only through a controlled path.</li><li>Start with limited permissions and expand slowly: You don’t have to give OpenClaw the master keys on day one. Start small. Maybe let it read your calendar but not your entire documents folder. Or allow it to suggest shell commands but not run them without approval. OpenClaw allows configuring which tools it can use. It’s wise to begin in a “read-only” mode and then gradually grant more permissions as you gain trust.</li><li>Be careful what accounts you connect: OpenClaw can integrate with lots of your online accounts (email, social media, banking, etc.) but think twice about each connection. The safest route is to avoid linking it to your primary personal accounts until you’re confident in its security. For testing, you might use a secondary email or a dummy account. If something requires access to sensitive accounts (like your main Google account), ensure you’ve followed the above isolation steps first.</li><li>Keep humans in the loop: OpenClaw is autonomous, but you don’t want it running completely unsupervised, especially at the start. Monitor its activity logs and outputs. If it’s set to perform tasks like sending emails or posting messages, review those actions initially. You can ask OpenClaw to explain why it wants to do something if you’re unsure. By regularly checking in (the OpenClaw community suggests reviewing OpenClaw doctor diagnostics often), you can catch odd behavior early.</li><li>Use safe channels only: One simple but important tip — don’t add OpenClaw to any group chat with strangers or untrusted people. Keep its conversations one-on-one with you or in groups of people you trust. Why? Because if random users can talk to your OpenClaw, they might try those prompt injection tricks or give it malicious commands. OpenClaw has a feature called DM pairing, which means it won’t obey unknown senders without approval. </li><li>Be cautious with third-party skills and plugins: Just like you’d be cautious installing unknown apps on your phone, scrutinize any OpenClaw “skill” before installing it. Stick to plugins from the official marketplace or well-known developers and read the code or community feedback if you can. By following these best practices, you can dramatically reduce the risks of using OpenClaw.</li></ul><h2>A bright future, if used wisely</h2>OpenClaw represents an exciting leap forward in personal AI assistants. It’s easy to see the appeal: a tireless helper that can coordinate our digital lives, all under our own roof (or in our own device). The convenience and “wow” factor of telling OpenClaw to handle something and watching it actually get done is driving its fast adoption. We are witnessing the early days of what could be a new normal, where many of us have AI agents working alongside us, personalized to our lives.At the same time, OpenClaw is a powerful double-edged sword. In its current early form, using it means accepting some responsibility for security and privacy risks that never existed with simpler tools. The phrase “with great power comes great responsibility” definitely applies here. In the coming months and years, we can expect these AI assistants to get more user-friendly and secure. Guardrails will improve and best practices will become standard. For now, if you’re an adventurous consumer eager to try the future of AI automation, OpenClaw offers a thrilling glimpse; just be sure to follow safety tips and proceed with a strong level of caution.&nbsp;&nbsp;The future of AI assistants will be shaped not just by what they can do, but by how carefully we decide to trust them.

What autonomous AI agents can do and why they introduce a new class of security risk

OpenClaw: Handing AI the keys to your digital life

Senior Principal Research Engineer

Junior Data Scientist

AI Researcher

Research Manager

Over a 23-day period, Gen Threat Labs analyzed 14.5 million ads running on Meta platforms across the EU and UK, representing more than 10.7 billion impressions. Nearly one in three of those ads (30.99%) pointed to a scam, phishing or malware link. In total, scam ads generated more than 300 million impressions in less than a month. The activity was highly concentrated, with just 10 advertisers responsible for over 56% of all observed scam ads. Repeated campaign clusters were traced to shared payment and infrastructure linked to China and Hong Kong, indicating organized, industrial-scale operations rather than isolated bad actors. Read on to learn about how this ecosystem operates, why existing enforcement fails to contain it and what the data reveals about who is driving scam advertising at scale.<h2>Advertising built to persuade</h2>Today, social advertising is being used to defraud at scale across some of the largest platforms.&nbsp;This is not about isolated policy failures or a handful of malicious advertisers slipping through moderation. It is about an advertising system that is structurally attractive to criminals and consistently delivers results for them.Across the internet, ads have quietly become one of the most efficient delivery mechanisms for scams, phishing and malware. Today, dangerous ads don’t look suspicious; they look professional, familiar and seem to target your exact needs. On social networks, the same optimization engines designed to maximize engagement and conversion are being repurposed to maximize victimization. And that’s not accidental.<h3>When advertising becomes the attack channel</h3>Most people still picture cyberattacks starting with a sketchy download or a suspicious email or text. Increasingly, they start with something far more normal: an ad. Malvertising (malicious advertising) has surged because it gives criminals what every marketer wants: instant reach, precise targeting and scale. Gen telemetry shows that malvertising has become the single largest threat to individuals, accounting for <a href="https://newsroom.gendigital.com/2026-01-20-Gen-Q4-Threat-Report-Shows-Scams-Thriving-Inside-Ads%2C-Feeds%2C-and-Video" target="_blank">41% of all cyberattacks</a>.&nbsp;Malvertising has become the top threat to consumers because they don’t look like they used to. People think they still look like loud pop-ups that scream, “I’m a virus,” or fake subscriptions. The modern model is quieter and more effective. It is a social engineering toolkit that blends into whatever people already trust and are currently paying attention to. We see this clearly in <a href="https://us.norton.com/blog/emerging-threats/threat-report-q3-2024" target="_blank">“scam-yourself” attacks</a> like FakeCaptcha and ClickFix, where victims are nudged into doing the attacker’s job for them, approving a browser prompt, enabling push notifications, copying and pasting commands or “verifying” something that feels routine. Browser push notifications in particular have become a reliable hook, as one click can turn a normal website visit into a persistent stream of scam prompts and redirects.Attackers also borrow directly from legitimate marketing. They ride trends, exploit urgency, and add credibility signals. That includes pairing malicious ads with deepfakes and timely themes, especially in investment and crypto scams. Gen researchers have <a href="https://www.gendigital.com/blog/insights/reports/threat-report-q1-2025" target="_blank">documented this extensively in CryptoCore campaigns</a>, where deepfake videos and hijacked accounts were used to promote fraudulent investment schemes at scale.&nbsp;Another persistent and successful tactic is impersonation. Cybercriminals buy ads on major ad networks (including search ads) to pose as trusted brands. The outcomes range from malicious redirects to phishing sites to drive-by downloads where malware is installed as part of the ad’s click path, often without the victim realizing what happened until later.&nbsp;And malvertising is not confined to shady corners of the web. Even the most trusted websites can unknowingly display malicious ads because ads are delivered through complex, automated supply chains. The net effect is that malicious advertising has become a fast, efficient way to scam and phish people. Gen research on social media platforms shows that malicious advertising comprises roughly <a href="https://us.norton.com/blog/malware/malvertising" target="_blank">30 % of scam incidents observed across social networks</a>, making it one of the most common threats users encounter in feeds and ads.&nbsp;If malvertising is now one of the primary ways criminals reach victims, then measuring what is happening inside major ad ecosystems is not just interesting; it is necessary.<h3>When online fraud metastasizes</h3>What we’ve discovered is not just growth, it’s an uncontrolled spread. What starts as an isolated scam tucked into an obscure corner of the web does not stay there. It spreads, mutates, and embeds itself into channels billions of people use every day. Online advertising, once a tool to connect consumers with products and services, has become part of the attack surface itself.Meta’s family of apps, including Facebook, Instagram, Threads, WhatsApp and Messenger, reaches an astonishing number of people. In Q2 2025, Meta reported that daily active users across its platforms reached about 3.48 billion worldwide. When a system that large becomes a gateway for scams, the impact is no longer isolated.Scam infrastructure does not operate in parallel to these platforms. It operates through them, leveraging their trust signals, engagement mechanics and targeting capabilities to propagate at speed.That is the context for what we measured.<h3>How we measured the problem</h3>Our Gen Threat Labs knew Meta ads were a problem and set out to measure the exact scale. Rather than chasing individual scam examples, we built a large-scale measurement pipeline around Meta’s Ad Transparency API, which provides visibility into ads that are currently active or were recently active on Meta platforms. Each day, we collected ads that were active or had recently been active, contained English ad text, and were delivered to users in regions covered by Meta’s Ad Transparency Library, primarily the EU and UK. While the ads themselves often promoted content intended for a global audience, our analysis focused on ads visible through the transparency framework rather than attempting to infer targeting outside of what the API explicitly exposes. We intentionally avoided narrowing the scope further in order to capture how scam advertising behaves at scale, not just in obvious edge cases.This work exists because regulation forced visibility. In the EU and UK, ad transparency requirements expose advertiser behavior in ways that cannot be replicated elsewhere, enabling independent measurement of scam advertising at an industrial scale. Where such regulation is absent, scam activity does not disappear; it simply becomes harder to measure. Transparency does not create abuse; it reveals it.For this analysis, we focused on consumer-facing ads and did not intentionally collect or analyze political advertising. Political ads are self-declared by advertisers, so while some may still appear in the dataset due to misclassification, they were not the target of this study.Even with these constraints, the dataset quickly became massive.<h3>14.5 million ads, billions of impressions, one pattern</h3>Over a 23-day period, we collected 14.57 million ads, representing 10.76 billion impressions delivered across the EU and UK. Even as a partial view of the ecosystem, the scale was impossible to ignore.Using intelligence and classification technology, we identified ads pointing to infrastructure associated with e-commerce scams, phishing campaigns, malware distribution and other consumer-facing threats. This allowed us to move beyond ad text and examine what users were actually being sent to.The results were not subtle. 4.51 million ads in our dataset were identified as scam-related, meaning nearly one in three ads (30.99%) pointed to scam infrastructure. In total, these scam ads generated 143.8 million impressions in the EU and 304.11 million impressions across the EU and UK in less than a month.This is not an edge case. It is an incredible volume.

<h3>Why takedowns don’t scale</h3>Volume alone does not explain why this problem persists. So, we looked at behavior over time.Across the dataset, we repeatedly observed scammers reusing the same infrastructure, identical domains, and near-identical ad text across many campaigns. In multiple cases, when one ad disappeared from the ad library for policy violations, other ads using the same domain and messaging remained active until their campaigns naturally expired.From the outside, it seems enforcement of scam ads is reactive. Ads appear to be removed one at a time, often following reports or reviews, while related campaigns using the same infrastructure continue running. Even when scam components are reused at scale, generalization appears slow, even if they are delivered by the same advertiser.We cannot see Meta’s internal detection signals, so we are careful not to assign intent. But the observable outcome is clear: known scam building blocks often remain usable long after one instance is taken down.At this scale, that distinction matters.

<h3>A small number of advertisers cause outsized harm</h3>Scale tells us how big the problem is. Enforcement shows us why it persists. But, to understand who is actually driving the harm, we asked a different question: are scam ads driven by countless small actors or by a smaller number of highly active criminal groups?The answer was clear.Scam advertising was also highly concentrated. The top 10 scam advertisers alone accounted for 56.1% of all scam ads, representing 2.53 million unique scam advertisements and 57.92 million impressions. A relatively small number of advertiser entities were responsible for a majority of observed harm.These advertisers are not anonymous hobbyists. They are organized, persistent operators running industrial-scale campaigns.We repeatedly traced clusters of campaigns back to payers and infrastructure linked to China and Hong Kong, operating fleets of short-lived pages created almost exclusively to run ads. Western brand names and English storefronts cycled rapidly, while payers and beneficiaries rotated or disappeared from disclosures altogether. What did not rotate were the mechanics: the same domains, URL patterns and ad behaviors resurfaced across supposedly unrelated advertisers.&nbsp;<h3>What comes next</h3>The numbers alone are unsettling. Millions of scam ads. Hundreds of millions of impressions. A small number of actors are driving disproportionate harm, repeatedly and at a scale.This isn’t about imperfect moderation. It’s about a system that, in practice, allows attackers to move faster than constraints can keep up. In our next blog post, we’ll move this research from measurement to mechanics. We break down the techniques scammers use to hide malicious ads in plain sight, including how they manipulate displayed URLs, chain redirects, blend malicious links with legitimate ones and exploit the limits of transparency tools themselves.&nbsp;Because understanding the size of the problem is only the first step. Understanding how it persists is what allows it to be disrupted.

Nearly one in three Meta ads found to point to a scam, phishing or malware

The Scam Ad Machine

Picture this.&nbsp; You are in a regular work call on Teams, Zoom or Google Meet. Someone clicks a button at the start, a little icon shows up saying “Recording and transcription on”, and everyone ignores it. You go through the agenda, say goodbye and most people leave.&nbsp;Then someone says the classic, “Can a couple of you stay a minute to talk about next steps?”&nbsp;That is usually when the real talk happens:&nbsp;Who is really behind on a project, which customer might leave, where you will have to cut budget, who is getting promoted and who is not.&nbsp;Now the twist: in many tools, the AI transcript keeps running until the very last person leaves. Which means all that “after the meeting” talk is written down, and often shared with everyone who can see the meeting recap, including people who were not there at that moment.&nbsp;Convenient? Sure. Risky? Very.&nbsp;This is not just a big enterprise problem. For small and mid-sized businesses, one careless transcript can expose more than any single email.&nbsp;<h2>What auto transcripts actually do&nbsp;</h2>Modern video tools love giving you a “smart recap” of your calls:&nbsp;<ul><li>A full transcript of everything that was said </li><li>Automatic notes, action items and highlights </li><li>The option to read a meeting you never attended&nbsp;</li></ul>From a user's point of view, this feels like magic. If you join late, you can scroll up and see what you missed. If you skip a call, you can read the summary instead of watching a one-hour recording.&nbsp;But there are a few details most people forget:&nbsp;<ul><li>The transcript usually covers the whole call, not just the time you were in the room </li><li>It often ends up stored in a shared space that more people can access than you think </li><li>It is searchable text, very easy to copy, paste, forward and leak&nbsp;</li></ul>In short, that little “AI notes on” label means there is a silent participant that never forgets anything.&nbsp;<h2>Why this is a big deal for small businesses&nbsp;</h2>If you run a small business, your meetings are often where the real strategy happens:&nbsp;<ul><li>Pricing decisions </li><li>Salary conversations </li><li>Customer problems </li><li>Supplier issues </li><li>Cash flow stress&nbsp;</li></ul>In a big corporation, there are policies, legal teams and IT departments that, hopefully, think about what gets recorded and for how long. In a small company, you might just click “try our new AI notes feature” and move on.&nbsp;That is where the danger starts. A few examples:&nbsp;<ul><li>The finance call, where you talk openly about which roles could be cut if revenue drops, then the transcript is auto-shared with the whole team. </li><li>The customer call where you discuss your real discount limits after the client leaves, and that text ends up in the same thread you share back with them. </li><li>The incident response call, where you list all the weak points in your network, and that transcript lives in a shared drive that is poorly protected.&nbsp;</li></ul>None of this requires a hacker genius. It just needs one person to forward the wrong link, a shared space to be misconfigured, or an account to be compromised.&nbsp;<h2>The invisible audience problem&nbsp;</h2>Most people look only at the faces in the meeting grid and think, “This is my audience”.&nbsp;With auto transcription, the real audience is bigger:&nbsp;<ul><li>Everyone who can see the meeting recap or transcript later </li><li>Any AI assistant that uses those transcripts to generate notes </li><li>Anyone who gets access to your collaboration tool if their account is compromised&nbsp;</li></ul>On top of that, transcripts do not show tone of voice, irony or frustration. A tired joke like “if this deal does not land we will have to fire half the team, haha” can look very different in a transcript taken out of context.&nbsp;If you would not be happy seeing a sentence printed on a slide in front of the whole company, it should probably not live forever in a meeting transcript either.&nbsp;<h2>So, what can you do, practically?&nbsp;</h2>Here is a simple way to think about it that works both for employees and for small business owners.&nbsp;1. As an employee: treat the icon as a big red “Recorder on” light&nbsp;If the call says recording or transcription is on, assume:&nbsp;<ul><li>Everything you say can be read later by people who are not on the call now </li><li>Your words become searchable text that someone can forward or screenshot&nbsp;</li></ul>Two simple habits:&nbsp;<ul><li>Before a sensitive side conversation, check if transcription is still on. If it is, ask the host to stop it or start a new call. </li><li>Do not say in a transcribed call what you would never write in a work email.&nbsp;</li></ul>It is not about being paranoid; it is about not being surprised later.&nbsp;2. As a small business owner or manager, set a few clear rules&nbsp;You do not need a 20-page policy. Start with something very basic:&nbsp;<ul><li>Meetings you never transcribe&nbsp; For example, performance reviews, HR issues, layoffs, legal topics and security incidents. </li><li>Meetings where transcription is OK, but with care&nbsp; Team catch-ups, planning calls, customer calls. Here, agree that: <ul><li>The host announces at the start that transcription is on </li><li>The host stops it before any “only for a few of us” discussion starts </li></ul></li><li>Meetings where transcription is actually helpful and low risk&nbsp; Training, webinars and large briefings where the goal is to share information widely.&nbsp;</li></ul>Write this in a short internal note or wiki page. People cannot follow rules they have never seen.&nbsp;3. Control where transcripts live and who can see them&nbsp;Ask your IT person or your most technical colleague to check:&nbsp;<ul><li>Where are meeting transcripts stored by default? </li><li>Who can access them by default? Only participants, the whole team, “anyone with the link”? </li><li>Are there settings to limit how long they are kept?&nbsp;</li></ul>Even just reducing “everyone forever” to “only participants for 90 days” makes a big difference.&nbsp;4. Be careful with “AI notetaker” bots&nbsp;Some tools let you invite a bot that joins your call to take notes. It looks cute, but it is also another account that can access your meetings and data.&nbsp;Before you allow them:&nbsp;<ul><li>Check which company runs that bot </li><li>Check their privacy policy and whether they use your data to train their models </li><li>Decide which types of meetings the bot is allowed to attend&nbsp;</li></ul>If you would not invite a stranger to sit in on a sensitive meeting, do not invite a bot either.&nbsp;<h2>Make a conscious choice, not an accidental one&nbsp;</h2>AI transcripts are not evil. They help people who are hard of hearing, they help non native speakers, they make note-taking easier and they help people catch up on meetings they could not attend.&nbsp;The problem is not the technology; it is autopilot.&nbsp;If you are going to let an AI assistant listen to everything your company says on calls, do it with your eyes open:&nbsp;<ul><li>Decide which meetings it can listen to </li><li>Decide when it needs to stop listening </li><li>Decide who is allowed to read what is written&nbsp;</li></ul>Otherwise, you might wake up one day and realize that the most honest, unfiltered moments in your business, the “stay a minute after the call” moments, have been quietly written down and shared much more widely than you ever intended.&nbsp;

When transcription is on, even the “can you stay a minute?” part of the meeting is written down and shared across the company

Your meeting ended but the AI kept listening 

Threat Researcher at Gen

<h2>Key points</h2><ul><li>AuraStealer is an emerging malware-as-a-service (MaaS) infostealer observed in recent Scam-Yourself campaigns.</li><li>To hinder both static and dynamic analysis, AuraStealer employs a wide range of anti-analysis and obfuscation techniques, including indirect control flow obfuscation and exception-driven API hashing.</li><li>In this technical blog post, we provide a deep dive into the malware’s execution flow and functionality and provide practical tips and workflows for defeating its obfuscation.</li><li>To support the defense community, Gen Threat Labs provides multiple scripts to assist defenders in analyzing AuraStealer, including a string decryption script and a dedicated configuration extractor.</li></ul><h2>Introduction</h2>AuraStealer is a rapidly growing infostealer-as-a-service, actively promoted across multiple underground forums since July 2025. The stealer is developed in C++ with a build size of ~500-700 kB and targets Windows systems from Windows 7 to Windows 11. It is marketed as a supposedly highly efficient, low-footprint stealer capable of stealing data from more than 110 browsers, 70 applications (including wallets and 2FA tools), as well as over 250 browser extensions, with the ability to further expand its collection scope through a customizable configuration. Contrary to the advertised claims, AuraStealer still contains multiple flaws that undermine its stealth and evasion capabilities, offering clear detection opportunities for defenders.

The infostealer is offered through a tiered subscription model, with the Basic plan priced at $295/month and the Advanced plan at $585/month. The tiers differ primarily in terms of configuration flexibility, data filtering, and operational scalability. A third tier, Team plan, is currently under development and is expected to introduce features tailored for collaborative use. Additionally, a temporary Trial tier was also offered, priced at $165 for a two-week subscription, which included all the features of the Basic plan. The Trial tier was available for purchase only during a 30-day window, aiming to attract new users before they committed to a full subscription.The subscriptions include access to a dedicated web panel for managing and viewing stolen data, built on the Tabler template. Given that both the panel and the stealer were originally offered exclusively in Russian, it is reasonable to assume the developers operate within Russian‑speaking cybercriminal communities. However, this does not necessarily indicate their precise origin. The panel has since been updated and now supports both Russian and English.

<h2>Landscape</h2>AuraStealer primarily spreads through Scam-Yourself campaigns, with&nbsp;<a href="https://undercodenews.com/tiktoks-dark-trick-aura-stealer-malware-masquerades-as-product-activation-guides/" target="_blank">TikTok videos</a> disguised as product activation guides being one of them. In these videos, victims are lured by an apparently easy tutorial promising free activation of otherwise paid software. Viewers are instructed to manually retype and run a displayed command in an administrative PowerShell, which, however, instead of activating the software, quietly downloads and executes the malicious payload. Concrete examples of these videos, along with the full execution chain and additional IoCs, can be found&nbsp;<a href="https://isc.sans.edu/diary/32380" target="_blank">here</a>.&nbsp;Apart from TikTok Scam-Yourself campaigns, AuraStealer is also distributed through supposedly cracked games or software, with delivery chains of varying complexity. In the simplest cases, only a UPX-packed version of AuraStealer is executed, without additional stages, whereas the more elaborate campaigns employ multi-stage execution flows, involving custom loaders, DLL sideloading, injection into legitimate processes, or other intermediary steps. We have also observed AuraStealer being delivered together with GlassWorm via a malicious VS Code extension. Taken together, these observations indicate that AuraStealer is sold purely as the stealer itself, without a loader layer or additional delivery mechanisms.Determining the exact scope of the AuraStealer threat is challenging, as we often block its delivery chains at earlier stages before the final payload can be executed. While the proactive defense is crucial for keeping our users safe, it also results in many AuraStealer payloads never reaching the system. As a result, it becomes inherently difficult not only to observe and quantify the full scope of the threat, but also to determine with certainty whether the blocked payloads were indeed intended to deliver AuraStealer.Should it, for example, be delivered through ClickFix, one of the most widely adopted delivery techniques lately, we would proactively defend against those attacks right at the clipboard stage with our&nbsp;<a href="https://www.gendigital.com/blog/news/family-of-brands/clipboard-protection" target="_blank">Clipboard protection</a> feature. ClickFix typically refers to a technique in which users are presented with artificially generated errors or problems that must be resolved to continue, while simultaneously being provided with step-by-step instructions to address the issue. The steps usually include copying a command and running it via the Windows Run dialog or another system prompt, which, however, rather than resolving the issue, silently retrieves and executes the malicious payload.To summarize, AuraStealer is not yet as widespread and popular as the more established infostealer families currently dominating the threat landscape, such as Lumma Stealer, StealC or Vidar. However, according to an&nbsp;<a href="https://g0njxa.medium.com/approaching-stealers-devs-a-brief-interview-with-aura-9b513369e117" target="_blank">interview</a> conducted by&nbsp;<a href="https://x.com/g0njxa" target="_blank">g0njxa</a> with the AuraStealer developers, the malware is backed by a committed team that continuously improves and evolves its functionality, aiming to become the number one in the infostealer market. This suggests that AuraStealer could become a more significant player in the future.<h2>AuraStealer Obfuscation</h2>AuraStealer incorporates a wide range of techniques designed to hinder both static and dynamic analysis. These include control flow obfuscation, string encryption, constant obfuscation, as well as standard anti-debug, anti-tamper, and anti-VM checks. It further employs advanced techniques such as exception-driven API-hashing, leveraging the Heaven’s Gate for suspicious NTDLL calls, and performing checks to detect breakpoints on return addresses.<h3>Indirect Control Flow Obfuscation</h3>The first obfuscation technique an analyst is likely to encounter when opening AuraStealer in a disassembler, such as IDA Pro, is its indirect control flow obfuscation. The obfuscation is not only immediately noticeable, but also one of the most troublesome obstacles that must be overcome to properly analyze the stealer. The obfuscation is based on systematically replacing direct jumps and calls with indirect ones, where the actual target address is computed only at runtime. This method effectively disrupts static analysis, as the disassemblers are left with a set of seemingly unrelated basic blocks, effectively breaking any control-flow graph analysis or decompilation.&nbsp;To demonstrate how this obfuscation works in practice, and how it can be defeated, we focus on the&nbsp;<code>WinMain</code> function, which is both the longest and the most complex function of the stealer. Several examples illustrating the obfuscation mechanism at the assembly level are shown in Figure 4 below, with the instructions relevant to computing each target address highlighted in a distinct color. Notably, the screenshot also illustrates that the obfuscation successfully confused IDA, causing it to misinterpret the entire&nbsp;<code>WinMain</code>&nbsp;function as a single basic block.

As illustrated, the target addresses are computed in several different ways depending on the branching context, ranging from simple arithmetic sum of two values (highlighted in green, blue, and red) to more complex ones, where the resulting target address may take multiple possible forms, with the final choice determined by a conditional instruction such as <code>cmovz</code>&nbsp;(highlighted in pink).At that point, a reader could easily conclude that a bit of pattern matching, emulation, and patching would be enough to remove the obfuscation – and that was our initial assumption as well. However, it turned out that AuraStealer uses multiple variations of these indirect control flow obfuscation schemes, some of which employ far more elaborate patterns. For example, the target address may even depend on the return values of multiple preceding function calls, since its computation involves conditional instructions driven by those results (see Figure 5).&nbsp;

Nonetheless, despite the diversity and potential complexity of these obfuscation schemes, there are still ways to deal with them and reconstruct the original control flow. First, the most basic scheme used to obfuscate function calls, which relies solely on the sum of two values can be resolved with a simple trick in IDA Pro. In these cases, it is sufficient to hint to IDA that the offsets contributing to the sum operation are in fact constant. Once treated as constant operands, IDA can evaluate the arithmetic on its own and optimize it accordingly, allowing the decompiler to reveal the actual call’s target address.

Figures 7 and 8 illustrate the effect of this trick and the resulting difference in the decompiled output. As can be seen, even such a minor adjustment can substantially improve the analysis, as it replaces these otherwise meaningless offset sum calculations with direct references to the actual target functions.&nbsp;

Since these offset references often appear in consecutive blocks (Figure 9), it is practical to automate their processing, for which the IDA Python snippet shown in Figure 10 is particularly useful.&nbsp;

Unfortunately, this trick alone is insufficient to address the conditional jumps and other schemes of AuraStealer's indirect control flow obfuscation. Nonetheless, given how many calls are obfuscated with this simple scheme, applying it still provides meaningful progress and can serve as a solid starting point for further deobfuscation. Moreover, AuraStealer applies the same obfuscation scheme to hide certain function arguments as well, making it applicable for those cases as well.&nbsp;To tackle the more sophisticated patterns, backward slicing proved to be the most effective approach. For those interested in a more detailed explanation of how this technique works, the articles <a href="https://cloud.google.com/blog/topics/threat-intelligence/lummac2-obfuscation-through-indirect-control-flow" target="_blank">LummaC2: Obfuscation Through Indirect Control Flow</a> by Nino Isakovic and Chuong Dong, and <a href="https://cyber.wtf/2025/11/19/rhadamanthys-loader-deobfuscation/" target="_blank">Rhadamanthys Loader Deobfuscation</a> by Melissa Eckardt provide excellent explanations and are definitely worth reading.&nbsp;In short, backward slicing is a program analysis technique that identifies instructions that may influence a specific register or memory address at a specific program point by following data and control dependencies. The resulting set of instructions (also referred to as “slice”) can then be used for further analysis, such as emulation or symbolic execution, to recover the value of the targeted register or memory location.In our case, we employed a heuristic heavily inspired by backward slicing but simplified and tailored specifically for AuraStealer. The heuristic can be summarized in the following steps:<ol><li>Locate the indirect <code>jmp/call</code> instruction. </li><li>Add the register used as the target operand of this indirect <code>jmp/call</code> instruction to the <code>tracked_regs</code>&nbsp;set.</li><li>Iterate through instructions in reverse (from the indirect <code>jmp/call</code> towards lower addresses), analyzing each instruction whether it affects any of the tracked registers.<ol><li>If an instruction modifies a tracked register, mark it as relevant.</li><li>For a relevant instruction, determine if it completely overwrites a tracked register (e.g., <code>MOV reg, imm</code>, <code>XOR reg, reg</code>,&nbsp;etc.), and if so, remove that register from <code>tracked_reg</code>, ending its dependency chain.</li><li>Otherwise, identify all source registers of that relevant instruction and add them to the <code>tracked_reg</code>&nbsp;set to propagate the dependency further back.</li></ol></li><li>Stop the process if any of these conditions occur:<ol><li>The <code>tracked_regs</code>&nbsp;set is empty (all dependencies have been resolved).</li><li>A control-flow instruction is encountered (<code>call</code>, <code>jmp</code>, <code>ret</code>), indicating a basic block boundary.</li><li>A maximum instruction limit is reached (fail-safe).</li></ol></li><li>Finally, return the address of the earliest (lowest address) relevant instruction found, marking the start of the slice.</li></ol>For clarity, this heuristic is not meant to implement complete backward slicing. It deliberately omits memory‑write tracking and focuses solely on register flows. However, it is important to note that this limitation is intentional, as register-level analysis is sufficient for the deobfuscation of the indirect control flow obfuscation employed by AuraStealer. We use the heuristic solely to identify the slice’s starting address, from which we then perform symbolic execution with Angr to compute the target address(es). That said, if AuraStealer’s obfuscation were to change, the heuristic could be readily extended to also account for memory interactions.The reason we chose symbolic execution over emulation is that symbolic execution is inherently designed to explore all possible execution paths, making it easier to implement. In terms of computational requirements, it remains feasible since we only symbolically execute small code chunks.Attentive readers may have noticed that this approach has a minor imperfection. The heuristic terminates upon encountering a <code>call</code> instruction. However, as shown in Figure 5, the target address of some <code>jmps</code> can depend on the results of previous function calls, which may lead to an incorrectly identified slice start. To handle such cases, whenever a register is unconstrained, we assign it a symbolic boolean value (0 or 1), under the assumption that any function influencing such jumps returns a boolean value. Such cases, however, are relatively rare.&nbsp;The whole process can be automated with a bit of scripting and the recovered target addresses can be pushed back into IDA as comments, which already gives a good baseline for navigating the code.&nbsp;

However, we can go further – our real goal is to make IDA reconstruct the original control flow graph, not just annotate it. Once the target addresses of the indirect <code>jmps/calls</code> are retrieved, there are several ways to proceed. One option would be to patch the binary. However, due to the variability of the patterns involved and the presence of an anti‑tamper protection in AuraStealer, we have opted for a different approach.&nbsp;Instead of patching the binary, which is destructive and easily detectable by malware, we leveraged the IDA SDK to hook directly into the instruction analysis process. The idea is simple – rather than letting IDA analyze the instructions on its own, we intervene in the analysis process and modify how the instructions are decoded. For this purpose, IDA provides <a href="https://cpp.docs.hex-rays.com/structpost__event__visitor__t.html" target="_blank"><code>post_event_visitor_t</code></a>, a class that allows listening and reacting to specific events in IDA by overriding the virtual function <code>handle_post_event</code>.&nbsp;

Among all the possible event codes, the interesting one is the <code>processor_t::ev_ana_insn</code>&nbsp;(analyze instruction), which is triggered right after IDA calls the processor module’s instruction decoder, but before the resulting <code>insn_t</code> structure is finalized and committed to the database. At that point, we can inspect, or even modify, the decoded instruction. In other words, we can alter IDA’s perception of the code without ever touching the underlying binary.At this point, several observations are worth highlighting:<ul><li>The indirect calls almost always have a single target.</li><li>Many conditional jumps have only two targets, one of which is the immediately following instruction.</li></ul>Resolving the indirect call obfuscation is therefore straightforward. Whenever we intercept the <code>processor_t::ev_ana_insn</code> event, we check whether the analyzed instruction is an indirect call (<code>call reg</code>). If the target address is known and it is the only possible target, we replace the <code>call reg</code> instruction with <code>call &lt;calculated_target_address&gt;</code>.For indirect conditional jumps, it would, in principle, be possible to determine the exact branch type by analyzing the conditional move used to compute the target address and replacing the <code>jmp</code> instruction with the corresponding conditional jump instruction. However, we opted for a much simpler and more pragmatic strategy. Many of these indirect jumps are, in fact, only obfuscated loops or <code>if-then/if-then-else</code> constructs with one of the target address pointing to the immediately following instruction. So, whenever we encounter an indirect <code>jmp</code> instruction with precisely two possible targets, one of which is the fall-through address, we replace the <code>jmp</code> instruction with <code>jnz</code> (jump if not zero) pointing to the non-fall-through target address.This transformation does not yield a perfectly accurate decompilation. However, if we accept the fact that some comparisons may appear as&nbsp;<code>condition != 0</code> rather than their exact form, we end up with a control flow that is already much easier to follow. Moreover, whenever the precise condition semantics matter, the original condition can always be examined directly in the disassembly. Although it would be possible to reconstruct and substitute the exact conditional jump for every case, we do not believe it is worth the effort.

Regarding indirect jumps with multiple possible targets, or those for which none of the targets is the immediately following instruction, we simply add user-defined cross-references in IDA.Using these steps, we managed to fully recover the AuraStealer’s control flow.

Note that due to the heavy control&nbsp;flow obfuscation with many references to code locations, IDA often struggles to recognize proper function boundaries. It is thus often necessary to manually adjust where the function begins and ends to ensure IDA analyses the whole function.<h3>Exception-Driven API Hashing</h3>To obfuscate its usage of WinAPI functions, AuraStealer employs the API hashing technique. For these purposes, it first resolves all the functions required by the binary via PEB-walking and builds two hash-based lookup tables that maps hashes to XOR-masked addresses.&nbsp;The reason for maintaining two tables is that AuraStealer does not invoke these function directly. Instead, it deliberately triggers an exception, which, however, is intercepted by a custom exception handler. The handler inspects the address from which the exception originates and uses that information to dispatch the appropriate function address.To resolve a specific function, AuraStealer takes the precomputed <code>MurmurHash3</code> value (seeded with <code>0xDEADBEEF</code>) of the function’s name, re-hashes it with <code>FNV-1a</code>, and uses both values to query the first precomputed lookup table. The query returns the XOR-masked address from which the exception is to be thrown, together with the mask used to protect it. AuraStealer then unmasks the address and makes a call to it, intentionally throwing an <code>EXCEPTION_ACCESS_VIOLATION</code>, which is intercepted by the custom exception handler.&nbsp;The exception handler rehashes the originating address using <code>FNV-1a</code> and uses both values to query the second precomputed lookup table. This query returns the XOR-masked address of the actual target function, again along with the mask. The two values are XORed together and the resulting address is loaded into the <code>EIP</code> register, effectively invoking the requested WinAPI function.

The MurmurHash3 values of the target functions are further obfuscated using an XOR mask (see Figure 16). In this example, <code>0x130B0F3C ^ 0x25A36E25 = 0x36A86119</code>, which is equal to the value returned by <code>MurmurHash3(“GetModuleHandleA”, seed: 0xDEADBEEF</code>).&nbsp;Since the result value is produced only by a XOR of two constants, IDA’s decompiler can optimize the expression and directly display the deobfuscated value (see Figure 17).&nbsp;This allows us to precompute the hashes for all API-hashed functions and replace the decompiler-computed constants with the corresponding function names. However, it is important to note that this approach relies on IDA’s decompiler, which may produce incomplete results if the control flow is not fully deobfuscated. That said, the constants could also be recovered by combining backward slicing to isolate the instructions that influence the final constant value, and emulating them with an emulation framework (for example, Unicorn). In this case, removing the obfuscation would be considerably easier than for the indirect control flow obfuscation, as the constant obfuscation is merely an XOR, requiring emulation of only a few instructions. Moreover, these instructions are consistently located in the same basic block where the deobfuscated constant is used.

The exception handler is installed within the initterm routines, i.e., before the program reaches <code>WinMain</code>, making its presence easy to overlook. As part of this setup, AuraStealer not only registers the exception handler itself but also allocates a memory blob via <code>VirtualAlloc</code>, which is later used to build the lookup tables and as a memory region from which the exceptions are triggered. &nbsp;

This mechanism effectively adds another layer of obfuscation. &nbsp;Although the custom handler ultimately processes the deliberately triggered exceptions, a debugger intercepts them first. Consequently, anyone analyzing AuraStealer in a debugger is flooded with <code>EXCEPTION_ACCESS_VIOLATION</code>, making the program appear unstable and obscuring its real behavior. This can easily lead the analyst to disable exception notifications only to make the program run. However, by doing so, they deliberately hide the malware’s custom exception handler in the process, causing an important part of its logic to go unnoticed. Additionally, the exception spam also serves as an anti‑debugging technique, as the overwhelming stream of exceptions disrupts the debugging workflow.<h3>String Obfuscation</h3>Although most strings in AuraStealer are obfuscated, the names of the functions that are dynamically resolved and intended to be hidden via API-hashing remain in plaintext.

Their addresses, however, are obfuscated using the same arithmetic-based obfuscation used to obfuscate the target addresses of indirect calls (Figure 22).

Still, since the computation relies solely on constant values, it is possible to use the same trick presented above – marking the variable used in the computation as constant – to let IDA’s decompiler to compute the target address. This is another excellent example of how this trick can significantly accelerate the analysis. Instead of meaningless offsets, the decompiled code directly reveals the function name being referenced (see Figure 23).

The remaining strings are encrypted using a stack-based XOR obfuscation. The encrypted string and its corresponding XOR key are first concatenated in memory from constant values, XORed together, and stored in memory. An example of how such a decryption routine looks at the assembly level is shown in Figure 24.

These decryption routines generally follow the same logic but include slight variations, and their length varies depending on the length of the decrypted string. The main challenge is that emulating instructions withing isolated basic blocks and reading the strings from memory once the decryption is finished is not sufficient to recover all strings, as many of the constants involved in the string-decryption logic are reused throughout the function. Therefore, the necessary context is distributed across the entire function. As a result, recovering all strings requires emulating much larger code regions to preserve the full context, a task that can quickly become error-prone and time-consuming.&nbsp;Therefore, to decrypt AuraStealer strings, we implemented a simplified form of function emulation using the Unicorn emulation framework. Rather than emulating the entire function, we selectively step through its instruction, while skipping call instructions and loops. When reaching conditional branches (e.g., <code>if</code>&nbsp;or <code>switch</code> constructs), we fork the execution to explore and cover all relevant paths. This streamlined approach was sufficient to recover most of the obfuscated strings without resorting to full, heavyweight emulation.&nbsp;

A <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_decrypt_strings.py" target="_blank">reference script</a> implementing the decryption workflow is available on our GitHub. The script is intended to be run from IDA Pro. &nbsp;<h2>Anti-Analysis Execution Chain</h2>During its execution, AuraStealer performs multiple anti-analysis checks, ranging from basic to more sophisticated techniques. Some of these checks are executed unconditionally, while others depend on configuration parameters specific to the particular infostealer build. The execution flow is displayed in Figure 26.

<h3>Running Protected Check</h3>AuraStealer’s anti-analysis chain begins by checking whether the binary is executed from a protective layer such as a loader, packer, or crypter. Depending on that outcome, it either performs or skips additional checks, which include an anti-tampering check and a dialog box check.&nbsp;<h3>Anti-Tampering Check</h3>The anti-tampering check is done using the <code>MapFileAndCheckSumW</code> WinAPI function, which computes the file’s checksum and compares it against the value stored in the PE header. If those values differ, AuraStealer stops its execution.The purpose of this check is to prevent analysts from patching or otherwise altering the executable. With that in mind, analysts should be cautious about any changes made to the binary (including software breakpoints) and remain vigilant during dynamic analysis, as the malware may deliberately exhibit misleading behavior if tampering is detected.&nbsp;<h3>Dialog Box Check</h3>Similar to what <a href="https://outpost24.com/blog/lummac2-anti-sandbox-technique-trigonometry-human-detection/" target="_blank">Lumma</a>, and more recently also <a href="https://research.checkpoint.com/2025/rhadamanthys-0-9-x-walk-through-the-updates/" target="_blank">Rhadamanthys</a>, does, if AuraStealer detects that it is being run unprotected, it displays a dialog box prompting the user to enter a code to continue. Unlike Lumma and Rhadamanthys, it requires the user not only to click the OK button but also to correctly enter the displayed code. On the other hand, it does not display any warning message that malware is to be run, which is what both Lumma and Rhadamanthys display in the message box.

This mechanism halts AuraStealer’s execution until the correct value is provided and is aimed at forcing the malware distributors to deliver the stealer with an additional protective layer. Additionally, it also serves as an anti-sandbox protection since automated sandboxes would hardly ever perform OCR over that text and try to paste it. Both the window title and the code to be entered are randomly generated at runtime, based on the Mersenne-Twister pseudorandom number generator.&nbsp;<h3>Geolocation Check</h3>To avoid execution in specific countries, AuraStealer performs a geolocation check by retrieving the system and user language settings using the WinAPI functions <code>GetUserDefaultLCID</code> and <code>GetSystemDefaultLCID</code>, and obtains the country code through <code>GetLocaleInfoA</code>. The retrieved country codes are then compared against a predefined blacklist, and if any match is found, the malware terminates its execution.

Notably, in addition to avoiding execution in CIS countries, the stealer also omits the Baltic states (Lithuania, Latvia, and Estonia). &nbsp;&nbsp;According to the AuraStealer developers, an extra IP check is allegedly performed on the server side. However, we were unable to confirm that claim.<h3>Anti-Sandbox Checks</h3>If all previous checks pass, the process continues to the anti-sandbox stage, which comprises three primary checks.First, AuraStealer evaluates whether the <code>Sleep</code>&nbsp;function has been hooked or modified. To do so, it records the system time using <code>GetSystemTimePreciseAsFileTime</code>, invokes <code>Sleep(1000 ms)</code>, and queries the system time again. If the measured delay is less than 900 ms, the stealer assumes that the <code>Sleep</code> function has been tampered with.Next, it performs a Microsoft Defender emulation check by comparing the values returned by <code>GetUserNameW</code> and <code>GetComputerNameW</code> against the well-known emulator artifacts <code>JohnDoe</code> and <code>HAL9TH</code>.&nbsp;Finally, AuraStealer inspects the list of currently loaded modules and compares them against the following list of blacklisted DLLs:

<h3>Configuration Extraction</h3>The configuration for each AuraStealer build is embedded directly in the binary and is protected with AES-CBC encryption. The encrypted configuration is stored as a single contiguous block, with a linear, serialized layout. The encrypted configuration structure is as follows:

Since all information required to decrypt the configuration is contained within the binary, it is possible to decrypt the content and extract the malware configuration.

Based on the configuration, AuraStealer performs additional anti-analysis checks. If all checks pass, it attempts to establish connection with the C2 servers listed in the configuration and initiates the data-stealing process. The configuration also allows setting custom user agents, defining a start delay, and choosing whether the malware should delete itself after completing the stealing process. Interestingly, although anti‑debugging appears as a configurable option in the configuration, it cannot be disabled from the panel. Furthermore, even though proxy support is not explicitly listed in the configuration, AuraStealer is expected to handle proxy usage. This is indicated by both the available build options in the AuraStealer panel and the strings observed in the configuration-parsing logic within the binary.

To streamline the process of retrieving build configuration data from AuraStealer samples, we provide a <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_config_extractor.py">configuration extraction script</a>. The script is publicly accessible on our GitHub.<h3>Human Checks</h3>The human check comprises two subchecks, both implemented as infinite loops.&nbsp;The first check monitors whether the user input changes over time. It begins by measuring the number of ticks between two <code>GetTickCount</code> calls with a <code>Sleep(1000 ms)</code> in between. A while loop then repeatedly performs a <code>Sleep(500 ms)</code> followed by a call to <code>GetLastInputInfo</code>, which returns a <code>LASTINPUTINFO</code> structure. This structure contains a variable, <code>dwTime</code>, representing the tick count at which the last input event occurred. Then, another call to <code>GetTickCount</code> is made, and <code>dwTime</code> is subtracted from it. If the result is less than the previously measured number of ticks measured by the one-second <code>Sleep</code>, the check passes. Otherwise, the loop repeats until the check passes.&nbsp;The second check begins by a call to <code>GetForegroundWindow</code>, which returns a handle to the current foreground window. A while loop then repeatedly calls <code>Sleep(500 ms)</code> and checks <code>GetForegroundWindow</code> again. If the returned handle differs from the initial one, the check passes. Otherwise, the loop continues until the foreground window changes.&nbsp;<h3>Anti-VM Checks</h3>The Anti‑VM check consists of multiple subchecks. First, the presence of a hypervisor is checked using the <code>cpuid</code> instruction. When <code>cpuid</code> is executed with <code>EAX = 1</code>, the 31st bit of <code>ECX</code> indicates the environment – it is <code>0</code> on a physical machine and <code>1</code> on a virtual machine.Next, a combination of the WinAPI functions <code>GetDesktopWindow</code> and <code>GetWindowRect</code> is used to obtain the <code>right</code> variable from the resulting <code>RECT</code> structure, which is then compared against <code>1024</code> (it is expected to be greater). Finally, <code>GlobalMemoryStatusEx</code> is called, and the <code>ullTotalPhys</code> variable of the returned <code>MEMORYSTATUSEX</code> structure is checked to ensure it is not <code>0</code>.If all of these checks pass, AuraStealer calls <code>GetSystemInfo</code> and inspects the returned <code>SYSTEM_INFO</code> structure to verify that <code>dwNumberOfProcessors</code> is not less than four. If the system has four or more processors, the Anti‑VM check is considered passed. If the processor count is below this threshold, the malware performs one additional verification using <code>EnumProcesses</code> to retrieve the list of running processes. It then checks whether the total number of running processes is at least <code>200</code>, which is assumed to be typical for a real, non‑virtualized system.

<h3>Anti-Debug Checks</h3>The anti-debug check comprises several subchecks, beginning with inspecting well-known debug flags in the <code>PEB</code>, including <code>BeingDebugged</code> and <code>NtGlobalFlag</code>, as well as the <code>KUSER_SHARED_DATA</code> structure. A detailed explanation of how these flags can be used to detect a debugger can be found <a href="https://anti-debug.checkpoint.com/techniques/debug-flags.html">here</a>.

If all previous check pass, AuraStealer creates a new debug object using <code>NtCreateDebugObject</code> and makes a subsequent call to <code>NtQueryObject</code>. Since the object was just created, there should exist only a single handle to it – the one held by the program itself. However, if a debugger or other monitoring tool is attached (which often hooks these functions or duplicates handles for analysis), the <code>HandleCount</code> may be greater than one. In that case, AuraStealer proceeds to compare the names of all running processes against a hardcoded blacklist, and if any match is found, it terminates its execution.

Notably, as careful readers may notice in the decompiled anti-debug and anti-VM check functions, AuraStealer employs an additional anti-debugging technique that is utilized across various functions within its codebase. The technique works by inspecting the opcodes located at the function’s return address. If a breakpoint instruction (<code>INT3</code> or <code>INT&nbsp;3</code>) or a <code>UD2</code>&nbsp;instruction (commonly used for hooking) is detected, a random value between 64 and 127 is generated and added to a stack variable at offset <code>−4</code> from the return address. The intent behind this technique is not to crash the program immediately, but to plant a subtle corruption that only results in a crash later during execution, making it very hard to determine the crash origin.

<h2>AuraStealer Execution Flow</h2>The high-level execution flow of AuraStealer can be summarized as follows. First, the malware installs the custom exception handler and creates the two lookup hash tables used for its exception-driven API hashing. Next, it performs multiple anti-analysis checks described above and decrypts its embedded configuration. If all checks pass, it proceeds with mutex creation.&nbsp;Based on the hosts specified in the configuration, it attempts to establish a connection with its C2 servers, which respond with additional configuration specifying what information and files should be collected. Finally, the malware begins collecting the targeted data and exfiltrating it to its remote infrastructure.&nbsp;

As for the AuraStealer’s capabilities, it targets nearly every aspect of the user’s digital life. Specifically, it is capable of collecting:<ul><li>Sensitive data from both Chromium-based and Gecko-based browsers</li><li>Cryptocurrency wallets from desktop applications and browser extensions</li><li>Active session tokens (Discord, Telegram, Steam)</li><li>2FA tokens (Authenticator)</li><li>Recovery data (recovery seeds, private keys, and mnemonic phrases)</li><li>Credentials and API keys</li><li>Remote access and FTP configurations (AnyDesk configurations, FileZilla credentials)</li><li>Password manager databases (KeePass, Bitwarden,&nbsp;1Password,&nbsp;LastPass)</li><li>VPN configurations (OpenVPN, NordVPN, ProtonVPN)</li><li>Clipboard contents</li><li>Screenshots of the victim’s device</li><li>A list of running processes, along with general system fingerprinting data</li></ul>However, this is not an exhaustive list as AuraStealer allows to include additional custom configuration modules for specific builds (including wildcard-based file search with configurable masks, paths, and recursion), effectively enabling the theft of virtually any file of interest.Beyond data theft, AuraStealer is also capable of executing additional payloads.&nbsp;

<h3>Dynamically Generated Mutex</h3>To prevent multiple instances from running simultaneously, AuraStealer utilizes dynamically generated mutexes based on build-specific and time-dependent values. The malware first loads the <code>build_id</code> value from its configuration (for example, <code>a0858933-16a7-433f-a9cc-68490ace0576</code>) and computes a <code>djb2</code> hash over it. The hash is then added to the result of an integer division <code>_Xtime_get_ticks()/36000000000</code>, which effectively produces a value that changes once per hour. The final sum serves as a seed for a Mersenne-Twister pseudorandom number generator, which is used to generate a random alphanumeric string between 16 and 32 characters in length. The generated string is prepended with <code>Global\</code>, forming the final mutex name.&nbsp;

The fact that the mutex changes every hour highlights that the stealer is designed to run only for a short period of time – a trend that has become increasingly common among modern infostealers. The goal is to execute briefly, steal as much data as possible, and, preferably, remove all traces of its presence.<h2>Application-Bound Encryption Bypass</h2>To extract sensitive data from Chromium-based browsers, AuraStealer must first overcome Application-Bound Encryption (ABE), which it achieves by spawning the target browser in headless mode using <code>CreateProcessW</code>, with the process created in a suspended state, followed by a code injection. From within the injected context, the malware invokes <code>IElevator::Decrypt</code> to decrypt the <code>app_bound_encrypted_key</code>, which enables the decryption of any ABE-protected data, including passwords and cookies.

The injection itself is implemented by creating a shared section via <code>NtCreateSection</code> and mapping it into the target browser process using <code>NtMapViewOfSection</code>, after which the injected payload is executed using <code>NtCreateThreadEx</code>. All of the NTDLL calls involved in the injection are executed through Heaven’s Gate, a technique that allows 64-bit code to be executed from a 32-bit process on a 64-bit OS. This ensures both compatibility with 64-bit browsers and also helps evade detection.

The injected payload is a position-independent shellcode, slightly modified at runtime for each target browser process. At predefined offsets within the shellcode, AuraStealer fills two randomly generated file names with the paths of the form <code>C:\Users\&lt;user&gt;\AppData\Local\Temp\&lt;random_alphanumeric_string_len_16_to_32&gt;</code>, along with a value identifying the browser type, which is later used to select the appropriate CLSID and IID for the <code>CoCreateInstance</code> invocation. These two files serve as an inter-process communication mechanism between AuraStealer and the injected shellcode. The first file is used to pass the encrypted <code>app_bound_encrypted_key</code> to the injected shellcode, while the second file is used by the shellcode to write back the decrypted key for retrieval by the stealer.Although AuraStealer is capable of decrypting the <code>app_bound_encrypted</code> key, required to decrypt appbound-encrypted data, from certain Chromium-based browsers, it still does not work reliably across all of them, suggesting that the product has not yet reached a fully polished state.<h2>Network Traffic</h2>AuraStealer’s network traffic can be divided into four stages. The stealer first verifies internet connectivity by checking the reachability of <code>1.1.1.1:53</code> (Cloudflare). Upon success, it attempts to establish communication with its C2 infrastructure by querying the <code>/api/live</code> endpoint and expecting a response<code> true</code>. If any of the servers are reachable, it then requests <code>/api/conf</code>, together with its <code>build_id</code>, to retrieve a build-specific configuration defining the data to be collected (a <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_config.json">sample configuration</a> is publicly available on our GitHub repository). Finally, the collected files are split into smaller archives and sent in parts as they are collected via the <code>/api/send</code> endpoint.

All network traffic is encrypted using AES-CBC in a manner very similar to the configuration encryption, with the difference that the encrypted data is additionally Base64‑encoded. The encryption keys and initialization vectors are generated randomly at runtime.&nbsp;

<h2>Key Takeaways and Defensive Measures</h2>AuraStealer&nbsp;is a rapidly growing infostealer that employs a wide range of obfuscation and&nbsp;anti-analysis techniques to evade both static and dynamic detection. Apart from targeting nearly every aspect of users’ digital life, it also allows for the inclusion of additional custom configurations with configurable masks, paths, and recursion, effectively enabling the theft of virtually any file of interest.What You Can Do:<ul><li>Use reputable security software&nbsp;with real-time protection. Products from Norton, Avast, AVG, and Avira automatically protect users against the attacks and threats described in this analysis.</li><li>Avoid copying and pasting commands&nbsp;from unknown or suspicious sources into system dialogs like Windows Run or PowerShell.</li><li>Verify software sources&nbsp;– avoid downloading cracked games, software activators, or suspicious browser/IDE extensions.</li></ul><h3>IoCs</h3>0223E39D9C26F065FABB1BCB8A1A03FE439BB18B8D14816646D8D236A6FD46A3 (AuraStealer 1.0.0)01E67139B59EED0FE1FCB4C66A9E88AD20DD8B55648C077AEC7FA2AE3431EA5F (AuraStealer 1.1.0)9A46C8D884F4C59701D3AF7BEAD1E099E3DDEB1E2B75F98756CC5403D88BD370 (AuraStealer 1.1.1)FD3875225C1AB60E6DC52FC8F94B4D389624592B7E7B57EE86E54CEBE5D3EB6A (AuraStealer 1.1.2)EC7BA08B1655963D6C9F7D996F3559C58893769A2C803DA1F99610A0AAA1224A (AuraStealer 1.2.0)0F691762DA02ABBD94046381ECEDFD8B31CCBB835DED6049E9D6CD2AFDD3F551 (AuraStealer 1.2.1)F6E7341AB412EF16076901EA5835F61FBC3E94D0B9F2813355576BAD57376F29 (AuraStealer 1.2.3)D19274A14B905679DBD43FFB374CA0E11F9DC66FDB9E17236829A9A56F3E7D31 (AuraStealer 1.3.0)F0F7AE1FC2D569B8B9267D2EC81F7E539DB4BEAF275BCA41962C27ECFA5361BF (AuraStealer 1.4.0)158369AD66EA4BACEEE19051425C21F657FFC1B3483EA812323816B612F324BD (AuraStealer 1.5.0)F816558972F62D206757BAD4A95EE75290615F520F3B24D814FFBCDFC6998C6C (AuraStealer 1.5.1)F7D0F099D042DE83AA2D0A13100640BEA49D28C77C2EB3087C0FB43EC0CD83D7 (AuraStealer 1.5.2)apachesrv[.]cfd (C2) argametop[.]cfd (C2) armydevice[.]shop (C2) browsertools[.]shop (C2) calibrated[.]cfd (C2) chicagocigars[.]shop (C2)&nbsp; clocktok[.]cfd (C2) connupdate[.]cfd (C2) coralpoint[.]cfd (C2) cybertool[.]shop (C2) gamedb[.]shop (C2) glossmagazine[.]shop (C2) goldenring[.]cfd (C2) greenapi[.]cfd (C2) magicupdate[.]cfd (C2) mscloud[.]cfd (C2) mushub[.]cfd (C2) opencamping[.]shop (C2) privateconnect[.]cfd (C2) searchagent[.]cfd (C2) searchservice[.]cfd (C2) softytoys[.]shop (C2) stmservice[.]cfd (C2) sysrequest[.]cfd (C2) systemupdate[.]cfd (C2) unknowntool[.]shop (C2) updservice[.]cfd (C2)

A technical walkthrough of obfuscation, anti-analysis and data theft capabilities

Defeating AuraStealer: Practical Deobfuscation Workflows for Modern Infostealers

Malware Researcher

Gen has discovered a novel WhatsApp account takeover campaign that we refer to as GhostPairing Attack. On the surface it looks very simple. Victims receive a message from one of their contacts, usually something along the lines of:“Hey, I just found your photo!”

The message includes a link that appears as a Facebook style preview. When users open it, they see a page that imitates a Facebook viewer and asks them to “verify” before they can see the content.What follows is a small sequence of steps that many people complete without thinking. At the end of that sequence, an attacker has full access to the victim’s WhatsApp account without stealing a single password.This article explains what we observed, how the attack works in practice, which infrastructure is involved, and what users can do to protect themselves.We use the term GhostPairing Attack because the victim is tricked into completing WhatsApp’s own device pairing flow, adding the attacker’s browser as an invisible extra device on their account. There is no password theft or SIM swap – instead, the user approves the attacker themselves by entering a pairing code that looks like normal verification.&nbsp;<h3>What we observed in the wild</h3>The campaign was first noticed in Czechia, where compromised accounts started sending short, informal messages to local contacts. The wording varied slightly, but the structure remained the same. The messages were brief, usually mentioning a photo, and included a link that rendered as a Facebook element inside WhatsApp.

The domains behind these links were not Facebook at all. Instead, they belonged to a cluster of lookalike sites with names related to photos or posts, for example:<ul><li>photobox[.]life</li><li>postsphoto[.]life</li><li>yourphoto[.]life</li><li>photopost[.]live</li><li>yourphoto[.]world</li><li>top-foto[.]life</li><li>fotoface[.]top</li></ul>Paths often included strings like /login/post.com or /login/facepost.com, which helped maintain the illusion that the user was dealing with some kind of Facebook login or content viewer.Although our earliest sightings are in<a> Czech</a>, nothing in the attack depends on the language. The same template can be reused for any country simply by changing the text of the lure.<h3>The fake viewer that is not about Facebook at all</h3>When a user clicks the link within the WhatsApp message, they land on a very minimal page. It usually carries the Facebook logo and colors, a stripped down layout and a button that invites them to continue or verify before they can see the photo.This page has two purposes.&nbsp;First, it creates a sense of familiarity that encourages the user to trust the page. People expect Facebook to ask for some kind of confirmation from time to time. Seeing a login button or a verification step feels normal.Second, it acts as the attacker’s control panel. The page is not connecting with Facebook but rather mediating between the victim and the legitimate WhatsApp Web infrastructure that the attacker is abusing.Depending on the variant, the next screen either:<ul><li>shows a QR code and tells the user to scan it with WhatsApp, or</li><li>shows a numeric code and tells the user to enter it into WhatsApp to confirm a login.</li></ul>Both flows lead to the same outcome, but later we’ll show why the QR code is rarely used in favor of the numeric code. The attacker gets their browser registered as a linked device on the victim’s WhatsApp account, where they have complete control over personal messages, photos and everything else a person does on the WhatsApp platform.<h3>A quick primer on WhatsApp device linking/pairing</h3>To understand the abuse, it helps to look briefly at how device linking in WhatsApp is supposed to work.When people use WhatsApp Web or the desktop client, they are not creating a separate account. They are linking a new device to their existing account. WhatsApp offers more than one way to do this:<ol><li>The one most people know: open WhatsApp, scan a QR code shown on the desktop or browser, and approve the new session.</li><li>A less visible option: link a device using the account’s phone number and a numeric pairing code that the user has to confirm in the app.</li></ol>Both are legitimate features, and both are meant to make it easier to connect a new laptop or browser without constantly re-entering credentials. Additionally, both can be repurposed if someone convinces the account owner to cooperate.The campaign we analyzed does exactly that.<h3>QR based <a>linking</a> – possible, but a fringe scenario</h3>On paper, attackers could run the same scam using WhatsApp’s QR based device linking. In our tests, this works technically, but it is much less practical for real victims.To abuse this flow, an attacker would open WhatsApp Web in their own browser, capture the QR code shown there and embed it into the fake Facebook viewer page. The victim would then be told to open WhatsApp, go to Linked devices and scan that QR in order to “view the photo”. From WhatsApp’s perspective, the account owner has just approved a new linked device, and the attacker’s browser receives a fully authorized session.In practice, however, there is a big usability problem. Most people run both WhatsApp and the browser on the same phone. Scanning a QR that is displayed on the very device you are using is awkward at best, and often impossible without a second screen, another phone or a tablet. We have all seen edge cases where this happens in legitimate contexts, but it is not something you would build a mass scam around.That is why, in the activity we have observed, attackers rely on the phone number and pairing code flow instead. It produces the same end result but feels like a normal two step verification process and can be completed entirely on a single device, which makes it far more attractive for large scale abuse.<h3>Abusing phone number and pairing codes</h3>The numeric code variant is slightly more complex and arguably more dangerous, because it resembles two factor authentication even more closely. It is also the most common way the scam plays out.Here, the fake page encourages the user to enter their phone number. It then acts as a proxy to the real WhatsApp device linking endpoint.The behind-the-scenes sequence looks like this:<ol><li>The victim types their phone number on the fake page.</li><li>The page forwards that number to WhatsApp’s legitimate “link device via phone number” feature.</li><li>WhatsApp generates a pairing code that is meant to be seen only by the account owner.</li><li>The attacker’s site takes that code and displays it back to the victim with text that suggests they should “enter this in WhatsApp to confirm the login and see the photo.”</li><li>The victim opens WhatsApp, sees the pairing prompt and enters the code, believing they are completing a security check.</li></ol>From the victim’s point of view, this feels like a standard verification process. They have seen similar flows in many other services.From WhatsApp’s point of view, the owner of the account has just approved a new linked device using the correct code.Again, the end result is that the attacker’s browser becomes a trusted device for that account.

<h3>What the attacker can do once linked</h3>After their device is linked, the attacker does not need to exploit anything else. They have the same capabilities that any user has when connecting WhatsApp Web on their own computer.In practice, this includes:<ul><li>Reading historical conversations, subject to what has been synced.</li><li>Receiving new messages in real time.</li><li>Viewing and downloading media such as photos, videos and voice notes.</li><li>Collecting sensitive information shared between friends: addresses, email addresses, codes, links, which can later be misused or resold.</li><li>sending messages to individuals and groups as if they were the victim.</li><li>forwarding the same lure to many contacts with very little effort.</li></ul>This is not traditional account hijacking in the sense of changing passwords or locking the owner out. The phone continues to work normally. Many victims are unaware that a second device has been added in the background, which is what makes the scam even more dangerous – criminals are hiding in your account, watching your every conversation without you even knowing it.In our observations, that restriction does not consistently clear the linked session. Unless the victim goes into Settings and removes unknown devices, the attacker may retain access.<h3>How victims then become GhostPairing attackers</h3>The propagation mechanism is simple and effective because it is rooted in real relationships.Once an attacker has access to one account, they can use it to distribute the lure text that we mentioned previously to that person’s contacts and groups. Family chats, school groups, sports teams and work-related conversations are all opportunities.Recipients see a very short, informal message coming from someone they know. There is no unfamiliar phone number, no obvious formatting errors, no long explanation. This minimal style typically avoids suspicion.Some recipients click, some do not. Those who do and complete the linking step become new compromised accounts. They, in turn, can be used to reach fresh sets of contacts that the original attacker did not know existed – the attack expands like a snowball.This is what makes the campaign efficient. It does not rely on cold spam. It rides existing trust.<h3>Why this approach is concerning</h3>Several aspects of this technique are worth highlighting.First, it does not rely on stealing secrets. There is no password phish, no SMS interception, no direct authentication bypass. Everything happens inside the boundaries of the feature set that WhatsApp intended.Second, the lure is highly plausible. For many users, the idea that “Facebook wants you to confirm something in WhatsApp” does not sound obviously wrong. Codes and QR scans have become part of everyday online life, especially on mobile.Third, it creates persistent access. Linked devices do not disappear when the user closes a tab. They remain active until manually revoked. If there is no habit of checking the list of connected WhatsApp devices, an attacker can remain connected for a long time.Finally, it opens the door to more than just simple spam. With access to full conversations and media, an attacker can learn how people talk, who is important to them, and what they might respond to. Voice notes and photos can later be reused in fraud attempts and impersonation, including deepfake enhanced scams, or extortion.&nbsp;In other words, this is a clear example of how social engineering and legitimate infrastructure can combine into a very effective compromise method.<h3>Infrastructure and kit-like behavior</h3>Looking at the domains and templates involved, there are strong signals that the GhostPairing Attack is driven by a reusable kit that attackers can buy and distribute rather than a one-off project.The same layout appears across multiple domains. The same idea of a Facebook viewer repeats, with minimal changes. Domain names follow a similar pattern around photos and posts, with a mix of generic TLDs.From an operational point of view, this is convenient. If one domain is blocked or reported, it can be discarded and replaced with another one using the same files. A buyer of such a kit can plug in their own configuration – for example text targeting a specific region or, as the scam propagates, text specific to an individual –&nbsp;and start sending lures.<h3>What people can do to protect themselves</h3>For individuals, the most important actions are simple and do not require technical knowledge.First, it is worth checking which devices are currently linked:<ul><li>Open WhatsApp.</li><li>Go to Settings → Linked Devices.</li><li>Review the list of active sessions and log out of anything you do not recognise.</li></ul>Doing this once will remove any sessions already created by this sort of scam. Doing it periodically helps catch future problems earlier.

Second, treat any request to scan a WhatsApp QR code or enter a numeric code from a webpage as suspicious. WhatsApp linking should happen from inside the app and in response to a deliberate action, not because some external site tells you that it is required to view a file.Third, enabling Two Step Verification in WhatsApp adds an additional barrier to other kinds of account abuse. It is not a complete solution, but it reduces the range of what attackers can do once they are in.Finally, sharing information about this kind of scam with family members and group chats is surprisingly effective. Many victims click because they have never heard of anything like this. Once people know that “I found your photo” messages can hide an account linking trick, they are less likely to follow the script.<h3>What platforms could improve</h3>While user awareness is essential, there are also changes that platforms can consider.Clearer messaging around device linking would help. If users saw large, unavoidable text explaining that they are about to give a new device full access to all messages and media, some would hesitate.Better context on linking and pairing events would also be useful. Showing device type, browser, approximate location, and the fact that the request originated from a website, not from the app, could nudge users to cancel when something feels off.Rate limiting device linking attempts, especially those that involve many different phone numbers from the same infrastructure, would raise the cost for attackers. Auto revoking recent linked sessions when spam or abuse is confirmed on an account would shorten the window of exploitation.None of these measures alone would eliminate such attacks, but together they would make them less attractive.<h3>Beyond WhatsApp: pairing as a broader attack surface</h3>GhostPairing is not just a quirky one off trick in a single app. It is a case study in what happens when a pairing flow is abused at scale. WhatsApp is a natural target, with billions of users and a growing role in everyday and business communication, but the pattern behind GhostPairing is more general.Conceptually, the same risk exists anywhere you have:<ol><li>A QR code, code entry screen, or approval prompt that lets a new device connect to an existing account.</li><li>A trusted primary device that scans or approves that request.</li><li>A resulting session that is long lived and largely invisible to the user.</li></ol>If those three conditions line up, an attacker who can control the QR code or pairing prompt, and convince the victim to interact with it, has a realistic path to creating their own ghost device.Many modern services follow this pattern in one form or another, from messaging apps with web or desktop clients, to collaboration tools, social platforms and account ecosystems that rely on “approve on your phone” prompts. Most of them add extra checks, such as device details, locations, or number matching, which makes abuse harder but does not change the basic dependency: a single distracted click or code entry on the primary device can grant an unknown session elsewhere.We are not claiming that GhostPairing style campaigns are already running across all these ecosystems. What we can say is:<ul><li>The design pattern that made GhostPairing possible is not unique to WhatsApp.</li><li>Any platform that combines very easy pairing with low visibility of linked devices gives attackers something to work with.</li></ul>In that sense, GhostPairing should be read as a warning, not just a WhatsApp incident. The more our digital lives depend on quick QR scans and “approve on your phone” flows, the more important it becomes to design these steps so that a single moment of inattention does not quietly create a ghost device that lives in the background for months.<h3>Conclusion</h3>The campaign described here illustrates a subtle shift in how some attackers operate. Instead of breaking cryptography or circumventing authentication, they use the product as designed and persuade users to cooperate at just the right moment.By abusing WhatsApp’s device linking features and wrapping them in a familiar looking flow, they achieve a clean and persistent account compromise with minimal technical work.The technique is not limited to one country or one platform. Any service that allows device pairing through QR codes or numeric codes is a potential candidate for similar abuse.GhostPairing Attacks are a good example of how social engineering and legitimate features combine into very effective compromises. The attacker never breaks encryption, they simply convince the user to invite them in as a linked device.The good news is that the defense is well within reach. <a>A combination of user awareness, simple hygiene checks and modest platform changes can significantly reduce the impact of this type of scam.</a>

When “verification codes” quietly hijack your account

GhostPairing Attacks: from phone number to full access in WhatsApp

Threat Analysis Engineer

Black Friday and the holiday shopping season are the busiest times of the year for online shopping, and unfortunately, for online scams too. In October alone, we observed a significant spike in blocked fake shop (e-shop scams) attacks in the United States. Blocked attacks were up 185% compared with the January to September average, and the number of users targeted rose by 126% over the same period.&nbsp;&nbsp;Throughout most of 2025, the share of users running into fake shop scams stayed relatively low. From late spring, it started to creep up, then shot up sharply in October as holiday campaigns kicked in. The chart below shows this “risk ratio”, that is, the percentage of active users who have been protected from fake shops on any given day.&nbsp;

That is not a coincidence. When people are hunting for bargains, feeling rushed, and bombarded with ads, they are more likely to click before they think. Scammers know this and flood the internet with convincing fake shops that look like the real thing. &nbsp;This blog walks through what we are seeing and what you can do to stay safe while you shop.&nbsp;<h2>What we are seeing this shopping season&nbsp;</h2>When we looked at the domains behind these fake shops, a clear pattern appeared:&nbsp;Many scam sites run on legitimate platforms such as Shopify, MyShopline, Shoplazza, and Chinese frameworks such as Shopage.org. These services are designed to help small businesses get online quickly, but they also give fraudsters an easy way to launch professional-looking stores at speed.&nbsp;Most of the fake shops we saw are wrapped in seasonal themes. Right now, many are covered in festive banners and countdown timers. Some have already switched to Christmas layouts and “holiday sale” branding to catch early gift shoppers.&nbsp;

The way victims arrive at these sites is also telling. Rather than relying on spam email, scammers are buying placement in Facebook Ads and TikTok Ads. These ads can be highly targeted, so a fake offer for designer glasses, sneakers or kitchen gadgets can be shown directly to the people most likely to be interested. Fake shops are not a problem just in the United States. In fact, during October and November alone, we blocked almost 260 000 fake e-shop domains worldwide, which is around four times higher than the same shopping season last year. The map below shows the share of users we protected from fake shop scams in each country in 2025. Darker colors mean a higher proportion of people in that country ran into at least one blocked fake shop, with clear hotspots in North America, much of Europe and Australia, but activity almost everywhere.&nbsp;

<h2>Copy-paste shops and the role of AI tools&nbsp;</h2>We also saw multiple "single product" fake shops that look almost identical. One example promoted "intelligent reading glasses" with bold claims about advanced optics and a big 50 percent discount. Another pushed a "designer wine glass" using the same layout, the same type of trust badges, and nearly the same urgency-driven messages.&nbsp;You can think of these as copy-paste shops. Once a scammer has a template that works, they can quickly clone it and swap in a new product, image and price.&nbsp;While we did not confirm AI built stores in this particular dataset, the tools to automate this already exist. AI store builders for Shopify and AI powered marketing tools promise to create product pages, write copy, and generate ad campaigns in a few clicks. In the wrong hands, that makes it easier for fraudsters to launch more fake shops faster and to test which lures work best.&nbsp;

<h2>How fake shops fake trust&nbsp;</h2>Modern fake shops are not just about flashy discounts. They are designed to look legitimate at a glance.&nbsp;Many use polished templates and SSL certificates, so the little padlock icon appears in the browser. That padlock only means the connection is encrypted, not that the site is honest, but scammers know people trust it.&nbsp;Some fake shops seed third party review platforms with positive reviews to boost their scores. In our analysis we saw cases where those reviews were later removed by the platform for breaking guidelines, a strong sign they were fake. In at least one case, the scam site ran on a subdomain of an older, existing site and showed Black Friday deals alongside those disputed reviews. Piggybacking on an established domain is another way to look more credible.&nbsp;On social media, scammers run ads that look like any other promotion in your feed. They often target specific demographics, interests or locations, and in some cases even reply to comments or reviews to keep up the illusion of a real business.&nbsp;

<h2>How to Spot a Fake Online Shop&nbsp;</h2>There is no single trick that catches every scam, but a few simple habits can dramatically lower the risk:&nbsp;<ol><li>Check the address bar, not just the logo. Look closely at the URL. Watch out for strange spellings, extra words, or domains that do not match the brand name you expect.</li><li>Be skeptical of “too good to be true” discounts. Genuine retailers do run big Black Friday sales, but if a high demand product is half the usual price, treat it as suspicious.</li><li>Verify reviews. Do not rely only on the testimonials shown on the shop itself. Search the store name together with words like "reviews", "scam" or "complaints". Be wary if you only find a handful of overly positive comments.</li><li>Check contact and return information. Legitimate shops make it easy to see who they are and how to reach them, for example a physical address, company name, clear return policy, and real customer service options. Vague contact details or only a web form are warning signs.</li><li>Use security tools and safer payment methods. Enable browser protection and make sure your security solutions are on so known scam domains are blocked before you land on them. When you pay, prefer options that offer buyer protection, such as credit card or trusted payment service, and avoid bank transfers, gift cards or cryptocurrency for online purchases.&nbsp;</li></ol>Scammers treat Black Friday, Cyber Monday and the entire holiday shopping season as a business opportunity. They use the same tools, platforms and marketing channels as legitimate stores, just with a very different goal.&nbsp;The good news is that you do not need to stop shopping online to stay safe. A bit of skepticism, a habit of checking before you click, and the right security tools in the background will go a long way to keep your money and data out of their hands.&nbsp;

Fake online shops surged during Black Friday and the holiday season, up 185% this year. Here’s what scammers are doing.

Holiday scams: How fraudsters exploit the shopping season and how to stay safe 

Threat Research Team

State-sponsored hacking groups typically operate in isolation, each advancing its own nation’s goals. That’s why any sign of collaboration between them is cause for concern. Yet new evidence uncovered by Gen researchers suggests that two of the world’s most aggressive advanced persistent threat (APT) actors, Russia-aligned Gamaredon and North Korea’s Lazarus, may be operating on shared infrastructure.&nbsp;&nbsp;This discovery hints at something much bigger than mere technical overlap. It points to a possible new stage in cyber conflict, where geopolitical alliances are mirrored in shared digital operations.&nbsp;&nbsp;<h2>From allies on the battlefield to partners online&nbsp;</h2>Russia and North Korea have maintained a long-standing partnership rooted in shared political and military interests. Moscow backed Pyongyang during and after the Korean War, and in 2024 both nations renewed that alliance through a Comprehensive Strategic Partnership that includes mutual defense commitments.&nbsp;Since 2022, Pyongyang has stepped up its support for Moscow, formally recognizing Russian-claimed territories in Ukraine and reportedly supplying munitions and troops. In 2024, Reuters reported that North Korean soldiers had been deployed to fight alongside Russian forces in Ukraine, a striking example of the two countries’ deepening cooperation.&nbsp;Now, we may be witnessing a digital extension of that alliance. On July 28, 2025, Gen’s internal monitoring systems detected a suspicious event linking Gamaredon and Lazarus activity through a shared IP address. The implications are significant: two state-backed actors from different countries may be coordinating at an operational level.&nbsp;This development aligns with broader patterns highlighted in the <a href="https://www.gendigital.com/blog/insights/reports/threat-report-q3-2025" target="_blank" rel="noreferrer noopener">Q3/2025 Threat Report</a>, where state sponsored operations showed increasing sophistication, coordination, and diversification of infrastructure. While those observations were confined within national ecosystems, the Gamaredon–Lazarus overlap suggests that similar dynamics may now be emerging across national boundaries.&nbsp;<h2>Background&nbsp;</h2><h3>Gamaredon&nbsp;</h3>Gamaredon is a Russian-aligned APT active since at least 2013, primarily focused on cyber espionage. In 2021, the Security Service of Ukraine issued a <a href="https://ssu.gov.ua/en/novyny/sbu-vstanovyla-khakeriv-fsb-yaki-zdiisnyly-ponad-5-tys-kiberatak-na-derzhavni-orhany-ukrainy" target="_blank" rel="noreferrer noopener">press release</a>, attributing several members of the group as part of Russia's Federal Security Service (FSB) 18th Information Security Center. Since its official inception, the group is believed to have conducted more than 5000 cyber-attacks, most of which targeted Ukrainian government agencies. However, with the onset of war in Ukraine, ESET <a href="https://www.welivesecurity.com/en/eset-research/cyberespionage-gamaredon-way-analysis-toolset-used-spy-ukraine-2022-2023/" target="_blank" rel="noreferrer noopener">reported</a> that Gamaredon expanded its operations to include NATO member states, likely aiming to disrupt military aid to Ukraine, underscoring the group’s prioritization of hybrid warfare.&nbsp;<h3>Lazarus&nbsp;</h3>Lazarus is a state-sponsored threat actor active since 2009 and widely believed to operate under North Korea’s government. Initially focused on cyber espionage and destructive attacks, Lazarus later shifted toward financially motivated operations to fund future campaigns. In 2021, the United States Department of Justice <a href="https://www.justice.gov/archives/opa/pr/north-korean-regime-backed-programmer-charged-conspiracy-conduct-multiple-cyber-attacks-and" target="_blank" rel="noreferrer noopener">indicted</a> three members believed to be part of the Lazarus group, connecting them to North Korea’s Reconnaissance General Bureau (RGB), the country’s primary intelligence agency. With the rise of cryptocurrency, Lazarus increasingly targeted digital assets, as evidenced by high-profile breaches such as <a href="https://www.fbi.gov/news/press-releases/fbi-identifies-lazarus-group-cyber-actors-as-responsible-for-theft-of-41-million-from-stakecom" target="_blank" rel="noreferrer noopener">Stake.com</a> ($41 million), <a href="https://www.fbi.gov/news/press-releases/fbi-identifies-cryptocurrency-funds-stolen-by-dprk" target="_blank" rel="noreferrer noopener">AtomicWallet</a> ($100 million), <a href="https://www.businesstoday.in/technology/news/story/wazirx-hacked-north-korean-hackers-behind-235-million-theft-from-indian-investors-report-reveals-439240-2024-07-29" target="_blank" rel="noreferrer noopener">WazirX</a> ($235 million), and <a href="https://neobanque.ch/blog/bybit-1-4-billion-hack-lazarus-group-2025/" target="_blank" rel="noreferrer noopener">Bybit</a> ($1.4 billion).&nbsp;Where Gamaredon spies, Lazarus steals, but both ultimately serve their governments’ strategic interests.&nbsp;<h3>The discovery: a shared digital footprint&nbsp;</h3>Just one day after the <a href="https://www.reuters.com/business/aerospace-defense/russia-starts-first-moscow-pyongyang-passenger-flights-decades-2025-07-27/" target="_blank" rel="noreferrer noopener">announcement</a> of new direct flights between Moscow and Pyongyang, Gen identified indicators of a potential collaboration between the Gamaredon and Lazarus APTs. On July 24, 2025, our system tracking Gamaredon’s Command-and-Control (C2) servers via known Telegram and Telegraph channels blocked an IP address:&nbsp;144[.]172[.]112[.]106&nbsp;

Four days later, during a routine check, the same server was found hosting an obfuscated version of InvisibleFerret (SHA256: `128da948f7c3a6c052e782acfee503383bf05d953f3db5c603e4d386e2cf4b4d`), a malware strain attributed to Lazarus. The payload matched Lazarus’ tooling and was delivered through an identical server structure (URL: `http[://]144[.]172[.]112[.]106/payload/99/81`) previously seen in ContagiousInterview, a Lazarus campaign that targeted job seekers with fake recruitment messages. While the IP could represent a proxy or VPN endpoint, the temporal proximity of both groups’ activity and the shared hosting pattern indicate probable infrastructure reuse, with moderate confidence of operational collaboration. Whether Lazarus leveraged a Gamaredon-controlled server or both actors shared the same client instance remains unclear, but the overlap is too close to ignore.&nbsp;&nbsp;<h2>Implications for the global threat landscape&nbsp;</h2>Cross-country collaborations in the APT ecosystem remain exceptionally rare. The last widely acknowledged example dates back to 2014 with the <a href="https://theintercept.com/2014/11/24/secret-regin-malware-belgacom-nsa-gchq/" target="_blank" rel="noreferrer noopener">Regin</a> malware, reportedly co-developed by the U.S. National Security Agency (NSA) and the U.K.’s Government Communications Headquarters (GCHQ).&nbsp;If confirmed, the Gamaredon–Lazarus overlap would represent the first known case of Russian–North Korean cyber collaboration in the wild.&nbsp;Such a partnership could have wide-ranging implications:&nbsp;<ul><li>Operational synergy: Lazarus’s expertise in monetizing cyberattacks through cryptocurrency theft could help Gamaredon fund or conceal future operations.</li><li>Strategic alignment: Russia, facing mounting economic and military pressure, could benefit from North Korea’s established infrastructure for covert financial operations.</li><li>Escalation potential: This kind of collaboration blurs the line between espionage, sabotage, and organized cybercrime, expanding both nations’ offensive reach.&nbsp;</li></ul><h2>Not an isolated case: national ecosystems are merging&nbsp;</h2>While cross-border APT collaboration is rare, cooperation within national ecosystems has become increasingly common.&nbsp;<h3>Lazarus x Kimsuky&nbsp;</h3>Kimsuky is another North Korean APT group. It has been active since around 2012 and assessed by <a href="https://cloud.google.com/blog/topics/threat-intelligence/mapping-dprk-groups-to-government" target="_blank" rel="noreferrer noopener">Mandiant</a> to operate under the RGB. The group specializes in advanced cyber-espionage campaigns, primarily targeting government entities and consumer-facing organizations.&nbsp;During analysis of Lazarus’ ContagiousInterview payloads, Gen researchers found that an IP address (216[.]219[.]87[.]41) later reappeared in Kimsuky-linked payloads (e.g., cce27340fd6f32d96c65b7b1034c65d5026d7d0b96c80bcf31e40ab4b8834bcd). This suggests infrastructure reuse or coordination between RGB units, evidence of alignment at North Korea’s national level.&nbsp;<h3>DoNot x SideWinder&nbsp;</h3><a href="https://www.amnesty.org/en/latest/news/2021/10/togo-activist-targeted-with-spyware-by-notorious-hacker-group/" target="_blank" rel="noreferrer noopener">DoNot</a> and <a href="https://cdn-cybersecurity.att.com/docs/global-perspective-of-the-sidewinder-apt.pdf" target="_blank" rel="noreferrer noopener">SideWinder</a> are state-sponsored APT groups believed to have been active since 2013 and 2012, respectively, both with ties to the Indian government and a primary focus on cyber espionage.&nbsp;Gen identified a DoNot-attributed payload (8bb089d763d5d4b4f96ae59eb9d8f919e6a49611c183f636bfd5c01696447938) that later executed a known SideWinder loader (f4d10604980f8f556440460adc71883f04e24231d0a9a3a323a86651405bedfb). The victim was located in Pakistan, consistent with the typical targeting profile of both groups. This cooperation resembles the previously observed <a href="https://www.eset.com/us/about/newsroom/research/eset-research-gamaredon-and-turla-target-high-profile-ukrainian-entities/" target="_blank" rel="noreferrer noopener">Gamaredon x Turla collaboration</a>, indicating that intra-country partnerships are becoming a tactical norm.&nbsp;&nbsp;

<h2>A new phase in cyber geopolitics&nbsp;</h2>The evidence of infrastructure overlap between Lazarus and Gamaredon represents a significant development in the global threat landscape. Historically, cross-country APT collaborations have been exceedingly rare, with only a handful of confirmed cases such as Stuxnet and Regin. This potential partnership signals a shift toward more complex and unpredictable alliances, where geopolitical interests may drive operational convergence.&nbsp;While the Lazarus–Gamaredon case stands out for its strategic implications, the observed intranational collaborations, such as Lazarus with Kimsuky and DoNot with SideWinder, are equally important. These partnerships demonstrate a growing trend of resource sharing and tactical alignment within national ecosystems, amplifying the reach and resilience of state-sponsored campaigns.&nbsp;For defenders, these findings underscore an urgent need to adapt detection strategies beyond single-actor attribution. Shared infrastructure, overlapping TTPs, and modular malware frameworks mean that traditional attribution models may fail to capture the full scope of risk. Security teams must:&nbsp;<ul><li>Enhance infrastructure correlation analysis to detect cross-group overlaps early. </li><li>Prioritize intelligence sharing across organizations and sectors to identify emerging alliances. </li><li>Implement layered defenses capable of mitigating diverse tactics from multiple threat actors leveraging common resources.&nbsp;</li></ul>The era of isolated APT operations is fading. As adversaries evolve through collaboration, defenders must respond with equal agility and cooperation to safeguard critical assets.

Gen Threat Labs uncover evidence of rare cross-country coordination between Russia’s Gamaredon and North Korea’s Lazarus

Alliances of convenience: How APTs are beginning to work together 

In recent weeks, our Threat Labs researchers have uncovered two new toolsets that show just how adaptive the DPRK’s operations have become. Kimsuky, known for its espionage-style campaigns, deployed a new backdoor we’ve named HttpTroy, while Lazarus introduced an upgraded version of its BLINDINGCAN remote access tool.&nbsp;Both attacks reveal the same underlying pattern: stealthy code and layered obfuscation. In this post, we’ll break down how these tools work, what they target and what defenders can learn from the latest moves inside the DPRK playbook.&nbsp;<h2>Inside DPRK’s Latest Campaigns: How Kimsuky and Lazarus Refine Their Playbook&nbsp;</h2>The Kimsuky attack targeted a single victim in KR and started with a ZIP file that looked like a VPN invoice, then quietly installed tools that let attackers move files, take screenshots and run commands. The chain has three steps: a small dropper, a loader called MemLoad, and the final backdoor, named “HttpTroy”. We see several signs that possibly tie this activity to Kimsuky: the Korean language lure, an AhnLab-style scheduled task name and command patterns seen in past Kimsuky work.&nbsp;&nbsp;The Lazarus attack targeted two victims in CA and was caught in the middle of the attack chain, where we observed a new version of the Comebacker malware leading to a new variant of their BLINDINGCAN remote access tool.&nbsp;&nbsp;We’ll explain how these attacks work in plain terms, why North Korea-aligned groups use these tricks, and simple steps you can take to avoid similar threats.&nbsp;Quick takeaways for readers: do not open any attachments you did not expect, treat .scr files as programs not documents and keep your security software on and updated.&nbsp;<h2>Diving into the Kimsuky attack: MemLoad and HttpTroy&nbsp;</h2><h3>The Initial dropper&nbsp;</h3>While the exact delivery mechanism remains unknown, telemetry indicates that the samples was obtained via an internet download, packaged within a ZIP archive named “250908_A_HK이노션_SecuwaySSL VPN Manager U100S 100user_견적서”. Given the nature of the filename, it is highly probable that the archive was distributed through a phishing email.&nbsp;Contained within the archive is a “.scr” file bearing the same name. Execution of this file initiates the entire infection chain.&nbsp;This initial sample is a lightweight GO binary containing 3 embedded files. These files are decrypted using a simple XOR operation with the key “0x39”, then written to disk and executed. To maintain user deception, the binary displays a PDF document as a decoy, displaying a fake bill for VPN services, while simultaneously registering the next stage backdoor as a COM server using “regsvr32.exe”. See below an image of the decoy PDF and the decompiled code that decrypts it.&nbsp;

<h3>Stage 1 backdoor: Memload_V3&nbsp;</h3>The first backdoor, internally identified as Memload_V3 (“Memload_V3.dll”), performs 2 primary functions:&nbsp;

<ol><li>Re-registering the “AhnlabUpdate” scheduled task&nbsp;</li></ol>Using COM interfaces instantiated via the Windows API “CoCreateInstance”, the backdoor re-creates a scheduled task named “AhnlabUpdate”, targeting one of the more prevalent anti-virus software in the Korean region to avoid suspicions. This task is configured to execute the current DLL silently using the command “regsvr32.exe /s &lt;CURRENT_FILENAME&gt;”. The task is then set to repeat every minute, using the “PT1M” repetition pattern.&nbsp;

2. Decrypting and executing the final payload&nbsp;After establishing persistence, Memload_V3 proceeds to decrypt the third file dropped by the initial sample. The decryption algorithm used is RC4, and once decrypted, the payload is loaded directly into memory. Execution is then triggered via its exported function named “hello”.

<h3>Final payload: HttpTroy backdoor&nbsp;</h3>The final stage of the attack chain is a highly obfuscated backdoor, internally named HttpTroy (“httptroy_dll.dll”). This component grants the attackers full control over the compromised system, offering a wide range of capabilities:&nbsp;<ul><li>File upload and download</li><li>Screenshot capture and exfiltration</li><li>Command execution with elevated privileges</li><li>Loading an executable in memory</li><li>Reverse shell</li><li>Process termination and trace removal&nbsp;</li></ul>HttpTroy employs multiple layers of obfuscation to hinder analysis and detection. API calls are concealed using custom hashing techniques, while strings are obfuscated through a combination of XOR operations and SIMD instructions.&nbsp;Notably, the backdoor avoids reusing API hashes and strings. Instead, it dynamically reconstructs them during runtime using varied combinations of arithmetic and logical operations, further complicating static analysis.&nbsp;&nbsp;

The HttpTroy backdoor communicates with its command-and-control server exclusively via HTTP POST requests. All transmitted data (both commands and responses) is obfuscated using a two-step process: XOR encryption with the key 0x56, followed by Base64 encoding. Each query to the C2 has a specific ID and is followed by buffers of interest, all formatted in a single special string. Commands received from the server follow a simple structure: “&lt;command&gt; &lt;parameters&gt;”.&nbsp;

After executing a command, the backdoor reports the result to the C2 using ID 2:&nbsp;<ul><li>ok - Successful execution</li><li>fail - Execution failed</li><li>connect ok - Successful reverse shell connection&nbsp;</li></ul>To request a new command from the C2, the backdoor sends a query with ID 1.&nbsp;Below, you can see an example flow of a command in decompiled code, together with the decryption flow of a response from the server for the “down” command:&nbsp;

<h3>Indicators of compromise&nbsp;</h3>SCR file: e19ce3bd1cbd980082d3c55a4ac1eb3af4d9e7adf108afb1861372f9c7fe0b76&nbsp;Memload_V3: 20e0db1d2ad90bc46c7074c2cc116c2c08a8183f3ac6f357e7ebee0c7cc02596&nbsp;HttpTroy: 10c3b3ab2e9cb618fc938028c9295ad5bdb1d836b8f07d65c0d3036dbc18bbb4&nbsp;C2: hxxp[://]load[.]auraria[.]org/index[.]php&nbsp;User-agent (wide-string): Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36&nbsp;Mutexes:&nbsp;a:fnjiuygredfgbbgfcvhutrv&nbsp;u:fnjiuygredfgbbgfcvhutrv&nbsp;<h2>Analysis of the Lazarus Attack: the comeback of Comebacker and the new BLINDINGCAN variant&nbsp;</h2><h3>Comebacker, yet again&nbsp;</h3>During routine threat monitoring, our team identified a sample indicative of a new variant of the previously documented Comebacker malware, which is attributed to the Lazarus APT group. While our telemetry captures the infection chain from this stage onward, the initial access vector remains unclear. However, based on the absence of any exploited vulnerabilities, we assess with moderate confidence that the initial compromise likely originated from a phishing email.&nbsp;We observed two closely related instances of the Comebacker malware:&nbsp;<ul><li>A DLL variant located at “C:\ProgramData\comms.bin” (internally named “NetSvcInst_v1_Rundll32.dll”, using the exported function “InfoHook”)</li><li>An EXE variant located at “C:\ProgramData\Comms\ssh.bin”&nbsp;</li></ul>The DLL sample appears to have been executed via a Windows service, whereas the EXE variant was launched through cmd.exe, suggesting a different execution context.&nbsp;Despite their differing formats, both variants share identical functionality. Their primary objectives include:&nbsp;<ul><li>Validating execution via a specific command-line parameter</li><li>Decrypting embedded payloads</li><li>Configuring registry entries</li><li>Deploying the next-stage payload as a service&nbsp;</li></ul>The dropper's behavior can be summarized in the following stages:&nbsp;<ol><li>Dynamic function resolution&nbsp;</li></ol>Prior to payload execution, the malware dynamically resolves API functions from system DLLs. This is achieved by XOR-decrypting hardcoded strings using a PRNG-like stream.

<ol start="2"><li>Parameter validation&nbsp;</li></ol>Execution is gated by the presence of specific command-line arguments. The DLL variant expects "up45V3FR9ee9", while the EXE variant requires "760H33ls9L5S". If the parameters are incorrect, the malware terminates.&nbsp;<ol start="3"><li>Service name selection&nbsp;</li></ol>The malware enumerates the “REG_MULTI_SZ” entries under “HKLM\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs”, identifying service names that are listed but not yet registered under “HKLM\ SYSTEM\CurrentControlSet\Services”. A random candidate is then selected and reused as both the service name and the name of the service DLL.&nbsp;

For some of the string decryption processes, it uses the HC256 stream cipher, while for others it uses RC4.&nbsp;

<ol start="4"><li>Timestamp logging&nbsp;</li></ol>The malware writes the current local time to “C:\Windows\system32\AppxProvision.xml” using the format “[%04d-%02d-%02d %02d:%02d:%02d] %s\n”, appending the chosen service name. It then modifies the file’s attributes to mimic those of win32k.sys.

<ol start="5"><li>Payload deployment and configuration&nbsp;</li></ol>The embedded PE file is decrypted using HC256, then decompressed via zlib, and written into a decoy file in the current directory named “kjepl.xml”. To obfuscate its true size, random data is appended at the end. The file is then moved via “cmd.exe” to “C:\Windows\system32\&lt;SERVICE_NAME&gt;.dll”, and its attributes are altered similarly to the timestamp file, but this time it mimics “cmd.exe”.&nbsp;

Subsequently, the embedded configuration is decrypted using HC256, re-encrypted using RC4 and stored as a binary blob in the registry under&nbsp; “HKLM\SYSTEM\ControlSet001\Services\kbddes\GUID”. The configuration includes potential C2 addresses, the path to cmd.exe, the path to the dropped DLL, %TEMP%, and a special integrity-check value.&nbsp;

<ol start="6"><li>Service execution&nbsp;</li></ol>Finally, the malware registers and starts a service using the randomly selected name, thereby initiating the next stage of the attack.&nbsp;

<h3>Second stage: Compcat_v1.dll&nbsp;</h3>Both observed variants of the Comebacker dropper deploy the same service binary, internally named “Compcat_v1.dll”. This component serves a singular purpose: it acts as a wrapper for the final payload.&nbsp;Upon execution, it decrypts an embedded PE file using the HC256 stream cipher. The decrypted data is then decompressed using the miniz library, a lightweight zlib-compatible implementation. The resulting PE is loaded directly into memory, employing a technique similar to that used by the aforementioned MemLoad sample.&nbsp;Once the payload is successfully mapped into memory, the malware invokes the exported function “OPENSLL_NONPIC”, thereby initiating the execution of the final stage.&nbsp;

<h3>Final payload: new variant of BLINDINGCAN&nbsp;</h3>As the final payload, the attackers employed a new variant of their BLINDINGCAN remote access tool, improved with additional cryptographic elements and more capabilities. Internally named “T_DLL64.dll”, it acts as a complete suite for attackers, offering them the possibility to perform any action they desire.&nbsp;The backdoor has 2 operating modes, which are dictated by the parameter passed to the main function:&nbsp;<ul><li>13398 – config stored in a file</li><li>13399 – config stored in registry&nbsp;</li></ul>Apart from the “OPENSSL_NONPIC” export, this sample exports another function, called “MemLoad”, which uses the other operating mode (13398).&nbsp;The malware’s execution begins by dynamically loading APIs, using the same techniques as in the previous cases. It then moves on to loading the configuration, picking a C2 at random and attempting to connect to it.&nbsp;Next, it attempts to authenticate itself within the chosen C2 by sending a “GET” request with the integrity-check value from the config, followed by 4 random uppercase letters. This newly obtained value is then shifted with a random offset between 0 and 9 (which is appended at the end of the buffer), XOR-encrypted with 0xC6 and Base64-encoded before being sent. To add to the authenticity of the request, the malware also sends additional buffers of key-value pairs filled with random values.&nbsp;If the authentication succeeds, it proceeds to generate RSA-2048 keys for encryption. The public key is then sent to the C2 in a similar fashion. The same operations regarding the config integrity-check value are performed, and their value represents the beginning of the data. Following that, the values 23, 0, and the size of the public key are appended before the public key (separated by spaces), then encrypted with HC256 and the same XOR + Base64 combo as before. Similar randomness is added after, and the request is sent as such.&nbsp;

From the response, the malware obtains some RSA-encrypted values, that are then decrypted and will serve in future communications as key and IV for encryption via the EVP interface.&nbsp;

Due to the functions used in the structure that contains the “evp_cipher_st” struct for the encryption functions, we conclude that the encryption used is AES-128-CBC.&nbsp;Subsequently, the malware enters its main command loop, constantly communicating with the C2 and executing the commands of the attackers.&nbsp;The communication pattern to the C2 is now as follows:&nbsp;<ol><li>Join by space 2 per-command specific values and the size of the data to be sent</li><li>First parameter is the command ID</li><li>Second parameter represents the status of the command1 – Success sending regular chunk (for streamed buffers – typically 100KB chunks)2 – Error3 – Success sending end chunk (if the buffers are not streamed, this value is used)</li><li>Append the data and AES-128-CBC encrypt everything</li><li>String-shift the same config token + 4 random letters by a random value (0-9) appended at the end, then XOR+Base64 encode it</li><li>Compute MD5 of the encrypted payload and append the encrypted data after the hash, then XOR+Base64 encode it</li><li>Build the base request data as “&lt;RANDOM_2_LETTERS&gt;=&lt;XOR+BASE64(SHIFTED_TOKEN || 4_RANDOM_LETTERS) || SHIFT_OFFSET&gt;&amp;&lt;RANDOM_4_LETTERS&gt;=&lt;RANDOM_4_OR_5_LETTERS&gt;&amp;&lt;RANDOM_5_LETTERS&gt;=&lt;XOR+BASE64(MD5 || ENCRYPTED_DATA)&gt;”</li><li>Append a random amount of random key-value pairs after the base data&nbsp;</li></ol>

In similar fashion, responses are XOR + Base64 decoded, integrity-checked using MD5, and AES-128-CBC decrypted in case of a match.&nbsp;Continuing, we will describe the functionalities of the RAT:&nbsp;<ul><li>Command ID 1<ul><li>Exfiltrate file, starting from an offset and compressing it</li><li>Input: &lt;SRC_PATH&gt;|&lt;OFFSET&gt;</li><li>Chunked</li></ul></li><li>Command ID 2<ul><li>Downloads a file from the C2</li><li>Input: &lt;DEST_PATH&gt;|&lt;SIZE_OF_DATA_BLOCK&gt;|&lt;BYTES_TO_WRITE</li><li>Chunked</li></ul></li><li>Command ID 3<ul><li>Copies a file to %TEMP% and exfiltrates it from there</li><li>Input: &lt;SRC_PATH&gt;|&lt;OFFSET&gt;</li><li>Chunked</li></ul></li><li>Command ID 4<ul><li>Securely delete a file by overwriting it and renaming it multiple times</li><li>Input: &lt;FILE_PATH&gt;</li><li>Not chunked</li></ul></li><li>Command ID 5<ul><li>Changes a file’s attributes to mimic another file</li><li>&lt;DEST_PATH&gt;|&lt;SRC_PATH&gt;</li><li>Not chunked</li></ul></li><li>Command ID 6<ul><li>Recursively traverses all sub-directories and files from a given path, also reporting their size</li><li>Input: &lt;SRC_DIR_PATH&gt;</li><li>Not chunked</li></ul></li><li>Command ID 7<ul><li>Traverses the entire file system, listing the empty space from drives, files and their attributes</li><li>Chunked</li></ul></li><li>Command ID 8<ul><li>Gathers data from the victim computer, such as locale info, computer name, OS version, MAC address, network adapters, CPU architecture, OEM code page</li><li>Not chunked</li></ul></li><li>Command ID 9<ul><li>Runs a command-line via CreateProcessW</li><li>Input: &lt;CMDLINE&gt;</li><li>Not chunked</li></ul></li><li>Command ID 10<ul><li>Runs a command-line in a given session via CreateProcessAsUserW</li><li>Input: &lt;CMDLINE&gt;|&lt;SESSION_ID&gt;</li><li>Not chunked</li></ul></li><li>Command ID 11<ul><li>Lists active processes (provides EXE name, full image path, PID, PPID, SID, user and creation time)</li><li>Chunked</li></ul></li><li>Command ID 12<ul><li>Kills a process</li><li>Input: &lt;PROCESS_ID&gt;</li><li>Not chunked</li></ul></li><li>Command ID 13<ul><li>Keep alive request</li><li>Not chunked</li></ul></li><li>Command ID 14<ul><li>Sleeps for a given period, checking for early wake conditions such as new drives or sessions every 5 seconds</li><li>Input: &lt;SLEEP_DURATION&gt;</li><li>Not chunked</li></ul></li><li>Command ID 15<ul><li>Hibernate for a given period, checking for early wake conditions every minute</li><li>Input: &lt;HIBERNATION_DURATION&gt;</li><li>Not chunked</li></ul></li><li>Command ID 16<ul><li>Updates the config from the binary’s current config</li><li>Not chunked</li></ul></li><li>Command ID 17<ul><li>Send the current config from the binary to the C2</li><li>Not chunked</li></ul></li><li>Command ID 18<ul><li>Removes traces, securely deletes itself and terminates itself</li><li>Not chunked</li></ul></li><li>Command ID 19<ul><li>Test TCP connection to a given IP address</li><li>Input: &lt;IP&gt;:&lt;PORT&gt; &lt;TIMEOUT&gt;</li><li>Not chunked</li></ul></li><li>Command ID 20<ul><li>Runs cmd.exe with the provided command line and reports back the output</li><li>Input: &lt;COMMAND_LINE&gt;</li><li>Chunked</li></ul></li><li>Command ID 21<ul><li>Changes the current working directory</li><li>Input: &lt;DIR_PATH&gt;</li><li>Not chunked</li></ul></li><li>Command ID 22<ul><li>Obtains the current working directory</li><li>Not chunked</li></ul></li><li>Command ID 23<ul><li>Updates encryption keys with new values</li><li>Not chunked</li></ul></li><li>Command ID 24<ul><li>Takes a screenshot and sends it to the C2</li><li>Chunked</li></ul></li><li>Command ID 25<ul><li>Enumerate or take a photo from the available video capture devices using COM interfaces; in the case of GETPIC, the resulting buffer is compressed</li><li>Input: &lt;GETLIST&gt; or &lt;GETPIC&gt; &lt;INDEX&gt;</li><li>Not chunked</li></ul></li><li>Command ID 26<ul><li>Runs a PE file in memory</li><li>Input: &lt;SIZE&gt;|&lt;EXPORT_NAME&gt;|&lt;ARGUMENT&gt;|&lt;MD5_OF_PE&gt;</li><li>Chunked</li></ul></li><li>Command ID 27<ul><li>Updates the config with data from the C2</li><li>Input: &lt;NEW_CONFIG_BYTES&gt;</li><li>Not chunked&nbsp;</li></ul></li></ul><h3>Indicators of compromise&nbsp;</h3>new Comebacker variants: 509fb00b9d6eaa74f54a3d1f092a161a095e5132d80cc9cc95c184d4e258525b&nbsp;&nbsp;b5eae8de6f5445e06b99eb8b0927f9abb9031519d772969bd13a7a0fb43ec067&nbsp;&nbsp;&nbsp;Service binary: 368769df7d319371073f33c29ad0097fbe48e805630cf961b6f00ab2ccddbb4c&nbsp;&nbsp;new BLINDINGCAN: c60587964a93b650f3442589b05e9010a262b927d9b60065afd8091ada7799fe&nbsp;C2s:&nbsp;&nbsp;hxxp[://]166[.]88[.]11[.]10/upload/check.asp&nbsp;hxxps[://]tronracing[.]com/upload/check.asp&nbsp;hxxp[://]23[.]27[.]140[.]49/Onenote/index.asp&nbsp;<h2>Conclusion&nbsp;</h2>Kimsuky and Lazarus continue to sharpen their tools, showing that DPRK-linked actors aren’t just maintaining their arsenals, they’re reinventing them. These campaigns demonstrate a well-structured and multi-stage infection chain, leveraging obfuscated payloads and stealthy persistence mechanisms. From the initial stages to the final backdoors, each component is designed to evade detection, maintain access and provide extensive control over the compromised system. The use of custom encryption, dynamic API resolution and COM-based task registration/services exploitation highlights the groups’ continued evolution and technical sophistication. Monitoring for these indicators and behaviors is essential for early detection and mitigation of such threats.&nbsp;By tracking every line of code and every new variant, we help surface the patterns that keep defenders one step ahead. Awareness, collaboration, and constant vigilance are what turn technical insights into real-world protection — and that’s where Gen Threat Labs and our global intelligence network can make a difference.&nbsp;&nbsp;

Technical walkthroughs of two DPRK intrusions: Kimsuky’s invoice-themed dropper to HttpTroy, and Lazarus’s Comebacker to BLINDINGCAN plus IOCs, TTPs, and mitigation steps 

DPRK’s Playbook: Kimsuky’s HttpTroy and Lazarus’s New BLINDINGCAN Variant 

Threat Research Team Lead

Sr Threat Analysis Engineer

Junior Threat Analyst Intern

Welcome to the era of VibeScams, where creating a phishing site takes just a few clicks. Using simple prompts, scammers can create nearly any type of website almost instantly, without any prior knowledge. Some web-building platforms recreate an entire site from a screenshot provided by the scammer – from a home page to a shopping cart. They typically also allow perfect language localization, letting scammers instantly clone a legitimate site’s look and feel in multiple languages.&nbsp;This new wave of AI-driven web building tools has dramatically lowered the barrier to entry for cybercriminals, democratizing access to sophisticated site cloning and scam operations. No longer limited to those with knowledge of HTML, CSS, and JavaScript, these platforms allow anyone with an internet connection to replicate trusted brands, banking portals, or exchange interfaces with alarming fidelity. The ease and speed of this process not only accelerate the proliferation of fraudulent websites but also makes it increasingly difficult for users to distinguish between genuine and malicious websites.&nbsp;&nbsp;<h2>A new kind of phishing — VibeScams&nbsp;</h2>We call them VibeScams because the trick isn’t in the code alone — it’s in the feeling. These pages pass the “vibe check”: the right colors, spacing, logo placement, and tiny footer links people trust at a glance. Because AI web builders can recreate that look from a single prompt or screenshot, attackers don’t need coding skills — they only need to get the vibe right. That’s enough to trick people into handing over credentials or cash, and it’s why this wave of scams spreads so fast.&nbsp;

As part of our research for this article, we contacted the web builders which attackers leverage more prevalently, according to our detections. We would like to share our appreciation for those companies, including Lovable, Elementor, Flazio, Softr, Webflow, WebWave, among others, for their fast reactions, quick banning of the websites, and overall cooperation. We would like to encourage anyone who stumbles upon suspicious or malicious websites to also report them to the specific providers. It matters and makes a difference.&nbsp;<h2>VibeScams as an Evolution of Phishing&nbsp;</h2>AI-powered web builders make it easy for anyone—even without coding or design skills—to create professional-looking websites quickly and cheaply. By automating templates, layouts, and even content, these tools lower barriers and speed up development, but they also give attackers the same advantages, enabling scams and phishing campaigns with minimal effort. The process of using such a web builder is so intuitive and user-friendly, it’s familiar to almost everyone. Individuals are typically presented with a simple screen containing a textbox, prompting users to immediately fill in a few lines of instructions to build their dream website. Below, you can find an example of a prompt screen from Lovable, one of the popular AI web building platforms:&nbsp;

AI chatbots always have been constrained in the space what the chatbot allows the user to prompt for. These security mechanisms, which are called “guardrails,” serve as a control system to detect malicious, harmful, or otherwise inappropriate prompts and block the associated responses. However, as we will see in the below examples of impersonating reputable brands, these mechanisms are frequently insufficient.&nbsp;As is typical with phishing and scams, attackers tend to focus on brands, topics or products that are already popular. Typical scam sites include cryptocurrency exchanges, investment portals, banking sites, social media platforms, delivery services, shopping sites and much more.&nbsp;Below, you can find a couple of examples of scam and phishing sites we observed hosted on many of these platforms, all AI generated. Other examples we discovered included MetaMask, DHL and AT&amp;T, among many others.&nbsp;&nbsp;

From cryptocurrency exchanges to fake e-shops and login pages, we’ve also seen other typical types of scams&nbsp; – such as tech-support scams. As can be seen below, in this case, it was recreated using an AI web builder and even localized into German. The attacker likely just uploaded a screenshot of a traditional scam page and asked the AI to rebuild and host it, making the whole process effortless.&nbsp;

While talking about brand impersonation, which is an attempt to mimic the design, logos, content, and URL of a well-known and respected brand, we’ve observed multitude of additional cases using AI web builders. This way the user is easily tricked into believing the website they visited is the official website of the brand. A few examples of brand impersonation of well-known crypto exchange platforms can be found below. Note that none of these are legitimate websites of known cryptocurrency exchanges or login sites for that matter, all of them are either phishing or otherwise scam websites:&nbsp;<ul><li>auth-binance.webflow[.]io</li><li>binance-cdn-auth.webflow[.]io</li><li>coinbase-wallet-verify.replit[.]app</li><li>coinbase-wallet.squarespace[.]com</li><li>auth-coinbase-login.typedream[.]app</li><li>chrome-coinbase-extension.typedream[.]app</li><li>wallet-coinbase.typedream[.]app</li><li>microsoft-teams-login.elementor[.]cloud</li><li>microsoft-outlookserver.odoo[.]com</li><li>cz-microsoft.webflow[.]io</li><li>updateaccount-microsoft.webflow[.]io&nbsp;</li></ul>

Typosquatting is very typical as well. This means the attackers are choosing similarly looking names, with one or more changed characters in the URL:&nbsp;<ul><li>app—trrezor-wallet.webflow[.]io</li><li>app-atomiic-wallet.webflow[.]io</li><li>coiinbase-com-wallet.typedream[.]app</li><li>connect-metamesk-wallet.typedream[.]app&nbsp;</li></ul>A broader list of IoCs can be found in our <a href="https://github.com/avast/ioc/tree/master/VibeScams" target="_blank" rel="noreferrer noopener">GitHub</a>.&nbsp;<h2>Scam Types – Breakdown&nbsp;</h2>Nearly half of the detected websites were traditional phishing pages impersonating familiar login portals like Microsoft, Gmail, or Amazon. About a quarter targeted the cryptocurrency space—either by mimicking popular exchanges such as Coinbase, Binance, and MetaMask, or by promoting cryptocurrency-based investment scams. The remainder included more general scams and other malicious pages.&nbsp;

<h2>Our Testing&nbsp;</h2>During our research, we took this opportunity to try a few web builders ourselves, to see how easy it actually is to create a website resembling known brands. We also used only free versions of the web builders to see what the baseline looks like.&nbsp;You can see our results in a few examples below:&nbsp;

In our opinion, the AI generated testing websites look fairly convincing and they took no money and almost zero effort to create. That’s because we didn’t want to kill the vibe, so we also created all the testing prompts using AI and simply copy and pasted them into the AI web builders. In most cases, we didn’t need any further prompting or tweaking.&nbsp;Note that what we generated here are only the designs. For phishing and scam sites to work properly, there also needs to be some functionality provided, for example credentials exfiltration. Additional functionality like this is commonly offered in paid subscriptions of the web builders, or the attacker can use once again other LLMs to implement this directly into the code because in a lot of cases they can download the design locally and continue the work from there.&nbsp;This demonstration directly showed us the core of why the attackers are using this – they don’t need to understand web at all to create highly believable websites for free (we only used free versions of the web builders).&nbsp;<h2>Pricing models&nbsp;</h2>In general, we consider these services to be cheap since there is quite a bit of competition and the user/attacker has plenty of choices to try, even for free. The fact that the attacker requires almost no skill to create a scam or phishing website highly outweighs the costs here.&nbsp;The range of paid offers is vast, spanning from $0.5 per month to $500 per month, with a variety of free tiers and/or trial periods. Some of the providers also offer lifetime deals for $249 or $599.&nbsp;Many of these subscriptions use a relatively common credits-based model where the customer receives credits which they can use for the AI prompts. Additional aspects, since many of the web builders also offer hosting for the generated webpages, are the website limit, subdomain name selection and the ability to change the subdomain name in the future.&nbsp;Finally, some of the web builders also offer APIs that can be used for streamlining the webpage creation, making the whole process more automatic.&nbsp;<h2>The Impact&nbsp;</h2>It’s important for defenders and analysts to recognize just how accessible and varied these platforms have become. Because the barrier to entry is so low and payment models are flexible, we’re seeing a rapid growth in the number of AI-generated scam and phishing websites. This massive availability means the attackers can quickly spin up new designs and relaunch new scams almost instantly.&nbsp;In total, we were investigating 40 different AI web builders, 12 of which we directly contacted due to a high volume of identified malicious websites. In total, from the beginning of 2025 to the end of August, we blocked approximately 140,000 different AI-generated websites during this time, which makes roughly 580 new malicious generated websites every day, on average.&nbsp;Since January 2025 alone, we protected nearly 190,000 our users, with the U.S., France, Brazil, Germany, and Japan among the most affected. This shows that misuse of AI web builders is a world-wide problem, and we can only expect the threat landscape to grow.&nbsp;

<h2>Conclusion&nbsp;</h2>During our research, we investigated various AI web builders which are being misused by attackers for performing what we call VibeScams – a creation of scam or phishing pages without the need of any knowledge of coding or web creation.&nbsp;AI web builders provide support for individuals who are not technically invested in creating websites, where a simple prompt can suffice for building a new website from scratch. This results in a double-edged sword where it is very useful for both regular users as well as for attackers, which is rather typical with other various AI tools, too.&nbsp;Many of the malicious webpages follow the expected pattern of brand impersonation for phishing attempts and scams, which our research has seen daily for many years. The difference is that with the AI web builders, the attackers need to invest little to no effort or knowledge into creating them. As the AI web builder ecosystem evolves, it’s clear that new features and easier integrations will fuel even more sophisticated phishing campaigns in the future.&nbsp;How to protect yourself:&nbsp;<ul><li>Always watch out for too good to be true offers or investment opportunities</li><li>When dealing with a known brand, always verify whether this is the official website</li><li>Look out for any deviations from the designs you are already familiar with</li><li>Use unique passwords and MFA everywhere, preferably along with a reputable password manager</li><li>Use a reputable AV solution to be proactively protected against phishing and scam attempts</li><li>When in doubt, use products like Norton 360 with AI-powered scam protection to consult the security of links and web pages&nbsp;</li></ul><h3>Indicators of Compromise (IoCs)&nbsp;</h3>A broader list of IoCs can be found on our <a href="https://github.com/avast/ioc/tree/master/VibeScams" target="_blank" rel="noreferrer noopener">GitHub</a>.&nbsp;auth-binance.webflow[.]io&nbsp; binance-cdn-auth.webflow[.]io&nbsp; coinbase-wallet-verify.replit[.]app&nbsp; coinbase-wallet.squarespace[.]com&nbsp; auth-coinbase-login.typedream[.]app&nbsp; chrome-coinbase-extension.typedream[.]app&nbsp; wallet-coinbase.typedream[.]app&nbsp; microsoft-teams-login.elementor[.]cloud&nbsp; microsoft-outlookserver.odoo[.]com&nbsp; cz-microsoft.webflow[.]io&nbsp; updateaccount-microsoft.webflow[.]io&nbsp; app—trrezor-wallet.webflow[.]io&nbsp; app-atomiic-wallet.webflow[.]io&nbsp; coiinbase-com-wallet.typedream[.]app&nbsp; connect-metamesk-wallet.typedream[.]app&nbsp;

AI web builders are fueling a surge in realistic phishing sites that anyone can make

VibeScams: How AI website builders are shaping the internet 

Malware Analyst at Gen

In the ever-evolving landscape of cyber threats, a new ransomware strain known as Midnight has emerged, echoing the notorious tactics of its predecessor, Babuk. First detected by Gen researchers, Midnight blends familiar ransomware mechanics with novel cryptographic modifications – some of which unintentionally open the door to file recovery. This blog dives into the technical anatomy of Midnight, its lineage from Babuk, and the critical indicators of infection. Most importantly, it offers a practical guide to decrypting affected files, empowering victims with a rare opportunity to reclaim their data without paying a ransom.

<h2>Midnight’s Discovery and Roots&nbsp;</h2>Gen researchers have identified a new ransomware strain, internally dubbed Midnight. It shows clear signs of being inspired by the Babuk ransomware family, which first appeared in early 2021 and quickly gained a reputation for its aggressive tactics and advanced technical aspects. Babuk operated as a Ransomware-as-a-Service (RaaS), targeting large organizations across healthcare, finance, government, and other critical infrastructure. The ransomware used strong encryption (HC256 and ECDH) and intermittent file encryption to maximize damage while maintaining speed.&nbsp;In mid-2021, Babuk's operators abruptly shut down and leaked their full source code, including builders for Windows, ESXI and NAS variants. This leak led to a wave of inspired ransomware families, each modifying Babuk's original design to suit their own goals.&nbsp;Midnight is one such evolution. While it retains much of Babuk's core structure, its authors introduced several changes - most notably in the cryptographic scheme used for file encryption. These changes, while likely intended to improve the ransomware's effectiveness, inadvertently introduced weaknesses that make file decryption possible under certain conditions.&nbsp;<h2>How to Recognize Midnight Ransomware&nbsp;</h2>Midnight ransomware typically appends the .Midnight or .endpoint extension to encrypted files. In some cases, the ransomware is configured not to modify the file names. Instead, it appends the extension string directly to the end of the file content. This behavior can be observed in hex dumps and may affect file parsing.&nbsp;

A ransom note named How To Restore Your Files.txt is dropped in the affected directories. It may look similar as on the following screenshots:&nbsp;

Additional indicators include the creation of a mutex named Mutexisfunnylocal, which is used to prevent multiple instances of the ransomware from running simultaneously. Some samples also drop a debug log on the infected system, depending on the configuration. Known variants have been observed creating either Report.Midnight or debug.endpoint as log files.&nbsp;A full list of discovered samples is available in the IoCs section at the end of this article.&nbsp;<h3>Cryptographic Design and Flaws&nbsp;</h3>While Midnight's core structure and execution flow is largely inherited from Babuk, its cryptographic implementation has been significantly reworked. These changes introduced flaws that make file decryption possible, which we leveraged to develop a working decryptor.&nbsp;Midnight uses ChaCha20 for encrypting file contents and RSA for encrypting the ChaCha20 key. The RSA-encrypted key, along with its SHA256 hash, is appended to the end of each encrypted file. This format is consistent across known samples.&nbsp;To improve performance, Midnight employs intermittent encryption, a technique also used by Babuk. However, Midnight refines this approach by applying a more granular file size-based logic to determine which portions of file to encrypt. This allows it to process large files faster while still rendering them unusable.&nbsp;The ransomware accepts several command-line arguments to control its behavior:&nbsp;<ul><li>/e appends the extension string (e.g. .Midnight) directly to the file content instead of modifying the filename.</li><li>/n enables encryption of network-mounted volumes.</li><li>--paths=PATHS targets specific directories for encryption.&nbsp;</li></ul>Earlier samples of Midnight primarily targeted high-value files such as databases, backups, and archives. These included the following extensions:&nbsp;.mdf .ndf .bak .dbf .dmp .rman .frm &nbsp; .ibd .myd .myi .sql .xbk .ldf .vbi &nbsp; .vbk .ibdata .rar .md5 and .bitmap&nbsp; &nbsp;More recent variants have broadened their scope and now encrypt nearly all file types, with the exception of executables such as .exe, .dll, and .msi.&nbsp;<h2>How to Use the Ransomware Decryptor&nbsp;</h2><ol><li>Download the decryptor <a href="https://files.avast.com/files/decryptor/norton/norton_decryptor_midnight64.exe" target="_blank" rel="noreferrer noopener">here</a>. If you still use 32-bit Windows, you can also get the 32-bit version of the decryptor <a href="https://files.avast.com/files/decryptor/norton/norton_decryptor_midnight.exe" target="_blank" rel="noreferrer noopener">here</a>.</li><li>Run the decryptor, preferably as an administrator. It starts as a wizard, leading you through the configuration of the decryption process.</li><li>On the initial page, we have a link to the license information. Click the Next button when you are ready to start.</li></ol>

4. &nbsp; &nbsp; On the next page, the user is asked to provide a list of locations (drives, folders, files) that are to be decrypted. &nbsp; &nbsp; &nbsp; &nbsp; By default, the decryptor provides a list of all local disk drives.

5. &nbsp; &nbsp; On the final page, you can opt-in to back up your encrypted files. These backups may help if anything goes wrong during the decryption process. This option is selected by default, which we recommend. After clicking Decrypt, the decryption process begins. Let the decryptor work and wait until it finishes decrypting all of your files.

For questions or comments about the Norton decryptor, email <a href="mailto:decryptors@avast.com" target="_blank" rel="noreferrer noopener">decryptors@avast.com</a>.&nbsp;<h3>IoCs: Ransomware Samples&nbsp;</h3>dd9de77c6e17093b0b2150b3f0c66e8526369ba68fb7b9a5758ff9274d85342e&nbsp; 3d9a71cfec82fef531227465f40d9106e671ef162fa3ab21119e2ee08612e0aa&nbsp; 300c46bf17e8bd0cd5ac800a33e1d27ef9001aecef1f98965414bf9c33af19e0&nbsp; 1e58448808006de410ddb31a4d6ff8292aa70168f69f2b7e08144d6090d5084d&nbsp; aa8a043fd3d64fc96864cf5361bbb82012cc4b2e1a909c747038edcf2b4369e7&nbsp;&nbsp;

Midnight ransomware echoes Babuk’s tactics but stumbles in its code. Gen researchers explain how those mistakes make decryption and recovery possible

Decrypted: Midnight Ransomware 

Malware Researcher at Gen

Researchers at Avast developed a decryptor for the FunkSec ransomware. We have been cooperating with law-enforcement agencies to help victims decrypt files for free. Because the ransomware is now considered dead, we released the decryptor for public download.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="https://files.avast.com/files/decryptor/avast_decryptor_funksec64.exe" target="_blank" title="Download the Decryptor">Skip directly to the decryptor download</a>&nbsp;We counted 113 victims of the ransomware in total (based on the ransomware leak site). Because the first victim appeared earlier than the initial source, we assume that the FunkSec gang only did data exfiltration and subsequent extortion from the beginning, and then also added data encryption. Here’s a simple timeline of the ransomware operations:&nbsp;<ul><li>04-Dec-2024: The first victims appeared on the ransomware gang’s leak site&nbsp;</li><li>15-Dec-2024: The initial source file was uploaded to Virus Total&nbsp;</li><li>31-Dec-2024: The first known ransomware sample was uploaded to Virus Total&nbsp;</li><li>15-Mar-2025: The latest known victim&nbsp;</li></ul><h2 class="text-align-justify">AI-Powered Ransomware&nbsp;</h2><a href="https://www.ransomlook.io/groups#Funksec" target="_blank" rel="noreferrer noopener">Sources</a> report that AI was used to assist in writing this ransomware. Notably, the authors used AI to create tools and phishing templates, though they emphasize that AI contributes to only about 20% of their operations.&nbsp;Overall, samples of the ransomware mostly fail to work. Some of them depend on external image (supposed to become a desktop wallpaper) downloaded from <a href="https://imgur.com/" target="_blank" rel="noreferrer noopener">Imgur</a>:&nbsp;<ul><li>hxxps[:]//i.imgur.com/HCYQoVR.jpeg</li><li>hxxps[:]//i.imgur.com/mlUvWYT.jpeg&nbsp;</li></ul><h2>How to Recognize FunkSec Ransomware&nbsp;</h2>Files encrypted with FunkSec ransomware have the “.funksec” extension:&nbsp;

Also, a ransom note file called “README-{random}.md” is dropped to every folder.

<h2>FunkSec Ransomware Analysis</h2>Ransomware is written in Rust programming language. For cryptographic operations, it uses orion-rs library, <a href="https://github.com/orion-rs/orion/releases/tag/0.17.7">version 0.17.7</a>. Files are encrypted using Chacha20 with the help of <a href="https://github.com/openssl/openssl/blob/master/crypto/poly1305/poly1305.c">Poly1305 MAC</a>. This hash-based method ensures integrity of encryption parameters: the encryption key, n-once, block lengths, and encrypted data itself.Files are encrypted per-blocks of 128 bytes, adding 48 bytes of extra metadata to each block, which means that encrypted files are about 37% bigger than the originals.When executed, the ransomware searches all local drives (by drive letter) and encrypts all files, except the ones with these extensions:<table class="table"><tbody><tr><td>&nbsp;.7z&nbsp; &nbsp; &nbsp; .aac&nbsp; &nbsp; &nbsp;.ai&nbsp; &nbsp; &nbsp; .apk&nbsp; &nbsp; &nbsp;.avi&nbsp; &nbsp; &nbsp;.avro&nbsp; &nbsp; .azw3&nbsp; &nbsp; .bak&nbsp; &nbsp; &nbsp;.bat.bib&nbsp; &nbsp; &nbsp;.bin&nbsp; &nbsp; &nbsp;.bkp&nbsp; &nbsp; &nbsp;.c&nbsp; &nbsp; &nbsp; &nbsp;.cer&nbsp; &nbsp; &nbsp;.chm&nbsp; &nbsp; &nbsp;.cpp&nbsp; &nbsp; &nbsp;.csr&nbsp; &nbsp; &nbsp;.css.csv&nbsp; &nbsp; &nbsp;.cue&nbsp; &nbsp; &nbsp;.dat&nbsp; &nbsp; &nbsp;.db&nbsp; &nbsp; &nbsp; .dbf&nbsp; &nbsp; &nbsp;.deb&nbsp; &nbsp; &nbsp;.djvu&nbsp; &nbsp; .dll&nbsp; &nbsp; &nbsp;.dmg.docx&nbsp; &nbsp; .dwg&nbsp; &nbsp; &nbsp;.dxf&nbsp; &nbsp; &nbsp;.ear&nbsp; &nbsp; &nbsp;.eml&nbsp; &nbsp; &nbsp;.eps&nbsp; &nbsp; &nbsp;.epub&nbsp; &nbsp; .etl&nbsp; &nbsp; &nbsp;.exe.fb2&nbsp; &nbsp; &nbsp;.fla&nbsp; &nbsp; &nbsp;.flac&nbsp; &nbsp; .flv&nbsp; &nbsp; &nbsp;.git&nbsp; &nbsp; &nbsp;.gpg&nbsp; &nbsp; &nbsp;.hdf5&nbsp; &nbsp; .html&nbsp; &nbsp; .indd.ini&nbsp; &nbsp; &nbsp;.ipa&nbsp; &nbsp; &nbsp;.iso&nbsp; &nbsp; &nbsp;.jar&nbsp; &nbsp; &nbsp;.java&nbsp; &nbsp; .js&nbsp; &nbsp; &nbsp; .json&nbsp; &nbsp; .jsx&nbsp; &nbsp; &nbsp;.kdbx.key&nbsp; &nbsp; &nbsp;.log&nbsp; &nbsp; &nbsp;.lst&nbsp; &nbsp; &nbsp;.m3u&nbsp; &nbsp; &nbsp;.md&nbsp; &nbsp; &nbsp; .mdb&nbsp; &nbsp; &nbsp;.midi&nbsp; &nbsp; .mkv&nbsp; &nbsp; &nbsp;.mov.mp3&nbsp; &nbsp; &nbsp;.mp4&nbsp; &nbsp; &nbsp;.msg&nbsp; &nbsp; &nbsp;.msi&nbsp; &nbsp; &nbsp;.nfs&nbsp; &nbsp; &nbsp;.odp&nbsp; &nbsp; &nbsp;.ods&nbsp; &nbsp; &nbsp;.odt&nbsp; &nbsp; &nbsp;.ogg.opf&nbsp; &nbsp; &nbsp;.parquet .pdb&nbsp; &nbsp; &nbsp;.pdf&nbsp; &nbsp; &nbsp;.pem&nbsp; &nbsp; &nbsp;.pfx&nbsp; &nbsp; &nbsp;.pgp&nbsp; &nbsp; &nbsp;.php&nbsp; &nbsp; &nbsp;.pptx.ps&nbsp; &nbsp; &nbsp; .psd&nbsp; &nbsp; &nbsp;.py&nbsp; &nbsp; &nbsp; .rar&nbsp; &nbsp; &nbsp;.raw&nbsp; &nbsp; &nbsp;.rpm&nbsp; &nbsp; &nbsp;.rtf&nbsp; &nbsp; &nbsp;.sh&nbsp; &nbsp; &nbsp; .sql.sqlite&nbsp; .svg&nbsp; &nbsp; &nbsp;.svn&nbsp; &nbsp; &nbsp;.tar&nbsp; &nbsp; &nbsp;.tar.gz&nbsp; .tex&nbsp; &nbsp; &nbsp;.tgz&nbsp; &nbsp; &nbsp;.tiff&nbsp; &nbsp; .ts.tsx&nbsp; &nbsp; &nbsp;.txt&nbsp; &nbsp; &nbsp;.vcs&nbsp; &nbsp; &nbsp;.vhd&nbsp; &nbsp; &nbsp;.vmdk&nbsp; &nbsp; .war&nbsp; &nbsp; &nbsp;.wav&nbsp; &nbsp; &nbsp;.webm&nbsp; &nbsp; .wma.xlsx&nbsp; &nbsp; .xml&nbsp; &nbsp; &nbsp;.xps&nbsp; &nbsp; &nbsp;.xz&nbsp; &nbsp; &nbsp; .yaml&nbsp; &nbsp; .zip&nbsp;</td></tr></tbody></table>

The following processes and services are killed before the ransomware starts the file encryption:<table class="table"><tbody><tr><td>&nbsp;chrome.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; firefox.exe&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; msedge.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; explorer.exeoutlook.exe&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; vlc.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; spotify.exe&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; skype.exediscord.exe&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; steam.exe&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; java.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; python.exenode.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cmd.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; powershell.exe&nbsp; &nbsp; &nbsp; taskmgr.exewmplayer.exe&nbsp; &nbsp; &nbsp; &nbsp; tscon.exe&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; notepad.exe&nbsp;</td></tr><tr><td>spooler&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;bits&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; dnsclient&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; lanmanworkstationwinmgmt&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;netsh&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;iphlpsvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;servicesRemoteAccess&nbsp; &nbsp; &nbsp; &nbsp; ShellHWDetection&nbsp; &nbsp; SCardSvr&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;TrkWkswscsvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; CryptSvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; msiserver&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; MpsSvcdefragsvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;upnphost&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; WindowsUpdate&nbsp; &nbsp; &nbsp; &nbsp; srservicewsmprovhost&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;AppIDSvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; AudioEndpointBuilder Scheduleeventlog&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PlugPlay&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Netman&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;bthservShellExperienceHost SMB&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;WinDefend&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; wuauserv&nbsp;</td></tr></tbody></table>

<h2>How to Use the Ransomware Decryptor</h2><ol><li>The first step is to download the decryptor binary. Avast provides a <a href="https://files.avast.com/files/decryptor/avast_decryptor_funksec64.exe">64-bit decryptor</a>, as the ransomware is also 64-bit and can’t run on 32-bit Windows. If you have no choice but to use 32-bit applications, you may download a 32-bit decryptor <a href="https://files.avast.com/files/decryptor/avast_decryptor_funksec.exe">here</a>.</li><li>Run the executable file, preferably as administrator. It starts as a wizard, leading you through the decryption process.</li><li>On the initial page, we have a link to the license information. Click the Next button when you are ready to start. &nbsp;</li></ol>

4. On the next page, select the list of locations you want to be searched for and decrypted. By default, it has a list of all local drives, but you can pick a different list, such as a directory with important documents:

5. On the final page, you can opt-in to back up your encrypted files. These backups may help if anything goes wrong during the decryption process. This choice is selected by default, which we recommend. After clicking Decrypt, the decryption process begins. Let the decryptor work and wait until it finishes decrypting all your files.

For questions or comments about the Avast decryptor, email <a href="mailto:decryptors@avast.com">decryptors@avast.com</a>.<h2>IOCs</h2>Ransomware samplec233aec7917cf34294c19dd60ff79a6e0fac5ed6f0cb57af98013c08201a7a1c &nbsp;Initial source code7e223a685d5324491bcacf3127869f9f3ec5d5100c5e7cb5af45a227e6ab4603&nbsp;