You are browsing the archive for Anti-*.

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

Using Start Time of the existing guest OS processes as a possible Anti-* trick

November 22, 2018 in Anti-*, Sandboxing

When you run the WMI command:

wmic process get name, creationdate

you get a list of process names, and their creation dates.

When I was testing it on my VM I realized that the results expose my VM as a sandbox. Since I saved the VM snapshot a while ago, the creation dates of many running processes were really old. Only a few processes had today’s date.

So, if you see any process (or a cluster of processes) that is older than… say… 6-12 months, it is highly possible that the sample is executed inside a sandbox. While the uptimes are much longer now than in the past, systems that run processes for more than a year are suspicious; after all, patching affects all the systems and if there was no restart within last year it’s at least unusual…