Debug Environment Variable are \o/

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.

Cur\o/bin

This post wraps up another Twitter thread I started a few days ago:

If you ever get bored using “copy” to copy files you can always use … curl:

curl file://c:\test\foo -o bar

Same way, you can use it instead of “type” or “cat”

curl file://c:\test\foo

You can also copy file by… uploading it locally

curl -T bar file://c:\test\

this will copy “bar” file to “c:\test\bar”.

And during copying, you can stat copying at a given offset:

and even cooler, you can extract any part of the file using range

curl file://c:\test\foo -C 1

dynamic payload building anyone?

and even cooler, you can extract any part of the file using range

curl file://c:\test\foo -r2-10

offering a chance to build dynamic payloads.

The operation is surgical and using Procmon we can confirm it reads only these two specific bytes:

@nf3xn added one more interesting option:

curl --remote-time file://c:\test\foo -o bar

to preserve file timestamps.