Potential Bug: Windows Security Event ID 5140 incorrectly parsed by OSSEC.

InfoSec

unread,

Feb 15, 2017, 3:20:23 AM2/15/17

to ossec-list

The events are sanitized.

XML in Windows Event Viewer:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

- <System>

<Channel>Security</Channel>

<Computer>Desktop</Computer>

</System>

- <EventData>

<Data Name="SubjectUserSid">S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX</Data>

<Data Name="SubjectUserName">UserName</Data>

<Data Name="SubjectDomainName">DOMAIN</Data>

<Data Name="SubjectLogonId">0xXXXXXX</Data>

</EventData>

</Event>

Event in Text Format (from Windows Event Viewer):

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 2017-02-15 09:43:12

Event ID: 5140

Task Category: File Share

Level: Information

Keywords: Audit Success

User: N/A

Computer: Desktop

Description:

A network share object was accessed.

Subject:

Security ID: DOMAIN\UseName

Account Name: UserName

Account Domain: DOMAIN

Logon ID: 0xXXXXXX

Network Information:

Object Type: File

Source Address: ::1

Source Port: 9723

Share Information:

Share Name: \\*\IPC$

Share Path:

Access Request Information:

Access Mask: 0x1

Accesses: ReadData (or ListDirectory)

OSSEC Log Event (in json format):

{"rule":{"level":1,"comment":"Windows - A network share object was accessed.","sidid":182047,"firedtimes":3,"groups":["win_audit"],"PCI_DSS":["10.6.1"]},"dstuser":"(no user)","full_log":"2017 Feb 15 09:43:12 WinEvtLog: Security: AUDIT_SUCCESS(5140): Microsoft-Windows-Security-Auditing: (no user): no domain: Desktop: A network share object was accessed. Subject: Security ID: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Account Name: GJahchan Account Domain: DESKTOP Logon ID: 0xXXXXXX Network Information: Source Address: File Source Port: ::1 Share Name: 9723","id":"5140","status":"AUDIT_SUCCESS","data":"Microsoft-Windows-Security-Auditing","systemname":"Desktop","decoder":{"name":"windows"},"hostname":"Win10EntDsktp","agentip":"XXX.XXX.XX.X","timestamp":"2017 Feb 15 07:43:12","location":"WinEvtLog"}

OSSEC Log Event (in multi-line log format):

2017 Feb 15 09:43:12 WinEvtLog: Security: AUDIT_SUCCESS(5140): Microsoft-Windows-Security-Auditing: (no user): no domain: Desktop: A network share object was accessed. Subject: Security ID: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Account Name: UserName Account Domain: DOMAIN Logon ID: 0xXXXXXX Network Information: Source Address: File Source Port: ::1 Share Name: 9723

Corresponding Custom Rule:

<if_sid>18104</if_sid>

<description>Windows - A network share object was accessed.</description>

</rule>

Issues:

The Source Address field is skipped, the Source Port is filled with the Source Address, the Share Name is filled with the Source Port.

Share Name, Access Mask and Accesses fields are missing.

dan (ddp)

unread,

Feb 15, 2017, 3:09:19 PM2/15/17

to ossec...@googlegroups.com

Can you turn on the logall option and pull a log sample from the archives.log?
The full_log entry in the json should be what OSSEC is seeing, and the
source port is listed as ::1

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Message has been deleted

InfoSec

unread,

Feb 20, 2017, 6:30:13 AM2/20/17

to ossec-list

The event is from a Windows 10 system.

I have turned on logall. I am having a hard time regenerating event ID 5140, however I have spotted several other event types where the xml field labels are NOT logged up by OSSEC.

As presented by OSSEC, these event types (and several others) are just a sequence of field content *without* field names. Without viewing the original event in Window Event Viewer, it is difficult to make head or tail of the content of such events.

Event 4703 is filtered by the rules I have in place, below is a sanitized capture of one event from the archives log.

Example event 4703 from archives log:

2017 Feb 20 10:19:04 (AgentName) 192.168.X.Y->WinEvtLog 2017 Feb 20 12:19:00 WinEvtLog: Security: AUDIT_SUCCESS(4703): Microsoft-Windows-Security-Auditing: (no user): no domain: Hostname: S-1-5-18 HOSTNAME$ DOMAIN 0x3e7 S-1-5-18 HOSTNAME$ DOMAIN 0x3e7 C:\Program Files (x86)\OSSEC-Agent\ossec-agent.exe 0x6d0 SeSecurityPrivilege -

Sanitized Text view in Event Viewer

A user right was adjusted.

Subject:

Security ID: SYSTEM

Account Name: HOSTNAME$

Account Domain: DOMAIN

Logon ID: 0x3E7

Target Account:

Security ID: SYSTEM

Account Name: HOSTNAME$

Account Domain: DOMAIN

Logon ID: 0x3E7

Process Information:

Process ID: 0x6d0

Process Name: C:\Program Files (x86)\OSSEC-Agent\ossec-agent.exe

Enabled Privileges:

SeSecurityPrivilege

Disabled Privileges:

-

And the XML Event Data

- <EventData>

<Data Name="SubjectUserName">HOSTNAME$</Data>

<Data Name="SubjectDomainName">DOMAIN</Data>

<Data Name="TargetUserName">HOSTNAME$</Data>

<Data Name="TargetDomainName">DOMAIN</Data>

<Data Name="ProcessName">C:\Program Files (x86)\OSSEC-Agent\ossec-agent.exe</Data>

<Data Name="DisabledPrivilegeList">SeSecurityPrivilege</Data>

</EventData>

The labels in Windows AppLocker events are missing (it seems t be the case for Windows XML logs other than System, Application and Security). Certain fields are not being logged at all (don't know if this was by design).

Event in OSSEC:

2017 Feb 20 12:59:32 WinEvtLog: Microsoft-Windows-AppLocker/EXE and DLL: INFORMATION(8002): Microsoft-Windows-AppLocker: Username: HOSTNAME: Hostname: %SYSTEM32%\NOTEPAD.EXE was allowed to run.

Similar event in Event Viewer:

Log Name: Microsoft-Windows-AppLocker/EXE and DLL Source: Microsoft-Windows-AppLocker Date: 2017-02-20 12:59:32 Event ID: 8002 Task Category: None Level: Information Keywords: User: HOSTNAME\Username Computer: Hostname Description: %SYSTEM32%\NOTEPAD.EXE was allowed to run.

<System> <Provider Name="Microsoft-Windows-AppLocker" Guid="{CBDA4DBF-8D5D-4F69-9578-BE14AA540D22}" /> <EventID>8002</EventID> <Version>0</Version> <Level>4</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2017-02-20T10:59:32.601746800Z" /> <EventRecordID>628604</EventRecordID> <Correlation /> <Execution ProcessID="12408" ThreadID="6736" /> <Channel>Microsoft-Windows-AppLocker/EXE and DLL</Channel> <Computer>Hostname</Computer> <Security UserID="S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX" /> </System> <UserData> <RuleAndFileData xmlns="http://schemas.microsoft.com/schemas/event/Microsoft.Windows/1.0.0.0"> <PolicyName>EXE</PolicyName> <RuleId>{68A289F7-223A-46C9-A2B2-A7C6F18046DE}</RuleId> <RuleName>Program Files (x86): MICROSOFT® WINDOWS® OPERATING SYSTEM signed by O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US</RuleName> <RuleSddl>D:(XA;;FX;;;S-1-5-11;((Exists APPID://FQBN) && ((APPID://FQBN) >= ({"O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\*",2814749767106560}))))</RuleSddl> <TargetUser>S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX</TargetUser> <TargetProcessId>7820</TargetProcessId> <FilePath>%SYSTEM32%\NOTEPAD.EXE</FilePath> <FileHash>D7AE8D9D859B4F6DC703E2005CC10E836CCFFC38C4DB97C3C9DEF101D722E417</FileHash> <Fqbn>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\NOTEPAD.EXE\10.0.10240.16425</Fqbn> <TargetLogonId>0x28f2bf</TargetLogonId> </RuleAndFileData> </UserData> </Event>

InfoSec

unread,

Feb 21, 2017, 6:58:14 AM2/21/17

to ossec-list

Here's another event missing firld names: Event ID 4627 which lists the group membership of a user when he logs on is missing field names.

2017 Feb 21 13:33:23 WinEvtLog: Security: AUDIT_SUCCESS(4627): Microsoft-Windows-Security-Auditing: (no user): no domain: Hostname: S-1-5-18 HOSTNAME$ DOMAN 0x3e7 S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Username HOSTNAME 0x22d8dd8 7 1 1 <LF><CR>

<TAB><TAB>%{S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXX}

<TAB><TAB>%{S-1-1-0}

<TAB><TAB>%{S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX}

<TAB><TAB>%{S-1-5-32-562}

<TAB><TAB>%{S-1-5-32-578}

<TAB><TAB>%{S-1-5-32-556}

<TAB><TAB>%{S-1-5-32-555}

<TAB><TAB>%{S-1-5-32-545}

<TAB><TAB>%{S-1-5-4}

<TAB><TAB>%{S-1-2-1}

<TAB><TAB>%{S-1-5-11}

<TAB><TAB>%{S-1-5-15}

<TAB><TAB>%{S-1-5-113}

<TAB><TAB>%{S-1-2-0}

<TAB><TAB>%{S-1-5-64-10}

dan (ddp)

unread,

Feb 21, 2017, 9:25:53 AM2/21/17

to ossec...@googlegroups.com

On Mon, Feb 20, 2017 at 6:09 AM, InfoSec <gjah...@compucenter.org> wrote:
> The event is from a Windows 10 system.
>
> I have turned on logall. I am having a hard time regenerating event ID 5140,
> however I have spotted several other event types where the xml field labels
> are NOT logged up by OSSEC.
>

> In addition, in the specific example below, the order of the last two fields
> is inverted.

>
> As presented by OSSEC, these event types (and several others) are just a
> sequence of field content *without* field names. Without viewing the
> original event in Window Event Viewer, it is difficult to make head or tail
> of the content of such events.
>
> Event 4703 is filtered by the rules I have in place, below is a sanitized
> capture of one event from the archives log.
>
> Example event 4703 from archives log:
> 2017 Feb 20 10:19:04 (AgentName) 192.168.X.Y->WinEvtLog 2017 Feb 20 12:19:00
> WinEvtLog: Security: AUDIT_SUCCESS(4703):
> Microsoft-Windows-Security-Auditing: (no user): no domain: Hostname:
> S-1-5-18 HOSTNAME$ DOMAIN 0x3e7 S-1-5-18 HOSTNAME$ DOMAIN 0x3e7 C:\Program
> Files (x86)\OSSEC-Agent\ossec-agent.exe 0x6d0 SeSecurityPrivilege -
>

I don't understand. What information in the above log message are you
expecting to be extracted?

> Sanitized Text view in Event Viewer
>

> A user right was adjusted. <--- Not reported by Windows in XML

>
> Subject:
> Security ID: SYSTEM
> Account Name: HOSTNAME$

> Account Domain: DOMAIN

> Logon ID: 0x3E7
>
> Target Account:
> Security ID: SYSTEM
> Account Name: HOSTNAME$

> Account Domain: DOMAIN

> Logon ID: 0x3E7
>
> Process Information:
> Process ID: 0x6d0
> Process Name: C:\Program Files (x86)\OSSEC-Agent\ossec-agent.exe
>
> Enabled Privileges:

> -
>
> Disabled Privileges:
> SeSecurityPrivilege

>
> And the XML Event Data

> - <EventData>
> <Data Name="SubjectUserSid">S-1-5-18</Data>
> <Data Name="SubjectUserName">HOSTNAME$</Data>

> <Data Name="SubjectDomainName">DOMAIN</Data>

> <Data Name="SubjectLogonId">0x3e7</Data>

> <Data Name="TargetUserSid">S-1-5-18</Data>
> <Data Name="TargetUserName">HOSTNAME$</Data>
> <Data Name="TargetDomainName">DOMAIN</Data>
> <Data Name="TargetLogonId">0x3e7</Data>
> <Data Name="ProcessName">C:\Program Files
> (x86)\OSSEC-Agent\ossec-agent.exe</Data>
> <Data Name="ProcessId">0x6d0</Data>
> <Data Name="EnabledPrivilegeList">-</Data>
> <Data Name="DisabledPrivilegeList">SeSecurityPrivilege</Data>
> </EventData>
>
>

> The labels in Windows AppLocker events are missing, in addition to certain
> fields not being logged at all.

InfoSec

unread,

Feb 21, 2017, 1:03:02 PM2/21/17

to ossec-list

The field names.

Instead of what is being collected,

2017 Feb 21 13:33:23 WinEvtLog: Security: AUDIT_SUCCESS(4627): Microsoft-Windows-Security-Auditing: (no user): no domain: Hostname: S-1-5-18 HOSTNAME$ DOMAIN 0x3e7 S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Username HOSTNAME 0x22d8dd8 7 1 1 <LF><CR>

<TAB><TAB>%{S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXX}

<TAB><TAB>%{S-1-1-0}

<TAB><TAB>%{S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX}

<TAB><TAB>%{S-1-5-32-562}

<TAB><TAB>%{S-1-5-32-578}

<TAB><TAB>%{S-1-5-32-556}

<TAB><TAB>%{S-1-5-32-555}

<TAB><TAB>%{S-1-5-32-545}

<TAB><TAB>%{S-1-5-4}

<TAB><TAB>%{S-1-2-1}

<TAB><TAB>%{S-1-5-11}

<TAB><TAB>%{S-1-5-15}

<TAB><TAB>%{S-1-5-113}

<TAB><TAB>%{S-1-2-0}

<TAB><TAB>%{S-1-5-64-10}

The event should be logged as follows (parts in Red are missing, without them an operator has no clue as to what the various pieces of information contained in the event are, unless he looks at a similar one in native Windows Event Viewer):

2017 Feb 21 13:33:23 WinEvtLog: Security: AUDIT_SUCCESS(4627): Microsoft-Windows-Security-Auditing: (no user): no domain: Hostname: Group Membership. Subject: Security ID: S-1-5-18 Account Name: HOSTNAME$ Account Domain: DOMAIN Logon ID: 0x3e7 Target User SID: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Target User Name: Username Target Domain Name: HOSTNAME Target Logon ID: 0x22d8dd8 Logon Type: 7 Event IDX: 1 Event Count: 1 Group Membership:<LF><CR>

<TAB><TAB>%{S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXX}

<TAB><TAB>%{S-1-1-0}

<TAB><TAB>%{S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX}

<TAB><TAB>%{S-1-5-32-562}

<TAB><TAB>%{S-1-5-32-578}

<TAB><TAB>%{S-1-5-32-556}

<TAB><TAB>%{S-1-5-32-555}

<TAB><TAB>%{S-1-5-32-545}

<TAB><TAB>%{S-1-5-4}

<TAB><TAB>%{S-1-2-1}

<TAB><TAB>%{S-1-5-11}

<TAB><TAB>%{S-1-5-15}

<TAB><TAB>%{S-1-5-113}

<TAB><TAB>%{S-1-2-0}

<TAB><TAB>%{S-1-5-64-10}

--------------------------------------------------------------------------------------------------------------

Event ID 4703:

Reported in archives.log

2017 Feb 21 17:31:27 (W10EntDsktp) 192.168.16.1->WinEvtLog 2017 Feb 21 19:31:13 WinEvtLog: Security: AUDIT_SUCCESS(4703): Microsoft-Windows-Security-Auditing: (no user): no domain: Hostname: S-1-5-18 DESKTOP$ COMPUCENTER 0x3e7 S-1-5-18 DESKTOP$ COMPUCENTER 0x3e7 C:\Program Files (x86)\OSSEC-Agent\ossec-agent.exe 0x11dc SeSecurityPrivilege -

What should have been logged as (missng bits in red):

2017 Feb 21 17:31:27 (W10EntDsktp) 192.168.16.1->WinEvtLog 2017 Feb 21 19:31:13 WinEvtLog: Security: AUDIT_SUCCESS(4703): Microsoft-Windows-Security-Auditing: (no user): no domain: Hostname: A user right was adjusted. Subject: Security ID: S-1-5-18 Account Name: HOSTNAME$ Account Domain: DOMAIN Logon ID: 0x3e7 Target: Security ID: S-1-5-18 Account Name: HOSTNAME$ Account Domain: DOMAIN Logon ID: 0x3e7 Process Name: C:\Program Files (x86)\OSSEC-Agent\ossec-agent.exe Process ID: 0x11dc Enabled Security Privilege: SeSecurityPrivilege Disabled Security Privilege: -

--------------------------------------------------------------------------------------------------------------

AppLocker Event ID: 8002

In OSSEC Archive log:

2017 Feb 21 17:24:04 (AgentName) 192.168.X.Y->WinEvtLog 2017 Feb 21 19:23:45 WinEvtLog: Microsoft-Windows-AppLocker/EXE and DLL: INFORMATION(8002): Microsoft-Windows-AppLocker: Username: HOSTNAME: Hostname: %SYSTEM32%\DLLHOST.EXE was allowed to run.

Without the missing information, the logged event is of little security value. It is the missing information that allows the event to be correlated with other types of events: Process ID, Logon ID, Security ID. The AppLocker Policy/Rule Details are critical for troubleshooting.

What should have been logged:

2017 Feb 21 17:24:04 (AgentName) 192.168.X.Y->WinEvtLog 2017 Feb 21 19:23:45 WinEvtLog: Microsoft-Windows-AppLocker/EXE and DLL: INFORMATION(8002): Microsoft-Windows-AppLocker: Rule and File Data: Policy Name: EXE Rule ID: {06EB0E7E-0F84-4D34-BF02-E59A8CAF9D61} Rule Name: Drive C:: INTERNET EXPLORER signed by O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US Rule SDDL: D:(XA;;FX;;;S-1-5-11;((Exists APPID://FQBN) && ((APPID://FQBN) >= ({"O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\INTERNET EXPLORER\*",3096224743817216})))) Target User SID: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Target Process ID: 1148 File Path: %SYSTEM32%\DLLHOST.EXE File Hash: 32527C58E1ED8888E4A8C5AEEF30BD9AECD584E9DD03976F83A8498C30EF3936 FQBN: O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\INTERNET EXPLORER\IELOWUTIL.EXE\11.0.10240.16384 Target Logon ID: 0x42c61d

InfoSec

unread,

Feb 23, 2017, 9:30:18 AM2/23/17

to ossec-list

I tend to think that the Windows Agent is the culprit.

Can the agent be temporarily run in debug mode, so it logs locally the events that it forwards to the server?

InfoSec

unread,

Feb 23, 2017, 10:30:10 AM2/23/17

to ossec-list

I found how to run the agent in debug mode. It seems like the issue lies with the agent, and the server is faithfully accepting whatever the agent is sending across.

Event ID 8002 (AppLocker) from agent debug log:

2017 Feb 23 16:51:53 WinEvtLog: Microsoft-Windows-AppLocker/EXE and DLL: INFORMATION(8002): Microsoft-Windows-AppLocker: Username: HOSTNAME: Hostname: %PROGRAMFILES%\WINDOWS\RESOURCE KITS\TOOLS\TAIL.EXE was allowed to run.

Format is identical to what is reported on the ossec-server.

dan (ddp)

unread,

Feb 23, 2017, 1:50:54 PM2/23/17

to ossec...@googlegroups.com

There are no options for that. The best you can do is turn the logall
option on the server on, and see what it receives from the agents.

dan (ddp)

unread,

Feb 23, 2017, 1:53:40 PM2/23/17

to ossec...@googlegroups.com

On Thu, Feb 23, 2017 at 10:30 AM, InfoSec <gjah...@compucenter.org> wrote:
> I found how to run the agent in debug mode. It seems like the issue lies
> with the agent, and the server is faithfully accepting whatever the agent is
> sending across.
>

Oh sweet, I didn't know it did that. I guess I should have read further.
Are you using the eventlog or eventchannel log format?
There shouldn't be anything in the agent that parses and removes
information from the events, so I'd guess that the following is what
it is actually getting from the log itself.*

> Event ID 8002 (AppLocker) from agent debug log:
> 2017 Feb 23 16:51:53 WinEvtLog: Microsoft-Windows-AppLocker/EXE and DLL:
> INFORMATION(8002): Microsoft-Windows-AppLocker: Username: HOSTNAME:
> Hostname: %PROGRAMFILES%\WINDOWS\RESOURCE KITS\TOOLS\TAIL.EXE was allowed to
> run.
>
> Format is identical to what is reported on the ossec-server.
>

* I know very little about the Windows side of things and avoid it as
much as possible.

Jahchan, Georges J.

unread,

Feb 23, 2017, 11:44:47 PM2/23/17

to ossec...@googlegroups.com

I am using the eventchannel format. Eventlog provides no useful information for logs other than the three basics: Application, Security and System.

If confirmed, this is a significant bug that impacts the integrity of all deployments of Windows agents, as far as I can determine at minimum on Windows 10, other versions are TBD.

I unfortunately do not have at hand other versions of Windows to test with, in order to determine whether it is an issue related to the agent that therefore impacts all Windows deployments, or a less serious issue that is specific to Windows 10.

IMHO the agent code needs to be thoroughly debugged, as:
i) some events are forwarded correctly;
ii) some have field names removed (which makes it very difficult to decode for any information other than what is in the OSSEC header); and
iii) some have important security information completely chopped off the message, that is in addition to missing field labels.

On Windows 10, I can confirm (not an exhaustive list):
i) The integrity of event IDs 4624, 4625, 4634, 4656~4663, 4688, 4689 is preserved.
ii) Event IDs 5140 and 4703 are forwarded without field labels (there are certainly others).
iii) Eventchannel logs other than the three standard event logs have no field labels, and are emptied of important security content.

Steps to reproduce on any recent flavor of Windows:

1) From the Group Policy Editor turn on AppLocker in Audit mode, and temporarily turn on all auditing in Security.

2) Configure the agent to collect AppLocker logs (This is for Windows 10, the log names differ for Windows 7):

In /var/ossec/etc/shared/agent.conf

<agent_config name="AgentName"> <localfile> <log_format>eventchannel</log_format> <location>Microsoft-Windows-AppLocker/EXE and DLL</location> </localfile> <localfile> <log_format>eventchannel</log_format> <location>Microsoft-Windows-AppLocker/MSI and Script</location> </localfile> <localfile> <log_format>eventchannel</log_format> <location>Microsoft-Windows-AppLocker/Packaged app-Deployment</location> </localfile> <localfile> <log_format>eventchannel</log_format> <location>Microsoft-Windows-AppLocker/Packaged app-execution</location> </localfile></agent_config>
3) Set the Windows agent to debug mode in internal_options.conf in the ossec-agent installation directory.

4) Restart the agent (net stop "OSSEC HIDS" then net start "OSSEC HIDS", or use the agent control GUI, or Services .msc to bounce the agent).

5) Examine events in the ossec.log file inside the OSSEC-agent installation directory.

InfoSec

unread,

Feb 24, 2017, 6:02:32 AM2/24/17

to ossec-list

After upgrading Windows 10 to the latest version:

- Event ID 6417 is missing the event description and the field names.

2017 Feb 24 12:18:43 WinEvtLog: Security: AUDIT_SUCCESS(6417): Microsoft-Windows-Security-Auditing: (no user): no domain: Hostname: 0x38a0 C:\Windows\System32\wbem\WmiPrvSE.exe

The event description is: "The FIPS module crypto selftests succeeded.", "0x38a0" is the process ID, and "C:\Windows\System32\wbem\WmiPrvSE.exe" the process name.

I would probably filter these events (but that is no excuse to have description and field name chopped off), logging failures only -- which would qualify as suspicious.

dan (ddp)

unread,

Feb 24, 2017, 12:32:02 PM2/24/17

to ossec...@googlegroups.com

Any Windows users want to take a look at this?

Grant Leonard

unread,

Feb 27, 2017, 9:18:23 AM2/27/17

to ossec-list

We will take a stab at it this week and see what we can uncover

All the best

Grant

Grant Leonard

unread,

Mar 6, 2017, 2:37:51 PM3/6/17

to ossec-list

Good afternoon

Are the 5140 events shares "to" your WIN10 or shares "from" your WIN10 to another platform?

I tend to think "to" but it is important to ask https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=5140

4703 appears on a server as well, though I do not see it in WIN10 outside of the domain - https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4703

What else are you doing to trigger Applocker events? I do not even see those in archives.log with debug on.

Finally I do not see the eventchannel load in the agent.conf, though I validated I had it listed correctly and I see events in my MSI and Script section in the WIN10 platform. I feel like I should see it load.

Jahchan, Georges J.

unread,

Mar 6, 2017, 5:20:11 PM3/6/17

to ossec...@googlegroups.com

Hello Grant,

Event ID 5140 is generated on the system itself. Source IP: ::1, source port: random dynamic, share name: \\*\IPC$ (There are no other shares).

2017 Mar 05 19:27:39 WinEvtLog: Security: AUDIT_SUCCESS(5140): Microsoft-Windows-Security-Auditing: (no user): no domain: Desktop: A network share object was accessed. Subject: Security ID: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Account Name: Acct_name Account Domain: DOMAIN Logon ID: 0xXXXXXX Network Information: Object Type: File Source Address: ::1 Source Port: 1170 Share Information: Share Name: \\*\IPC$ Share Path: Access Request Information: Access Mask: 0x1 Accesses: ReadData (or ListDirectory) I modified the audit policy on the system so that event ID 4703 is no longer generated, and I have deleted 4703 events from SIEM. To enable AppLocker, you need to go to the Group Policy Editor (gpedit.msc), then select: Windows Settings -> Security Settings -> Application Control Policies -> AppLocker Click on 'Configure Rule Enforcement' and make sure you set it to 'Audit only' mode per screenshot 2. I the enforced policy is incorrect, you may lock yourself out. No harm can be done in Audit mode. Create a default set of rules so you generate events. Finally you need to make sure that the Application ID service is running. See services.msc below.

Configure the OSSEC agent to pick up AppLocker logs: /var/ossec/etc/shared/agent.conf <agent_config name="AgentName"> <localfile> <location>Microsoft-Windows-AppLocker/EXE and DLL</location> <log_format>eventchannel</log_format> </localfile> <localfile> <location>Microsoft-Windows-AppLocker/MSI and Script</location> <log_format>eventchannel</log_format> </localfile> <localfile> <location>Microsoft-Windows-AppLocker/Packaged app-Deployment</location> <log_format>eventchannel</log_format> </localfile> <localfile> <location>Microsoft-Windows-AppLocker/Packaged app-execution</location> <log_format>eventchannel</log_format> </localfile> <localfile> <location>Windows PowerShell</location> <log_format>eventchannel</log_format> </localfile> <localfile> <location>Microsoft-Windows-WMI-Activity/Operational</location> <log_format>eventchannel</log_format> </localfile></agent_config>

All the agent picks up from this information is (fields in Red are sanitized): 2017 Mar 06 22:48:01 WinEvtLog: Microsoft-Windows-AppLocker/EXE and DLL: WARNING(8003): Microsoft-Windows-AppLocker: Acct_Name: DOMAIN: Hostname: %OSDRIVE%\USERS\XXXXXXXX\APPDATA\LOCAL\CITRIX\GOTOMEETING\6441\G2MUPDATE.EXE was allowed to run but would have been prevented from running if the AppLocker policy were enforced. Which is similar to what the non-eventchannel view in native EventViewer shows:

This is not limited to AppLocker, PowerShell and WMI events suffer from similar issues. WMI (XML): - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Microsoft-Windows-WMI-Activity" Guid="{1418EF04-B0B4-4623-BF7E-D74AB47BBDAA}" /> <EventID>5858</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x4000000000000000</Keywords> <TimeCreated SystemTime="2017-03-06T21:10:11.370750400Z" /> <EventRecordID>8042</EventRecordID> <Correlation /> <Execution ProcessID="1144" ThreadID="15224" /> <Channel>Microsoft-Windows-WMI-Activity/Operational</Channel> <Computer>Xxxxxx</Computer> <Security UserID="S-1-5-18" /> </System> - <UserData> - <Operation_ClientFailure xmlns="http://manifests.microsoft.com/win/2006/windows/WMI"> <Id>{00000000-0000-0000-0000-000000000000}</Id> <ClientMachine>XXXXXXX</ClientMachine> <User>NT AUTHORITY\SYSTEM</User> <ClientProcessId>1256</ClientProcessId> <Component>Unknown</Component> <Operation>Start IWbemServices::ExecQuery - ROOT\CIMV2 : SELECT * FROM Win32_IDEController</Operation> <ResultCode>0x80041032</ResultCode> <PossibleCause>Unknown</PossibleCause> </Operation_ClientFailure> </UserData> </Event>

2017 Mar 06 23:10:11 WinEvtLog: Microsoft-Windows-WMI-Activity/Operational: ERROR(5858): Microsoft-Windows-WMI-Activity: SYSTEM: NT AUTHORITY: Desktop: Id = {00000000-0000-0000-0000-000000000000}; ClientMachine = DESKTOP; User = NT AUTHORITY\SYSTEM; ClientProcessId = 1256; Component = Unknown; Operation = Start IWbemServices::ExecQuery - ROOT\CIMV2 : SELECT * FROM Win32_DiskPartition WHERE BootPartition = True; ResultCode = 0x80041032; PossibleCause = Unknown

Grant Leonard

unread,

Mar 7, 2017, 2:04:19 PM3/7/17

to ossec...@googlegroups.com

This is great, thank you sir.

I do see that 5858 processes as expected

AV-Lab-01:~/client_log_samples# /var/ossec/bin/ossec-logtest
2017/03/07 13:53:45 ossec-testrule: INFO: Reading decoder file alienvault/decoders/decoder.xml.
2017/03/07 13:53:46 ossec-testrule: INFO: Started (pid: 29793).
ossec-testrule: Type one log per line.

WinEvtLog: Microsoft-Windows-WMI-Activity/Operational: ERROR(5858): Microsoft-Windows-WMI-Activity: SYSTEM: NT AUTHORITY: Desktop: Id = {00000000-0000-0000-0000-000000000000}; ClientMachine = DESKTOP; User = NT AUTHORITY\SYSTEM; ClientProcessId = 1256; Component = Unknown; Operation = Start IWbemServices::ExecQuery - ROOT\CIMV2 : SELECT * FROM Win32_DiskPartition WHERE BootPartition = True; ResultCode = 0x80041032; PossibleCause = Unknown

**Phase 1: Completed pre-decoding.
       full event: 'WinEvtLog: Microsoft-Windows-WMI-Activity/Operational: ERROR(5858): Microsoft-Windows-WMI-Activity: SYSTEM: NT AUTHORITY: Desktop: Id = {00000000-0000-0000-0000-000000000000}; ClientMachine = DESKTOP; User = NT AUTHORITY\SYSTEM; ClientProcessId = 1256; Component = Unknown; Operation = Start IWbemServices::ExecQuery - ROOT\CIMV2 : SELECT * FROM Win32_DiskPartition WHERE BootPartition = True; ResultCode = 0x80041032; PossibleCause = Unknown'
       hostname: 'AV-Lab-01'
       program_name: '(null)'
       log: 'WinEvtLog: Microsoft-Windows-WMI-Activity/Operational: ERROR(5858): Microsoft-Windows-WMI-Activity: SYSTEM: NT AUTHORITY: Desktop: Id = {00000000-0000-0000-0000-000000000000}; ClientMachine = DESKTOP; User = NT AUTHORITY\SYSTEM; ClientProcessId = 1256; Component = Unknown; Operation = Start IWbemServices::ExecQuery - ROOT\CIMV2 : SELECT * FROM Win32_DiskPartition WHERE BootPartition = True; ResultCode = 0x80041032; PossibleCause = Unknown'

**Phase 2: Completed decoding.
       decoder: 'windows'
       status: 'ERROR'
       id: '5858'
       extra_data: 'Microsoft-Windows-WMI-Activity'
       srcuser: 'SYSTEM'
       system_name: 'Desktop'

**Phase 3: Completed filtering (rules).
       Rule id: '18103'
       Level: '5'
       Description: 'Windows error event.'
**Alert to be generated.

That said, you seem to want more information sent over from the agent to the server, and end up using more of the XML based event channel entry in OSSEC. I would agree that is a key component. Do you have some samples, unedited from archives.log on the OSSEC server? We can likely craft a decoder and rules to get that working the way you expect.

I tried to reach out directly to you, perhaps we can connect and do a quick GoToMeeting session , share screens and figure out a path forward?

All the best

Grant Leonard

Castra Consulting, LLC

--

---
You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/GnA9qGZw9MU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+unsubscribe@googlegroups.com.

Jahchan, Georges J.

unread,

Mar 7, 2017, 5:38:02 PM3/7/17

to ossec...@googlegroups.com

I have no issues with creating decoders and rules, been doing it for years.

But these do not make up for event information that the agent fails to include in the event that it forwards to the OSSEC server. That is where the problem lies -- agent-side not server-side.

In the case of WMI, sufficient detail is forwarded. But in the case of AppLocker, the information forwarded by the agent is woefully deficient.

In the environment, sudowin is utilized to elevate privileges. So the user name cannot be a criteria that allows the determination of whether a user is privileged or not. In regulated environments this is crucial. The Logon ID is what allows us to distinguish between unprivileged and privileged user sessions for the same Account Name and Security ID. In the XML event, it reports the logon ID plus rule/policy information. All that the agent sends upstream is the user name and application path, and whether it was blocked, allowed, or allowed in audit mode. Better than nothing, but not good enough. Lots more information is definitely lurking in XML, and it is not being picked up by the agent.

Seems to me the agent is picking up the eventlog and not the eventchannel. For WMI, there is little difference. between the two But for AppLocker the story differs
eventlog is truly minimal.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

- <System>

<Channel>Microsoft-Windows-AppLocker/EXE and DLL</Channel>

<Computer>Desktop</Computer>

</System>

- <UserData>

- <RuleAndFileData xmlns="http://schemas.microsoft.com/schemas/event/Microsoft.Windows/1.0.0.0">

<TargetUser>S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX</TargetUser>

<FilePath>%OSDRIVE%\USERS\XXXXXXXX\APPDATA\LOCAL\CITRIX\GOTOMEETING\6441\G2MUPDATE.EXE</FilePath>

<Fqbn>O=CITRIX ONLINE, L=FORT LAUDERDALE, S=FLORIDA, C=US\GOTOMEETING\G2M.EXE\8.0.0.6441</Fqbn>

</RuleAndFileData>

</UserData>

</Event>

Yet, the following is all the agent picks up:

Log Name: Microsoft-Windows-AppLocker/EXE and DLL
Source: Microsoft-Windows-AppLocker

Date:          2017-03-07 23:48:00
Event ID:      8003
Task Category: None
Level:         Warning
Keywords:
User:          DOMAIN\User
Computer:      Computer
Description:

%OSDRIVE%\USERS\XXXXXXXX\APPDATA\LOCAL\CITRIX\GOTOMEETING\6441\G2MUPDATE.EXE was allowed to run but would have been prevented from running if the AppLocker policy were enforced.

Open to a G2M to exchange info if you feel it necessary to move forward.

Which time zone are you in?

Message has been deleted

Grant Leonard

unread,

Mar 8, 2017, 2:49:59 PM3/8/17

to ossec-list

I am in EST and I absolutely agree with you. I think we should spend no more than 30 minutes looking at your discovery, looking at logs in archives.log then , as you noted, requesting an enhancement to ensure those log values are sent over by the agent.

All the best

Grant Leonard

Castra Consulting, LLC

Grant Leonard

unread,

Mar 13, 2017, 9:43:24 AM3/13/17

to ossec-list

Confirmed

George walked through the events with me. The event channel is read, though in archives.log , post decryption, only part of the event is sent over. For most events this is not an issue, but for Applocker and other more detailed events writing to Event Channels, there is a second level of XML that has VERY interesting traffic. There are some good security features in Windows OS that are worth reading correctly with any tool.

It is worth noting that, It did not matter which rule set was being used, this was an agent thing. (Default versus custom). Further in comparison with another "open source windows event agent to syslog" utility, the same issue was present.

Grant

Reply all

Reply to author

Forward