Category Archives: Forensic Analysis

Event Logs++

Posted on by

Inspired by Samir’s findings about “programs running from Run/RunOnce Auto startup locations using events Microsoft-Windows-Shell-Core/Operational EID 9707/9708“, I decided to go through all the win10 Event Logs on my test box.

Just causally browsing through these I was able to quickly find a number of interesting (DFIR-wise) logs that I was not aware of. I am pretty sure many researchers did that before, but I thought it will be an interesting exercise anyway, given (at least in my experience) there is a significant difference between logs available on different systems…

Before we continue, let me repeat what I said on Twitter – you should follow Samir – he has some great Threat Hunting examples in his Twitter feed!

All the logs listed below are located under: Applications and Services Logs\Microsoft\Windows. It’s obviously far from a complete list, but if you never looked at these, perhaps this post will motivate you to poke around…

  • Alternative way of tracking system date/time changes.
    • DateTimeControlPanel\Operational
      • e.g. The system time was set successfully with the following parameters: wYear: 2015, wMonth: 6, wDayOfWeek: 1, wDay: 22, wHour: 12, wMinute: 54, wSecond: 4, wMilliseconds: 0.
    • Time-Service\Operational
  • Program/App Execution
    • Application-Experience\<various>
    • CodeIntegrity\Operational
    • App* e.g.
      • AppModel-Runtime\Admin
      • AppReadiness\Operational
    • Win32k\Operational
  • DHCP changes
    • Dhcp-Client\Microsoft-Windows-DHCP Client Events\Admin
    • DHCPv6-Client\Microsoft-Windows-DHCPv6 Client Events\Admin
  • Various diagnostic logs that may point to existing files on the system that in turn may contain references to interesting artifacts
    • Diagnostics-*
  • References to USB devices
    • DriverFrameworks-UserMode\Operational
  • References to modifications of Regional Settings/Languages
    • Internationl\Operational
      • e.g. Process number 3056 (C:\Windows\system32\rundll32.exe) called SetUserGeoID(104) successfully.
    • International-RegionalOptionsControlPanel\Operational
      • e.g. The user changed their location preference (GeoID) to 104.
  • References to Kernel Event Tracing
    • Kernel-EventTracing\Admin
  • History of Network profiles
    • NetworkProfile\Operational
  • History of issues with network gateway
    • NlaSvc\Operational
  • User logon events are listed here
    • OfflineFiles\Operational
    • User Profile Service\Operational
  • Changes of the default printer
    • PrintService\Admin
  • Terminal services logons
    • TerminalServices-ClientActiveXCore\Microsoft-Windows-TerminalServices-RDPClient/Operational
    • TerminalServices-LocalSessionManager\Operational
  • LiveID-related logs
    • LiveId\Operational
  • Security Mitigations (not sure what it is, but seems to be detecting dynamic code)
    • Security-Mitigations\Operational
  • Lots of Shell-related activities
    • Shell-Core\*
  • SMB logs
    • SMBClient\*
    • SMBServer\*

Too much % makes Event Viewer drunk

Posted on by

Update:

After I posted it Daniel Bohannon provided a link to his earlier research (March 2018) where he described the very same problem. He has some interesting examples so please have a look!

Old Post:

This is a short post about a funny side effect of using the % sign and how these are being interpreted by Windows Events Log Viewer.

When you use this character as a part of a file name, or as a Registry data the program will assume these % signs are referring to actual parameters and will resolve them into actual strings.

I know it doesn’t make any sense, so let’s do a test.

Name your program %1.exe. Run it. This is what the Viewer will show:

Now try to add this Registry value:

reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run /v Foo /t reg_sz /d test%1%2%3%4%5%6%7%8%9%10%100

The result? Very strange details:

What about naming the program %1%2%3.exe?

Look at the image and the command line. One is: C:\Test\2019-01-27 22:28:29.601{670b5bbc-308d-5c4e-0000-00105f407c03}.exe, and the other “C:\Test\Incorrect function.The system cannot find the file specified.The system cannot find the path specified..exe”.

Only the viewer is fooled, because the actual data is logged properly (although there is an inconsistency in the way %s are doubled in command line) — one just needs to go to Details tab and see what it really shows:

That’s it. Yet another quirky behavior to be aware of.