Using Event Logs (Event 4624) to troubleshoot an alleged illicit login

At the company, I'm considered the Incident Response / Forensics Guru.  I'm certainly not a guru, but I'm the only employee (that I know of) with both the SANS GCIH and GCFA certifications.  Both of those certs are what I'm passionate about.  And I think it is a rule, all incidents have to occur just before you are leaving for the weekend.

So, it was 4:45 when the company internal security officer (and pen-tester) came to me with an issue.  He had been going through the Splunk logs when he found curious connections to his machine from one one the admins in the IT department.  I asked why he thought one of the admins might have been connecting to his machine, and he thought it might be retaliation for a sanctioned pen-test.  It seems the security officer had snagged the admin's credentials and had been using them during his pen-test.  The admin found out about it at least once and was trying to shut the security officer down.

So, it was off to look at some logs.  Our security officer was using OSSEC to aggregate all of the logs on his machine and was sending them to a log server.  He could correlate those logs with Splunk.  My first question was "What are we trying to prove?"  And the answer was:  "Did the admin "illicitly" log onto the security officer's machine?"  Fortunately, the security officer had EnCase on the machine.  The first thing we did was build a timeline, and look at the dates in question.  (Personally, I prefer the SleuthKit for this activity.)  The activity certainly showed a profile for another user being built.  But, there were no extraneous files accessed, created or deleted.  I thought maybe the admin was logging on to see what processes were running, or what activity was taking place.

My next step was to look at the Splunk logs.  Splunk showed a login, with the corporate id during the night.  I asked our security officer, why night?  He replied that he was running the pen-test at that time, and he might have used the id at that time.  So, now I was thinking, how can we prove whether or not this was truly an incident or the machine showing activity from the pen-test.  What I found interesting in the logs were that there was a login by the admin, but no logoff.  Why would that occur?

Looking at the log, I noticed that the EvenID was a 4624.  We Googled 4624, and found a great page with the fields laid out.  There were no entries for the Network Information so I was beginning to think that this might not be an incident.  We looked up the Logon Type and found a 2, which meant that this was a login through the keyboard.  Further, there was no Kerberos information, so no real authentication was occurring across the network.  I asked the security officer how he conducted the pen-test with the admin's credentials. He showed me a "run-as" batch script he had created, where he passed it the credentials of the admin.  It opened a shell with the credentials of the admin.  When he demoed it, it created the exact same log entry we were using to troubleshoot.

I was fairly confident that this was not an incident, merely a log entry created by opening the shell up with a different user.  Why were there no logoffs?  I posited that when the pen-test was over for the night, the security officer shut down his machine and never really "logged out" his shell script with the admin's credentials.

I suggested looking at the VPN logs, but apparently, our VPN ip address leases are not long, and we don't actively log their issuances and revocations.

So, it appeared to be no-harm-no-foul.  That kind of disturbed the security officer, I think he really wanted to catch the admin.  But the log and timeline evidence did not point to any nefarious activity.