This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject

NetWitness Community

  • Home
  • Products
    • NetWitness Platform
      • Advisories
      • Documentation
        • Platform Documentation
        • Known Issues
        • Security Fixes
        • Hardware Documentation
        • Threat Content
        • Unified Data Model
        • Videos
      • Downloads
      • Integrations
      • Knowledge Base
    • NetWitness Cloud SIEM
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Detect AI
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Investigator
    • NetWitness Orchestrator
      • Advisories
      • Documentation
      • Knowledge Base
      • Legacy NetWitness Orchestrator
        • Advisories
        • Documentation
  • Community
    • Blog
    • Discussions
    • Events
    • Idea Exchange
  • Support
    • Case Portal
      • Create New Case
      • View My Cases
      • View My Team's Cases
    • Community Support
      • Getting Started
      • News & Announcements
      • Community Support Forum
      • Community Support Articles
    • Product Life Cycle
    • Support Information
    • General Security Advisories
  • Training
    • Blog
    • Certification Program
    • Course Catalog
    • New Product Readiness
    • On-Demand Subscriptions
    • Student Resources
    • Upcoming Events
  • Technology Partners
  • Trust Center
Sign InRegister Now
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
NetWitness Community Blog
Subscribe to the official NetWitness Community blog for information about new product features, industry insights, best practices, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
  • NetWitness Community
  • Blog
  • Detecting C2 in RSA NetWitness: BeEF + Octopus

Detecting C2 in RSA NetWitness: BeEF + Octopus

MarcoMeli
Occasional Contributor MarcoMeli Occasional Contributor
Occasional Contributor
Options
  • Subscribe to RSS Feed
  • Mark as New
  • Mark as Read
  • Bookmark
  • Subscribe
  • Email to a Friend
  • Printer Friendly Page
  • Report Inappropriate Content
‎2020-05-13 11:12 AM

Intro

Octopus was presented at Black Hat London 2019 by Askar. The github page is available here. It is a pre-operation C2  for Red Teamers, based on HTTP/S and written in python. This blog post will show the detection of Octopus (over http) with NetWitness Endpoint and Network.

 

Scenario

The attacker sets up an HTTP listener in Octopus and generates an exe payload. He then builds a webpage where he embeds the payload and spreads the webpage through social media and email spam campaigns. The victim opens the webpage from his Windows 10 machine and a pop-up message is immediately shown on the browser stating the current version of Adobe Flash plugin is outdated and needs to be updated to install latest security patches. Thus the victim clicks on the pop-up and installs the update which infects his machine.

 

Part 1 -  Attack phase

Once Octopus is started this is how the attacker creates a listener and generates the payload, in this case an exe payload (hta and powershell payloads are also an option):

 

Octopus1.png

 

More in detail we have:

listen_http listen_ip port hostname interval page listener_name
generate_unmanaged_exe listener_name output_path

The attacker uses the popular ngrok tunneling service as a proxy, that is once the victim machine is infected it will communicate with the address 4dcd8c6d.ngrok.io which will  in turn create a secure tunnel to the attacker box.

 

Next the attacker uses a technique known as browser hooking to embed the exe file into a webpage. To achieve this the attacker used the BeEF framework. Explaining this whole process is out of the scope of this post but if you are interested to know more about it you should have a look at the  Autorun Rule Engine BeEF github page.

 

The victim, using a Windows 10 machine, sees an interesting website about organic food on social medias and clicks on the webpage:

 

ogani.png

 

As shown above once the webpage is loaded a message pops up warning to install a new version of Adobe Flash plugin which included new security updates. Interestingly the message also warns to ignore the missing certificate signature and that it is a known issue which Adobe is working on.

 

ogani4.png

 

The victim then clicks on Install missing Plugins and then on Run ignoring the signature warning as advised. Windows Defender is activated and did not detect the exe file.

 

On the other side of the wall the attacker receives a connection to the listener.

 

Octopus2.png

To interact with the victim the attacker runs the following command:

interact 1

where 1 is number of the session.

 

The attacker also runs some other commands such as "whoami", "quser", and "report". The latter is a command built-in in Octopus which provides some additional information about the victim machine. After a little of browsing within the victim machine folders the attacker also finds a file containing potential sensitive information (TopSecret.txt) and downloads it using Octopus download command.

 

Part 2 - Detection phase with the RSA NetWitness Platform

NetWitness Endpoint

The analyst receives an email alert about a high priority incident generated in the NetWitness Respond module so he starts investigating:

 

INC16.png

networkevent.png

 

The incident is generated by the NetWitness Endpoint incident rule "High Risk Alerts: NetWitness Endpoint".  However, the rule originates from an App Rule which is part of a bundle content pack available in RSA Live. More information about this bundle is available here.

 

The App Rule condition is the following:

device.type = 'nwendpoint' && category = 'network event' && context = 'network.outgoing' && direction = 'outbound' && context != 'network.nonroutable' && context.src = 'file.unsigned' && dir.path.src = 'appdatalocal','appdataroaming'

and it basically alerts if an unsigned file initiated from the Windows AppData/local or AppData/roaming directory has made an outbound network connection. The alert in turn generates an incident since it is marked with High Risk.

 

It is apparent from the incident that the file adobe_flash_update.exe made a connection to 4dcd8c6d.ngrok.io which is the name of the ngrok server the attacker uses to tunnel the connection to his machine. The fact that file is unsigned and makes a connection to a website that is not from Adobe makes things extremely suspicious.

Drilling down into the events with NetWitness Endpoint and analyzing them in details the analysts also notices this:

 

adobeAnalysis.png

 

which clearly shows the adobe_flash_update.exe spawned few other processes among which whoami.exe and quser.exe that are Windows utilities typically used by attackers for enumeration. 

 

NetWitness Network

With the information retrieved from the incident, the analyst investigates further with NetWitness Network filtering by hostname:

 

Service Analysis.png

The analyst notices some potentially malicious HTTP requests under the Service Analysis meta key. While analyzing these meta keys he finds the following event under the "http1.1 without user-agent header" meta value.

 

AES.png

 

The above is the initial communication of the victim machine with the Octopus C2. Note that "home.php" in the GET request is the name the attacker used in the command to setup the listener we saw in the beginning. The response to the request contains a powershell payload that intends to setup the communication with the C2 . We can see an AES key and its Initialization Vector used to encrypt the communication. This structure looks very similar to the Ninja C2, described by my colleague Lee Kirkpatrick in another blog post available here.

 

After the agent/C2 communication has been setup the next request is the "GET /login" where the encrypted communication is established:

 

loginRequest.png

 

each further request is a beacon to the C2 and the analyst notices that the request includes the victim machine name "WINEP1" followed by a 5 characters random name:

 

beaconing.png

 

The below two requests show the command quser launched from the C2 in the previous steps and its response (the response is contained on a separate GET request):

 

quserOutput.png

Note that when the C2 requests something we see "/bills" in the GET request.

 

The below figure shows the decryption of the above strings using the powershell decryption function seen in the very first request (GET /home.php😞

 

Decryption.png

With the same process the analyst was able to see other commands the attacker ran but more importantly was able to see the attacker exfiltrated a file named TopSecret.txt from the infected machine:

 

topsecret.png

 

The beaconing pattern can also be observed with 120 seconds intervals and same size:

 

becaoningInterval.png

 

It is important to note different destination IP addresses in the above figure. This is because ngrok resolves to different IP addresses in round robin.

 

Another interesting thing to note is that the URL parameters we saw in the GET requests can be customized via  the Octopus profile.py file:

 

#!/usr/bin/python3

# this is the web listener profile for Octopus C2
# you can customize your profile to handle a specific URLs to communicate with the agent
# TODO : add the ability to customize the request headers

# handling the file downloading
# Ex : /anything
# Ex : /anything.php
file_receiver_url = "/messages"

# handling the report generation
# Ex : /anything
# Ex : /anything.php
report_url = "/calls"

# command sending to agent (store the command will be executed on a host)
# leave <hostname> as it with the same format
# Ex : /profile/<hostname>
# Ex : /messages/<hostname>
# Ex : /bills/<hostname>
command_send_url = "/view/<hostname>"

# handling the executed command
# Ex : /anything
# Ex : /anything.php
command_receiver_url = "/bills"

# handling the first connection from the agent
# Ex : /anything
# Ex : /anything.php
first_ping_url = "/login"

# will return in every response as Server header
server_response_header = "nginx"

# will return white page that includes HTA script
mshta_url = "/hta"

# auto kill value after n tries
auto_kill = 10‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

 

Lastly, while inspecting the network for C2 traffic the analyst  finds the following:

 

beefBeacon.png

 

These are HTTP beacons. Requests are sent on port 3000 which is the default port the BeEF framework uses.

 

beefBeacon2.png

 

Looking at one of the sessions the analyst sees it contains several requests like the one in the above screenshot. In the Referer field we can see the address of the phishing website used by the attacker and the GET request contains the hook to the BeEF C2. The victim will be hooked to the C2 until he closes the browser. The attacker can leverage the hook to performs social engineering attacks like the fake Adobe Flash update among many others.

 

Observations

A client-side attack vector was used to get initial foothold to the victim machine. Once the victim opened the legitimate-looking webpage his browser was "hooked" to the attacker BeEF C2. The attacker had also set an automatic rule that pushed a fake pop-up message suggesting the victim to install Adobe Flash security updates. Once the victim installed the fake Adobe Flash update the incident was created in NetWitness Respond module because of the App Rule discussed earlier.

Threat actors usually use multiple techniques to distribute their malicious payloads. What would have happened if the user had downloaded the file by a different mean on his machine? The same incident would have probably not been generated in NetWitness because that specific app rule relied on the fact that an unsigned file was started from appdatalocal directory in Windows. However, even without the incident the analysts would have identified suspicious network activity with NetWitness Network such as the beaconing to the C2 and also indicators of compromise and suspicious activities in NetWitness Endpoint . For example, the Behavior of Compromise meta key of NetWitness Endpoint would have shown following values:

 

    queries users logged on local system (1)  related to the whoami command
    gets current username (1)    related to the quser command

 

The same applies if the attacker had set an HTTPS listener instead of the HTTP one. In this case the analysts would not have been able to see the content of the communication between the C2 and the victim (unless there is an interceptor in place) but they would have noticed the beaconing and the indicators of compromise in NetWitness Endpoint.

 

Conclusions

Octopus is quite new but showed similarities to other recent C2 frameworks. It is customizable and modular (external modules can be plugged-in) and can run both on HTTP and HTTPS. This article showed that the NetWitness Suite can be of great use when it comes to C2 detection with the combination of both NetWitness Network and Endpoint by providing a very granular level of visibility. In the case of HTTPS an SSL/TLS interceptor would help providing more visibility but without it NetWitness can still identify C2 patterns and indicators of compromise that will help analysts detect potential malicious activities.

  • beef framework
  • botnet
  • browser hooking
  • c2
  • client-side attack
  • command & control
  • EDR
  • endpoint analysis
  • exfiltration
  • hunting
  • ir
  • NetWitness
  • NetWitness Endpoint
  • netwitness network
  • netwitness.
  • NW
  • NWP
  • RSA NetWitness
  • RSA NetWitness Platform
  • threat analysis
  • threat hunting
  • web hooking
0 Likes
Share
3 Comments

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

  • Comment
Latest Articles
  • Agent Tesla: The Information Stealer
  • Threat Analysis: Detecting “Follina” (CVE-2022-30190) RCE Vulnerability with Netwitness Endpoint
  • Introducing NetWitness Vision XDR
  • Introducing NetWitness Platform XDR v12.0
  • Atlassian Confluence Zero-day Vulnerability (0-Zero) CVE-2022-26134: What You Need To Know
  • ‘Follina’ CVE-2022-30190 0-Day: What You Need To Know
  • CVE-2022-1388: BIG-IP iControl REST RCE Vulnerability
  • Ragnar Locker Ransomware: The Rampage Continues…
  • Ransomware Email Attacks: Beware of BazarLoader
  • Detecting Impacket with Netwitness Endpoint
Labels
  • Announcements 54
  • Events 2
  • Features 9
  • Integrations 6
  • Resources 57
  • Tutorials 21
  • Use Cases 21
  • Videos 116
Powered by Khoros
  • Blog
  • Events
  • Discussions
  • Idea Exchange
  • Knowledge Base
  • Case Portal
  • Community Support
  • Product Life Cycle
  • Support Information
  • About the Community
  • Terms & Conditions
  • Privacy Statement
  • Acceptable Use Policy
  • Employee Login
© 2022 RSA Security LLC or its affiliates. All rights reserved.