Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Authors John Simmons

RSA NetWitness Platform

3 Posts authored by: John Simmons Employee

On a recent engagement, I took a different approach to finding possible malicious files entering the customer's network.  Rather than focusing on the e-mail, I looked for any RAR, macro-enabled office documents, and portable executable files (PE) entering the network where no service was specified.  Of course, this was done using RSA NetWitness and immediately I found a RAR file which contained a malicious executable.  Although, this was a different vector by which it entered the network.  It didn't appear to be a link that someone clicked from an e-mail and it wasn't an attachment from an email either.  It was from a customer configured, cloud based support site.  You can find many customers who use these types of sites.

 

So here's how I believe this was attempted.  A malicious actor goes to the <customer name>.<customer support site>.com site where they open a support ticket for an order they placed. (Of course they probably didn't place an actual order)  Then using the support interface, they upload what appears to be an order list.  In this instance I found the file name was "OrderList_Xlsx.arj" which is a RAR file and inside was a file called "OrderList.exe" all of which was downloaded by the customer support representative using their admin console to the site.

 

It's a simple approach.  It involves the actor opening a support ticket on the customer's site but whether they are actually doing this or using a script/automation is another question.  In this instance, I didn't see it as being targeted towards this customer but maybe they're testing the waters.  Without having access to this customers admin console to this service it's hard to determine whether this is happening more frequently because from our perspective, we only see where the employee downloads the file and enters into the customer's network. 

 

I created a quick and easy search to find this type of activity.

 

alias.host = '<customer name>.<customer support site>.com' && (filetype = 'rar' || filetype = 'windows executable' || ((filetype = 'zip' || filetype contains 'office') && filename contains 'vbaproject.bin') || extension contains 'docm','xlsm','pptm' || content contains 'macro')

A question was posed to our team by one of the engineers; had we seen the new Chrome and Microsoft zero-day exploits using RSA NetWitness Endpoint?  I honestly didn't even know about these exploits and so I had to do some research.  I found the initial Google Blog post here: Google Online Security Blog: Disclosing vulnerabilities to protect users across platforms.  The first vulnerability (NVD - CVE-2019-5786) is the Google Chrome vulnerability and the second was disclosed to Microsoft by Google but as of the time I am writing this, no patch had been released by Microsoft.

 

Other articles and blogs that talk about these zero-days say they are being used in conjunction with each other. There was no proof of concept code nor any exploits I could use from the research I did. I did see some articles talking about these being exploited in the wild but I couldn’t find any other details. The second zero day is a Windows 7 32 bit privilege escalation vulnerability which does a null pointer dereference in win32k.sys. I found a similar privilege escalation exploit for CVE-2014-4113 and successfully exploited a box in my sandbox environment while it had an NetWitness Endpoint agent on it. The two IIOCs that fired that would help detect this attack were:

 

IIOC 1 - “Creates process and creates remote thread on same file”
IIOC 2 - “Unsigned creates remote thread”

 

The remote thread in this case was on notepad.exe which is common of Meterpreter.

 

The exploit I used can be found here: https://www.exploit-db.com/exploits/35101. It also does a null pointer dereference in win32k.sys similar to the Microsoft zero-day.  Below are some screenshots of what I saw from the attacker side and the NetWitness Endpoint side.

 

Here you can see the the exploit being injected in process ID 444.

 

 

Here is the entry in RSA NetWitness Endpoint.

 

 

Another entry is lsass.exe opening notepad.exe after the remote thread creation.  I believe this is the actual privilege escalation taking place.  It also makes sense because the timestamp matches exactly to the timestamp in Kali.

 

 

Here are the IIOCs which I believe are the initial meterpreter session based on timestamps.   It's still an indication of suspicious activity and when combined with lsass.exe opening the same remote thread process, it raises even more alarms.

 

 

I gave this to the engineer in hopes that the new Microsoft zero-day could be detected in the same way and even though we don't know the details of the Google Chrome vulnerability, we do know they are being exploited together.  This could help possibly identify this attack that has been seen in the wild.  Also, on another note, the fact that two zero-days are being exploited in the wild together just screams of a well-funded advanced adversary and it's a relief to know that our tool out-of-the-box should be able to help find this type of activity.

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.

Filter Blog

By date: By tag: