sync: auto-sync from GURU-5070 at 2026-06-04 07:07:43
Author: Mike Swanson Machine: GURU-5070 Timestamp: 2026-06-04 07:07:43
This commit is contained in:
@@ -149,7 +149,8 @@ SChannel: **TLS 1.0 Server `Enabled=1`** (and TLS 1.1 at OS default = enabled);
|
||||
- Custom **Session-variable auth** (no ASP.NET Forms auth); **no session-ID regeneration on login** → session-fixation risk.
|
||||
- **No `requireSSL`** and **no `httpOnlyCookies`** configured → cookies not marked Secure (site was HTTP-reachable until the 2026-06-03 HTTP→HTTPS redirect was added).
|
||||
- **No MFA, no account lockout / rate limiting**; username = customer **account number** (guessable) → brute-force exposure.
|
||||
- **Fix:** Secure+HttpOnly cookies, regenerate session on login, add lockout/throttling, consider MFA for employee/admin access.
|
||||
- **Detection blind spot (see Appendix A):** the employee login returns **HTTP 200 on both success and failure** (no redirect-on-success), and the app logs **no failed login attempts** anywhere. App-level auth never touches the Windows Security log. The net effect is that a slow credential-guessing attack against staff or customer accounts would be **effectively invisible** — there is no lockout to stop it and no log to detect it after the fact.
|
||||
- **Fix:** Secure+HttpOnly cookies, regenerate session on login, add lockout/throttling, **add failed-login logging (timestamp, username, source IP)**, consider MFA for employee/admin access.
|
||||
|
||||
### H6 — Database access model
|
||||
Web app connects with a **single shared SQL login (`tom`)** that has full read on card and password columns (no column-level control); **connection strings with credentials are in `Web.config`** on the web server (15+ per-office DBs). **Fix:** least-privilege per-function accounts, remove blanket card/password read, protect/secret-manage connection strings, enable TDE at rest.
|
||||
@@ -193,4 +194,37 @@ Web app connects with a **single shared SQL login (`tom`)** that has full read o
|
||||
|
||||
---
|
||||
|
||||
**Status:** Assessment complete 2026-06-03. **No changes were made to the application, database, or data during this assessment** (read-only). Findings to be reviewed with the client (Steve Eastman / Tom) as priority security and PCI remediation. This report contains no card numbers or passwords.
|
||||
## Appendix A — Intrusion / Brute-Force Log Review (2026-06-04)
|
||||
|
||||
**Question asked:** Is there evidence in the logs of anyone trying to brute-force the website logins (or the server)?
|
||||
**Method (read-only, via GuruRMM):** 7 days of IIS request logs (`C:\inetpub\logs\LogFiles\W3SVC4`, ~52,000 requests, May 29 – Jun 4) plus the Windows Security event log (4625 failed logons / 4624 successful logons, 7-day window; log retains 65 days back to 2026-03-31). No data was modified.
|
||||
|
||||
**Bottom line: NO evidence of a brute-force attack — not against the website logins, and not against the Windows server.**
|
||||
|
||||
### Website logins (IIS)
|
||||
Two login endpoints on the live site: `/customer_login.aspx` (customer portal) and `/emp/employee-login.aspx` (staff portal).
|
||||
|
||||
| Endpoint | Success | Fail | Reading |
|
||||
|---|---|---|---|
|
||||
| `/customer_login.aspx` | 2,547 (HTTP 302) | 78 (HTTP 200) | ~97% success — normal traffic across 740 distinct IPs, each logging in a few times/week |
|
||||
| `/emp/employee-login.aspx` | 77 (302) | 381 (200) | **Artifact, not failures** — see below |
|
||||
|
||||
- **Important interpretation correction:** the employee login returns **HTTP 200 on BOTH success and failure** (it does not use the post-redirect-get/302 pattern the customer login uses). Status code alone therefore does **not** indicate a failed staff login. The apparent "381 failures" is a measurement artifact. Confirmed by pulling full request timelines: the top "suspect" IP `160.3.157.9` (24 hits, "0 successes" by the 302 metric) is a single legitimate employee on an iPhone (consistent iOS 18.7 Safari UA all week) who POSTs the login and then loads `/emp/check-hours2.aspx` + `/emp/index.aspx` with real content — i.e. a logged-in employee checking a timecard. Every "failure-heavy" employee IP fits the same benign shape (residential IP, single consistent device UA, reaches protected pages).
|
||||
- **No brute-force / credential-stuffing signature** anywhere: no single IP firing rapid high-volume login POSTs, no username-cycling at machine speed, no scanner/bot user-agents hammering the login.
|
||||
- **Minor observation (not an attack):** scattered bursts of **HTTP 500** on post-login pages (`invoices.aspx`, `quotes.aspx`, `place_orders.aspx`, `billing-statements.aspx`, `online-payment-pnc.aspx`) — several IPs firing 8–17 identical 500s within a single second (automated, not human clicking). Source IPs incl. `201.146.179.166`, `64.178.182.162`, `205.185.107.49`, `172.87.137.60`. These read more like a buggy page than a campaign (different pages, different residential IPs, normal browser UAs), **but** given C3 (the SQL-injectable `quo()` path), a 500 on a login/data page is exactly what a quote character in input produces against that code — worth an app-side look at what those pages throw. IIS does not log POST bodies, so the attempted inputs are not recoverable from these logs.
|
||||
|
||||
### Windows server (Security log)
|
||||
- **13** failed logons (4625) in 7 days — trivial volume (an internet-exposed Windows host sees thousands/day).
|
||||
- **All 13 were LogonType 3 (SMB/network), 100% from internal LAN IPs, zero from any public IP.** No RDP (type 10) failures at all.
|
||||
- Targeted usernames: 12 blank (null/anonymous SMB) + 1 `tomabens` (internal — a stale cached credential or service, not an attack).
|
||||
- **No successful remote logons from any external IP** (4624 type 3/8/10).
|
||||
- **Inference:** the absence of *any* external 4625 strongly indicates RDP/SMB are **not internet-exposed** (a reachable RDP port produces a relentless type-10 failure stream within hours). The only meaningful internet-facing attack surface is the web application on 443 — which is exactly where the risk in this report lives.
|
||||
|
||||
### Takeaway for remediation
|
||||
The review found no attacker, but it confirmed the **detection gap** noted in H5: 200-on-both responses + no lockout + no failed-login logging mean a slow guessing attack would be invisible here. **Add failed-login logging and account lockout** (already on the roadmap) — without them, "has anyone tried to break in?" cannot be answered with confidence going forward. Re-run this same log review periodically.
|
||||
|
||||
*Read-only review. No card numbers, passwords, or POST bodies were retrieved or are reproduced.*
|
||||
|
||||
---
|
||||
|
||||
**Status:** Assessment complete 2026-06-03; intrusion/brute-force log review added 2026-06-04 (Appendix A). **No changes were made to the application, database, or data** (read-only throughout). Findings to be reviewed with the client (Steve Eastman / Tom) as priority security and PCI remediation. This report contains no card numbers or passwords.
|
||||
|
||||
65
clients/glaztech/session-logs/2026-06-04-session.md
Normal file
65
clients/glaztech/session-logs/2026-06-04-session.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# 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`
|
||||
@@ -2,7 +2,7 @@
|
||||
type: client
|
||||
name: glaztech
|
||||
display_name: Glaz-Tech Industries
|
||||
last_compiled: 2026-06-03
|
||||
last_compiled: 2026-06-04
|
||||
compiled_by: DESKTOP-0O8A1RL/claude-main
|
||||
sources:
|
||||
- clients/glaztech/session-logs/2026-04-20-session.md
|
||||
@@ -10,6 +10,7 @@ sources:
|
||||
- clients/glaztech/session-logs/2026-05-28-session.md
|
||||
- clients/glaztech/session-logs/2026-06-02-session.md
|
||||
- clients/glaztech/session-logs/2026-06-03-session.md
|
||||
- clients/glaztech/session-logs/2026-06-04-session.md
|
||||
- clients/glaztech/reports/2026-04-17-phishing-incident-report.md
|
||||
- clients/glaztech/reports/2026-06-03-pci-cardholder-data-finding.md
|
||||
- clients/glaztech/reports/2026-06-03-website-security-assessment.md
|
||||
@@ -39,7 +40,7 @@ Multi-site Windows environment (~200 users, 9 locations). Active Directory confi
|
||||
|
||||
| Server | Role | OS / Build | Local IP | Public IP | Notes |
|
||||
|---|---|---|---|---|---|
|
||||
| WWW | IIS web server — customer/e-commerce site | Windows Server 2019 Standard, build 10.0.17763.8755 (patched ~May 2026) | 192.168.8.72 | 65.113.52.88 | IIS 10.0, .NET 4.8; site `glaztech_new` at `D:\web\glaztech_4`; full VB.NET source on disk (not precompiled); LE cert CN=www.glaztech.com, SAN apex+www, exp 2026-08-19 via Certify The Web (HTTP-01); GuruRMM agent 455a1bc7-1c29-42bc-b597-fa1e64f08eec; **doubles as dev workstation** (VS 2015+2022 installed — see Security Posture) |
|
||||
| WWW | IIS web server — customer/e-commerce site | Windows Server 2019 Standard, build 10.0.17763.8755 (patched ~May 2026) | 192.168.8.72 | 65.113.52.88 | IIS 10.0, .NET 4.8; site `glaztech_new` at `D:\web\glaztech_4`; full VB.NET source on disk (not precompiled); LE cert CN=www.glaztech.com, SAN apex+www, exp 2026-08-19 via Certify The Web (HTTP-01); GuruRMM agent 455a1bc7-1c29-42bc-b597-fa1e64f08eec (v0.6.54); **doubles as dev workstation** (VS 2015+2022 installed — see Security Posture); active IIS site W3SVC4 (log dir `C:\inetpub\logs\LogFiles\W3SVC4`; older sites W3SVC1/2/3 stale, last writes 2018–2022) |
|
||||
| GTI-INV-SQL | SQL Server — website backend + GTIware PSA (shared instance) | [unverified — Server OS not confirmed; co-located with GTI/Glaztech infra] | 192.168.8.62,3436 | — | **Hostname: GTI-INV-SQL.** Login `tom` = named SQL login (SQL auth, created 2018), **member of `sysadmin` server role** (also securityadmin, dbcreator, db_owner); password embedded in site `Web.config` (NOT vaulted). **46 databases total:** all offices' `glaz_prod*` + `*_archive` databases, PDF stores, `qqest` (TimeForce payroll), `gti_samsara`, `mas_gti` (Sage 100), system DBs (`master`, `msdb`). Other sysadmin logins on instance: `GTI-INV-SQL\Administrator`, `NT SERVICE\*`, `sa` (enabled), `tom`. |
|
||||
|
||||
| Service | Details | Notes |
|
||||
@@ -79,7 +80,7 @@ Full transport rule list as of 2026-06-02:
|
||||
|
||||
Rule GUIDs: Priority 2 = 482c714a-8780-4c62-ae0a-0b6da9ca9d52; Priority 3 = 7e0c01a8-ec22-43fe-b600-796c0f295aa5. GUIDs for Priority 0, 1, 4 not recorded.
|
||||
|
||||
Note on Priority 1: The "GTIMail No-Reply - Reject Inbound" rule rejects ALL inbound mail to gtimail@glaztech.com, which causes the daily MailProtector digest for that address to fail. This is a pre-existing rule — review with Steve is pending (see Active Work).
|
||||
Note on Priority 1: The "GTIMail No-Reply - Reject Inbound" transport rule rejects ALL inbound mail to gtimail@glaztech.com, which causes the daily MailProtector digest for that address to fail. This is a pre-existing rule — review with Steve is pending (see Active Work).
|
||||
|
||||
### Inbound Connector
|
||||
|
||||
@@ -117,13 +118,13 @@ Note on Priority 1: The "GTIMail No-Reply - Reject Inbound" rule rejects ALL inb
|
||||
|
||||
**Classification: CONFIDENTIAL/Security.** Full detail in:
|
||||
- `clients/glaztech/reports/2026-06-03-pci-cardholder-data-finding.md`
|
||||
- `clients/glaztech/reports/2026-06-03-website-security-assessment.md`
|
||||
- `clients/glaztech/reports/2026-06-03-website-security-assessment.md` (incl. Appendix A — Intrusion/Brute-Force Log Review, 2026-06-04)
|
||||
|
||||
A full read-only security assessment of the Glaztech e-commerce web application and SQL backend was performed 2026-06-03. Overall risk: **CRITICAL**. Key findings (no card numbers or passwords are reproduced here):
|
||||
A full read-only security assessment of the Glaztech e-commerce web application and SQL backend was performed 2026-06-03. A follow-up read-only intrusion/brute-force log review was performed 2026-06-04 (see Appendix A in the assessment report). Overall risk: **CRITICAL**. Key findings (no card numbers or passwords are reproduced here):
|
||||
|
||||
### C0 (TOP CRITICAL) — Website connects to `GTI-INV-SQL` as `sysadmin`
|
||||
|
||||
**This is the single most dangerous finding.** The public website at `D:\web\glaztech_4` logs into the SQL server `GTI-INV-SQL` (192.168.8.62,3436) using SQL login **`tom`** — a **named SQL login** (SQL auth, created 2018, NOT the built-in `sa`) that is a **member of the `sysadmin` server role** (also securityadmin, dbcreator, db_owner). The password is **embedded in the site's `Web.config`** on the internet-facing server.
|
||||
**This is the single most dangerous finding.** The public website at `D:\web\glaztech_4` logs into the SQL server `GTI-INV-SQL` (192.168.8.62,3436) using SQL login **`tom`** — a **named SQL login** (SQL authentication, created 2018, NOT the built-in `sa`) that is a **member of the `sysadmin` server role** (also securityadmin, dbcreator, db_owner). The password is **embedded in the site's `Web.config`** on the internet-facing server.
|
||||
|
||||
That same SQL instance (`GTI-INV-SQL`) is **shared with GTIware** (Tom's internal PSA) and hosts **46 databases**: all offices' `glaz_prod*` + `*_archive`, PDF stores, `qqest` (TimeForce payroll), `gti_samsara`, `mas_gti` (Sage 100), and system DBs.
|
||||
|
||||
@@ -175,12 +176,31 @@ Used to build concatenated dynamic SQL in payment pages (`ach.aspx.vb`, `quick-p
|
||||
| Remote-access sprawl: RealVNC Enterprise E4.2.8 (~2009, EoL), stale ScreenConnect v6.0.11622 (2018), Splashtop, Datto RMM+EDR, Syncro, GuruRMM (6+ agents) | High |
|
||||
| Server listener accepts TLS 1.0 + 1.1 (SChannel Enabled=1) | High |
|
||||
| Single shared SQL login (`tom`) with sysadmin rights; creds in `Web.config` in cleartext | High |
|
||||
| No Secure/HttpOnly cookies; no session regeneration on login; session-fixation risk | High |
|
||||
| No Secure/HttpOnly cookies; no session regeneration on login; session-fixation risk; no MFA, no lockout; H5 detection blind spot (see below) | High |
|
||||
|
||||
### H5 Detection Blind Spot — No Failed-Login Visibility
|
||||
|
||||
The employee login (`/emp/employee-login.aspx`) returns **HTTP 200 on both success and failure** — the status code is NOT a success/failure signal for staff logins (no post-redirect-get pattern). The app logs **no failed login attempts** anywhere, and app-level auth never touches the Windows Security log. The net effect: a slow credential-guessing attack against staff or customer accounts would be **effectively invisible** — there is no lockout to stop it and no log to detect it after the fact. (Confirmed during the 2026-06-04 log review — see Appendix A of the assessment report.)
|
||||
|
||||
**Fix:** add failed-login logging (timestamp, username, source IP) to the application; add account lockout/throttling; consider MFA for employee/admin access.
|
||||
|
||||
### Attack Chain Summary
|
||||
|
||||
Obtain a customer login (LOW difficulty — no lockout, guessable username = account number, plaintext passwords as short as 3 chars) → access payment pages → SQL inject with `quo()` → executes as **sysadmin** on `GTI-INV-SQL` → full read/write/DROP of all 46 databases, `xp_cmdshell` OS takeover, network pivot. **Every compensating control (lockout, password hashing, PAN encryption, parameterized queries, least-privilege DB login) is absent; first failure is last failure.**
|
||||
|
||||
### Intrusion / Brute-Force Log Review — 2026-06-04 (No Evidence of Attack)
|
||||
|
||||
A read-only review via GuruRMM was performed 2026-06-04 covering 7 days of IIS logs (`W3SVC4`, ~52,000 requests, May 29 – Jun 4) and the Windows Security event log (4625/4624, 7-day window; log retains back to 2026-03-31).
|
||||
|
||||
**Bottom line: NO evidence of a brute-force attack — not against the website logins, and not against the Windows server.**
|
||||
|
||||
- **Website logins (IIS):** Customer login (`/customer_login.aspx`) shows 2,547 HTTP 302 (success) / 78 HTTP 200 / 5 HTTP 500 across 740 distinct IPs — normal traffic. Employee login (`/emp/employee-login.aspx`) showed 77 HTTP 302 / 381 HTTP 200 / 6 HTTP 500; the apparent imbalance is an artifact — the employee login returns HTTP 200 on BOTH success and failure (no redirect-on-success). Top "suspect" IP `160.3.157.9` (24 hits) is a single legitimate employee on an iPhone checking timecards. No brute-force / credential-stuffing signature (no rapid high-volume POSTs, no username-cycling at machine speed, no bot UAs).
|
||||
- **HTTP 500 bursts (open item):** Scattered bursts of HTTP 500 on post-login pages (`invoices.aspx`, `quotes.aspx`, `place_orders.aspx`, `billing-statements.aspx`, `online-payment-pnc.aspx`) from IPs `201.146.179.166`, `64.178.182.162`, `205.185.107.49`, `172.87.137.60` — 8–17 identical 500s within a single second per IP. Not classified as a brute-force campaign, but given C3 (the `quo()` SQLi path), a quote character in input on those pages produces exactly a 500 error — worth an app-side look. IIS does not log POST bodies, so attempted inputs are not recoverable.
|
||||
- **Windows Security log:** Only 13 failed logons (4625) in 7 days — all LogonType 3 (SMB/network), 100% from internal LAN IPs, zero from any public IP. No RDP (type 10) failures at all. Targeted usernames: 12 blank (null/anonymous SMB) + 1 `tomabens` (internal stale credential). No successful remote logons from any external IP. Inference: RDP/SMB are not internet-exposed — no external host got in at the OS auth layer.
|
||||
- **Detection gap confirmed (see H5):** The review found no attacker, but confirmed that a slow guessing attack would currently be undetectable without failed-login logging + lockout. Both are already on the #32378 remediation roadmap.
|
||||
|
||||
Full detail in `clients/glaztech/reports/2026-06-03-website-security-assessment.md` (Appendix A).
|
||||
|
||||
### Remediation Roadmap (Ticket #32378 — Waiting on Customer)
|
||||
|
||||
**Now (days) — requires client sign-off:**
|
||||
@@ -193,7 +213,7 @@ Obtain a customer login (LOW difficulty — no lockout, guessable username = acc
|
||||
**Short term (weeks):**
|
||||
6. Hash all passwords (PBKDF2/bcrypt/Argon2); replace email-the-password flow with reset-token flow; force global reset
|
||||
7. Parameterize all concatenated SQL in payment pages; delete `quo()`
|
||||
8. Add Secure+HttpOnly cookies, session regeneration on login, login throttling/lockout
|
||||
8. Add Secure+HttpOnly cookies, session regeneration on login, login throttling/lockout, **failed-login logging (timestamp, username, source IP)**
|
||||
9. Migrate card-on-file to the chosen processor's token vault (CyberSource or new provider — confirm which flows actually route through "Payrilla"); purge/encrypt historical `cc_number` columns; address backups
|
||||
|
||||
**Structural:**
|
||||
@@ -220,6 +240,7 @@ Obtain a customer login (LOW difficulty — no lockout, guessable username = acc
|
||||
- **Glaztech custom web app — stored card feature requires tokenization to remediate safely:** Cards in `cc_file` are there for GTIware auto-pay via `gt_auto_process_2020.dll`. Deleting the PANs without a replacement breaks the auto-billing feature. The safe path is processor token vault migration (tokenize on write, replace stored PAN with token, update `gt_auto_process` to bill by token). Quick win: purge CVV (`cc_code`) immediately — this has no functional impact and is the fastest PCI Req 3.2 remediation.
|
||||
- **Glaztech SQL login (`tom`) + Web.config creds are NOT in the SOPS vault.** Do not commit these credentials. If future automation needs SQL access, vault them first. This login has sysadmin rights — treat any use with corresponding care.
|
||||
- **Internet-facing website + internal PSA (GTIware) share one SQL instance; website connects as sysadmin → any website SQLi = full internal-DB compromise.** The public website (`WWW`, 65.113.52.88) and GTIware (the internal card-on-file PSA) both use `GTI-INV-SQL` (192.168.8.62,3436). The web login `tom` is sysadmin. A SQL injection on the website executes as sysadmin against the entire 46-DB instance — cross-DB reads confirmed live. Public web apps must use least-privilege DB logins isolated from internal data. Internet-facing apps must never share a SQL instance with an internal PSA without strict permission partitioning.
|
||||
- **Employee login HTTP 200 on both success and failure — status code is not a success/failure signal; no failed-login logging exists:** `/emp/employee-login.aspx` returns HTTP 200 regardless of outcome (no redirect-on-success pattern). The application logs no failed login attempts anywhere, and app-level auth does not generate Windows Security log events. A slow credential-guessing campaign against staff or customer accounts would be completely invisible: no lockout triggers, no log to audit after the fact. Confirmed during the 2026-06-04 log review — the 381 "200 responses" on the employee portal that initially appeared anomalous proved to be normal authenticated sessions. Fix: add failed-login logging + account lockout. Do not treat HTTP status code as an auth-outcome signal on this endpoint.
|
||||
|
||||
## Active Work
|
||||
|
||||
@@ -247,7 +268,7 @@ MFA rollout plan: Phase 1 — user communication (install Authenticator); Phase
|
||||
|
||||
### Website Security Remediation (Ticket #32378 — Waiting on Customer)
|
||||
|
||||
Security assessment complete 2026-06-03. Assessment and reports delivered to client (Steve/Tom). Tom replied 2026-06-03 confirming that the website stores no cards (correct); investigation of his reply surfaced C0 (sysadmin login). Reply posted on #32378 explaining the sysadmin+SQLi chain and the four required remediations. Ticket set to **Waiting on Customer** — Tom/Steve to remediate. ACG can execute quick wins (CVV purge, least-privilege login, debug-off) on client go-ahead.
|
||||
Security assessment complete 2026-06-03. Intrusion/brute-force log review complete 2026-06-04 (no attacker found; detection gap confirmed). Assessment and reports delivered to client (Steve/Tom). Tom replied 2026-06-03 confirming that the website stores no cards (correct); investigation of his reply surfaced C0 (sysadmin login). Reply posted on #32378 explaining the sysadmin+SQLi chain and the four required remediations. Ticket set to **Waiting on Customer** — Tom/Steve to remediate. ACG can execute quick wins (CVV purge, least-privilege login, debug-off) on client go-ahead.
|
||||
|
||||
Key actions queued but not yet executed (require client sign-off):
|
||||
- Pull `tom` sysadmin login from the website → replace with least-privilege login that cannot see GTIware data (HIGHEST PRIORITY)
|
||||
@@ -255,6 +276,8 @@ Key actions queued but not yet executed (require client sign-off):
|
||||
- `debug="false"` + `customErrors="On"` — can apply quickly with low risk
|
||||
- Remove RealVNC 4.2.8 and stale ScreenConnect v6
|
||||
- Disable TLS 1.0/1.1 on IIS/SChannel listener
|
||||
- Add failed-login logging + account lockout (reinforced by 2026-06-04 log review finding)
|
||||
- App-side investigation of 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
|
||||
|
||||
### gtimail@glaztech.com Daily Digest Failure (Pending — review with Steve)
|
||||
|
||||
@@ -278,6 +301,7 @@ Message trace confirmed shannon@glaztech.com receives no MailProtector digests a
|
||||
- Tom code fallback (`ServicePointManager.SecurityProtocol = Tls12` in app code) staged but not deployed — can apply if registry fix ever regresses
|
||||
- Investigate `corp` DB `cc_file` "Invalid object name" anomaly (existed 2026-06-03 morning with 3 rows, then returned "Invalid object name" later same day — per-office DBs unaffected)
|
||||
- Confirm with Tom/Payrilla which flows actually route through Payrilla, and whether a migration to tokenized card storage via the new provider is planned for the website
|
||||
- Optional: enumerate listening/forwarded ports on `WWW` to confirm RDP is not internet-exposed (log review strongly implies it is not; a port enumeration would make it definitive)
|
||||
|
||||
## History Highlights
|
||||
|
||||
@@ -290,6 +314,7 @@ Message trace confirmed shannon@glaztech.com receives no MailProtector digests a
|
||||
- **2026-06-02** — MailProtector quarantine digest messages from `noreply@azcomputerguru.com` confirmed hitting `FilteredAsSpam` for some recipients (e.g., tshaw@glaztech.com). Transport rule created: "SCL Bypass - noreply@azcomputerguru.com (MailProtector digests)" at Priority 4 (From=noreply@azcomputerguru.com, SetSCL=-1). Message trace via `Get-MessageTraceV2` also revealed `gtimail@glaztech.com` failing daily due to pre-existing Priority-1 reject rule — flagged for Steve review.
|
||||
- **2026-06-03 (earlier)** — Three tickets on web server `WWW` (192.168.8.72 / 65.113.52.88), all via GuruRMM. (1) **Apex 404 emergency:** glaztech.com returned 404 (IIS site `glaztech_new` had www-only binding); added apex http:80+https:443 bindings (cert SAN already covered apex), then added HTTP→HTTPS 301 URL Rewrite redirect with `/.well-known/acme-challenge/` exclusion (Certify/LE HTTP-01 renewal safe). `web.config.bak-20260603-090701` created. Ticket #32376 — Resolved, 1h remote. (2) **CyberSource payment outage ("Could not create SSL/TLS secure channel"):** CyberSource (PNC merchant processor) disabled TLS 1.0/1.1; .NET 4.x on Server 2019 defaulted to old TLS. Fix: `SchUseStrongCrypto=1` + `SystemDefaultTlsVersions=1` in both `.NETFramework\v4.0.30319` hives + app pool `glaztech_new` recycle. Verified via payments DB (credit-card approval at 09:36 post-fix). Ticket #32377 — Resolved, 1.5h emergency remote. (3) **Security assessment:** read-only deep inspection of IIS config, VB.NET source, and SQL backend revealed CRITICAL posture. Sage 100 (`mas_gti`) confirmed NOT a cardholder-data location — CC module disabled (0 stored cards). Two reports created. Ticket #32378 opened. Billed 1h remote. Prepaid block: 26.5 → 22.25 hrs. Also: shannon@glaztech.com digest-not-received confirmed as MailProtector provisioning issue (not Exchange) — requires MailProtector partner-portal fix. Payrilla/CyberSource reconciliation: live system confirmed website is still on CyberSource/PNC with daily ongoing card writes.
|
||||
- **2026-06-03 (late — ~19:32 PT)** — **Tom (GTIware dev) replied to #32378** clarifying that the website's online payment system stores no card data — he is correct. Investigation of Tom's reply surfaced the **top critical finding (C0):** the website connects to the shared SQL server `GTI-INV-SQL` (192.168.8.62,3436) as SQL login `tom`, a **named SQL login that is a member of the `sysadmin` role** (created 2018; password in `Web.config`). The instance hosts 46 databases shared between GTIware and the website. Because SQLi executes as the connecting login, the website's `quo()` injection = sysadmin over the entire `GTI-INV-SQL` instance; cross-database card-table reads confirmed live. **Attribution corrected in both reports:** the website is the access path (C0); GTIware (staff-operated) writes the cards. Sage CC module confirmed disabled (0 stored cards, not a CHD location). Both reports updated. Plain-English reply posted to Tom on #32378 (public+emailed, comment 417070212) explaining the sysadmin+SQLi chain and the four required fixes. Ticket set to **Waiting on Customer**.
|
||||
- **2026-06-04** — **Read-only intrusion/brute-force log review** on `WWW` (GuruRMM agent 455a1bc7, v0.6.54). Reviewed 7 days of IIS W3SVC4 logs (~52,000 requests, May 29 – Jun 4) and Windows Security event log (4625/4624 events, 7-day window, log retained back to 2026-03-31). **Finding: NO evidence of a brute-force or intrusion attempt** against the website logins or the Windows server. Customer login traffic is normal (2,547 successes/740 IPs). Employee login: initial "381 failures" corrected — the employee login returns HTTP 200 on BOTH success and failure (status code is not an auth-outcome signal); all flagged IPs proved to be legitimate employees reaching protected pages post-login. Windows Security log: 13 failed logons in 7 days, all SMB type 3 from internal LAN IPs, zero external, no RDP failures — RDP/SMB not internet-exposed. **Key confirmation:** the H5 detection blind spot is real — 200-on-both + no failed-login logging + no lockout = a slow guessing attack would currently be completely invisible. HTTP 500 bursts on post-login pages flagged as an open app-side item. Findings folded into the security report as Appendix A. Ticket #32378 remains Waiting on Customer.
|
||||
|
||||
## Backlinks
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Wiki Index
|
||||
|
||||
Last updated: 2026-06-03
|
||||
Last updated: 2026-06-04
|
||||
Compiled by: GURU-BEAST-ROG/claude-main
|
||||
|
||||
This wiki is LLM-maintained. Do not edit articles manually — run `/wiki-compile` to update.
|
||||
@@ -25,7 +25,7 @@ Run `/wiki-lint` to check for stale entries and broken backlinks.
|
||||
| [ACG Internal Infrastructure](clients/internal-infrastructure.md) | ACG's own hosting infra — Neptune Exchange (cert expires 2026-05-31, DkimSigner disabled), IX server, Cloudflare tunnel workaround, ACG M365 tenant gaps | 2026-05-24 |
|
||||
| [BirthBiologic](clients/birth-biologic.md) | Bio/healthcare; BB-SERVER (WS2016) GuruRMM enrolled; Datto→SharePoint migration incomplete; M365 apps partially consented | 2026-05-24 |
|
||||
| [CryoWeave](clients/cryoweave.md) | Custom cryogenic cable assemblies; cPanel on IX; website redesign + SEO project in progress; Syncro ID not documented | 2026-05-24 |
|
||||
| [Glaz-Tech Industries](clients/glaztech.md) | ~200 users, 9 locations; prepaid ~22.25 hrs; web server WWW (192.168.8.72 / 65.113.52.88) — IIS 10/VB.NET e-commerce; CRITICAL security posture: website connects to GTI-INV-SQL as sysadmin (login `tom`, named SQL login, C0 top finding) + plaintext PANs+CVV (stored by GTIware PSA, not website) + plaintext passwords + SQLi via `quo()` + XSS; apex 404 fixed + payment TLS fixed 2026-06-03; #32378 Waiting on Customer (assessment + reports delivered, Tom replied); M365 no MFA; SCL bypass rules for vendor DMARC + MailProtector digests | 2026-06-03 |
|
||||
| [Glaz-Tech Industries](clients/glaztech.md) | ~200 users, 9 locations; prepaid ~22.25 hrs; web server WWW (192.168.8.72 / 65.113.52.88) — IIS 10/VB.NET e-commerce; CRITICAL security posture: website connects to GTI-INV-SQL as sysadmin (login `tom`, named SQL login, C0 top finding) + plaintext PANs+CVV (stored by GTIware PSA, not website) + plaintext passwords + SQLi via `quo()` + XSS; apex 404 fixed + payment TLS fixed 2026-06-03; intrusion/brute-force log review 2026-06-04 (no attacker found; H5 detection blind spot confirmed — HTTP 200 on both success/failure + no failed-login logging); #32378 Waiting on Customer (assessment + reports + Appendix A delivered); M365 no MFA; SCL bypass rules for vendor DMARC + MailProtector digests | 2026-06-04 |
|
||||
| [Grabb & Durando Law Office](clients/grabb-durando.md) | Personal injury law firm; GND-SERVER GuruRMM enrolled; AI demand review app scoped ($4K–$7K); website migration pending; plaintext DB password in README needs vaulting | 2026-05-24 |
|
||||
| [Pavon](clients/pavon.md) | Former/archive client; GeoVision NVR surveillance; OwnCloud at 172.16.3.22 backed by Uranus; cron stacking fixed; Nextcloud migration deferred 3–6 months | 2026-05-24 |
|
||||
| [Rednour Law Offices](clients/rednour.md) | Law firm; M365 rednourlaw.com (tenant 4a4ca18a) fully onboarded 2026-05-31; all 5 ComputerGuru SPs consented; no MDE license; 3 workstations GuruRMM enrolled (FRONTDESKRECEPT/LEGALASST/REDNOURCARRIEVI); Carla Skinner renamed from Emma; prior MSP agents (ScreenConnect/Splashtop/Datto) still present; shared-drive access for Nick Pafford deferred | 2026-06-02 |
|
||||
|
||||
Reference in New Issue
Block a user