Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2019 > February
2019

Attackers are continuously evolving in order to evade detection.  A popular method often utilized is encoding. An attacker may choose to, for example, encode their malicious binaries in order to evade detection; attackers can use a diverse range of techniques to achieve this, but in this post, we are focusing on an example of a hex encoded executable. The executable chosen for this example was not malicious, but a legitimate signed Microsoft binary.

 

This method of evading detection was observed in the wild by the RSA Incident Response team. Due to the close relationship between the Incident Response Team and RSA's Content Team, a request for this content was submitted by IR, and was published to RSA Live yesterday. The following post demonstrates the Incident Response team testing the newly developed content.

 

The Microsoft binary was converted to hexadecimal and uploaded onto Pastebin, which is an example of what attackers are often seen doing:  

 

A simple PowerShell script was written to download and decode the hexadecimal encoded executable and save it to the Temp directory:

 

Typically, the above PowerShell would be Base64 encoded and the IR team would normally see something like the below:

 

After executing the PowerShell script. It is possible to see the dllhost.exe was successfully decoded and saved into Temp directory:

 

Upon perusing the packet metadata, the analyst would be able to easily spot the download of this hex encoded executable by looking under the Indicator of Compromise key:

 

Conclusion

It is important to always keep the RSA NetWitness platform up to date with the latest content. RSA Live allows analysts to subscribe to content, as well as receive updates on when newly developed content is available. For more information on setting up RSA Live, please see: Live: Create Live Account 

I've come across ICMP tunneling only a handful of times, but this was the first time I had seen it used as part of a VPN client.  The VPN client was SoftEther VPN and, in addition to SSL VPN, it can also perform ICMP and DNS tunneling.  During a recent hunting engagement, I had the opportunity to identify and create content to detect this activity.

 

Let's have a look.

 

 

I drilled into ICMP traffic (ip.proto = 1) and then looked at Session Characteristics (analysis.session).  This led me to the meta 'icmp large session'.  Previously, I had created meta to describe when sessions had 'session.split' meta.  Session.split occurs when a session is either very large or very long.  You can find more about session.split in a previous post I wrote here.  However, one simple way to identify when session.split exists, is to simply write an application rule.  

 

 

As we look at the sessions associated with this activity, we see the following:

 

 

The data called out above is around the transmitted (requestpayload) and received (responsepayload) as well as the payload size and overall size of the session.  If you've ever looked at ICMP traffic before, its typically small.  This is not small.

 

Furthermore, this does not look like typical ICMP traffic as shown below:

 

 

With RSA Netwitness Packets, we have an opportunity to describe our network traffic pretty effectively.  When I saw this traffic, I wanted to improve some of the meta I had to describe the size.  The one below will let me know if a session is greater than 1mb.

 

 

Now, circling back to the ICMP tunneling, we can do this with another application rule.

 

 

By taking these steps, I am now better equipped at identifying ICMP tunneling when I observe it.

 

App Rules
name="session split" rule="session.split exists" alert=analysis.session type=application
name="session size greater than 1mb" rule="streams=2 && size=1024000 -u" alert=analysis.session type=application
name=possible_icmp_tunneling rule="ip.proto=1 && session.split exists && analysis.session = 'icmp large session' && analysis.session = 'session size greater than 1mb'" alert=ioc type=application

 

Note that 'session split' and 'session size greater than 1mb' should be before the 'possible_icmp_tunneling' rule.  Order is important.

 

I'll try to get some DNS tunneling created with this SoftEther VPN client soon.

 

Good luck and happy hunting.

These are a collection of ESA rules that create persisted in-memory tables for various different scenarios.  Hopefully they are useful as well as serve as templates for future ideas.

 

GitHub - epartington/rsa_nw_esa_whatsnew: collection of ESA rules for whats new stuff 

 

  • New JA3 hash
  • New SSH user agent
  • New useragent
  • New src MAC family
  • New certificate CA
  • New certificate CA (Endpoint)

 

These are advanced ESA rules so it will require copying and pasting the text into the rules.

 

These can also be tuned to learn more (longer learning window) so that more data is added to the known window of the ESA rule.  Just be careful about potential performance issues if you make the window too long for your environment.

 

Recently, a question came from a customer who wanted to know if it was possible to alert when a new device.ip started logging to RSA NetWitness.  Thinking about it for a second it seemed like a good test of a new template that I was testing for ESA.

 

The rule, located here, does just that:

GitHub - epartington/rsa_nw_esa_whatsnewdeviceip: ESA rule to indicate when a new device type is seen 

 

Add this rule in ESA in the advanced editor to create the rule.

 

It works as follows:

A window of a learning phase is created with the timer in the rule (1 day default)

In that learning window new device.ip + device.type are added to the window to create a known list of devices.

Once the learning window has expired the system alerts on any new combinations of device.ip and device.type that is seen after that.

 

Customizations that you possibly want to make would include changing the learning window timer from 1 day to longer (5 days potentially)

 

The data is kept in a named window and persisted to a JSON file on the ESA disk system in case there are restarts or service changes.

 

Alerts are created in ESA/Respond that can then be assigned work to validate that the new system was on-boarded properly and configured appropriately before closing.

 

During a recent customer engagement, I found the "customtcp shell" meta with some very interesting sessions.  All of the traffic was using what appeared to be custom encryption and the destination IP was based in Korea.  Of course, I knew this couldn't be the first time someone had come across traffic like this so I looked at previous reporting for similar traffic.  Multiple analysts, like myself, had seen traffic exactly like this and their analysis led them in different directions.  Some even believed that this was NanoCore RAT traffic as it had similar attributes but I was still skeptical.  After hours of researching this traffic and trying to dissect this traffic I came across someone's master's thesis talking about end-to-end encrypted mobile messaging apps.  The link to the thesis is below.

 

https://www.diva-portal.org/smash/get/diva2:1046438/FULLTEXT01.pdf 

 

The traffic I was seeing matched perfectly with the handshake packet used with the propriety protocol called LOCO, which is used by the mobile messaging app KakaoTalk.  The article broke it down very well and without it I think I would still be scratching my head at this traffic.  So lets go back to what this traffic looks like and how I was able to determine it was KakaoTalk.

 

Here is an example of the customtcp shell meta being populated in a customer's environment.  This over a 5 day time period so it's not very common in most customer's environments.

 

 

As of today, I have seen this type of traffic in four customer environments within the RSA NetWitness Platform. Further, fellow colleagues and team members have also inquired about this type of traffic.  To recreate this traffic and avoid showing customer data, I downloaded the KakaoTalk mobile app on my personal iPhone.  Here is an example of the what the handshake packet looks like.

 

 

With the help of Stephen Brzozowski during the first engagement, we were able to dissect this packet to some extent.  The first 12 bytes of the sessions are the custom headers and always repeat during the first session.

 

 

The response and any follow-on packets would begin with the size in little-endian format.

 

 

With the help of the article mentioned above, I was able to match this traffic to the LOCO protocol's initial handshake packet.

 

 

As well as the follow-on packets that matched the LOCO encrypted packet.

 

Considering that every instance of the handshake packet I have seen in multiple environments always begin with the same first 12 bytes, I wrote a quick parser to find this traffic.  It's attached below.  I have deployed it on two customer environments and left it running for almost 24 hours with no false positives and approximately 20 sessions discovered in each environment.  Currently, it only detects the initial handshake, but I intend to modify it later to detect all sessions with the same high fidelity.  In addition, I have seen one other instance where the first 12 bytes didn't match because of one bit being off but I still believe it was KakaoTalk.

 

While deploying this parser and testing in these environments, I also discovered similar traffic that used other custom headers which I believe is another type of mobile messaging app that uses end-to-end encryption.  I believe we will continue to see additional mobile apps that populate this meta key in the future.  While documentation for these apps and custom protocols are scarce, I believe that it will present a challenge for analysts to distinguish between malicious custom TCP shells and benign traffic such as discussed in this blog.

This blog post is a follow on from the following two blog posts:

 

 

 

The Attack

The attacker is not happy with executing commands via the Web Shell, so she decides to upload a new Web Shell called, reGeorg (https://sensepost.com/discover/tools/reGeorg/). This Web Shell allows the attacker to tunnel other protocols over HTTP, therefore allowing the attacker to RDP for example, directly onto the Web Server, even though RDP isn’t directly allowed from the internet.

 

The attacker can upload the Web Shell via one of the previously utilized Web Shells:

 

The attacker can now check the upload was successful by navigating to the uploaded JSP page. If all is okay, the Web Shell return the message shown in the below screenshot:

 

The attacker can now connect to the reGeorg Web Shell:

 

This means the attacker now has remote access to anything accessible from the Web Server where the Web Shell is located. This means the attacker could choose to RDP to a previously identified machine for example:

 

Attackers also like to keep other access methods to endpoints, one way of doing this is to setup an accessibility backdoor. This involves the attacker altering a registry key to load CMD when another application executes, in this case sethc.exe – this is an accessibility feature you typically see when pressing the SHIFT key five times. This now means that anyone who can RDP to that machine, can receive a system level command prompt with no credentials required; this is because sethc.exe can be invoked at the login screen by pressing the SHIFT key five times, and with the registry key altered, will spawn CMD as well.

 

To set this up, the attacker can use the Web Shell, and perform this over WMI using REG ADD:

 

Now the attacker can RDP back to the host they just setup the accessibility backdoor on, press the SHIFT key five times to initiate sethc.exe, and will be given the command prompt as system without having to use credentials:

 

 

The Analysis in RSA NetWitness

The analyst, while perusing Behaviors of Compromise, observes some suspicious indicators, runs wmi command-line tool, creates remote process using wmi command-line tool, and http daemon runs command shell just to name a few:

 

Drilling into the WMI related metadata, it is possible to see the WMI lateral movement that was used to setup the accessibility backdoor from the Web Shell:

 

The analyst also observes some interesting hits under the Indicators of Compromise meta key, enables login bypass and configures image hijacking:

 

Drilling into these sessions, we can see it is related to the WMI lateral movement performed, but this event being from the endpoint the backdoor was setup on:

 

The analyst, further perusing the metadata, drills into the Behavior of Compromise metadata, gets current username, and can see the sticky key backdoor being used (represented by the sethc.exe 211) to execute whoami:

 

The analyst, also perusing HTTP network traffic, observed HTTP headers that they typically do not see, x-cmd, x-target, and x-port:

 

Drilling into the RAW sessions for these suspicious headers, it is possible to see the command sent to the Web Shell to initiate the RDP connection:

 

Further perusing the HTTP traffic toward tunnel.jsp, we can see the RDP traffic being tunnelled over HTTP requests. The reason this shows as HTTP and not RDP, is that the RDP traffic is being tunnelled over HTTP, there are therefore more characteristics which define this as HTTP, compared to RDP:

 

Conclusion

Attackers will leverage a diverse range of tools and techniques to ensure they keep access to the environment they are interested in. The tools and techniques used here are freely available online and are often seen utilized by advanced attackers; performing proactive threat hunting will ensure that these types of events do not go unnoticed within your environment.

Joshua Randall had a recent post that showed how to use the resourceBundle package to create a custom package for content deployment.

Leveraging RSA Live to Deploy Custom Parsers in Large Environments 

 

I took the idea from Josh and took it a step further to create a script that lays down the structure of the resourceBundle for you, then provides a second script to zip up the appropriate content to create your resource bundle.  This should remove the need to hand edit the xml files to create the proper linkages.

 

The script is hosted here:

GitHub - epartington/rsa_nw_script_resourcebundle: Script to create a resource bundle for netwitness content 

 

Run the script from the site above in the folder where you want the bundle created

follow the README.MD to add supported content to the right folder structure created.

Content is placed in the version folder
-------------------
##Currently working in this script:
APPLICATION RULES
LUAPARSERS
-------------------
Not working/Not implemented
All other folders


### APPLICATION RULES
--------------------
require clear text nwr files to be placed in the version folder
if there is more than 1 line per .nwr file then it will split the file into multiples (one line per file) and rename the original file to .multiline
### LUAPARSERS
--------------------
requires lua parser in the version folder
the script will zip the lua file up

 

run the resourceBundleZipper.py script to create the XML and zip file for upload via the RSA NW UI > Configure > Deploy package.

 

Now you are able to upload content in one file, to many locations in the NW environment saving you time.

 

 

 

 

Following up from the previous blog, Web Shells and RSA NetWitness, the attacker has since moved laterally. Using one of the previously uploaded Web Shells, the attacker confirms permissions by running, whoami, and checks the running processes using, tasklist. Attackers, like most individuals, are creatures of habit:

 

The attacker also executes a quser command to see if any users are currently logged in, and notices that an RDP session is currently active:

 

The attacker executes a netstat command to see where the RDP session has been initiated from and finds the associated connection:

 

The attacker pivots into his Kali Linux machine and sets up a DNS Shell. This DNS Shell will allow the attacker to setup C&C on the new machine she has just discovered:

 

The attacker moves laterally using WMI, and executes the encoded PowerShell command to setup the DNS C&C:

 

The DNS Shell is now setup and the attacker can begin to execute commands, such as whoami, on the new machine though the DNS Shell:

 

Subsequently, as the attacker likes to do, she also runs a tasklist through the DNS Shell:

 

Finally, the attacker confirms if the host has internet access by pinging, www.google.com:

 

As the attacker has confirmed internet access, she decides to the download Mimikatz using a PowerShell command:

 

The attacker then performs a dir command to check if Mimikatz was successfully downloaded:

 

From here, the attacker can dump credentials from this machine, and continue to move laterally around the organisation, as well as pull down new tools to achieve their task(s). The attacker has also setup a failover (DNS Shell) in case the Web Shells are discovered and subsequently removed.

 

 

 

Analysis

Since the previous post, the analyst has upgraded their system to NetWitness 11.3, and deployed the new agents to their endpoints. The tracking data now appears in the NetWitness UI, and subsequently the analysis will solely take place, on the 11.3 UI.

 

Tracking Data

The analyst, upon perusing the metadata, uncovers some reconnaissance commands being executed, whoami.exe and tasklist.exe on two of their endpoints:

 

Refocusing their investigation on those two endpoints, and exposing the Behaviours of Compromise (BOC) meta key, the analysts uncovers some suspect indicators that relate to a potential compromise, creates remote process using wmi command-line tool, http daemon runs command shell, runs powershell using encoded command, just to name a few:

 

Pivoting into the sessions related to, creates remote process using wmi command-line tool, the analyst observes the Tomcat Web Server performing WMI lateral movement on a remote machine:

 

The new 11.3 version stores the entire Encoded PowerShell command and performs no truncation:

 

This allows the analyst to perform Base64 decoding directly within the UI using the new Base64 decode function (NOTE: the squares in between each character are due to double byte encoding and not a byproduct of NetWitness decoding):

  

 

Navigating back to the metadata view, the analyst opens the Indicators of Compromise (IOC) meta key, and observed the metadata, drops credential dumping library:

 

Pivoting into those sessions, the analyst see’s that Mimikatz was dropped onto the machine that was previously involved in WMI the lateral movement:

 

Packet Data

The analyst also is looking into the packet data, they are searching through DNS as they had seen an increase in the amount of traffic that they typically see. Upon opening the SLD (Second Level Domain) meta key, the culprit of the increase is shown:

 

Focusing the search on the offending SLD, and expanding the Hostname Alias Record (alias.host) meta key, the analyst observed a large number of suspicious unique FQDN’s:

 

This is indicative behaviour of a DNS tunnel. Focusing on the DNS Response Text meta key, it is also possible to see the commands that were being executed:

 

We can further substantiate that this is a DNS Tunnel by using a tool such as CyberChef, and taking the characters after cmd in the FQDN, and hex decoding them, this reveals that data is being sent hex encoded as part of the FQDN itself, and sent as chunks, and reconstructed on the attacker side, due to the constriction on how much data can be sent via DNS:

 

 

ESA Rule

DNS based C&C is noisy, this is because there is only a finite amount of information that can be sent with each DNS packet. Therefore returning information from the infected endpoint requires a large amount of DNS traffic. Subsequently, the DNS requests that are made, need to be unique, so as not to be resolved by the local DNS cache or internal DNS servers. Due to this high level of noise from the DNS C&C communication, and the variance in the FQDN, it is possible to create an ESA rule that looks for DNS C&C with a high rate of fidelity.

The ESA rule attached to this blog post calculates a ratio of how many unique alias host values there are toward a single Second Level Domain (SLD). Whereby we count the number of sessions toward the SLD, and divide that by the number of unique alias hosts for that SLD, to give us a ratio:

 

  • SLD Session Count ÷ Unique Alias Host Count = ratio

 

The lower the ratio, the more likely this is to be a DNS tunnel; due to the high connection count, and variance in the FQDN to a single SLD. The below screenshot shows the output of this rule which triggered on the SLD which was shown in the analysis section of this blog post:

 

 

NOTE: Legitimate products perform DNS tunnelling, such as McAfee, ESET, TrendMicro, etc. These domains would need to be filtered out based on what you observe in your environment. The filtering option for domains is at the top of the ESA rule.

 

The rule for import and pure EPL code in a text file are attached to this blog. 

IMPORTANT: SLD needs to be set as an array for the to rule to work.

 

 

Conclusion

This blog post was to further demonstrate the TTP’s (Tools, Techniques, and Procedures) attackers may utilise in a compromise to achieve their end goal(s). It demonstrates the necessity for proactive threat hunting, as well as the necessity for both Packet and Endpoint visibility to succeed in said hunting. It also demonstrates that certain aspects of hunting can be automated, but only after fully understanding the attack itself; this is not to say that all threat hunting can be automated, a human element is always needed to confirm whether something is definitely malicious or not, but it can be used to minimise some of the work the analyst needs to do.

This blog also focused on the new 11.3 UI. This allows analysts to easily switch between packet data and endpoint data in a single pane of glass; increasing efficiency and detection capabilities of the analysts and the platform itself.

A couple of interactions with customers recently sent me down the path of designing better whitelisting options around well known services that generate a lot of benign traffic.  A lot of customers have gone down the path of Office365, Windows 10 and Chrome/Firefox as standard software in the Enterprise.  As a result, the traffic that NetWitness captures would include a lot of data for these services so enabling the ability to filter this data when needed is important.

 

The Parsers

The end result of this effort is 3 parsers that allow the filtering of Office365 traffic, Windows 10 Endpoint/Telemetry and Generic filtering (Chrome/ Firefox etc.) in the NetWitness plaform.

 

The data for filtering (metvalues) is written by default in the Filter key and looks like this

 

With these metavalues, analysts are able to select and deselect meta for these services to reduce the benign signals for these services from investigations and charting to focus more on the outliers.

filter!='whitelist'

filters all data tagged as whitelist from the view

 

filter!='windows10_connection'

filters all traffic that is related to windows 10 Connection endpoints (telemetry etc.) captured from these sites

windows-itpro-docs/windows/privacy at master · MicrosoftDocs/windows-itpro-docs · GitHub 

 

filter !='office365'

filters traffic from this endpoint related to all Office365 endpoints

Office 365 IP Address and URL Web service | Microsoft Docs 

 

filter !='generic'

filters traffic related to generic endpoints including Chome updates from gvt1.com and gtvt2.com as well as other misc endpoints related to windows telemetry (V8/V7 etc and others)

 

Automating the Parsers

To take this one step further, to make the process of creating the lua parsers easier a script was written for Office365 and Window10 to automate the process of pulling the content down, altering the data, creating a parser with the content and outputting the parser ready to be used on log and packet decoders to flag traffic.

 

Hopefully this can be rolled into a regular content pipeline to update the parsers periodically to get the latest endpoints as they are added (for instance when a new Windows 10 build comes out there will be an update to the endpoints most likely).

 

Scripts, lua parsers and descriptions are listed here and will get updated as issues pop up.

 

For each parser that has an update mechanism the python script can be run to generate the data that outputs a new parser for use in NetWitness (and the parser version is updated to the time the parser is built to let you know in the UI what the version is).

These parsers also serve as proof of concepts for other ideas that might need both exact and substring matches for say hostnames, or other threat data.

 

Currently the parsers read from hostname related keys such as alias.host, fqdn, host.src, host.dst.

 

As always, this is POC code to validate ideas and potential solutions. Deploy code and test/watch for side effects such as blizzards, sandstorms, core dumps and other natural events.

 

GitHub - epartington/rsa_nw_lua_wl_O365: whitelist office365 traffic parser and script 

GitHub - epartington/rsa_nw_lua_wl_windows10: whitelist window 10 connection traffic parser and script 

GitHub - epartington/rsa_nw_lua_wl_generic: whitelist generic traffic parser 

 

There will also be a post shortly about using resourceBundles to generate a single zip file with this content to make uploading and management of this data easier.

Introduction

This blog post demonstrates a common method as to how organisations can get compromised. Initially, the viewpoint will be from the attacker’s perspective, it will then move on to show what artifacts are left over within the RSA NetWitness Packets and RSA NetWitness Endpoint solutions that analysts could use to detect this type of activity.

 

Scenario

Apache Tomcat server exposed to the internet with weak credentials to the Tomcat Manager App gets exploited by an attacker. The attacker uploads three Web Shells, confirms access to all of them and then uploads Mimikatz to dump credentials.

 

Definitions

Web Shells

A web shell is a script that can be uploaded to a web server to enable remote administration of the machine. Infected web servers can be either internet-facing or internal to the network, where the web shell is used to pivot further to internal hosts.

A web shell can be written in any language that the target web server supports. The most commonly observed web shells are written in languages that are widely supported, such as JSP, PHP, ASP, Perl, Ruby, Python, and Unix shell scripts are also used.

 

Mimikatz

Mimikatz is an open source credential dumping program that is used to obtain account login and password information, normally in the form of a hash or a clear text password from an operating system.

 

THC Hydra

When you need to brute force crack a remote authentication service, Hydra is often the tool of choice. It can perform rapid dictionary attacks against more than 50 protocols, including telnet, ftp, http, https, smb, several databases, and much more.

 

WAR File

In software engineering, a WAR file (Web Application Resource[1] or Web application Archive[2]) is a file used to distribute a collection of JAR-files, JavaServer Pages, Java Servlets, Java classes, XML files, tag libraries, static web pages (HTML and related files) and other resources that together constitute a web application.


 

The Attack

The attacker finds an exposed Apache Tomcat Server for the organisation. This can be achieved in many ways, such as a simple Google search to show default configured Apache Servers:

                                      

The attacker browses to the associated Apache Tomcat server and see’s it is running up to date software and appears to be mainly left at default configuration:

                 

 

The attacker attempts to access the Manager App, the manager app requires a username and password and therefore the attacker cannot login to make changes. Typically, these servers are setup with weak credentials:

               

 

Based off of this assumption, the attacker uses an application called THC Hydra to brute force the Tomcat Manager App using a list of passwords. After a short while, Hydra returns a successful set of credentials:

                


The attacker can now login to the Manager App using the brute forced credentials:

               

 

From here, the attacker can upload a WAR (Web application ARchive) file which contains their Web Shells:

                

 

The WAR file is nothing more than just a ZIP file with the JSP Web Shells inside. In this case, three Web Shells were uploaded:

                  

 

After the upload, it is possible to see the new application called, admin (which is based off the WAR file name, admin.war), has been created:

              


The attacker has now successfully uploaded three Web Shells on to the server and can begin to use them. One of the Web Shells named, resetpassword.jsp, requires authentication to help protect direct access by other individuals; this page could also be adapted to confuse analysts when visited:

            

 

The attacker enters the password, and can begin browsing the web servers file system and executing commands, typical commands such as, whoami, are often used by attackers:

           

 

The attacker may also choose to see what processes are running to see if there are any applications that could hinder their progression by running, tasklist: 

           

 

From the previous command, the attacker notices a lack of Anti-Virus so decides to upload Mimikatz via the WebShell: 

          

 

The ZIP file has now been uploaded. This Web Shell also has an UnPack feature to decompress the ZIP file: 

         

 

Now the ZIP file is decompressed:

         

 

The attacker can now use the Shell OnLine functionality within this Web Shell which emulates CMD in order to navigate to the Mimi directory and see their uploaded tools: 

         

 

The attacker can then execute Mimikatz to dump all passwords in memory:

        

 

The attacker now has credentials from the Web Server:

         

 

The attacker could then use these credentials to laterally move onto other machines.

 

The attacker also dropped two other Web Shells, potentially as backups in case some get flagged. Let’s access those to see what they look like. This Web Shell is the JSP file called, error2.jsp, it has similar characteristics to the resetpassword.jsp Web Shell:

       

 

We can browse the file system and execute commands:

        

 

The final Web Shell uploaded, login.jsp, exhibits odd behavior when accessed:

       

 

It appears to perform a redirect to a default Tomcat Page named, examples, this appears to be a trick to confuse anyone who potentially browses to that JSP page. Examining the code for this Web Shell, it is possible to see it performs a redirect if the correct password is not supplied:

     

           <SNIP>

     

 

Passing the password to this Web Shell as a parameter, which is defined at the top of this Web Shell’s code, we get the default response from the Web Shell:

    

 

Further analyzing the code, you can understand further parameters to pass in order to make the Web Shell perform certain actions, such as a directory listing:

   

 

This Web Shell is known as Cknife, and interacting it in this way is not efficient or easy, so Cknife comes with a Java based client in order to control the Web Shell. We can launch this using the command shown below:

  

 

The client is then displayed which would typically be used:

  

Note:  This web shell is listed in this blog post as it is something the RSA Incident Response team consistently sees in some of the more advanced attacks.

 

The Analysis

Understanding the attack is important, and hence why it comes prior to the analysis section. Understanding how an attacker may operate, and the steps they may take to compromise a Web Server, will significantly increase your ability to detect these types of threats, as well as better understand the viewpoint of the analysis while triage is performed.

 

RSA NetWitness Packets

While perusing the network traffic, a large number of 401 authentication errors towards one the Web Servers was observed; there is also a large variety of what look like randomly generated passwords:

        

 

Focusing on the 401 errors, and browsing other metadata available, we can see the authentication errors are toward the Manager App of Tomcat over port 8080, also take note of the Client Application being used, this is the default from THC Hydra and has not been altered:

       

 

Removing the 401 errors, and opening the Filename and Directory meta keys, we can see the Web Shells that were being accessed and the tools that were uploaded:

       

 

NOTE: In an actual environment, a large number of directories and filenames would exist, it is up to the analyst to search for the filenames of interest that sound out of the norm or are in suspicious directories, are newly being accessed, and not accessed as frequently as other pages on the web server. For a more in-depth explanation to hunting using NetWitness Packets, take a look at the hunting guide available here: https://community.rsa.com/docs/DOC-79618

 

The analyst could also use other meta keys to look for suspicious/odd behavior. Inbound HTTP traffic with windows cli admin commands would be worth investigating, as well as sessions with only POST’s for POST based Web Shell’s, http post no get or http post no get no referer, for a couple of examples:

     

 

Investigating the sessions with windows cli admin commands yields the following two sessions, you’ll notice one of the sessions is one of the Web Shells, resetpassword.jsp

    

 

Double clicking on the session will reconstruct the packets and display the session in Best Reconstruction view, in this case, web. Here we can see the Web Shell as the browser would have rendered it, this instantly should stand out as something suspicious:

    

 

This HTTP session also contains the error2.jsp Web Shell, from the RSA NetWitness rendering, it is possible to see the returned results that the attacker saw. Again, this should stand out as suspicious:

    

 

Coming back to the investigate view, and this time drilling into the sessions for post no get no referer, we can see one of the other Web Shells, login.jsp:

   

 

Double clicking on one of these sessions shows the results from the Cknife Web Shell, login.jsp:

    

 

As this was not a nicely formatted web based Web Shell, the output is not as attractive, but this still stands out as suspicious traffic: why would a JSP page on a Web Server return a tasklist?

 

Sometimes changing the view can also help to see additional data. Changing the reconstruction to text view shows the HTTP POST sent, this is where you can see the tasklist being executed and the associated response:

   

 

Further perusing the network traffic, it is also possible to see that Mimikatz was executed:

  

This is an example of what the traffic may look like in RSA NetWitness Packets. The analyst would only need to pick up on one of these sessions to know their organization has been compromised. Pro-active threat hunting and looking for anomalies in traffic toward your web servers will significantly reduce the attacker dwell time.

 

The activity observed was only possible due to the communication happening over HTTP. If this had been SSL, the detection via packets would be much more difficult. This is why introducing SSL Decryption/Interception/Offloading is highly recommended. SSL inspection devices are nothing more than a well-designed man-in-the-middle attack that breaks the encryption into two separate encrypted streams. Therefore, they still provide an adequate level of protection to end-users while allowing security analysts and devices to properly monitor and alert when malicious or unwanted activity takes place, such as the web shells shown here. In summary, if you are responsible for protecting your organization’s assets, you should definitely consider the pros and cons of using this technology.

 

 

RSA NetWitness Endpoint

On a daily basis, analysts should be perusing the IIOC’s within NWE, paying particular attention to the Level 1 IIOC’s. Upon logging into NWE, we can see an interesting Level 1 IIOC has hit, HTTP Daemon Runs Command Shell. This IIOC is looking for a HTTP Daemon, such as Tomcat, spawning cmd.exe:

 

      

 

If we double click on the machine name in the Machines window, we can then navigate to the tracking data for this machine to see what actually happened. Here we can see that Tomcat9.exe is spawning cmd.exe and running commands such as whoami and tasklist, this is not normal functionality and should raise concern for the analyst. We can also see the Mimikatz execution and the associated command executed for that:

 

    

 

Another IIOC that would have led us to this behavior is, HTTP Daemon Creates Executable:

 

   

 

Again, coming back into the tracking data, we can see the Tomcat9.exe web daemon writing files. This would be note-worthy and something that should be investigated further, as web daemons can perform this activity normally. In this instance, the presence of Mimikatz is enough for us to determine this would be malicious activity:

  

 

The analyst also has the capability to request files from the endpoint currently under analysis by right-clicking on the machine name, selecting Forensics and then Request File(s):

 

The analyst can specify the files they want to collect for their analysis (NOTE: wildcards can be used for the filenames but not directories). In this case, the analyst wants to look into the Tomcat Access files, and requests that five of them be returned:

 

Once the files have been downloaded, the analyst can save them locally by navigating to the Download tab, right-clicking the files of interest and selecting Save Local Copy:

 

Perusing the access files, the analyst can also see a large number of 401 authentication errors to the Tomcat Web Server which would have been from the THC Hydra brute force:

 

And also evidence of the Web Shells themselves. Some of the commands the attacker executed can be seen in the GET requests, the data in the body of the POST's however, does not show in the log file, showing why it is important to have both Packets and Endpoint visibility to understand the interaction with the Web Shell:

 

Conclusion

Understanding the potential areas of compromise within your organisation vastly increases your chances of early detection. This post was designed to show one of those potential areas of importance for attackers, and how they may go about a compromise, while also showing how that attack may look as captured by the RSA NetWitness Platform. It is also important to understand the benefits behind proactively monitoring the RSA NetWitness products for malicious activity, simply awaiting for an alert is not enough to capture attacks in their early stages.

 

It is also important to for defenders to understand how these types of attacks look within their own environment, allowing them to better understand, and subsequently protect against them.

 

This is something our RSA Incident Response practice does on a daily basis.  If your organization needs help or your interested to learn more, please contact your account manager.  

 

As always, happy hunting!  

RSA CHARGE 2019 CALL FOR SPEAKERS OPEN FOR SUBMISSIONS

It's official - time to get your creative juices flowing as the RSA Charge 2019 'Call for Speakers' (C4S) is now open and awaiting your submissions!

 

As you are aware, the RSA Charge events represent all RSA products and an increasing number of customers across solutions attend this one-of-a-kind event each year. The RSA 2019 Charge promises to be the biggest event in our history of RSA Charge and RSA Summit conferences. 

 

The RSA Charge event is successful in no small part because of the stellar customer submissions we receive each year. We invite you to submit your presentation brief(s) for consideration. (That's right, you may submit more than one submission brief!)

 

This year for the first time the '8' Tracks for RSA Charge 2019 are identical across all products and represent all RSA solutions. We are pleased to present them to you:

 

Transforming Your Cyber Risk Strategy - Cyber-attacks are at the top of the list of risks for many companies today.  Tell us how you are approaching reducing this risk utilizing RSA products.

 

Beyond the Checkbox: Modernizing Your Compliance Program - The regulatory landscape is always shifting.  How are you keeping up and what steps are you taking towards a sustainable, agile compliance program?

 

Aligning Third Party Risk for the Digital Transformation - Inherited risk from your business partners is a top of mind issue.  Third party risk must be attacked from multiple angles.  Share your strategy.

 

Managing Operational Risk for Impact - Enterprise risk, operational risk, all things risk management.  Share your experience and strategy on how you identify, assess and treat risk across your business operations.

 

View from Above: Securing the Cloud - From security visibility to managing organizational mandates, what is your risk and security strategy to answer the "go to cloud" call.

 

Under the RSA Hood: Managing Risk in the Dynamic Workforce - The workforce has become a dynamic variable for many organizations - from remote users to BYOD to contractors and seasonal workers.  How are you addressing this shift?

 

Business Resiliency for the 'Always On' Enterprise - The world expects connectivity.  When the lights are off, the business suffers.  Tell us how you are ensuring your business is 'always on' - business continuity, recovery, crisis management and the resilient infrastructure.

 

Performance Optimization: RSA Product Learning Lab - Share your technical insights of how you use RSA products to meet your business objectives.  Extra points for cool 'insider' tips and tricks.

 

We know you have great stories to share with your peers, best practices, teachings, and how-to's. We hope you consider submitting a brief and thank you in advance for your consideration. More information can be found on the RSA Charge 2019 website (scroll to bottom of page) including the RSA Charge 2019 Call for Speakers Submission Form. Submission should be sent to: rsa.events@rsa.com.

 

Call for Speakers 'closes' April 26. 

 

Filter Blog

By date: By tag: