The goal of this post is singular: inform you (innocent reader, client, or competitor) about how we at TrustedSec are attempting to meet specific industry needs that have been growing over time pertaining to Assumed Breach testing. In our little infosec world of unceasing, ubiquitous streams of highly technical information, this post takes a more contemplative, and hopefully humorous, route to its conclusion. No GPT filler, no memes even, just a ponderous and shenanigan-laced hindsight at the offensive industry from a country guy with an inappropriately fast internet connection and a penchant for spinning mental tops.

I recommend reading along with the consumption of your favorite beverage, but for the impatient, I discuss the specifics of our Assumed Breach testing model under the "Scenarios" heading.

A Salty Walk Down Memory Lane

For a while now, network pentesting has largely been settled into two primary categories: external and internal. External tests are typically scoped to IP address/hostname and run black-box style (no creds, no remote access, find-it-yourself), and internal tests are usually run from a network implant device that’s shipped to the client. This device typically consists of a Linux distro, for example Kali, Ubuntu, or BlackArch, and establishes a reverse SSH tunnel back to HQ, which the tester uses to connect and perform the test. 

These concepts are well-worn paths that most organizations are reasonably comfortable with in 2024. Fears of major outages are largely unrealized, though there is the occasional batch of locked accounts and someone foolish enough to monkey with the Configuration NC in Active Directory, but overall, the biggest black eye in the offensive security industry is testing firms that don’t test at all, but simply print nmap/Nessus results into a report. I still hear of this happening and it’s as cringeworthy today as it was 10 years ago. An extra helping of cringe is in order for said firms because before the dawn of behavior-based controls, pentesting wasn’t just easy to those who knew the dark arts, it was glorious.

Offensive shops had been coasting on DA-by-lunch tradecraft such as Responder, Mimikatz, and PowerSploit for years. Every conference talk given by red teamers hammered the need for 'the basics' (least privileged access, patched systems, good security baselines, etc.) ad nauseum, to the point of heaping shame upon defenders with headline tweets along the lines of 'we can’t even get the basics right, how are we supposed to ??' Defenders were awash in their own tears and guilt, doomed to endless breach disclosures, holiday on-call nightmares, and 'McAfee LOL' jeers from the Red Team as a never-ending stream of hashdumps flew across the screen in a haze of Red Bull-infused shellibrations. The gloating was to be short-lived, however.

Not to be outdone, the defense did what it always does, and sometimes does well: it adapted. As if outgrowing the timidity of adolescence, defenders realized that AV wasn’t going to save them and began ingesting massive quantities of internal logs, determined to increase visibility where it mattered (at the time this was endpoints). The industry awoke en masse to important event codes such as 4688, 4662, and 5145, learning that the precious data they sought this whole time had just been waiting for the right GPO to enable it.

Gigabytes+ of logs were generated, all tucked neatly into open-source and commercial SIEMs such as Splunk, Graylog, and ELK Stack. Purple Team engagements arrived on the scene, enhancing and fine-tuning detections, putting dashboards of high-quality alerts in the hands of the SOC for the first time. And SOCs, at least the ones that didn’t delete these dashboards because 'they never did anything', reaped the benefit of a greater measure of peaceful sleep. 

But it wasn’t only internal defense teams that were paying attention. Vendors had also been noticing that existing security tooling was ineffective at stopping…well, pretty much everything, leaving a gap in the market for tooling that actually worked at detecting and preventing real attacks (not just 'stopping teh mimikatz' lol). New products were released that, for the first time in history, appeared to bring to reality the ultimate corporate infosec dream: good security that could be purchased. EDR landed on the market with incredible force and was eagerly adopted in a matter of just a few years. The vast majority of clients we perform Red Teams against now use essentially one of two endpoint controls: CrowdStrike or Microsoft. Both are effective. Finally, defenders had realized what had been true all along: they owned the battlefield.

The Red Team, used to years of passwords essentially being handed to them (literally in the case of CCDC, which didn’t help our ego), had been set back on its heels and awkwardly began to relearn the art of curiosity, having grown lethargic on the never-ending supply of Responder logs. Not used to being detected, the Red Team initiated 'Ghost Protocol' and began withholding TTPs from social media. Adversary Simulation ('AdSim') and 'Red Team' engagements took center stage, giving the Red Team more time to adapt to defenses and research new attack methods. Though bruising to the ego, massive improvements in defenses have forced top-tier Red Team shops to make significant investments in their internal tradecraft and tooling, and consequently, use this to improve client defenses to great effect. Organizations that have taken advantage of this have enjoyed massive gains in security posture.

Despite all the huffing about OSTs and petty but hilarious debates over C2s and terms like 'bypass', the red/blue methodology has proven itself time and time again. Improve the Red Team, and you will improve the Blue Team. Almost simultaneously, defenders realized that the Red Team truly had its best interests in mind and that manufactured adversity was really a good thing. Red Teams rightly concluded that good defense is incredible (perhaps even a bit… fun…), and that if they pay careful attention, defenders will help the Red Team develop new tradecraft. So how do we continue this cycle of improvement?

To keep pace with defenses that seem to be improving by the day, Red Teams reacted with the first logical move: adding engagement time. This works to a point, and some clients will readily sign up for a multi-month Red Team engagement, favoring realism and stealth above all. But stealth requires time, and not everyone can afford the lowest and slowest of movements in a network. The advantage of time continues to be eroded by behavior-based detections that are now baselining user activity in weeks and months. Red Teams needed a way of delivering targeted value while not breaking the bank.

Enter Assumed Breach

Assumed Breach (AB) assessments are designed to mimic a threat scenario in which an attacker has already gained access to the internal network via some manner of compromise. But what scenarios are we talking about? Isn’t that what an internal pentest already does? Yes. Kind of. The closest threat scenario that a standard internal pentest mimics is a physical intrusion, but even then, the focus is coverage. That is, how many vulnerable paths to escalation can be discovered, and what vulnerabilities were documented along the way that can shut those paths down if remediated. Do all of it as fast as possible, targeting as many systems as possible, then deliver the results with accuracy and professionalism. 

A company’s security posture can go far, and many have, on simply fixing their pentest findings. Ironically, most great pentesters that I know severely undervalue their own skillset. This may be a good thing however (in small measure at least), as pentesting performance combined with unchecked morals can be easily swung into criminal activity, as the LockBit leader alluded to during a 2022 interview with vx-underground.

Apologies for the digression. So, what is the material difference between the AB and pentesting? In short, and I’ve already alluded to it, pentesting is coverage-based, whereas ABs are scenario-based. Are ABs an 'evolution' of pentests? Not exactly. Penetration testing will continue to provide value as long as there are corporate environments. However, as described above, controls have improved significantly, forcing offensive shops to adjust their services. Even shops that still have non-IT users with local admin rights can buy an EDR and enjoy immediate improvement in their endpoint security, and consequently frustration for the Red Team. This simply means Red Teams must narrow the focus of intrusions, i.e., scenario-based testing, for mature organizations.

At TrustedSec, we have identified several threat scenarios:

• Perimeter Breach
• Disgruntled Worker/Malicious Insider
• Successful social engineering attack
• Credential Abuse
• Physical theft or loss of an internal device
• Physical Intrusion 

These are, of course, high-level categories of compromise and are meant to be so. There is also overlap. For example, it’s easy to envision a successful social engineering attack that leads to credential abuse. Red Teams do this all the time. That said, some lines had to be drawn, and this was an attempt to draw them as cleanly as possible. 

What about ransomware?! I can hear the question loud and clear and have been asked similar questions many times by clients. Is ransomware not a valid threat scenario? The direct answer is, not exactly. Yes, ransomware represents a high-impact outcome of a compromise, but it is not the compromise itself. Data loss is also a potential outcome but is not a threat scenario. Rightly categorizing our terms and what we mean by them is important. Additionally, the requirements to deploy ransomware are similar to standard elevation goals in an AB or Red Team exercise. Before ransomware can be deployed at scale, the attacker must have elevated privileges on the target hosts. Bottom line – fix the escalation paths discovered in an AB exercise and you 'contain the explosion' of a ransomware deployment. Talk to your friendly neighborhood Red Teamer about discovering paths related to backup systems. xD

Scenarios

TrustedSec developed seven AB scenarios that are intended to provide coverage for these threat scenarios. Looking at the chart below, you might think that that some scenarios aren’t in your threat model. That’s perfectly fine (if not debatable) as the intention is to provide different types of targeted tests that will overlap your threat model.

1)    Single-Sign-On Compromise

• Threat Scenario(s): Disgruntled Worker, Successful social engineering (SE) attack, Credential Abuse
• Description: Simulating the compromise of an O365 account, TrustedSec will attempt to access third-party services attached to the O365 tenant using SSO, exfiltrating and analyzing accessible information. Internal network analysis, if achieved, is not performed.
• Minimum Duration: 1 week
• Client Requirements:
  • SSO portal information (Okta, Ping, O365) to be targeted.
  • Valid credentials representing a compromised user. For maximum value, TrustedSec recommends either an active employee to be used (preferred) or a recently terminated account with access rights intact.
  • Point of contact to provide MFA access if necessary.

2)    Network Pivot

• Threat Scenario(s): Successful network perimeter breach, Disgruntled Worker, Successful SE attack, Credential Abuse
• Description: TrustedSec will work with a client-provided employee to simulate the compromise that may be achieved through a successful social engineering attack. Using allowlisted infrastructure and payloads, C2 of a user’s machine is established and used to attack the network in targeted pursuit of a single post-exploitation goal. The focus of the engagement is on post-exploitation activities and detection, not evasive endpoint control testing.
• Minimum Duration: 2 weeks
• Client Requirements:
  • One of the following:
    • Internal worker (non-IT preferred) to act as the compromised endpoint. TrustedSec will work with the employee to establish non-intrusive C2.
    • A laptop and/or Citrix VDI image with domain credentials (username/password) with access that mirrors an existing job role.
  • TrustedSec will submit payload and infrastructure details in advance for allowlisted

3)    Endpoint Compromise and Pivot

• Threat Scenario(s): Successful network perimeter breach, Disgruntled Worker, Successful SE attack, Credential Abuse
• Description: TrustedSec will work with a client-provided employee to simulate the compromise that may be achieved through a successful social engineering attack. Using custom infrastructure and evasive payloads, C2 of the user’s machine is established and used to attack the network in stealthy, targeted pursuit of post-exploitation goals.
• Minimum Duration: 3 weeks
• Client Requirements:
  • Internal worker (non-IT preferred) to act as the compromised endpoint.*TrustedSec will work with the employee to establish non-intrusive C2.
  • Client may choose two targets (application, server, IP address, access level) to be pursued.

*Note: A 'spare laptop' or 'a gold image build' with generic domain credentials is not supported for this assessment as attackers rely heavily on daily usage for situational awareness.

4)    Perimeter Compromise

• Threat Scenario(s): Successful network perimeter breach, Successful SE attack
• Description: Simulating the compromise of an external web application, TrustedSec will acquire C2 of a designated web server or database server (successful SQL injection attack) and attempt to breach a targeted application or network environment from a variety of viewpoints. This can take a variety of forms such as a web shell or full C2.
• Minimum Duration: 3 weeks
• Client Requirements:
  • The execution of an implant on a chosen web server or database server under the context of the application’s account.
  • Depending on firewall rules, an exemption may be required to permit the necessary outbound traffic.

5)    DevOps

• Threat Scenario(s): Disgruntled Worker, Credential Abuse
• Description: Using a client-provided laptop, TrustedSec will connect to the internal network and probe for vulnerabilities related to development operations, such as repo privileges, hard-coded credentials, and inappropriate infrastructure access. Attacks are highly targeted towards the client DevOps environment and corresponding infrastructure.
• Minimum Duration: 3 weeks
• Client Requirements:
  • An account provisioned with developer privileges
  • Laptop with standard developer build
  • Remote access to the DevOps environment

6)    Workstation Compromise

• Threat Scenario(s): Disgruntled Worker, Physical theft or loss of a device
• Description: TrustedSec will test a physical workstation or Citrix VDI image for a variety of security misconfigurations, including both hardware and software-based vulnerabilities, wherever applicable. Exploitation is generally contained to the local machine and does not traverse network boundaries. Any supplied hardware may be disassembled at TrustedSec’s discretion.
• Minimum Duration: 2 weeks
• Client Requirements:
  • Laptop with standard build and/or Citrix VDI access
  • Non-admin login credentials
  • (Optional) Remote access to the corporate network

7)    Physical Breach

• Threat Scenario(s): Disgruntled Worker, Successful physical intrusion
• Description: TrustedSec will simulate a successful physical compromise by shipping a special device that can evade most NAC systems and requires no outbound firewall exemptions. Intended to be a truly stealthy device implant, TrustedSec will use the corresponding connection to effect network compromise using standard techniques.
• Minimum Duration: 2 weeks
• Client Requirements:
  • A physical machine with persistent internal network connectivity
  • Proximity to LTE cellular service

Concluding Ramble

My hope here is that this post gave you food for thought about your own threat model and how that might pertain to your next rounds of offensive testing, and if I made you smile along the way, that’s a happy bonus. If you are on an internal team, you can bend and fit these scenarios to great benefit as you no doubt have more time and capacity than a third party.

And if you stuck with me this long, you deserve a walk, or a sip, whatever suits you.

Cheers!