azcomputerguru/claudetools
1
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
- 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
This commit is contained in:
Mike Swanson
2026-04-13 15:40:43 -07:00
parent a78fb96f95
commit 5169936cfc
6 changed files with 518 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
clients/valleywide/README.md Normal file
View File

@@ -0,0 +1,52 @@
# 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

59
clients/valleywide/session-logs/2026-04-13-rdweb-brute-force-incident.md Normal file
View File

@@ -0,0 +1,59 @@
# 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.