Software Integrity

 

Are you red team secure?

Data breaches can result in severe damages to an organization’s brand, financial standing, or customer trust. Many of these, including recent breaches in the news, are not the result of a single, easy to find weakness that just happened to be overlooked or the common “low hanging fruit” that is adequately detected by automated scanners and heavily scripted approaches. It is true, these types of issues can play a small part in a much larger attack, but it is oftentimes just that, a small part. Advanced attacks, whether a large scale data breach or a stealthy attack on a very specific target, often occur as a result of a set of weaknesses strung together in the form of a composite attack. Composite attacks that result in an asset being compromised are extremely difficult, if not impossible in many cases to identify with automated or restricted scope assessment activities.

Red teams aim to model the motivations, capabilities, and visibility of an adversary as they attack in pursuit of some goal. That goal could be anything, but what we’ve seen recently is a financially motivated adversary, looking to steal customer data and either resell or use it directly for a profit. The complex nature of how we do business today means customer data will be collected, handled, and stored in a variety of places across a large organization. It is also likely there will be support systems, services, people, and processes that don’t directly deal with customer data but rather have some form of trust-relationship, such as network access through white-listed firewall ACLs or intermediary customer service representatives. Defending this increasingly complex attack surface with traditional risk rank, assess, remediate, rinse, and repeat processes is challenging and as we’re seeing, leaves a lot to be desired for defenders.

To be effective, a red team needs to have clear objectives (i.e., their adversarial goal) and understand the adversary they’re modeling. Let’s talk about objectives first, as this is something very intimately tied to the customer, not a generic “cross-site scripting is bad because of X”. Some of the objectives our red team has achieved in the past include:

  • Gaining access to an internal network starting from a completely external perspective and using that access to plant persistent network sniffers or pivot to sensitive data stores
  • Compromising client information through any of the services provided, internal centralized storage, or through employees
  • Retrieving data from email servers used for external customer communication and customer contact lists
  • Exposing customer PII or payment information
  • Finding ways to bring down a distributed service to directly impact up-time, violate SLAs with customers, and revenue stream

While the establishment of goals is the first step, the next thing to consider in a red team assessment is how to move beyond restricted scope testing, such as just looking at a web app, or a network segment, or conducting dragnet phishing. Real world attackers consider their targets in a holistic fashion relative to their own capabilities, meaning they may leverage a combination of phone and email-based social engineering, application-layer injection attacks, onsite wireless network attacks, or other combinations of attack vectors they can to achieve their goal.

A recent red team assessment leveraged the following elements in a single composite attack to bring us from zero access to goal attainment:

  1. OSINT recon – open source intelligence gathering used to identify employee contact information, roles, office locations, etc.
  2. External network attacks – mail server configuration errors allowed us to send emails without authentication to the employees we identified earlier (open local SMTP relay), directing them to a page we controlled for password and MFA pin collection. Once collected, we immediately authenticated to two-factor authentication protected services such as the VPN and gained access to the internal network.
  3. Internal network attacks – un-patched workstations and servers allowed us to compromise several systems internally and open up persistent, remotely accessible shells. Additionally, we found we could escalate privileges to SYSTEM to make sure our backdoors weren’t blocked by any host-based AV.

Once we were able to obtain internal network access in this engagement, we found several internal-only storage locations that contained archived customer information, which was exactly what we were targeting. In this case, any of the individual vulnerabilities we identified and leveraged along the way may not have been seriously considered in a mitigation plan. By demonstrating that these vulnerabilities, when tied together, allowed us as an external adversary to go from zero access to a complete compromise of the customer data the organization had a new appreciation of seemingly lower priority security holes and what they needed to do to at a strategic level to address their overall security posture.

Ultimately, pushing a security program to the next level with a red team capability provides a new way of thinking about, identifying, and allocating defenses to address risk. Risk in a red team assessment is all relative to an asset, and let’s face facts, assets being compromised are what really makes the front page news, not point-in-time weaknesses. Red team assessments provide a much more realistic picture of an organization’s security posture and how well defended their assets really are.