Build the remaining Windows and domain hardening

Aperta
#103 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
bash, powershell

Direzione di ricerca

Start from branch phase-7/win-tier3 and the planned module at phases/harden/modules/win_tier3/. Read design 14 section 5 and design 12 specs, and review #83 for prior work. Write bats and Pester acceptance tests first covering KRBTGT reset and LDAP signing, then implement the hardening module. Done when all tests pass and domain weaknesses are remediated.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: accounts phase: harden platform: windows type: build

Read first

Read these before starting. If this issue and the spec disagree, the spec wins; say so in the pull request.

Summary

Build the Windows and domain hardening that needs a person's approval first: requiring LDAP signing, lockout settings, a per-host block for one abused download tool, and the KRBTGT reset. KRBTGT is the domain account whose password signs every Kerberos ticket; an attacker who has its hash can forge tickets until the password is reset twice, so Labyrinth carries out two resets with a replication check between them. Each change is an approval item: Labyrinth acts only after a person approves it.

Depends on

  • Blocked by #124 (the CI job that tests domain modules on a throwaway domain controller) and #83 (the Windows protocol and credential settings, which this builds on).

Location & Context

  • Branch: phase-7/win-tier3. Module ID: harden.win_tier3, in phases/harden/modules/win_tier3/ (new), with module.yml, the .ps1 entry points and about.txt (design 00, section 4). The module is Windows-only.
  • Tests: tests/phases/harden/win_tier3/ (new), in Pester.

Current Behavior

LDAP signing, lockout settings, the abused-tool block and the KRBTGT reset are not built, so the domain keeps these weaknesses.

Plan

  1. Build LDAP signing (listing every client seen in event 2889; a scored service among them blocks the change), lockout settings, the per-host abused-tool block and the remaining approval items of design 12, section 3.
  2. Build the KRBTGT reset: two resets with a replication check between (section 5.1), carried out after approval. The category krbtgt is never pre-approvable. If any domain controller does not report successful replication, block the item (20).

Acceptance tests

Write these first, in Pester:

  • With replication broken on one domain controller the KRBTGT reset is blocked and no password changes.
  • An approved KRBTGT reset changes the key version twice on every domain controller; a member server still logs on and every probe passes.
  • A lab client's unsigned LDAP bind is listed in the LDAP signing plan; when the client is a scored service, the change is blocked.
  • An approved certutil block stops it connecting out; rollback removes the rule.
  • Negative test: protected accounts and scored services are untouched before and after.

Done when

  • The Windows version passes CI, including the real-host tests on the domain controller CI job (#124).
  • The manual entry and the module's help page (about.txt) are written.
  • The module is added to the shipped profiles that use it.
  • The tests above pass in the lab on a domain controller, in both Windows Server versions the lab uses (docs/lab/README.md).

Out of scope

  • The protocol and credential settings (NTLM, WDigest, SMBv1, Print Spooler): #83.
  • The read-only domain checks and the printed checklist: #84.
  • Group Policy, domain password policy and DNS on the domain controller: a person does these from the checklist.
  • Watching abused tools through logging: #93 (Windows audit and Sysmon).
  • Undoing a KRBTGT reset: it cannot be undone, and rollback only records that.
Lingua principale
PowerShell
Stelle
0
Fork
0
Merge medio
2h 7m
PR unite (30g)
53

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Issue simili

Altre issue su Operating Systems

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.