Category Archives: Forensic Analysis

AntiEDR – Samples targeting EDR (Endpoint Detection and Response) solutions

Posted on by

I have recently came across an non-intriguing intriguing sample belonging to a family of applications commonly known as a PUA/PUP (Potentially Unwanted Application/Program). The ‘intriguing’ part is that it is the first one I have ever came across that actively tries to detect an EDR solution installed on the system, and in this particular case – CarbonBlack.

The sample md5 is 1233411098A5EE69EB925C559B815510.

What caught my attention was a string ‘IsRunningCarbon’ that I came across when i was eyeballing some of the logs generated by my batch analysis script.

It was placed among many other interesting strings f.ex.:

  • IsTestingBox
  • IsVirtualMachine
  • HasVirtualDrive
  • IsRunningOnVMWare
  • IsRunningOnHyperV
  • IsRunningOnVBox
  • IsRunningOnXEN
  • IsRunningVPN
  • IsRunningIPSECLP2
  • IsRunningOpenVPN
  • IsRunningPPTP
  • IsRunningTools
  • IsRunningFiddler
  • IsRunningFiddlerCert
  • IsRunningDeepFreeze
  • IsRunningPacketCapture
  • IsRunningAVs
  • IsRunningESET
  • IsRunningVipre
  • IsRunningCarbon
  • IsFlashInstalled

so it looked like a part of a generic ‘sandbox/monitor/security product detection’ pack of routines.

When loaded into ILSPY, the code of the function referenced by the name turned out to be a simple ‘directory present’ check (if the ‘CarbonBlack’ directory exists in a predetermined location), but the message the existence of this routine in the code sends to the EDR vendors is that they start to be recognized.

carbonPerhaps it’s not a big deal, but certainly notable. Maybe it is time to introduce randomization in the way EDR-specific directories are named? Or hide them completely (rootkit)?

Of course, the detection of EDR was always possible, but since now it is being actively done I bet it’s just a matter of time when we will see first evasions…

Java and .oracle_jre_usage folder

Posted on by

Today I installed the latest version of Java SDK (8.0.660.17) for testing purposes. After the installation on the good ol’ XP I noticed that it created a folder named %userprofile%\.oracle_jre_usage. This looked interesting so I googled for it. Turns out lots of people spotted it in earlier version of Java and someone on Oracle forum even provides a good explanation as to what Java component it is from:

That is the default location for the Java Usage Tracker. See the Oracle docs
https://docs.oracle.com/javacomponents/usage-tracker/overview/

Since the folder is created even if the Usage tracker is disabled, we can leverage it as a yet-another-minor timeline-related artifact that can be potentially useful for cherry-picking two Java-related timestamps:

  • when Java was installed (more or less, see below)
  • when was the last time java.exe was launched (most likely to execute an application; I have not tested JRE & applets yet)

The folder ‘%userprofile%\.oracle_jre_usage’ is created during Java installation:

oracle0

so you should find at least one randomly named file in this folder. In my case it was:

  • 90737d32e3aba4b.timestamp

Inspecting its content shows a path leading to Java JRE and a timestamp in a format that appears to be a Unix timestamp with microseconds:

oracle1

gives us 1446745410996 which roughly translates to 2015-10-05 09:43:30:996  – somewhere in-between the logs shown in Procmon output (could be a discrepancy between the time of retrieving of the timestamp and time of actually writing it to a file).

Running actual Java program causes the java.exe to look for ‘f9b9f6b8ff8b2b60.timestamp’ (refer to Procmon screenshot above) – this is randomly named file as well so if you look at the folder, you should see 2 of them.

If not found it’s created and its content is similar to ‘90737d32e3aba4b.timestamp’: the path and the Unix stamp.

The following screenshot shows how the Unix timestamp is changing anytime we run java.exe to execute a simple HelloWorld Java application (HelloWorld.class):

oracle2To conclude: nothing ground breaking, but yet another pair of timestamps that may help with the investigation one day…