Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Authors SeffyGHops

RSA NetWitness Platform

7 Posts authored by: SeffyGHops Employee

NOTE: This post was written by Jared Myers of the RSA Incident Response Team. It original appeared on RSA's Speaking of Security blog site: https://blogs.rsa.com/wolves-among-us-abusing-trusted-providers-malware-operations/

 

112926

 

Within the past year the RSA Incident Response (IR) team has worked multiple APT engagements where they’ve identified the adversary’s malware using a unique method of determining its Command and Control (C2) server. By leveraging trusted content providers, such as popular shopping sites and discussion forums, adversaries can perform operations within a network in plain sight. By replacing a hard-coded beacon address within malware with a simple user name, binaries can transmit a basic lookup for activity made by fake accounts on public discussion forums that contain dynamic IP addresses for communications.

 

As an example, RSA IR discovered use of malware known as PNGRAT during a recent response effort.  PNGRAT, which has since been publicly documented as ZoxPNG, is a substantially equipped trojan with the ability to manage files, enumerate and control processes, and execute commands.  In this particular variant, there were additional features that allowed the malware to collect stored HTTP credentials from the registry of the compromised system, as well as monitor for RDP connections.  More importantly, these samples of PNGRAT did not contain a hardcoded IP address or domain for C2 communications.

 

RSA has noted many adversaries who use public services for C2 architecture in order to prevent detection. However, the method in which the C2 IP address is acquired from these samples is considered unique.  In this PNGRAT variant, the malware used the method of retrieving its download instructions from Microsoft’s Technet website. By connecting to Technet and retrieving the user profile for a hardcoded user account, PNGRAT retrieved an IP address for further C2 connections.  This IP address is stored and encoded within the user profile.  Though encoded, the address did have a particular header and footer that made it obvious to those who knew to look for it:

@MICR0S0FTabcdabcdC0RP0RATI0N

 

These C2 messages were made into legitimate discussions on the Microsoft Technet forums, such as shown in the figure below.  In the example highlighted in the red box, the decoded IP Address is 127.0.0.1.

technet_example

 

The malware searches for this value and then retrieves the encoded data stored between “@MICR0S0FT” and “C0RP0RATI0N“. This value is the result of a fairly simple encoding routine.  Every two bytes represents a single number, which when combined back together creates an octet of an IP address.

As described in the example below, the IP address if 192.168.1.1 can be encoded as amyzbabq and would be stored on Technet as:

@MICR0S0FTamyzbabqC0RP0RATI0N

 

Each octet of the IP Address is encoded using two characters.  The table below breaks down the original values for each set of characters.

First setSecond setThird setFourth set
amyzbabq
19216811

 

To determine the first octet simple logic is applied to each character of the first set.

The decimal value for each character is obtained.  For the set of ‘am’, this would be 97 for ASCII letter ‘a’ and 109 for ASCII letter ‘m’.

The second value, 109, is then bit-shifted left by 4.  The resulting value is then added to the value of the first character, 97.

The routine then subtracts the value of 113 (0x71) from the sum and cast as a single byte (commonly seen as “& 0xFF”). The resulting value is 192, the first octet of the IP address.

 

The same logic is followed for the remaining octets.

OperationResulting Value
1109 << 40x06D0 (1744)
21744 + 970x0731 (1841)
31841 – 1130x06C0 (1728)
41728 & 0xFF0x00C0 (192)

 

It should be noted that several letter combinations could produce the same value once decoded.  This is demonstrated in the example 192.168.1.1, which we show in an encoded form as ‘amyzbabq’, both the value ‘ba’ and ‘bq’ will properly decode to the value of 1.

 

The retrieval of this traffic is stored in plain text and can be easily tracked by a comprehensive network-monitoring solution.  RSA’s Security Analytics and ECAT can both be leveraged to assist security hunters in detecting this activity, and an adversary early in their campaign.  Using a custom LUA Parser for Security Analytics, security can be alerted to the presence of this malware in their environment by inspecting all network traffic for this unique encoding structure. Instead of passively allowing all traffic from a trusted provider, incorporating parsers, like the one provided leaves no packet unsearched. This decoder will detect the activity, decode the IP address, and store it as an indexed value for detailed analysis, under IP Alias (which is illustrated in the image below).  This parser is provided along with this blog, along with a Yara Rule for the executables, which can be used independently or ingested into ECAT.  The image below illustrates how the alert that will be observed in Security Analytics.

png_rat_alert

While the attached parser has been tested and used by the RSA IR Team without issue or impact in multiple SA environments for our customers, custom content should always be tested and its performance implications considered before integrating additional content into an organization’s  SA infrastructure.


Additionally, RSA has created a simple Python script for automatically decoding these values that can be leveraged or implemented into other internal projects.  This file is also provided along with the publication.  For more questions about this blog post or other information in general, please contact us at FirstResponse@rsa.com

 

All of the files that were referenced in this blog can be located in this archive

hunter

“In a sea change nothing is safe. Strange waves push us every way,

In a stolen boat we’ll float away” – Beck from Little One

111931

With a week of recovery under my belt I’m finally able to reflect on another amazing RSA Conference. Some of my experiences were the same as years past. My feet were once again sore from 8+ miles a day of walking. I had the pleasure of coming home with the dreaded RSA flu (apparently dousing myself in hand sanitizer does not actually do anything) and my liver and I are no longer on speaking terms. Of course I also got a chance to catch up with dozens of old friends but barely got to speak to countless others. Another year gone and already looking forward to RSA Conference 2016 (in addition to the many Cons I’ll be attending in between).

 

Here are my top 3 personal takeaways from RSA Conference 2015:

 

Amit’s keynote kicked butt

For years at RSA we asked ourselves who would give the keynote at RSA Conference once Art Coviello retired. This was often used as a litmus test for water cooler discussions amongst employees about potential successors to the throne. If you couldn’t imagine a person giving the keynote at RSA Conference could they really lead our company? Could they lead our industry? The RSA Conference keynote represents more than a typical vendor keynote, it has always stood as a state of the union so to speak for the security industry and Art was a master at giving it.

 

When Amit Yoran took over as RSA President no one had any doubt that he was a security guru and a passionate leader. But would that come off on stage? I’ve seen Amit speak many times over the past four years. Sometimes his personality shone through, sometimes he was just seemed like yet another executive. Fortunately, the Amit that gave this year’s keynote was definitely the same passionate, highly opinionated and funny in a slightly inappropriate way person we work with every day at RSA. He doesn’t mince words or shy away from a debate and his keynote was no exception. It was bold, it was aggressive, it kicked butt. You can watch it here.

 

If I had to summarize the keynote in 3 bullets:

  • The security industry is fundamentally broken and we need to change
  • Signature-based tools like SIEM are failing. Pervasive visibility and deep investigation is “what SIEM was meant to be”
  • We’ve lost focus of our mission and often are just pretending to do security. Its time to actually start facing the most important challenges head on.

 

Internally at RSA we’re going through a sea change being dubbed as “RSA 2.0” where we focus on moving faster, thinking bigger and solving the most important problems we see in the industry. Amit’s keynote was a call to action for the rest of the industry to take a long hard look at themselves and start doing the same. Some are already getting the message:

 

Screen Shot 2015-05-01 at 11.35.12 AM

 

Screen Shot 2015-05-01 at 11.35.05 AM

 

Screen Shot 2015-05-01 at 11.34.41 AM


There are over 500 vendors at the RSA Conference and I have no idea what most of them do

I usually try and carve out at least 4 hours to walk the showroom floor. Besides competitive analysis, marketing benchmarking and schwag procurement I really just find it …. Fun. I don’t know what that says about me but I’m guessing it stems from a combination of my love for security and my upbringing walking aimlessly around New Jersey malls hoping to spot a cute girl that I’d inevitably be too afraid to talk to (Side note: I’m so glad the Conference banned overexposed booth babes, it was a long time coming).

Each year (and this is 9 straight for me) walking the floor it seems to become more and more difficult to separate one vendor from the next. Besides the fact that many security teams stink at marketing (RSA luckily has geniuses like me so we’re not in this bucket) but the messages are completely bleeding together. I sympathize for practitioners. If I have no idea what a vendor does and I’m paid to figure it out I can’t imagine trying to navigate the Expo Hall in an attempt to learn more about the industry and what you should be looking to purchase must feel like. It has to be overwhelming. Next year we should supply tour guides like they have at the Roman Coliseum to walk you around. Bottom line: Vendors need to do a better job showing the actual use cases their products solve. Buyers need to pay less attention to marketing buzzwords and think about their individual security priorities before walking around the Expo Hall.

 

We’re past the tipping point

The excitement I felt this year was different than years past. Perhaps it’s the fact that we’ve gone mainstream, or the sheer volume of the event, or the fact that the products we’re focused on in the Advanced SOC group at RSA are really starting to reshape the security landscape. Or perhaps it was the seven caffeinated beverages I drank daily in order to physically get through the Conference. Whatever the cause, I felt there was a real buzz to this year’s event.

 

First, I went to go to our Advanced SOC user group meeting and couldn’t get into the room. Over 100 customers (with a few employees sprinkled in) overstuffed the venue. Our demo stations didn’t just get traffic they got attention. Demos were lasting 45 minutes with real engagement; the hands-on lab we set up in the booth had users interacting with our products for hours in some cases. When I got to San Francisco I saw a lot of competitors using the same key word as we use: visibility. I started to get a little worried we would get lost in the noise but we didn’t. I think our message that you need to see everything, and not just one myopic security viewpoint really resonated. This is why we chose the tagline “See Everything. Fear Nothing.” for our upcoming RSA Security Analytics launch event and why we had hundreds of articles written about RSA (the company, not the event) through the week. Simply amazing. I’m curious if other vendors felt the same buzz. Rising tides lift all boats.

 

The week completely wiped me out but also reinvigorated my passion for security and what we still can achieve. I hope it did the same for you.

 

See you next year.

 

You can find me on Twitter @Geftic

This blog originally appeared on the RSA Speaking of Security site here: https://blogs.rsa.com/security-hipsters-meet-mainstream/  We felt it was worth reposting to this Community. 

 

moustache-473661_1280

“Well, my boyfriend’s in a band, he plays guitar while I sing Lou Reed. I’ve got feathers in my hair, I get down to Beat poetry. And my jazz collection’s rare, I can play most anything. I’m a Brooklyn baby.” – from Brooklyn Baby by Lana Del Rey.

 

Whether we like it or not the security industry has officially gone mainstream. The scene just isn’t what it once was. We’re no longer a counterculture movement. Face it, security is…OVER. It’s been co-opted by the mainstream. There is literally a movie in theaters now called “Blackhat.” Dude, it’s over.

 

 

Have you seen security “experts” you never heard of giving their uninformed opinion to an even less informed news anchor on a major news network? It’s happening every day. You know that guy who shows up at events like DerbyCon wearing a slick suit? He’s not going away anytime soon. Your retired father calling to kibitz (chit-chat) about one of the latest security breaches and theories on attribution – I’ve been on that call. Literally, as I’m writing this there is a commercial on during The Simpsons featuring a real-life “hacker” with a beard and hoodie trying to convince me to go to college to study cyber security. These things are our new normal. Security has gone from hipster status to mainstream status and there isn’t much we can do about it other than accept it, preach our passion and spread our truth.

 

We may not like it, and we don’t have to be happy about it, but we actually are going to need the annoying “mainstream” if we’re going to accomplish our security missions. That’s because unlike tight jeans, yoga, artisanal ice, ironic facial hair and The Lumineers, security reallymatters. Security can’t continue to be a niche. It impacts all of us personally and its sphere of influence is only expanding. Not only do we need the mainstream to have the broad impact we want, but it is also our job to make sure that the new guests at our party are learning about security from us, and reaching out to us for advice. Don’t make them feel unwelcome or stupid or else they’re going to start listening to people who you probably don’t think much of, rather than listening to you. Sometime you are just going to have to shout a little louder to ensure your good idea trumps a misguided poor idea. But it will be worth it in the end.

 

The world is changing around us and we can make it better. The good news is we have an incredibly smart and passionate community who are totally capable of driving the security industry in the right direction. Let’s make that our collective 2015 resolution.

 

PS Yes I recognize the irony of writing about hipsters on a corporate blog … just pretend I’m doing it to be ironic

We are very excited to announce a set of new content specifically designed to take advantage of the release of RSA Security Analytics 10.4 and RSA ECAT 4.0!

 

One of the major content highlights of the Security Analytics 10.4 release is the addition of NetFlow support. To take advantage this new feature, we’ve created a suite of NetFlow rules and reports that will allow you to collect and correlate flow-based host and protocol statistics. This allows our customers to better detect potentially malicious activity that may not occur underneath the umbrella of a packet or log decoder.

 

Another highlight of the releases is the deeper integration between RSA ECAT and RSA Security Analytics and the ability for ECAT to utilize RSA Live feeds.  This content release includes a set of correlation rules from Event Stream Analysis (ESA) to integrate endpoint data with log and network data.  Additionally, we have provided a set of new threat detection rules to detect identity abuse and DoS events.

 

NetFlow

•      New NetFlow reports providing a summary of top talkers, protocols, and applications.

•      New NetFlow alerts triggering on high volume TCP reset events, as well as SYN flood detection.

•      Netflow reports for “First Heard” source and destination IP.

 

Endpoint detection with RSA ECAT alerts

•      New correlation rules in ESA for detecting malicious end-point activity found by ECAT combined with network activity captured by Security Analytics. Use the power of both tools to gain a broader visibility into your environment and detect compromised hosts.

 

Threat Detection

•      New correlation rules in ESA rules to identify potential identity abuse and suspicious privileged escalations.

•      ESA rules to identify multiple denial of service techniques.

 

 

Regards,

 

The RSA Advanced SOC Content Team

“Look out honey, ‘cause I’m using technology”

– from Search And Destroy by Iggy & The Stooges

 

The old saying goes “You cannot stop what you cannot see”. This is why one of our obsessions in the Advanced SOC group at RSA is our focus on visibility. We want to ensure that our customers have the broadest view possible so they stop missing attacks that are putting their organizations at risk.  One reason they are missing attacks is because they are relying on a log-centric approach.  This limited scope means that they are only getting insight into the most basic security data, and missing out on the rich context that would give them a fighting chance to defend their organization against advanced attackers.

 

RSA Security Analytics is the only solution that has visibility across log, network packet, NetFlow and endpoint data in single infrastructure.  This broad view gives analysts the ability to see everything happening in their environment, not just what was logged. Utilizing a risk-based approach to data collection allows organizations to collect the data that is appropriate for their needs and use cases.  Each of these data sources provides teams with a different perpective:

 

  • Logs: Logs give basic security information and can be useful to spot previously seen attack signatures. While helpful, they dont have the deep detail to spot many attacks, especially advanced attacks, and lack the context to understand what is truly happening and what to do about it. This is partially why log-centric SIEMs struggle at incident detection, investigation and response.
  • Packets: Full packet capture is the most important data source for incident detection, investigation and response. Packets give the SOC visibility to see everything happening on their network, especially when the data is enriched at capture time with additional context. Utilizing packets SOCs can understand what exactly happened, what was targeted and how they were impacted.  This is absolutely crucial to go beyond basic correlation and move to an intelligence-driven security approach.
  • NetFlow: NetFlow, while not nearly as rich as Packets, can be a useful data source. We see NetFlow serving two primary use cases.  First, for those who have logs and want more visibility into network traffic but aren’t ready for packets NetFlow is a good in-between step.  Second, NetFlow is a good fit for those who want visibility into internal traffic, typically to detect lateral movement.  Packets are best for this use case but are not always realistic to be deployed at this scale. As an alternative, NetFlow gives organizations some visibility here to help spot internal movement of attackers.
  • Endpoints: Endpoint data is in some ways the forgotten ingredient for complete visibility.  While some SIEMs offer basic endpoint information, it is nowhere near the level of detail needed to be helpful for detection or investigations. Using RSA ECAT and its unique scan technologies, SOCs can get a real-time x-ray view into what is happening on the endpoint. This gives teams the ability to detect threats undiscovered by traditional AV, conduct deep dive investigations on the endpoint and analyze and combine this data with log and network information gives teams a much more robust view of their environment.  RSA ECAT also has the added advantage of instantly identifying all other machines that were infected to know how far the threat spread.  This way SOCs can not only detect the attack and understand what the attacker attempted to do, but also see where they are still vulnerable. 

 

At RSA we’re obsessed with providing the broadest visibility possible from logs to packets to NetFlow to endpoints.  Utilizing a risk-based approach to data collection SOCs can choose the right data for the right use cases giving them not just visibilitybut the right kind of visibility.

 

What types of data sources do you rely on?  Where could you use more visibility?

NOTE: This blog entry originally appeared on RSA's Speaking of Security blog: https://blogs.rsa.com/rsa-uncovers-new-pos-malware-operation-stealing-payment-card-personal-information/

 

 

By Yotam Gottesman, Senior Security Researcher, RSA FirstWatch team

In a recent investigation, RSA researchers uncovered the server infrastructure used in a global Point-of-Sale (PoS) malware operation responsible for the electronic theft of payment card and personal data from several dozen retailers, mostly based in the U.S. Infection activity has also been detected in 10 other countries including Russia, Canada and Australia. While the malware used in the operation is not new, RSA researchers discovered that, beginning October 25th, it had logged track 1 and 2 data of payment cards it had scraped from infected PoS systems.

RSA anti-fraud researchers have been in contact with victim companies at the center of this operation, sharing key forensics information gathered in this investigation.

As part of RSA’s investigation that uncovered this stolen payment card data, RSA observed “ChewBacca,” a relatively new, private Trojan used in this operation that features simple keylogging and memory-scraping functionality.

Untitled

Figure 1: ChewBacca server login page

ChewBacca Bot

ChewBacca features two distinct data-stealing mechanisms: a generic keylogger and a memory scanner designed to specifically target systems that process credit cards, such as Point-of-Sale (POS) systems. The memory scanner dumps a copy of a process’s memory and searches it using simple regular expressions for card magnetic stripe data. If a card number is found, it is extracted and logged by the server.

 

Untitled

Figure 2: Using RegEx to scan for credit card data in memory.

 

RSA observed that communication is handled through the TOR network, concealing the real IP address of the Command and Control (C&C) server(s), encrypting traffic, and avoiding network-level detection. The server address uses the pseudo-TLD “.onion” that is not resolvable outside of a TOR network and requires a TOR proxy app which is installed by the bot on the infected machine.

 

Installation Process

The Trojan is self-contained and runs as-is. It has no dynamic configuration and is non-modular according to RSA’s investigation.

Upon running, ChewBacca installs a copy of itself in the Windows Start > Startup folder, as a file named “spoolsv.exe“, for example:

Untitled

Figure 3: Dropped ChewBacca malware file.

The file name disguises the Trojan as a Windows Print Spooler service executable, and placing it in the Startup folder causes it to run automatically at Windows startup.

After installation, the keylogger creates a file called “system.log” inside the system %temp% folder, logging keyboard events and window focus changes.

Based on its current findings, RSA believes that deleting this file and rebooting will effectively remove ChewBacca from an infected system.

ChewBacca Server Side

The server side control panel allows the botmaster easy access to manage the botnet and review the compromised data. A “Reports” screen lists information about the compromised machines and the data captured from each of them. Data is presented in either parsed form or in raw text (as it was grabbed from the machine).

Before disappearing behind TOR, the controller of this botnet was observed logging into the server from an east European country.

Untitled

Figure 4: ChewBacca server-side reports screen.

 

The ChewBacca Trojan appears to be a simple piece of malware that, despite its lack of sophistication and defense mechanisms, succeeded in stealing payment card information from several dozen retailers around the world in a little more than two months.

Retailers have a few choices against these attackers. They can increase staffing levels and develop leading-edge capabilities to detect and stop attackers (comprehensive monitoring and incident response), or they can encrypt or tokenize data at the point of capture and ensure that it is not in plaintext view on their networks, thereby shifting the risk and burden of protection to the card issuers and their payment processors.

RSA researchers are continuing their analysis and monitoring of the operation.

 

Yotam Gottesman is a senior security researcher at RSA’s FirstWatch team. Yotam is an expert in software security and malware research, having specialized in protocol analysis and reverse engineering malicious code written for both the Windows and Linux OS. When not dissecting malware, Yotam can be found trading stocks and closely watching financial trends.

NOTE: This blog is being posted on behalf of Alex Cox, Principal Research Analyst on the RSA FirstWatch team.  To read more of the FirstWatch team's blogs you can visit their RSA Speaking of Security blog page: http://blogs.rsa.com/author/rsa-first-watch-team/

------------------------------------------------------------------------------------------------------------------

 

As reported today, yet another zero-day exploit in Acrobat Reader is being used in the wild in targeted attacks.  Details can be found here:

 

http://www.pcworld.com/article/2027946/researchers-zero-day-pdf-exploit-affects-adobe-reader-11-earlier-versions.html

 

As is the case in most of these situations, RSA FirstWatch begins analysis of such threats as soon as they are discovered, and this threat is no different. 

 

One of the things that the team did in regards to PDF exploits was to profile the most common methods and techniques for PDF-based exploitation and document them.  These techniques were then developed into a FlexParser for the RSA Live (aka NetWitness Live) library.


The good news is that the Adobe Zero-Day uses a common “Open” action when exploiting the target workstation and this is detected forensically on the wire using our parser.  While this particular action is not always malicious, it’s unusual enough that it’s worthwhile to look for it in your network traffic on a regular basis.

 

To detect this attack (and others like it, zero-day or otherwise), use the following pivot in Security Analytics, or NetWitness Investigator:

 

  1. risk.info = “pdf with open action”

 

 

....which will be displayed as follows in the RSA Security Analytics “Investigation” view or in NetWitness Investigator:

https://community.emc.com/servlet/JiveServlet/showImage/102-18196-48-54584/alexadobe1.png

 

 

If we then reconstruct the session we get additional details:

https://community.emc.com/servlet/JiveServlet/showImage/102-18196-47-54577/alexadobe2.png

 

 

For RSA Live (aka NetWitness Live)  customers that want to make sure they have this parser loaded, please look for the following in your RSA Live subscription:

 

https://community.emc.com/servlet/JiveServlet/showImage/102-18196-48-54585/alexadobe3.png

 

 

In the name of responsible disclosure, we can’t release additional details on the exploit at this time, but this detection offers a generic way for our customers to inspect suspicious PDFs in lieu of a patch from Adobe and/or additional public indicators.


 

Happy Hunting!


 

- Alex Cox, Principal Research Analyst,  RSA FirstWatch

Filter Blog

By date: By tag: