Unchecked AI in the workplace quickly becomes a massive loophole for data leaks and security breaches. All too often, employees drop sensitive company data into public chatbots, or install rogue AI assistants on their own — in the process handing over way too much access. In a previous post, we broke down the different types of risky AI systems, and later shared some tips on how to turn off the built-in AI features on major tech platforms. Today let’s take a look at practical ways to block or restrict the unauthorized “helpers” employees might be using — from ChatGPT and Grammarly, to meeting bots like Fireflies and Read AI.
How to detect and restrict ChatGPT
ChatGPT is the biggest culprit when it comes to unauthorized AI use worldwide. A quick word of warning, though: an outright ban only sends users hunting for sketchy third-party sites or messaging app chatbots that hook into the same service. That’s why it’s always a good idea to offer an approved alternative before pulling the plug.
Detecting it: keep an eye on the NGFW or web filter for traffic heading to chat.openai.com, chatgpt.com, oaistatic.com, oaiusercontent.com, or cdn.oaistatic.com. It’s also smart to use EDR/EPP tools to scan browser histories, installed apps, and browser extensions across corporate devices.
Locking it down: use the firewall or web filter to block the entire AI Services category, and set up DNS to reroute traffic away from those OpenAI domains. Browser policies can also be used to ban ChatGPT-powered extensions. Better yet, block all extensions not on a pre-approved allowlist. Finally, use application controls and EPP solutions to stop users from installing the official desktop app (ChatGPT.exe or com.openai.chat).
How to detect and restrict Claude and Claude Code
Detecting it: use the NGFW or web filter to track traffic going to claude.ai, anthropic.com, *.anthropic.com, and api.anthropic.com. EDR/EPP or application control tools can also be used to scan employee computers for the desktop app (claude.exe).
Locking it down: drop a blanket block on the AI Services category through the NGFW or web filter, and tweak DNS settings to reroute traffic away from the aforementioned Anthropic domains. Next, use browser policies to shut down Claude-powered extensions. Finally, use application controls and the EPP platform to prevent users from installing the desktop app.
How to detect and restrict Perplexity AI
Detecting it: keep tabs on the NGFW or web filter to flag any traffic heading to *.perplexity.ai or pplx.ai.
Locking it down: just like the others, add the AI Services category to the NGFW or web filter blocklist, and use DNS routing to redirect traffic away from those domains.
Configure the browser to block third-party extensions from being installed. If Firefox is used in the organization, be aware that recent versions come with Perplexity built in. Luckily, these AI features can be turned-off company-wide using enterprise policies — specifically, by setting SidebarChatbot = blocked. The full list of tweaks can be found in the Firefox documentation.
How to detect and restrict DeepSeek
Detecting it: keep an eye on the NGFW or web filter for traffic hitting deepseek.com, chat.deepseek.com, api.deepseek.com, or platform.deepseek.com. For better precision, analyze the SNI (server name identification) in TLS connection requests. For mobile devices, look out for the official app (com.deepseek.chat).
Locking it down: blocklist the AI Services category on the NGFW or web filter, and reroute traffic to DeepSeek’s domains via DNS settings. Use browser policies to block third-party extensions, and lean on MDM/EMM tools to restrict the mobile app.
How to detect and restrict Mistral, xAI Grok, and Character.ai
The playbook for these tools is exactly the same as DeepSeek, so here’s the quick list of domains to watch for and block: chat.mistral.ai, mistral.ai, console.mistral.ai, grok.com, x.ai, api.x.ai, character.ai, beta.character.ai, and c.ai.
A quick word of warning on Grok: because Grok is baked into X, blocking this specific AI access point means blocking the entire social media platform.
How to detect and restrict Slack AI
Detecting it: in the Slack workspace admin dashboard, look under Analytics → Slack AI usage. If an enterprise plan is used, the detailed Slack logs can be searched for any events starting with the ai_ prefix.
Blocking it with policies: in the organization’s Slack settings, click through the Workspace settings → Roles & permissions → Feature access, and change the permission to “no one”. Slack has a step-by-step guide in their help center.
Locking it down: shutting this down at the network level is tricky; it can be pulled off with a finely tuned CASB solution in place. Also, don’t forget the importance of blocking rogue integrations and keeping external AI services from tapping into Slack data in the first place. We covered how to lock this down using OAuth controls in a previous post.
How to detect and restrict Zoom AI Companion
Detecting it: if a corporate Zoom subscription is in use, just head to Admin Center → Reports → AI Companion usage. Detecting Zoom’s AI when employees join external meetings or use free accounts is a lot tougher, but email filters can be set up to flag incoming AI-generated meeting notes by scanning for subject lines or text containing “Meeting summary” or “Meeting assets”.
Blocking it with policies: for the company’s own Zoom subscription, go to the Admin Portal → Account Management → Account Settings → Meeting → AI Companion and toggle it OFF for everyone.
Locking it down: unfortunately, AI Companion is baked into Zoom’s DNA, so the only real option is blocking Zoom altogether.
How to detect and restrict Grammarly
What looks like an innocent spellchecker is actually one of the biggest culprits for workplace data leaks.
Detecting it: check the NGFW or web filter logs for traffic hitting grammarly.com, *.grammarly.com, and gnar.grammarly.com. EDR and MDM/EMM tools can also be used to hunt down the standalone desktop apps (Grammarly Desktop.exe and the macOS version), as well as the Grammarly browser extension.
Locking it down: use firewalls to block those domains at the network level, and EPP to stop employees from installing the desktop app, browser extensions, or the Grammarly add-ins for Microsoft Word and Excel.
How to detect and restrict meeting assistants: Fireflies, Read.ai, Tactiq, Fathom, and Granola
This massive category of third-party SaaS tools records and analyzes meetings — creating a massive risk for data leaks. The trickiest part? Outside clients or vendors can bring these bots into a meeting just as easily as employees can.
Detecting them: run an audit on calendar invites, and look for bot participants using email domains like @fireflies.ai, @read.ai, @tactiq.io, @fathom.video, or @granola.ai. Zoom, Teams, or Google Meet logs can also be used to review external participants who joined past calls.
Locking them down: since it’s impossible to control what outsiders do, blocking these bots comes down to tightening meeting rules. The best moves are: blocking users from granting OAuth permissions for bots to join calls, restricting employees from inviting unapproved external participants, or locking down meeting recording access for external users. That last option is usually the least painful way to keep bots out without disrupting business.
How to detect and restrict AI code editors: Cursor, Windsurf, and the like
Detecting them: use EDR/EPP tools to scan for executables like cursor.exe or windsurf.exe. It’s also worth monitoring network traffic heading to cursor.com and windsurf.com, as well as traffic hitting various AI model API providers. Keep in mind that there’s a pretty extensive list of API hosts to monitor here, since these editors aren’t tied to just one specific AI vendor.
Blocking them with policies: these apps can be prevented from being installed by setting up filters based on the developer’s digital signature certificate. Alternatively, a strict application allowlist can be employed where only pre-approved software is allowed to run.
Locking them down: rely on the EPP/EDR platform to actively detect and block these applications from running.
How to detect and restrict local AI tools: Ollama, LM Studio, and GPT4All
On one hand, this category carries fewer data leak risks because the AI models run completely locally on the user’s machine. On the other hand, it opens up a whole new can of worms: these apps themselves aren’t always highly secure, and can become targets for cyberattacks. Plus, it still means that employees can misuse models or process data in unauthorized ways.
Detecting them: EDR/EPP tools are the best line of defense here. They should be used to flag known local AI files and processes like ollama.exe, ollama serve, lmstudio.exe, LM Studio.app, jan.exe, or gpt4all.exe. From a network perspective, it’s worth scanning for open ports on local devices — typically port 1234 for Ollama and LM Studio, or port 8080 for WebUIs (using an additional fingerprint check of the server response). Another massive red flag is the presence of large files (often several gigabytes) containing language model weights. Look out for extensions like .gguf, .bin, or sometimes .safetensors.
Locking them down: use EPP/EDR platforms or windows AppLocker to block these applications by name, or switch to an application allowlist.
How to detect and restrict autonomous agents: OpenClaw, NemoClaw, and NanoClaw
This is easily one of the most dangerous categories of AI tools out there. These agents mix high-level independence with access to untrusted data, making them a massive security headache.
Detecting them: use EPP/EDR tools to sniff out active processes like openclaw, nanoclaw, nemoclaw, or clawdbot. Also keep an eye out for devices running Node.js that suddenly start launching Bash or Python scripts. Another dead giveaway is the appearance of system folders like ~/openclaw, ~/nanoclaw, ~/.claw*, or ~/clawhub. At the network level, monitor connections to the AI model APIs we mentioned earlier, as well as traffic hitting servers like openclaw.ai, nanoclaw.dev, or clawhub.*.
Locking them down: the safest bet is to use strict application allowlisting (only allowing approved software to run), or to specifically ban the known agent apps listed above. On top of that, consider blocking non-developers from installing Node.js and Docker, neither of which they need on their computers anyway.
In April 2026, we discovered a new campaign targeting users of hentai games. Attackers are embedding a remote access Trojan named Argamal into game installers. While concealing its presence, it can remotely control the computer and steal files and personal data.
Here’s how to avoid falling victim to this new Trojan — and how to safely and anonymously enjoy spicy content with (or without) anime girls.
How computers get infected with Argamal
Most of the infected games are distributed through adult game and torrent sites. In some cases, they are posted for download on file-sharing services and linked on gaming websites.
Example of a trojanized game hosted on the AniRena torrent tracker
Interestingly, instead of finding a dummy file inside the archive — as is often the case — the user gets the actual game built on popular engines like RenPy or RPG Maker. Infected pirated versions usually turn out to be scams: games fail to launch, folders are full of files with bizarre extensions, making it rather easy to put two and two together. Here, however, the user gets the actual gameplay they expected. Meanwhile, the Trojan lets itself in and keeps a completely low profile.
Example of a trojanized game hosted on the AniRena torrent tracker
Tucked right alongside the legitimate files in the archive is a DLL that the game relies on to run, but it’s been rigged: as soon as the user launches the game, the infected DLL automatically loads into memory. There are no outward signs of infection: neither an installer popping up in the background, nor a scary window or prompt asking you to disable your antivirus.
Argamal takes things real slow: instead of immediately rushing to steal files and passwords or throwing a digital rager on your computer, the Trojan first checks whether it’s running in a virtual machine or sandbox, and then goes into standby mode.
During this time, the malware writes hidden parameters to the system, conceals the paths to its DLLs, and delays its own execution. Three days later, the computer connects to GitHub, downloads an encrypted file, decrypts it, and turns it into a working Trojan module.
To ensure persistence, the attackers register the malware under the WindowsColorSystem Calibration Loader system task, a built-in Windows feature that triggers at every user logon to load monitor color profiles. Before shutting down, the malware deletes temporary files and covers its tracks to make it even harder to detect.
What makes Argamal dangerous?
Argamal is a remote access Trojan (RAT), which means attackers can use it to remotely control the victim’s computer. Here’s just a short list of what it may entail:
Executing arbitrary commands on the computer
Downloading and running files
Checking if an antivirus is installed on the PC (by the way, our security solution detects and neutralizes Argamal before it can harm you)
Searching for and exfiltrating sensitive data from files and system settings
Taking screenshots and streaming video from the device
Sending data to the attackers’ server
Monitoring user activity
Shutting down or restarting the device
Essentially, the infected computer turns into a remotely controlled machine. The owner may keep calmly going about their day, completely unaware that their device has been compromised. Yet the consequences of such an infection can be devastating.
For example, a single password stolen from a text note can lead to multiple compromised accounts at once if the victim reuses the same credentials across different sites. That’s why we recommend storing strong and unique passwords in an encrypted vault of a password manager rather than in plain text files.
Beyond hijacking accounts, the Trojan lets attackers literally spy on the user — reading their chats, digging into secret files, studying their sexual preferences… The cybercriminals can then use this highly sensitive information for subsequent attacks, blackmail, and extortion. We’ve covered what to do if you find yourself being targeted by extortionists in a previous post.
Another common scenario involves quietly stealing or substituting financial data — for instance, intercepting credentials from banking apps or replacing crypto-wallet addresses in the clipboard, which sends all your money straight to the attackers’ accounts.
In short, there’s a whole laundry list of ways attackers can exploit a victim’s device and data.
Argamal, yamete kudasai! How to protect yourself from similar threats
If you’ve decided to become the proud owner of “Waifu Simulator Ultra Definitive Edition”, stay on your guard:
Use security software that runs in real time and catches sophisticated malware. Despite the attackers’ best efforts to make the Trojan invisible, Kaspersky Premium instantly detects and removes Argamal from users’ devices.
Avoid downloading adult apps, installation files, and spicy content from untrusted sources. Clicking a “free XXX game, no signup needed” is a surefire way to invite malware onto your device. That said, even official platforms like Google Play and the App Store unfortunately let infected apps slip through the cracks at times. To stop worrying about accidentally downloading a Trojan or an infostealer, use Kaspersky Premium on all your devices.
Don’t share more data than you absolutely have to. If an adult game or website insists you sign up, enter personal data, or link third-party accounts instead of just checking your birth date, that’s a huge red flag. Sites rarely collect sensitive data for no reason. In the best-case scenario, it ends up with marketers and ad trackers. In the worst-case, it falls into the hands of bad actors who will use it for blackmail, phishing, or breaking into your other accounts.
Don’t click ad banners on adult websites. Even the most popular platforms like Pornhub occasionally host ads laced with malware. If you find it hard to hold back, use a security solution that will block malware downloads and prevent redirects to suspicious sites.
Apple heeft macOS 27 Golden Gate aangekondigd. De nieuwe versie richt zich volgens Apple vooral op verbeteringen aan bestaande functies, zoals het kunnen terugschroeven van transparantie in het ontwerp en het oplossen van de hoeken van vensters.
WhatsApp has detected and stopped spear-phishing campaigns allegedly conducted by the NSO Group after investigating user reports of social engineering attacks. [...]
Apple zegt dat oudere iPhones sneller en zuiniger worden met iOS 27. De upgrade krijgt een nieuwe cpu-scheduler. Bovendien krijgen alle telefoons die iOS 26 draaien, vanaf de iPhone 11 uit 2019, een upgrade naar iOS 27.
Apple heeft een nieuwe versie van zijn assistent Siri en Apple Intelligence aangekondigd. De nieuwe versie heet Siri AI en kan onder meer begrijpen wat er op het scherm staat. Ook heeft Siri AI toegang tot persoonlijke gegevens. De assistent werkt voorlopig niet in Europa.
If you’re a user—owner?—of this cryptocurrency, this is important:
On May 29, the security researcher Taylor Hornby found a critical vulnerability in Zcash Orchard privacy pool using Claude Opus 4.8. The Zcash team hired Hornby specifically to look for this kind of issue. He found one fast enough to be embarrassing.
The Orchard pool is the newest and most advanced shielded transaction system in the cryptocurrency Zcash. Introduced in 2022, it allows users to send and receive ZEC while keeping transaction details private. It uses zero-knowledge proofs to validate transactions without revealing amounts or participants. The bug: a specific check that was supposed to validate transaction inputs wasn’t actually enforcing the rules it appeared to enforce. An attacker could have exploited the flaw to feed false inputs into that check and generate ZEC from nothing, with the zero-knowledge proof system blessing the fraudulent transaction as valid.
It’s fixed; that’s the good news. The bad news is that there’s no way of knowing if anyone exploited the vulnerability to steal money. And this fragility is the fundamental problem that makes blockchain such a bad idea.
De KPN-joint venture Glaspoort mag een deel van het glasvezelnetwerk van Delta Fiber niet overnemen, zo zegt de Nederlandse toezichthouder Autoriteit Consument en Markt. De overname zou de concurrentie op het gebied van glasvezel beperken.
Het aantal klachten over privacyschendingen dat de Nederlandse Autoriteit Persoonsgegevens kreeg, verdubbelde bijna in 2025. In een derde van de gevallen stuurde de autoriteit een berisping of brief naar de overtreder.
Samsung zou een deel van de Z Flip8-exemplaren voorzien van een Qualcomm-soc. Alle Z Flip7's hebben een Samsung Exynos-soc aan boord. In Europa en Zuid-Korea krijgt de Flip8 wel weer een Exynos-soc, volgens het gerucht.
Gogs has patched a critical security zero-day flaw that can allow attackers to compromise Internet-facing instances and access any repositories (including private ones). [...]
Enabling security tooling is the starting point. Making it operational—where findings drive decisions, response times are measurable, and your security posture improves week over week—is where most organizations struggle.
This blog post provides a phased maturity roadmap for organizations that have already enabled AWS Security Hub and Amazon GuardDuty. These two services form the foundation of a cloud-centered security operations capability on AWS. Security Hub provides centralized security posture management and aggregates findings from multiple AWS security services, while GuardDuty provides intelligent threat detection by continuously monitoring for malicious activity and unauthorized behavior. For any production or enterprise AWS environment, having both services enabled across all accounts and AWS Regions is a baseline expectation; not because they’re optional add-ons, but because effective security operations require both the ability to detect threats and the ability to understand your overall security posture. If you haven’t yet enabled them, the Security Hub documentation and GuardDuty documentation provide setup guidance, including multi-account deployment with AWS Organizations.
Customers consistently tell us that while individual AWS security service documentation is thorough, what’s missing is a consolidated operational playbook—one resource that ties the services together into a working security operations practice with clear phases, progression criteria, and an operational cadence. That’s the gap this post fills. Rather than covering how each feature works (the documentation does that well), this post focuses on when and why to use each capability, and how to build the organizational habits that make them effective.
What follows is a six-phase roadmap for moving from these services are active to these services are driving our security operations. Each phase builds on the previous one, and each is designed to deliver tangible, measurable improvement.
Phase 0: Assess your current state
Goal: Understand what’s working before changing anything.
Estimated timeline: 1–2 weeks
Move to Phase 1 when: You have a documented current-state assessment covering all the following items.
Before introducing new processes or automation, establish a clear picture of the current environment. This assessment informs every decision that follows.
Actions:
Findings inventory: Review existing active GuardDuty findings to determine how many there are, the severity distribution, and how old the oldest findings are. A large backlog of untouched HIGH or CRITICAL findings that have been sitting for weeks is a strong signal about where to focus first.
Security Hub score baseline: Determine your current compliance score against AWS Foundational Security Best Practices (FSBP) and The CIS AWS Foundations Benchmark. Check to see which standards are enabled; if multiple standards are enabled, review for overlapping standards (creating noise) or unused standards.
Multi-account and multi-Region check: Look to see if GuardDuty is enabled in every account and every Region, or only in Regions with active workloads. Threat actors frequently operate in Regions that organizations don’t actively monitor. Also check to see if Security Hub aggregation is configured with a delegated administrator account or if each account is being managed independently.
Integration check: Determine if GuardDuty findings are flowing into Security Hub and if Amazon Inspector and Amazon Macie are enabled and feeding findings in. Without integration, Security Hub might be only surfacing its own compliance checks.
Notification check: See if there’s an Amazon EventBridge rule configured for notifications and if so, how findings are being routed and to whom. Know if notifications are being sent using an Amazon Simple Notification Service (Amazon SNS) topic or a chat channel integration. Without a clear notification and response workflow, findings can accumulate silently in the console with no one looking at them.
Deliverable: A one-page current state assessment that identifies what’s enabled, what’s flowing where, who’s looking at it, and what’s in the existing backlog.
Phase 1: Reduce the noise
Goal: Make the signal meaningful before asking anyone to act on it.
Estimated timeline: 2–3 weeks
Move to Phase 2 when: Remaining findings represent items requiring real decisions, compliance scores reflect actual posture, and you can articulate why every suppression rule and disabled control exists.
This is the single most important phase. If this step is skipped in favor of jumping straight to automation, the result is automated chaos. Alert fatigue is the primary reason security tooling is ignored, and addressing it first is what makes everything that follows sustainable.
GuardDuty tuning:
Create suppression rules for known-benign findings. The goal is to suppress activity you’ve already evaluated and accepted—such as expected traffic from corporate egress IPs (based on trusted IP lists), internal tools that trigger DNS-based findings, or internet-facing resources that naturally receive port scanning. The principle: if you’ve investigated a finding and it’s expected, suppress it so your team can focus on what matters.
Triage every active HIGH and CRITICAL finding into three categories: needs immediate investigation (real threat, not yet reviewed), true positive, already addressed (archive using workflow status), or false positive or expected behavior (create a suppression rule). Every finding must be categorized into one of these three states.
Review GuardDuty protection plans and enable any that are relevant but not yet active. Organizations that enabled GuardDuty years ago might not have activated protection plans released since then (such as Runtime Monitoring, Malware Protection, RDS Protection, and Lambda Protection). Evaluate each against your workload profile and enable what applies.
Security Hub tuning:
Disable controls that aren’t relevant to the environment. This is the highest-value quick win. If a service isn’t in use, disable its controls. If a control is addressed by an alternative solution, disable it. A 47% compliance score where half the failures are irrelevant trains teams to ignore the dashboard entirely. See the Security Hub controls reference for the full list.
Choose a primary standard. AWS Foundational Security Best Practices is a strong default. The CIS AWS Foundations Benchmark adds value when there’s a specific compliance mandate. Avoid enabling PCI DSS or NIST 800-53 standards unless there’s a reporting requirement—they add significant volume without proportional signal for most organizations.
Configure cross-Region aggregation to the delegated administrator account if not already in place. A single aggregated view eliminates the need to check findings across multiple Regional consoles.
Use the workflow status field operationally. Findings should progress from NEW to NOTIFIED to RESOLVED or SUPPRESSED. If everything remains in NEW indefinitely, the system carries no operational meaning.
Deliverable: A tuned environment where remaining findings represent items that require real decisions. Compliance scores should now reflect your organization’s actual security posture rather than noise.
Phase 2: Build the notification and routing layer
Goal: Get the right findings to the right people at the right time.
Estimated timeline: 2–3 weeks
Move to Phase 3 when: CRITICAL and HIGH findings reach the security team within minutes, MEDIUM findings create tracked tickets, and notifications include enriched context. No action is taken until a person or an automation is informed that something needs attention.
Architecture: Security Hub to EventBridge rule to routing logic to destination
Tiered notification strategy:
CRITICAL
Page on-call immediately
PagerDuty or Opsgenie
15 minutes
HIGH
Alert security team channel
Slack or Teams channel and ticket creation
4 hours
MEDIUM
Create ticket for review
Jira or ServiceNow
48 hours
LOW or INFORMATIONAL
Batch digest
Weekly email summary or dashboard review
Next review cycle
Key design decisions:
Route from Security Hub, not individual services. Because findings from GuardDuty, Inspector, Macie, and Security Hub compliance checks all aggregate in Security Hub, build your EventBridge rules there for centralized management.
Create a fast path for the most dangerous finding types. Certain GuardDuty findings, particularly those involving credential exfiltration, cryptocurrency activity, trojans, and active compromises, warrant a separate, faster routing path that bypasses normal triage. Identify these based on your threat model and the GuardDuty finding types reference.
Enrich notifications before delivery. A raw JSON finding in a chat channel provides little actionable context. Use an AWS Lambda function to format notifications with the information responders need: account alias, Region, Amazon Resource Name (ARN), finding type, severity, a console deep link, and a plain-language description. The Security Hub CloudWatch Events integration guide describes the event format.
Deliverable: A working notification pipeline where CRITICAL and HIGH findings reach the security team within minutes, MEDIUM findings create tracked work items, and LOW and INFORMATIONAL findings are batched for periodic review.
Phase 3: Build automated remediation for high-confidence findings
Goal: For findings where the correct response is deterministic, remove the human from the loop.
Estimated timeline: 3–4 weeks
Move to Phase 4 when: At least 3–5 high-confidence finding types have automated responses deployed with audit trails, and the team has established a process for evaluating new auto-remediation candidates.
The guiding principle: Only auto-remediate when all three conditions are met: the finding is high-confidence, the response is deterministic, and the blast radius of the automated action is limited. Automated remediation must not create the risk of a production outage.
Decision framework:
Confidence level
High – no false positive risk
Medium – context-dependent
Low – requires investigation
Response complexity
Single, well-defined action
Multiple steps or judgment calls
Requires forensic analysis
Blast radius
Limited to one resource
Could affect dependent services
Production-wide impact
Rollback difficulty
Straightforward to reverse
Moderate effort to reverse
Difficult or impossible to reverse
Common auto-remediation categories:
Instance isolation for confirmed compromise findings (cryptocurrency mining, malware, and trojans): Replace the security group, snapshot volumes for forensics, and notify.
Credential revocation for confirmed credential compromise: Attach deny-all policies, revoke sessions, and deactivate access keys as appropriate to the credential type.
Compliance drift correction for deterministic misconfigurations: Re-enable Amazon Simple Storage Service (Amazon S3) Block Public Access, revoke overly permissive security group rules, and re-enable AWS CloudTrail logging.
Notification-only escalation for findings that require human judgment before action: Amazon Elastic Block Store (Amazon EBS) encryption gaps (require migration) and access key rotation (requires coordination with the key owner).
For implementation, AWS provides Security Hub Automated Response and Remediation (SHARR), a solution that includes pre-built remediation playbooks deployed as AWS Step Functions workflows triggered by EventBridge. This is a strong starting point—evaluate the provided playbooks, enable the ones that fit, and extend with custom remediations as needed.
Note: For findings that recur because the environment lacks preventive guardrails, the best long-term response is often a service control policy (SCP) that prevents the misconfiguration from occurring in the first place. Phase 5 covers this preventive controls layer.
Deliverable: A library of automated and semi-automated remediation runbooks with full audit trails, and a documented decision framework the team uses to evaluate new auto-remediation candidates.
Phase 4: Build the operational rhythm
Goal: Turn security findings management into a sustained organizational practice, not a one-time cleanup.
Estimated timeline: 4–6 weeks to establish, then ongoing
Move to Phase 5 when: The weekly cadence has been running consistently for at least 8 weeks, monthly metrics show positive trends, and the first quarterly review has been completed.
This is where many organizations stall, and it’s the most important phase in the entire roadmap. The technology is working, the notifications are flowing, automated remediations are firing, but there’s no organizational habit built around it. Without this phase, everything you’ve built in Phases 0–3 will gradually decay. Suppression rules will go stale, new team members won’t know the system exists, and findings will start accumulating again. The operational rhythm is what converts a security tooling deployment into a security operations practice.
Weekly security review (30 minutes)
Attendees: Security team lead, cloud platform team representative, rotating engineering lead from an application team
Why the rotating engineering lead matters: Security findings don’t exist in a vacuum; they’re generated by workloads that engineering teams own. Rotating an engineering representative through this meeting accomplishes three things: it builds security awareness across the organization, ensures findings are routed to people with the context to resolve them, and creates organizational accountability beyond the security team.
Agenda template:
5 minutes
Compliance score trend – Review Security Hub scores by account and standard. Is the trend improving, declining, or flat? If declining, why?
Security lead
Identified regression areas
5 minutes
Critical and high findings review – Walk through new HIGH and CRITICAL GuardDuty findings from the past week. Are there any that need immediate escalation?
Security lead
Escalation actions assigned
10 minutes
Top five failing controls – Identify the five Security Hub controls with the most failures. Assign an owner and a target date for each.
Platform lead
Owners and dates documented
5 minutes
Automation review – Did any auto-remediations fire this week? Did they work correctly? Were there any false triggers?
Security lead
Automation adjustments queued
5 minutes
Tuning decisions – Are new suppression rules needed based on this week’s findings? Are any new finding types candidates for auto-remediation?
All
Tuning backlog updated
Running the meeting effectively:
Keep a running document (such as a wiki page or shared document) that captures decisions and action items week over week. This becomes your institutional memory.
If the compliance score hasn’t moved in over 3 weeks, that’s a signal. Either the assigned work isn’t happening, or the remaining findings are genuinely difficult to address. Both need to be discussed.
Track action items from previous weeks. A review that generates action items but never follows up on them will lose credibility and attendance quickly.
Escalation procedures
Define clear escalation paths before they’re needed:
CRITICAL finding not acknowledged within the SLA
Auto-escalate to security team manager
15 minutes after SLA breach
HIGH finding not resolved within the SLA
Escalate to finding owner’s manager
4 hours after SLA breach
Compliance score drops more than 5 points in a week
Escalate to cloud platform team lead for investigation
Next business day
Auto-remediation failure
Page security on-call
Immediate
New finding type not covered by existing runbooks
Add to weekly review agenda for triage and runbook development
Next weekly review
Monthly metrics report
Compile these metrics monthly and review them with security and engineering leadership. The goal is to tell a story about whether the organization’s security posture is improving, stable, or degrading, and why.
Mean time to acknowledge (MTTA) for CRITICAL findings
Are findings being seen promptly?
Decreasing month over month
Mean time to resolve (MTTR) for CRITICAL and HIGH findings
Are findings being acted on?
Decreasing month over month
Security Hub compliance score by standard, by account
What is the posture trend over time?
Increasing month over month
Number of active GuardDuty findings by severity
Is the backlog growing or shrinking?
Decreasing for HIGH and CRITICAL
Findings auto-remediated compared to manually resolved
Is automation delivering value?
Auto-remediation ratio increasing
Number of suppressed findings (with quarterly justification review)
Is noise being managed, or are problems being hidden?
Stable or decreasing
New findings introduced compared to resolved this month
Is the organization getting ahead or falling behind?
More finding resolved than introduced
SLA adherence rate by severity
Are response commitments being met?
More than 95% for CRITICAL, and more than 90% for HIGH
Building the dashboard: Use Amazon CloudWatch dashboards for real-time operational visibility or Amazon QuickSight connected to Security Hub findings through Amazon Security Lake for historical trend analysis and executive reporting. The dashboard should be visible to—and regularly viewed by—everyone in the weekly review, not locked in a security team tool.
Quarterly reviews
The quarterly review is a deeper inspection of the system itself; not just the findings, but the machinery processing them.
Quarterly review checklist:
Suppression rules audit: Review every active suppression rule to determine if the underlying condition is still present and the suppression is still justified. Document the review outcome for each rule.
Disabled controls audit: Review every disabled Security Hub control. Check that the justification is still valid and if the environment changed (for example, a service that wasn’t in use is now in use).
Automation audit: Review AWS Identity and Access Management (IAM) roles used by remediation functions and verify least privilege. Review execution logs for any anomalies or failures that weren’t caught.
New capabilities review: Evaluate newly released GuardDuty protection plans and Security Hub controls from that quarter. AWS releases new detection and compliance capabilities regularly. If you’re not reviewing them quarterly, you’re accumulating blind spots.
Process effectiveness review: Determine if the weekly meeting is well-attended and if action items are being completed. Make sure SLAs are being met. If attendance, action item completion, and SLA compliance aren’t where they should be, explore structural changes to address the gaps.
Operational maturity scoring
Use this rubric to assess the maturity of your operational rhythm itself. Score each dimension 1–3 and use the total to track progress over time.
Review cadence
One time reviews when someone remembers
Weekly review happens, but attendance is inconsistent
Weekly review is consistently attended with documented outcomes
Metrics tracking
No metrics captured
Metrics are collected monthly but not acted on
Metrics drive decisions and declining trends trigger specific actions
Finding ownership
Findings sit in queue with no owner
Findings are assigned to teams but SLAs aren’t tracked
Every finding has an owner, SLAs are tracked, and breaches are escalated
Automation management
Set-and-forget automations
Automation logs are reviewed periodically
Automation is reviewed weekly, and new candidates are evaluated continuously
Tuning lifecycle
Suppression rules created but never reviewed
Annual review of suppressions and disabled controls
Quarterly reviews with documented justification for every rule
Cross-team engagement
Security team works in isolation
Platform team participates
Engineering teams actively participate and own remediation
Scoring (revisit quarterly):
Beginning: 6–9
Established: 10–14
Optimized: 15–18
Deliverable: A documented operational cadence with clear ownership (consider a RACI matrix), metrics dashboards, escalation procedures, and a continuous improvement loop. The cadence should survive team member turnover—if it depends on one person remembering to run it, it’s not yet operational.
Phase 5: Mature the architecture
Goal: Fill remaining gaps and build toward a comprehensive security operations capability. Estimated timeline: Ongoing. Prioritize based on organizational risk profile and compliance requirements.
Amazon Inspector integration: Enable Amazon Inspector for Amazon Elastic Compute Cloud (Amazon EC2) instances, Lambda functions, and Amazon Elastic Container Registry (Amazon ECR) container images. Findings flow into Security Hub automatically, adding vulnerability management alongside threat detection and posture management. Prioritize this if you have Amazon EC2 or container workloads without an existing vulnerability scanning solution.
Amazon Macie: Enable Amazon Macie for S3 buckets containing potentially sensitive data. Particularly important for organizations with compliance requirements around personally identifiable information (PII), protected health information (PHI), or Payment Card Industry (PCI) data. Configure automated sensitive data discovery and route findings to Security Hub.
Amazon Security Lake: Amazon Security Lake centralizes security-relevant logs in OCSF format for long-term retention, forensic investigation, and threat hunting. This is valuable when you need historical analysis beyond the Security Hub retention window, or when feeding a third-party Security Information and Event Management (SIEM) tool.
Preventive controls layer: Convert recurring detective findings into preventive policies. Use SCPs to prevent disabling GuardDuty, Security Hub, and CloudTrail, IAM permission boundaries on developer roles, AWS WAF on public endpoints, and AWS Network Firewall for VPC traffic inspection. The pattern is to make recurring misconfigurations impossible to introduce.
Incident response readiness: Have incident response playbooks referencing specific GuardDuty finding types, pre-built forensics infrastructure (isolated VPC, forensic AMIs, and pre-configured IAM roles), regular tabletop exercises, and AWS CloudFormation templates to deploy isolation infrastructure on demand. See the AWS Security Incident Response Guide for a comprehensive framework.
Conclusion
In this post, I provided a six-phase roadmap for operationalizing Security Hub and GuardDuty and showed that it isn’t a single project, but a progression. Phase 0 and Phase 1 can typically be completed in 3–5 weeks and deliver immediate clarity. Phases 2 and 3 build the response infrastructure that turns findings into action over the following 5–7 weeks. Phase 4 is what makes everything sustainable and is where you should invest the most attention. And Phase 5 expands the aperture from Security Hub and GuardDuty into a comprehensive security operations capability.
If you walked away from this post and did one thing, run the Phase 0 assessment this week. That single deliverable tells you exactly where to focus next. Use the following self-assessment checklist to identify your current phase, then focus on the next one. A tuned environment with working notifications and a weekly review cadence is dramatically more effective than a fully featured but neglected deployment. Start where you are, reduce the noise, build the habits, and iterate. To learn more, explore the AWS Security Hub User Guide, the Amazon GuardDuty User Guide, and the AWS Security Incident Response Guide. If you’ve implemented a similar operational cadence, or have questions about any phase, share your experience in the comments.
Self-assessment checklist
Phase 0
We know how many active GuardDuty findings exist across all accounts
☐
We know our current Security Hub compliance score
☐
We know whether GuardDuty is enabled in every account and region
☐
We know who (if anyone) is reviewing findings today
☐
Phase 1
GuardDuty suppression rules exist for known-benign activity
☐
Irrelevant Security Hub controls have been disabled with documented justification
☐
All active HIGH and CRITICAL findings have been triaged
☐
Security Hub compliance scores reflect actual posture, not noise
☐
Phase 2
HIGH and CRITICAL findings generate real-time notifications to the security team
☐
MEDIUM findings automatically create tracked work items
☐
Notifications include enriched context (account alias, resource ARN, and console link)
☐
Phase 3
At least three high-confidence finding types trigger automated remediation
☐
Auto-remediation actions have full audit trails
☐
Remediation runbooks are documented and version-controlled
☐
Phase 4
A weekly security review meeting occurs with defined attendees and agenda
☐
MTTA and MTTR are tracked monthly for CRITICAL and HIGH findings
☐
Suppression rules and disabled controls are reviewed quarterly
☐
Security metrics trend positively over the past 3 months
☐
Phase 5
Amazon Inspector, Macie, or Security Lake are integrated
As threat actors operationalize AI to accelerate attacks, they are also leveraging the wider global interest around AI itself as a social engineering lure. In recent months, Microsoft Threat Intelligence has observed a growing number of campaigns that impersonate the branding of popular AI platforms such as ChatGPT, Microsoft Copilot, DeepSeek, and Anthropic’s Claude as lures. These campaigns, which don’t represent compromise of services, span phishing, malvertising, and search engine optimization (SEO)-driven attacks that ultimately lead to credential theft, financial fraud, or malware infection.
Threat actors are quick to capitalize on highly anticipated launches or emerging trends, leveraging trusted branding and exploiting user curiosity to improve the success rates of their campaigns. Despite the AI-themed lures, however, these campaigns combine longstanding tactics, such as urgency-driven messaging, abuse of trusted services, and multi-stage redirection chains that require user interaction to evade detection.
While traditional lures like invoices, payment notifications, or delivery alerts remain effective and continue to be widely used, AI-themed lures reflect a shift in social engineering that is likely to persist as a long-term tactic used by threat actors, from cybercriminal groups to nation states. Notably, Microsoft Threat Intelligence has observed the initial access broker Storm-3075 employing AI-themed malvertising to deliver payloads, including malware signed by the malware-signing-as-a-service (MSaaS) offering attributed to the financially motivated threat actor Fox Tempest, on behalf of multiple downstream actors.
This blog details several of the campaigns observed by Microsoft Threat Intelligence in the past few months that used AI brands and references as lures, and provides guidance to help users and organizations detect, mitigate, and respond to these threats. Importantly, Microsoft believes that the activity noted in this blog is purely abuse of AI brand names as lures, not reflecting a compromise of any referenced vendor. As threat actors scale their operations with AI, organizations should leverage AI-powered security capabilities to enhance visibility, automate detection, and accelerate response across email, identity, and endpoint surfaces.
ChatGPT-themed lure leads to phishing kit collecting credit card data
On May 5, 2026, Microsoft detected a ChatGPT-themed phishing attack that delivered malicious URLs leading to phishing pages that collected credit card and personal information such as names and addresses. This phishing activity, which consisted of 4,500 emails sent to targets in South Africa (97%), was part of a broader campaign using similar themes and infrastructure. We also observed this campaign delivering as much as 100,000 emails on a single day to targets in Switzerland, Austria, and South Africa affecting a broad range of industries, including higher education and professional services.
The emails used the sender display name ChatGPT and the subject “To ensure your ChatGPT Plus continues to work – please update your payment method”. The emails posed as an urgent request to update the ChatGPT Plus subscription payment method. They warned the recipient that if a new payment method was not provided within seven days, the account would be downgraded to a free plan. A ChatGPT logo was prominently displayed at the top of the email body.
Figure 1. Attack chain of ChatGPT-themed lure leading to phishing kit
The phishing email contained a clickable Update payment method button, which did not directly send users to the attacker-controlled site. Instead, users were redirected through a series of legitimate and abused redirector hops. This is a common technique used by threat actors to exploit the reputation of trusted domains and bypass email filters, evade detection, and track victim engagement.
Figure 2. Snippet of the top portion of the email impersonating ChatGPT and enticing users to click on the link
Targets were first directed to grupoconstat[.]bitrix24[.]com[.]br (a legitimate customer relationship management (CRM) service), which redirected to awstrack[.]me (an Amazon domain used for tracking email opens and clicks), which in turn redirected to a Rebrandly URL (a legitimate but often abused URL shortener service). Targets were finally sent to a likely legitimate but compromised domain legendarytrendsbay[.]shop where the threat actor had placed the phishing page in the /ChatGPT/ folder.
The landing page did not immediately display the phishing content. It first required visitors to pass a custom CAPTCHA, which was a simple Update payment button. If they clicked this button, users were sent to the next page where personal information, including first name, last name, and address was collected. The final page then collected the name, credit card number, expiration date, and card verification code.
Figure 3. Phishing landing page collecting name and addressFigure 4. Phishing landing page collecting credit card information
Claude-themed phishing campaign collected credentials and access tokens
From April 20 to 22, 2026, Microsoft observed a phishing campaign impersonating Anthropic-branded services to target users with account-related lures tied to the Claude AI platform. The campaign sent phishing emails to targets across more than 2,000 organizations, primarily in the United States (62%), the United Kingdom (18%), and India (9%). While this campaign impacted a broad range of industries, it was most notably focused on information technology (56%), other business entities (21%), and financial services (8%).
The campaign used enforcement-themed messaging claiming that the recipient’s account was in violation of acceptable use policies and required immediate action. The emails impersonated Anthropic’s popular AI service Claude using the display names Anthropic Teams and Anthropic PBC, masquerading as legitimate account-related communications. Subject lines followed a consistent structure of “Claude Appeal Request” combined with date elements.
Figure 5. Attack chain of Claude-themed phishing campaign leading to AiTM
The email body was delivered as HTML and included Anthropic and Claude branding. The message informed recipients that their account was violating “AUP (Account Usage Policy)” and that Anthropic had “initiated an appeal procedure”. The message instructed recipients to review the attached material to access their appeal and indicated that Claude features would be limited pending review.
Figure 6. Email impersonating Anthropic’s Claude, prompting users to open the attachment
The email attachment was a PDF named Fill and Sign Claude Appeal Form.pdf, which was designed to resemble an official process tied to Claude account enforcement. The document presented an appeal workflow, prompting users to copy an appeal ID and click the “Claude Appeal” link, which initiated the credential harvesting process.
Figure 7. PDF attachment providing instructions on how recipients can appeal the supposed Account Usage Policy (AUP) violation
When clicked, the link embedded in the PDF directed users to an attacker-controlled domain, dash.awaydouble[.]org. The initial landing page displayed a Cloudflare verification prompt, presented as confirming the user was arriving from a “legitimate session”. This step likely served as a gating mechanism to impede automated analysis and sandbox detonation.
Figure 8. CAPTCHA-gated landing page with Claude branding
Users who completed the verification were redirected to another Claude-themed landing page hosted on servicing.pureplantcravings[.]com. This page was named “Account Appeal Notice” and contained “Account Security & Compliance” message informing users that their account had been flagged for repeated violations of usage policies. The page provided a reference date and a one-time access code, prompting users to copy the code and continue.
Figure 9. Intermediate landing page displaying the Claude logo, referencing the usage policy violation and providing an access code
Clicking “Continue” redirected users to the final page, which was not available at the time of analysis. Source code revealed conditional redirect logic that routed users to one of two final landing pages, depending on whether the site was accessed through mobile device or a desktop system.
Figure 10. Redirect logic identified in landing page source code, differentiating between mobile device and desktop systems
While the final redirect destination was no longer active at the time of analysis, infrastructure overlap, including shared intermediate domains and consistent redirect logic, strongly suggested that users were ultimately presented with a Microsoft sign-in experience. This final stage is consistent with adversary-in-the-middle (AiTM) tactics designed to intercept authentication tokens and facilitate account compromise.
“Awesome AI Windows Plugin” malvertising deploys Vidar stealer
Since at least early 2026, Microsoft Threat Intelligence has observed malvertising campaigns that use AI-themed terms such as “Awesome AI Windows Plugin” and “Flux Pro AI” in social engineering lures in malicious popups, in malware executable names, and GitHub repository and folder names throughout the attack chain. These campaigns are notable for their scale and velocity, moving from launch to mass impact within hours and infecting tens to hundreds of thousands of endpoints. The malware delivered in these campaigns is frequently code-signed, lending an additional layer of perceived trust to both the operating system and the user.
Microsoft attributes this malvertising activity to an initial access broker and malware distributor tracked as Storm-3075. We assess that Storm-3075 delivers final payloads on behalf of multiple downstream actors. While the example campaign described in this section delivered Vidar Stealer, we have also observed this campaign distributing Lumma Stealer, Hijack Loader, and Oyster.
Figure 11. Attack chain for “Awesome AI Windows plugin” malvertising leading to Vidar
On March 13, 2026, a single campaign run targeted over 66,000 devices. Microsoft has revoked the related signing certificate and GitHub has taken down the associated repository, helping to prevent tens of thousands of additional infections. Given the nature of the attack source, majority of impacted devices were likely consumer rather than enterprise endpoints. Telemetry showed global distribution, with the top affected countries being Japan, South Africa, the United States, and France.
Analysis of the redirection chain determined that the attack likely originated from free movie streaming sites. Infections on such sites typically begin when users interact with embedded movie players or click popups. Malvertising embedded in such sites can redirect users to a range of unwanted content, including malware. In this campaign, users were redirected to a page advertising a download for an “Awesome AI Windows plugin”, a fictitious product name. The plugin purported to help users watch free, high-quality videos, a lure aligned with the context of users already streaming free or pirated content.
Figure 12. Screenshot of malvertising redirecting users to a purported download for an “Awesome AI Windows plugin”
Clicking the download button retrieved an executable named ProFluxeFlowAi-win-Setup.exe, which the user then had to manually launch. The file name mimicked a legitimate product with a similar name, Flux Pro AI, which supports text, image, and video creation. This lure reinforced the perceived legitimacy of the executable within the streaming of free movies context. The executable itself was hosted on GitHub in a repository named shippingtechnologymovie under a folder named AI-techVideos, both tailored to the AI video helper narrative.
Figure 13. Malware hosted on a GitHub repository “shippingtechnologymovie”, in a folder “AI-techVideos”
The malware executable was signed with a fraudulently obtained Microsoft-issued code-signing certificate obtained through Artifact Signing (certificate thumbprint: 4f5c5b3ef45cfff7721754487a86aeff9a2e6e32). Microsoft attributes the signing service used by the threat actor to Fox Tempest, a financially motivated threat actor operating a malware-signing-as-a-service (MSaaS) offering used by other threat actors. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest. In May 2026, Microsoft’s Digital Crimes Unit (DCU), in partnership with Resecurity, facilitated a disruption of Fox Tempest infrastructure and access model.
Signing malware through such a service is expensive; however, for a threat actor targeting tens or hundreds of thousands of infections, the cost can be justified by the additional level of trust signed binaries imply to both the operating system and the user. Signed malware also tends to exhibit lower detection rates early in the infection lifecycle, extending the window of effective distribution.
Another notable feature of the malware is that, immediately after launch, it displays a window with a “Continue” checkmark and does not proceed until the box is clicked. This extra user interaction step is uncommon. We assess that this technique is intended to hide the malicious functionality from sandboxes and automated analysis environments that cannot dynamically perform the click. Until the user clicks “Continue,” the malware performs no suspicious activity on the operating system. This technique is functionally analogous to the CAPTCHAs frequently seen in phishing attacks.
Figure 14. CAPTCHA-like “Continue” check mark displayed to the users if they launch the malware, requiring them to click before the malware continues executing.
Once the user clicks “Continue”, the executable drops and runs a malicious Python-based downloader. Both the Python interpreter and the downloader script are saved in the \AppData\Local\ folder as pythonw.exe and LICENSE.txt, respectively. The malicious script runs shellcode that loads the next-stage malware from the command-and-control (C2) domain brokeapt[.]com. The final payload observed in this campaign was Vidar infostealer.
Fake DeepSeek V4 installers on GitHub delivered Vidar Stealer
In April 2026, Microsoft identified a social engineering campaignsocial-engineering campaign that leveraged interest in the newly released DeepSeek V4 by impersonating it through a fraudulent GitHub repository and organization. The campaign abused GitHub’s release-asset infrastructure to deliver information-stealing malware such as Vidar stealer. Search engines increased the exposure of the malicious repository, exacerbated by the fact that DeepSeek did not publish an official V4 repository on GitHub.
Our investigation shows the DeepSeek lure is one identity in a broader rotating brand-abuse ecosystem that recycles whichever AI tool is trending into a fresh malware download experience. After discovering this activity, Microsoft shared the details with GitHub, and GitHub has since taken down the malicious organization, repository, and operator account.
Figure 15. Fake DeepSeek V4 campaign timeline and attack chain
On April 24, 2026, within hours of DeepSeek officially previewing its new V4 frontier model, a threat actor initiated the attack chain that can be summarized as:
Resource development on GitHub, all within roughly 45 minutes: A new GitHub organization (DeepSeek-V4), a single repository (deepseek-V4), and a release tag (deepseek-V4). The repository was decorated with stolen DeepSeek branding, real benchmark data, and SEO-optimized topics.
Search-driven discovery: Users found the repository through GitHub repository search, search engines, social sharing, and AI-assisted search results pointing to the lure page. The repository’s llms.txt and topic taxonomy were designed to be discovered by both classical search engines and large-language-model-powered search; observed top-rank results on search engines are consistent with that design, though we did not observe paid advertising and therefore do not assess this as malvertising.
Archive download from GitHub’s release-asset CDN: The release page hosted two archives, deepseek-v4-pro_x64.7z and deepseek-v4-flash_x64.7z.
User extraction: Users needed to extract the executable from the archive using common Windows archive tools.
Payload execution: The archives contained a heavyweight Win32 PE that masqueraded as the DeepSeek installer. At least one confirmed victim endpoint revealed the extracted payload landed at: C:\Users\<user>\Downloads\Programs\IA DeepSeek-V4\deepseek-v4-flash_x64.exe.
Active payload rotation: The threat actor actively rotated archive content while preserving file names and the release page. We observed at least three distinct archive hash generations in three days.
Microsoft Defender telemetry observed the first victim download approximately four hours later. The threat actor’s operational tempo on April 24, 2026, is consistent with a prepared, rehearsed workflow. The repository was designed to be convincing at a glance. It accumulated 91 stars and 27 forks within four days, though the proportion of organic versus inflated engagement is not independently confirmed. The attacker invested in several credibility-building elements:
Stolen branding: The repository’s README and assets folder embedded the legitimate DeepSeek whale logo, copied from the real deepseek-ai/DeepSeek-V2 repository.
Real benchmark data as lure: The release notes displayed authentic DeepSeek V4 benchmark scores against Claude Opus 4.6, GPT-5.4, and Gemini 3.1 Pro, copied from the official release announcement.
Action-oriented SEO topics: The repository was tagged with deepseek-v4, deepseek-v4-download, deepseek-v4-downloader, deepseek-v4-install, and deepseek-v4-installer, which are queries users are expected to use when intent-shopping for an installer.
LLM-aware discoverability: A top-level llms.txt file repeated the same SEO copy in a format aimed at AI-assisted search engines.
On closer inspection, the staging gives the operation away: the repository contained only a README, LICENSE, llms.txt, and stub assets/ and inference/ directories with no real model code; all nine commits were made in a single burst on April 24, 2026 by a single author; the README claimed an MIT license while repository metadata specified Apache 2.0.
Figure 16. The malicious DeepSeek-V4/deepseek-V4 repository contains stolen DeepSeek logo, SEO tags targeting install and download queries, sole-contributor “graphrtest” burner account, and 91 stars accumulated in four days.Figure 17. The fake release page had real DeepSeek V4 benchmark chart used as a credibility lure, two 102 MB .7z archives, hashes rotated three times in three days.
Once the lure was live, search engines increased the exposure of the malicious repository. We tested the queries an interested user would naturally try when looking for DeepSeek V4 on GitHub or the open web. In a snapshot captured on April 28, 2026, the results were as follows (search results are volatile and may differ at the time of reading):
Platform
Query
Result
GitHub
DeepSeek-V4 installer
1 result — the malicious repository (only result on GitHub)
GitHub
DeepSeek V4 install
1 result — the malicious repository (only result on GitHub)
GitHub
DeepSeek V4
The malicious repository ranked #2 of 169 results
Bing
Deepseek v4 weights github
The malicious repository ranked #1, above the official Hugging Face page
Google
DeepSeek v4 weights github
The malicious repository and two of its forks occupied three of the top four positions, including a top result with rich sitelinks
The 7z archives hosted on GitHub contained a loader executable such as SHA-256: 5455341ed1bbe75a664fca2dd0794c508e1874f75360253a7ff5bc119bc92d80. The loader was observed downloading and installing Vidar stealer and potentially additional malware.
Lastly, Microsoft observed that the DeepSeek-themed payloads share infrastructure with a much larger rotating fake-AI / fake-tool ecosystem. The same shared loader hash (SHA-256 5455341…) appeared under file names impersonating GPT-5.5, Claude Code, Kimi, Seedance, Gemma, GrokCLI, Manus AI, FraudGPT, and others (see table below). Public research from Trend Micro, Zscaler ThreatLabz, and Huntress describe the same broader ecosystem, with TradeAI.exe, OpenClaw_x64.7z, WormGPT_x64.7z, and DeepSeekAI_agent_x64.7z appearing as sibling lures and the downstream payload set documented as Vidar plus GhostSocks.
Lure name
Fake GitHub organization (observed or sibling pattern)
To defend against social engineering campaigns that leverage AI brands as lures, Microsoft recommends the following mitigation measures:
Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
Enforce multifactor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices in all locations at all times.
Enable Zero-hour auto purge (ZAP) in Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
Configure Microsoft Defender for Office 365 Safe Links to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow and time-of-click verification of URLs and links in email messages, other Microsoft Office applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers like Microsoft Edge that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
Microsoft Defender detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
Phishing emails
Microsoft Defender for Office 365 – A potentially malicious URL click was detected – Email messages containing malicious URL removed after delivery – Email messages removed after delivery – A user clicked through to a potentially malicious URL – Suspicious email sending patterns detected Email reported by user as malware or phish
Persistence
Threat actors distribute malware Threat actors sign in with stolen valid entities
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Attackers can chain three already fixed vulnerabilities in the Ubiquiti UniFi OS server to execute remote code with root privileges and without authentication. [...]
Microsoft heeft een functie uitgesteld waarmee gebruikers de camera en microfoon kunnen testen voordat ze een vergadering binnenkomen. Die had er eigenlijk al moeten zijn, maar de release vindt nu plaats van eind juni tot half juli.
Nintendo heeft een boete van 35 miljoen euro gekregen van de Franse consumententoezichthouder. Het bedrijf zou klanten te laat hebben geïnformeerd over problemen met de Joy-Con-controllers van de Nintendo Switch. Vooral de controllersticks vertonen snel kuren.
By Saher Naumaan, Carlos Rubio, and the Proofpoint Threat Research Team
Key Findings
Between April and May 2026, Proofpoint Threat Research observed a likely North Korean threat actor conducting phishing campaigns using developer role recruitment or code review themes to targets in close to 100 organizations in finance, cryptocurrency, education, technology, and several other sectors. Proofpoint clusters this activity under the name UNK_DeadDrop.
The infection chain begins with emails containing links to actor-controlled GitHub repositories hosting malicious scripts that result in the execution of cross-platform malware for macOS, Linux, and Windows, including an open-source Go framework named Overlord.
The campaigns abused Visual Studio Code workflows and deployed a stealthy new technique using malicious Visual Studio Extensions (VSIX) that requires minimal user interaction.
The activity has similarities to another North Korean group called Contagious Interview; however, there is no direct overlap in Proofpoint telemetry so Proofpoint Threat Research tracks this activity as a distinct cluster.
Overview
Since at least 2022, North Korea-aligned threat actors have made a concerted effort not only to target cryptocurrency and decentralized finance organizations, but specifically to target developers using fake recruiter personas, malicious npm/PyPI packages (TraderTraitor / Jade Sleet), and trojanized cryptocurrency trading applications (AppleJeus / Citrine Sleet). These often masquerade as technical assessments or coding challenges and use techniques such as ClickFix or abusing Visual Studio Code’s features to execute malware. Approaches often occur over LinkedIn, Slack, Telegram, or in a multi-platform manner, with a consistent aim of targeting developer assets such as API tokens, cryptocurrency wallets, and credentials.
In April and May 2026, Proofpoint Threat Research observed a new, large wave of this type of activity distinct from known DPRK operations (also recently reported by independent researcher Denys Vitali). Proofpoint tracks this new cluster as UNK_DeadDrop, a very likely North Korea-aligned group that uses broad phishing to target developers.
Figure 1. Distribution of UNK_DeadDrop targeting across sector and geography.
Over a six-week period, the attackers sent over 250 emails to individuals in almost 100 organizations across several sectors, primarily technology, education, business services, and financial services, specifically organizations in the cryptocurrency industry. Most targeted organizations were in the US, but the distribution of targeted geographies was global.
Infection chain
The emails contained links to GitHub repositories masquerading as technical assignments or cryptocurrency-related projects. The instructions encouraged the target to clone the repository and open it in an editor such as VS Code or Cursor. A pre-configured task executes silently when the user opens the repository folder in the IDE, triggering platform-specific loaders that decode embedded payloads on Linux, macOS, and Windows. The loader installs a malicious VS Code extension (VSIX) masquerading as a legitimate Google service. The payloads communicate with a hardcoded C&C server, enabling remote command execution, system reconnaissance, followed by exfiltration of browser wallet extensions, decrypted credentials, and desktop wallets. The infection chain finishes by deleting malicious payloads and directories from the cloned repository in an effort to clean up forensic artifacts, while maintaining persistence through the VSIX extension.
Lures
UNK_DeadDrop activity in late April and early May 2026 masqueraded as companies from various sectors seeking to recruit for software developer roles.
The spoofed companies included:
Ondo Finance: a decentralized finance (DeFi) platform
Empower Pharmacy: a pharmaceutical company
NXLog: a log collection and centralization tool
OnePlan: a strategic portfolio and work management platform
Hypen Connect: a Web3 & AI Talent Agency
Valon: a mortgage service provider
Nourish: a telehealth company
The emails used attacker-owned sender domains and approached targets with job opportunities for “Full-Stack Engineer” or “Agent Lead Developer” positions.
Figure 2: UNK_DeadDrop emails containing job offers for developer roles.
The emails provided instructions on how to complete a technical assignment that was part of the job application process. The URLs led to attacker-controlled GitHub repositories hosting take-home assessments and coding challenges.
Campaigns observed later in May 2026 changed their approach to targets with requests for peer review on open-source projects. The attackers masqueraded as cryptocurrency trading or prediction companies, such as Pulsynk and Trixauvex, to send requests for developer code reviews with the option of a job offer based on the fixes.
Figure 3. UNK_DeadDrop emails requesting code reviews.
In late May, another UNK_DeadDrop campaign targeted finance and technology organizations requesting targets to test an ERC-4626 vault in Foundry, a toolkit for Ethereum and smart contract development.
Figure 4. UNK_DeadDrop emails requesting testing on Foundry tool.
The most recently observed iteration of UNK_DeadDrop campaigns used a project for building AI agent-based systems with payment capabilities, similarly including skill requirements and a potential job offer.
Figure 5. UNK_DeadDrop emails offering a role building an AI payments project.
Analysis of 10 repositories, all hosted by different GitHub accounts, showed four thematic categories: cryptocurrency platforms, exploit archives, Foundry testing, and AI payments.
Repo Name
GitHub Account
Theme
Description
First Commit Date
Repository URL
pulsynk
Pulsynk
Crypto Prediction
AI-powered cryptocurrency price prediction platform
May 10, 2026
hxxps://github[.]com/Pulsynk/pulsynk
trixauvex
Trixauvex-org
Crypto Trading
Cryptocurrency trading engine and analytics platform
May 16, 2026
hxxps://github[.]com/Trixauvex-org/trixauvex
rekt-db
PedrinPY
Exploit Archive
Cross-chain blockchain exploit archive with runnable PoCs
May 19, 2026
hxxps://github[.]com/PedrinPY/rekt-db
rekt-db
wayout4u
Exploit Archive
Cross-chain blockchain exploit archive with runnable PoCs
May 21, 2026
hxxps://github[.]com/wayout4u/rekt-db
rekt-db
Stomp47
Exploit Archive
Cross-chain blockchain exploit archive with runnable PoCs
May 25, 2026
hxxps://github[.]com/Stomp47/rekt-db
forge-4626-invariants
sr-werney
Foundry Testing
Drop-in Foundry invariant tests for ERC-4626 vaults
May 20, 2026
hxxps://github[.]com/sr-werney/forge-4626-invariants
forge-4626-invariants
ziobiri
Foundry Testing
Drop-in Foundry invariant tests for ERC-4626 vaults
May 27, 2026
hxxps://github[.]com/ziobiri/forge-4626-invariants
forge-4626-invariants
mireles343
Foundry Testing
Drop-in Foundry invariant tests for ERC-4626 vaults
May 26, 2026
hxxps://github[.]com/mireles343/forge-4626-invariants
x402-kit
skyjum
AI Payments
HTTP 402 micropayments for AI agents - EVM, Solana, Lightning adapters
May 25, 2026
hxxps://github[.]com/skyjum/x402-kit
x402-kit
rkama411
AI payments
HTTP 402 micropayments for AI agents - EVM, Solana, Lightning adapters
May 27, 2026
hxxps://github[.]com/rkama411/x402-kit
Figure 6. UNK_DeadDrop GitHub repositories and descriptions.
The attackers presented Pulsynk and Trixauvex as AI-powered crypto prediction and trading platforms with professional Python project structures, while rekt-db masqueraded as a security research archive with reproducible proof-of-concepts for real high-profile exploits such as Bybit ($1.46B), Wormhole ($325M), and Radiant Capital ($50M). The forge-4626-invariants repository was centered around drop-in Foundry invariant tests for ERC-4626 tokenized vaults. The newest variation, x402-kit, focused on HTTP 402 micropayment infrastructure with multi-chain adapters for EVM, Solana, and Lightning networks.
The malicious repositories appeared legitimate, masquerading as open-source projects targeting specific developer niches within the cryptocurrency and blockchain ecosystem: security researchers, DeFi developers, and AI engineers. They had technical credibility, containing realistic directory structures, working npm/forge scripts, and references to real standards and frameworks.
Across 10 repositories analyzed, there were roughly six builds containing only minor changes such as binary recompilations, altered naming conventions, and bug fixes. This suggests that the operators are continuing active development.
Delivery
The emails all contained GitHub or GitLab URLs with instructions to clone the repository and open it in a code editor such as VS Code or Cursor.
Figure 7. Sample attacker-controlled GitHub repository.
Inside the hidden vscode folder, there is a file called tasks.json that will execute either a shell script or .cmd file, buried in the src/ folder, when the repository is opened in Cursor or VS Code. This infection chain abuses the IDEs’ task automation as well as VSIX extensions to facilitate further execution, as well as achieve persistence on macOS and Linux devices.
Execution
The hidden tasks.json file defines a task with runOptions.runOn: "folderOpen", a VS Code feature that executes the task automatically when the folder is opened in the editor.
Figure 8. tasks.json file that is run when .vscode folder is opened.
The task definition specifies the platform-specific commands that will be executed when the task runs:
Linux/macOS: /bin/bash vendor/run-update[.]sh
Windows: wscript[.]exe //B //Nologo vendor/run-update-hidden-launch.vbs
VS Code requires user interaction before any task can run; additionally, if automatic task execution has never been accepted before, a second prompt is shown.
Figure 9. VS Code trust prompt when running malicious repository.
By contrast, Cursor does not show any trust dialog. Opening a folder with tasks.json containing runOn: "folderOpen" in Cursor results in immediate silent execution with zero user interaction.
The launcher scripts install the VSIX extension to the editor. Every time the user opens VS Code or Cursor on macOS or Linux, the VSIX extension activates, checks whether the subsequent infection portions are already running, and re-launches them if not. On Windows, this persistence mechanism does not apply. The pipeline executes once and terminates; the VSIX remains installed but does not re-execute on subsequent editor starts.
Once the task is executed, the infection chain diverges by platform. The Linux and macOS chains use a native Go binary that connects to the C&C as a persistent RAT, while Windows runs a Node.js pipeline entirely inside the editor's Electron process. Both paths share the same C&C infrastructure and exfiltration endpoints but differ significantly in their architecture and capabilities.
Linux/macOS infection chain
The Linux and macOS infection chains use native Go binaries derived from the open-source Overlord C&C framework (github[.]com/vxaboveground/Overlord). Unlike the Windows pipeline (which performs a single stealer operation), these binaries function as full RATs with persistent WebSocket connectivity.
Binary
Platform
google-update-support-linux-amd64
Linux AMD64
google-update-support-darwin-amd64
macOS Intel
google-update-support-darwin-arm64
macOS Apple Silicon
Figure 10. Binaries built for respective platforms.
The threat actor added three custom modules: browserlogin (Chrome and Firefox credential theft), companywallet (crypto wallet stealer with 2-phase ZIP+upload exfiltration), and cleanup (anti-forensic removal of workspace artifacts).
The initial launcher (run-update.sh) is a bash script with an embedded Base64-encoded payload. When executed, it installs the VSIX extension in all available editors (Cursor, VS Code, VSCodium), resolves the correct Go binary for the platform, removes macOS quarantine, and launches Overlord fully detached. It also schedules cleanup of vendor/ and .vscode/ via a background subshell that survives editor shutdown.
Figure 11. run-update.sh (Base64-decoded).
Once Overlord is running, it immediately establishes a persistent WebSocket connection to the C&C server at 23.137.105[.]75:5173.
Figure 12. Overlord agent.log.
macOS credential theft and exfiltration
The credential theft chain then proceeds differently on each platform. Internally, the malware code divides its operation into two phases: Phase 1 (wallet data collection) and Phase 2 (credential theft + exfiltration). Overlord first collects wallet extension data, browser profile artifacts, and standalone wallet directories, packaging them into a ZIP and uploading to the C&C server. The malware waits five minutes before proceeding to credential theft. The credential theft uses a second embedded Mach-O binary named darwin-password-prompt that creates a fake system dialogue to prompt the user to enter their password:
Figure 13. darwin-password-prompt app showing the fake prompt.
Figure 14. Prompt for the credentials to access the keychain.
The credentials are validated by the parent Overlord process. After password validation, the malware modifies Keychain ACLs for the following browsers: Chrome, Brave, Edge, Opera, Vivaldi, Arc, Yandex, and Chromium. Safe Storage keys are then extracted. Following credential gathering, the backdoor re-launches itself as root using the captured password.
The elevated instance performs a command to dump the entire login keychain. The collected credentials, Safe Storage keys, and keychain data are then packaged as ZIP files and uploaded to the C&C via the persistent WebSocket connection.
Linux credential theft and exfiltration
If it is running on Linux, Overlord first collects wallet-related data (browser extension storage, standalone wallet directories) and uploads a ZIP to the C&C before attempting credential theft. After Phase 1 upload, the agent waits five minutes before proceeding to password capture. The Linux backdoor uses Zenity, a standard GTK dialog tool present on most desktop Linux distributions, to create a prompt to collect user credentials.
Figure 15. Fake dialog to collect user credentials.
This backdoor also attempts to read browser passwords from GNOME Keyring by spawning Python3 processes for each browser, querying chrome_libsecret_os_crypt_password_v2 and v1 schemas. If secret-tool is not installed, the agent falls back to the Python gi.repository.Secret method via D-Bus.
Similar to the macOS chain, Overlord re-launches itself as root using the captured password. The elevated instance re-attempts keyring access by impersonating the original user via runuser, since the GNOME Keyring is tied to the user session and not accessible directly as root. Credentials are exported to e_p.txt and uploaded as a _pa.zip to the C&C.
Windows infection chain
Unlike Linux/macOS, the Windows attack does not deploy a Go binary. It runs entirely as JavaScript inside the editor's Electron process using ELECTRON_RUN_AS_NODE=1, a documented Electron feature that turns the editor into a plain Node.js interpreter. No binary is dropped to disk, the process appears as Code.exe in Task Manager, and the editor itself provides the runtime. As stated before, the VSIX extension does not create persistence in the Windows infection chain.
The tasks.json file launches run-update-hidden-launch.vbs via wscript[.]exe //B (hidden window), which calls run-update[.]cmd.
Figure 16. run-update.cmd script.
The CMD file decodes an embedded script, which installs a VSIX extension. The script then stages three encrypted files into a staging directory and relaunches the editor with ELECTRON_RUN_AS_NODE=1 running gus-node-bootstrap.js.
The three encrypted payloads are decrypted at runtime using the hardcoded AES-256-GCM key: 4f7a8c3d2e1b5f9071a6b2c8d4e3f50a92b1c7d6e8f4a30b5c2d9e1f7a6b8c4d.
Encrypted file
Purpose
windows-js-pipeline.js.enc
Runs the Node.js agent through both phases, uploads artifacts to the companywallet API, and cleans up Windows runtime files.
windows-agent-node.js.enc
Wallet stealer + Python setup
detect_malware.py.enc
DPAPI + App-Bound Encryption bypass for credential stealing
Figure 17. Windows encrypted payloads in staging directory.
Credential theft and exfiltration
The Windows variant first conducts wallet collection and then credential theft. The wallet collection is done by scanning Chromium browser variants for items in Local State, Login Data, and Local Extension Settings/, as well as wallet-specific IndexedDB entries. It targets 35 wallet extension IDs (MetaMask, Phantom, Rabby, Keplr, and others), 18 standalone wallet applications (Exodus, Electrum, Ledger Live, Monero, Solana CLI, Bitcoin, and others), and Firefox profiles. It also enumerates all Windows user profiles via registry, not just the current user.
The wallet stealer also looks for Python executables in the victim host and attempts to download Python 3.12.8 embeddable from the C&C, or falls back to system Python. If downloaded, Python is installed inside the browser's application directory (e.g., Program Files\Google\Chrome\Application\python[.]exe) to pass App-Bound Encryption's path validation.
Once Python is available, the credential stealer (detect_malware.py) is executed for each browser profile. It performs:
Password extraction from Chromium browsers via DPAPI + App-Bound Encryption bypass (COM Elevation Service, IElevator2)
Firefox credential extraction via key4.db + logins.json
Cookie theft from Chrome/Edge/Brave
Five cascade methods for reading locked databases: shutil.copy2 → SQLite backup() → Win32 shared-read → Win32 backup-semantics → Volume Shadow Copy (VSS)
For Chrome, Edge, and Brave, elevated privileges are required to access credentials protected by App-Bound Encryption. COM Elevation Moniker is used to elevate privileges silently. If this fails, it falls back to Start-Process -Verb RunAs, which displays the standard Windows UAC dialog.
After both phases are complete, the stolen data is uploaded to the C&C server at 23.137.105[.]75:5173 via HTTP POST. Unlike the Linux/macOS agent, the Windows pipeline does not maintain a persistent connection; it uploads the ZIP files, performs cleanup, and terminates.
The VSIX package.json contains a reference to a Windows binary (google-update-support-windows-amd64.dat) in its description of the windowsActivationMode setting. While this binary was not found in any of the analyzed repositories, searching VirusTotal for the developer path Yuki/dionbenu2yuki returned Windows samples named google-update-support-windows-amd64[.]exe with the same C&C server and agent token found in the Linux and macOS binaries. This implies the threat actor previously distributed a Windows Go binary (Overlord RAT) but replaced it with the Node.js and Python pipeline in the current campaign, likely to avoid detection. The references to the DAT/EXE binary in the scripts are legacy code that is no longer executed.
Infrastructure
UNK_DeadDrop campaigns spanned April and May 2026 with related infrastructure created in the same timeframe and emails sent within days of domain registrations.
Figure 18. UNK_DeadDrop domain registration timeline (April-May 2026).
Most domains were registered using Namecheap, and set MailHostBox mailservers. The domains used slight name variations of fake companies used for recruiting in phishing emails.
Some domains used to send phishing emails were also hosting unfinished, likely AI-generated websites to market the projects. These were hosted on Vercel Inc. rather than Namecheap infrastructure.
Figure 19. Fake company websites hosted at trixauvexnet[.]ink, trixauvex[.]org, and pulsnyk[.]org.
A small subset of domains, including nemesis[.]work, used Advin Services LLC IPs for hosting, which are likely attacker-controlled boxes that were also used as sender IPs in early UNK_DeadDrop campaigns: 170.205.29[.]83 and 170.205.30[.]227. In May, the attackers transitioned to using Mailgun and MailHostBox as email sender services.
Figure 20. Fake company website spoofing NEMESIS, a decentralized finance protocol, hosted at nemesis[.]work.
Attribution
UNK_DeadDrop activity shares several characteristics with previously documented North-Korea-aligned operations, specifically Contagious Interview activity reported by OpenSourceMalware, Microsoft, and JAMF. The campaigns broadly overlap in developer targeting, cryptocurrency and credential theft, GitHub delivery, VS Code workflow abuse, and cross-platform targeting.
UNK_DeadDrop
Contagious Interview
Targeting
Software developers, security researchers, AI engineers in cryptocurrency
Developers in cryptocurrency and AI
Target platforms
macOS, Windows, Linux
macOS, Windows, Linux
Initial access
Phishing over email
Phishing over social media
Lures
Job recruitment, code reviews
Job recruitment
Delivery
GitHub, GitLab
GitHub, GitLab, BitBucket
Repositories
Professional structure, legitimate references, industrialized creation, iterative builds, consistent obfuscation
Possibly AI-assisted generation, less polished code, tutorial comments, emoji logging
Installation
VS Code tasks.json auto-execution abuse (silent)
VS Code tasks.json npm installation abuse (visible)
Execution
Malicious VSIX extension and self-contained payloads
Remote fetch from Vercel or external hosting
Payload
Overlord (Go binaries)
OtterCookie (JavaScript), Invisible Ferret (Python), FlexibleFerret (Go/Python)
C&C protocol
WebSocket Secure (WSS)
HTTP/HTTPS
Exfiltration
Cryptocurrency wallets, browser credentials, system keychains
Cryptocurrency wallets, API tokens, credentials, source code, password managers
Anti-forensics
Removes payload and malicious artifacts from directories
Self-cleanup capability
Figure 20. Comparison of UNK_DeadDrop and Contagious Interview campaigns and TTPs.
However, there are several differences between the activity sets, such as the shift in social engineering from arranging fake interviews to unsolicited job offer or code review approaches as well as the move from delivery platforms such as LinkedIn to email. UNK_DeadDrop campaigns use the Overlord framework as a payload instead of custom malware, and it is contained within the repository rather than hosted remotely. The VS Code auto-execution approach exploits trust in standard developer workflows similar to malicious npm packages and previous VS code abuse, but requires less user interaction, executes silently without output, and doesn’t rely on external infrastructure that can be taken down.
It is possible, or even likely, that the overlaps between UNK_DeadDrop and Contagious Interview demonstrate an operational evolution to include more mature techniques rather than distinct but related groups. However, based on the use of email for initial access, the high volume of emails, industrialization and scale of repository creation, a new self-contained payload, and distinct infrastructure from previous Proofpoint observations of Contagious Interview campaigns, Proofpoint Threat Research continues to track UNK_DeadDrop activity as an independent cluster.
Conclusion
UNK_DeadDrop activity suggests North Korea-aligned operations targeting developers for financial gain are maturing and evolving. The shift from active social engineering over social media platforms to conduct fake interviews to large campaigns of recruitment-themed phishing emails distributing links to malicious repositories could indicate an actor industrializing and scaling operations. The consistent creation of new GitHub repositories as well as a new malware framework with iterative builds and a stealthy new execution and persistence technique through VSIX extensions demonstrates dedicated resourcing and active development of tooling. The attackers have likely also adapted by embedding payloads rather than hosting them externally, potentially increasing operational resilience and avoiding the effects of infrastructure takedowns.
UNK_DeadDrop bears many similarities to Contagious Interview activity and may be an improved and more professional iteration of previous operations as attackers adapt to defenders and adopt new techniques. However, the TTP and infection chain differences could also suggest another actor leveraging previously disclosed techniques or a subgroup incorporating various types of tradecraft into one operation. While attribution to a known actor remains unconfirmed, Proofpoint continues to track this ongoing activity as an independent cluster.
Indicators
Indicator
Type
Description
First Seen
alex@contacttrixauvex[.]ink
Email address
Attacker-controlled email address
May 2026
alex@mailpredicttogether[.]ink
Email address
Attacker-controlled email address
May 2026
alex@predicttocareer[.]space
Email address
Attacker-controlled email address
May 2026
alex@pulsynk[.]org
Email address
Attacker-controlled email address
May 2026
alex@trixauvexnet[.]ink
Email address
Attacker-controlled email address
May 2026
alexsnow@hr.onoplanoai[.]ink]
Email address
Attacker-controlled email address
May 2026
alexsnow@hr.predicttocareer[.]space
Email address
Attacker-controlled email address
May 2026
alexstone@hr.trixauvex[.]org
Email address
Attacker-controlled email address
May 2026
carissae@hr.mailpulsynk[.]xyz
Email address
Attacker-controlled email address
May 2026
christopher@hr.trixauvex[.]org
Email address
Attacker-controlled email address
May 2026
chrisyan@hr.pulsynk[.]org
Email address
Attacker-controlled email address
May 2026
emmaparker@hr.recruitvex[.]us
Email address
Attacker-controlled email address
May 2026
faithtedesco@hr.mailtrixauvex[.]ink
Email address
Attacker-controlled email address
May 2026
frankbloch@hr.trixauvex[.]org
Email address
Attacker-controlled email address
May 2026
jamesrock@hr.trixauvexnet[.]ink
Email address
Attacker-controlled email address
May 2026
jamierain@hr.contacttrixauvex[.]ink
Email address
Attacker-controlled email address
May 2026
jamierain@hr.onoplanoai[.]ink
Email address
Attacker-controlled email address
May 2026
jamiereed@hr.mailpredicttogether[.]ink
Email address
Attacker-controlled email address
May 2026
jamiereed@hr.predicttocareer[.]space
Email address
Attacker-controlled email address
May 2026
joshn@hr.recruitvex[.]us
Email address
Attacker-controlled email address
May 2026
justinstone@hr.trixauvex[.]org
Email address
Attacker-controlled email address
May 2026
nicoupdyke@hr.trixauvexnet[.]ink
Email address
Attacker-controlled email address
May 2026
oliviaben@hr.pulsynk[.]org
Email address
Attacker-controlled email address
May 2026
sam@hr.pulsynk[.]org
Email address
Attacker-controlled email address
May 2026
samalt@hr.contacttrixauvex[.]ink
Email address
Attacker-controlled email address
May 2026
samalt@hr.onoplanoai[.]ink
Email address
Attacker-controlled email address
May 2026
samalt@hr.predicttocareer[.]space
Email address
Attacker-controlled email address
May 2026
shelbysturm@hr.mailtrixauvex[.]ink
Email address
Attacker-controlled email address
May 2026
sophiareed@hr.contacttrixauvex[.]ink
Email address
Attacker-controlled email address
May 2026
sophiareed@hr.onoplanoai[.]ink
Email address
Attacker-controlled email address
May 2026
taylorzhang@hr.pulsynk[.]org]
Email address
Attacker-controlled email address
May 2026
dalbir@empowerpharmacy[.]space
Email address
Attacker-controlled email address
April 2026
dianaberendi@nxlog[.]tech
Email address
Attacker-controlled email address
April 2026
gusb@ondofinance[.]tech
Email address
Attacker-controlled email address
April 2026
jasen@empowerpharmacy[.]space
Email address
Attacker-controlled email address
April 2026
joshc@ondofinance[.]tech
Email address
Attacker-controlled email address
April 2026
jovanav@nxlog[.]tech
Email address
Attacker-controlled email address
April 2026
michaelw@ondofinance[.]tech
Email address
Attacker-controlled email address
April 2026
neila@ondofinance[.]tech
Email address
Attacker-controlled email address
April 2026
oladotuna@ondofinance[.]tech
Email address
Attacker-controlled email address
April 2026
sarikasinha@nxlog[.]tech
Email address
Attacker-controlled email address
April 2026
sladjanas@nxlog[.]tech
Email address
Attacker-controlled email address
April 2026
valerie@empowerpharmacy[.]space
Email address
Attacker-controlled email address
April 2026
vanjamirkovic@nxlog[.]tech
Email address
Attacker-controlled email address
April 2026
nemesistrade[.]work
Domain
Related infrastructure
May 2026
ceronet[.]work
Domain
Related infrastructure
May 2026
deep-ai-guard[.]store
Domain
Related infrastructure
May 2026
ceronetwork[.]org
Domain
Related infrastructure
May 2026
culyrax[.]us
Domain
Related infrastructure
May 2026
elsavora[.]us
Domain
Related infrastructure
May 2026
optixauvex[.]us
Domain
Related infrastructure
May 2026
recruitvex[.]us
Domain
Sender domain
May 2026
talentnexhr[.]ink
Domain
Related infrastructure
May 2026
onoplanoai[.]ink
Domain
Sender domain
May 2026
trixauvexnet[.]ink
Domain
Sender domain
May 2026
recruitptogether[.]xyz
Domain
Related infrastructure
May 2026
contactpredicttogether[.]ink
Domain
Related infrastructure
May 2026
connectptogether[.]ink
Domain
Related infrastructure
May 2026
notifypulsynk[.]ink
Domain
Related infrastructure
May 2026
contactpulsynk[.]ink
Domain
Related infrastructure
May 2026
contacttrixauvex[.]ink
Domain
Sender domain
May 2026
trixauvex[.]org
Domain
Sender domain
May 2026
careertrixauvex[.]ink
Domain
Related infrastructure
May 2026
cotrixauvex[.]ink
Domain
Related infrastructure
May 2026
pulsynk[.]org
Domain
Sender domain
May 2026
mailtrixauvex[.]ink
Domain
Sender domain
May 2026
teampulsynk[.]team
Domain
Related infrastructure
May 2026
careerpulsynk[.]xyz
Domain
Related infrastructure
May 2026
mailpulsynk[.]xyz
Domain
Sender domain
May 2026
mailpredicttogether[.]ink
Domain
Sender domain
May 2026
predicttogetherrecruit[.]store
Domain
Related infrastructure
May 2026
predicttogerecruit[.]store
Domain
Related infrastructure
May 2026
predicttogether[.]ink
Domain
Related infrastructure
May 2026
careerpredictto[.]space
Domain
Related infrastructure
May 2026
togetherhire[.]fun
Domain
Related infrastructure
May 2026
predictcareertogether[.]space
Domain
Related infrastructure
May 2026
predicttocareer[.]space
Domain
Sender domain
May 2026
nowurisch[.]fit
Domain
Sender domain
May 2026
hyperdevpipline[.]org
Domain
Sender domain
May 2026
asteara[.]org
Domain
Related infrastructure
April 2026
doxxela[.]ink
Domain
Related infrastructure
April 2026
coslyintra[.]online
Domain
Related infrastructure
April 2026
valorecuiting[.]online
Domain
Sender domain
April 2026
onoplainai[.]ink
Domain
Related infrastructure
April 2026
raxvatange[.]ink
Domain
Related infrastructure
April 2026
alphanonega[.]org
Domain
Related infrastructure
April 2026
domatisc[.]ink
Domain
Related infrastructure
April 2026
migadyn[.]info
Domain
Sender domain
April 2026
empowerpharmacy[.]space
Domain
Sender domain
April 2026
nxlog[.]tech
Domain
Sender domain
April 2026
ondofinance[.]tech
Domain
Sender domain
April 2026
170.205.29[.]83
IP address
Sender IP
April 2026
170.205.30[.]227
IP address
Sender IP
April 2026
hxxps://github[.]com/Pulsynk/pulsynk
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/Trixauvex-org/trixauvex
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/PedrinPY/rekt-db
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/sr-werney/forge-4626invariants
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/wayout4u/rekt-db
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/ziobiri/forge-4626-invariants
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/skyjum/x402-kit
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/Stomp47/rekt-db
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/mireles343/forge-4626invariants
URL
Attacker-controlled GitHub repository
May 2026
hxxps://gitlab[.]com/pulsynk-org/rekt-db.git
URL
Attacker-controlled GitHub repository
May 2026
hxxps://gitlab[.]com/trixauvex-org/x402-kit.git
URL
Attacker-controlled GitHub repository
May 2026
hxxps://gitlab[.]com/predict-together/forge-4626invariants.git
URL
Attacker-controlled GitHub repository
May 2026
hxxps://github[.]com/rkama411/x402-kit
URL
Attacker-controlled GitHub repository
May 2026
23.137.105[.]75
IP address
C&C IP
May 2026
35813f4401d3ad77b618275473a556eb47bfa6f4b7439dd8943b19f81aa7252e
SHA256
settings.json
May 2026
c935808147f0236c81483d7bbeda4b9d602f3595d5d4057f8115d39e222d1c4b
SHA256
tasks.json
May 2026
4c0d9b802c075be79e9edb52d88f8dd72e6904f5c58267213745818470945c78
SHA256
run-update-hidden-launch.vbs
May 2026
62761f38ed194c59abe15c49f09f0ebc431ac852c965180c9327ed84d3a454fb
SHA256
run-update.cmd
May 2026
d3ebce2f05fe91a8260e87fd11a6ea17c156703d081b3f91d9bbe5fd6aeedc10
SHA256
gus-node-bootstrap.js
May 2026
91b9381d19b2e6a2db5cc0307167979b502731cb3fb50da684479e9ed35261aa
SHA256
windows-agent-node.js.enc
May 2026
6cf9f7b2aa456a0b438600588df869b38d8007e28f01fa96022f9d8059f120b0
SHA256
windows-js-pipeline.js.enc
May 2026
2812e0847d472cb8870c94f463331dbe53b84135132b9bf5f6d84c2382be628f
SHA256
detect_malware.py.enc
May 2026
52886aab179f26421678ff23af1b0fabf0a17ffbb534369cdbbac8008cbed8e7
SHA256
google-update-support.vsix
May 2026
d5e9288693aa745dc89368deac677e7ea1ec81e663283af30838cdae189b7a7e
SHA256
extension.js
May 2026
734699773e53d995f20d485eb61261033d9d00b4332b39ca26071bcd60cd352f
SHA256
run-update.sh
May 2026
e1bf1b29e6fa3525d7f32f429290a88d6ea2890e61c06574b8ff6372aa5d0667
SHA256
google-update-support-agent.zip
May 2026
a2b9a769df84d9d3a4694bb0252a2c6a5e5f5d1a85a04565362737092bbb3a86
SHA256
google-update-support-linux-amd64
May 2026
bb10adac5b0124efedfe71102c1d5638135ec9e1cde8c8cb3353c5ed91bb9f81
SHA256
google-update-support-darwin-amd64
May 2026
339907b44f161f57ff30819f422c552382ff437b3ae437463b4222cfe86bd943
SHA256
google-update-support-darwin-arm64
May 2026
808e7154b7af2bc7a4b28d577297c55f77221c355191cbe00f9f1810b6d4a619
SHA256
darwin-password-prompt
May 2026
Login
