The Hidden Threat Within: Applying Red Team Tactics to Business Workflows
Thinking Inside the Box
Traditional red teaming approaches often focus on external threats—simulating how an outside attacker might breach a company’s defenses. This method is undeniably valuable, offering insights into how well an organization can withstand external cyberattacks. However, this "outside-in" perspective can sometimes overlook another aspect of security: the risks that arise from within the organization itself. While traditional red teaming is crucial for understanding external threats, thinking inside the box—examining internal processes, workflows, and implicit trusts—can reveal vulnerabilities that are just as dangerous, if not more so to an organization.
In this article, we’re going to explore the often-overlooked risks that lie within typical business processes and how applying a red team mindset to internal corporate processes can uncover hidden vulnerabilities.
Many organizations implicitly trust their internal business processes and assume they are secure simply because they are routine or involve trusted employees. Yet, these very processes can be prime targets for malicious insiders or attackers who manage to gain internal access. Red teaming from an "inside-the-box" perspective, where the focus shifts to testing and challenging internal processes, is an essential but often overlooked aspect of comprehensive security testing.
Why Business Processes Need a Closer Look
Business processes—those routine, often "boring" procedures that keep a company running smoothly—are rarely seen through the lens of security controls. Yet, they are essential to the functioning of the organization. These processes include everything from hiring and payroll to internal approvals and change management. Because they are so ingrained and trusted, they can become prime targets for exploitation by malicious insiders or external attackers who manage to gain a foothold within the organization.
Take, for example, the recent incident involving KnowBe4, a prominent security awareness training company. The organization unknowingly hired a North Korean hacker, who managed to circumvent standard hiring checks designed to ensure only legitimate employees gained access to corporate resources and internal systems. In response, KnowBe4 highlighted several process improvements, emphasizing the dangers of implicit trust in routine business procedures. The attack succeeded due to vulnerabilities such as inadequate background checks, insufficient reference verification, and inconsistencies in hardware shipping addresses, among other flaws in internal processes.
These recommendations underscore the importance of not taking business processes at face value. Implicit trust in routine procedures, such as hiring in this example, can lead to serious security breaches if those processes are not continuously evaluated and strengthened.
Processes Under Fire
When we think about securing an organization, our minds often jump to firewalls, antivirus software, intrusion detection systems, and other technical controls. However, the processes that keep a business running smoothly are just as crucial to protect and can be exploited by malicious actors if they are not properly scrutinized.
While not a conclusive list, below are some quick examples of typical internal processes, often trusted implicitly, which could be targeted with the right level of insider access:
- Permission Change/Approval Requests:
Any process involving permission changes or approvals can be a potential target. If an attacker can bypass or manipulate the approval process—by forging a manager's approval or exploiting gaps in verification—they could gain unauthorized access to sensitive systems or data.
- Hiring and Onboarding:
As demonstrated in recent incidents, hiring processes are particularly vulnerable. Attackers could use fake credentials, falsified employment histories, or even compromised insider help to get hired. Once inside, they might gain access to important systems or sensitive information, posing a significant security risk.
- Promotions or Internal Department Changes:
Processes related to promotions or department transfers can also be manipulated. For instance, an attacker might alter records to reflect a promotion they didn't earn, giving them higher privileges within the organization. Alternatively, they could engineer a transfer to a department with access to more sensitive information.
- Bonuses and Payroll Changes:
Payroll is another process ripe for exploitation. A malicious insider could manipulate the system to award themselves or others unauthorized bonuses or salary increases. This type of fraud can go undetected for long periods, especially if the changes are made gradually or hidden among legitimate payroll adjustments.
- Business Email Compromise (BEC):
BEC attacks against executives and other trusted individuals can target a wide range of communication processes within an organization. An attacker could pose as the CEO or financial officer to request fraudulent wire transfers, manipulate payment details, or approve unauthorized financial transactions. Without stringent verification processes and clear communication protocols, this type of fraud could lead to significant financial losses and damage to an organization.
- Vendor and Supplier Management:
Processes related to managing vendors and suppliers, such as payment approvals or contract renewals, can also be exploited. An attacker might alter payment details to divert funds or manipulate contract terms for their own benefit.
- Change Management in IT:
IT change management processes, which oversee updates and modifications to software or infrastructure, can be compromised. An attacker might approve changes that introduce vulnerabilities, deploy unauthorized software, or disrupt services.
Hopefully, these examples illustrate how even routine internal processes and procedures can become significant vulnerabilities to an organization. Next, let's explore an example more in-depth, and how we can apply a red team mindset to mapping and attacking internal business processes.
Bypassing Internal Approval Processes
Let's take an example scenario involving internal permission change/approval requests. In this hypothetical scenario, the following facts set the scene:
- The red team has gained initial access to a low privileged corporate employee account via social engineering. This includes standard access to internal systems, such as internal knowledge bases, and other typical internal resources.
- The target company has a separated internal federal environment, where only certain employees should have access. An internal approval workflow exists for granting employees access to this restricted environment.
In this example, a traditional red team approach, once gaining internal access, might focus on escalating privileges within the network, attacking systems directly, or exploiting vulnerabilities to gain access to the sensitive federal environment. While these methods can be effective in certain scenarios, they are often more detectable and run directly into various technical security controls like intrusion detection systems, firewalls, and access logs. While attacking from this angle is valid, red teaming is about being fluid, creative, and taking the path of least resistance to achieve the objectives.
So, what if instead of attacking the network directly, we utilized documented internal processes for legitimate access requests? Imagine promoting a compromised low-level account into the sensitive federal environment by abusing the change management and approval procedures.
By exploiting the process itself, the attacker could bypass traditional security measures, gaining access through legitimate channels and potentially remain undetected. This approach leverages the organization's trust in its own processes, turning a “boring” internal process into a powerful attack vector.
Let's break down how we take get a big picture viewpoint to approach this scenario from a different angle:
- What Process Are We Targeting:
In this example, the process involves an internal approval workflow for granting access to the restricted federal environment. This environment is highly sensitive, and only certain employees should have access to it. The process is designed to ensure that access is granted only after thorough vetting and approval. - Identify Stakeholders:
Which employees or roles are required as part of this process, and who does the process touch? In this scenario, the stakeholders include members of the federal team responsible for approvals, the employee's direct manager, and the IT team that implements the access changes. Each of these roles is vital to the integrity of the process. - Identify Inputs/Outputs:
The input in this example process is a change request submitted through a change management system, such as Jira. This request must go through a series of approvals before it is fulfilled. The process's output is granted access permissions and acquiring an account within the federal environment. - Identify Impact:
Successfully completing this process would grant a standard-level employee access to a highly restricted federal environment. Unauthorized access could have severe implications, including the exposure of sensitive data, disruption of operations, or even compliance violations. - Identify Trust Boundaries:
What part of the process relies on others? This involves creating a map of the process from start to finish. In this scenario, trust boundaries exist between the employee requesting access, the approvers (both the direct manager and the federal approvals group), and the IT team that implements the changes. These boundaries are points where trust in the process is assumed but could be exploited.
Attacking the Process
During this stage, we invent and carry out attack scenarios to test the process's resilience. Let's consider the following possibilities:
- Spoofed Approval Emails:
In this process, approvals can be documented as a comment on the change request ticket from the required approvers or via an email attached to the ticket. What if someone were to spoof a fake email showing an approval that never actually happened? A malicious insider could forge an email chain that appears to show the necessary approvals, thereby tricking the system into granting unauthorized access.
- Compromised Manager Account:
What if a manager's account were compromised and used to request and approve access to a malicious account directly? This scenario could lead to unauthorized access being granted without the real manager's knowledge.
- Misuse of Managerial Authority:
What if a compromised manager's account was used to request and approve access for someone they don't manage? In this case, an attacker might exploit the managerial approval step to grant access to a colleague or external party without proper oversight.
While just a handful of examples, these attack scenarios highlight the importance of not only understanding the process but also recognizing where trust is placed—and where it might be vulnerable to exploitation. Are there checks in place to verify the authenticity of email approvals? Is there a system to ensure that a manager only approves access for employees they manage? Are there audit trails to detect anomalies in the approval process?
Rethinking Your Routine: Red Teaming Business Processes
The most impactful vulnerabilities in an organization may not lie in its technical defenses but in the trusted processes that operate behind the scenes. Applying a red teaming mindset against these business processes is essential to identify and address potential weaknesses before they can be exploited by malicious insiders or attackers.
As seen in recent real-life examples, implicit trust in "boring" processes is a luxury that organizations can no longer afford. It's time to bring these processes into the spotlight and subject them to the same rigorous testing as any other security control. Contact us today to start the conversation regarding how best to achieve your specific security goals.
About Jonathan Garella
Jonathan Garella is a Senior Penetration Tester at Schellman, specializing in identifying and exploiting vulnerabilities across diverse customer environments. His expertise extends to assessing websites, conducting social engineering campaigns, and maintaining persistence in macOS, Windows, and Linux systems while evading anti-virus detection.
Before joining Schellman in 2021, Jonathan served as a Security Engineer, focusing on incident response and remediation management in Managed Service Provider (MSP) environments. In this role, he led regular team training sessions on attacker tactics, techniques, and procedures, aiming to reduce the time between detection and containment during security incidents. Additionally, Jonathan contributed to threat modeling, Security Information and Event Management (SIEM) implementation and optimization, and the deployment and configuration of Endpoint protection solutions.