Incident Response

Home » Incident Response

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 

Incident Response Strategy – Establish a Perimeter via Network Visibility

in Incident Response by Mike Spohn Comments are off

As a seasoned incident response practitioner, I am always looking for better ways to manage serious security breaches. Over the last decade, the cyber-security community has refined many strategies and best-practices to help organizations identify, investigate, contain, and remediate advanced threat attacks. This has been enormously helpful.

I have also found it useful to look beyond our own realm in cyber-space and observe how other industries manage large security incidents. A few years ago, I spent some time researching and interviewing public safety, fire, and military professionals. My goal was to determine if there are patterns of behavior in their response tactics that might apply to our IR space. 

Establish a Perimeter

It did not take long to realize that the foundation of most public safety incident handling practices is to, “Establish and secure a perimeter.” This may seem obvious to you, but it is important to realize the safety of human lives is often at stake if this is not done right. When you think about it, almost all public safety, search-and-rescue, and military operations begin with this strategy.

The most obvious example is the fighting of a wildfire. A large percentage of the effort is spent on surrounding the fire and creating a “Dozer line” free of debris to starve the fire. Granted, the firefighters are usually at the mercy of temperature, wind, and humidity. Regardless of the weather, the containment strategy is to surround the fire and work inward to contain it.

Network Visibility is like setting a fire line

Cutting a fire line – Image courtesy of FEMA

 

You see the same behavior when law enforcement agencies are faced with an act of terrorism. From the Boston Marathon attack to the bombing of the Brussels airport, the response was identical. Establish and secure a perimeter and work inward to determine the scope of the incident and look for suspects.

Sometimes this is really difficult. Consider the disappearance of Malaysia Air Flight MH370 on March 8, 2014. Lacking any reliable telemetry to determine where to search for the aircraft, a primary search area (perimeter) of 23,000 square miles was established. Folks, that is a big perimeter. Regardless, the same rule applied: establish a perimeter and search inward.

 

I immediately realized the value of this strategy in cyber-attack incident response investigations. In a cyber-attack response, the “perimeter” is almost always network boundaries. Why? If the source of the attack is not an insider, and the attacker(s) do not have physical access to your computing resources, the source of their attack will be an external network. This dynamic is obvious and compelling.

This makes it easy for incident responders to determine where to ‘establish’ a perimeter. It will always be where any external network has a route to your internal network. The first place to look is where your Internet points-of-presence (POP) are located.

Once you know the “scope” of your perimeter, you have to make some quick decisions on whether or not you “secure” it.

In the case of PCI, HIPAA, or other regulated data loss, you really have no choice but to secure the perimeter by shutting down the network segment. In other cases you need to make a hard decision. Do you lock out the intruders by securing the perimeter, or do you monitor it to learn more about the attacker TTP’s?

Tough choice.

If you secure the perimeter you tip off the attackers you know of their presence, and you lose the ability to collect additional, often critical, evidence. If you monitor the perimeter you run the risk of watching your precious data head to the Far East.

Here at PacketSled, we are all believers in the “Establish/Secure the perimeter and work inward” strategy when dealing with advanced threat actors. In fact, many of our customers rely on PacketSled network sensors to monitor their network perimeters during high-profile incidents.

Network Visibility is the Key to Establishing a Perimeter

Deploying a PacketSled sensor to establish a perimeter is painless. 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.

 

PacketSled Network Visibility Automated Investigation Advanced Threat Hunting

PacketSled Dashboard

 

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

The Biggest Companies in the World Are Failing at Basic Detection

in Incident Response, Malware, PacketSled, Threat Detection by Web Admin Comments are off
We received a really interesting email from our upstream Internet provider yesterday – AT&T, indicating that we were effectively infected with Tinba malware. For those of you who don’t remember it, Tinba is 4 year old Windows specific Malware based on the old Blackhole exploit kit that does all kinds of fun stuff like steal facebook credentials, attempt to access your online banking accounts, etc. The email was as follows: att-incident Technical and operational observations are as follows:
  • First, we don’t possess any Windows machines capable of executing this Malware, with the exception of some VMs that are turned off unless otherwise needed.
  • Second, all of those machines have adequate endpoint protection on them, such that they would have averted this ancient attack, should it have been, you know, actually happening.
Regarding the email we received, if you haven’t already found the funny part, I’d like to point that out first. Obfuscating the IP address of the site that (according to them) indicates an infection is extraordinarily unhelpful, almost to the point where I feel like they might be trying to live up to some weird obtuse legacy of what it was like to order circuits in the 1990s. Thankfully, they took the time to include the domain name, which, you know…resolves to the obfuscated IP address listed directly above it. The unfortunate part about this situation is that they simply didn’t have the proper tools to make a quick determination that this was in fact, not a threat at all, and that we were running some tests on this network against legacy threat intel. Of course, we knew that, and we could easily validate that such testing was occurring during the timeframe that they mention with a simple query in the investigator as follows:
Querying specific IPs during specific timeframes using natural language

Querying specific IPs during specific timeframes using natural language

We get one session record returned:
PacketSled Investigator

PacketSled Investigator

And immediately determine that this “threat” originated from a Mac running Wget:
Hey look, not a Windows machine. Not even a real browser.

Hey look, not a Windows machine. Not even a real browser.

Nevertheless, we received this email, meaning that someone in the AT&T SOC had to investigate this non-incident, put in a ticket, send the email and manage the eventual closure of that ticket. This scenario is extremely commonplace. The number of SOC personnel, incident responders, and general infosec professionals that routinely chase non-incidents due to only having partial data is extremely perplexing. The data is in the packets. Making it accessible to analysts and automated processes such that it can be intelligently used is the goal. With something this simple getting incorrectly bubbled up to the top, we are clearly a long way off from that goal.

© 2017 PacketSled, Inc.