Mike Saunders is a principle consultant for Red Siege Information Security who will be sharing his thoughts with us on how to approach assumed breach scenarios in a way that’s intended to resolve current issues with today’s pen testing. A large part of this con talk focuses on tools that get used during these assumed breach scenarios.

Pen Testing is BROKEN

Internal pen tests don’t represent how attackers operate, in that they don’t start inside the network, don’t do noisy scans, and aren’t lobbing exploits everywhere. Are we doing a good job of preparing customers for real world attacks?

I Want a Red Team

Most customers don’t need a true red team since they require a lot of time and are expensive. These tests require maturity within an IT organization and don’t take place within two weeks. There is generally a lower return on investment compared to other test options. A red team assessment is long, expensive, complex, and usually tests things that a client may not be comfortable with testing (e.g. targeting employees at lunch).

Assumed Breach Scenarios

Based on the assumption that an endpoint is already compromised or the organization is breached, what can an attacker do with this access? There are two models here that center around a malicious user or a compromised user (they’ve clicked on something). Both use a standard workstation image with representative users, preferably a recently terminated user (both user account and computer!). Domain Admin is a tool, not a destination, and shouldn’t be the ultimate objective during an assumed breach scenario.

Compromised USER - Path A

Simulate a user who clicked on a payload to execute it so that all operations take place over the chosen command-and-control framework, and then pivot into the network to pursue targets.

Compromised USER - Path B

Demonstrate the impact of a compromised user where we operate on a workstation to either initiate command-and-control or poke around the network locally.

AV / EDR - Disabled?

AV/EDR can be bypassed given time, but is it worth it to spend the time to bypass? Discuss the goals with the client. @HackingLZ recommends starting with AV/EDR enabled, verify bypass or visibility of actions, and then disabled if needed.

Malicious User

Simulates employee who wants to steal / cause harm. This can be done with a shipped laptop that is configured to allow VPN or RDP access to the internal network or by going on-site to the client’s office. This can also be done by testing being performed on a standard workstation and using whatever tooling is on the workstation. Standard A/V + EDR deployment.

Real World Tactics

The blog post lays out likely real-world attack scenarios, that started with phishing, then involved pivoting to the internal network through remote access, using Kerberoasting for elevation of privilege, and then accessing high-value targets. Ask the client, “What keeps you awake at night about your organization?” to help firm up the goals of the assumed breach scenario.

Assumed Breach Tactics

  1. Simulate payload sent via email / social engineering
  2. Search out high value targets / data
      a. Kerberoasting for elevation of privilege
      b. Gather credentials
      c. Pivot to data
      d. Access high-value targets

Again, Domain Admin is a tool, not a destination! Always pivot towards data and high value targets.

Domain Fronting

Vendors are breaking traditional fronting models, however, some Content Delivery Networks (CDNs) still work, such as *.cloudfront.net / *.azureedge.net still work. Build a custom C2 profile with Malleable-C2-Randomizer to have a custom C2 profile to a trusted domain using domain fronting.

Initial Access

Simulating phishing with HTAs are common to start an assumed breach scenario with, as they are still effective using the tools unicorn or Invoke-Obfuscation or nishang’s Out-HTA.ps1 or NCCGroup’s demiguise (environmental keying). Either use demiguise with environmental keying or use unicorn into Invoke-Obfuscation into Out-HTA.ps1.

Macros, click once exectuables, and updates are other methods for initial access.

Finding Accounts

Password spraying against OWA / O365 and using MailSniper for this. Domain accounts via DomainPasswordSpray.

Kerberoasting

Traditional tools involve the usage of Invoke-Kerberoast and AutoKerberoast_NoMimi_Stripped.ps1 in the form of Invoke-AutoKerberoast -Format hashcat. These generate Event ID 4769 for each SPN requested, so pulling them all at once is very noisy. Ideally, perform this low and slow, target users in specific groups by using the PowerSploit functions Get-DomainUser -SPN & Get-DomainSPNTicket -SPN with a random delay.

Mining AD

SharpHound via execute-assembly with the –NoSaveCache is your friend. Hunt for creds within Active Directory schema with the command adexplorer.exe -snapshot "" ad.snap -noconnectprompt. For further information about this technique, check out this article about Active Directory explorer.

Hunting Group Policy Preference Credentials

GPP = XML config files stored in SYSVOL, which store credentials for workstation local admin, mapping drives, etc. Further reading here. Tools can be used in the form of PowerSploit Get-GPPPassword or Get-CachedGPPPassword in PowerUp. Manually this can be done with a recursive search against SYSVOL for “cpassword”. If a file were created recently with a honey token or time stomped so it looks like the file was created awhile ago, this would be a great way to catch a pen tester.

Lateral Movement

Find lateral movement to admin access with PowerView. We can do Test-AdminAccess -ComputerName or Get-DomainComputer | Test-AdminAccess. psexec and wmic can also be used for this.

Trawling Files & Shares

Elevated account creds are frequently found in files, PowerShell PSReadLine Logs (ConsoleHost_history.txt), source code, and sensitive data. PowerView can once again be used in the form of Invoke-ShareFinder -CheckAccess or Find-InterestingDomainShareFile or Find-InterestingFile. Be sure to rerun the discovery commands under different user accounts that are compromised knowing that different users have access to different shares. This is noisy using scripts, so doing it manually may be preferable depending on the desired discovery profile.

Hunting Sessions

Find files that can be used for lateral movement, which include SSH private keys, RDP files, FileZilla / WinSCP save passwords, and more. The Session Gopher tool will search for things for us using the commands Invoke-SessionGopher -Thorough or -Target hostxyz -Thorough or -Alldomain -Thorough

BYO PowerShell

Code can be executed in ISE even if PS script execution is disabled. Additionally, build a custom PowerShell environment by including all of the various PowerShell scripts one wants to include. This can be done with PowerLine. Sometimes AV/EDR will pick up on this, so using tools for obfuscation are useful.

Pros & Cons

Pros involve a better understanding of strengths & weaknesses and the ability to model real-world tactics, techniques, and procedures. However, the cons include a limited amount of time, so we must be noisier, not focused on vulnerabilities, and non-representative accounts/workstations can negatively impact a test.

Summary

Assumed breaches are a better way to prepare clients for attacks they’re likely to face if they have had a pen test. This approach does require maturity in client processes and vulnerability assessments and pen test cycles should be executed prior to an assumed breach scenario. Work with clients to get good accounts and workstations that mimic a threat they’re concerned about. PowerShell & Cobalt Strike aren’t the only way–these are just examples.

« home

Reference Index
Estimated date of talk: Wild West Hackin’ Fest 2019
Slides: https://www.redsiege.com/abm
Title: Assumed Breach: A Better Model for Pen Testing
Speaker: Mike Saunders, Red Siege Principal Security Consultant