You are browsing the archive for Batch Analysis.

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

November 7, 2015 in Anti-*, Anti-Forensics, Batch Analysis, Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

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…

Beyond good ol’ Run key, Part 33

October 20, 2015 in Anti-*, Autostart (Persistence), Batch Analysis, Clustering, Compromise Detection, Forensic Analysis, Malware Analysis

There is a secret place in almost every organization utilizing Microsoft Outlook where malware can hide.


The pros: no one checks it.

The cons: there is no API to make it easily work (directly).

About the cons – one has to either install the malware manually, or employ some sort or macro / autoit / sending messages trickery. Direct access /via code/ is also possible, but we have yet to find someone brave enough to reverse MAPI and internal interfaces of Outlook that can automate this process.

I am of course talking about the mechanism of executing program as a part of Outlook Rules.

Here is a simple example of running a calc.exe anytime someone receives the message:

outlook1Yup. It’s that simple. It’s not visible in Registry, it’s not visible on the file system level. I am not even sure if any of the PST reading solutions out there can read theses rules somehow…

And how to add these?

As I said, there is no actual interface at the moment known, but one can employ macros, sending messages, etc.. One can also use the convenient mechanism that allows importing of the rules via Outlook:


If you are eager to reverse engineer these, look at the API OpenStreamOnFileW. Enough said :)