Bypassing Cisco’s Sourcefire AMP endpoint solution – Full demo & comparison with RSA NWE

This article will demonstrate one of the key differences between NG AV endpoint protection and EDR solutions such as RSA NetWitness for Endpoints. In this article, we will demonstrate how Cisco’s endpoint protection solutions Sourcefire AMP is easily bypassed by performing a buffer overflow and in-memory post exploitation activities. This test was performed on a fully patched Windows 10 machine with an active MS Defender, MS Firewall, Cisco AMP & RSA NWE agent installed.

The setup used for this test was the following:

1

Windows 10 client protection verification

2

Vulnerable application is installed and running

3

Cisco SourceFire AMP does not find any issues on the clean machine

4

AMP tracking information does not highlight any suspicious activities

5

RSA NWE does not find any suspicious activities on the clean machine

6

Attacker – KALI setting up exploit & payload module

7

8

Running remote buffer overflow exploit

9

No alerting from either Cisco AMP or MS Defender…

15

Attacker runs additional post exploitation activities such as a keylogger

11

Attacker searches and downloads password.txt & creates a screenshot

12

Attacker performs a ARP network scan

13

Attacker start an interactive SHELL and runs WHOAMI & IPCONFIG commands

14

Still no alerting from either Cisco AMP or MS Defender…

15

Cisco AMP does not detect or notifies on exploit and post exploit activities….

23

16

Now let’s look at RSA NWE

17

1819202122

What would you prefer?……. :-S

 

 

 

Geplaatst op september 30, 2016, in RSA NetWitness. Markeer de permalink als favoriet. 6 reacties.

  1. It’s cool you work for RSA and that possibly explains why you are not able to understand how to interpret AMP alerts. It’s clear from your (unclear) screenshot that fsws.exe is launching a command shell and running whoami.exe among other commands that you launched from meterpreter. It’s pretty obvious that something is unusual with that process if you look at the AMP screenshot carefully. I’m not saying AMP is great, but I am saying you don’t know how to interpret its results if you think it didn’t detect this behaviour.

    • Hi Analyst 13. Thank you for your comment! Yes your right I currently work for RSA and because of that have less experience with AMP than NWE. You are also right the AMP process tree shows commands executed by fswe.exe which I ran in the meterpreter session. What I found worrying though was these activities did not generate alerts, got marked or increased the risk rating of the endpoint. Additionally, I was surprised to see AMP did not show the injection of the exploit or payload in memory and its relation to the fswe.exe process. As I find these capabilities key when monitoring large infrastructures and responding to security incidents, I wanted to highlight them to explain the difference between NGAV and EDR tools like NWE and others. Nevertheless, this is just my personal opinion so I am more than happy to learn about other point of views and experiences

  2. What is highlighted in this example is ECAT’s capability for examining floating code based on a point-in-time scan, which is not a strong point for AMP.
    Questions & observations:
    Did ECAT actually block this from happening? No
    How many screen shots/drill downs required? 6
    Expertise required? Advanced

    ECAT Blocking requires administrator/user to identify modules for blocking. Blocking is only supported on Windows – not MAC’s and they have no support for Linux agents.
    Supported modules for blocking:
    EXE, .COM, .SYS, .DLL, .SCR, .OCX, .JAR, .BAT, .PS1, .VBS, .WSF, .VBE, .PYC, .WSF, .WAR, .VB, .PY, .CLASS /Hmmm…sure looks like file based blocking to me…
    Moreover, AMP enables a very simple way to mitigate this with an OPEN-IOC signature scan, so you can clearly see that we can also address the attack vectors which we are not that good at…now that’s the stuff protection tools should be made of…😃

    • Hi Aaron, Thank you for your message. I understand where you are coming from but I don’t entirely agree on your observations.

      Firstly in this example, RSA NWE did not block this activity but it actually can if you wanted it to. I agree however, on the fact RSA NWE requires a bit more knowledge. And this is exactly the point and main differences I mend to highlight between NGAV & EDR solutions in general. First, NWE is not mend to be an auto blocking solution because it’s main purpose it to provide analysts with as much as visibility to help them understand the root cause and scope of a potential breaches so they can choose and take actions accordingly.

      What’s also incorrect, is that RSA NWE does support MAC & Linux and that OpenIOC scans are only useful if the “known bad” pattern you are looking for matches.

      Additionally, scanning will most likely leave a window in which attackers are able to perform activities undetected and do harm.
      They main aim of this blog was not to attack Cisco AMP but highlight the main difference between NGAV and EDR solutions.

      That said, I do think Cisco AMP and similar solutions are valuable however, one should not expect any signature or sandbox based solution to detect everything. This is why my personal option is that solutions that provide visibility are more valuable, if of course you know what to look for 😉

  3. Hey sdrinkenburg,
    I came across this interesting analysis and wanted to understand a little more. From the screenshot I would assume that the file fsws.exe would’ve been submitted by the AMP for the behavior analysis during the time after which it should’ve been classified as a malware. Wondering why the file events and threatgrid analysis were not checked checked in the AMP case and would like to know after how much time these screenshots were taken.

    I have no experience with RSA, but would want to understand how the score of 175 was assigned, is this based on the file’s behavior on the client machine alone ?

    • Hi Mark,

      Thank you for your message. Fsws.exe is the web file sharing program which is a valid application and was scanned by AMP at installation time. After this, it got exploited using a buffer overflow vulnerability. As a buffer overflow loads code in memory of the running process and does not create or deliver new binary code to disk, AV and Cisco AMP had nothing new to analyze. This is why fsws.exe was not resubmitted to threatgrid for analysis and actually shows the weakness of these kind of solutions.

      This also explains why AV and Cisco AMP did not detect the keylogging, network scanning and password.txt search and download activities as all of these occurred in memory and did not interacted with application or OS processes, dll’s etc.

      Cisco AMP did detect the interactive shell and commands as these made use of the CMD.exe file which is part of the endpoints OS. It did not however, mark these activities as suspicious.

      RSA NWE and probably other EDR tools work completely different. RSA NWE for instance, continuously tracks what is happing at an disk, network and very importantly the memory layer of an endpoint. As this “tracking” data gets directly send to the NWE server, it is instantly capable to detect and track the behavior of both existing and newly downloaded or injected code on disk and memory.

      Due this RSA NWE, was directly able to detect a “good program gone bad” and see the floating code (buffer overflow code injected in memory). As it monitors all activities, it was also able to map its behavior to several IOC’s or suspicious activities and increased the endpoint’s risk and suspicious rating accordingly to 175.

      You might have seen comments stating these attacks can be detected using scans. This however, is partly true as IOC scans many depend on “known bad” information and do not run continuously. Due to this, scans will make it hard to detect the “unknown” and leave a large time window (between scans) for adversaries to perform their activities in.

      I hope this explains what I tried to demonstrate a bit better. It is important to understand though I don’t mean to make Cisco AMP look bad. I do think it is important to show the detection and tracking limitations of these kind of solutions as they are being positioned to provide good protection which in my opinion is not always the case.

      If you have any comments or suggestions please do not hesitate to let me know.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s

%d bloggers liken dit: