Red Teaming: A Critical Security Practice for Modern Cloud Driven Organizations

Red Teaming: A Critical Security Practice for Modern Cloud Driven Organizations

Introduction

For a digital healthtech platform like Halodoc, safeguarding sensitive data—such as patient records and personal health information—is critical to maintaining user trust and ensuring the platform remains secure and reliable. As organizations adopt cloud-native environments, their attack surfaces expand alongside the growing sophistication of threats. Adversaries increasingly exploit zero-day vulnerabilities, cloud misconfigurations, social engineering, and exposed internal systems to bypass traditional security controls—often evading standard detection tools, especially in dynamic and distributed cloud setups.

Red Teaming helps address this challenge by simulating realistic attack scenarios across the full kill chain—from initial access to data exfiltration. Unlike traditional penetration testing, red team exercises evaluate not only technical vulnerabilities but also the effectiveness of detection mechanisms, incident response processes, IAM configurations, and employee security awareness. For a healthtech company like Halodoc, these assessments are essential to continuously improve our ability to detect, respond to, and recover from real-world cyber threats.

Importance of Red Teaming for Modern Organizations

  • Real-World Attack Simulation: Red teams think like attackers, employing tactics such as phishing, social engineering, privilege escalation, lateral movement, and data exfiltration. This approach uncovers security gaps that automated tools or vulnerability scanners may overlook.
  • Testing Security Controls & Incident Response: Validates whether security controls (like EDR, SIEM, Firewalls, WAF) are configured correctly and functioning as intended. Tests how well blue teams (defenders) detect, respond, and recover from simulated attacks.
  • Identifying Human Factor Weaknesses: Exploits non-technical attack vectors such as phishing, social engineering, weak passwords, or untrained employees.
  • Building a Security-First Culture: Red team exercises help build security awareness throughout the organization and emphasise the importance of proactive defense. This fosters a collaborative approach to security, involving everyone across the organization.
  • Continuous Improvement: Post-engagement reports from red team exercises provide actionable insights for fixing security gaps and improving detection and response mechanisms.

Red Teaming vs. Traditional Security Testing

Technical Aspect

Traditional Security Testing

Red Teaming

Testing Goal

Discover and patch known vulnerabilities and misconfigurations

Emulate realtime attacks & tactics to assess detection & response

Attack Simulation

Limited to scanning, fuzzing, or isolated exploit attempts

Full kill chain simulation (recon, initial access, persistence, lateral movement, exfiltration)

Scope Coverage

Specific to applications, infrastructure, or components

Cross-domain (network, physical, social engineering, cloud, apps, identity)

Toolset

Nessus, Burp Suite, Nikto, OWASP ZAP, Checkmarx, Fortify

Cobalt Strike, Metasploit, Empire, BloodHound, custom scripts

Threat Emulation

Signature-based and vulnerability-ID based (e.g., CVEs)

TTP-based (mimics MITRE ATT&CK techniques)

Stealth/Detection

Transparent and cooperative with blue/engineering teams

Covert operations to bypass detection systems (EDR, SIEM, NDR)

Authentication Usage

Usually tests authenticated/unauthenticated paths without credential theft

May simulate stolen credentials, phishing, token abuse

Reporting Outcome

Focused on vulnerability lists, CVSS scores, patch recommendations

Focused on impact, detection gaps, response timing, and persistence resilience

Testing Frequency

Regular and often automated (CI/CD pipeline integrated)

Periodic, high-effort engagements (quarterly or annually)

Team Interaction

Security testers collaborate with developers/IT teams

Red vs. Blue (often no prior notice to defenders)

Phases of a Red Team exercise

Red Teaming is a structured, goal-driven exercise, following are the different phases in the red team exercise and what will be done during each phase,

Fig:Image Depicting different phases of a Red Team Exercise

Reconnaissance & Open-Source Intelligence (OSINT)

In any real world cyberattack, adversaries don’t begin with an exploit—they begin with obtaining information. In red teaming, this early stage is known as reconnaissance, and it often relies heavily on Open-Source Intelligence (OSINT) to gather publicly accessible data about the target. During this phase, red teams passively collect external information—such as exposed assets, employee details, leaked credentials, or cloud misconfigurations—to map the organization’s digital footprint and identify potential entry points, while carefully avoiding detection to emulate real-world attack behavior. Some commonly used techniques include,

Scenario 1

Subdomain Enumeration, Subdomains often expose development environments, Internal API endpoints, VPN portals, staging servers, and more.

Fig: Subdomain enumeration using amass & sample outputs

Scenario 2

GitHub Recon and Secret Discovery, is a common technique in red teaming where attackers analyze public GitHub repositories and commits to uncover sensitive information that may have been unintentionally exposed.

Fig: Information gathering from public repositories using trufflehog

Possible Findings:

  • AWS Access Keys in .env files
  • Slack tokens in README commits
  • Hardcoded secrets and internal URLs
  • Even developers’ personal repos can unintentionally leak sensitive info!

Scenario 3

Breached Credential Harvesting, in red teaming involves collecting previously leaked or exposed usernames and passwords associated with the target organization, often from past data breaches or public dumps.

Fig: Collecting leaked accounts & passwords from internet

Findings:

  • Reused passwords from old LinkedIn/Adobe/MyFitnessPal breaches
  • Password spraying usernames for VPN or email logins

Initial Access: Breaching the Perimeter

The initial access phase in a red teaming assessment involves gaining unauthorised entry into a target system or network by exploiting vulnerabilities, misconfigurations, or human errors, mimicking real-world attacker tactics. Common techniques include phishing, credential theft, exploiting unpatched software, or leveraging supply chain weaknesses. The red team aims to establish a foothold stealthily, bypassing security controls like firewalls or antivirus, while remaining undetected.

#

Tactic

Technique

Tools Used

MITRE ATT&CK

1

Phishing or Monitoring Alerts Fake Slack / Jenkins alerts targeting engineers

Credential Harvesting + Session Hijacking

Gophish, Evilginx2, Modlishka

T1566.001 – Spearphishing via Service

2

OIDC Session Hijack via Reverse ProxyStealing session cookies and tokens from AWS SSO / Google

MFA Bypass via Session Replay

Evilginx2, mitmproxy

T1556.004 – Token Manipulation

3

SSO Token Reuse / Credential StuffingUsing leaked credentials/ tokens from past breaches

Unauthorized Access via Reuse

HaveIBeenPwned, Dehashed, custom token scripts

T1110.003 – Credential Stuffing

4

Exposed Cloud Services / APIsMisconfigured S3, open VPC endpoints, exposed metadata

Anonymous Access to Internal Data

S3Scanner, nuclei, httpx, Burp, Postman

T1526 – Cloud Service Discovery

5

Dependency Confusion / Supply Chain AbuseInjecting malicious packages into CI/CD pipelines

Code Execution in Build Process

pypi-poison, custom NPM modules, Canarytokens

T1195.002 – Supply Chain Compromise

6

Forgotten SSO Apps / Shadow SaaS Active tokens tied to unused or misconfigured SaaS integrations

API Abuse via Stale Auth

Slack API, Gitlab, GraphQL API, jwt.io

T1528 – Steal Application Access Token

An Example Use Case Scenario:

An attacker sends a fake AWS GuardDuty alert through a cloned notification using Gophish. The link redirects to an Evilginx2-hosted AWS login page. A DevOps engineer logs in and completes MFA.

Sample Email:

Fig: Sample Phishing Email format in regards to above given example

Evilginx2 captures session cookies and AWS federation tokens, which are then injected into a browser session. The attacker gains console access without triggering MFA.

Lateral Movement in Cloud-Native Environments

In the lateral movement phase of a red teaming assessment, the red team, having gained initial access, navigates through the target network to expand their control and access additional systems, accounts, or resources. Techniques include exploiting stolen credentials, pass-the-hash attacks, abusing misconfigured permissions, or leveraging legitimate tools (e.g., PowerShell, WMI) to move stealthily across workstations, servers, or cloud environments. The goal is to escalate privileges, compromise high-value assets, and maintain persistence while evading detection by security controls like EDR or network monitoring. Several Lateral Movements can be,

Scenario 1

IAM Role Enumeration + Privilege Escalation: Once in the cloud console, the attacker might run tools like enumerate-iam to find misconfigured IAM roles that the compromised user can assume to elevate privileges. For example, the user could sts:AssumeRole into a HealthAppAdmin role with broader access to services like RDS, ECS, and CodeBuild.

Fig: Commands to enumerate aws roles with initial access

Scenario 2

Lambda → RDS → S3 Data Discovery: The attacker could use permissions inherited from the SRE role to access sensitive services. They may:

  • Invoke a Lambda function that has read access to an RDS database containing PHI.
  • Exfiltrate the data from RDS to an attacker-controlled S3 bucket.
  • Trigger the function through an API call or by modifying event sources the function is subscribed to.
Fig: Obtaining new services information from compromised credentials

Privilege Escalation and Access Expansion

In the privilege escalation phase of a red teaming engagement, the red team leverages the initially compromised information like cloud identity or access point to elevate permissions and gain broader control over the cloud environment. This involves identifying overly permissive IAM policies, trust relationships between roles, or exploitable service configurations, vulnerable application end points that allow access beyond the original scope.

Scenario

Developer Role to Cloud Admin via Privilege Escalation: Once initial access is gained using a low-privileged IAM user (e.g., a compromised DevUser), the attacker enumerates IAM policies and permissions using tools like enumerate-iam or native AWS CLI calls. They identify that DevUser has the iam:PassRole and lambda:CreateFunction permissions, which can be abused to escalate privileges. Then the red teamer will follow the following steps

  1. Creates a new Lambda function with an execution role tied to a high-privileged role like CloudAdminRole.
  2. The Lambda function is configured to run a payload that uses sts:GetCallerIdentity and other AWS CLI commands to confirm escalated access.
  3. The red teamer executes the Lambda, effectively inheriting the permissions of CloudAdminRole.

From here, the red team now has access to a wide range of services including EC2, S3, RDS, and KMS, enabling:

  • Secret retrieval from Secrets Manager or Parameter Store.
  • Modifications to VPC network configurations.
  • Snapshotting or exfiltrating EBS volumes or RDS databases.

This technique shows how combining regular looking permissions, when misconfigured can allow attackers to fully take control over a cloud environment.

Data Discovery & Exfiltration

In the data exfiltration phase, the red team simulates stealing sensitive data to demonstrate the impact of a breach. They identify and extract valuable information (e.g., intellectual property, customer data, or credentials) using methods like encrypted file transfers, tunneling through compromised systems, or cloud-based uploads to mimic real attacker behavior. The focus is on bypassing data loss prevention (DLP) systems and network monitoring while ensuring the data is extracted undetected, highlighting weaknesses in data protection and monitoring capabilities. Several Data Exfiltration techniques can be, 

Scenario 1

Dumping RDS or DynamoDB Data: Exfiltrate patient or transaction records via SQL or API query access using

  • aws dynamodb scan
  • Native DB clients (psql, mysql)
  • dbeaver (GUI access)
Fig: Extracting critical data through internal resources

Scenario 2

Leaking Kubernetes Secrets: If the attacker has access to the cluster or compromised pods, he can leverage it to use and extract critical Kubernetes secrets using,

  • kubectl
  • KubeHound
  • kubesecrets-dumper
Fig: Extracting critical data through internal resources

A Simulated Real-World Attack Scenario

As part of the red team engagement to assess the resilience of internal systems against realistic adversarial behavior, a comprehensive simulated attack was carried out covering multiple stages from reconnaissance through to exploitation. The objective was to emulate the tactics of a sophisticated threat actor or compromised user with limited access.

The engagement begins with an extensive Reconnaissance phase, where open-source intelligence was gathered from platforms like GitHub, Pastebin, and underground forums. During this phase, multiple types of data which are associated with any internal domain were discovered. Subdomain enumeration and passive scanning tools like Amass and Subfinder helped to map out accessible infrastructure. Through endpoint enumeration, traffic monitoring, and API inspection, several internal services were discovered.

During the Initial Access phase, the internal endpoints and APIs which were identified during the previous phase, included a PUT request that accepted user-specific identifiers in the URI path. This endpoint became a key focus for further testing. The red team manipulated the object references in the URI path of the PUT request, simulating an Insecure Direct Object Reference (IDOR) vulnerability.

By changing a user ID from /resource/1001/update to /resource/1005/update, they were able to access data linked to another user without triggering any authorization checks. This lack of access control led to a successful lateral movement, where the red team accessed privileged configuration data from another user. Combined with session persistence, this enabled further pivoting into more sensitive areas of the environment. This could lead to privilege escalation, unauthorised data access, and full compromise of internal systems without ever needing to exploit traditional vulnerabilities like RCE or authentication bypass.

Fig: Image depicting the process of the simulated Real-World Attack Scenario

The attack simulation successfully proved that insufficient server-side authorization could enable a malicious actor, or a compromised internal user to escalate privileges or gain access to sensitive system data without triggering alerts or error responses. Such behavior, left unchecked, could lead to data breaches or system compromise.

Conclusion 

Red Teaming provides a realistic evaluation of an organization’s ability to detect, respond to, and recover from advanced threats. It enables security and engineering teams to proactively bridge the gap between being “secure on paper” and “secure in practice” before real adversaries exploit it.

At Halodoc, the recent red team exercise targeting our public-facing systems offered valuable insights into our security posture. While many threats were mitigated by our existing defenses—such as a robust Web Application Firewall (WAF), enhanced application security practices, and multi-layered perimeter monitoring—there were a few areas identified where potential risks could arise, including unauthorized access, privilege escalation, and data exposure.

This exercise reinforced the value of regular Red Team assessments. By conducting these exercises periodically, we can better identify potential blind spots, validate our security assumptions, and continuously improve our defenses against evolving threats.

References

  • https://github.com/BloodHoundAD/BloodHound
  • https://osintframework.com/
  • https://attack.mitre.org

Bug Bounty 

Got what it takes to hack? Feel free to report a vulnerability in our assets and get yourself a reward through our bug bounty program. Find more details about policy and guidelines at https://www.halodoc.com/security

Join Us

Scalability, reliability and maintainability are the three pillars that govern what we build at Halodoc Tech. We are actively looking for engineers at all levels and if solving hard problems with challenging requirements is your forte, please reach out to us with your resumé at careers.india@halodoc.com

About Halodoc 

Halodoc is the number one all-around healthcare application in Indonesia. Our mission is to simplify and deliver quality healthcare across Indonesia, from Sabang to Merauke. Since 2016, Halodoc has been improving health literacy in Indonesia by providing user-friendly healthcare communication, education, and information (KIE). In parallel, our ecosystem has expanded to offer a range of services that facilitate convenient access to healthcare, starting with Homecare by Halodoc as a preventive care feature that allows users to conduct health tests privately and securely from the comfort of their homes; My Insurance, which allows users to access the benefits of cashless outpatient services in a more seamless way; Chat with Doctor, which allows users to consult with over 20,000 licensed physicians via chat, video or voice call; and Health Store features that allow users to purchase medicines, supplements and various health products from our network of over 4,900 trusted partner pharmacies. To deliver holistic health solutions in a fully digital way, Halodoc offers Digital Clinic services including Haloskin, a trusted dermatology care platform guided by experienced dermatologists.We are proud to be trusted by global and regional investors, including the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, GoJek, Astra, Temasek, and many more. With over USD 100 million raised to date, including our recent Series D, our team is committed to building the best personalized healthcare solutions — and we remain steadfast in our journey to simplify healthcare for all Indonesians.