Hello Reader,
This was a popular contest, I got a lot of submissions and the majority of you clued into the event logs that LogMeIn generates in the Application event log! This is what I was hoping you would research and find, but this weeks winner went beyond the Application event log and found some interesting artifacts that I wasn't aware of! So this week we salute Doug Collins who earned his prize.
The Challenge:
This was a popular contest, I got a lot of submissions and the majority of you clued into the event logs that LogMeIn generates in the Application event log! This is what I was hoping you would research and find, but this weeks winner went beyond the Application event log and found some interesting artifacts that I wasn't aware of! So this week we salute Doug Collins who earned his prize.
The Challenge:
You have a forensic image Windows Server 2008 R2 system that the former administrator installed LogMeIn on. You have been told that your client suspects that the former administrator has logged in remotely and shutdown database services preventing the company's webstore from functioning. When you go to review the LogMeIn logs you notice they have been deleted from the system.
Where can you look on the system, other than the free space of the disk for the logs, to determine when the ex-administrator used LogMeIn to access the system.
The Winning Answer!:
Doug Collins
The first place to look is for the low hanging fruit. First, I’m going to look in the $Recycle.Bin for the deleted files, then I’ll move on to the volume shadows. The ex-admin may have deleted the log files; but it is unlikely that he cleared out the shadow copies of that folder. I will mount the image of the drive using Encase PDE and use the vssadmin tool to find the shadow files of interest. Those files will be linked to my forensic box and parsed for the last instance of the log file.
C:\ProgramData\LogMeIn\LogMeIn.log.
If that fails, the next stop will be the event logs. LogMeIn creates a number of event upon each log in attempt or success.
- Application Log
- EventID 102 – Source LogMeIn
- User WIN-XXX\dc has successfully logged on from IP address AA.BB.CC.DD Secure (SSL) Connection: Yes
- EventID 202 – Source LogMeIn
- Remote Control session started for user WIN-XXX\dc from IP address AA.BB.CC.DD. The interactive user (if present) has not been asked for a confirmation.
- EventID 9011 – Source Desktop Window Manager
- The Desktop Window Manager was unable to start because a mirroring driver is in use.
- Security Log
- EventID 4648 – Source Microsoft Windows security auditing
- A logon was attempted using explicit credentials.
- Process Name: C:\Program Files (x86)\LogMeIn\x64\LogMeIn.exe
- EventID 4624 – Source Microsoft Windows security auditing
- An account was successfully logged on.
- Process Name: C:\Program Files (x86)\LogMeIn\x64\LogMeIn.exe
- PrinService
- EventID 823 – Source Microsoft-Windows-PrintService/Admin
- The default printer was changed to Samsung ML-3050 via LogMeIn,winspool,Ne02
The SOFTWARE hive in the registry will reveal some information, related to the last time that the LogMeIn software was used. It won’t be a detailed list of logins, but it will match back to the last login made with the software. Specifically, the HKLM\SOFTWARE\LogMeIn\V5\Net\NATUDP gets updated when connections are made.
The last place I would look, before carving for deleted log files, would be to take a look at the prefetch files. It won’t give me as detailed a list of logins as the other places; but I will be able to determine the last login attempt. It looks like at least two prefetch files are created.
- C:\Windows\Prefetch\LMIGUARDIANSVC.EXE-ABCD1234.pf
- C:\Windows\Prefetch\LOGMEIN.EXE-ABCD1234.pf
However, it is unlikely these will be on this system, as Superfetch is disabled on Windows Server 2008 by default.
Also Read: Daily Blog #140
Post a Comment