Get USB device information

I have a script that gets me just about all I need to know on USB devices attached to the system using Get-PNPDevice and Get-PNPDeviceProperty. What I cant seem to find is the User that plugged in that device. Google yielded no results, at least not that I found. I am only able to correlate the times obtained from these cmdlets with user login info for one week as the logs are cleared and archived weekly, which is better then nothing, however, some of the times returned on some systems are months ago.

Is there some back door trick or C# code I can leverage to find out what user plugged in the device? I am only gathering USB Disk/Mass Storage info, dont care about anything else.

Thanks in advance for any help you can provide.

I’m going to suggest the user information isn’t logged and you won’t find it without a lot of messing about.
While I don’t know for certain, the reason I say this is that I have used Nirsoft’s USB Log View and USB Device View tools which show a wealth of USB device information but not the user that removed/inserted the device. I’m sure those tools would show the user if the information was available.

Regarding the messing about I mentioned above. You may be able to find the GUID of the device as a mountpoint in the user’s registry hive and then match that to the user.

Unless you have a camera watching the machine, how could you possibly know. If you mean who was logged in when the USB device was plugged in, you can easily get that from the security log.

This is what he’s asking to find. I’m curious too so I’ll await your easy example. :smiley:

1 Like

Thanks Matt on the mount point in the registry. I will have a look at that. Here is more detail on what I am doing.

I am using Get-PnPDevice to find the devices, then I enumerate through the devices getting the First Install Date, Last Inserted Date, and Last removed Date using Get-PnPDeviceProperty. As I stated, I can use these dates to check the security log for who was logged in on that day, however, the logs are cleared weekly and some of the dates/times I am seeing are weeks, months and sometimes years ago. Additionally, there can be multiple users on the system per day and narrowing down the USB time with a correlating 4624 event could be tricky at best.

To further muddy the waters, neither of these CmdLets are available on Win7 or server 2012.

I know what your thinking, who cares about weeks/months/years ago? Sadly, my company does for reasons I wont bore you with.

There are some great log entries that will track USB connection so if you have those enabled, this will be easy to find using Get-WinEvent. This article starts with a good explanation of those log events and where to find them.

If you don’t have those log events enabled but do have registry changes logs enabled you could use a combination of Registry Entries along with logging to figure out who was logged in. That article also shows the registry entries created by plugging in a USB device. If you are looking for something malicious, it is possible to cover these tracks if the user has administrative priv in the machine or the machine is compromised and the malware has elevated priv.

Get-WinEvent -FilterHashtable @{Logname = 'Security'; ID=4657}  |
    Where-Object {
        $_.message -like '*SYSTEM\ControlSet*\Enum\USB\*'
    } 
1 Like

Thanks ralphmwr … already doing all that. I just need to find the user that plugged in the device. Right now, I am just correlating the LastRemovalDate from Get-PNPDeviceProperty with 4624 events in the security log and grabbing “possible” users from there based on that time since the removal date and login date will never match exactly. I think that is the best I can do at this point. Of course, with the logs being cleared weekly, the removal dates I am finding from weeks/months/years ago cant be correlated, hence my question to the forum.

Thanks again, appreciated :slight_smile:

4657 has the security identifier for the subject account. Here’s an example of a log entry (XML view).

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" /> 
  <EventID>4657</EventID> 
  <Version>0</Version> 
  <Level>0</Level> 
  <Task>12801</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8020000000000000</Keywords> 
  <TimeCreated SystemTime="2021-04-05T13:20:25.6375589Z" /> 
  <EventRecordID>312708</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="4" ThreadID="26904" /> 
  <Channel>Security</Channel> 
  <Computer>DESKTOP-45U5M41</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data Name="SubjectUserSid">S-1-5-21-1025438829-2302907773-1309982554-1002</Data> 
  <Data Name="SubjectUserName">micha</Data> 
  <Data Name="SubjectDomainName">DESKTOP-45U5M41</Data> 
  <Data Name="SubjectLogonId">0xd04e861</Data> 
  <Data Name="ObjectName">\REGISTRY\MACHINE\SYSTEM\ControlSet001\Enum\USB\AnotherKey</Data> 
  <Data Name="ObjectValueName">Hello</Data> 
  <Data Name="HandleId">0x540</Data> 
  <Data Name="OperationType">%%1905</Data> 
  <Data Name="OldValueType">%%1873</Data> 
  <Data Name="OldValue" /> 
  <Data Name="NewValueType">%%1873</Data> 
  <Data Name="NewValue">World</Data> 
  <Data Name="ProcessId">0x398c</Data> 
  <Data Name="ProcessName">C:\Windows\regedit.exe</Data> 
  </EventData>
  </Event>

My SID and username are in the data.

Interesting ralphmwr. I am not getting any 4657 entries at all in my security log (just plugged in 3 new USB thumb drives). Upon investigation, according to this site: Windows Security Log Encyclopedia

“Of course this event will only be logged if the key’s audit policy is enabled for Set Value permission for the appropriate user or a group in the user is a member”

I am not able to set registry auditing in our environment. Can you elaborate on if you had to enable auditing on that key in the registry?

Thanks.

Yes, it was already enabled. From a security standpoint, I’d recommend that setting. It can be set via GPO.

Thanks ralphmwr. I will stick with what I have moving forward. Registry changes GPO or otherwise just aint gonna happen in our environment.