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
  • Using RSA NetWitness to Detect Ninja C2

Using RSA NetWitness to Detect Ninja C2

LeeKirkpatrick
Valued Contributor LeeKirkpatrick Valued Contributor
Valued 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-04-09 03:10 AM

A new C2 framework was recently added to the C2 Matrix called, Ninja. It was built on top of the leaked MuddyC3 framework used by an Iranian APT group called, MuddyWater. It can be run on Windows, Linux, macOS, and FreeBSD; the platform is built for speed, is highly malleable and feature rich. As usual, in this blog post will cover the detection of its usage using NetWitness Network and NetWitness Endpoint.

 

The Attack

Ninja creates a variety of payloads for you upon execution. In this instance, we just chose one of the PowerShell payloads and executed it on the victim endpoint:

pastedImage_3.png

 

A few seconds later we see our successful connection back to Ninja whereby a second stage payload is sent along, as well information about the victim endpoint:

pastedImage_4.png

 

We can see the information sent back from one of the initial HTTP POSTs by listing the agents:

pastedImage_2.png

 

Now we can change our focus to the agent, and start to execute commands against the endpoint:

pastedImage_1.png

 

The Detection Using NetWitness Network

Ninja C2 works over HTTP and currently has no direct support for SSL. This is in an attempt to blend in with the large quantities of HTTP traffic typically already present in an environment: the best place to hide a leaf is in the forest.

 

Ninja has a somewhat large amount of anomalies in regard to the HTTP requests it makes to and from the C2, a few of these have been highlighted below:

pastedImage_3.png

NOTE: While plenty of applications (ab)use the HTTP protocol, focusing on charateristics of more mechanical type behaviour can lead to us to sessions that are more worthy of investigation.

 

Another interesting element to Ninja is that for each agent a unique five character ID is generated. All requests from or to that agent are then in the form of, "AgentId-img.jpeg" - so from the below, we can tell that two agents are communicating with Ninja. You'll also notice that the requests it is making are for JPEG images, but none are actually returned. We can tell this as the File Type meta key is populated by a parser looking for the magic bytes of files, and it found no evidence of a JPEG in these sessions:

pastedImage_15.png

 

 

Another interesting artefact from Ninja is that it also returns encrypted commands in GET requests, and the associated encrypted response in POST requests; these can be seen under the Querystring meta key - the initial HTTP POST however, contains information about the system and is sent in the clear delimited by **:

pastedImage_5.png

 

Drilling into the Events view for the Ninja traffic, we can also see a defined beaconing pattern (we set this to two minutes upon setting up Ninja), as well as the fact that the beacons typically all have the same payload size:

pastedImage_17.png

Reconstructing the sessions from the beginning, we can see the initial communication with the Ninja C2, whereby it returns a second stage PowerShell payload:

pastedImage_19.png

 

This payload is somewhat large and is setting up the agent itself, the communication with the C2, encrypt and decrypt functions, as well as dynamically generating the AES key that should be used. Payloads such as this should be studied in-depth as they allow you to better understand the C2's function, and in this case, will allow us to decrypt the communication:

pastedImage_3.png

 

The next two pieces of information directly after the second stage payload are of importance, they contain information regarding the agent ID, details of the infected endpoint, as well as the encryption key that will be used; this is not a static key and is dynamically created for each agent:

pastedImage_5.png

 

Continuing the reconstruction of the sessions, we can see some Base64 encoded data, these are the AES encrypted commands and associated responses from them:

pastedImage_21.png

 

If you remember from earlier, we managed to identify the key that was used to encrypt this data. We also identified the second stage payload that was sent, this payload contained the PowerShell code for the agent which included the encryption and decryption functions for this data. We can simply use this to our advantage and create a simple decoder for this data:

#Ninja AES Key Returned From First HTTP POST to C2
$key = 'VU9XU0VIQUpaSldVU0JET1pXUVRaTVFMRUpZVU1ZUFQ='
#User passed data to decrypt
$enc=$args[0]



function CAM ($key,$IV){
try {$a = New-Object "System.Security.Cryptography.RijndaelManaged"
} catch {$a = New-Object "System.Security.Cryptography.AesCryptoServiceProvider"}
$a.Mode = [System.Security.Cryptography.CipherMode]::CBC
$a.Padding = [System.Security.Cryptography.PaddingMode]::Zeros
$a.BlockSize = 128
$a.KeySize = 256
if ($IV)
{
if ($IV.getType().Name -eq "String")
{$a.IV = [System.Convert]::FromBase64String($IV)}
else
{$a.IV = $IV}
}
if ($key)
{
if ($key.getType().Name -eq "String")
{$a.Key = [System.Convert]::FromBase64String($key)}
else
{$a.Key = $key}
}
$a}


$b = [System.Convert]::FromBase64String($enc)
$IV = $b[0..15]
$a = CAM $key $IV
$d = $a.CreateDecryptor()
$u = $d.TransformFinalBlock($b, 16, $b.Length - 16)
[System.Text.Encoding]::UTF8.GetString($u)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

 

Executing the script and passing it the encrypted Base64 will decrypt the encrypted commands and associated responses allowing us to see what the attacker executed:

pastedImage_2.png

 

Based on Ninja being over HTTP by default, and the initial communication being in the clear, an application rule to pick up on this would look like the following:

(service = 80) && (action = 'post') && (query contains '**')

 

To detect further potential communication to and from Ninja C2 we could use the following application rule logic:

(service = 80) && (filename regex '^[a-z]{5}-img.jpeg') && (filetype != 'jpeg')

 

The Detection Using NetWitness Endpoint

Upon deploying Ninja, NetWitness Endpoint generates four Behaviours of Compromise, runs powershell, runs powershell decoding base64 string, and runs powershell with long arguments:

pastedImage_3.png

 

NetWitness Endpoint also generated meta values for the reconnaissance commands that were executed by the Ninja PowerShell agent:

  • C:\>whoami: gets current username
  • C:\>quser: queries users logged on local system
  • C:\>tasklist: enumerates proceses on local system

 

This is an important point to note, that even if you miss the initial execution, the malicious process will still have to do something in order to achieve its end goal, and as a defender, you only need to pick up on one of those activities to pull the thread back to the beginning.

 

Drilling into the Events view for the meta value, runs powershell decoding base64 string, we can see the Base64 encoded PowerShell command to initiate the connection to Ninja, we can also Base64 decode this within the UI to obtain other information such as the C2 IP:pastedImage_3.png

 

Drilling into the Events view for the other meta values identified, we can see that a FILELESS_SCRIPT, spawned from the initial PowerShell command, is executing the reconnaissance command, tasklist:

pastedImage_5.png

 

 

Conclusion

New C2 frameworks are constantly being developed but all fall prey to the same detection mechanisms. It just comes down to you, as a defender, to triage the data the system presents to you to look for anomalies in processes doing things they shouldn't.

  • c&c
  • c2
  • c2matrix
  • NetWitness
  • ninja
  • ninjac2
  • NW
  • NWP
  • RSA NetWitness
  • RSA NetWitness Platform
2 Likes
Share
8 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
  • Ransomware Email Attacks: Beware of BazarLoader
  • Detecting Impacket with Netwitness Endpoint
  • Exotic Lily: Global Activity Analysis
  • Threat Research Data Hygiene Exercise: Retirement of Threat Research Intelligence Content and Report...
  • Netwitness Orchestrator Dashboarding Overview
  • Highlights from Recent Releases - Here's What's New in NetWitness Platform 11.7 and 11.7.1
  • NetWitness News Bytes: Improved Broker Query Experience
  • NetWitness News Bytes: Meta Only Event Reconstruction
  • NetWitness News - Press Releases
  • Endpoint Bundle Tuning
Labels
  • Announcements 52
  • Events 2
  • Features 9
  • Integrations 6
  • Resources 56
  • Tutorials 21
  • Use Cases 20
  • 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.