From Scans to Adversary Emulation, Pentesting is Evolving Rapidly

Traditional pentesting is evolving as many companies are rapidly maturing their information security programs. Additionally, improvements in operating system hardening, endpoint protection agents, and security appliances are raising the bar for successful compromise and lateral movement. If you talk with pentesters across the industry, you will hear more and more positive stories about client security programs, compared to even a few years ago.

 

Old and Busted

It’s more common for testers to run up against more maturing products that provide alerts on common attack patterns or post-exploitation activities. Many of the go-to testing tools are becoming ineffective without modification to the code to avoid early detection.

Here are some great examples of the tester getting spotted:

Figure 1 – CarbonBlack Detecting ‘Impackets’ WMIExec.py

 

Figure 2 – CarbonBlack Detecting CobaltStrike Lateral Movement via PowerShell

 

Figure 3 – PaloAlto Detecting Empire Traffic Over the Wire

 

Figure 4 – Symantec EndPoint

 

In addition, most pentests are time-boxed engagements with one- or two-week testing periods and a client-defined scope of systems. The engagement includes trying to enumerate as many paths to data or privileged access as possible during this allocated time. Consultants in the past have been able to pretty easily avoid detection. However, with the advancement of EDR, SIEM, and IDS, there is tradeoff between coverage and stealth during a fixed-time engagement. Often, stealth Is sacrificed for the sake of covering as many systems and attack paths as possible.

 

The New Hotness

With the increasing maturity level of clients, new and novel approaches to testing are needed. One approach includes adversary emulation assessments. Clients who have the ability to detect, respond, and contain threats benefit from adversary emulation exercises, as it allows consultants to purely target a specific goal or piece of data. Oftentimes, that route to client data can side-step the need for Domain Administrator or other highly privileged accounts, around which strong controls and alerting are built. These types of engagements can often be spread out over multiple weeks and even months, which allows for a better understanding of the environment, and provides time to possibly circumvent alerting and other potential security controls.

Here’s one where new approaches are needed and successful:

Figure 5 – Traditional Alert Around “Domain Administrator” Account Being Added

 

What’s the Goal?

So now the question is, what are you trying to determine from a technical assessment? Are your users susceptible to spear-phishing attacks? If the user does divulge credentials or execute malware, are sufficient protections in place to quarantine the malware or alert on outbound Command and Control (C2) communications? If the endpoint compromise isn’t detected, can lateral movement activities be detected? Knowing the capabilities at each layer of security is important to determining the focus and goals of the assessment.

 

Simulating Real-World Threats

Simulating real-world threats that would likely affect the client provides the most value for the engagement. Examples can include a targeted spear-phishing attack, malicious insider, or breach of the DMZ. We will explore these scenarios in a little more detail.

 

Spear Phishing

What is your ability to respond to an attack launched from ? The level of effort required to gather the necessary information to launch a spear-phishing attack is fairly minimal. Email address format can be determined from past breach data, or even soliciting a reply from an info@ or other inquiry address. This information is then coupled with names and titles gathered from LinkedIn, Salesforce, and other publicly available resources. A pretext is then developed to target employees who would provide access to the goal data. If the target is successfully coerced into clicking the embedded email link, is the outbound connection detected and blocked? If they executed malware, was it detected and blocked? If not, were the C2 communications detected? If not, were post-exploitation and lateral movement activities detected?

 

The Malicious Insider

The disgruntled employee who wants to steal, corrupt, or manipulate company data or intellectual property is another potential emulation. This scenario could have several potential outcomes: data could be exfiltrated to a local drive or to a server positioned on the Internet; network privileges could provide access to sensitive information, to which the insider might not normally have access; and corruption of data could be performed manually within a database or by execution of destructive malware. Can you detect abnormal access to systems and data? Does application whitelisting properly prevent binary execution? Is DLP tuned to detect unpermitted movement of data?

 

DMZ Breach

It is common for many companies to provide remote access to internal network resources. Examples could include webmail, virtual desktop infrastructure (VDI), and VPN, to name a few. Even with multi-factor authentication (MFA) enabled, untrained users could still be coerced into authorizing authentication when bombarded with push notifications. Without MFA deployed, VDI login portals could be abused for brute-force of weak user passwords. These platforms provide a remote desktop within the internal network. Are you able to detect multiple failed login attempts against externally facing portals? Are VDI desktops properly hardened to prevent access to applications commonly abused by attackers, but generally not needed by most users? Are users properly trained to understand when authentications occur on the systems that they use to conduct their job within the organization?

 

Attack Like a Professional

Taking a threat-modeled approach with appropriate goals is key to building and executing a successful engagement. While no company wants to be breached during these activities, the success can be measured in exposing areas that were thought to be covered by the various layers of the security program. Maybe the SIEM needs further tuning, maybe detection is missing in certain corners of the network, or maybe sensitive data was located where it was not expected. All exposures aid the client in better refining their program and ultimately raising the bar to successfully penetrate the network and access sensitive data.

 

Other Considerations Within Mature Security Programs:

Automation A number of automated “Red Team-style” frameworks have popped up lately, promising to emulate or replace adversary simulation exercises. These tools work by replaying static attack techniques to hopefully cause an alert in the SIEM or EDR product. The tools have their place and are a great thing for SoCs or Blue Team to test their tuning efforts and alerting. The downfall is that they are still based off of static signatures. Attackers spend significant amounts of time chaining together known and unknown techniques to break signature-based alerting. The majority of EDR products are fairly easy for an attacker to identify, without the need to call an API or execute a command that would cause an alert. Once a product is properly identified, an attacker can attempt to modify the attack pattern to work around known product weaknesses.

Research The future of offensive security consulting is going to be deeply rooted in companies with a strong focus on research. The defensive side is making great strides with machine learning and a much deeper understanding of the attack patterns used by adversaries and malicious actors. Offensive companies will need to continually research new techniques and trends, which will be integrated into active and future engagements. The rate at which anti-virus/EDR companies can create signatures for techniques and methods is going to greatly hinder the ability to use off-the-shelf tools without modification and testing.

Risk Assessments Both security risk assessments and advanced pentesting contribute to the overall quality and maturity of security programs. Risk assessments are the iterative process that analyze the potential threats to a system in order to calculate the likelihood of their occurrence and their consequence. The common risk equation is [Risk = Threat x Vulnerability x Impact – Controls], and thus includes not just vulnerabilities, but threats, impacts, and countermeasures as well.

The high-level perspective of a risk assessment can provide guidance to the activities carried out during penetration testing, whereas testing can provide crucial feedback on the actual functioning of the program. Integrating the activities from both sides allows for a more accurate, focused, and helpful assessment that provides real value to the business.

Are you looking to make your risk assessments more actionable and valuable? Listen to our webinar “Ensuring Risk Assessments Have Business Value.”

Justin Elze

Author: Justin Elze

Justin Elze is a Principal Security Consultant with TrustedSec’s Force practice with over ten years of experience in the Information Technology industry. His areas of specialty are in enterprise penetration testing, network security, social engineering, red teaming. Prior to joining TrustedSec Justin was a senior penetration tester for Accuvant LABs, Dell SecureWorks and Redspin where he leads numerous red team engagements, penetration tests, and HIPAA risk assessments. Justin has worked in various industries including Internet Service Providers, hosting, DoD contracting, and services consulting companies. Justin has a broad range of experience in information technology implementation and solutions. The diverse environments and a broad range of technology solutions have given Justin a wide variety of skills and experience that applies to his current role.