Cloud Control-Plane Access Bypasses Existing Endpoint Security at a Singapore Education Institution

‍

CHALLENGE

The education institution operated its administrative and student portal publicly on the internet. Hosted on major cloud infrastructure, the portal relied on an enterprise business application suite that handled sensitive functions, including admissions, enrolment, payroll, and academic records. However, this software was several versions behind the vendor's supported, patchable releases. Consequently, an unauthenticated vulnerability in the portal permitted any external user to trigger server-side web requests and view the returned data. Although the software vendor had released a fix three years prior, it was never backported to the legacy version deployed by the institution.

A threat actor discovered this vulnerability in May 2026, executing a rapid sequence of actions over less than 40 minutes. The attacker scanned the host's internal ports, discovered the management portal, and executed a known exploitation path aimed at gaining full administrative control — attempting login bypasses, default credentials, and reading the local encryption file. These initial attempts failed due to a custom directory structure that displaced the target encryption file from its standard location, preventing the installation of a web shell.

Pivoting tactics, the attacker exploited the same vulnerability against the cloud platform's internal instance metadata and credential service, which implicitly trusted all requests originating from the local host. The service returned a list of assigned identities and released an active credential set. Within two minutes, the compromised cloud credentials were leveraged against the organisation's cloud environment, followed by the acquisition of a second identity the next day. Crucially, both identities possessed elevated permissions enabling remote command execution across every server in the cloud tenant.

Although automated cloud threat-detection systems triggered alerts on both days, leading to an investigation alongside a third-party security provider, remediation efforts remained incomplete. While the excessive permissions were revoked from one compromised identity, the second identity retained its elevated privileges, active session tokens were not invalidated, and the underlying vector used to extract the credentials went unidentified. Over the subsequent weeks, the attacker repeatedly leveraged this unpatched pathway to collect more than 10 additional sets of credentials from the metadata service.

Nearly a month later, the threat actor re-engaged the environment without needing to exploit any software flaw. The breach was uncovered only after unauthorised administrative commands began executing across production servers — nearly an hour after the attacker had already re-established active control.

‍

SOLUTION

1. Built one timeline out of host, cloud and network evidence

Blackpanda took forensic images and triage collections from the affected servers, then went after the cloud account's own memory of events: the audit log, the threat-detection findings, the remote-execution history and the load-balancer access logs. Those were correlated with the institution's endpoint and log-management telemetry into a single sequence. The exercise recovered over 600 of the attacker's commands, including the text of what each one had been instructed to do, which is the difference between knowing an intrusion happened and knowing what it was for.

2. Traced the root cause to the cloud control plane, not the servers

The attacker operated through a distinct mechanism rather than traditional code execution on these servers. Holding a compromised cloud identity with permissions to register standing instructions, the attacker relied on the cloud platform itself to execute commands as administrator across all managed machines. This structural distinction clarifies the central paradox of the incident: when the institution's endpoint agent terminated all seven initial adversary sessions within 90 seconds, it had no lasting effect. Because the delivery channel operated within an unmonitored layer invisible to the agent, every newly issued instruction executed with full administrative privileges. Uncovering this architecture fundamentally altered the remediation strategy, shifting focus from individual servers directly to the cloud account.

3. Mapped the persistence, including a web shell inside the live portal

To ensure that evicting any single mechanism would fail to restore security, four distinct routes back to administrative control were established on every server: an altered remote-access setup, hidden administrative keys, a system service, and three scheduled tasks disguised as routine maintenance. Proof of system tampering emerged from a privileged copy of the system shell that had been back-dated by two years to blend in with the base operating system. Identical timestamps down to the second were uncovered across all eight affected servers.

An additional persistence mechanism was embedded within the production portal application itself. Upon recovery and decompilation by Blackpanda, it proved to be a search-engine cloaking utility — designed to retrieve external content and present it to crawlers — rather than a fully featured backdoor. While its local activity log contained no entries (confirming the tool's presence without proving active execution), its deployment location was critical. Configured across all application endpoints, this web shell executed prior to processing incoming portal requests, placing adversary code ahead of every public visitor. The component remained present when servers were seized, actively running on one instance.

4. Defined the scope of the data inquiry strictly by the extent of the available evidence

Because web-request logging on the portal had never been activated, every log file across the system was zero bytes — a pre-existing configuration gap that left no application-layer record of requests for either breach. Instead of glossing over this limitation, Blackpanda clearly detailed what the remaining evidence proves, what it disproves, and the single open question that remains unresolved. This question is explicitly addressed both in the findings below and within the full report.

‍

RESULTS

1. Root cause established for both intrusions

Initial intrusion leveraged an unauthenticated vulnerability within the public-facing portal to query the cloud environment's credential service. Conversely, the second intrusion bypassed exploitation entirely, relying solely on extracting credentials from an accessible service paired with an identity that retained elevated permissions.

2. The two intrusions linked, with the limits stated

While shared infrastructure and the attacker's clear familiarity with the environment link the two incident waves, the second wave shows no sign of the original entry address. Consequently, attributing both intrusions to a single operator remains an inference rather than an established fact, as highlighted in the report.

3. Scope corrected from seven servers to nearly 40

The attack scope was significantly broader than initial estimates: remote execution commands were dispatched to nearly 40 systems, succeeding on over 20. An additional subset of endpoints received scheduled tasks and administrator keys without undergoing on-host investigation, requiring full remediation and verification before restoration. Furthermore, the payload failed on ten additional targeted machines solely due to operating system incompatibility.

4. No evidence that student or staff records left, and one gap that stays open

Out of more than 600 recovered commands, none targeted or referenced students, personnel, academics, enrolment, or payroll. Database export tools were absent, and fewer than ten database statements were executed in total, with none involving bulk queries.

However, a specific data transfer remains unexplained: an internal relay configured by the attacker extracted approximately 10 MB of responses from a portal server across a 90-minute window, flowing in payload sizes indicative of paginated query results. Because the required logging mechanisms were never enabled, it is impossible to determine whether this traffic comprised personal data or standard portal output.

5. Redefining eradication as control-plane remediation

Resolving this credential compromise required actions beyond server-level clean-up. Blackpanda outlined the steps necessary to fully neutralise the threat: invalidate all credentials and active sessions connected to the compromised identities, strip remote-execution privileges from all instance identities while uncoupling shared ones, mandate the use of the authenticated credential service version, and wipe the attacker's persistent instructions prior to returning any server to production. This matches patterns observed in similar credential compromise cases, where access persists until explicit revocation occurs.

The key lesson lies in the 30-day window between the two intrusion events, during which the organisation assumed the issue was fully resolved. Although detection and initial investigative efforts succeeded, and a permission was removed, the attacker maintained access because remediation was confined to the servers while the underlying credentials resided within the cloud account. To mitigate this risk proactively, organisations managing production workloads in the cloud should restrict unauthenticated reads on credential services, remove remote-execution capabilities from server-assigned identities, and ensure incident remediation is validated within the cloud control plane.

‍

FREQUENTLY ASKED QUESTIONS

1. The first intrusion was detected and investigated. How did the attacker get back in?

Although two cloud identities were breached, remediation addressed only one. The unaddressed identity retained permissions for remote command execution, and its active session tokens remained unrevoked. Because the mechanism used to extract the credentials went unidentified, the attack vector remained fully accessible for the threat actor to exploit again.

2. Our endpoint security is well regarded. Why did it not stop this?

The endpoint security agent performed exactly as designed, terminating the adversary's active sessions across all seven servers in roughly 90 seconds. However, the attacker was issuing instructions via the cloud provider's remote administration service, which functions above the server level. Lacking visibility into this external channel, the endpoint agent could not prevent subsequent commands from executing, irrespective of previous process terminations. Completely halting the activity required revoking the compromised credential and its associated privileges directly within the cloud account.

3. Was student or staff data stolen?

While no evidence suggests that records were exfiltrated, this remains an unresolved question rather than a definitive negative. The recovered attacker commands exclusively focused on harvesting credentials and securing system access, rather than targeting data. Additionally, no data export tools were identified across the environment, and the records tier showed zero contact with the adversary's infrastructure. However, a specific outbound data transfer of approximately 10 MB from a portal server could not be definitively analysed, as web-request logging for the application had never been configured.

4. What is a cloud credential service, and why did it matter so much here?

Cloud infrastructure assigns unique identities to individual servers, utilising a localised internal service to issue temporary access credentials upon request. Under its unauthenticated default configuration, this service satisfies any query originating from the host machine without validating the requestor. This vulnerability enabled a web application flaw to expose host-level cloud credentials.

By contrast, enforcing the authenticated implementation of the service mandates a specific request format that this vulnerability type cannot generate, effectively neutralising the attack path prior to credential retrieval.

5. Our core system is old but stable. Is running an unsupported version really the problem?

Running unsupported software fundamentally restricts your strategic choices. Although the vendor resolved this vulnerability three years prior to the breach, the fix was never made available for the legacy release in use, leaving no applicable patch. Consequently, routine patch management escalates into an architectural challenge, forcing a choice between implementing compensating security controls or executing a full system migration. This exact scenario unfolded previously with an unpatched, internet-facing mail server at a Hong Kong investment firm.

6. What should change in how we close out an incident?

Treat incident closure as an account-level cloud requirement rather than a server-rebuild process. Key steps include:

• Credential Revocation: Rotate all credentials accessible to the attacker.
• Permission Removal: Strip the permissions that enabled lateral movement and execution.
• Service Hardening: Enforce the hardened, authenticated version of the cloud credential service.
• Orchestration Cleanup: Purge any persistent orchestration objects deployed by the threat actor.
• Independent Sign-off: Require independent verification and sign-off separate from host restoration.

For prior incidents closed without these control-plane verification steps, a Compromise Assessment provides the necessary visibility to identify lingering exposure.

WHAT THIS MEANS FOR YOUR ORGANISATION

Conventional incident response often focuses on server-level containment and remediation. However, as this case demonstrates, relying solely on host-based clean-up introduces severe blind spots. Because the threat actor obtained cloud credentials trusted by the platform alongside permissions to dispatch elevated commands, they maintained full administrative reach without needing a persistent host footprint. Rebuilding servers left the underlying cloud access intact, enabling the adversary to retain control while the incident was presumed resolved.

To protect cloud-hosted production environments effectively, organisations must refine their operational priorities:

• Prioritise Identity Protection: Treat cloud credentials as primary assets requiring protection above individual host infrastructure.
• Mandate Control-Plane Remediation: Ensure incident closure protocols enforce credential revocation, privilege stripping, and the removal of malicious orchestration objects before restoring host systems.

For environments closed out without control-plane verification, a Compromise Assessment can identify lingering exposure. Organisations seeking proactive preparedness can establish immediate incident response capability through an IR-1 assurance subscription.

‍

ABOUT BLACKPANDA

Blackpanda is Asia's leading cyber incident response company, delivering digital emergency response across three integrated channels: IR consulting, IR-1 assurance subscriptions, and Lloyd's of London-underwritten cyber insurance. Each is purpose-built for a different buyer, whether enterprise, mass market, or sophisticated risk-transfer clients, and each stands alone as full incident response. Together, these channels reach the entire commercial market, because our mission is to provide digital emergency response for everyone. Buy all three and they combine into the complete post-attack recovery solution: preparation in advance, response the moment you're hit, and financial recovery paid for by insurance. One local team to help you get ready, respond, and recover.