Making the Most Out of WLAN Event Log Artifacts

by SANS Blog on August 5, 2020

If you have taken FOR500 (Windows Forensic Analysis) or utilize the FOR500 “Evidence of…” poster, you are probably familiar with the WLAN Event Log listed under the Network Activity/Physical Location section of the poster. This Windows event log (Microsoft-Windows-WLAN-AutoConfig/Operational) records wireless networks that a system has associated with as well as captures network characteristics that can be used for geolocation. In recent testing involving this artifact, a discovery was made that may have implications for investigators. I will outline a scenario that illustrates the issue and present artifacts to help solve it.

Historically, the most useful artifacts from the WLAN event log are event IDs 8001 and 8003, which provide evidence of successful network connect and successful network disconnect, respectively. Below is an example of event ID 8001 that shows a successful network connection to NAT2 on 2020/06/06 at 14:30:41 EDT.

As the FOR500 poster indicates, this log is not the only source for Network Activity/Physical Location. Another artifact source exists in the registry under the SOFTWARE hive. Three “NetworkList” keys amalgamate to form a detailed picture of network first and last connections. Network information can be wired or wireless, and includes the SSID, gateway MAC, and record time in local system time. Utilizing Eric Zimmerman’s tool “Registry Explorer” as well as the plugin for “NetworkList,” we are able to show an example of this artifact, which indicates a first connect time on 2017/11/15 at 06:55:43 EST and a last connect time on 2020/06/06 at 14:46:13 EDT for NAT2.

Sponsorships Available

Sticking with the registry, another artifact pertinent to our examination is located under the SYSTEM hive. The “Interfaces” key lists the network interfaces of the machine, network information including IP addresses, DHCP lease information where applicable, and record time in UTC. Using the “Interfaces” plugin within Registry Explorer, we observe a DHCP lease obtained from NAT2 on 2020/06/06 at 18:46:13 UTC (2020/06/06 at 14:46:13 EDT).

If you are keeping track of the timeline of events, it appears that we have a ~16-minute gap represented by different artifacts intended to show evidence of the same activity. Below is the timeline of activity thus far:

In an attempt to determine the cause of the gap in our timeline, we head back to the WLAN event log to see if there are other events that could help explain our timeline issue. Upon further examination, we see an event ID 11005 with a description “wireless security succeeded” that was recorded on 2020/06/06 at 14:46:13 EDT. This is the exact date/time recorded by our registry artifacts mentioned above. We also discern that event ID 11005 was recorded at the same date/time as our original 8001 (network successful connection) event.

In addition to 11005, we observe event ID 11004 (wireless security stopped) recorded on 2020/06/06 at 14:45:11 EDT.

Adding these artifacts to our overall timeline below, we have additional context that explains the gap in our timeline.

Our connection to the NAT2 network stopped and started, but a full network disconnect/connect did not transpire since there was no record of 8001/8003 events. Given this scenario, an investigator may suspect that the System Windows event log could help shed light on the root cause of the wireless network stop/start events (11004 & 11005). The System log contains events associated with Windows services, system components, drivers, and resources. Upon examination of the System log, a hibernate event is observed that matches the timeline for our wireless security stop/wireless security succeeded events. As seen below, the system was hibernated on 2020/06/06 at 18:45:02 UTC (2020/06/06 at 14:45:02 EDT) and booted on 2020/06/06 at 18:46:11 UTC (2020/06/06 at 14:46:11 EDT).

Adding these events to our final timeline below, the investigator has full context and can explain in detail what occurred regarding the network activity on this system.

Finding: If a system is actively connected to a wireless network and changes to a low power state (hibernate or sleep) and wakes while in range of that same wireless network, event IDs 8003 and 8001 will not be recorded even though the system has effectively disconnected (at low power state) and connected (at wake). Evidence of network activity from the WLAN event log is limited to event IDs 11004 and 11005.

Implications: While there are multiple artifacts to shed light on this area of system activity, if an investigator is solely relying on the WLAN event log with event IDs 8003 and 8001, they may miss evidence pertinent to their investigation. Registry artifacts show an accurate last time connected, but the WLAN event logs are necessary to fill in the gaps and show a more complete view of network activity.

Note: Testing was performed on Windows 10 Version 1803 OS Build 17134 and Windows 10 Version 1909 OS Build 18363.

About the Author:
Christian Vrescak is a Sr. Incident Response Analyst at a major energy company. He is currently pursuing his Master’s Degree from SANS Technology Institute. You can find him on Twitter @d4n6k8.