Poisoned Ruby Gems and Go Modules Exploit CI Pipelines for Credential Theft

A new software supply chain attack campaign has been observed using sleeper packages as a conduit to subsequently push malicious payloads that enabled credential theft, GitHub Actions tampering, and SSH persistence.

The activity has been attributed to the GitHub account "BufferZoneCorp," which has published a set of repositories that are associated with malicious Ruby gems and Go modules. As of writing, the packages have been yanked from RubyGems, and the Go modules have been blocked. The names of the libraries are listed below -

• Ruby:
  • knot-activesupport-logger
  • knot-devise-jwt-helper
  • knot-rack-session-store
  • knot-rails-assets-pipeline
  • knot-rspec-formatter-json
  • knot-date-utils-rb (Sleeper gem)
  • knot-simple-formatter (Sleeper gem)
• Go:
  • github[.]com/BufferZoneCorp/go-metrics-sdk
  • github[.]com/BufferZoneCorp/go-weather-sdk
  • github[.]com/BufferZoneCorp/go-retryablehttp
  • github[.]com/BufferZoneCorp/go-stdlib-ext
  • github[.]com/BufferZoneCorp/grpc-client
  • github[.]com/BufferZoneCorp/net-helper
  • github[.]com/BufferZoneCorp/config-loader
  • github[.]com/BufferZoneCorp/log-core (Sleeper module)
  • github[.]com/BufferZoneCorp/go-envconfig (Sleeper module)

The identified packages masquerade as recognizable and well-known modules like activesupport-logger, devise-jwt, go-retryablehttp, grpc-client, and config-loader so as to evade detection and trick users into downloading them.

"The account is part of a software supply chain campaign targeting developers, CI runners, and build environments across two ecosystems," Socket security researcher Kirill Boychenko said in an analysis published today.

The Ruby gems are designed to automate credential theft during install time, harvesting environment variables, SSH keys, AWS secrets, .npmrc, .netrc, GitHub CLI configuration, and RubyGems credentials. The stolen data is then exfiltrated to an attacker-controlled Webhook[.]site endpoint.

On the other hand, the Go modules harbor broader capabilities to tamper with GitHub Actions workflows, plant fake Go wrappers, steal developer data, and add a hard-coded SSH public key to "~/.ssh/authorized_keys" for remote access to the compromised host. The modules do not all have the same payload; instead, they are spread across the cluster.

"The module executes through init(), detects GITHUB_ENV and GITHUB_PATH, sets HTTP_PROXY and HTTPS_PROXY, writes a fake go executable into a cache directory, and appends that directory to the workflow path so the wrapper is selected before the real binary," Boychenko explained.

"That wrapper can then intercept or influence later go executions while still passing control to the legitimate binary to avoid breaking the job."

Users who have installed the packages are advised to remove them from their systems, review for signs of access to sensitive files or unauthorized changes to "~/.ssh/authorized_keys," rotate exposed credentials, and inspect network logs for outbound HTTPS traffic to the exfiltration point.

from The Hacker News https://bit.ly/4teDVOR
via IFTTT

Btrfs vs ZFS: An In-Depth Comparison

Compare Btrfs and ZFS to understand their key differences in performance, architecture, and data integrity. Learn which filesystem fits your workload, from lightweight setups to enterprise storage.

For years most Linux machines just ran ext4. Drives were small, datasets were small, and the worst that usually happened was a power loss. That is no longer the world we work in. Drives got bigger, data picked up more value attached to it, and silent corruption stopped being a theoretical concern. So the question of “what filesystem do I run?” got more interesting, and Btrfs and ZFS are usually where the conversation lands.

Both are copy-on-write. Both check data with checksums, do snapshots, manage pools of disks, and try to use space efficiently. Same general targets – very different routes to get there.

Below is a real comparison: how each one performs, what features they actually ship, where they break, and which one fits which kind of workload.

What are Btrfs and ZFS?

 

Figure 1: Btrfs and ZFS file systems difference

 

Btrfs (B-tree File System) is a Linux-native file system. Oracle started it around 2007, and it has been part of mainline Linux kernel for years. It focuses on flexibility – snapshots, subvolumes, online resizing, RAID 0/1/10, and RAID 5/6 with caveats. Because it sits in the kernel, installing it is essentially nothing.

ZFS (Zettabyte File System) is older and much more mature. Sun Microsystems built it for Solaris in the early 2000s. After Oracle bought Sun, the open-source side continued as OpenZFS, and that is what almost everyone runs today. ZFS is built around data integrity and very large pools.

The easiest way to think about them: Btrfs is a filesystem with extra features. ZFS is a complete storage system that also includes a filesystem.

Origins and design philosophy

The two filesystems were designed with very different goals in mind, and you can still see those goals in how they work today.

Btrfs was built for Linux, by Linux developers. The idea was to bring modern filesystem features such as snapshots, checksums, and flexible pooling to the Linux kernel without the need for a separate volume manager. It is modular and designed to work alongside the rest of the Linux storage stack. That makes it easier to install and use, but it also means Btrfs relies on other kernel components for things like encryption.

ZFS was never meant to be just a filesystem. It combines the filesystem, volume manager, and software RAID layer into one integrated package. Such bundling is what makes ZFS reliable – the layers communicate directly, so corruption or hardware glitches do not slip between abstractions. The trade-off is that ZFS is heavier, more complex, and lives outside the Linux kernel because of license incompatibility (CDDL vs GPL).

Key differences between Btrfs and ZFS

On paper they look similar. Both are copy-on-write. Both do snapshots. Both checksum the data. Once you sit down with them, the differences are big enough to drive the choice.

Architecture: Btrfs is modular and lives in the kernel. It works alongside other Linux storage tools, and you can mix and match them – for example, using LUKS for encryption and Btrfs on top. ZFS is a fully integrated stack that handles storage from the physical disk all the way up to the filesystem. Disks, RAID, volumes, snapshots, and encryption – all live in one piece of software. This makes ZFS more capable out of the box, but also less flexible if you want to combine it with other tools. Btrfs trades some power for being easier to fit into a typical Linux setup.

Maturity: ZFS has been running production storage for over twenty years. Many companies use it to manage petabytes of data. That kind of mileage means most of bugs were fixed years ago. Btrfs is younger – it was declared stable for general use around 2014 and still has rough edges, especially around RAID 5/6. The core filesystem itself is solid these days, but anything off the well-trodden path is more likely to surprise you than ZFS will.

RAID: ZFS has its own RAID system, RAID-Z. It is one of the most trusted software RAID implementations out there, and it comes in three flavors – RAID-Z1, Z2, Z3 – differing in how many drives can fail before data is lost. Btrfs has its own RAID modes too. The simple ones (0, 1, 10) are fine. The parity ones (5 and 6) are still not considered production-ready. The Btrfs developers have been working on it for a long time, but as of now anyone who needs reliable parity RAID on Linux usually goes ZFS, or stacks Btrfs on top of mdraid.

Memory usage: ZFS is resource-intensive. It uses RAM aggressively for caching through the Adaptive Replacement Cache (ARC). The ARC keeps frequently used data in memory, so reads return almost instantly. This is a big reason why ZFS feels fast. The downside is that on a busy system, ZFS can consume gigabytes of RAM that other applications might need. However, you can set limits on memory usage to mitigate this. Btrfs is much lighter and runs comfortably on machines with limited memory. A small home server with 4 GB of RAM is no problem for Btrfs, while ZFS on the same machine may feel slow. If you are working with limited hardware, this difference alone can make the decision for you.

High-level comparison table

A quick side-by-side across the categories most people care about:

 

	Btrfs	ZFS
Architecture	Modular, lives in Linux kernel	Integrated stack, separate from kernel
Maturity	Stable since ~2014, RAID 5/6 still rough	20+ years in production storage
RAID	0/1/10 solid; 5/6 not production-ready	RAID-Z1/Z2/Z3, mirrors, all trusted
RAM footprint	Light, fine on 4 GB boxes	Heavy, ARC will eat what you give it
Native encryption	No, use LUKS underneath	Yes, per-dataset
Snapshots	Subvolume snapshots, send/recv exists	First-class, polished send/recv
Default in distros	Fedora, openSUSE	TrueNAS, Proxmox, ports for Ubuntu
License vs Linux	GPL, in-tree	CDDL, ships out-of-tree

 

Btrfs vs ZFS performance comparison

Performance is where people expect one to crush the other. In practice it depends entirely on the workload and how the pool is set up. Synthetic benchmarks rarely tell you anything useful here – what matters is how the filesystem behaves under your real workload.

ZFS is strong on large datasets and sequential I/O. Most of that comes from caching: the ARC in memory and the optional L2ARC on a fast SSD. ARC keeps hot data in RAM so repeat reads come back almost instantly; L2ARC extends that cache onto an SSD when working set is bigger than RAM. Given enough memory, ZFS read performance is very consistent.

Writes are a different story. Sequential writes are fine. Random writes are a weak point. Every write goes to a new location because of copy-on-write, which fragments the data over time and puts pressure on the disks. RAID-Z makes it worse, because small random writes often turn into full-stripe operations across every disk in a vdev. For random-heavy workloads – busy databases are the obvious example – mirrored vdevs perform far better than RAID-Z, and you need a lot of RAM to keep things smooth.

Synchronous writes deserve their own paragraph. A sync write is one the application requires to land on disk before continuing. Databases do this constantly to protect data. By default ZFS satisfies sync writes through the ZFS Intent Log (ZIL), which lives on the same drives as the data. Every sync write hits the disks twice, which is brutal on spinning rust. A separate log device (SLOG) on a fast SSD or NVMe drive moves the ZIL off the main pool so sync writes can be acknowledged quickly without stalling everything else. Without a SLOG, a database server on ZFS-on-spinning-disks can feel painful.

Btrfs is lighter and quicker to set up, which makes it feel snappier in casual use. There is no big cache to warm up and not much to tune. It also has its own performance limits. Heavy writes hurt – especially on spinning disks and especially with metadata-heavy workloads. The fragmentation problem that used to torture Btrfs is better than it used to be, but it still appears in database-style workloads where the same files are rewritten constantly. There is a nodatacow mount option that turns CoW off for specific files, which fixes the problem and also disables checksums for them. That kind of defeats one of the reasons you picked Btrfs in the first place. Random write performance is generally below ext4 or XFS, and unlike ZFS there is no caching layer or log device you can point at the problem.

For a desktop, a home server, or a small NAS, you probably will not notice much difference. The bottleneck is usually network or drives, not the filesystem.

For a busy database server with dozens of users, ZFS is usually the safer choice. Reasons are not purely technical – it has been in production for two decades, the community of admins who know how to tune it is large, and the documentation is extensive. When something goes wrong, the chance of finding an answer is much higher with ZFS than with Btrfs.

That said, ZFS is not a fix for everything. It cannot rescue a setup that does not have enough RAM or the right vdev layout, and a badly designed pool can perform worse than plain ext4 on the same hardware. ZFS rewards the people who learn it and punishes anyone treating it as a drop-in replacement.

Workload-based performance

Different workloads require different tools. Here is how the two filesystems handle common workloads:

Different workloads, different tools. Here is roughly how the two handle common patterns:

 

	Btrfs	ZFS
Sequential reads	Fine, no real cache layer	Excellent once ARC warms up
Random reads	Decent on SSDs	Strong, especially with L2ARC
Sequential writes	Fine on SSDs, weaker on HDDs	Fine, integrates well with vdevs
Random writes	Weak point, fragments quickly	Mirrored vdevs OK, RAID-Z is rough
Database (sync writes)	Use nodatacow, lose checksums	Needs SLOG to be usable on HDDs
Lots of small files	Reasonable	Reasonable, tune recordsize
VM image storage	Subvolumes work well	zvols are first-class for this

 

SSD optimization: Both filesystems support TRIM and work fine on SSDs. ZFS offers more tuning options – you can adjust record sizes, enable specific caches, and tweak compression per dataset. Btrfs is simpler but performs well on SSDs with default settings.

Features comparison: Btrfs vs ZFS

Both filesystems have many modern features, but the quality and depth of those features vary. Here are the most important ones and how they compare:

 

Feature	Btrfs	ZFS
Snapshots	Yes, fast and simple to create	Yes, mature and integrated with send/receive
Compression	Yes (zlib, LZO, Zstd)	Yes (LZ4, Zstd, gzip) – more mature implementation
Deduplication	Limited (offline dedup tools only)	Native inline deduplication (RAM-heavy)
RAID 0 / 1 / 10	Yes, stable	Yes, stable
RAID 5 / 6	Available but not production-ready	RAID-Z1, Z2, Z3 – all production-ready
Encryption	Relies on dm-crypt / LUKS	Native encryption built in
Online resize	Grow and shrink	Grow only

 

ZFS features are generally more integrated and production-hardened, while Btrfs focuses on flexibility and ease of use. The sections below break down how these differences play out.

Snapshots: Both filesystems create snapshots in seconds and use almost no extra space at first. ZFS snapshots are a bit more polished – you can send them to another machine over the network with a single command, which is very useful for backups and replication. Btrfs offers similar functionality, but the tooling is less refined.

Compression: Both support modern compression algorithms like Zstd and LZ4. In practice, ZFS compression tends to be more tunable. You can set it per dataset and get very good control over the setup. Btrfs compression is simpler and works well out of the box.

Deduplication: This is where ZFS has a clear advantage. It can deduplicate data inline as you write it, saving space automatically. The downside is that it requires a significant amount of RAM. A common rule of thumb is roughly 5 GB per 1 TB of deduplicated data. Btrfs does not have native inline deduplication. You can use offline tools like duperemove, but this is a separate process rather than an integrated feature.

RAID: ZFS wins here. RAID-Z is well-trusted and very good at handling drive failures. Btrfs RAID 1 and 10 are solid, but RAID 5 and 6 still have known data loss risks in certain failure scenarios. If you need parity RAID, ZFS is the clear choice between the two.

Copy-on-write and snapshots explained

 

Figure 2. Copy-on-write makes snapshots cheap and crashes safe.

 

Copy-on-write (CoW, for short), is the most important feature that makes these filesystems special. When you change a file on a CoW filesystem, the original data is not overwritten. Instead, the new data is written to a new location, and the filesystem updates its internal pointers to use the new version.

This sounds like a small detail, but it unlocks three big benefits:

• Instant snapshots: Because the old data is still there, taking a snapshot is almost free. The filesystem just remembers where the old pointers were. No data is copied, and no space is used until you start making changes.
• Efficient backups: Because the filesystem tracks which blocks changed since the last backup, it can send just those changed blocks to a backup target. Instead of copying entire files every time, you send small differences. This makes incremental backups fast and efficient in terms of bandwidth.
• Crash consistency. Writes always go to new locations first, so a crash mid-write cannot corrupt data already on disk. Either the whole change is committed or none of it is. No half-written files.

This approach has a small downside. Over time, CoW can fragment data more than traditional filesystems. Both Btrfs and ZFS have mitigations for this, but it is something to be aware of if you store large files that change frequently.

Scalability and storage architecture

Scale is one of the clearest differences between ZFS and Btrfs.

ZFS was built for large-scale environments from day one. It uses 128-bit addressing, which means the theoretical maximum storage size is enormous. In practice, ZFS manages petabyte-scale storage pools without issues. Enterprise storage systems built on ZFS can easily manage dozens of drives in a single pool.

Btrfs also scales well, but less predictably. It is comfortable with multi-terabyte volumes and works fine on home NAS setups with up to a dozen drives or so. Beyond that, Btrfs is less proven. There are fewer Btrfs implementations at true enterprise scale, and its RAID limitations hold it back in larger setups.

Storage pool vs filesystem approach

One of the biggest differences between the two is how they manage multiple disks.

 

Figure 3. ZFS gives you an explicit pool layer, while Btrfs collapses the pool into the filesystem and uses subvolumes for organization.

 

ZFS uses storage pools, called zpools. You add disks to a pool, and the pool presents itself as one giant storage resource. From there, you create datasets and volumes on top of the pool. You can add more disks later, create as many datasets as you want, and apply different settings (compression, quotas, snapshots) to each dataset.

Btrfs manages everything at the filesystem level. You do not really have pools like in ZFS. Instead, a Btrfs filesystem can span multiple devices, and you use subvolumes to organize them. Subvolumes are lightweight and flexible, but the overall arrangement feels more improvised compared to the clean separation you get with ZFS zpools.

For someone just getting started, the Btrfs approach is probably simpler. For anyone managing large storage, the ZFS pool architecture is better in the long run.

Data integrity and reliability

If there is one area where these file systems show their strengs, it is data integrity. Both use checksums to detect corruption, and both can repair damaged data, but they do it in different ways.

ZFS uses end-to-end checksums. Every block of data and every block of metadata is checksummed. When ZFS reads a block, it verifies the checksum. If something does not match, ZFS knows the data is corrupt. In a redundant setup (mirror or RAID-Z), ZFS then takes a good copy from another drive and replaces the bad one. This is called self-healing, and it happens automatically in the background.

Btrfs also uses checksums, but its self-healing capability depends on the RAID mode. When Btrfs reads a file, it compares the data against its stored checksum. If they do not match, Btrfs knows that the block is corrupt. In RAID 1 and RAID 10, there is a second copy of every block on another drive, so Btrfs can take the good copy and automaticaly overwrite the bad one. In RAID 5 and 6, the story is messier. Btrfs is supposed to use parity data to rebuild the corrupted block, but there are known issues with how it handles parity in certain failure situations. That is why those layouts are still not recommended for production.

Bit rot protection and self-healing

Bit rot is the slow, silent corruption of data on storage media. It eventualy happens to every drive. Without a filesystem that checks its own data, files can degrade in the background for years without anyone noticing. The problem usually appears only when something important fails to open.

 

Figure 4. The self-heal flow looks similar on paper. The differences are in coverage and RAID modes you can trust.

 

ZFS was designed with this problem in mind. It runs regular scrubs. A scrub is a background scan that reads every block, verifies every checksum, and fixes any corruption it finds. If you run ZFS on a mirrored or RAID-Z pool, bit rot is essentially a solved problem. You will read about corruption in the logs, and the filesystem will fix it for you.

Btrfs has the same scrub feature and handles bit rot well on RAID 1 and RAID 10. On single-drive setups, it can detect corruption but cannot repair it (there is no redundant copy available). For most users running redundant setups, Btrfs scrubs are reliable and work as expected.

Quick summary: Both filesystems protect against bit rot far better than ext4 or XFS. ZFS is a little more thorough and polished. Btrfs gets you 90 percent of the way with less complexity.

Ease of use and management

This is where Btrfs and ZFS differ. One is in your kernel and ready to use. The other takes some work to install, but the tools are very good once you have it.

Btrfs is very simple to start with. Every mainstream Linux distribution ships it in the kernel. Fedora and openSUSE use it by default for the root filesystem. To create a Btrfs volume, you just run mkfs.btrfs and mount it. Snapshots are a one-line command. Most of what you need is already there, and the tools follow standard Linux conventions.

ZFS requires more effort to install on Linux. Because of its licensing, ZFS cannot be shipped inside the Linux kernel. You install OpenZFS as a separate package, and on some distributions, you need to rebuild the module when the kernel updates. Once it is installed, the command-line tools are very good. zpool and zfs are among the best-designed storage commands in any operating system.

Administrative complexity

Managing storage at scale is always a challenge. Here is how the two filesystems compare in day-to-day tasks:

 

Task	Btrfs	ZFS
Create filesystem	One command (mkfs.btrfs)	Two commands (zpool create + zfs create)
Take a snapshot	btrfs subvolume snapshot	zfs snapshot
Send to another host	btrfs send | btrfs receive	zfs send | zfs receive (more features)
Add disk to pool	btrfs device add	zpool add
Replace failed disk	btrfs replace	zpool replace
Monitoring	btrfs scrub status, dmesg	zpool status (cleaner output)
Learning curve	Gentle	Steeper but well documented

 

ZFS has a reputation for complexity, but that reputation is somewhat unfair. The tools themselves are very clean. For example, zpool status gives you an immediate health snapshot of your entire storage setup. The complexity mainly comes from the concepts (pools, vdevs, datasets, volumes), rather than the commands themselves.

Btrfs is simpler on the surface, but it can become confusing when something goes wrong. Error messages are often unclear, and recovery tools are less mature. For most day-to-day use, Btrfs is easier. For debugging a failing array, ZFS provides clearer and more informative results.

Use cases: When to choose Btrfs or ZFS

After all this discussion, the real question is: which one should you actually use? The answer depends on what you are building.

Choose Btrfs if you want the following:

• A simple snapshot for your desktop or laptop. It integrates well with tools like Snapper and Timeshift, giving you easy rollback after bad updates.
• A standard Linux distribution without dealing with external modules or extra packages.
• Lightweight filesystem management on a modest server with limited RAM.
• A small to medium-sized NAS with RAID 1 or RAID 10.
• Subvolumes for organizing container storage, VM images, or development branches.

Choose ZFS if:

• You need maximum data integrity. It is a gold standard for protecting data against silent corruption.
• You run an enterprise or large-scale storage environment where downtime is not an option.
• You require advanced RAID and want to trust your parity RAID.
• You are building a backup server or a replication target. ZFS send/receive is a good replication tool.
• You run workloads where consistent sequential performance matters more than simplicity.
• You have plenty of RAM and want to take advantage of the ARC cache for faster reads.

There is also a middle ground worth mentioning. Many home labs and NAS appliances use ZFS because the appliance handles the complexity for you. You get the benefits of ZFS without having to manage it all manually.

Challenges and limitations

Neither filesystem is perfect. Both have real drawbacks that you should understand before committing.

Btrfs has a RAID 5 and RAID 6 problem. For years, these parity layouts had a known issue called the write hole, where a crash during a write could cause data corruption. The Btrfs developers have improved it, but the official project page still warns against using RAID 5 or 6 for important data. If you need parity RAID on Btrfs, most people recommend using it on top of a traditional RAID like mdraid, but this defeats part of its design.

ZFS has a significant memory appetite. The ARC cache will happily consume most of your system RAM if you let it. A common rule is to assign 1 GB of RAM per 1 TB of storage, and that is before enabling deduplication. This is not a problem on a dedicated storage server, but it requires planning.

ZFS also has a licensing issue on Linux. It is released under the CDDL, which is not compatible with the GPL license that governs the Linux kernel. As a result, ZFS cannot be shipped as part of the kernel. You have to install OpenZFS separately and rely on your distribution to keep it up to date as the kernel evolves. This is mostly a paperwork problem, but it creates some friction.

Known issues and trade-offs

These are not deal-breakers, but they are practical limitations that tend to surface once you move beyond basic setups:

• ARC memory overhead: The ARC is a key reason ZFS performs well, but it also means ZFS does not perform in the same way on memory-limited systems. You can limit ARC size through kernel parameters, but doing so sacrifices some of the performance benefits. On a machine with 8 GB of RAM running a lot of other software, this can be annoying.
• Kernel integration: Because ZFS lives outside the Linux kernel, it can lags behind new kernel releases. If you run a bleeding-edge distribution, you may occasionally end up with a kernel that OpenZFS has not caught up to yet. Stable distributions like Ubuntu LTS or Debian handle this better.
• Btrfs recovery tools: When a Btrfs filesystem goes bad, recovery can be painful. The tools exist, but they are less polished than ZFS tools, and the community knowledge base is smaller. Maintaining good backups is very important with Btrfs.
• Shrinking a zpool: ZFS does not allow easy shrinking of a storage pool. You can add drives, but removing them from most vdev types is either impossible or very limited.

Future of Btrfs and ZFS

Both are actively developed and have strong communities behind them, but they are heading in slightly different directions.

ZFS is going deeper. OpenZFS keeps adding enterprise features – persistent L2ARC, improved encryption, raw encrypted send/receive, better support for high-performance NVMe setups. TrueNAS, Proxmox, and other storage platforms rely on ZFS, which means continued investment and refinement. ZFS is not going anywhere in enterprise segment of the market.

Btrfs is going broader. Major distributions keep adopting it. openSUSE made Btrfs the default years ago. Fedora switched to Btrfs as the default for its workstation edition in 2020. Ubuntu has been steadily expanding its support. Development effort focuses on stability, performance, and eventually fixing the RAID 5/6 issues. Btrfs is becoming the default modern filesystem for Linux desktops.

Conclusion

So which one is better? The honest answer is: neither. They are built for different jobs.

ZFS is the right choice when reliability and “enterprise-grade” is the hard requirement. If you are managing a big server, running databases under heavy load, or just want the most robust filesystem money can buy (well, download), ZFS is your choice. Complexity is real, RAM appetite is real, but the payoff is a storage system that takes care of your data better than almost anything else.

Btrfs is the right choice when flexibility and ease of use matter more. For Linux desktops, home servers, and anywhere you want modern filesystem features without the operational overhead, Btrfs does the job. It is already in your kernel, works with standard Linux tools, and gives you all necessary tools with almost no setup.

Both filesystems are far ahead of the old standards like ext4 in terms of what they can do. Whichever one you choose, you are in a good company. The key is to pick the one that fits your workload, your hardware, and your operational comfort level. That is what actually makes the difference.

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

What’s new, updated, or recently released in Microsoft Security

New capabilities in Microsoft Agent 365; new Microsoft Defender and GitHub integration

At Microsoft, security innovations are purpose-built to help every organization protect end-to-end with the speed and scale of AI. Our vision is simple: security should be ambient and autonomous, just like the AI it protects.

In a world where AI agents can act autonomously to take action, access data, and interact across systems, every organization should have the confidence that their security posture can scale and keep pace with their AI investments. Microsoft is focused on helping organizations gain visibility into what their agents are doing, governance over what they’re allowed to do, and protection against emerging threats. With an AI-first, end-to-end security platform grounded in Zero Trust for AI, fueled by more than 100 trillion daily threat signals¹, and shaped by the Secure Future Initiative, security and IT teams can harden their security posture with protection that is continuous, intelligent, and built for the agentic era.

In the Loop is a new series from Microsoft Security that delivers timely news and updates to the global security community. Today’s edition spotlights the latest capabilities designed to help security and IT teams secure their AI agents, secure their foundations, and defend against threats in real time with the powerful combination of agents and experts.

New Microsoft Defender capabilities in Agent 365 tooling gateway

Detect, block, and investigate threats to AI agents

Get started ↗

The Agent 365 tooling gateway gives security teams the visibility and control they need to detect and respond to threats that target agentic workflows. New Microsoft Defender capabilities, now available in preview, enable security teams to detect, block and investigate anomalous behavior of their agents. Near real-time protection leverages webhooks to evaluate the actions an AI agent attempts to detect and block malicious or risky activities before they’re executed. Read more and get started.

AI-powered Defender and GitHub solution helps protect from code to runtime

GitHub Advanced Security integration

Learn more ↗

Microsoft Defender for Cloud integration with GitHub Advanced Security, now generally available, provides unified security visibility across the development lifecycle. This integration automatically maps code changes to production environments, prioritizes security alerts based on real runtime context, and enables coordinated remediation workflows between development and security teams. Teams can track vulnerabilities from source code to deployed applications, focus on the security issues that affect production workloads, and take advantage of AI-powered remediation tools to speed resolution.² Get started today and watch the video.

New demo: Run a data security investigation in Microsoft Purview

Data Security Investigations

Get started ↗

Step into the role of a data security analyst and see how Microsoft Purview Data Security Investigations helps you identify investigation‑relevant data, analyze it using AI‑powered deep content analysis, and mitigate sensitive data risks—all within a single, integrated solution. Follow the end‑to‑end investigation journey in this hands‑on demo.

In the demo, you’ll learn how to:

• Proactively assess data security risk across your data estate.
• Reactively investigate data involved in security incidents, such as breaches, leaks, fraud, or bribery.
• Visualize risk using the data risk graph, which shows correlations between sensitive content, users, and activities.

Stay In the Loop

Microsoft Security continually ships meaningful innovations across our portfolio and research-driven insights and reports for the security community. In the Loop posts are your reliable source of what’s new across Microsoft Security and what it means for your security strategy. Check back for the next drop and connect with us at Microsoft Build, June 2-3, 2026 in San Francisco, to hear directly from Microsoft Security experts, learn more about today’s releases, and more.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

---

¹Microsoft Digital Defense Report 2025, Safeguarding Trust in the AI Era

²GitHub Advanced Security Integration with Microsoft Defender for Cloud, Microsoft Defender for Cloud | Microsoft Learn

The post What’s new, updated, or recently released in Microsoft Security appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/Ib8O2Wm
via IFTTT

From Security Blocked to Prod Ready: ClickHouse on Docker Hardened Images

In November 2025, a team self-hosting Langfuse, an open-source LLM observability platform, on Kubernetes uploaded their ClickHouse image to AWS ECR as part of their production preparation. They found that the pipeline scanner had returned three critical vulnerabilities – not in ClickHouse, but in the base image. Their security team saw the findings and blocked the deployment before it ever reached production.

“Our security team is not allowing us to take it to production. Please suggest alternatives.“

vinaygoel586

GitHub Issue #286, November 28, 2025

If you’ve shipped containers into an enterprise environment recently, this situation will sound familiar. A perfectly functional deployment gets blocked not because something is broken, but because a scanner found CVEs in packages the application never even touches. A day goes into investigating the findings, a risk exception gets written up, and the security team rejects it anyway, because the vulnerabilities are technically real even if they’re practically irrelevant to your workload.

This post is about how Docker Hardened Images (DHI) gets you unstuck, when a security team blocks the deployment of a container that has CVEs. In this case we will specifically look at the image for ClickHouse, one of the most widely pulled database images on Docker Hub.

A Quick Word on ClickHouse

ClickHouse is an open-source columnar database built for analytical workloads at scale. It is capable of querying billions of rows and returning results in milliseconds in a way that traditional row-oriented databases simply can’t match. Companies such as Cloudflare, Uber, and Spotify all run it in production. With over 100 million pulls from Docker Hub, it has become the default infrastructure choice for teams that need serious analytics throughput. The image’s default security posture, though, was designed with developer ease-of-use in mind rather than the hardening that enterprise production environments demand and that gap is where the trouble starts.

Figure: The layered architecture of ClickHouse

How ClickHouse is Structured

ClickHouse follows a layered architecture. It is designed for analytical speed at scale. SQL queries arrive over HTTP (port 8123) or TCP (port 9000), then pass through the optimizer which parses into an abstract syntax tree and prunes it before the pipeline executor picks it up and hands the work off to parallel threads. Beneath the query layer sits the MergeTree storage engine, the heart of ClickHouse which stores data in columnar .bin files. It uses a sparse primary index to skip irrelevant granules without reading entire columns, and runs background merge processes to compact parts and maintain query performance over time. 

At the bottom, storage is pluggable: local disk, S3, HDFS, or Azure Blob, with tiered hot/warm/cold policies to balance cost and latency. In distributed deployments, ClickHouse Keeper (or ZooKeeper) coordinates replication across replicas, while sharding splits data horizontally across nodes allowing the cluster to scale reads and writes independently. The result is a database that processes hundreds of millions of rows per second per server, making it the default choice for teams running serious analytics workloads.

The Real Problem: It’s Not ClickHouse, It’s the Packaging

The standard clickhouse/clickhouse-server image is built on a full Ubuntu 22.04 base. The base ships with a lot of things ClickHouse doesn’t need such as Perl, system utilities, apt itself, and dozens of transitive dependencies that exist in the image simply because Ubuntu brought outdated package along and in many cases, Ubuntu maintainers decide to not backport fixes from upstream.

ClickHouse doesn’t use most of those system utilities. But the CVEs in those packages are real. They show up in Trivy, Grype, and AWS ECR has no way to distinguish a vulnerable library that’s never loaded from one that’s actively running in production. Your security team sees critical findings and blocks the deployment, which is the correct thing for them to do given what the scanner is telling them.

The instinct at this point is to argue the case, documenting why each CVE doesn’t apply to your workload, writing risk exceptions and escalating, but that’s a slow process. The only real fix is to remove those unnecessary packages entirely. That’s what Docker Hardened Images do.

What DHI Actually Changes

Docker Hardened Images for ClickHouse are built around a straightforward question: what does the database actually need to run? Rather than starting from a full Ubuntu base and hoping the CVE count stays manageable, DHI ships only what ClickHouse requires and leaves everything else out.

The most immediate consequence of that is the absence of apt at runtime. Without a package manager, an attacker who gains a foothold in the container has no obvious path to installing tools or establishing persistence. Network utilities like curl and wget are gone for the same reason, the standard clickhouse/clickhouse-server image has been carrying wget with CVE-2021-31879 unpatched since 2021 because there is no upstream fix as noted by the Ubuntu maintainer, a vulnerability in a tool ClickHouse never needed in the first place. DHI doesn’t patch it; it simply doesn’t include wget at all. A shell is still available for operational work, but without the package manager and network tools, there’s very little an attacker can actually do with it.

To make this practical across different stages of a pipeline, DHI ships two variants. The development image (dev) includes additional tooling that makes local testing and debugging more comfortable. The production image (runtime) strips that back to the absolute minimum, giving you the smallest possible attack surface for the workload that actually faces the world. The intent is that teams adopt the dev variant early in the pipeline and promote the hardened production image through to deployment, rather than discovering the differences at the point where it matters most.

The image also runs as a non-root user uid=65532 out of the box, with no additional Dockerfile configuration required. On the provenance side, every DHI image ships with SLSA Level 3 attestation, which provides cryptographic proof of exactly what went into the build and how it was produced. Docker’s security team actively tracks and patches CVEs, and the presence of 2026 CVE IDs in DHI’s findings is evidence of that remediation happening ahead of public disclosure feeds rather than in response to them.

Getting Started

Before you can pull a DHI image, you need to mirror it to your organization’s namespace on Docker Hub. This is a one-time setup per image not per tag and it means all future updates flow to your namespace automatically.

1. Log in to Docker Hub and open the DHI catalog
2. Find clickhouse-server and select Mirror to repository
3. Follow the on-screen instructions
4. Authenticate locally: docker login dhi.io

Once that’s done, you’re pulling from your own namespace with the same image, same tags, same ClickHouse – just hardened.

Your first DHI ClickHouse container

docker run --name my-clickhouse-server -d \
  --ulimit nofile=262144:262144 \
 dhi.io/clickhouse-server:26.2-debian13

The --ulimit nofile=262144:262144 flag is a ClickHouse requirement, not a DHI one – ClickHouse needs high file descriptor limits to operate correctly. Keep it in all your run commands.

Verify it started:

docker exec my-clickhouse-server clickhouse-client \
  --query "SELECT 'Hello from DHI ClickHouse!'"

Production setup with persistent storage

For anything beyond local testing, you want volumes and a password:

docker run -d \
  --name my-clickhouse-server \
  --ulimit nofile=262144:262144 \
  -e CLICKHOUSE_PASSWORD=mysecretpassword \
  -v clickhouse-data:/var/lib/clickhouse \
  -v clickhouse-logs:/var/log/clickhouse-server \
  -p 8123:8123 -p 9000:9000 \
  dhi.io/clickhouse-server:26.2-debian13

Note that CLICKHOUSE_PASSWORD is required if you want to access ClickHouse over the network. DHI disables unauthenticated network access by default which is the right call for any production deployment.

Test it over HTTP:

curl "http://localhost:8123/?query=SELECT%20version()&user=default&password=mysecretpassword"

Custom configuration

If you’re already running ClickHouse with custom XML config, nothing changes. Same format, same mount path:

cat > custom-config.xml << EOF
<clickhouse>
    <logger>
        <level>information</level>
        <console>true</console>
    </logger>
    <listen_host>0.0.0.0</listen_host>
</clickhouse>
EOF

docker run -d \
  --name my-clickhouse-server \
  --ulimit nofile=262144:262144 \
  -v $(pwd)/custom-config.xml:/etc/clickhouse-server/config.d/custom.xml:ro \
  -p 8123:8123 -p 9000:9000 \
  dhi.io/clickhouse-server:26.2-debian13

Running DHI ClickHouse on Kubernetes

For Kubernetes, there’s one important addition to your pod spec. Since DHI runs as a non-root user, you need to set fsGroup to ensure your persistent volume data is accessible:

spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 65532     # DHI nonroot user
        fsGroup: 65532       # makes mounted volumes accessible to the nonroot user
      containers:
      - name: clickhouse-server
        image: dhi.io/clickhouse-server:26.2-debian13
        ports:
        - containerPort: 8123
        - containerPort: 9000
        volumeMounts:
        - name: clickhouse-data
          mountPath: /var/lib/clickhouse
        - name: clickhouse-logs
          mountPath: /var/log/clickhouse-server
        resources:
          limits:
            cpu: "2"
            memory: "4Gi"

One thing worth mentioning: ClickHouse’s default ports 8123 and 9000 are above the 1024 privileged port boundary, so running as nonroot doesn’t cause any port binding issues.

The metrics exporter

If you’re running ClickHouse on Kubernetes and need Prometheus metrics, Docker also ships clickhouse-metrics-exporter – a hardened image that works with the ClickHouse Operator to expose a /metrics endpoint. It’s 65% smaller than the standard exporter (10.3 MB vs 29.4 MB) and has 75% fewer layers (5 vs 20). Same data, dramatically smaller surface.

containers:
- name: metrics-exporter
  image: dhi.io/clickhouse-metrics-exporter:0-debian13
  ports:
  - name: metrics
    containerPort: 8888
  resources:
    limits:
      cpu: 100m
      memory: 128Mi
    requests:
      cpu: 50m
      memory: 64Mi

Debugging without the usual tools

The debugging story is simpler than it might seem. docker debug attaches an ephemeral layer to the running container that includes bash, curl, strace, vim, and anything else you need without modifying the production image itself. When you exit, the layer disappears and the container is exactly as it was. It’s a cleaner approach than shelling directly into a production container, and in practice it’s a single command:

docker debug my-clickhouse-server

Or if you prefer, you can mount a debug image alongside the container:

docker run --rm -it --pid container:my-clickhouse-server \
  --mount=type=image,source=<your-namespace>/dhi-busybox,destination=/dbg,ro \
  dhi.io/clickhouse-server:26.2-debian13 /dbg/bin/sh

There’s also a broader security benefit that goes beyond CVE counts. If something does go wrong in production, an attacker who gets into the container finds no package manager to install tools with, no curl or wget to exfiltrate data through, and no obvious path to reach out to the network which significantly limits what a compromise can actually turn into.

ClickHouse: Non-hardened Image vs. Hardened Image Compared

A Docker Scout scan of both images puts the difference in plain numbers. Using ubuntu:22.04 as its base, the standard image carries 8 medium and 11 low severity vulnerabilities across 111 packages, including the wget and tar findings that are most likely to trigger a security block in an enterprise pipeline. The DHI image eliminates all medium severity findings entirely and comes in at 14 low severity items but these are in core system libraries like glibc and openssl where no fix exists on any distribution, not in unnecessary utilities that had no business being in the image. The 3 unconfirmed findings that Scout surfaces have already been assessed and suppressed via VEX attestation, which ships with the image as part of its SLSA Level 3 provenance

To view the difference between versions for any other image, you can run your own scan with Docker Scout for a quick comparison using this command:

docker scout quickview clickhouse/clickhouse-server:latest

docker pull dhi.io/clickhouse-server:26.2-debian13
docker tag dhi.io/clickhouse-server:26.2-debian13 clickhouse-dhi:latest
docker scout quickview clickhouse-dhi:latest

	Non-Hardened  ClickHouse Image	Docker Hardened Image
Default user	root (steps down to clickhouse user at runtime via entrypoint, but Dockerfile has no USER directive overridable with CLICKHOUSE_RUN_AS_ROOT=1)	nonroot (enforced at image level via USER directive cannot be overridden at runtime)
Shell access	Full shell (bash/sh) available	bash present, no network tools or package manager
Package manager	apt available	No package manager
CVE exposure	Ships wget (CVE-2021-31879, unpatched since 2021), tar (CVE-2025-45582)	No wget, no tar – unnecessary packages removed entirely
CVE patching	Unpatched findings from 2021–2025 due to the lack of upstream fixes from Ubuntu base image.	Actively tracked, 2026 CVE IDs show proactive remediation
Provenance	Standard	SLSA Level 3 attestation
Compliance	Manual hardening required	CIS, NIST, FedRAMP-aligned
Debugging	Traditional shell debugging	Use docker debug or Image Mount for troubleshooting

The Security Team Conversation

The team that got blocked at AWS ECR in November 2025 didn’t have a ClickHouse problem, they had a base image problem. Their database was fine; what the scanner was finding were CVEs in Perl, system utilities, and other packages that had come along in the Debian base and never used by the application. Nothing in the scanner output made that distinction, so the security team did exactly what they were supposed to do and blocked the deployment.

With DHI, that conversation with your security team becomes considerably more straightforward. Rather than building a case for why specific CVEs don’t apply to your workload, you can point to an image built by Docker’s security team from the minimum required components, with SLSA Level 3 provenance and independent validation by SRLabs. The ClickHouse runtime itself is unchanged ~ queries, ports, configuration files, and performance all carry over so the only thing you’re actually changing is the answer you can give when someone asks whether this image can go to production.For teams that need stronger guarantees, DHI Enterprise adds SLA-backed CVE remediation within seven days, FIPS and STIG variants, and extended lifecycle support. For most teams, the free Enterprise trial is the right starting point. It answers the question that actually matters before you commit to anything. Interested to learn further? Start with this blog that walks through the trial and sets you up for success.

Migration Checklist

☐ Mirror clickhouse-server DHI image to your Docker Hub namespace (one-time setup)
☐ Update your image reference to dhi.io/clickhouse-server:26.2-debian13
☐ Set CLICKHOUSE_PASSWORD (required for network access in DHI)
☐ Keep --ulimit nofile=262144:262144 on all run commands
☐ In Kubernetes: add fsGroup: 65532 to your pod securityContext
☐ Switch from kubectl exec to kubectl debug for troubleshooting
☐ Run trivy against both images to see the difference yourself:
     trivy image clickhouse/clickhouse-server:latest
     trivy image dhi.io/clickhouse-server:26.2-debian13

The migration is narrower in scope than it might appear – your volume mounts, port mappings, and existing XML configuration files all carry over without modifications, and on Kubernetes the only structure addition is the fsGroup security context. Everything else is an image reference change.

Resources

• Docker Hardened Images Documentation
• DHI ClickHouse Server Guide
• DHI ClickHouse Metrics Exporter Guide
• Docker Debug Documentation
• Free DHI Catalog
• DHI Community Announcement
• Docker Scout Documentation

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

Email threat landscape: Q1 2026 trends and insights

1. Tycoon2FA disruption impact
2. QR code phishing attacks
3. CAPTCHA tactics
4. Malicious payloads
5. Business email compromise
6. Defending against email threats
7. Microsoft Defender detections

During the first quarter of 2026 (January-March), Microsoft Threat Intelligence detected approximately 8.3 billion email-based phishing threats, with monthly volumes declining slightly from 2.9 billion in January to 2.6 billion in March. By the end of the quarter, QR code phishing emerged as the fastest-growing attack vector, more than doubling over the period, while CAPTCHA-gated phishing evolved rapidly across payload types. Overall, 78% of email threats were link-based, while malicious payloads accounted for 19% of attacks in January—boosted by large HTML and ZIP campaigns—before settling at 13% in both February and March. Credential phishing remained the dominant objective behind malicious payloads throughout the quarter. This shift toward link-based delivery, combined with the payload trends, suggests that threat actors increasingly preferred hosted credential phishing infrastructure over locally-rendered payloads as the quarter progressed.

These trends reflect how threat actors continue to iterate on both scale and delivery techniques to improve effectiveness. At the same time, disruption efforts can meaningfully impact this activity. Following Microsoft’s Digital Crime Unit-led action against the Tycoon2FA phishing-as-a-service (PhaaS) platform in early March, associated email volume declined 15% over the remainder of the month, alongside a significant reduction in access to active phishing pages, limiting the platform’s immediate effectiveness. While Tycoon2FA has since adapted by shifting hosting providers and domain registration patterns, these changes reflect partial recovery rather than full restoration of previous capabilities. Alongside these shifts, business email compromise (BEC) activity remained prevalent, totaling approximately 10.7 million attacks in the quarter, largely driven by low-effort, generic outreach messages. At the same time, Microsoft Defender Research observed early indications of emerging techniques such as device code phishing—sometimes enabled by offerings like EvilTokens—which, while not yet at the scale of the trends discussed below, reflect continued innovation in credential theft methods.

Tycoon2fa ecosystem

Detect, investigate, and disrupt AiTM phishing ›

AI-enabled phishing

Examine device code authentication attacks at scale ›

This blog provides a view of email threat activity across the first quarter of 2026, highlighting key trends in phishing techniques, payload delivery, and threat actor behavior observed by Microsoft Threat Intelligence. We examine shifts in QR code phishing, CAPTCHA evasion tactics, malicious payloads, and BEC activity, analyze how disruption efforts and infrastructure changes influenced threat actor operations, and provide recommendations and Microsoft Defender detections to help mitigate these threats. By bringing these trends together, this blog can help defenders understand how email-based attacks are evolving and where to focus detection, mitigation, and user protection strategies.

Tycoon2FA disruption impact

Since its emergence in August 2023, Tycoon2FA has rapidly become one of the most widespread PhaaS platforms, leveraging adversary-in-the-middle (AiTM) techniques to attempt to defeat non-phishing-resistant multifactor authentication (MFA) defenses. The group behind the PhaaS platform (tracked by Microsoft Threat Intelligence as Storm-1747) leases malicious infrastructure and sells phishing kits that impersonate various enterprise application sign-in pages and incorporate evasion tactics, such as fake CAPTCHA pages.

The quarter began with Tycoon2FA in a period of reduced activity. January volumes represented a 54% decline from December 2025, marking the second consecutive month of sharp decreases. While post-holiday seasonal effects may have contributed to this decrease in volume, some of the reduction might also have been the result of Microsoft’s Digital Crimes Unit disruption of RedVDS, a service used by many Tycoon2FA customers to distribute malicious email campaigns.

Inside RedVDS

Investigate infrastructure, tooling, and attack chains ›

After surging 44% in February, phishing attacks pointing to Tycoon2FA fell 15% in March driven largely by the effects of a coordinated disruption operation. In early March 2026, Microsoft’s Digital Crimes Unit, in coordination with Europol and industry partners, took action to disrupt Tycoon2FA’s infrastructure and operations, significantly impairing the platform’s hosting capabilities. While Tycoon2FA-linked messages continued to circulate after the disruption, almost one-third of March’s total volume was concentrated in a three-day period early in the month; daily volumes for the remainder of March were notably lower than historical averages, and targets’ ability to reach active phishing pages was substantially reduced.

Figure 1. Tycoon2FA monthly malicious messages volume (November 2025 – March 2026)

Tycoon2FA’s infrastructure composition evolved multiple times during the first three months of 2026. In January, Tycoon2FA domains started shifting toward newer generic top-level domains (TLDs) such as .DIGITAL, .BUSINESS, .CONTRACTORS, .CEO, and .COMPANY, moving away from previous commonly used TLDs or second-level domains like .SA.COM, .RU, and .ES. This trend became even more well-established in February. Following the March disruption, however, Microsoft Threat Intelligence observed a notable increase in Tycoon2FA domains with .RU registrations, with more than 41% of all Tycoon2FA domains using a .RU TLD since the last week of March.

Figure 2. Top TLDs and second-level domains (2LDs) associated with Tycoon2FA infrastructure (November 2025 – March 2026)

Additionally, toward the end of March, we saw Tycoon2FA moving away from Cloudflare as a hosting service and now hosts most of its domains across a variety of alternative platforms, suggesting the group is attempting to find replacement services that offer comparable anti-analysis protections.  

QR code phishing attacks

In recent years, QR codes have rapidly emerged as a preferred tool among phishing threat actors seeking to bypass traditional email defenses. By embedding malicious URLs within image-based QR codes in the body of an email or within the contents of an attachment, threat actors attempt to exploit the limitations of text-based scanning engines and redirect victims to phishing sites on unmanaged mobile devices.

The most significant shift in Q1 2026 was the rapid escalation of QR code phishing, with attack volumes increasing from 7.6 million in January to 18.7 million in March, a 146% increase over the quarter. After an initial 35% decline in January (continuing a late-2025 downtrend), volumes reversed course dramatically, growing 59% in February and another 55% in March. By the end of the quarter, QR code phishing had reached its highest monthly volume in at least a year.

Figure 3. Trend of QR code phishing attacks by weekly volume (November 2025 – March 2026)

PDF attachments were the dominant delivery method throughout the quarter, growing from 65% of QR code attacks in January to 70% in March. While the overall volume of DOC/DOCX payloads containing malicious QR codes steadily increased each month, their share of overall delivery payloads decreased from 31% in January to 24% in March. A notable late-quarter development was the emergence of QR codes embedded directly in email bodies, which surged 336% in March. While still a small share of total volume (5%), this approach eliminates the need for an attachment altogether and highlights a shift in threat actor delivery methods that defenders should continue to monitor.

CAPTCHA tactics

Threat actors use CAPTCHA pages to delay detection and increase user interaction. These pages function as a visual decoy, giving the appearance of a legitimate security check while concealing a transition to malicious content. By forcing users to engage with the CAPTCHA before accessing the payload, threat actors reduce the likelihood of automated scanning tools identifying the threat and increase the chances of successful credential harvesting or malware delivery. Additionally, fake CAPTCHAs are used in ClickFix attacks to trick users into copying and executing malicious commands under the guise of human verification, allowing malware to bypass conventional security controls.

After declining in both January (-45%) and February (-8%), CAPTCHA-gated phishing volumes exploded in March, more than doubling (+125%) to 11.9 million attacks, the highest volume observed over the last year.

Figure 4. CAPTCHA-gated phishing volume (November 2025 – March 2026)

The most notable aspect of Q1 CAPTCHA trends was the rapid rotation of delivery methods, as threat actors appeared to actively experiment with which payload formats most effectively evade email defenses:

• HTML attachments started the year as the most common method to deliver CAPTCHA-gated phishing (37% in January), but dropped 34% in February, hitting its lowest monthly volume since August 2025. Although their volume more than doubled in March, hitting an annual monthly high, HTML files were still only the second-most common delivery method to close the quarter.

• SVG files, which had seen consecutive months of decreasing volumes, grew by 49% in February at the same time nearly every other delivery payload type decreased. Because of this, it was the most common delivery method for the month, which had not happened since November 2025. This one-month spike reversed itself in March, however, and the number of SVG files delivering CAPTCHA-gated phish fell by 57%, accounting for just 7% of delivery payloads.
• PDF files saw a meteoric rise in volume during the first quarter of the year. After seeing steady month-over-month declines since July 2025, and hitting an annual monthly low point in January 2026, the number of PDF attachments leading to CAPTCHA-gated phishing sites more than quadrupled in March (+356%). Not only did it retake its spot as the most common delivery method for these attacks since last July, but it eclipsed its annual high by more than 37%.
• DOC/DOCX files, which didn’t make up more than 9% of CAPTCHA-gated phishing payloads over the previous nine months, increased almost five times (+373%) in March to account for 15% of payloads.
• Email-embedded URLs, which had once delivered more than half of CAPTCHA-gated phish at the end of August 2025, hit an eight-month low after falling 85% between December and February. While their volume nearly doubled in March, they remained well below late-2025 levels.

Figure 5. Monthly CAPTCHA-gated phishing volume by distribution method (Q1 2026)

Another notable shift in CAPTCHA-gated phishing attacks was the erosion of Tycoon2FA’s impact on the landscape. At the end of 2025, more than three-quarters of CAPTCHA-gated phishing sites were hosted on Tycoon2FA infrastructure. This share decreased significantly over the course of the first three months of 2026, falling to just 41% in March. This broadening of CAPTCHA-gated phishing sites being used by an increasing number of threat actors and phishing kits, combined with the overall surge in volume, indicates that this technique is becoming a more entrenched component of the phishing playbook rather than a specialty of a small number of tools.

Three-day campaign delivers CAPTCHA-gated phishing content using malicious SVG attachments

Between February 23 and February 25, 2026, a large, sustained campaign sent more than 1.2 million messages to users at more than 53,000 organizations in 23 countries. Messages in the campaign included a number of different themes, including an important 401K update, a credit hold warning, a question about a received payment, a payment request for a past due invoice, and a voice message notification.

Many of the messages contained a fake confidentiality disclaimer to enhance the credibility of the messages and provide a proactive excuse about why a recipient may have mistakenly received an email that may not be applicable to them.

Figure 6. Example fake confidentiality message used in February 23-25 phishing campaign

Attached to each message was an SVG file that was named to appropriately match the theme of the email. All the file names included a Base64-encoded version of the recipient’s email address. Example of file names used in the campaign include the following:

• <Recipient Email Domain>_statements_inv_<Base64-encoded Email Address>.svg
• 401K_copy_<Recipient Name>_<Base64-encoded Email Address>_241.svg
• Check_2408_Payment_Copy_<Recipient First Name>_<Base64-encoded Email Address>_241.svg
• INV#_1709612175_<Base64-encoded Email Address>.svg
• Listen_(<Base64-encoded Email Address>).svg
• PLAY_AUDIO_MESSAGE__<Recipient Name>_<Base64-encoded Email Address>_241.svg

If an attached SVG file was opened, the user’s browser would open locally and fetch content from one of the three following hostnames:

• bouleversement.niovapahrm[.]com
• haematogenesis.hvishay[.]com
• ubiquitarianism.drilto[.]com

Initially, the user would be shown a “security check” CAPTCHA. Once the CAPTCHA had been successfully completed, the user would then be shown a fake sign-in page used to compromise their account credentials.

Malicious payloads

Credential phishing tightened its grip on the malicious payload landscape across Q1, growing from 89% of all payload-based attacks in January to 95% in February before settling at 94% in March. These credential phishing payloads either linked users to phishing pages or locally loaded spoofed sign-in screens on a user’s device. Traditional malware delivery continued its long-term decline, representing just 5–6% of payloads by the end of the quarter.

Figure 7. Malicious payloads by file type (Q1 2026)

The most striking payload trend was the volatility across file types, driven by large campaigns that created dramatic week-to-week swings:

• HTML attachments started Q1 as the leading file type (37% of payloads in January), fell to an annual low in February (-57%), then nearly tripled in March (+175%). This volatility was largely campaign-driven, with concentrated activity in the first half of January and the third week of March.
• Malicious PDFs followed a steady upward trajectory, increasing 38% in February and another 50% in March to reach their highest monthly volume in over a year. By March, PDFs accounted for 29% of payloads, up from 19% in January.
• ZIP/GZIP attachments were similarly volatile by nearly doubling in January (+94%), dropping 38% in February, then surging 79% in March. Threat actors commonly use ZIP files to circumvent Mark of the Web (MOTW) protections.
• SVG files emerged briefly in February as a notable delivery method (with a 50% volume increase) before declining 32% in March, mirroring the pattern seen in CAPTCHA-gated phishing.

Figure 8. Daily malicious payload file type (Q1 2026)

Large-scale HTML phishing campaign hosts content on multiple PhaaS infrastructures

On March 17, 2026, Microsoft Threat Intelligence observed a massive phishing campaign that drove a significant surge in malicious HTML attachments during the month. The campaign involved more than 1.5 million confirmed malicious messages sent to over 179,000 organizations across 43 countries, accounting for approximately 7% of all malicious HTML attachments observed in March.

All messages in this campaign were likely sent using the same tool or service, which exhibited several distinct and highly consistent characteristics. Most notably, sender addresses across the campaign featured excessively long, keyword‑stuffed usernames that embedded URLs, tracking identifiers, and service references. These usernames were crafted to resemble legitimate transactional, billing, or document‑related notification senders. Examples of observed sender usernames include:

• eReceipt_Payment_Alert_Noreply-/m939k6d7.r.us-west-2.awstrack.me/L0/%2F%2Fspectrumbusiness.net%2Fbilling%2F/2/010101989f2c1f29-ab5789bd-1426-4800-ae7d-877ea7f61d24-000000/LHnBIXX0VmCLVoXwNWtt23hGCdc=439/us02web.zoom.nl/j/81163775943?pwd=bLoo4JaWavsiTAuLWNoRsmbmALwjLB.1-qq8m2tzd
• Center-=AAP1eU7NKykAABXNznVa8w___listenerId=AAP1eU7NKykAABXNznVa8w___aw_0_device.player_name=Chrome___aw_0_ivt.result=unknown___cbs=9901711___aw_0_azn.zposition=%5B%22undefined%22%5D___us_privacy=___aw_0_app.name=Second+Screen___externalClickUrl=otdk-takaki-h
• DocExchange_Noreply-m939k6d7.r.us_west_2.awstrack.me/L0/%2F%2Fspectrumbusiness.net%2Fbilling%2F/2/010101989f2c1f29ab5789bd14264800ae7d877ea7f61d24000000/LHnBIXX0VmCLVoXwNWtt23hGCdc=439/us02web.zoom.nl/j/81163775943?pwd=bLoo4JaWavsiTAuLWNoRsmbmALwjLB.1-angie

The emails themselves contained little to no message body content. While subject lines varied, they consistently impersonated routine business and workflow notifications, including payment and remittance alerts (for example, Automated Clearing House (ACH), Electronic Funds Transfer (EFT), wire), invoice or aging statements, and e‑signature or document delivery requests. These subjects relied on urgency, approval language, and transactional framing to prompt recipients to review, sign, or access an attached document.

Each message included an HTML attachment with a file name aligned to the email’s theme. When opened, the HTML file launched locally on the recipient’s device and immediately redirected the user to an initial external staging page. This page performed basic screening and then redirected the user to a secondary landing page hosting the phishing content. On the final landing page, users were presented with a CAPTCHA challenge before being directed to a fraudulent sign‑in page designed to harvest account credentials.

Interestingly, although messages in this campaign shared common tooling, structure, and delivery characteristics, the infrastructure hosting the final phishing payload was linked to multiple different PhaaS providers. Most observed phishing endpoints were associated with Tycoon2FA, while additional activity was linked to Kratos (formerly Sneaky2FA) and EvilTokens infrastructure.

Business email compromise

Microsoft defines business email compromise (BEC) as a text-based attack targeting enterprise users that impersonates a trusted entity for the purpose of persuading a recipient into initiating a fraudulent financial transaction or sending the threat actor sensitive documents. These attacks fluctuated across Q1, totaling approximately 10.7 million attacks: rising 24% in January, dipping 8% in February, then surging 26% in March.

Figure 9. Monthly BEC attack volume (November 2025 – March 2026)

The composition of BEC attacks remained consistent throughout Q1. Generic outreach messages (like “Are you at your desk?”) accounted for 82–84% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 9–10%. This pattern underscores that BEC operators overwhelmingly favor establishing a conversational rapport before making fraudulent requests, rather than leading with direct financial asks.

Within the smaller subset of explicit financial requests, two sub-categories showed notable movement. Payroll update requests grew 15% in February, reaching their highest volume in eight months, potentially reflecting tax season-related social engineering. Gift card requests fell 37% in February to their lowest level since July before rebounding sharply in March (+108%), though they still represented less than 3% of overall BEC messages. These fluctuations suggest that BEC operators adjust their specific financial pretexts seasonally while maintaining a consistent overall approach.

Figure 10. Initial BEC email content by type (Q1 2026)

Defending against email threats

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

• Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
• Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

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

Microsoft Defender for Endpoint

The following alert might indicate threat activity associated with this threat. The alert, however, can be triggered by unrelated threat activity.

• Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site

Microsoft Defender for Office 365

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• Email reported by user as malware or phish

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following Threat Analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Activity Profile: Email threat landscape, March 2026
• Activity Profile: Email threat landscape, February 2026
• Activity Profile: Email threat landscape, January 2026
• Tool Profile: Tycoon2FA
• Actor Profile: Storm-1747
• Technique Profile: QR code phishing
• Technique Profile: ClickFix technique leverages clipboard to run malicious commands
• Threat Overview Profile: Business Email Compromise
• Threat Overview Profile: Adversary-in-the-middle credential phishing

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

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.

The post Email threat landscape: Q1 2026 trends and insights appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/r5LuCMt
via IFTTT