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,
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.
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.
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.
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:
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.
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.
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
- Creates a new Lambda function with an execution role tied to a high-privileged role like CloudAdminRole.
- The Lambda function is configured to run a payload that uses sts:GetCallerIdentity and other AWS CLI commands to confirm escalated access.
- 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)
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
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.
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.