Author Archives: adam

Debug Environment Variable are \o/

Posted on by

Looking at the list of debug environment variables one can immediately spot a lot of room for abuse.

One can hypothesize that setting e.g. _NT_SYMBOL_PATH, _NT_ALT_SYMBOL_PATH, _NT_SYMBOL_PROXY, SRCSRV_INI_FILE to point to a malicious server will ensure that next time OS or any application tries to reach out to Symbol server, it will actually ping the malicious server first. It could be a nice semi-covert channel to communicate with C2. Moreso, if executed via proxy e.g. via existing software (ideally OS or some coding components) e.g. Windows Error Reporting (WEFault.exe), debuggers (windbg, cdb), sysinternals tools (ProcMon), and other reversing tools (IDA), etc – the fact it’s the good guys calling out may help to hide the activity from prying eyes of EDR/AV.

Other ideas can circle around abusing paths e.g. _NT_DEBUGGER_EXTENSION_PATH and WINDBG_INVOKE_EDITOR to use them both as a persistence method and/or for LOLBIN purposes.

In my tests, not all tools obey these environment variables so YMMV.

SleepStudy logs

Posted on by

Update

After I posted it, Bryan linked to this article which explains how to generate SleepStudy report. Thx!

Old Post

A few days ago I came across ETL logs I have not seen before. They are residing inside c:\WINDOWS\System32\SleepStudy and I posted about them on Twitter. Not sure if anyone looked at them from a forensic perspective in the past – quick Twitter and Google search returned nothing of interest, hence decided to quickly describe it here.

The logs originate from “Microsoft-Windows-Kernel-Power” and “Microsoft-Windows-UserModePowerService” ETW providers. Files that can be found inside the directory are as follows:

  • c:\WINDOWS\System32\SleepStudy\
    • ScreenOn\ScreenOnPowerStudyTraceSession-YYYY-MM-DD-HH-MM-SS.etl
    • UserNotPresentSession.etl
    • user-not-present-trace-YYYY-MM-DD-HH-MM-SS.etl

These marked with a YYYY-MM-DD-HH-MM-SS patterns include timestamps, meaning multiple files following the same file naming pattern exist in the folder.

The user* files can be quickly converted from ETL to XML format by using the following commands:

tracerpt.exe <etlfile>

or

tracerpt.exe -of csv

if you prefer CSV output. The resulting files are dumpfile.xml or dumpfile.csv.

What triggered my interest was the fact we can see both paths and timestamps inside the output user* files:

I don’t know exactly what these log mean, but it can be yet another source of process execution telemetry.