Windows Event ID 4625

1,725 views
Skip to first unread message

Luke Goldman

unread,
Nov 3, 2014, 4:37:34 PM11/3/14
to ossec...@googlegroups.com
I am new to setting up Ossec but so far am liking it a lot.  I am having one issue that I am sure someone has resolved.  The main thing I am working right now is tracking failed windows logins.  Most of this has worked right out of the box which is awesome.  The issue I am having is that the Windows Event ID 4625 shows (no user) where every other Windows Event ID shows the username.  So Ossec reports the user as (no user).  This causes issues when I want to alert on 6 failed logins from the same user, as every user will match this (no user).  Has anyone got a solution for this?  Below is a log that will show what I am talking about.  Thanks!

2014 Nov 03 12:05:34 WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no user):
2014 Nov 03 13:15:27 WinEvtLog: Security: AUDIT_SUCCESS(4624): Microsoft-Windows-Security-Auditing: Username:


gr...@castraconsulting.com

unread,
Nov 4, 2014, 7:43:37 AM11/4/14
to ossec...@googlegroups.com
So that is rule 18106

I have just recently been playing with this one.

The issue isn't OSSEC its literally the WIndows log (note that the log states (no user)

EVENT: "[INIT]WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no user): no domain: some.server.name.here: An account failed to log on. Subject:
Security ID:  S-1-0-0  Account Name:  -  Account Domain:  -  Logon ID:  0x0  Logon Type:   3  Account For Which Logon Failed:  Security ID:
S-1-0-0  Account Name:  username_we_want_here_but_not_parsed  Account Domain:  some.domain  Failure Information:  Failure Reason:  %%2313  Status:   0xc000006d  Sub Status:
0xc000006a  Process Information:  Caller Process ID: 0x0  Caller Process Name: -  Network Information:  Workstation Name: Remote.workstation  Source
Network Address: -  Source Port:  -  Detailed Authentication Information:  Logon Process:  NtLmSsp   Authentication Package: NTLM  Transited
Services: -  Package Name (NTLM only): -  Key Length:  0  This event is generated when a logon request fails. It is generated on the computer
where access was attempted.  [END]";


What it appears we need is a way to move the "match" for this particular event

From --

Microsoft-Windows-Security-Auditing: (no user):

To --

Account Name:  username_we_want_here_but_not_parsed

Which I assume we need to do in the decoder

Initially in OSSIM I was excluding (no user) but I decided on a different path and I was trying to match on the status/subcode (like this 0xC000006F) as that tells me what really happened (this is not proving worthwhile as the sub code types are numerous) What matters after the username are the sub codes or status here as we get the kind of auth fail for this VERY wide scoping log

Does anyone have any idea on how better to match at the decoder level?

18106 is if_sid 18105 which is if_sid 18100 which is

 <rule id="18105" level="4">
    <if_sid>18100</if_sid>
    <status>^AUDIT_FAILURE|^failure</status>
    <description>Windows audit failure event.</description>
  </rule>

and the generic decoder

<decoder name="windows">
  <type>windows</type>
  <prematch>^WinEvtLog: </prematch>
  <regex offset="after_prematch">^\.+: (\w+)\((\d+)\): (\.+): </regex>
  <regex>(\.+): \.+: (\S+): </regex>
  <order>status, id, extra_data, srcuser, system_name</order>
  <fts>name, location, user, system_name</fts>
</decoder>


So, the srcuser is perhaps wrong? Maybe we need a second decoder for this and other events that don't leverage the initial username, adding an actor and actee type value?

Luke Goldman

unread,
Nov 4, 2014, 9:32:02 AM11/4/14
to ossec...@googlegroups.com
That is exactly what I was noticing.  I was playing around with the suggestions from this site (http://www.richardosgood.com/blog/fixing-ossec-windows-logon-failure-events/) to create custom decoders but was messing something up because every time I used the custom decoders it would break all of the other alerts from the windows decoder.  I did have to change his decoder for the 4625 event id because it was not correct.  

I didn't know if anyone else had a fix.  Thanks for any help/suggestions.

gr...@castraconsulting.com

unread,
Nov 4, 2014, 10:07:14 AM11/4/14
to ossec...@googlegroups.com
great article sir, thanks I am testing that now

Make sure you add the values to local_decoder the way he discusses, not the way he lists them.

He also doesn't note that you need override rules for each of those in your local_rules so be sure to add those.

Thanks again for the link!

Luke Goldman

unread,
Nov 4, 2014, 10:16:24 AM11/4/14
to ossec...@googlegroups.com
Let me know if you get the decoders to work.  Do you have tell ossec to use the local_decoders.xml?  I cannot get it to use the custom decoders.

Grant L

unread,
Nov 5, 2014, 7:43:08 AM11/5/14
to ossec...@googlegroups.com
You do not have to tell the platform to use local_decoders, just make sure the permissions are the same

I am upgrading to 2.8 this week across numerous platforms from 2.7.1

I already have the decoders in place and will begin making rules today or tomorrow for the events in the custom decoder file

I will post with results.

All the best

--

---
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/AFawPZZ4v4k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Eloy Alonso

unread,
Oct 7, 2015, 4:56:14 PM10/7/15
to ossec-list
This Event is usually caused by a stale hidden credential. Try this from the system giving the error:

From a command prompt run:    psexec -i -s -d cmd.exe
From the new DOS window run:  rundll32 keymgr.dll,KRShowKeyMgr
Remove any items that appear in the list of Stored User Names and Passwords.  Restart the computer.

Eloy Alonso

unread,
Oct 7, 2015, 4:56:14 PM10/7/15
to ossec-list

Joshua Roback

unread,
Nov 20, 2015, 12:35:55 PM11/20/15
to ossec-list
I have a decoder that grabs the appropriate Account Name, but have come across another issue.  Even if I am able to properly decoder "user", my ossec alert.log does not correlate that to "user" unless it's in the expected location in the WinEvtLog header.

Raw Log
WinEvtLog: Security: AUDIT_SUCCESS(4725): Microsoft-Windows-Security-Auditing: (no user): no domain: myhost.mydomain.com: A user account was disabled.    Subject:   Security ID:   S-1-5-21-789336058-1532298954-839522115-141077     Account Name:  my_account    Account Domain:   MYDOMAIN     Logon ID:   0x23a80332    Target Account:    Security ID:   S-1-5-21-789336058-1532298954-839522115-60716   Account Name:  my_account    Account Domain:   MYDOMAIN

Decoder:
<decoder name="windows-verbose-auth">
  <parent>windows</parent>
  <regex offset="after_parent">Security ID:\s*\S*\s*Account Name:\s*(\S\S+)\s+Account Domain:\s*(\S*)</regex>
  <order>user, extra_data</order>
</decoder>

ossec-logtest output:

**Phase 2: Completed decoding.
       decoder: 'windows'
       status: 'AUDIT_SUCCESS'
       id: '4725'
       extra_data: 'Microsoft-Windows-Security-Auditing'
       system_name: 'myhost.mydomain.com'
       dstuser: 'my_account'



Alert.log
** Alert **
time: 1448030023
hostname: (agent26) 0.0.0.0->WinEvtLog
location: (agent26) 0.0.0.0->WinEvtLog
rule_id: 18112
rule_rev: 1
rule_name: User account disabled or deleted.
rule_level: 8
lrec_object_tag: user
lrec_action_tag: authentication delete
lrec_status_tag: success
lrec_action: review
event_id: 4725
status: AUDIT_SUCCESS
data: Microsoft-Windows-Security-Auditing
systemname: myhost.mydomain.com
raw_log:
WinEvtLog: Security: AUDIT_SUCCESS(4725): Microsoft-Windows-Security-Auditing: (no user): no domain: myhost.mydomain.com: A user account was disabled.    Subject:   Security ID:   S-1-5-21-789336058-1532298954-839522115-141077     Account Name:  my_account    Account Domain:   MYDOMAIN     Logon ID:   0x23a80332    Target Account:    Security ID:   S-1-5-21-789336058-1532298954-839522115-60716   Account Name:  my_account    Account Domain:   MYDOMAIN

As you can see, "user" in the alert.log doesn't populate.  If I modify the log message and manually ingest it into OSSEC, it works.


New Raw Log:
WinEvtLog: Security: AUDIT_SUCCESS(4725): Microsoft-Windows-Security-Auditing: my_account: no domain: myhost.mydomain.com: A user account was disabled.    Subject:   Security ID:   S-1-5-21-789336058-1532298954-839522115-141077     Account Name:  my_account    Account Domain:   MYDOMAIN     Logon ID:   0x23a80332    Target Account:    Security ID:   S-1-5-21-789336058-1532298954-839522115-60716   Account Name:  my_account    Account Domain:   MYDOMAIN

New Alert.log
** Alert **
time: 1448030023
hostname: (agent26) 0.0.0.0->WinEvtLog
location: (agent26) 0.0.0.0->WinEvtLog
rule_id: 18112
rule_rev: 1
rule_name: User account disabled or deleted.
rule_level: 8
lrec_object_tag: user
lrec_action_tag: authentication delete
lrec_status_tag: success
lrec_action: review
event_id: 4725
status: AUDIT_SUCCESS
data: Microsoft-Windows-Security-Auditing
user: my_account
systemname: myhost.mydomain.com
raw_log:
WinEvtLog: Security: AUDIT_SUCCESS(4725): Microsoft-Windows-Security-Auditing: my_account: no domain: myhost.mydomain.com: A user account was disabled.    Subject:   Security ID:   S-1-5-21-789336058-1532298954-839522115-141077     Account Name:  my_account    Account Domain:   MYDOMAIN     Logon ID:   0x23a80332    Target Account:    Security ID:   S-1-5-21-789336058-1532298954-839522115-60716   Account Name:  my_account    Account Domain:   MYDOMAIN

Grant Leonard

unread,
Nov 20, 2015, 1:59:57 PM11/20/15
to ossec...@googlegroups.com
We addressed this using an OSSIM plugin to read a different part of the alert log

Hope that helps sir
Reply all
Reply to author
Forward
0 new messages