claudetools/clients/valleywide/session-logs/2026-04-13-rdweb-brute-force-incident.md

Session Log: 2026-04-13 — RDWeb Brute-Force Incident

Summary

Originally asked to help find a Windows Server 2016 box that could serve as a DISM source for IMC's broken component store. Valleywide's VWP_ADSRVR turned out to be Server 2019 (wrong version), so not useful for IMC — but while investigating, we uncovered an active brute-force attack on Valleywide's publicly-exposed RDWeb and pivoted to incident response.

No compromise identified. Attack surface closed.

Timeline

1. Asked user for SSH access — user provided the sysadmin local password and instructions to enable SSH on VWP_ADSRVR
2. Added public key to C:\ProgramData\ssh\administrators_authorized_keys; key auth landed as vwp\guru (domain admin)
3. Discovered server is Server 2019, not 2016 — unusable as DISM source for IMC
4. User pivoted: "a number of accounts are/were locked out"
5. Queried AD: lockout policy 5/16min/16min; scanner being locked out every ~20 min, 24/7 from VWP-QBS; also Receptionist once and Guest twice
6. Initially hypothesized stale scanner credential on some device; checked VWP-QBS via Invoke-Command with vwp\sysadmin:
   • No services or scheduled tasks running as scanner
   • No stored credentials (cmdkey /list empty)
   • 4625 failed logons showed w3wp.exe as the caller process (IIS worker)
7. Examined IIS config — no app pool running as scanner, no config file referenced scanner
8. Checked IIS access logs (C:\inetpub\logs\LogFiles\W3SVC1\u_ex260413.log) — found distributed attack in progress: POST /RDWeb/Pages/en-US/login.aspx from dozens of public IPs (China, Belarus, UAE, etc.) at ~6 req/min
9. User removed the UDM port forward exposing 443 to the internet
10. Attack traffic kept arriving briefly (in-flight connections); performed iisreset on VWP-QBS to drain
11. Verified: no IIS log activity after 17:15:28, no external established connections on 443
12. Re-enabled domain lockout policy (had temporarily disabled at user's request during diagnosis)
13. Ran 30-day 4624 audit for public IPv4 source addresses — zero successful external logons

Key finding

The scanner and Guest lockouts had nothing to do with internal stale credentials. They were the brute-force attacker trying common Windows usernames through the public-facing RDWeb portal. Lockout threshold 5 meant every 5 external attempts at scanner would trip the lockout, account auto-unlocked after 16 min, repeat.

Attacker source IPs observed (partial list, all public): 175.27.166.65, 1.13.91.38, 124.220.25.11, 116.63.167.144, 213.184.204.221, 49.235.60.135, 150.158.14.111, 129.211.14.197, 123.207.6.38, 111.231.15.117, 217.164.235.215, 203.143.83.36, 42.193.102.227, 124.71.205.87, 81.70.13.85, 139.9.90.166, 42.192.195.29, 177.21.61.100, 146.135.5.89

(Mix looks consistent with commodity botnet / residential proxy infrastructure — typical of opportunistic RDWeb sweeps.)

Actions taken

• SSH key auth added for guru@VWP_ADSRVR
• Default SSH shell: still cmd.exe (not changed — remote work used powershell -NoProfile -Command wrappers)
• Domain lockout policy: temporarily set threshold=0 (disabled) during diagnosis → restored to 5 / 16min / 16min once attack cause was understood and UDM change was in place
• IIS reset on VWP-QBS to drain attacker sessions (inetsrv W3SVC/WAS restarted)

Decisions / rationale

• Disabling lockout was a mistake in retrospect — I did it assuming stale-credential loop before seeing the attack. Once external source was identified, restored immediately. Window: ~15 minutes.
• Did not install IPBan — user chose to close exposure at the edge (UDM) instead. Appropriate since no documented need for public RDWeb was confirmed. IPBan recommended as a prerequisite if RDWeb is ever re-exposed.

Outstanding

• Audit UDM for UPnP (could let the server re-punch a hole)
• Document who actually needs RDWeb access and from where; if external is needed, require VPN + IPBan
• Rotate scanner account password as hygiene (PasswordLastSet 2024-10-17)
• Investigate the LastLogonDate: 9/28/2049 ghost on VWP-QBS AD object — likely time-skew artifact, cosmetic

Credentials referenced

• vwp\sysadmin — used for Invoke-Command double-hop from VWP_ADSRVR to VWP-QBS. Password handled verbally, not stored here.
• vwp\guru — domain admin, SSH key auth.