Trending Topics

Microsoft’s GigaWiper Shows How “All-in-One” Malware Has Become the New Normal

Microsoft has disclosed details on GigaWiper, a Windows backdoor that blends long-term remote access with the ability to destroy data on demand. Here's what it does and what defenders should do about it.

What You Need to Know

GigaWiper shows how far Windows malware has evolved beyond single-purpose tools. It combines surveillance, persistence, and destructive capability in one backdoor, giving attackers quiet long-term access that can be flipped into a data-destroying attack whenever they choose. Microsoft first observed it in destructive attacks in October 2025, and Defender already has detection coverage, but signature-based detection alone isn't enough to catch it early.

What's Vulnerable

GigaWiper isn't a clean-sheet build. Its authors fused code from at least three older malware families into a single backdoor targeting Windows systems, stitching together multiple wiping and sabotage routines behind one remote-access tool. Once it lands on a machine, it sets up a scheduled task disguised as "OneDrive Update" that runs at startup and every minute, using RabbitMQ for command delivery and Redis to return results. That setup gives operators reliable, low-profile control over the compromised system.

From there, attackers can pick from several attack modes. They can wipe partition data and physical disks outright, repeatedly overwrite just the Windows system drive, or run a fake ransomware scenario that encrypts files and appends a .candy extension. Each path is built to leave the device unusable or unrecoverable.

The Details

The destructive phase is optional, and that's what makes GigaWiper particularly dangerous. Attackers can sit quietly in surveillance and remote administration mode for as long as they want before pulling the trigger. Around 20 command codes support this phase, letting operators run PowerShell, harvest system and antivirus details, manipulate processes and services, edit the Registry, capture screenshots, log activity on connected displays, and exfiltrate files. They can even take interactive control through a VNC-like remote desktop capability, after first tweaking Windows Firewall rules to make room for it.

Why This Matters

The gap between initial access and destructive action is the real risk here. A backdoor that can quietly persist for weeks or months before wiping a system means organizations may already be compromised without any obvious signs of damage. By the time the destructive phase kicks in, the attacker has had ample opportunity to map the environment, harvest credentials, and stage further access elsewhere. Waiting for a wipe event to be the first sign of trouble means finding out far too late.

What to Do

Microsoft Defender already includes detection coverage for GigaWiper, but Microsoft's guidance is clear that signature-based detection shouldn't be the only line of defense. Harden endpoints by enabling tamper protection, cloud-delivered protection, and EDR in block mode. Watch closely for suspicious scheduled tasks, especially ones masquerading as routine software updates, along with unusual disk-level operations and changes to Windows recovery settings. Restricting outbound connectivity to known command infrastructure can also cut off the backdoor's ability to phone home before it ever reaches the destructive stage.

Threats like GigaWiper are a reminder that persistence and destruction aren't separate problems anymore, they're two phases of the same attack.

Zimbra’s Critical Web Client XSS Flaw Is a Wake-Up Call for Email Security

Zimbra is telling customers to patch a critical stored cross-site scripting flaw in its Classic Web Client right away. Here's what's going on and what to do about it.

What You Need to Know

This is one of those bugs that turns your inbox into an attack surface the moment you open it. Tracked as CVE-2025-27915, the flaw lets an attacker inject malicious JavaScript that gets stored on the server and runs automatically whenever a victim opens a crafted email, calendar item, or other webmail content. No malware, no attachment, no click required beyond opening a message. Zimbra has patches out now, and organizations running the Classic Web Client should treat this as an emergency update, not a next-maintenance-window item.

What's Vulnerable

The flaw sits in the Classic Web Client interface, which many organizations, including enterprises and public-sector environments, rely on as core communications infrastructure. It comes down to insufficient input sanitization and output encoding, which lets untrusted content flow directly into the page that authenticated users see in their browsers. Once the script lands, it persists until the underlying server is patched or the offending content is removed, which is why this is being treated less like a routine XSS nuisance and more like a long-lived foothold inside user sessions.

In practice, that persistence is what makes it dangerous. An attacker can silently hijack active sessions, steal email data, manipulate messages, or pivot deeper into internal systems, all from a single stored payload sitting quietly until someone opens the wrong item.

Why This Matters

Webmail is exactly the kind of always-open, always-trusted surface that attackers like to abuse, because a single successful injection can sit there working on every user who happens to load the affected content. For organizations that lean on Zimbra as core infrastructure, that means one unpatched server can turn into an ongoing session-hijacking and data-theft problem rather than a one-time incident, especially for internet-facing deployments or mail flows carrying sensitive information.

What to Do

Zimbra has released fixes across supported branches, including 9.0.0 Patch 46, 10.0.15, and 10.1.9, which harden input validation and strengthen content security policies for the Classic client. Test and deploy these as an emergency change, particularly for internet-facing servers or those handling sensitive mail. If immediate patching isn't possible, restrict external exposure where you can, increase monitoring for suspicious webmail behavior, and review logs for signs of script injection or unusual session activity.

A stored XSS in a webmail client isn't just a browser quirk, it's a foothold that waits patiently for the next person to open their inbox.

Forg365 Shows How Telegram Fueled PhaaS Is Supercharging Microsoft 365 Account Takeovers

A new phishing-as-a-service platform called Forg365 is selling industrial-scale Microsoft 365 account hijacking over Telegram. Here's how it works and what defenders need to change because of it.

What You Need to Know

Forg365 packages techniques that once required a well-funded threat actor into a point-and-click subscription. It combines device-code-based phishing with adversary-in-the-middle capabilities, letting customers bypass MFA, capture OAuth tokens, and quietly maintain access to Outlook, Teams, OneDrive, and other Microsoft 365 apps. The service even ships a browser extension that keeps stolen sessions alive after a victim changes their password, which means "MFA is on" is no longer a safe assumption for defending Microsoft 365 identities.

What Happened

Researchers who gained access to the Forg365 backend found a control panel that lets attackers spin up new campaigns, manage phishing links, configure OAuth apps, and plug in SMTP profiles in a few clicks. The platform auto-generates convincing phishing emails using AI to match a target's tone and branding, lowering the skill bar even further for whoever is running the campaign.

The real damage happens after initial compromise. Forg365 manages session cookies and access tokens on behalf of its operators, and it ships a browser extension called ForgCookie that runs quietly in Chrome, Edge, or Brave to refresh Microsoft sign-in cookies in the background. That persistence means an attacker can keep riding along in a victim's cloud account long after passwords are changed, because the stolen tokens and cookies keep the door open regardless.

Forg365's operators also lean on mainstream infrastructure such as Amazon SES for email delivery and Cloudflare Pages for phishing sites. That choice helps campaigns blend into normal cloud traffic and slip past basic filters that are tuned to flag obviously suspicious infrastructure.

Why This Matters

Device code flows, OAuth consent, and session tokens are now the real battlegrounds for Microsoft 365 security, not just passwords and MFA prompts. A platform like Forg365 means an attacker no longer needs deep technical skill to run this kind of campaign, just a Telegram subscription. For organizations, that shifts identity security from a set-and-forget checkbox into a continuous, high-resolution monitoring problem, because the attack techniques that used to be rare and expensive are now available to a much wider pool of operators.

What to Do

Restrict or disable device code authentication where it is not strictly needed, since that flow is core to how Forg365 operates. Tighten Conditional Access policies to reduce what a stolen token or session can actually reach. Mine Microsoft Entra logs for unusual device code activity, OAuth grants, and new sign-ins from suspicious locations, since these are the signals that show up before an account takeover turns into something bigger. Given that Forg365 is built to blend into normal cloud traffic, monitoring needs to focus on behavioral anomalies in identity activity rather than relying on traditional email or malware filtering alone.

Platforms like Forg365 are a reminder that the barrier to a sophisticated Microsoft 365 attack is now a subscription fee, not a skill set.

Wireshark 4.6.7 Tightens the Screws on Dissector Bugs and Crash-to-Exploit Paths

Wireshark 4.6.7 closes a dozen protocol-level vulnerabilities, some of which could go beyond a crash and into code execution. Here's what's fixed and why analysts shouldn't skip this one.

What You Need to Know

This is a quiet release, but not a skippable one. Wireshark 4.6.7 patches 12 vulnerabilities across its dissectors and file parsers, and while most start out as denial-of-service bugs, several carry real code-execution risk when memory corruption is involved. Because Wireshark often runs on analyst workstations with elevated access to sensitive network segments, a flaw like this isn't just an inconvenience, it's a potential pivot point into the defender's own environment.

What's Vulnerable

Over recent cycles, the Wireshark team has been working through issues across its dissectors and file parsers, covering everything from malformed TLS, HTTP, and SMB2 traffic to more niche protocols like ZigBee and Monero, plus specialized capture formats. In each case, a single crafted packet or capture file could bring the application down. Several of the CVEs fixed in the 4.6.x line, including CVE-2026-5402 in the TLS dissector and CVE-2026-5403 in the SBC codec, show how what starts as "just a DoS" bug can, in some cases, escalate toward code execution.

The 4.6.7 update follows earlier 4.6 branch fixes that addressed more than 40 vulnerabilities, including crashes in dissectors for RDP, ICMPv6, MySQL, WebSocket, and GSM RP, along with various audio codecs. Some of the deeper issues sat in Wireshark's decompression pipeline itself, such as CVE-2026-6535 and CVE-2026-6533 in zlib and LZ77 handling. Across all of these, the common thread is the same: if an attacker can get an analyst to open a malicious pcap or inject malformed traffic into a live capture, they can at minimum force a crash and at worst attempt to steer execution through corrupted structures.

Why This Matters

Every capture an analyst opens is untrusted network data by definition, which is exactly why this matters more than a typical tool update. A red team or attacker could plant a specially crafted capture file on a compromised share labeled as "suspicious traffic," wait for an analyst to double-click it, and let an unpatched dissector do the rest. For a tool that sits close to sensitive environments and often runs with elevated privileges, that turns packet analysis itself into a potential entry point rather than just a diagnostic tool.

What to Do

Treat Wireshark 4.6.7 and its recent predecessors as a mandatory update, not an optional one. Schedule the upgrade across analyst laptops and jump hosts, and fold Wireshark into the same regular vulnerability management process used for browsers and VPN clients. Keeping the tool current cuts off the "malicious pcap" attack path before it starts and keeps packet analysis where it belongs, as a window into attacks rather than a new attack surface of its own.

Update: CitrixBleed 2 Shows Why Memory Leaks Make MFA a Speed Bump, Not a Barrier

CitrixBleed 2, tracked as CVE-2025-5777, lets attackers skip authentication entirely by stealing already-validated session tokens straight out of memory. Here's how it works and what needs to happen next.

What You Need to Know

If an attacker can reach the memory of your remote access gateway, your MFA is only as strong as the tokens it leaves behind. CitrixBleed 2 hits Citrix NetScaler ADC and Gateway appliances configured as VPNs or AAA virtual servers, and it is pre-authentication, remotely exploitable, and trivial to automate. That combination means scanning for exposed NetScaler gateways and hammering them with crafted requests quickly turns into a pile of usable, already-authenticated sessions. Citrix has shipped patches, but patching alone won't undo tokens already stolen before the fix went in.

What's Vulnerable

A malformed authentication request against affected NetScaler appliances triggers an out-of-bounds memory read, leaking whatever happens to be sitting on the stack at that moment. That can include live session cookies, MFA-validated tokens, and even administrative credentials. With those tokens in hand, attackers never need to log in as the victim. They simply replay the stolen session and walk straight into internal portals and published apps as a fully authenticated user, and in the logs it looks like a legitimate session just continued a bit longer than usual.

Security researchers and incident responders describe attack chains where adversaries harvest tokens from memory, replay them on cloud servers, and then use that access to reach file shares, desktop sessions, and backend admin consoles sitting behind the Citrix front door. In this model, MFA isn't broken so much as bypassed entirely, because the attacker joins the conversation after the factor check is already complete and the device is already trusted.

Why This Matters

"We have MFA on the VPN" has been a comforting sentence for a long time, and CitrixBleed 2 is a clear example of why that comfort doesn't hold up against remote memory leaks on edge appliances. The vulnerability doesn't need to defeat MFA at all, it just needs to grab the proof that MFA already happened. For any organization relying on NetScaler as a remote access front door, that means the appliance itself becomes the weak link, regardless of how strong the authentication policy behind it looks on paper.

What to Do

Citrix has released fixed builds for supported branches, and customers should upgrade to versions such as 14.1-43.56 or later, along with the corresponding 13.1 releases. Patching is only half the job, though, since stolen session tokens can outlive the vulnerability itself. Kill active ICA and PCoIP sessions, force logouts, and rotate sensitive credentials that may have been exposed. Comb through logs for bursts of malformed authentication requests and unusual reuse of Citrix sessions, since those patterns are the clearest sign that tokens were harvested before the patch went in.

In the age of zero-day memory leaks against edge appliances, MFA on the VPN only means something when it's backed by tight patch discipline, aggressive session hygiene, and continuous monitoring for token abuse across the entire remote access stack.