Hello everyone,
I’m seeking help regarding a persistent "FAIL" on a custom SCA check for Windows 11 (localized in French). Despite the Guest account being confirmed as disabled, the SCA engine keeps reporting it as "Active" or fails to parse the command correctly.
Context:
Environment: Windows 11 (localized in French).
Goal: Detect if the built-in Guest account (Invité/Guest) is enabled.
Wazuh Version: [Indiquez votre version, ex: 4.14
The Problem: When using Get-LocalUser, the command often fails in SCA because of syntax interpretation or because the account name varies between "Invité" and "Guest".
Current Check in YML:
What I've tried:
Verified manually: net user Invité returns "Compte actif : Non".
Used $_ in PowerShell, but it caused a ParserError: ExpectedValueExpression in the logs.
Tried targeting the SID (S-1-5-21-*-501) to avoid language issues, but the result remains inconsistent.
Question: Has anyone successfully implemented a robust check for the Guest account status that works regardless of the OS language? Is there a better way to handle the output piping in the SCA YML to avoid parser errors with Where-Object?
Any help or example of a working YML configuration for this specific check would be greatly appreciated.
Best regards,
Hello,
It seems to me this is happening due to the command you are using.
Based on findings, this is not a valid command.
& powershell.exe -ExecutionPolicy Bypass -Command \"if (Get-LocalUser -Name *Invité*,*Guest* -ErrorAction SilentlyContinue | Where-Object Enabled) { 'Active' } else { 'Disabled' }\"
This is a valid command.
& powershell.exe -ExecutionPolicy Bypass -Command "if (Get-LocalUser -Name *Invité*,*Guest* -ErrorAction SilentlyContinue | Where-Object Enabled) { 'Active' } else { 'Disabled' }"
I would also like to point out that when Invité is used, é is dropped with a space
2026/05/11 14:53:31 sca[21988] wm_sca.c:1699 at wm_sca_read_command(): DEBUG: Executing command 'powershell.exe -Command "if (Get-LocalUser -Name *Invité*,*Guest* -ErrorAction SilentlyContinue | Where-Object Enabled) { Write-Output Active } else { Write-Output Disabled }"', and testing output with pattern 'r:Disabled'
2026/05/11 14:53:31 wazuh-agent[21988] wm_exec.c:147 at wm_exec(): DEBUG: UTF-8 command: powershell.exe -Command "if (Get-LocalUser -Name *Invit *,*Guest* -ErrorAction SilentlyContinue | Where-Object Enabled) { Write-Output Active } else { Write-Output Disabled }"
And the Get-LocalUser is not recognized.
2026/05/11 15:01:26 sca[24744] wm_sca.c:2043 at wm_sca_pattern_matches(): DEBUG: Pattern test result: (r:Disabled)( + FullyQualifiedErrorId : CommandNotFoundException) -> 0
2026/05/11 15:01:26 sca[24744] wm_sca.c:1286 at wm_sca_do_scan(): DEBUG: Breaking from rule aggregator 'all' with found = 0
2026/05/11 15:01:26 sca[24744] wm_sca.c:1302 at wm_sca_do_scan(): DEBUG: Result for check id: 50006 'Verify Guest account is disabled' -> 0
2026/05/11 15:01:26 sca[24744] wm_sca.c:502 at wm_sca_read_files(): DEBUG: Calculating hash for scanned results.
2026/05/11 15:01:26 sca[24744] wm_sca.c:2964 at wm_sca_hash_integrity(): DEBUG: Concatenating check results:
2026/05/11 15:01:26 sca[24744] wm_sca.c:2967 at wm_sca_hash_integrity(): DEBUG: ID: 50006; Result: 'failed'
To check if the guest account is disabled, you can use this Policy.
# 2.3.1.2 (L1) Ensure 'Accounts: Guest account status' is set to 'Disabled'. (Automated)
- id: 26009
title: "Ensure 'Accounts: Guest account status' is set to 'Disabled'."
description: "This policy setting determines whether the Guest account is enabled or disabled. The Guest account allows unauthenticated network users to gain access to the system. The recommended state for this setting is: Disabled. Note: This setting will have no impact when applied to the Domain Controllers organizational unit via group policy because Domain Controllers have no local account database. It can be configured at the domain level via group policy, similar to account lockout and password policy settings."
rationale: "The default Guest account allows unauthenticated network users to log on as Guest with no password. These unauthorized users could access any resources that are accessible to the Guest account over the network. This capability means that any network shares with permissions that allow access to the Guest account, the Guests group, or the Everyone group will be accessible over the network, which could lead to the exposure or corruption of data."
impact: "All network users will need to authenticate before they can access shared resources. If you disable the Guest account and the Network Access: Sharing and Security Model option is set to Guest Only, network logons, such as those performed by the Microsoft Network Server (SMB Service), will fail. This policy setting should have little impact on most organizations because it is the default setting in Microsoft Windows 2000, Windows XP, and Windows Server™ 2003."
remediation: "To establish the recommended configuration via GP, set the following UI path to Disabled: Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Accounts: Guest account status."
references:
compliance:
- cis: ["2.3.1.2"]
- cis_csc_v8: ["4.7"]
- cis_csc_v7: ["16.8"]
- iso_27001-2013: ["A.9.2.1"]
- pci_dss_v3.2.1: ["2.1", "2.1.1"]
- pci_dss_v4.0: ["2.2.2", "2.3.1"]
- soc_2: ["CC6.3"]
condition: all
rules:
- 'c:powershell -NoProfile -Command "[bool](Get-CimInstance -Query ''SELECT * FROM Win32_UserAccount WHERE LocalAccount = TRUE AND SID LIKE ''''S-1-5-21-%-501'''''' | Where-Object -Property Disabled)" -> r:True'
Ref:
https://github.com/wazuh/wazuh/blob/7af5a7e14f3c54846b0aa07a15e3a9baf2c75c25/ruleset/sca/windows/cis_win11_enterprise.yml#L265
You can test that condition directly in PowerShell by running the inner command separately first.
The relevant PowerShell command is:
[bool](
Get-CimInstance -Query "SELECT * FROM Win32_UserAccount WHERE LocalAccount = TRUE AND SID LIKE 'S-1-5-21-%-501'" |
Where-Object -Property Disabled
)
This checks whether the built-in Guest account (RID 501) exists and is disabled.
Expected output:
True → Guest account is disabled
False → Guest account is enabled or not found
Check the test results.
To check if you have an account with the name Invité, you can use this policy.
# 2.3.1.5 (L1) Configure 'Accounts: Rename guest account'. (Automated)
- id: 26012
title: "Configure 'Accounts: Rename guest account'."
description: "The built-in local guest account is another well-known name to attackers. It is recommended to rename this account to something that does not indicate its purpose. Even if you disable this account, which is recommended, ensure that you rename it for added security."
rationale: "The Guest account exists on all computers that run the Windows 2000 or newer operating systems. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination."
impact: "There should be little impact, because the Guest account is disabled by default."
remediation: "To establish the recommended configuration via GP, configure the following UI path: Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Accounts: Rename guest account."
references:
compliance:
- cis: ["2.3.1.5"]
- cis_csc_v8: ["4.7"]
- pci_dss_v3.2.1: ["2.1", "2.1.1"]
- pci_dss_v4.0: ["2.2.2", "2.3.1"]
- soc_2: ["CC6.3"]
condition: all
rules:
- 'not c:net user -> r:guest|Guest|Gast|Invité|Invitado|Ospite|Convidado|Gäst |Gjest|Gæst|Vieras|Гость|Gość|Vendég|Host |Misafir|Επισκέπτης|ゲスト|来宾|來賓|게스트|ضيف|אורח|บัญชีผู้ใช้ทั่วไป'