claudetools/clients/glaztech/session-logs/2026-06-04-session.md

Glaztech — Session Log 2026-06-04

User

• User: Mike Swanson (mike)
• Machine: GURU-5070
• Role: admin

Session Summary

Performed a read-only intrusion / brute-force log review on the Glaztech web server (WWW, agent 455a1bc7-1c29-42bc-b597-fa1e64f08eec, Windows Server 2019, agent v0.6.54) via GuruRMM, following up on the 2026-06-03 website security assessment. Question: is there evidence anyone tried to brute-force the website logins or the server itself.

Analyzed 7 days of IIS logs (C:\inetpub\logs\LogFiles\W3SVC4, ~52,000 requests, May 29 – Jun 4). Identified the two login endpoints (/customer_login.aspx, /emp/employee-login.aspx), then broke POSTs down per source IP with HTTP status codes. An initial pass flagged the employee portal as suspicious (381 "failures"/HTTP 200 vs 77 "successes"/302 — an inverted ratio vs the customer login). Pulling full per-IP request timelines corrected this: the employee login returns HTTP 200 on both success and failure (no redirect-on-success), so status code alone does not indicate a failed staff login. The top "suspect" IP 160.3.157.9 proved to be a single legitimate employee on an iPhone checking timecards. No brute-force or credential-stuffing signature exists on either endpoint.

Also reviewed the Windows Security event log (4625 failed logons / 4624 successes, 7-day window): only 13 failed logons, all LogonType 3 (SMB) from internal LAN IPs, zero external, no RDP failures, and no successful remote logons from public IPs — indicating RDP/SMB are not internet-exposed and nothing got in at the OS auth layer.

Folded the findings into the security record: added Appendix A — Intrusion / Brute-Force Log Review (2026-06-04) to clients/glaztech/reports/2026-06-03-website-security-assessment.md, and extended finding H5 with a detection-blind-spot note (200-on-both + no lockout + no failed-login logging = slow guessing would be invisible).

Key Decisions

• Used IIS request logs as the primary evidence source, not the Windows Security log, because the app's custom session-based auth never generates Windows logon events. The Security log was used only to rule out RDP/SMB brute force against the host.
• Did not treat HTTP 200 on the employee login as a failure once the timelines showed 200-on-success. Reported the corrected interpretation rather than the alarming-but-wrong intermediate read.
• Flagged the HTTP 500 bursts as worth an app-side look (possible SQLi error path per C3) but explicitly classified them as not-a-brute-force, to avoid overstating the threat.
• Recorded the detection gap as the actionable outcome — the review found no attacker, but confirmed that a slow guessing attack would currently be undetectable; reinforces the existing #32378 remediation (add lockout + failed-login logging).

Problems Encountered

• jq -n --arg heredoc capture glitched when dispatching the Security-log script (parse error / empty command). Resolved by writing the PowerShell to .claude/tmp/seclog.ps1 and passing it with jq --rawfile, which is robust against embedded quoting.
• IIS logs do not record POST bodies, so attempted usernames/passwords are not recoverable — noted as a limitation; confirming which accounts (if any) were targeted would require app-level auth logging that does not exist.

Configuration Changes

• Modified: clients/glaztech/reports/2026-06-03-website-security-assessment.md — added Appendix A (2026-06-04 log review); extended H5 with detection-blind-spot note + failed-login-logging fix; updated Status line.
• Created: clients/glaztech/session-logs/2026-06-04-session.md (this file).
• Local-only (gitignored): .claude/current-mode set to infra; transient .claude/tmp/seclog.ps1, .claude/tmp/rmm.token, .claude/tmp/rmm.cmd.

Credentials & Secrets

• None discovered or created. RMM admin credential read from vault infrastructure/gururmm-server.sops.yaml (unchanged).

Infrastructure & Servers

• WWW (Glaztech web server) — internal 192.168.8.72, public 65.113.52.88, Windows Server 2019 (build 17763), GuruRMM agent 455a1bc7-1c29-42bc-b597-fa1e64f08eec (v0.6.54), client "Glaztech Industries" / site "TUS - Tucson".
• Active IIS site: W3SVC4 (log dir C:\inetpub\logs\LogFiles\W3SVC4; daily u_exYYMMDD.log). Older sites W3SVC1/2/3 are stale (last writes 2018–2022).
• SQL backend (context only, not touched): 192.168.8.62,3436 (GTI-INV-SQL).

Commands & Outputs

• IIS analysis dispatched as PowerShell via GuruRMM (POST /api/agents/<id>/command), parsing #Fields-keyed log lines for cs-method, cs-uri-stem, c-ip, sc-status, date, time, cs(User-Agent).
• Key counts: customer login 2,547×302 / 78×200 / 5×500; employee login 77×302 / 381×200 / 6×500; 740 distinct IPs hit the login endpoints; 241 distinct IPs hit the employee login.
• Security log: span 2026-03-31 .. 2026-06-04; 4625 in last 7d = 13, all type 3, all internal, usernames = 12 blank + 1 tomabens; 4624 external type 3/8/10 = none.

Pending / Incomplete Tasks

• App-side investigation of the HTTP 500 bursts on post-login pages (possible SQLi error path) — IPs 201.146.179.166, 64.178.182.162, 205.185.107.49, 172.87.137.60. Not yet handed to Tom.
• #32378 (Waiting on Customer) unchanged: add account lockout + failed-login logging (now explicitly tied to this review), fix SQLi, least-privilege the tom/sysadmin DB login, separate website DB from GTIware, stop storing cards / never CVV, encrypt at rest.
• Optional confirming check offered but not run: enumerate listening/forwarded ports on WWW to turn "RDP almost certainly not exposed" into "confirmed."
• Carried over: corp DB cc_file "Invalid object name" anomaly; confirm Payrilla payment-flow scope.

Reference Information

• Report: clients/glaztech/reports/2026-06-03-website-security-assessment.md (Appendix A)
• Companion: clients/glaztech/reports/2026-06-03-pci-cardholder-data-finding.md
• Wiki: wiki/clients/glaztech.md
• Ticket: Syncro #32378 (Glaztech website security — Waiting on Customer)
• RMM API: http://172.16.3.30:3001 | agent id 455a1bc7-1c29-42bc-b597-fa1e64f08eec