4.2 KiB
Command Usage
audit-settings
The audit-settings command checks the Windows event log audit policy settings and compares them with the recommended settings from Yamato Security, Microsoft(Sever/Client), and Australian Signals Directorate (ASD).
RuleCount indicates the number of Sigma rules that can detect events within that category.
audit-settings command examples
Check with the default Yamato Security's recommended settings and save results to CSV:
./WELA.ps1 audit-settings -Baseline YamatoSecurity
Check with the Australian Signals Directorate's recommended settings and save results to CSV:
./WELA.ps1 audit-settings -Baseline ASD
Check with Microsoft's recommended Server OS settings and display results in a GUI:
./WELA.ps1 audit-settings -Baseline Microsoft_Server -OutType gui
Check with Microsoft's recommended Client OS settings and display results in table format:
./WELA.ps1 audit-settings -Baseline Microsoft_Client -OutType table
audit-filesize
The audit-filesize command checks the Windows event logs' file size and compares them with the recommended settings from Yamato Security's recommendations.
audit-filesize command examples
Check the Windows event log file size with Yamato Security's recommendations and save results to CSV:
./WELA.ps1 audit-filesize -Baseline YamatoSecurity
configure
The configure command sets the recommended Windows event log audit policy and file size.
Domain NTLM auditing (AuditNTLMInDomain) is set to 7 (Enable all) only on
confirmed domain controllers. Windows clients, member/standalone servers and
non-DC AD CS servers report Not applicable and retain any existing value.
An unavailable or unknown computer role is reported as Unknown and skipped.
Role detection uses Win32_OperatingSystem.ProductType=2, not the presence of
AD DS tools or a registry key. Before a change, WELA reports the previous numeric
value; legacy value 2 is not described as full auditing. Changes respect the
usual confirmation prompt or -Auto and are verified by a registry read-back.
audit-settings includes role applicability and the current value in its console
and CSV output. Incoming and outgoing NTLM controls are separate from this policy.
The Microsoft NTLM auditing guidance
describes the policy and event collection prerequisites. A registry read-back
does not prove that events were generated, and GPO or MDM may overwrite a local
change. Validate benign domain NTLM activity and expected Operational events on
an isolated DC before deployment. tests/DomainNtlm.Tests.ps1 uses mocked OS and
registry access; the associated Windows workflow runs Windows PowerShell 5.1 and
PowerShell 7 without changing host policy.
Live-DC validation for issue #363
remains pending. Before closing that issue, record the Windows build and confirmed
DC role, the previous registry value/type, the verified AuditNTLMInDomain=7
DWORD, and representative NTLM event XML from benign test authentication. Also
check that a second run is idempotent and that clients, member servers and non-DC CAs leave
this domain-only setting unchanged. Mocked policy tests and console/CSV regression
tests do not provide this event-generation evidence.
configure command examples
Apply Yamato Security's recommended settings (with confirmation prompt before changing settings):
./WELA.ps1 configure -Baseline YamatoSecurity
Apply Australian Signals Directorate's recommended settings without confirmation prompt:
./WELA.ps1 configure -Baseline ASD -auto
update-rules
update-rules command examples
Update WELA's Sigma rules config files:
./WELA.ps1 update-rules