You are browsing the archive for Incident Response.

Too much % makes Event Viewer drunk

January 27, 2019 in Anti-*, Anti-Forensics, Forensic Analysis, Incident Response, Malware Analysis


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.

Trivial Anti-BlueTeam trick for 32-bit systems

December 6, 2018 in Anti-*, Compromise Detection, EDR, Incident Response

I love evasion tricks of any sort. Sometimes they can be very elaborate, and sometimes… incredibly trivial, almost stupid really. Such is the trick I am describing below. It works on 32-bit Windows only, and that’s because it relies on a folder structure that is (exclusively) present on 64-bit systems.

If we look at logs from various process monitoring tools we can notice that they omit a very important info. They don’t tell us what is the architecture of the logging system. Unless it is somehow self-evident (e.g. ‘bitness’ is a part of a host naming convention) there is no way to tell whether the process is executed on a 32- or 64- box.

These 3 folders are present on 64-bit systems only:

  • c:\windows\syswow64\
  • c:\windows\sysnative\
  • c:\Program Files (x86)\

Nothing (apart from access rights) stops us from re-creating them on a 32-bit system.

Imagine seeing the following paths in the logs indicating that calc.exe or iexplore.exe was launched on a system:

  • c:\windows\syswow64\calc.exe – from a 64-bit system
  • c:\windows\syswow64\calc.exe – from a 32-bit system
  • c:\windows\sysnative\calc.exe – from a 64-bit system
  • c:\windows\sysnative\calc.exe – from a 32-bit system
  • c:\Program Files (x86)\Internet Explorer\iexplore.exe – from a 64-bit system
  • c:\Program Files (x86)\Internet Explorer\iexplore.exe – from a 32-bit system

For all logs from 32-bit systems it’s obvious that they are fake.
How can you tell the difference though if your logs don’t tell you the architecture of the system where they come from?

This opens up a lot of opportunities for an impersonation.

Threat hunting efforts that rely on full paths for analysis purposes (whitelisting, LFO, etc.) could be easily fooled to accidentally exclude, or include bad processes that are executed from locations that pretend to be ’64-bit legitimate’.
And since most of the orgs are mixed 32/64 environments, the logs from all systems will be inevitably clustered together, and detection rules will be applied to them as a whole.

Admittedly, a malicious svchost.exe executed from c:\windows\syswow64\svchost.exe is definitely less suspicious than one starting from %APPDATA%:

Now, could this be a bad process?

  • c:\Program Files (x86)\Windows Defender\MpCmdRun.exe