Darren

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).

Penetration Test :

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.

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.