Will the Real S-1-7-23-3394466182-97151736-2635146241-1084 Please Stand?
Sometimes security measures can be completely correct and at the same time, completely useless. Such is the case when viewing the logs of a user added to the local Administrators group on a Windows 2003 server.
Here is what an OSSEC syslog-formatted alert looks like in this case:
Mar 3 11:04:39 hostname ossec: Alert Level: 8; Rule: 18114 – Group account changed.; Location: (hostname) 172.16.0.1->WinEvtLog; user: username; WinEvtLog: Security: AUDIT_SUCCESS(636): Security: username: HOSTNAME: HOSTNAME: Security Enabled Local Group Member Added: Member Name: – Member ID: %{S-1-5-21-2533786115-122353884-3837542848-1670} Target Account Name: Administrators Target Domain: Builtin Target Account ID: %{S-1-5-32-544} Caller User Name: username Caller Domain: DOMAIN Caller Logon ID: (0×0,0×11529569) Privileges: -
Pop quiz: Tell me who was added to the Administrators group. If your answer is S-1-5-21-2533786115-122353884-3837542848-1670, then you are correct. Now tell me who that really is. Is it Bob from accounting or is it a l33t hacker? What will you tell your auditors? Without the Member Name, how can you know?
By now you may be thinking, “this is clearly an OSSEC bug.” That’s what I thought, too. But as it turns out, Snare exhibits the exact same behavior. And so does another commercial log aggregation tool I have used. So what’s going on here?
When viewing this alert in the Windows Event Viewer, the Member Name also displays the dash (-), but resolves the Member ID at the application layer (if it can). If there is no corresponding user, the SID is displayed. The Member Name is not in the raw log at all.
On one hand, this could be seen as correct behavior. After all, the administrator “Bob” from two years ago may not be the same administrator named Bob who was just hired last week. From a log integrity perspective, presenting the unique SID, which is never duplicated, is correct.
On the other hand, having the Member Name is entirely useful and relevant from the practicality and usability perspective. Who the heck is S-1-7-23-3394466182-97151736-2635146241-1084? Should I be concerned? I don’t know.
Just when you thought this was starting to make sense, a domain controller exhibits different behavior. In that case, the Member Name is populated. If it is a domain member or a stand-alone system, it is not.
To me, the correct behavior seems to be to write both the Member Name and the Member ID to the raw log. That way, the log analyst can clearly see that these were different Bobs. By correlating the timeline of the logs with other activities, we can put the pieces of the puzzle together.
Why did Microsoft not do this? I’d love to know. If you know, please enlighten us in the comments.
I would have to agree with you, but this is a historical ‘legacy’ thing with windows. If user Tom existed at the time of the hack, but was then deleted, and another user Tom created by someone else at a later date, it might appear to be the same Tom. But, in this case they would have different RIDs. I guess there would be other ways you could determine this as well.
I would have to agree as well. But at least have the ability to Tag a name to the RID or SID. Example S-1-7-23-3394466182-97151736-2635146241-1084 (DOMAIN\User) . Oh that would be nice! Nice article though.
Considering the Event Viewer resolves the SID, I expect Microsoft considers it to be correct behavior. It seems that Windows logs were not really meant to be aggregated and analyzed by non-Microsoft products.
Horrible, isn’t it Michael.
We get around this on the Snare Server side by pulling down the user to sid mapping, and then basically searching through the events, and tagging each SID with the corresponding UserID mapping.
I considered doing it directly in the agent, but the additional CPU requirement would have had sysadmins pulling their hair out when we’re talking kilo-events-per-second on some systems. The MS Log viewer can do it, since it tends to operate on ‘human viewing speeds’.
Unfortunately, other log formats often exhibit the same problem, sending UID’s exclusively rather than username information. As you mention, whilst technically ‘correct’, it certainly makes things awkward, and it also presents challenges for historical log analysis.
Sometimes log formats err too far on the side of human legibility, at the expense of ease of follow on processing (*cough*CISCO*cough* … really guys – people are not going to wade through 17 gigs of logs without some sort of tool, even if it’s just grep, awk and cut), whilst others streamline logs to the point of obfuscation. MS logs seem to wander between the two extremes.
Leigh. (Snare dev, InterSect Alliance).
Leigh, would you consider doing this, i.e have 2 versions of the agent ? we really need this capability..
Darren