Intelligence Insights: September 2026

The Bridewell Threat-Led Approach

Bridewell’s managed security services are built upon a proactive, threat-led defence strategy. Moving beyond reactive monitoring, we actively track adversary infrastructure and tradecraft. By seamlessly integrating Cyber Threat Intelligence (CTI), Incident Response (IR), and Managed Detection and Response (MDR), we ensure our clients remain ahead of the evolving threat landscape.

In a landscape defined by rapid adaptation, knowing what is attacking you is just as critical as knowing how. This month’s Threat Insights leverages data from Bridewell’s global MDR and Incident Response engagements to expose the top malicious infrastructure of September 2026. We go beyond the headlines to provide actionable detection guidance on the month's threat insights, equipping your team with the foresight to stay one step ahead.

Top 5 Malicious Infrastructure Threats Tracked

---

Threat Detection Insights - September

Throughout September, our team tracked two developments that between them illustrate how the threat to the endpoint is shifting away from the perimeter and towards the people and tooling that sit behind it.

The first was Mirage Kitten, the Iran-linked espionage group also tracked as UNC1549, Smoke Sandstorm and Nimbus Manticore, which Kaspersky reported on the 1st of September 2026 as having expanded beyond its established native C, C++ and Go implants to deploy two previously undocumented cross-platform remote access trojans, NodeRabbit and PollCat, written in Node.js and obfuscated JavaScript respectively. The delivery mechanism is familiar: fake recruiter personas on LinkedIn and other job platforms send software engineers a time-limited coding challenge hosted on legitimate Amazon S3 storage, in which the projects contain malicious bundled code and, in NodeRabbit's case, a trojanised npm dependency that launches the implant when the project is run.

Confirmed victims were identified in the aviation, aerospace and fintech sectors across Egypt, Ethiopia and Afghanistan, but Kaspersky also observed related archives being submitted to an online multi-scanner from India, Türkiye, Israel, Iraq, Germany and Ireland. This delivery model means the exposure is not limited to the sectors already observed: organisations whose engineers use external recruitment platforms should consider themselves potentially exposed to similar lures.

Mirage Kitten: Trojanised Coding Challenges and Developer-Centric Persistence

Community Detection Opportunities

DeviceNetworkEvents
| where Timestamp >= ago(30d)
| where ActionType has "Listening"
| where LocalIP in ("127.0.0.1", "::1")
| where LocalPort == 48739 or LocalPort between (41984 .. 46983)
| where InitiatingProcessFileName in~ ("node.exe", "nodew.exe", "IntelDSA.exe", "node")
    or InitiatingProcessCommandLine has_any ("msedge_update.js", "idriver_support.js", "node_modules", ".320697f1")
| project Timestamp, DeviceName, ActionType, LocalIP, LocalPort,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessFolderPath

---

BigDiskBuster: Starving Microsoft Defender of Updates

BigDiskBuster is a proof-of-concept tool published to GitHub on the 19th of September by the researcher known as NightmareEclipse, MSNightmare and Chaotic Eclipse. It is the latest instalment in a dispute that began in April, when the researcher started publishing Windows zero-days and exploit code without prior disclosure. The releases followed a succession of proof-of-concept disclosures, including RoguePlanet in June, LegacyHive in July, ShieldBreak in August and ShieldCrash earlier in September, alongside exploits affecting products from CrowdStrike, Nvidia, Avast and Kaspersky. Several of the earlier Windows bugs have since been patched, and some were exploited in the wild after their public release, which is the main reason BigDiskBuster deserves attention despite being, by the author's own admission, buggy and in need of a rewrite. As of the 28th of September 2026, there is no CVE, Microsoft advisory specifically addressing BigDiskBuster, confirmed patch or vendor workaround. The claim that it works on every supported Windows version has also not been independently tested.

The technique is a local denial of service against Defender's update pipeline rather than a bypass of its detection logic, and it requires code execution on the host. It is a post-compromise defence-evasion tool rather than an entry point. According to analysis of the published proof of concept, BigDiskBuster monitors the system volume for new directories appearing under ProgramData\Microsoft\Windows Defender\Platform and the Definition Updates path, which is where Defender stages platform and security intelligence updates. When one appears, it checks remaining free space and creates a hidden, delete-on-close temporary file under the user's Temp directory sized to consume nearly all of it, spinning up additional worker threads to reclaim any capacity that frees up as the installer modifies or removes files. In parallel it opens MRT.exe, the Malicious Software Removal Tool binary, with restrictive sharing so that other processes cannot obtain write or delete access while the handle is held, potentially interfering with replacement or servicing of MRT.exe, alongside the disk-exhaustion technique used against Defender’s update staging. Once the monitored update directory disappears, the tool treats the update as failed, closes its handles and releases the space, leaving nothing obviously amiss on disk.

The screenshot accompanying the release shows Windows Security reporting a protection definition update failure with error 0x80070643, though that is a generic installer error with many benign causes and cannot on its own be taken as evidence of tampering. The practical result is an endpoint whose Windows Security dashboard reports protection as active while the engine and signatures quietly age, an outcome that is arguably more useful to an intruder than an outright kill because protection can remain enabled while its platform and intelligence content become stale, potentially attracting less immediate attention than the antivirus service being disabled outright.

Defensively, BigDiskBuster is noisy in ways that tamper protection alone will not catch, so the value lies in correlating signals that are each individually unremarkable. Free space on the system drive collapsing to near zero and then recovering within minutes, coinciding with a Defender update attempt, is the primary indicator, and endpoint telemetry that records hidden file creation in user Temp directories with unusually large allocations should be alerted on. Persistent open handles to MRT.exe from a non-Microsoft process are a second, and repeated Defender update failures, or simply the absence of successes, are a third. Microsoft logs signature update outcomes to the Microsoft-Windows-Windows Defender/Operational channel, where Event ID 2000 records a successful security intelligence update, so a fleet-wide hunt for hosts that have not logged Event ID 2000 within the organisation’s expected update interval can identify potentially stale protection.

A 24-hour threshold may be appropriate for frequently connected endpoints but should be adjusted for the organisation’s update cadence and intermittently connected devices. Organisations should also compare reported engine and signature versions against the current release through their management tooling rather than trusting the endpoint's own health status and treat any host that has silently fallen behind as a candidate for investigation rather than a servicing ticket. Where a host is confirmed affected, responders should preserve process and file-handle telemetry before terminating the process, recover disk capacity, force a trusted update via Windows Update, WSUS or MpCmdRun.exe -SignatureUpdate, and then, because the tool has no initial access capability of its own, work backwards to establish how the code came to be running in the first place. Given the researcher's stated intention to continue publishing and the track record of post-release exploitation, this is a detection that should be built and tested ahead of any confirmed abuse rather than in response to it.

Community Detection Opportunities

MDE_DeviceFile_BigDiskBuster_Correlate_Code-Derived_temp_File_Behaviour_with_Defender_Failures - Correlate code-derived temp-file behaviour with Defender failures.

let HuntStart = ago(14d);
let GuidFileName =
    @"^\{[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}\}$";

let SuspiciousTempActivity =
    DeviceFileEvents
    | where Timestamp >= HuntStart
    | where FolderPath endswith @"\Temp"
        or FolderPath contains @"\Temp\"
    | where FileName matches regex GuidFileName
    | extend Host = tolower(tostring(split(DeviceName, ".")[0]))
    | summarize
        TempFirstSeen = min(Timestamp),
        TempLastSeen = max(Timestamp),
        TempEventCount = count(),
        UniqueGuidFiles = dcount(FileName),
        GuidFiles = make_set(FileName, 20),
        FileActions = make_set(ActionType, 20)
        by
            Host,
            DeviceName,
            InitiatingProcessAccountName,
            InitiatingProcessFileName,
            InitiatingProcessFolderPath,
            InitiatingProcessCommandLine,
            InitiatingProcessId,
            InitiatingProcessCreationTime,
            InitiatingProcessSHA1;

let DefenderUpdateFailures =
    WindowsEvent
    | where TimeGenerated >= HuntStart
    | where Provider == "Microsoft-Windows-Windows Defender"
    | where EventID in (2001, 2003, 2006)
    | extend Host = tolower(tostring(split(Computer, ".")[0]))
    | project
        Host,
        DefenderFailureTime = TimeGenerated,
        Computer,
        EventID,
        EventData;

SuspiciousTempActivity
| join kind=inner DefenderUpdateFailures on Host
| where DefenderFailureTime between
    (TempFirstSeen - 5m .. TempLastSeen + 15m)
| project
    DefenderFailureTime,
    DeviceName,
    EventID,
    TempFirstSeen,
    TempLastSeen,
    TempEventCount,
    UniqueGuidFiles,
    GuidFiles,
    FileActions,
    InitiatingProcessAccountName,
    InitiatingProcessFileName,
    InitiatingProcessFolderPath,
    InitiatingProcessCommandLine,
    InitiatingProcessId,
    InitiatingProcessSHA1,
    EventData
| order by DefenderFailureTime desc

---

Bridewell CSIRT Detection Rules & Analytics