Network Visibility

Home » Network Visibility

Using PacketSled to detect Golden Ticket Attacks

in Network Visibility, Threat Detection by Patrick Kelley Comments are off
2016 was a year of exciting news in Information Security, and unfortunately one of many breaches. As I write this, I’m reading news about continuing leaks from Yahoo and new SCADA attacks.

With over 20 years as a professional in Information Technology, I’m always looking at new methodologies.  However, I’m also looking at the ways things haven’t changed. 

For as long as I remember, privileged account exploitation has always been at the center of targeted cyber attacks. This provides InfoSec Professionals with a constant pattern of events to look for on their networks.

In typical fashion, attackers penetrate the network perimeter using phishing attacks or attacks on mobile devices, hijack credentials and use them to move laterally throughout the network, taking additional credentials and escalating privileges along the way.

During my time as a Penetration Tester, combining privileged accounts with attacks on the Kerberos authentication in Windows domains was a method I always employed, in hopes of compromising the entire network. In fact, my team used to joke that lunch wouldn’t be served until we had “Domain Admin”. During such attacks, my team would target domain administrator privileges, which provide unrestricted access and control of the IT landscape. Armed with these privileges, my team could manipulate Domain Controllers (and Active Directory) and generate Kerberos tickets to obtain unauthorized access.  Our ultimate goal was the “Golden Ticket”!  That’s the ticket that gives us 10 years of unfettered access.



In order to successfully collect one of these tickets, the four things necessary to formulate one is:

·       the account name of a domain administrator

·       the domain name

·       the SID for the domain

·       the password hash of the krbtgt user from the Domain Controller

The good news is that Golden Ticket Attacks are particularly noisy, both in system logs and on the network. With the ability to perform deep packet inspection on Kerberos and DCE-RPC logs, this gives users of PacketSled the ability to look for indicators of these attacks across their entire network, instead of searching through system logs which are often dispersed and not centrally stored while attempting to piece together the pattern for themselves 

In particular, Golden Ticket Attacks require a particular DCE-RPC command on the network, defined as, “DRSGetNCChanges”. This command obtains updates for a specified naming context (NC = partition of the AD database), typically between domain controllers.  This behavior is particularly useful, as knowing that this data would not be transferred between a workstation and a domain controller would be anomalous.



Now, how do you get visibility into these attacks from a central point? Well, deploying a PacketSled sensor to establish a perimeter has never been easier. We have an IR deployment package that can have you up and running in minutes. Provide a SPAN/TAP feed to our sensor(s) and you have perimeter network visibility when you need it most.

Using this approach to develop the security detection moves the security controls from making decisions based on circumstantial, atomic elements and moves towards being more contextual in nature. This can greatly reduce the false-positive rate and make notifications more actionable.

At PacketSled, our researchers are continually pushing the boundaries of using our IRES-based security platform to provide greater value in security notifications. We do so by not just notifying InfoSec Professionals with alarms of potentially malicious behavior, but putting the context of those events in their hands as quickly as possible. 

Let us show you the value of PacketSled network visibility tools. To arrange a product demonstration or talk IR strategies give us a call.

Attacks On Routers and IoT

in Incident Response, Malware, Network Visibility, Security Research by Patrick Kelley Comments are off
Here at PacketSled, we live on the forefront of technological innovation.  Our deployed platform captures multitudes of attacks each day against devices that have just barely made it into the market. To keep up with attacks against “bleeding edge” IoT devices is no small feat.

To understand how to best protect these new assets, it’s best to understand what brought them here.  The adoption of IoT and BYOD has increased with the intent of streamlining technology for the user and easing adoption in the marketplace..  Apps in IoT can become seamless, removing the barrier that a user used to have in determining if they were sharing information with a co-worker or with the Internet.  The more covert we make these transactions, the more risk we are accepting (think tap to pay, passwords transferred through nfc, and magic links as Slack likes to call them).  

Without a clear understanding of standards and services, it’s a challenge to determine how to best approach securing them. In fact, it’s such a challenge that Gartner has claimed that nearly all security vendors will fail at this task. 

Personally, I agree.  

Security budgets are rarely earmarked for efforts around IoT and business scenarios require a delivery mechanism that can also grow and keep pace with security requirements in monitoring, detection, and access control.  Despite this, users continually add more devices to the enterprise network, due to ease of doing so.

Fortunately, PacketSled has been thinking about IoT for quite some time.  Our team has spent many years of focused research on the most common IoT attacks.

One of the most common attacks we witness is authentication bypass. This could be due to poor session handling with predictable IDs or backdoors using hardcoded credentials. Regardless of the means, the outcome is the same – unauthorized access to sensitive information.

A quick search of Shodan will likely provide access to nearly any device, including devices in your infrastructure, an attacker would be interested in. In fact, we need not look further than a recent IoT attack which was seen with Mirai. It worked by scanning the Internet for devices with default credentials and enrolling them into the command and control platform. Once done, all of these devices can be remotely controlled and used to perform nearly any action conceivable. These attacks occurred across a wide spectrum of devices from smart TV’s to routers to really anything with the “smart” monicker attached.

Packetsled is here to help protect by proactively building detections in our platform to look for these behaviors, but our recommendation is to make sure your organization is covering the basics.

Where should you begin? 

Start with the CIS Critical Security Controls with emphasis on the 1st six. 
  1. Inventory of Authorized and Unauthorized devices
  2. Inventory of Authorized and Unauthorized software
  3. Security configurations for hardware and software on mobile and IoT devices
  4. Continuous Vulnerability Assessment and Remediation
  5. Controlled user of administrative or root privileges
  6. Maintenance, Monitoring, and Analysis of Audit Logs
  

With these basics addressed, you will have a more clear understanding of what devices and accounts are in use on your network and how you should expect them to behave.  

Among the many detections that PacketSled provides, you should look for unencrypted credentials present on the network, by issuing the following query in the investigator:

last 24 hours cluster password on [password]





This simple query will provide you with every password observed on the network in the last day.  This list is exportable and can be used to aid in the mitigation of these vulnerabilities.

We also provide extensive support for newer IoT protocols, along with our raw TCP and UDP analyzers, which will allow you to see inside network flows, even when a specific protocol analyzer isn’t available. 

Along with our security platform and the recommendations outlined above, we suggest signing up with each vendor for updates related to security patches, firmware updates and any available alerts provided from the devices, themselves.

 
Written by Patrick Kelley and Chris Mitzlaff 

Analyzing Unknown Protocols – Finding a Piece of Hay in a Hay Stack

in Network Visibility, Threat Detection by Patrick Kelley Comments are off
Over the years, I’ve had the fortune of performing in several differing capacities in the Information Security community.  Some positions have been on “blue teams”, whereas others have been performed more “red team” roles.  One thing that always rings true is the importance of visibility. 

You can’t make decisions around data that you can’t see. 

When PacketSled chose to build our sensors on Bro, we knew that significant effort would be necessary, if we were going to meet our high level of expectations.  Bro provides visibility for around 60 protocols, at this time. Unfortunately, there are literally thousands of protocols. That’s a lot of missed network traffic. 

For those that aren’t aware, WinRM is a remote management service for Windows that is installed in Windows XP and higher versions. Both of these authenticated services are tied to an HTTP or HTTPS SOAP listener and support Kerberos and NTLM authentication by default. It’s important to note that many attacks start with NTLM authentication since it’s already supported in Metasploit.



As our security team began launching live attacks in networks observed by Bro sensors, we realized that many of the Metasploit attacks weren’t being properly observed and tagged.  WinRM traffic is based on HTTP and HTTPS, but isn’t formatted in a manner that is properly recognized and analyzed by Bro. As a company focused on security solutions, we realized that something had to be done to permit our clients to see actionable data in this attack, as well as attacks on other protocols.

Therefore, we built raw TCP and UDP analyzers.  With these analyzers, it’s now possible to build IRES rules or bro-formatted detection scripts to alert on attacks in protocols that aren’t yet supported by the Bro framework.  So, how do you do it? 

By collecting a Packet Capture (pcap) of the attack traffic using our raw analyzers, we were able to extract the associated User-Agents and URI strings associated with these attacks.  

In our case, these were defined as:



User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

URI and Action: POST /wsman HTTP/1.1

Host: 192.168.1.3:5985

Though this was an authenticated session, which later became encrypted, we were still able to see some interesting indicators as the session was established.  The most important being a Mozilla User-Agent connecting to a service that would normally be engaged using a variation WinRM.* as the User-Agent.  Also, we noticed that the listening port was TCP/5985, which is a non-standard HTTP port, and repeated failed authentication attempts.  Knowing this was anomalous and potentially malicious, our team was able to create a simple IRES rule to pull these indicators from our raw TCP analyzed traffic.  By doing so, we were immediately able to recognize a large amount of attacks from Metasploit against WinRM services in our extracted TCP payloads.



The single piece of hay was found in the haystack and what would normally be unrecognizable by standard installations of Bro was quickly brought to the surface.  That is the unmatched power of the PacketSled platform. 

At PacketSled, we’re always striving to provide the greatest visibility with our award-winning platform by continually developing additional protocol analyzers, allowing you to continuously monitor for advanced threats and policy violations missed by other defenses. Allowing you to analyze and remediate in record time. Don’t settle with being an Analyst. Be a Hero!

It’s 10 o’clock; do you know where your data is?

© 2017 PacketSled, Inc.