Skip to main content
SearchLogin or Signup

Can You Track Processes Accessing the Camera and Microphone on Windows 10?

Published onNov 19, 2020
Can You Track Processes Accessing the Camera and Microphone on Windows 10?


Forensics Question:
Can you track processes accessing the camera and microphone on Windows 10?

OS Version:
Windows 10 Home Version 1909 Build 10.0.18363,
Windows 10 Enterprise Evaluation Version 1909 Build 10.0.18363,
Windows 10 Enterprise Version 1903 Build 10.0.18362

regedit.exe - Registry Validation,
Registry Explorer/RECmd (By Eric Zimmerman) - Registry Validation,
Zoom.exe – Testing access to camera/microphone,
Metasploit (record_mic module via meterpreter shell) – Testing access to camera/microphone


In certain investigations, it may arise that you need to find the following:

  • What process was using the camera or microphone?

  • When was the last session?

  • How long was that session?

Using the contents of the following reg keys, you can determine when and how long a process had access to privacy protected resources. These resources include the microphone, webcam, bluetooth, location, contacts and more. For this blog, I will focus on the microphone and webcam as an example.

Webcam Registry Key:


Microphone Registry Key:


With limited testing, so far these registry keys appear in 1903 or later versions in Windows 10.


Below is an example of the typical entries in the webcam directory. There are several entries including Microsoft and non-Microsoft applications.

Image for post

Microsoft applications are stored in as child keys but non-Microsoft applications (which are of the most interest) are stored in the NonPackaged child key.

Within the NonPackaged directory, you can see that the name of the keys are the full paths of an executable with # replacing \.

Each entry has two values, LastUsedTimeStart and LastUsedTimeStop, with the timestamps in FILETIME format.

From the example above, you are able to determine, Zoom.exe had access to my webcam for 27.2 minutes (between 2020/06/01 04:30:52 UTC and 2020/06/01 04:58:04 UTC).

Testing RAT-like behaviour

I needed to test if this also applied to more malicious methods of accessing the microphone. I used a meterpreter post-exploit module to record audio from Windows VM. I first set up a reverse meterpreter shell on my Windows 10 analysis machine and then ran record_mic.

Image for post

As soon as I ran the recording command, a new entry was populated from where my meterpreter shell was executed.

Image for post


If we wanted to track all sessions (not just the last), it is easy with Sysmon. If you are running something like the Swift on Security configuration, you will need to add an inclusion line for event id 12,13 and 14 (Registry modification):

<TargetObject condition="contains">SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\</TargetObject> <!-- When a process accesses bluetooth, location, webcam, microphone etc, the timestamps of last access are updated here. HKLM and HCKU -->

After updating your configuration, a Sysmon event will now be created when the registry keys are created or updated. Below is the LastUsedTime key being updated for Skype.exe accessing my microphone in the Sysmon event log.

Image for post

The timestamp in the log are still in hex which needs to be converted to decimal then to a human readable timestamp, however the timestamp of the event itself is also very accurate.


Whether you are looking at what processes had access to a webcam or even trying to prove long a user’s conversation may have been, this is a great source of information.

What spurred this off is when I came across this page in the settings, and it got me thinking on where this data is stored.

Image for post

It will be interesting if there are other places that track historical sessions without the use of monitoring. This would be more valuable to forensic analysts that don't always have nice logs.

Further research also could be done to identify which device the process is accessing (front camera, USB camera etc). I would also like to explore if this method catches more covert RAT malware.

Thanks for reading,

Zachary Stanford

DFIR Review

The blog covers a precise artifact to answer a specific question. The investigative questions are clearly expressed. This approach is interesting for spyware and malware detection. The comment about using a custom sysmon configuration is interesting but may not be available to the forensic examiner.

Future Work

Additional work could include looking at the Windows 10 Timeline for correlation. The registry transaction logs might also provide a picture of activity over a period of time. It might be useful to determine if the storage of artifacts in the registry can be turned off by a system setting.


Zheng Jie Chan (Methodology Review, Validated Review using Reviewer Generated Datasets)

Adrien Vincart (Methodology Review)

Timothy Bollé (Methodology Review, Validated Review using Reviewer Generated Datasets)


No comments here