Event Log Attack Patterns
This is work in progress. In fact, just
some quick notes on the way to a comprehensive paper on Windows event log attack
signatures.
An initial paper is now out on
"Detecting
Password Attacks on Windows".
This list here is far from being complete. It mostly serves as a think tank for
the upcoming paper. If you have a suggestion, please email me at rgerhards@adiscon.com. I
intend to update this paper as soon as I receive new ideas, suggestions or other
updates.
Please note that I already have some parts of the paper
underway (but not ready yet for publication) - this may be the reason that some
topics are missing.
Thanks,
Rainer Gerhards
Revision History
2003-02-26: added link to first paper out, added reference to security object reference helper
2003-02-21: First version assembled
Important Preliminaries:
- The default event lgo configuration supplied by
Windows setup is not useful for auditing and attack detection and needs to be
modified.
- Be sure to move log data out to a different log
server - an attacker can otherwise easily mess up with it. The log host should
be hardened.
- Event log data is probably not enough information to
track an attacker, just another source of wisdom. Also be sure to check several text log files, like IIS
logs, DHCP logs and so on.
Things to watch out for:
- Logon tries when FTP is set to “anonymous only” –
these will only show up in the FTP log files, not in Event Log
- System startup and shutdown notifications
- Look for event sources that never before have been
seen (When being hacked by ftp this is a favourite)
- Check your file system (new path, additional path,
very long names)
- Abandoned Terminal Server logins
- Elevated priviledge use
- simultaneous logins using the same account,
especially on machines in different buildings, etc.
- Attempted interactive logins on servers using
accounts where that has been turned off.
- Attempted share or ftp logins on workstations using
accounts that should be interactive only for the workstation.
- If you have naming conventions, then look for systems
put up that don't conform. Usually in the server logs and exchange logs.
- Child processes started by parent processes that
should not be starting that child. This is fun because you have to trace
backwards using process handles or maintain a handle-and-image-name list for
each system.
- Turn on auditing for important files and watch for
unauthorized processes accessing them. Another fun one.
- If you have a distributed logging system with closely
timed collections, then set up an 'at' job on each system to generate a
heartbeat mark message at < 1/2 your collection interval. If your
collections are every 5 minutes, then generate mark messages every 2 minutes.
Check for missing mark messages. You will know pretty quick if someone takes
down an important server and didn't tell you. You will also know quickly if a
hacker is trying to erase logs. They will likely be unable, unless they are an
insider, to re-construct your mark messages fast enough to beat your
collection interval if it is 3-5 minutes. Even more true if you use an obscure
mark message with a hash fingerprint of the timestamp or something.
- Set up a security policy that requires a "scheduled maintenance window" or
"emgergency maintenance incident" to be declared before admins touch the
systems. Then look for administrative activity outside the maintenance
windows.
Helpers:
|
