You are browsing the archive for EDR.

A few ideas to mess around with threat hunting, and EDR software (anti-threat hunting/anti-edr)

December 12, 2016 in Anti-*, Anti-Forensics, EDR, Incident Response

I just came back from holidays and since time off it’s usually a great time to make your brain run idle, it often turns it into a bit more creative device than usual. As a result I came up with a number of ideas that I will post about in the coming days. I’ll kick it off by discussing the anti-threat hunting/anti-edr techniques.

I do threat hunting for living, so it’s not just a post to play a devil’s advocate, but an invitation to discuss ways of detecting techniques I am going to present below (and potentially others).

To stay focused, I’ll mainly talk about the process creation events that can be typically analyzed inside Splunk (or other log aggregator) that is collecting Windows Event logs (f.ex. Security events with the Event ID 4688) and data from a typical EDR software (this includes sysmon). The discussion can be extended to other events quite easily.

Okay, so let’s assume that we have a nice collection of events showing us all the process names (and possibly command line options) from the systems and we already created rules for detecting some anomalies + we regularly review the alerts and new event logs to see if there is any new anomaly that we can potentially spot by just eyeballing data and codify into a new alert/watchlist. A clever attacker could attempt to modify our logs in a way that could affect these automated detections & analysis by attempting to hide the execution of some processes, or if lucky (I have not tested it), perhaps even hide some of the logs from the analyst.

Here’s how it could work:

  • Many watchlists focus on process names; changing a process name turns the watchlist useless (f.ex. macro could copy ‘powershell.exe’ to ‘harmless.exe’ before executing the powershell snippet, or ‘cscript.exe’ to ‘goodprogram.exe’); try it, it actually works and since the copy operation can be delivered via API, it may be hard to spot it by just looking at process logs; to detect it we would need to look at the flow of both process creation events and preceding it file system operations
  • Lots of analysis happen on Web UI level; if the EDR or Event Viewer doesn’t process the HTML entities correctly, there is a possibility of injecting tags modifying the flow of the generated HTML; I have not tested it, but it’s a possibility
  • Possibly a silly idea, but EDR has to store data somewhere and it probably uses some database; would a carefully crafted path or a file name cause an SQL command to fail? [similar to SQL injection; could we delete all records by doing SQL injection using a specially crafted event?]
  • There are potential bugs in EDR that can be exploited
  • Homomorphic object names f.ex. paths, and file names (using two identically looking Unicode characters with one non-English replacing opcodes for English characters) may make the analyst ‘blind’; if the attacker creates ‘c:\Windоws\system32\calc.exe’ and ‘o’ in ‘Windows’ is a Cyrillic ‘о’, the paths will look identical and casual eyeballing of the data will miss this entry classifying it as a legitimate ‘c:\Windows\system32\calc.exe’; this can be detected using data stacking, and by showing the non-standard English characters (especially these that can be used for homomorphic paths) using their Unicode code in an escaped form (or using a different color at least).
  • Delays are a trouble to sandboxes. The very same is true for EDR; if the events are generated slowly, it may be hard to correlate them + they will be interleaved by a large number of other, legitimate events; unfortunately, even basic event logs are quite noisy (load module, create open file/registry, etc. – lots of it comes from legitimate OS libraries; perhaps filtering of white-listed events is required)
  • Direct attack on EDR could prevent event interception; this is not bugs per se, but understanding how the software operates may help to bypass it:
    • If the EDR doesn’t work from kernel/hypervisor level, one could modify access rights to the malicious files so they can’t be accessed; same goes for directories, registry
    • If the EDR doesn’t protect its services, processes, registry keys, files from tampering, this could help to kill its functionality (same techniques as for AV)
    • Evasions could be built-in for specific EDR that bad guys don’t know how to bypass (EDR detection working the same way as sandbox / vm detection)
    • Finally, knowing the network protocol, one could potentially install a filter (or simply patch the code in memory) that would disable the event reporting that is related to malicious activity (EDR events going via malicious proxy!)
  • Using new hacking tricks may help to bypass EDR as well (good to follow the trends in pentesting world)
  • If the system is a web server, it may be hard to spot activities on the system if delivered via a web shell that talks directly to API
  • Also, lots can be done from ntdll alone and it’s resident in every process; and while using NT call, or even syscalls directly is trickier, it could bypass some of the user-mode EDR engines as well; in other words – spawning new processes is a lazy way malware does it today, but it may change in the future
  • and so on, and so forth…

rEDRoviruses – Whether you’re a AV or whether you’re a EDR, You’re stayin’ alive, stayin’ alive…

September 19, 2016 in Anti-*, EDR

EDR software is so hot right now. While AV is mainly focused on badness and silent detections/reputation analysis, the EDR solutions log everything. Sooner or later this ‘everything’ will cause trouble to bad guys and they will act on it. Interestingly, while killing AV doesn’t make that much sense (because it’s so afraid of triggering FPs), the nature and immaturity of EDR (and associated with it an omnipresent problem of dead agents) makes it actually a very easy target…

Such kill-EDR, or at least anti-EDR , or perhaps even just detect-EDR (which already exists) techniques are also important to offensive teams that will surely want to know about the EDR presence and … will try their best to bypass/avoid it…

It’s also important to remember that discussion of anti-EDR is very important for another reason. Most of AV is using anti-tampering technologies that prevent AV from being well… tampered with. EDR should follow these steps closely – otherwise, well… they will be tampered with too. And fundamentally, the more protection and attention is given to the security of EDR – the better. Think of the Project Zero blog that excels in killing bugs in a variety of software ranges – I don’t see any reason why they shouldn’t give it a try with EDR software…

The following is a bunch of ideas that EDR vendors should look into to protect themselves against being shut down:

  • Blocking via Software Restriction Policies
  • Blocking via AppLocker
  • Blocking via Image File Execution Options
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
  • Stopping or blocking WMI
    • Many agentless solutions relying on WMI may stop working
  • Disabling Windows Script Host (and VBS/JS) f.ex. via
    • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled
    • HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\Enabled
      • solutions using visual basic script will stop working – EDR relying on such a single Registry setting needs to ensure this setting is restored prior to execution of every script
  • Disabling the Powershell
  • Changing ACLs to directories/Registry entries
    • Potentially preventing log writing, config updates, etc.
  • Modification of hosts files
    • Same old, same old…
  • Stopping/disabling services
    • I won’t list service names, but they are easy to find
  • Analysis of kernel drivers of EDR solutions may help in finding new ways to escalate privileges