Files

Mike Swanson 5169936cfc Session log: IMC SQL move + DISM repair attempt, VWP RDWeb brute-force incident, Dataforth API planning

- IMC: document 716 GB SQL backup cleanup, retention scheduled task, DB move C:->S:, sysadmin grant via single-user recovery, parked RDS removal after KB5075999 apply rolled back on ETW manifest error
- Valleywide: document RDWeb brute-force incident on VWP-QBS, UDM port forward closure, 30-day audit showing no breach, lockout policy restoration
- Dataforth: capture Swagger API review and Hoffman Zoom call prep

2026-04-13 15:40:43 -07:00

2.4 KiB

Raw Blame History

Valleywide (VWP)

Infrastructure

Servers

VWP_ADSRVR (192.168.0.25)

Windows Server 2019 Standard (build 17763)
Domain Controller for vwp.local
SSH enabled (OpenSSH Server), key auth working for vwp\guru

VWP-QBS (172.16.9.169)

Windows Server 2022 Standard
Internal network only (172.16.9.0/24 reachable via VWP site VPN)
Runs QuickBooks + IIS with RD Gateway / RD Web Access (/RDWeb, /RDWeb/Pages, /RDWeb/Feed, /Rpc, /RpcWithCert)
WinRM available on 5985 (used for remote admin via Invoke-Command)

Networks

Internal: 172.16.9.0/24
One subnet also numbered 192.168.0.0/24 (conflicts with IMC's LAN if VPNs overlap — be careful switching contexts)

Access

SSH to VWP_ADSRVR: ssh vwp\guru@192.168.0.25 (ed25519 key, added 2026-04-13)
Double-hop to VWP-QBS: SSH won't forward Kerberos; use Invoke-Command -ComputerName VWP-QBS -Credential $cred with vwp\sysadmin PSCredential

Security posture

2026-04-13 incident

RDWeb (https://VWP-QBS/RDWeb/Pages/login.aspx) was exposed to the public internet via UDM port forward. Distributed brute-force attack was in progress (multiple external IPs, ~6 POSTs/min, hitting usernames like scanner, Guest, etc.). This was discovered while investigating repeated scanner account lockouts (event 4740) which originally looked like a stale service credential.

Actions taken:

UDM port forward removed (user action)
IIS reset on VWP-QBS to drain in-flight attacker sessions
Domain lockout policy restored (threshold 5, 16-min duration/window) after being temporarily disabled during diagnosis
30-day audit: no successful external logons — no compromise

Current state

RDWeb no longer reachable from public internet
Internal access still works on port 443 from within 172.16.9.0/24
Account lockout policy active

Recommendations (outstanding)

If RDWeb must be public again: deploy IPBan (https://github.com/DigitalRuby/IPBan) + firewall restriction to known client IPs
Audit UDM for UPnP (prevents the server from re-punching its own hole)
Consider 2FA / Conditional Access on any externally-reachable Windows service
Rotate scanner AD account password (last set 2024-10-17) as hygiene

Open items

Confirm UPnP state on UDM
Document intended RDWeb access pattern (who connects from where)
Add Valleywide entry to SOPS vault

2.4 KiB Raw Blame History