INC Ransomware — SonicWall SMA 1000 Post-Exploitation Chain

Scope note — how this pack differs from the existing CVE pack: SonicWall-SMA1000-CVE-2026-15409-Hunt.html (published 2026-07-24) already covers the raw CVE-2026-15409 / CVE-2026-15410 exploit chain — the /wsproxy SSRF bypass and the remove_hotfix path-traversal privilege escalation — in detail. This pack does not re-derive that content. It exists because, since the beginning of August 2026, INC Ransomware has become the dominant actor weaponizing that chain, and the campaign carries its own named, previously undocumented post-exploitation toolkit that the CVE pack has zero coverage of: the KNUCKLEBALL Python loader, the Suo5 HTTP tunnel, the ORANGETAIL Behinder-class Java web shell, in-memory JVM injection via the Java Attach API, MFA/TOTP seed theft, and the downstream ransomware deployment chain. The CVE chain is cited below only as the initial-access vector.

Volexity tracks the pre-disclosure exploitation cluster as UTA0533, active from at least June 22, 2026 — three weeks before SonicWall's July 14, 2026 advisory (SNWLID-2026-0008). Rapid7 identified significant TTP overlap between its own incident-response engagements and the UTA0533 cluster. Resecurity subsequently linked the exploitation activity directly to an INC Ransomware affiliate, and by early August 2026 INC had accelerated its data-leak-site postings to the point that Resecurity and The Hacker News both describe it as the "dominant threat actor" now weaponizing this chain. INC claims 885+ victims to date; new victims added between July 17 and August 1, 2026 alone span the United States, Australia, the UAE, Colombia, and Switzerland, across both government and private sector.

The attacker's objective is not the appliance itself — it is what the appliance guards. After chaining the two CVEs to root, UTA0533/INC deploys KNUCKLEBALL (/usr/lib/python3.11/site-packages/deploy_new.py), a Python loader that uses the Java Attach API to inject two Base64-encoded JAR payloads directly into the legitimate SonicWall workplace.startup.CommandStartup JVM as instrumentation agents — no standalone binary ever touches disk as the final payload. The first JAR is a modified Suo5 (open-source HTTP forwarding proxy) providing covert tunneling; the second is ORANGETAIL, a custom Java memory-resident web shell functionally similar to the well-known Behinder shell, with AES-128-ECB encrypted, gated, reflection-based command execution. Both implants activate only behind a deliberately implausible spoofed User-Agent (Chrome/149.0.0.1, Windows NT 11.0) — itself a strong detection opportunity. From that foothold the actor harvests credentials, session databases, and TOTP MFA seed configurations (per Rapid7), sniffs unencrypted LDAP traffic with tcpdump, and pivots into the internal network to stage INC's Rust-based Windows/Linux/ESXi ransomware encryptor — the actual monetization event.

The highest-value defensive angle is downstream, not on the appliance. The SMA 1000 is a proprietary appliance with no Falcon sensor coverage, so KNUCKLEBALL/Suo5/ORANGETAIL are functionally invisible to EDR telemetry — appliance-side detection depends entirely on the vendor's own logs (extraweb_access.log, access_servers.log, ctrl-service.log), covered in Section 7. Falcon-covered telemetry becomes relevant the moment the actor pivots off the appliance: lateral movement (PsExec/RDP), RMM tool staging, EDR-tampering BYOVD drivers, Veeam credential dumping, and — the actual ransomware event — INC's Rust encryptor executing with its distinctive --esxi/--motd CLI flags and mass file modification. Sections 8–9 build that downstream detection surface.

Defender priority: treat every SMA 1000 appliance that was internet-facing and unpatched at any point between June 22, 2026 and firmware 12.4.3-03453 / 12.5.0-02835 as compromised, not just exposed. Patching alone does not evict an in-memory JVM implant or a setuid rootrun backdoor (/usr/bin/xzfind) — factory-reset and reimage is the only reliable eviction path. Rotate every credential and reissue every TOTP/MFA seed the appliance ever processed before the exposure window closes, and hunt the internal network (Sections 8–9) for the lateral-movement and encryptor-staging behaviors that turn an appliance compromise into an INC ransomware event.

Eight sources were fetched and saved in full to INC-SonicWall-Hunt-sources/ for this pack. Two sources returned by initial search (a rankiteo.com aggregator mirror and a socradar.io campaign card) were excluded as low-value re-aggregations once the primary Volexity/Rapid7/Resecurity reporting was in hand. No fetched source contained any text addressed to an AI agent, instructions to execute commands, or attempts to redirect this research process — all eight are ordinary article/report content and are cited below.

Decision: the appliance-side exploit mechanics (the SSRF/path-traversal internals) are intentionally kept brief here and referenced back to the existing CVE pack — full technical reconstruction of that chain is out of scope for this document. Everything from the malware toolkit onward (KNUCKLEBALL injection, Suo5/ORANGETAIL, MFA seed theft, and the INC ransomware deployment chain) is treated as primary content.

Hypothesis: An INC Ransomware-affiliated actor (tracked upstream as UTA0533) has used, or is using, the SonicWall SMA 1000 CVE-2026-15409/15410 chain for initial access, has deployed KNUCKLEBALL to inject Suo5 and ORANGETAIL into the appliance JVM, has harvested credentials and MFA/TOTP seeds from the appliance, and is either staging or has already executed lateral movement and ransomware deployment against the internal network the appliance fronts. Steps 1–8 (appliance compromise) are summarized for context only — see the existing CVE pack for full exploit detail. Steps 9–15 (post-appliance-compromise) are this pack's primary focus.

The ASN 206092 ranges are shared/bulletproof-hosting infrastructure per Rapid7 — correlate hits with appliance-adjacent authentication or Suo5/ORANGETAIL activity before actioning as a block, not on IP alone.

The SMA 1000 is a proprietary appliance with no Falcon sensor coverage. Every hunt in this section runs against the appliance's own logs (SSH to the appliance, or forward these logs to a SIEM) — none of it is CQL. This is where the KNUCKLEBALL/Suo5/ORANGETAIL detection actually has to happen.

extraweb_access.log — webshell access via the hijacked routes

Presence of successful (HTTP 200) access to /__api__/login or /__api__/logout from an external source is a strong indicator of ORANGETAIL/Suo5 interaction, since these are legitimate SMA paths that UTA0533 rewrote to proxy to the implants:

x.x.x.x - - [DD/Mon/YYYY:HH:MM:SS -0000] "POST /__api__/logout HTTP/1.1" 200 211602 "-" -
x.x.x.x - - [DD/Mon/YYYY:HH:MM:SS -0000] "POST /__api__/login HTTP/1.1" 200 - "-" -

Filter for these paths from source addresses outside your known VPN client IP space, and separately for any request whose User-Agent matches the ORANGETAIL/Suo5 gating string: Mozilla/6.0 (Windows NT 11.0; Win64; x64) AppleWebKit/1537.136 (KHTML, like Gecko) Chrome/149.0.0.1 Safari/1537.136 — the version numbers (NT 11.0, Chrome 149.0.0.1) do not correspond to any real browser release.

ctrl-service.log — command execution and privilege escalation

Entries referencing hotfix removal with a path-traversal payload confirm CVE-2026-15410 was actually triggered (context only — see the existing CVE pack for the exploit detail):

YYYY-MM-DD HH:MM:SS,mmm - INFO - running hotfix removal for:../../../../../tmp/<staged-script>.sh
YYYY-MM-DD HH:MM:SS,mmm - ERROR - Command '['/usr/local/bin/remove_hotfix', '../../../../../tmp/<staged-script>.sh']' exited with status '1'

Filesystem — KNUCKLEBALL / ROOTRUN / staged-artifact sweep

• find / -perm -4000 -type f — flag any setuid binary outside the documented legitimate set (auth_pam_tool, ssh-keysign, umount, su, mount, newgrp, at, ping/ping6, sudo, and the appliance's own /usr/local/workplace/conf). A setuid /usr/bin/xzfind is ROOTRUN.
• Check for /usr/lib/python3.11/site-packages/deploy_new.py (KNUCKLEBALL) and any unexpected *.jar under /tmp.
• Check /tmp and /var/tmp for 1234.sh, hypdate.b64, agent_wp8.jar, agent_wp9.jar, lib.sh, and any zero-byte root-owned file named txt.
• diff the live /etc/init.d/workplace and /var/lib/unit/conf.json against a known-good pre-June-2026 backup; look specifically for a python3 /usr/lib/python3.11/site-packages/deploy_new.py line and for routes proxying /__api__/login / /__api__/logout to http://127.0.0.1:8085.
• Confirm against Volexity's published YARA signatures for ROOTRUN, KNUCKLEBALL, Suo5, and ORANGETAIL (linked in Section 18) if you have on-appliance or memory-image scanning capability.

LDAP-sniffing artifact

Check for an unexpected tcpdump-launching script (Volexity observed /var/tmp/lib.sh) and any resulting .pcap-style capture files under /var/tmp dated after the appliance's known exposure window. Presence confirms LDAP credential sniffing on TCP/389 — treat every account whose credentials transited unencrypted LDAP during that window as compromised.

Identity Provider / MFA — TOTP seed reissuance validation (non-CQL)

Because MFA seed theft cannot be reliably detected after the fact from endpoint telemetry, this is a verification hunt, not a detection: for every account that authenticated through the appliance during the exposure window, confirm in the IdP admin console that its TOTP secret has been reissued (not merely that MFA is "enabled") and that no TOTP codes are being accepted from a seed generated before the rotation timestamp.

All nine queries below hunt downstream of the appliance — on Falcon-covered internal hosts, not on the SMA 1000 itself (see Section 7 for appliance-side log hunts). Set the console time picker to at least the June 22, 2026 exposure-window start when back-hunting.

// HUNT: Network connections to published UTA0533 / INC Ransomware attacker IPs
// MITRE: T1190, T1071
// CONF: high  FP: low  COST: low
// REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: none expected -- these are actor-attributed hosts, not shared cloud/CDN space
#event_simpleName=NetworkConnectIP4
| RemoteAddressIP4=/^(42\.200\.172\.14|81\.19\.140\.217|89\.117\.20\.1|108\.205\.8\.173|147\.45\.51\.19|150\.241\.210\.53|202\.8\.105\.201|217\.77\.15\.99)$/
| table([ComputerName, UserName, RemoteAddressIP4, RemotePort, LocalAddressIP4, ContextBaseFileName, @timestamp])

// HUNT: Traffic to Rapid7-attributed ASN 206092 attacker infrastructure
// MITRE: T1071, T1090
// CONF: medium  FP: medium  COST: low
// REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: ASN 206092 is bulletproof/shared hosting -- unrelated tenants share these ranges
// TUNING: correlate with Q1/Q3-Q9 hits or appliance-adjacent auth before actioning; do not auto-block on this alone
#event_simpleName=NetworkConnectIP4
| cidr(RemoteAddressIP4, subnet=["45.131.194.0/24","45.146.54.0/24","63.135.161.0/24","173.239.211.0/24"])
| table([ComputerName, UserName, RemoteAddressIP4, RemotePort, ContextBaseFileName, @timestamp])

// HUNT: PsExec-based lateral movement (INC affiliate tradecraft)
// MITRE: T1021.002, T1570
// CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2, SyntheticProcessRollup2
// FALSE POSITIVES: legitimate IT operations and RMM platforms use PsExec for routine administration
// TUNING: exclude known ITSM/automation service accounts and scheduled-maintenance windows; scope to hosts reachable from the compromised appliance segment
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| FileName=/^psexec(svc)?\.exe$/i
| table([ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, @timestamp])

// HUNT: Unauthorized RMM tool staging (AnyDesk / ScreenConnect / TeamViewer)
// MITRE: T1219
// CONF: medium  FP: medium  COST: low
// REQUIRES: ProcessRollup2, SyntheticProcessRollup2
// FALSE POSITIVES: legitimate MSP-managed or internal IT RMM deployments
// TUNING: exclude approved RMM golden-image hashes and known MSP service accounts; alert only on first-seen installs per host
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| FileName=/^(anydesk|screenconnect|connectwisecontrol|teamviewer)\.exe$/i
| table([ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, @timestamp])

// HUNT: BYOVD vulnerable driver load (INC process-terminator tool)
// MITRE: T1562.001, T1068
// CONF: high  FP: low  COST: low
// REQUIRES: DriverLoad
// FALSE POSITIVES: none expected -- these driver filenames are not part of any legitimate software distribution
#event_simpleName=DriverLoad
| FileName=/^(filwfp|filnk|fildds)\.sys$/i
| table([ComputerName, UserName, FileName, ImageFileName, @timestamp])

// HUNT: EDR/security-process termination via PsKill / ProcessTerminator
// MITRE: T1562.001
// CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2, SyntheticProcessRollup2
// FALSE POSITIVES: PsKill has legitimate sysadmin uses -- rare enough in most estates to keep FP low; validate against your own PsKill baseline if used internally
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| FileName=/^(pskill|processterminator)\.exe$/i
| table([ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, @timestamp])

// HUNT: Veeam backup credential-dumper execution
// MITRE: T1003, T1552.001
// CONF: medium  FP: medium  COST: low
// REQUIRES: ProcessRollup2, SyntheticProcessRollup2
// FALSE POSITIVES: legitimate Veeam backup-admin maintenance scripts touch the same cmdlets and tables
// TUNING: exclude signed, scheduled backup-admin tasks running under the documented Veeam service account
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| FileName=/^powershell(_ise)?\.exe$/i
| CommandLine=/Veeam.*Get-Creds|Get-VBRCredential|dbo\.\[?Credentials\]?/i
| table([ComputerName, UserName, ParentBaseFileName, CommandLine, @timestamp])

// HUNT: INC Rust encryptor CLI execution signatures
// MITRE: T1486, T1489
// CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2, SyntheticProcessRollup2
// FALSE POSITIVES: none expected -- these flags and the INC-README string are campaign-specific, not generic admin tooling
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/--esxi|--motd|--skip |getallvms|INC-README/i
| table([ComputerName, UserName, FileName, CommandLine, @timestamp])

// HUNT: Mass critical-file modification (ransomware encryption behavior)
// MITRE: T1486
// CONF: high  FP: medium  COST: medium
// REQUIRES: CriticalFileModified
// FALSE POSITIVES: backup jobs, AV full scans, large file-copy or migration tasks, patch deployment tools
// TUNING: exclude known backup/AV/migration service accounts and their scheduled windows; tune the 50-event threshold to your environment's baseline
#event_simpleName=CriticalFileModified
| groupBy([ComputerName, UserName], function=[count(as=FilesModified)], limit=500)
| FilesModified>50
| sort(FilesModified, order=desc, limit=100)
| table([ComputerName, UserName, FilesModified])

Queries not listed above (Q2, Q3, Q4, Q7, Q9) remain investigate-only hunt queries — their FP profile (shared-hosting ASN, legitimate admin/backup/RMM tooling) makes them appropriate for scheduled hunting and analyst triage, but not for automated Prevent-mode blocking without environment-specific tuning first.

Playbook 1 — SonicWall SMA 1000 Patch + Compromise Assessment

PLAYBOOK 1 — SonicWall SMA 1000 patch + compromise assessment

Step 1. Verify current firmware version.
  Prerequisites: MySonicWall admin access to the AMC/CMC console.
  Command:  AMC/CMC UI -> System Configuration -> Firmware & Settings -> confirm build number
  Reboot required: No (read-only check)
  Rollback: N/A

Step 2. Run the compromise-assessment sweep BEFORE patching (patching can disturb evidence).
  Prerequisites: SSH/console access to the appliance as an administrative user.
  Command:
    find / -perm -4000 -type f
    ls -la /usr/lib/python3.11/site-packages/deploy_new.py /usr/bin/xzfind 2>/dev/null
    ls -la /tmp/1234.sh /tmp/hypdate.b64 /tmp/agent_wp8.jar /tmp/agent_wp9.jar /var/tmp/lib.sh 2>/dev/null
    diff /etc/init.d/workplace /path/to/known-good-backup/etc/init.d/workplace
    diff /var/lib/unit/conf.json /path/to/known-good-backup/var/lib/unit/conf.json
  Reboot required: No
  Rollback: N/A (read-only sweep)

Step 3a. IF NO artifacts found: apply the vendor hotfix.
  Prerequisites: Maintenance window; current configuration backup taken AFTER Step 2 (never restore a
    backup that predates confirmation of a clean state -- see Note below).
  Command:  AMC/CMC UI -> System Configuration -> Firmware & Settings -> Upload/Apply
    12.4.3-03453 (12.4.3 branch) or 12.5.0-02835 (12.5.0 branch)
  Reboot required: Yes -- appliance reboots automatically as part of firmware application.
  Rollback: Revert to the pre-patch firmware image via AMC/CMC firmware rollback if the hotfix breaks
    production VPN service; re-open the compromise-assessment question immediately if you roll back, since
    reverting removes the patch that closes CVE-2026-15409/15410.

Step 3b. IF artifacts found: do not patch in place. Factory reset and reimage.
  Prerequisites: Confirmed clean configuration backup taken BEFORE 2026-06-22 (the earliest observed
    UTA0533 compromise date). If no such backup exists, rebuild configuration manually from documentation
    rather than restoring any backup taken during or after the exposure window.
  Command:  Factory reset via AMC/CMC or physical reset per SonicWall's documented procedure, then reimage
    with 12.4.3-03453+ / 12.5.0-02835+ firmware.
  Reboot required: Yes (inherent to factory reset/reimage).
  Rollback: None -- this IS the rollback/remediation step for a confirmed-compromised appliance. There is
    no safe path back to the pre-reset state; the pre-reset state is the compromise.

Note: never restore a configuration backup dated after 2026-06-22 onto a reimaged appliance without first
auditing it for the persistence artifacts listed in Step 2 -- a restored backup can reintroduce the
attacker's init.d/conf.json modifications onto an otherwise-clean appliance.

Playbook 2 — Windows EDR Tamper Protection / Vulnerable-Driver Blocking (BYOVD)

PLAYBOOK 2 — Windows EDR tamper protection / vulnerable-driver blocking (BYOVD mitigation)

Step 1. Enable Falcon Sensor Tampering Protection (if not already enabled).
  Prerequisites: Falcon console admin access; sensor policy edit rights.
  Command:  Falcon console -> Host Setup and Management -> Sensor Update Policies -> [policy] ->
    enable "Sensor Tampering Protection"
  Reboot required: No
  Rollback: Disable the same toggle in the sensor policy if it causes conflicts with an approved
    endpoint-management tool; document the exception and re-enable once resolved.

Step 2. Enable the Microsoft vulnerable-driver blocklist.
  Prerequisites: Windows 10 2004+ / Windows 11 or Server 2022+; verify via
    Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -ClassName Win32_DeviceGuard
    that Device Guard / VBS is supported on target hardware.
  Command (PowerShell, run as Administrator):
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" `
      -Name "VulnerableDriverBlocklistEnable" -Value 1 -Type DWord -Force
  Reboot required: Yes -- the blocklist is enforced by Code Integrity at boot.
  Rollback:
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" `
      -Name "VulnerableDriverBlocklistEnable" -Value 0 -Type DWord -Force
    then reboot. Roll back only if a legitimate, currently-required driver is blocklisted and no
    updated/signed replacement is available yet.

Step 3. Verify enforcement with a benign lab test (do not test against production).
  Prerequisites: Isolated lab VM, NOT a production host.
  Command:  Attempt to load a known-blocklisted test driver in the lab VM and confirm Code Integrity
    event 3033/3034 is logged and the load is blocked.
  Reboot required: No (lab VM already rebooted in Step 2)
  Rollback: N/A (verification step only)

Playbook 3 — Credential and MFA/TOTP Seed Rotation

PLAYBOOK 3 — Credential and MFA/TOTP seed rotation (post-appliance-compromise)

Step 1. Enumerate every account that authenticated through the affected appliance during the exposure
  window (2026-06-22 through the confirmed patch/reimage date).
  Prerequisites: Appliance or SIEM-forwarded authentication logs covering the full window.
  Command:  grep/SIEM query against extraweb_access.log and access_servers.log for successful auth events
    in the window; export the account list.
  Reboot required: No
  Rollback: N/A (data-gathering step)

Step 2. Force a password reset for every enumerated account.
  Prerequisites: Domain admin or IdP admin rights; enumerated account list from Step 1.
  Command (on-prem AD example):
    Get-Content accounts.txt | ForEach-Object { Set-ADAccountPassword -Identity $_ -Reset
      -NewPassword (ConvertTo-SecureString -AsPlainText "<temp-policy-compliant-password>" -Force) }
    Set-ADUser -Identity $_ -ChangePasswordAtLogon $true
  Reboot required: No
  Rollback: N/A -- a forced reset is not reversible by design; if a reset locks out a legitimate user
    before they can respond, use the organization's standard helpdesk re-provisioning process (not a
    rollback of the reset itself).

Step 3. Reissue TOTP/MFA seeds for every enumerated account. This is the step most incident responses
  skip -- a password reset alone does NOT invalidate a stolen TOTP seed.
  Prerequisites: IdP admin console access (Entra ID, Okta, Duo, or equivalent).
  Command:  IdP admin console -> per user -> revoke existing MFA/authenticator enrollment -> require
    re-enrollment on next login. For bulk operations, use the IdP's bulk MFA-reset API/PowerShell module.
  Reboot required: No
  Rollback: N/A -- do not roll back an MFA reseed. If users are locked out, re-provision through the
    standard identity-verification helpdesk process.

Step 4. Confirm no TOTP codes generated from a pre-rotation seed are still being accepted.
  Prerequisites: IdP audit log access.
  Command:  Review IdP sign-in logs for successful MFA challenges tied to the enumerated accounts;
    confirm all post-rotation successes reference the new enrollment, not the old one.
  Reboot required: No
  Rollback: N/A (verification step)

Playbook 4 — Enforce LDAPS/StartTLS for Directory-Service Traffic

PLAYBOOK 4 — Enforce LDAPS/StartTLS for directory-service traffic

Step 1. Inventory current LDAP bind traffic and confirm which is unencrypted.
  Prerequisites: Network visibility (packet capture or firewall flow logs) on TCP/389 and TCP/636.
  Command:  Review firewall/flow logs for TCP/389 traffic volume between the appliance/VPN segment and
    domain controllers; any nonzero volume on 389 during the exposure window should be treated as
    potentially sniffed per the LDAP-capture finding in Section 7.
  Reboot required: No
  Rollback: N/A (assessment step)

Step 2. Enable LDAPS (TCP/636) or StartTLS on the domain controllers.
  Prerequisites: A valid server certificate installed on each domain controller for LDAPS; AD CS or an
    equivalent PKI already issuing DC certificates.
  Command (verify LDAPS is listening):
    Test-NetConnection -ComputerName <dc-hostname> -Port 636
  Reboot required: No (LDAPS listener activates once a valid certificate is present; no reboot needed on
    modern Windows Server, though an LDS/AD DS service restart may be required on older builds).
  Rollback: Remove/revoke the LDAPS certificate binding if it breaks a legacy LDAP client that cannot
    negotiate TLS; re-enable plaintext LDAP only as a temporary bridge while that client is remediated,
    and re-close it on a tracked deadline.

Step 3. Reconfigure the SonicWall SMA appliance's directory-service integration to use LDAPS instead of
  plaintext LDAP.
  Prerequisites: Step 2 complete and verified; SMA admin console access.
  Command:  AMC/CMC UI -> Authentication -> LDAP Configuration -> set port 636, enable "Use SSL/TLS"
  Reboot required: No (configuration change only; connection re-establishes automatically)
  Rollback: Revert the LDAP configuration to port 389 without TLS if directory lookups fail after the
    change -- only as a temporary measure while troubleshooting the DC certificate, tracked to closure
    within 48 hours.

Step 4. Disable plaintext LDAP (port 389) at the domain controller firewall once all clients are
  confirmed migrated.
  Prerequisites: All directory-integrated systems confirmed using LDAPS/StartTLS (repeat Step 1's traffic
    review and confirm zero remaining plaintext bind volume).
  Command:  Firewall rule blocking inbound TCP/389 to domain controllers from all sources except an
    explicitly documented legacy-system exception list.
  Reboot required: No
  Rollback: Re-open TCP/389 for a specific source if a previously-unidentified legacy client breaks;
    add it to the documented exception list and schedule its LDAPS migration.

Validation gates: see Section 11 for the telemetry-readiness, benign-baseline, positive-test, and IOA-promotion criteria that back this map. Every row marked GAP reflects a genuine blind spot — the SMA 1000 has no Falcon sensor coverage — and is mitigated through vendor log hunting (Section 7) and hardening (Section 12), not through CQL.

All eight primary/secondary sources above were fetched in full and saved to INC-SonicWall-Hunt-sources/ at research time for IOC provenance verification. None contained any content addressed to an AI agent or attempting to redirect this research process.