Hidden value of Windows 673/4769 events in your SIEM

If you are like me you are always (or in stages) on the lookout for “noise” events to filter out of the SIEM. Windows event 673 is fairly tempting in that regard. However, depending on what sources you are pulling in you can leverage these events, which are recorded on your DCs, to see PCs hitting other PCs. There are two main limitations to these events. The first is you can’t see what network resource on the destination the source is trying touch. The second is you can’t see if the attempt was successful or not. If you REALLY needed that information though you probably have the appropriate level of logging turned on at the destination anyway.

Go here and here to learn all kinds of goodly technical things about 673s.

I can only speak within the context of ArcSight so if you are using something else you are going to have to see what fields things are in. First you are going to want to filter out where destination service name = krbtgt and where message = Ticket expired frequently logged by computer accounts. The next thing is you WANT to see where destination service name ends with a $ (meaning computer account). Depending on what you are after and how you are set up you may or may not want to ignore servers in general or file servers specifically. This recipe is one you can season to your tastes! The key though is the data in the destination service name field is what the source system is trying to touch.

At this point you can create a couple different rules/Trends/Active Lists/whatever based on what it is you want to see. For example, it is quite uncommon for a single PC to access a handful of computers within a short timeframe. You could create a rule looking for something like 10 different destinations in 1 minute. A hit on that rule could be indicative of a worm (or some idiot who somehow thought searching his network neighborhood would really return his lost report). You could also back track the events to see what all sources are trying to touch specific systems. Depending on your use of zones you could play around with which source zones are trying to access a particular system. Remember the event itself is recorded on a DC so the DC’s destination would be in the destination zone name field. You will probably have to use a variable or three if you want to really leverage the data in the destination service name field or even to filter out where the computer in the destination service name is itself in order to cut down on partial matches.

Would be interested in hearing about successes or how you are using these events!