Category Archives: Incident Response

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…

Enter Sandbox – part 10: Removable devices & clickbait file names

Posted on by

Infection of removable drives is an old trick and no point explaining what it is. What is interesting though is looking at creativity of guys who leverage this infection vector and not the ones that exploit the autorun.inf mechanism (yawns!), but the one that focuses on social engineering.

Assuming that a potential victim of ‘removable device infection’ is typically not a very computer savvy individual is actually quite easy. We all know that it’s the guys like these that are a typical pray for malware authors.

But are they the only ones?

There is so many things one can do to place clickbaitfiles on the removable drive that the victim will end up clicking. It is stronger than us. Whether a rookie or a pro. You have seen it, I have seen it – the guys clicking, clicking… until it works. I have done it too.

Infection via a removable device is still a perfect social engineering platform and I’d say it is not going away anytime soon.

Looking at some of the sandboxes samples I have analyzed I created a short list of tricks I have spotted so far (send me more if you know others, and care to share).

  • hide the folder, create an .exe with the same name and ensure the .exe is using a folder icon
  • use ‘current’ and ‘directory up’ file names i.e. ‘..exe’ and ‘…exe’
  • use important-looking file names, also in foreign languages

匆删(重要资料).exe

  • leverage desktop.ini to change the appearance of the folder (f.ex. bin folder)
[.ShellClassInfo]
CLSID={645FF040-5081-101B-9F08-00AA002F954E}
  • use various file extensions: .exe, .scr, .pif, .lnk
  • double .exe (.exe.exe), triple .exe (.exe.exe.exe)
  • intriguing names (sex&pr0n in general, controversy&scandal)
  • use attractive looking icons – yup, it’s thats imple
  • Fake Recycler folders
  • obviously, a randomized autorun.inf is a norm now
[AutoRun]
;FLvfB ysQiGKArLcs 
sheLl\open\commAnD = ukxfqq.pif
;fWJoARTstov kivfsp 
SHeLL\oPEn\dEfault=1
;tCcl bcaolB WdIa BdqhbkeGrp
Shell\explorE\COmmand= ukxfqq.pif
;ngFiihrOUk 
open =AutoRun.exe
;KyGpw
shEll\AutOpLAY\COMMaND=ukxfqq.pif
shell\1=Open
shell\1\Command=AutoRun.exe
shell\2\=Browser
shell\2\Command=AutoRun.exe
shellexecute=AutoRun.exe
;YtGyagvMMf ceqdP ymhOtYeaQn

Look at the screenshot below.

Be honest.

What you would NOT click?

mind you – it is good ol’ Windows XP!

removable

and same – on Windows 7

removablew7

 

 

Update

What does the topic of this post have in common with sandboxing?

It would be cool for sandboxes to highlight these artifacts (if they don’t, yet)…

If any sample drops its copy on a removable drive or another well-known file associated with social engineering i.e. exhibits one of the behaviors described above (and more, subject to more analysis) the ‘maliciousness’ score can easily go up.

Everyone wins. I hope 🙂