DisableDefender.ps1 is a PowerShell script that switches off Windows Defender's core protections, clearing the way for attackers to steal credentials and run malicious tools without triggering alerts. Huntress recovered it as part of a larger batch file, i.bat, during an incident it responded to on June 7.

The important thing to understand is that this is not a flaw in Windows itself. It's a post-exploitation tool - something attackers run after they've already broken into a server. The break-in happens elsewhere.

In this case, the entry point was a set of Adobe ColdFusion vulnerabilities. Historical logs pointed to exploitation attempts against three known bugs:

• CVE-2023-26360 - a critical remote code execution flaw that lets an attacker run their own code on the server
• CVE-2023-29298 - an improper access control bug that opens up restricted ColdFusion admin paths
• CVE-2023-29300 - a deserialization flaw

Once attackers used those CVEs to plant a webshell (a hidden script that gives them command execution through the web server), they ran the Defender-disabling script to remove the one control most likely to catch what came next. The script turns off real-time monitoring, behavior monitoring, script scanning, and sample submission, then adds exclusions so certain folders and file types are ignored entirely.

Why this matters to your business: Defender is often the last automated line watching an already-compromised server. With it silenced, the attackers in this incident moved on to dumping credentials using a Mimikatz driver - a step that would normally set off critical Defender alerts. Stolen credentials let an intruder log in as a legitimate user, which makes follow-on activity far harder to spot.

The takeaway is that patching those ColdFusion CVEs closes the door attackers use to get in and run this script in the first place. If you run ColdFusion servers exposed to the internet, they are the systems most at risk here.

Attack Chain: From Initial Compromise to Defender Disablement

The intrusion started with an unpatched Adobe ColdFusion server. Historical logs pointed to exploitation of three 2023-era ColdFusion bugs: CVE-2023-26360, a critical remote code execution flaw; CVE-2023-29298, an improper access control bug; and CVE-2023-29300, a deserialization flaw. The clearest evidence was a set of known-targeted admin endpoints appearing in the request logs, including /CFIDE/adminapi/_datasource/setdsn.cfm and /CFIDE/adminapi/serverinstance.cfc.

These paths normally sit behind access control. CVE-2023-29298 breaks that control, letting an unauthenticated request reach administrative functions it should never touch. Chained with the RCE and deserialization bugs, that gives an attacker a path from a web request to code running on your server.

The first artifact of that access was an .aspx file dropped into wwwroot\Images — a directory that should hold images, not executable web pages. Huntress caught the tell almost immediately: an OS reconnaissance command (whoami) spawning from w3wp.exe, the IIS worker process. A legitimate web app serves content; it does not enumerate the host.

That file was a steganographic webshell hiding executable code inside what looked like an ordinary image. Each webshell in this campaign carried the same signature strings — a hex-encoded value decoding to ONEPIECE and a second decoding to x_best_911, used as status responses confirming the shell was live. That shared string is a reliable hunt indicator across the whole intrusion.

The window stayed open because remediation was incomplete. The SOC queued the webshell for deletion and handed over a remediation list, but the server went back online before the fixes were applied. The attacker returned three days later, and again after that — each time re-uploading a webshell to a server that was still vulnerable. For a business, this is the practical lesson: half-finished incident response leaves the same door unlocked for the next visit.

The server was put back online twice before remediations were carried out fully, allowing the threat actor to continue the attack across June 7, June 10, and June 11.

On the return visits, the attacker layered in evasion before doing anything noisy. They timestomped the webshell's MAC (modified, accessed, created) metadata to falsify when the file appeared, corrupting the forensic timeline investigators rely on to scope an incident. They then ran registry enumeration against HKEY_LOCAL_MACHINE\SOFTWARE, specifically checking for FileZilla — likely scouting an installed FTP client to move data out later without dropping their own tooling.

The staging payload that pulled all of this together was a batch file, i.bat, recovered from C:\ProgramData\x\ before the attacker could delete it. That directory matters: the same script later added a Defender exclusion for C:\ProgramData\x\ and for files ending in .mdk, carving out a protected workspace where follow-on tools could run unscanned.

Security teams can hunt for these confirmed indicators now:

• Steganographic webshells: UA4fp7R.aspx (SHA256 bd74a00f4d2ec3bf50d13ddf324bb368b2464d547abd0c572ef5e2f77943a920), WRBYTR5750images.aspx (SHA256 f63d293e117cae1d0a6c24359fc1361a9dc48178049cc6491051b09268c8c39c), and 03Fl3i.aspx (SHA256 40859ede262098086962ab00c89f02452aa9941c88c7f4ac002db166179980c6).
• Batch file: C:\ProgramData\x\i.bat (SHA256 94cd18f3f030fcc9b259dc410b17ea72a1f9800ee654f8e0f07a87bb9443b593).
• Additional shells: PHP webshells jT1Ds.php and RG0eQV6.php, plus the ONEPIECE string embedded across all recovered webshells.
• Execution signature: reconnaissance processes such as whoami or net spawning from w3wp.exe under an IIS site directory.

Once i.bat executed, its first substantive action was disabling IIS HTTP logging via appcmd, cutting off the record that would reveal any additional shells POSTed to the server. From there the script moved through Defender configuration changes and credential dumping — the point where a compromised web server becomes a staging platform for stealing credentials and delivering further tooling.

Business and Operational Impact of Disabled Endpoint Protection

When a threat actor turns off Microsoft Defender and kills your logging tools, the technical event is straightforward. The business consequence is that your server spends a period of time with no active antimalware watching it, and no reliable record of what happened during that window.

In this incident, the attacker disabled real-time monitoring, behavior monitoring, script scanning, and sample submission before running Mimikatz to dump credentials to pass.txt and hash.txt. If your endpoint protection is off, credential dumping that would normally trigger a critical alert runs silently.

That silence matters because of what usually comes next. Once Defender is disabled and Sysmon, Filebeat, and third-party agents are stopped, an attacker has an open window to install backdoors, deploy cryptominers, stage ransomware, or move laterally to other machines using the credentials they just stole.

The stolen credentials are the pivot point. The attacker extracted ODBC database credentials stored in plaintext in the Registry and forced Windows to cache plaintext passwords in memory by setting UseLogonCredential to 1. Credentials pulled this way let an attacker log in to other systems as a legitimate user, which means your remaining defenses may see valid logins rather than an intrusion.

Consider what an unmonitored server becomes in your environment:

• A ransomware staging point — with antimalware off and backups potentially in reach, encryption can run before anyone sees an alert.
• A data exfiltration channel — the attacker enumerated the FileZilla FTP client, a ready path for moving stolen data off the host.
• A lateral movement launchpad — dumped hashes and plaintext passwords let the attacker reach domain accounts and other servers.

The forensic cost is separate and often underestimated. This attacker cleared the Security, System, Application, and Setup event logs with wevtutil cl, turned off IIS HTTP logging, and falsified file timestamps on the webshell. When you go to investigate, the evidence you need to scope the breach may no longer exist.

Because logging was disabled early, Huntress could not determine the exact initial access mechanism — a direct example of how log tampering limits your ability to answer basic incident questions.

That gap has real consequences during breach response. If you cannot prove when an intruder arrived, what they touched, or whether data left the building, you cannot confidently tell customers, insurers, or regulators the scope of the event. Notification decisions get made on incomplete information, which tends to widen the assumed blast radius rather than narrow it.

There is a compliance dimension you should account for as well. PCI-DSS, HIPAA, and SOC 2 all expect active endpoint protection and reliable audit logging as controls you maintain continuously. A server that ran for a period with Defender disabled and its event logs cleared is a control failure you would have to document, not merely a malware infection you cleaned up.

Treat disabled endpoint protection as a failed critical control, not a passing technical nuisance. The moment antimalware and logging go dark on a production server, you have lost both your ability to stop the next stage of the attack and your ability to reconstruct what already happened.

Detection and Immediate Response Actions

Start by verifying Windows Defender status on every internet-facing server and endpoint. Open PowerShell as administrator and run Get-MpComputerStatus to confirm real-time protection, behavior monitoring, and antimalware services are active. If RealTimeProtectionEnabled returns False on a system you didn't deliberately configure that way, treat it as a compromise indicator and investigate immediately.

The attack described here bypassed Defender through both cmdlet changes and direct registry edits, so a healthy service state alone isn't enough. Check these keys for tampering:

• HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential — a value of 1 means Windows is caching plaintext passwords in memory, the precursor to credential dumping.
• HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware and the Real-Time Protection subkeys — any value set to 1 indicates deliberate disablement.
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options — look for Debugger entries pointing at ntsd -d under sysmon.exe, filebeat.exe, or SetACL.exe, which silently neutralize logging tools.

In environments Capstone manages, SentinelOne flags the endpoint-protection tampering and process-kill activity described in this attack across managed environments, catching taskkill and sc delete commands aimed at Sysmon, Filebeat, and EDR agents before credential dumping completes.

Detect

Search your web server and application logs for exploitation of the three ColdFusion flaws, CVE-2023-26360, CVE-2023-29298, and CVE-2023-29300. Grep IIS logs for requests to the targeted admin endpoints under /CFIDE/adminapi/, and hunt the wwwroot tree — including image directories — for recently created .aspx and .php files.

Two behavioral signatures matter most. First, any OS reconnaissance command spawning from w3wp.exe, the IIS worker process, points to an active webshell. Second, PowerShell execution referencing the Defender-disabling script recovered in this incident is a high-confidence indicator that a script-based impairment routine ran on the host.

Because the attacker cleared the Security, System, Application, and Setup event logs with

, a suspicious gap or absence of recent log entries is itself evidence worth investigating.

Respond

Where you find Defender disabled and not re-enabled, isolate the system from the network before doing anything else. That contains lateral movement and stops further data staging while you work.

Forensically image any compromised host before you remediate. This attacker deleted generated files, Registry classes for Wscript.shell and Shell.Application, and multiple CLSID keys to break scripting and remediation tooling — so the evidence you need may already be partially destroyed, and a clean image preserves what remains.

• Search all endpoints for the webshell filenames UA4fp7R.aspx and WRBYTR5750images.aspx, plus files matching the recovered IoC hashes.
• Reset credentials for any account exposed while WDigest plaintext caching was active, prioritizing local administrators and service accounts like iis_user.
• Confirm no ODBC connection strings were exported from HKLM\SOFTWARE\ODBC\ODBC.INI; rotate any database credentials stored there in plaintext.

Recover

Patch all three ColdFusion vulnerabilities to the fixed versions in Adobe's advisory before returning any server to service. In this incident the vulnerable server was put back online twice before remediation finished, which let the attacker return and escalate — so verify end-to-end remediation, not just webshell deletion.

Enable Tamper Protection in Windows Defender to block the Set-MpPreference and registry edits this attacker used to switch protection off. Add application control to prevent unsigned PowerShell scripts and unknown binaries like g.com and hs.com from executing, and restore your ModSecurity WAF module and IIS HTTP logging if either was disabled during the intrusion.

Patching and Prevention: Addressing the Root Vulnerabilities

Start by patching the Adobe ColdFusion server that gave the attacker their way in. All three vulnerabilities Huntress tied to this incident — CVE-2023-26360, CVE-2023-29298, and CVE-2023-29300 — were addressed by Adobe in 2023. If your ColdFusion installation predates those fixes, it is exploitable using the exact request patterns seen here against /CFIDE/adminapi/ endpoints.

Here is what each flaw does, so you can gauge urgency against your own environment:

• CVE-2023-26360 — a critical remote code execution flaw. This is the one that lets an attacker run arbitrary code on the server, which is how the initial webshell landed.
• CVE-2023-29298 — an improper access control bug. It lets unauthenticated requests reach administrative .cfm functions that access control should keep out of reach.
• CVE-2023-29300 — a deserialization flaw that provides an additional code execution path.

Apply the version listed in Adobe's security bulletin for your ColdFusion release train (2018, 2021, or 2023). The source does not name a specific Windows build or KB, so confirm the fixed version against the vendor advisory rather than guessing — installing the wrong update leaves the RCE path open.

Patching priority

Patch in order of exposure, not convenience. Take internet-facing ColdFusion, IIS, and any web application server first, because those are the systems an attacker can reach without a foothold. Business-critical servers that hold or connect to credentials — including anything with ODBC data source entries in the registry — come next, since this attacker specifically pulled plaintext ODBC credentials from HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI. Internal-only infrastructure follows once the reachable systems are covered.

Protect Defender from being turned off

Patching closes the front door, but this incident turned on the ability to disable endpoint protection outright. Enable Windows Defender Tamper Protection on every server and endpoint. Tamper Protection blocks the exact category of changes the attacker used — Set-MpPreference cmdlet edits, WMIC exclusion additions, and direct registry writes under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender — so an operator who reaches the host still cannot switch off real-time monitoring or add a malware exclusion.

SentinelOne enforces anti-tamper protection across managed environments, so an attacker who runs a disable script or edits Defender registry keys is blocked and flagged rather than left to work in silence. That matters because credential dumping only stays quiet if the endpoint agent is neutralized first.

Constrain PowerShell and web-directory execution

The batch file ran nearly all of its Defender changes through powershell -c and a bundled DisableDefender.ps1. Restricting how and where PowerShell runs removes that path:

• Enforce PowerShell Constrained Language Mode and require code signing (AllSigned execution policy) so unsigned scripts like DisableDefender.ps1 fail to run.
• Use AppLocker or Windows Defender Application Control to deny script and executable launches from web-writable directories — the same wwwroot\Images path where the webshell was dropped. A legitimate image folder has no reason to execute .ps1, .aspx, or .com files.
• Block w3wp.exe and other IIS worker processes from spawning script interpreters. A web worker running whoami, reg query, or net1 is not normal application behavior.

These controls do not depend on a signature or a running agent. Even if the attacker gets code execution through an unpatched application, an application-control policy that refuses to run untrusted scripts from a web root stops the follow-on script before it disables anything.

Finally, keep the remediation loop closed. In this case the server was returned to production twice before fixes were finished, which is what let the attacker come back on June 10 and June 11. Verify that every remediation item — patch, webshell removal, and configuration hardening — is complete before the system goes back online.

Key Takeaway: Re-enable and Harden Endpoint Protection Now

The core lesson from this incident is uncomfortable but simple: the attacker never found a flaw in Microsoft Defender itself. They walked in through an unpatched web server, and once inside, they turned off the protections that were working exactly as designed. Every command that disabled Defender ran with privileges the attacker earned by exploiting known vulnerabilities.

That distinction matters for how you think about the risk. Any server still running a vulnerable version of Adobe ColdFusion is exposed to the same sequence Huntress documented, where enumeration gave way to nearly a dozen defence impairment techniques before credential dumping. A fully licensed, correctly configured endpoint agent offers no protection if an attacker can reach a shell and switch it off.

The three priorities that address this specific attack are:

• Confirm Defender is actually running on every internet-facing server and endpoint, not just installed.
• Close the ColdFusion vulnerabilities that gave the attacker their foothold in the first place.
• Turn on Tamper Protection so that Defender settings cannot be silently changed by scripts like the batch file recovered here.

Tamper Protection is the control that specifically addresses this tradecraft. It blocks the registry edits and cmdlet changes the attacker used to disable real-time monitoring, meaning an i.bat-style script fails partway through instead of running clean.

The business reality is straightforward. A disabled Defender means credential theft, ransomware staging, and data exfiltration can proceed without generating the alerts your team relies on to intervene. In this case a watching SOC caught the activity before encryption or exfiltration occurred; without that layer, the same script runs to completion in silence.