ThreatsDay Roundup: 296K-Device IoT Botnet, Water Utility Intrusions, and SharePoint RCE Chains — A Defender's Field Guide

This week's ThreatsDay roundup reads like a cross-section of everything keeping IR teams busy in 2026: a 296,000-device IoT botnet leveraging compromised consumer and edge hardware (with command infrastructure borrowing AI services to blend in), more than 100 water and wastewater systems targeted in a coordinated scanning and intrusion campaign, and a critical remote code execution chain in Microsoft SharePoint that collapses the window between disclosure and exploitation. Layered on top: phishing pages impersonating security scans, trojanized productivity apps, and malware that deliberately sleeps before revealing its true behavior to evade sandbox analysis.

None of these are exotic, theoretical threats. They are the exact intrusion classes our SOC sees weekly — and each one is preventable or detectable with controls most organizations already own but haven't tuned. This post breaks down the three highest-impact stories from a defensive standpoint and gives you deployable detection content for each.

Technical Analysis

1. The 296K-Device IoT Botnet

What's happening: A botnet of roughly 296,000 compromised IoT devices — routers, cameras, DVRs, and embedded Linux systems — is being used as infrastructure for downstream attacks. The notable evolution: command-and-control traffic is being routed through or disguised as legitimate public infrastructure and AI service endpoints, making traditional domain-reputation blocking ineffective. When your C2 rides the same TLS sessions as sanctioned SaaS and AI APIs, egress filtering by destination category stops working.

How devices get compromised: The classic playbook hasn't changed — default credentials, unpatched embedded firmware vulnerabilities, and exposed management interfaces (Telnet/23, HTTP admin panels on 80/8080/8443) reachable from the internet. Exploitation is automated and opportunistic; a device exposed to the internet today can be enrolled into a botnet within hours.

Why defenders should care even if they 'don't own IoT': Botnet nodes inside your network become (a) egress sources for DDoS and scanning that torch your IP reputation, (b) pivot points for lateral movement onto flat networks, and (c) covert proxy infrastructure — attackers increasingly relay intrusions through compromised devices inside victim networks to inherit trusted egress paths.

2. 100+ Water Systems Targeted

What's happening: Over 100 water and wastewater utilities are being actively scanned and probed. This fits the established pattern of targeting small-to-midsize utilities with weak OT/IT segmentation, internet-exposed HMIs, and remote access tools (VNC, RDP, vendor remote-support software) reachable directly from the internet.

Defender's view of the attack chain:

1. Internet-wide scanning for exposed ICS protocols and remote access (Modbus/502, DNP3/20000, EtherNet-IP/44818, VNC/5900, RDP/3389).
2. Access via default credentials or unpatched remote access gateways.
3. Manipulation of HMI views or PLC logic — in water systems, historically chemical dosing and pressure setpoints.

The exposure window is the story here: the time between a system appearing in scan databases and being probed continues to shrink.

3. Critical SharePoint Remote Code Execution Chain

What's happening: A critical code-execution flaw chain in on-premises Microsoft SharePoint is being actively exploited. SharePoint RCE chains follow a predictable anatomy: an authentication bypass or unsafe deserialization endpoint reachable pre-auth, followed by payload delivery that typically culminates in a webshell dropped into the SharePoint web root and commands executing as the w3wp.exe (IIS worker process) child.

Key defensive facts:

• On-premises SharePoint servers that are internet-facing are the primary targets. SharePoint Online (M365) is not affected by on-prem server flaws.
• Post-exploitation behavior is highly consistent: w3wp.exe spawning cmd.exe, powershell.exe, or rundll32.exe, followed by webshell files (.aspx, .ashx, .asmx) appearing under SharePoint's LAYOUTS and TEMPLATE directories.
• Treat any unpatched, internet-facing SharePoint farm as potentially already compromised — scan for webshells before and after patching, because patching does not remove shells already dropped.

4. The Supporting Cast: Social Engineering and Delayed-Execution Malware

The roundup's other thread deserves equal attention: fake login pages, fake 'security scan' lures, and trojanized productivity apps remain the cheapest way in. The new wrinkle is delay logic — malware that idles through sandbox detonation windows (sleep timers, environment checks, user-interaction gates) before executing its real payload. If your email/web detonation pipeline analyzes samples for only 2–5 minutes with no user simulation, assume a meaningful percentage of these loaders are passing clean.

Detection & Response

The rules below target the most reliable, low-noise observables from this story: SharePoint post-exploitation behavior, loader execution patterns from trojanized apps, and ICS exposure discovery.

---
title: SharePoint Worker Process Spawning Command Shell or Script Interpreter
id: 3f7c1a92-8e4d-4b5a-9c21-6d8f0e2a7b14
status: experimental
description: Detects the IIS worker process (w3wp.exe) on SharePoint servers spawning cmd.exe, powershell.exe, or other script interpreters — a hallmark of webshell execution following SharePoint RCE exploitation.
references:
  - https://attack.mitre.org/techniques/T1505/003/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/14
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\w3wp.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\powershell_ise.exe'
      - '\pwsh.exe'
      - '\cscript.exe'
      - '\wscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\net.exe'
      - '\net1.exe'
      - '\whoami.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  filter_sp_syntax:
    CommandLine|contains:
      - 'SharePoint Products Configuration Wizard'
      - 'psconfig.exe'
  condition: selection_parent and selection_child and not filter_sp_syntax
falsepositives:
  - Rare SharePoint administrative tooling or third-party farm management software; baseline per-server and tune
level: critical
---
title: Webshell File Dropped in SharePoint Web Directories
id: 9b2e5d41-6c3a-4f78-b1e9-2d4a7c0f5e38
status: experimental
description: Detects creation of ASPX/ASHX/ASMX script files in SharePoint LAYOUTS and TEMPLATE directories by processes other than the SharePoint installer or timer service — consistent with webshell deployment after RCE exploitation.
references:
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/08/14
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\LAYOUTS\'
      - '\TEMPLATE\'
      - '\_app_bin\'
      - '\inetpub\wwwroot\'
  selection_ext:
    TargetFilename|endswith:
      - '.aspx'
      - '.ashx'
      - '.asmx'
      - '.asp'
  filter_installers:
    Image|endswith:
      - '\setup.exe'
      - '\msiexec.exe'
      - '\psconfig.exe'
      - '\psconfigui.exe'
      - '\OWSTIMER.EXE'
  condition: selection_path and selection_ext and not filter_installers
falsepositives:
  - Custom SharePoint solution (WSP) deployments during maintenance windows — correlate with change tickets
level: high
---
title: Trojanized Application Loader Executing from User-Writable Paths with Sleep Delay
id: 5c8f3b17-2a9d-4e6c-87f1-4b3d9a0e6c52
status: experimental
description: Detects script interpreters and LOLBins launched from user-writable directories with command-line sleep/timeout delay arguments — behavior associated with trojanized productivity apps and sandbox-evasive loaders described in this week's reporting.
references:
  - https://attack.mitre.org/techniques/T1497/
  - https://attack.mitre.org/techniques/T1036/
author: Security Arsenal
date: 2026/08/14
tags:
  - attack.defense_evasion
  - attack.t1497
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_path:
    Image|contains:
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\Users\Public\'
      - '\Downloads\'
  selection_delay:
    CommandLine|contains:
      - 'timeout /t'
      - 'Start-Sleep'
      - 'ping -n '
      - 'choice /t'
      - 'Wait-For'
  condition: selection_path and selection_delay
falsepositives:
  - Software installers using delayed cleanup routines; constrain to unsigned binaries in production tuning
level: medium

Sentinel / Defender Hunting Queries

The first query hunts SharePoint post-exploitation on endpoints; the second hunts botnet/ICS-style egress and inbound scanning patterns via ingested firewall syslog (CEF). Both assume standard Sentinel connectors.

// Hunt 1: SharePoint w3wp spawning shells or recon commands (last 7 days)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","mshta.exe","rundll32.exe","regsvr32.exe","net.exe","whoami.exe","certutil.exe","bitsadmin.exe")
| extend CommandLine = tostring(ProcessCommandLine)
| where CommandLine !contains "psconfig"
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, FileName, CommandLine, AccountName, ReportId
| order by TimeGenerated desc

// Hunt 2: Outbound sessions from servers/IoT segments to rare external destinations (botnet C2 pattern via CEF/syslog firewall logs)
let knownVolume = CommonSecurityLog
| where TimeGenerated > ago(30d) and TimeGenerated < ago(7d)
| summarize BaselineConns=count() by DestinationIP;
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceAction in~ ("allow","allowed","permit","accept") or isempty(DeviceAction)
| join kind=leftanti (knownVolume) on DestinationIP
| summarize FirstSeen=min(TimeGenerated), ConnCount=count(), Destinations=dcount(DestinationIP), Ports=make_set(DestinationPort) by SourceIP, SourceHostName
| where ConnCount > 200  // beacon-like frequency from a single internal host to previously unseen destinations
| order by ConnCount desc

// Hunt 3: Inbound scanning against ICS/remote-access ports on utility or DMZ segments
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationPort in (502, 20000, 44818, 5900, 3389, 23, 8080, 8443)
| summarize ProbeCount=count(), UniqueSources=dcount(SourceIP), SourceSet=make_set(SourceIP, 20) by DestinationIP, DestinationPort
| where UniqueSources > 3
| order by UniqueSources desc

Velociraptor Hunt Artifact

Use this VQL across your SharePoint farm and DMZ Windows hosts to sweep for webshell artifacts and suspicious worker-process lineage in one pass.

-- Sweep SharePoint servers for webshells and suspicious w3wp lineage
LET webroots = SELECT FullPath, Mtime, Size
FROM glob(globs=[
  'C:/Program Files/Common Files/microsoft shared/Web Server Extensions/*/TEMPLATE/LAYOUTS/*.as*x',
  'C:/Program Files/Common Files/microsoft shared/Web Server Extensions/*/TEMPLATE/LAYOUTS/*.ashx',
  'C:/inetpub/wwwroot/**/*.aspx',
  'C:/inetpub/wwwroot/**/*.ashx'
])
WHERE Mtime > ago(30d)

LET suspicious_procs = SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist(parent='')
WHERE CommandLine =~ '(powershell|cmd\.exe|certutil|bitsadmin|rundll32)'

SELECT * FROM webroots
UNION ALL
SELECT FullPath=NULL, Mtime=CreateTime, Size=Pid FROM suspicious_procs

For network-side validation of the same hosts:

-- Identify SharePoint/IIS processes holding unexpected external connections
SELECT Pid, Name, RemoteIP, RemotePort, State
FROM netstat()
WHERE Name =~ 'w3wp'
  AND NOT RemoteIP =~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.|::1|fe80)'
  AND RemotePort > 1024

Remediation

SharePoint (Highest Priority)

1. Patch now. Apply the latest Microsoft security update for your SharePoint build (Subscription Edition, 2019, or 2016) per Microsoft's security update guide. Verify the build number after patching — do not rely on Windows Update reporting alone.
2. Assume breach on internet-facing farms. Run the webshell sweep above before patching, preserve evidence, then patch. A patch does not evict an existing webshell.
3. Rotate secrets after patching a previously exposed server: the SharePoint farm account, service accounts, and any credentials in memory on that host. Machine keys (ViewState validation keys) must be rotated if there is any chance of theft — stolen ASP.NET machine keys enable forged __VIEWSTATE deserialization payloads that survive patching.
4. Harden the attack surface:
   • Remove SharePoint from direct internet exposure; place behind an authenticated reverse proxy or VPN/ZTNA gateway.
   • Enable AMSI integration for SharePoint (the AMSI feature is supported on SharePoint Server and blocks many webshell/in-memory payloads in real time).
   • Restrict outbound egress from SharePoint servers — a web front-end has almost no legitimate reason to initiate arbitrary internet connections.

# SharePoint compromise assessment + hardening verification (run elevated on each farm server)
# 1. Report installed SharePoint build
$spVer = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\16.0\WSS' -ErrorAction SilentlyContinue).InstalledProducts
Write-Output "SharePoint build info: $spVer"
Get-SPProduct -Local -ErrorAction SilentlyContinue  # requires SharePoint Management Shell

# 2. Sweep web roots for recently written script files (potential webshells)
$cutoff = (Get-Date).AddDays(-45)
Get-ChildItem -Path 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions','C:\inetpub\wwwroot' `
  -Recurse -Include *.aspx,*.ashx,*.asmx,*.asp -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt $cutoff } |
  Select-Object FullName, LastWriteTime, Length | Format-Table -AutoSize

# 3. Check whether AMSI is enabled for SharePoint (feature present and not disabled)
Get-SPWebApplication | ForEach-Object { "{0} : AMSI Enabled = {1}" -f $_.DisplayName, $_.AmsiEnabled }
# Enable AMSI where missing:
# Get-SPWebApplication | ForEach-Object { $_.AmsiEnabled = $true; $_.Update() }

# 4. Audit w3wp child processes logged in the last 24h (requires process creation auditing, Event 4688)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'w3wp\.exe' -and $_.Message -match 'cmd\.exe|powershell\.exe|mshta\.exe|rundll32\.exe' } |
  Select-Object TimeCreated, Message | Format-List

IoT / Botnet Exposure

1. Inventory and isolate. Enumerate all IoT/OT/embedded devices; place them on dedicated VLANs with default-deny east-west rules. IoT devices should not be able to reach servers, workstations, or each other unless required.
2. Kill inbound internet exposure. No IoT management interface (Telnet, HTTP admin) should be reachable from the internet. Audit NAT rules, UPnP tables on consumer-grade edge gear, and cloud-punch-through services (P2P camera clouds are a recurring offender).
3. Egress control and detection. Alert on IoT VLANs initiating high-frequency outbound connections to destinations with no history (Hunt 2 above). Block outbound Telnet/23 and IRC-era ports at the perimeter entirely.
4. Credential hygiene. Rotate every default credential; where devices can't support unique creds, that's a replacement decision, not an exception.

# Quick Linux-based exposure audit for IoT/edge segments (run from a scanner host)
# 1. Find devices with Telnet or web admin panels open
nmap -Pn -p 23,80,443,8080,8443,7547 --open 192.168.40.0/24 -oG iot_exposure.gnmap
grep -E '23/open|7547/open' iot_exposure.gnmap   # Telnet and TR-069/CWMP should be empty

# 2. Check your public IP range for inbound exposure to IoT/ICS services (from an external host)
nmap -Pn -p 23,502,20000,44818,5900,3389,8080 --open <your_public_range> -oG external_exposure.gnmap

# 3. Identify high-frequency outbound talkers on an IoT VLAN via conntrack (on a Linux gateway)
conntrack -L 2>/dev/null | awk '{for(i=1;i<=NF;i++) if($i ~ /^src=192\.168\.40\./) print $i}' \
  | sort | uniq -c | sort -rn | head -20

Water / Wastewater and Small Utility Operators

1. Remove direct internet exposure of OT assets. HMIs, PLCs, and historian jump boxes must never be internet-reachable. Use CISA's free Cyber Hygiene Vulnerability Scanning service if you lack attack-surface visibility — utilities in this campaign were found via exactly the exposure that service reports.
2. Remote access via brokered, MFA-enforced paths only. Vendor remote support should be disabled by default and enabled per-incident, logged, and time-boxed.
3. Segment IT from OT with a firewall or unidirectional gateway; monitor the boundary for the ICS ports in Hunt 3.
4. Manual fallback readiness. Rehearse operating the plant in manual mode. The credible worst case in water incidents is loss of view/control integrity — operators who have drilled manual operations turn a cyber incident into an inconvenience.
5. Report and coordinate. Water-sector incidents should be reported to CISA and your WaterISAC; the current campaign's scope (100+ systems) means shared indicators are actively flowing through those channels.

Phishing, Fake Security Scans, and Delayed Malware

• Extend sandbox detonation windows to 10+ minutes and enable user-interaction simulation (mouse movement, dialog dismissal) — static delay loops are the cheapest evasion in this week's tooling.
• Block newly registered domains at the web proxy for general users; the fake login and fake 'security scan' pages in these campaigns overwhelmingly live on NRDs.
• Enforce application allow-listing on endpoints so trojanized 'productivity apps' fail to execute by default; pair with SmartScreen/reputation checks for downloaded binaries.

The Bottom Line

Three threads, one lesson: exposure plus time equals compromise. A 296K-device botnet exists because hundreds of thousands of devices sat unpatched with default credentials. Water utilities are being hit because remote access was left reachable. SharePoint servers are being shelled because the patch window is now measured in hours, not weeks. The defenders who win this week are the ones who already had their attack surface inventoried, their SharePoint farm hardened, and their detection content tuned before the roundup was published. Use the queries and rules above to close those gaps today.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub