PEBKAC Attack:
When logging logons leads to leaks of luser's lore
In a secure environment it's usually
in the best interest of the organization to log failed and successful user
access r, but there are times when logs may contain information that is best
kept secret. I doubt I'm the first to come up with this idea, but I'd like to
discuss it and give it a name for future reference: The PEBKAC Attack. Here's a
simple example of how this attack works that I think many of us security geeks
will relate to.
I've noticed in the past that once I know my logon password really well I can
type it in without consciously thinking about it. Sometimes I do it so fast I
hit the wrong series of control keys and end up typing my password in the user
name field by accident. This happens to me fairly often on Windows boxes that I
login to or unlock regularly. This of course causes my password to be saved (in
plaintext) as a name in a failed login attempt record (assuming auditing is
turned on). This has led me a few times to have to go into Event Viewer and
delete the record from the Windows Security event log (Of course, this problem
does happen on more than just Windows boxes, so *nix guys may want to check
their /var/log/* files). While doing security audits in the past I've manually
gone into logs to see if I could find just these sorts of user mistakes, what I
like to call a PEBKAC Attack. Rather than having to do it manually all of the
time I've decided to write a quick and dirty script in Autoit3 to automate the
process of searching for such a series of events in the Windows Security log.
What my script does is:
1. Look in the event log for a failed logon (Event ID 529), and then notes the user name involved.
2. Finds the next logon that was successful (Event ID 538 or 540), and then notes the user name involved.
3. Compares the two user names.
4. If they do not match, the script prints both to Stdout. The failed login name is presented as a possible password and the next successful logon as a possible user name for that password.
The command is simple to use, and I've even included the source which you can compile in Autoit3. If you issue it without any parameters it queries the event log on the local box:
C:\>pebkac.exe
Irongeek's PEBKAC Attack on the Windows Security Event Log ver .1
Successful Login (18): Adrian
Possible Password (2): ir0n g33k
Successful Login (871): Adrian
Possible Password (869): network logon password
C:\>
And if you specify the UNC name of another box it will try to parse the log from it:
C:\>pebkac.exe \\cthulhu
Irongeek's PEBKAC Attack on the Windows Security Event Log ver .1
Working on \\cthulhu...
Successful Login (868): Admin
Possible Password (864): god
Successful Login (871): Adrian
Possible Password (869): network logon password
C:\>
Pretty simple over all.
Now, I know there will be some people who will question the usefulness of this sort of attack, so I will try to preemptively answer some of their questions.
1. Don't you have to be an admin to see the log? How is this useful?
Answer: Well, it's easy to get local admin access on a workstation, I've done many videos and articles on that subject. After a pen-tester gained admin access on the local computer he could use this attack find a password for an Active Directory Domain user that fat-fingered his credentials. This could work great for privilege escalation.
2. Aren't there a lot of false positive?
Answer: Yes, there can be. But with a little thought it's easy to figure out which ones may be real passwords and which are just background noise. Also, this script includes the record numbers in which it found the events if you want to open them up in Event Viewer and take a look at them and the surrounding events yourself. Also, sometimes my parsing may be off as to which successful logon goes with which failure. Feel free to contribute fixes for my lack luster programming logic.
3. So, you have to be an admin to use this attack?
Answer: Well, for this specific tool, yes, but for some other systems the logs may be world readable. Also, it's possible to slightly modify the code to read an offline event log if you like.
Please send me your feedback on this script and attack method via the forums I frequent:
http://www.binrev.com/forums/index.php?showtopic=37936
http://forums.remote-exploit.org/showthread.php?p=86332
http://www.governmentsecurity.org/forum/?showtopic=29098
and if you try this attack on something other than a Windows Event Log I'd love to see and host your script here. Also, feel free to modify my script, but I'd like to get a copy of any improvements so I can give them to others. I'll be sure to add your handle/name to the source credits.
Thanks to BOFH139 for helping me to name the attack and the tool.