You are browsing the archive for Compromise Detection.

Why PUA/PUP are bad for you a.k.a. the evil of environment fingerprinting

November 9, 2015 in Compromise Detection, Incident Response, Preaching

In my post about sample targeting EDR I mentioned that the sample is a PUA/PUP. Looking at the code of many PUA/PUP/adware samples created in last few years it’s easy to see how far they go nowadays in fingerprinting the environments.

This is why many of them should be treated as malware & should not be ignored in ‘business as usual’ IR activities.

In the aforementioned post I listed a couple of routine names that that particular sample used. All these routines are called one by one, and a final string is generated containing reference numbers associated with each ‘discovered’ piece in the environment.

fingerprintingThis is no longer just a sandbox detection.

EDR, VPN, AV, security tools, often list of updates, hotfixes, full software list from registry, etc. is added too. Someone, somewhere populates some large databases with a lot of this ‘goodness’.

One can imagine that this data may be a very valuable piece of information – it could be sold not only to advertisers, software writers, even companies whose products are being profiled (competition/market research), but also – of course – on a darker side – to random malware authors, and guys specializing in targeted attacks. If you think of it, a good PUP/PUA campaign could be even orchestrated by the actual BAD guys.

If 0days allow a way in, a database with an information about used software may simplify and speed up a lateral movement. And why bother doing all the time-consuming illegal hacking/malware infestation/recon if you can simply deploy borderline software first. Let it populate a huge matrix including lots of information about as many hosts as possible in as many organizations as possible. And then, with such precise information about installed software & deployed countermeasures it can be leveraged to simplify many hacking operations (and targeting).

This is of course scaremongering on my side and a conspiracy theory in the making, but the only reason I am writing this is that if you are ever looking for arguments to treat PUA/PUP as malware… or someone argues that PUA/PUP can be ignored in your AV alerts then the massive fingerprinting they do nowadays is the big one…

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…