| 🔴 Critical | S2-KERB-001 |
Kerberoastable service accounts detected ▼ expand |
S² — Credential | 6 | 2026-05-15 |
Description 6 user accounts have Service Principal Names (SPNs) configured, making them Kerberoastable. An attacker with any valid domain credentials can request a Kerberos service ticket for these accounts and attempt to crack the password hash offline — with no noise on the network and no account lockout risk. Evidence SamAccountName SPN PasswordAge
--- --- -----------
svc_sql MSSQLSvc/db01.alpha-inv.co.ke 847 days
svc_backup BackupExec/bkp01.alpha-inv.co.ke 1,203 days
svc_erp HTTP/erp.alpha-inv.co.ke 612 days
svc_reports HTTP/reports.alpha-inv.co.ke 945 days
helpdesk_admin HTTP/helpdesk.alpha-inv.co.ke 388 days
svc_monitoring WSMAN/mon01.alpha-inv.co.ke 721 days Remediation 1. Audit each SPN — remove any that are not actively required.
2. Migrate all service accounts to Group Managed Service Accounts (gMSA).
3. For accounts that cannot use gMSA: reset passwords to 25+ character random strings immediately and enforce AES-only Kerberos encryption.
4. Enable "Protected Users" security group for all service accounts where possible.
Priority order: svc_sql and svc_backup first (oldest passwords, highest-privilege services). |
| 🔴 Critical | S2-ASRP-001 |
AS-REP roastable accounts — pre-auth disabled ▼ expand |
S² — Credential | 3 | 2026-05-15 |
Description 3 accounts have Kerberos pre-authentication disabled. This allows an unauthenticated attacker to request an AS-REP response, obtaining an encrypted hash that can be cracked offline without any valid domain credentials. Evidence SamAccountName Enabled PasswordLastSet
--- ------- ---------------
legacy_app_svc True 2023-11-04
testuser_old True 2022-08-17
api_connector True 2024-02-09 Remediation 1. Enable Kerberos pre-authentication on all 3 accounts immediately.
2. Reset passwords to 25+ character random strings.
3. Disable legacy_app_svc and testuser_old if no longer required.
This can be remediated in under 30 minutes. |
| 🔴 Critical | S1-PRIV-003 |
Domain Admins group contains 11 members — excessive privilege ▼ expand |
S¹ — Identity | 11 | 2026-05-15 |
Description The Domain Admins group contains 11 members — significantly above the recommended maximum of 2–3. Each DA account is a potential path to full domain compromise. 3 of these accounts have not logged in within the last 90 days, indicating they may be stale or service accounts incorrectly elevated. Evidence Domain Admins members (11):
Administrator, paul.admin, james.it, grace.it,
svc_deploy, backup_admin, helpdesk_lead,
legacy_admin, test_admin, mary.infra, peter.sec
Stale (>90 days no logon): svc_deploy, legacy_admin, test_admin Remediation 1. Remove all 11 accounts from Domain Admins.
2. Re-add only 2–3 named individuals who require DA privileges for day-to-day operations.
3. Disable svc_deploy, legacy_admin, and test_admin immediately — investigate before deletion.
4. Use just-in-time (JIT) privilege escalation for temporary DA access via PAM tools.
5. Enable DA logon auditing (Event ID 4672). |
| 🔴 Critical | S5-AUD-001 |
Advanced audit policy not configured — no privileged activity logging ▼ expand |
S⁵ — Detection | 2 DCs | 2026-05-16 |
Description Neither domain controller has Advanced Audit Policy configured. Critical security events — including privileged account usage (4672), Kerberos ticket activity (4769), GPO changes (5136), and account management events (4728) — are not being captured. An attacker with domain access could operate undetected. Evidence DC01 \ DC02 — Advanced Audit Policy:
Account Logon : Not Configured
Account Management : Not Configured
DS Access : Not Configured
Logon/Logoff : Not Configured
Privilege Use : Not Configured
Policy Change : Not Configured Remediation 1. Deploy Advanced Audit Policy via GPO (Computer Config → Windows Settings → Security Settings → Advanced Audit Policy).
2. Enable at minimum: Account Logon (Success+Failure), Account Management (Success), Privilege Use (Success), DS Access (Success), Policy Change (Success+Failure).
3. Set Security event log to minimum 512 MB and configure log forwarding to SIEM or centralised collector.
4. Required for SASRA and CBK compliance. Estimated effort: 4 hours. |
| 🟠 High | S1-STALE-001 |
47 enabled user accounts — no logon in 90+ days ▼ expand |
S¹ — Identity | 47 | 2026-05-15 |
Description 47 enabled Active Directory accounts have not logged on in over 90 days. Stale accounts represent a persistent attack surface — they are valid credential targets for password spraying, credential stuffing, and Kerberoasting. Former employees, contractors, and decommissioned service accounts are common causes. Remediation 1. Export the list and cross-reference with HR active employee records.
2. Disable (do not delete) all accounts with no business justification within 7 days.
3. Review and disable/delete within 30 days after confirming no service dependency.
4. Implement a quarterly stale account review process. Estimated effort: 3–4 hours. |
| 🟠 High | S2-PWD-001 |
Default domain password policy — minimum 7 characters, no complexity ▼ expand |
S² — Credential | All users | 2026-05-15 |
Description The domain password policy enforces a minimum of only 7 characters with basic complexity. This falls well below the NIST SP 800-63B recommendation of 8+ characters and CBK password guidelines. 7-character passwords are vulnerable to rapid offline cracking following a hash extraction. Evidence Default Domain Policy — Password Settings:
Minimum Length : 7 (recommended: 14+)
Complexity : Enabled (basic only)
Max Password Age : 42 days
Min Password Age : 1 day
History : 24 passwords
Reversible Enc. : Disabled Remediation 1. Update Default Domain Policy to minimum 14 characters.
2. Remove maximum password age (NIST recommends removing expiry in favour of length).
3. Implement a Fine-Grained Password Policy (FGPP) for privileged accounts — minimum 20 characters.
4. Enable HIBP (Have I Been Pwned) integration via Azure AD Password Protection or equivalent tool. |
| 🟡 Medium | S3-DEL-001 |
Unconstrained delegation configured on 2 non-DC computers ▼ expand |
S³ — Delegation | 2 | 2026-05-15 |
Description 2 non-DC computers (APP01, LEGACY-SRV) have unconstrained Kerberos delegation enabled. Any account that authenticates to a service on these servers will have their Kerberos TGT cached on the machine — extractable by an attacker with local admin access to impersonate any user, including Domain Admins. Remediation 1. Remove unconstrained delegation from APP01 and LEGACY-SRV.
2. Replace with constrained delegation (S4U2Proxy) or resource-based constrained delegation (RBCD) limited to specific SPNs.
3. Add all DA and sensitive accounts to the "Protected Users" group — prevents TGT delegation. |
| 🟡 Medium | S5-SMB-001 |
SMB signing not enforced on all domain members ▼ expand |
S⁵ — Detection | 18 hosts | 2026-05-16 |
Description SMB signing is not enforced across 18 domain member workstations and servers. Without SMB signing, an attacker on the local network can perform NTLM relay attacks — capturing authentication requests and relaying them to other services, potentially gaining administrative access without cracking any passwords. Remediation 1. Enable "Microsoft network server: Digitally sign communications (always)" via GPO on all domain computers.
2. Also enable "Microsoft network client: Digitally sign communications (always)".
3. Deploy via Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options.
Estimated effort: 1–2 hours (GPO deployment). |
| 🟡 Medium | I1-LAPS-001 | LAPS not deployed — shared local admin password across endpoints ▼ expand | I — Infrastructure | 63 endpoints | 2026-05-16 |
Description Windows LAPS (Local Administrator Password Solution) is not deployed. This means the local administrator password is likely the same across all 63 endpoints. If an attacker compromises any single machine, they can immediately authenticate to all other machines using pass-the-hash or pass-the-password techniques. Remediation 1. Deploy Windows LAPS (built into Windows 10 22H2+ / Windows 11 / Server 2019+).
2. Configure LAPS policy via GPO to rotate the local admin password every 30 days.
3. Store passwords in AD computer objects or Azure AD — readable only by authorised IT staff.
Estimated effort: 4 hours to deploy, 30 minutes per subsequent rotation review. |
| 🟡 Medium | S1-SHAD-001 | 4 shadow admin accounts detected (AdminCount=1, not in privileged group) ▼ expand | S¹ — Identity | 4 | 2026-05-15 |
Description 4 accounts have AdminCount=1 set but are not members of any privileged group. This indicates these accounts were previously added to a privileged group (triggering AdminSDHolder protection) and then removed — retaining a hardened ACL that prevents modification. 1 of these accounts has logged on in the last 30 days. Remediation 1. Investigate the recently-active shadow admin account immediately — treat as potential compromise indicator.
2. Clear AdminCount=0 on all 4 accounts after investigation.
3. Allow SDProp to revert ACLs (runs every 60 minutes).
4. Review account creation and modification history in event logs. |
| 🟡 Medium | S5-EVTLOG-001 | Security event log size insufficient — 20 MB on both DCs ▼ expand | S⁵ — Detection | 2 DCs | 2026-05-16 |
Description The Security event log on both domain controllers is configured to 20 MB with "overwrite events as needed". At current event volumes, logs are being overwritten within 24–48 hours. This makes forensic investigation of incidents impossible and violates SASRA record-keeping requirements. Remediation 1. Set Security log size to minimum 1 GB on each DC via GPO (Computer Config → Windows Settings → Security Settings → Event Log).
2. Configure log forwarding to a centralised SIEM or Windows Event Collector immediately.
3. Retain security logs for minimum 12 months per SASRA requirements.
Estimated effort: 1 hour. |
| ℹ Low | S1-PRIV-004 | Protected Users security group not utilised for privileged accounts ▼ expand | S¹ — Identity | All DAs | 2026-05-15 |
Description No accounts are members of the Protected Users security group. This group prevents: NTLM authentication, DES and RC4 Kerberos encryption, unconstrained delegation use, and TGT renewal beyond 4 hours — significantly hardening privileged accounts against credential theft. Remediation Add all Domain Admins and sensitive service accounts to the Protected Users security group. Test in a lab environment first — Protected Users restrictions may break legacy applications that rely on NTLM or RC4 Kerberos. Estimated effort: 2–4 hours including testing. |
| ℹ Low | S5-LDAP-001 | LDAP signing not required — LDAP relay possible ▼ expand | S⁵ — Detection | 2 DCs | 2026-05-16 |
Description LDAP signing is not required on the domain controllers. This enables LDAP relay attacks where an attacker with network access can relay LDAP authentication to the DC to perform privileged operations, including adding computer objects to the domain or modifying ACLs. Remediation 1. Set "Domain controller: LDAP server signing requirements" to "Require signing" via GPO.
2. Set "Network security: LDAP client signing requirements" to "Require signing" on all domain members.
3. Test all LDAP-dependent applications before enforcing — some legacy apps use unsigned LDAP.
Estimated effort: 2–3 hours including application testing. |
| ℹ Info | S1-ASSET-001 | 19 computer objects inactive for 180+ days — clean-up recommended ▼ expand | S¹ — Identity | 19 | 2026-05-15 |
Description 19 computer objects in Active Directory have not contacted the domain in 180+ days. These are likely decommissioned machines whose AD objects were not removed. Stale computer objects inflate the attack surface and create confusion in asset inventory. Remediation 1. Export the list and cross-reference with physical asset register and IT asset management system.
2. Disable objects not accounted for. Delete after 30-day confirmation period.
3. Implement a quarterly stale computer object review. Estimated effort: 2 hours. |