system,windows: fix UAC attribute bit table#8361
Conversation
The previous table was incorrect. Table data comes from MS-SAMR: Security Account Manager (SAM) Remote Protocol (Client-to-Server) version 46.0[1], 2.2.1.12 USER_ACCOUNT Codes. [1]https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-SAMR/%5bMS-SAMR%5d-230828.docx
c9b115c to
bcc115d
Compare
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsExpand to view the GitHub comments
To re-run your PR in the CI, just comment with:
|
🌐 Coverage report
|
|
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
andrewkroh
left a comment
There was a problem hiding this comment.
Do we have the evtx file associated with one of these samples that you can load into the Window Event Viewer and grab the event xml with the rendered message? I want to sanity check this. The user that reported the problem had good evidence, but I still want to double check.
| "0x00400000": DONT_REQ_PREAUTH | ||
| "0x00800000": PASSWORD_EXPIRED | ||
| "0x01000000": TRUSTED_TO_AUTH_FOR_DELEGATION | ||
| "0x04000000": PARTIAL_SECRETS_ACCOUNT |
There was a problem hiding this comment.
I'm thinking we should trim the USER_ prefix.
There was a problem hiding this comment.
I agree from a storage/simplicity perspective, but am conflicted given that it will then no longer match the MS docs.
There was a problem hiding this comment.
I don't have a strong opinion. My reasoning behind making the comment was to reconcile the differences between the docs12 that MS points to for this field and the docs that we have discovered to have the correct numerical values.
Now that I look closer the names are still a little different than the old names even after trimming the USER_ prefix. So that would still break queries that might have existed for the old names. Maybe a clean shift to new names is best.
Footnotes
There was a problem hiding this comment.
Indeed, some were the same, but there in not a proper mapping between the two sets.
andrewkroh
left a comment
There was a problem hiding this comment.
I just looked at the example given in https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738, and I think this change checks out with the values shown there.
|
We have evtx files in the security module in beats that give json files that exercise this. |
|
This is the event that is used in the winlogbeat 4741 that gives this diff in the beats PR here. |
|
Package system - 1.47.2 containing this change is available at https://epr.elastic.co/search?package=system |
|
Package windows - 1.41.1 containing this change is available at https://epr.elastic.co/search?package=windows |
|
@Edf6 I was working on uac control flags and noticed you changed the flags to something wrong. following this documentation: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/useraccountcontrol-manipulate-account-properties. the previous values were correct. What was the reason of this change? |
Proposed commit message
The previous table was incorrect. Table data comes from MS-SAMR: Security Account Manager (SAM) Remote Protocol (Client-to-Server) version 46.0, 2.2.1.12 USER_ACCOUNT Codes.
Checklist
changelog.ymlfile.Author's Checklist
How to test this PR locally
Related issues
Screenshots