A Logo

Feel free to include my content in your page via my
RSS feed

Help Irongeek.com pay for
bandwidth and research equipment:

Search Irongeek.com:

Affiliates:
ISDPodcast Button
RootSecure Button
Social-engineer-training Button
Irongeek Button

Web Hosting:
Dreamhost Logo
Help Irongeek.com pay for bandwidth and research equipment:

paypalpixle




PEBKAC Attack: When logging logons leads to leaks of luser's lore

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.

Download PEBKAC

Thanks to BOFH139 for helping me to name the attack and the tool.

Printable version of this article

15 most recent posts on Irongeek.com:


If you would like to republish one of the articles from this site on your webpage or print journal please contact IronGeek.

Copyright 2014, IronGeek
Louisville / Kentuckiana Information Security Enthusiast