Key facts
- Organisation
- Philippine energy firm
- Threat
- ClickFix social engineering, delivered through the organisation's own compromised website
- Initial access
- Stolen content management system administrator credential; no multi-factor authentication in place
- Impact
- Over 20 devices reached the lure; three staff executed the command, and every execution was blocked; more than 250 credentials were later stolen from one administrator's browser
- Core issue
- A single browser held the credentials to the website, the hosting account and every tool required to contain the incident
What this case shows
- An organisation's own website is an attack surface pointed directly at its own staff, and it sits outside the network most security investments protect.
- Blocking an execution is not the same as containing an incident: the credential theft that followed was the material loss, and it happened on a device no sensor was watching.
- Evidence expires. Web logs, endpoint telemetry and re-imaged disks removed the answers to several questions within days of the incident.
If an administrator credential were stolen today, the answer would come from the evidence you retained. Blackpanda runs Compromise Assessment and Emergency Incident Response across Asia.
What this would have cost without Blackpanda IR-1 in place
| ODIR | IR-1 | |
|---|---|---|
| Type of engagement | On-demand incident response | Yearly subscription |
| Hours covered | 45 hours | Unlimited* |
| Pricing1 | USD $22,500 | USD $2,250 |
* Unlimited for one incident per year
1 Ad-hoc incident response pricing based on average market rates, from USD 500 per hour. Blackpanda IR-1 subscription pricing based on no. of endpoints, costing approx. 10x less than ad-hoc and retainer-based incident response. All figures are illustrative only, for guidance and marketing purposes and not to be relied upon by the reader. Actual incident response costs vary by scope, complexity, and provider.
CHALLENGE
A Philippine energy firm operated two public websites from a single shared hosting account: a corporate site and a separate marketing site built on a content management system. Both were hosted externally, neither connected to any internal system, and administrators signed in to the content management system with a password alone. No second factor was enforced.
In August 2026, staff who opened their employer's own website were redirected within seconds to a counterfeit verification page imitating the security check of a well-known content delivery provider. The page did not exploit the browser. Instead, it instructed the visitor to open a terminal and paste a command, so that the victim installed the malware on the attacker's behalf. This technique, reported publicly as ClickFix, inverts the usual assumption that a compromised website attacks the people who visit it; here, the website recruited them.
Three staff complied. The organisation's endpoint detection platform blocked every launch before anything downloaded, and its external security operations provider raised the incident the same morning. However, the exposure was considerably wider than the three executions suggested: more than 10 managed hosts and around 10 unmanaged devices reached the lure server that day, over 20 devices in total. The first device to reach it carried no sensor at all, and did so 13 minutes before any monitored machine.
What the organisation could not see at that point was the layer underneath. The injected script carried no destination address of its own, which meant the threat actor could redirect every subsequent visitor without touching the website again. Two days after the lure was removed, more than 250 credentials saved in the browser of the compromised administrator account surfaced in an infostealer log, among them the logins to the website, the hosting account, the endpoint detection console, the firewall dashboards and the secure access platform.
Blackpanda was engaged under IR-1 to establish what had happened, what had run, and what had been taken.
SOLUTION
1. Established the root cause from the surviving database evidence
Because the request-level web logs for the intrusion window had not been retained by the hosting provider, the usual record of the compromise did not exist. Blackpanda therefore reconstructed initial access from the session tokens preserved in the content management system's own database, including a clone of the site taken while the lure was still live. Six unauthorised administrator sessions were recovered, all originating from a single overseas hosting provider that appears nowhere in the organisation's records, four of them arriving within two seconds of one another from addresses in three countries.
That pattern is automated, not human: it is consistent with a tool validating a password the threat actor already held. Consequently, a software exploit was ruled out as the entry route, and the compromised credential was established as the root cause.
2. Reconstructed the delivery chain record by record
Blackpanda traced the path from the website to the lure across network and endpoint records for every device that executed the command. In each case the company website loaded, blockchain services were queried, and the lure server was reached, all inside seven seconds. On one laptop the lure request survived on disk with the company website recorded as its originating page, which placed the injection on the site itself rather than on any intermediary.
The blockchain lookups explained the behaviour the organisation had found hardest to interpret. The script retrieved its destination from a public ledger at the moment of each visit, a dead-drop technique that let the threat actor change the lure address at will while the website itself stayed untouched.
3. Scoped the endpoint exposure and triaged what could still be examined
Every device that reached the lure was enumerated across the detection platform and the network logs, then separated into monitored and unmonitored populations, because the two carry entirely different degrees of certainty. Two further laptops were triaged offline: both had loaded the lure, neither had executed anything, and no payload, persistence, unexplained program execution, account change or log clearing was found on either.
Although the three executing laptops had been re-imaged before Blackpanda arrived and their telemetry had expired, the detection record for the entire fleet was reviewed forward from the incident. No incident-related detection has occurred since.
4. Mapped the credential exposure and the second compromise
Dark web monitoring identified the infostealer log holding the administrator's saved passwords, dated two days after the lure was removed, and established that neither the website nor the hosting credential appeared in any source before that date. Crucially, this ordering matters: the theft followed the intrusion and therefore cannot explain it.
The same work surfaced a separate compromise of the same hosting account a week later, in which a self-deleting mail relay ran on the corporate site. One unexecuted copy was captured intact, read-only, before removal.
RESULTS
1. The root cause was established, and the exploit theory closed
Initial access was a compromised administrator credential used from anonymising infrastructure, with no multi-factor authentication to stop it. No software exploit was supported by the evidence.
2. The execution outcome was confirmed on every monitored device
All command executions were blocked before any download, and no incident-related detection has occurred on any managed host since the day of the incident.
3. The credential exposure was quantified and sequenced
More than 250 stolen credentials were recovered from a single administrator's browser, spanning the website, the hosting account, and the security tooling the organisation would need to contain the incident. The theft was dated after the intrusion, which removed it as a candidate root cause.
4. A second, separate compromise was identified and contained
A mail relay running from the shared hosting account was found, captured and removed, along with the finding that one credential governed both public websites.
5. The limits of the evidence were stated rather than papered over
Several questions remain open and were reported as such: how the administrator password was first obtained, which device leaked the saved credentials, whether the second compromise used the stolen hosting login or another route, and whether data held in the site database was viewed. Each depends on evidence that had already expired or was never retained.
The pattern underneath this incident is not the social engineering, which worked on three people out of more than 20 exposed. It is that a public website, hosted outside the network and governed by one password, was able to reach every staff device that opened it, while the credentials capable of containing the resulting incident sat in the same browser as the credential that caused it. Separating those two things, enforcing a second factor on every administrative login, retaining web logs off the web server, and extending endpoint coverage to every device on the office network are all decisions available before an incident, and all unavailable after one.
FREQUENTLY ASKED QUESTIONS
1. How can our own website be used to attack our own staff?
A public website is an attack surface pointed at everyone who opens it, including employees, and it usually sits outside the network perimeter most security spending protects. In this case the threat actor did not need to breach the corporate network at all; they changed what the website served and waited. Staff trusted the page because it was their employer's own domain, which is precisely what made the instruction to run a command persuasive.
2. Our endpoint security blocked the attack. Does that mean we were fine?
No. Blocking an execution prevents one outcome; it does not establish what else happened, and it offers no visibility into devices the agent is not installed on. In this case around 10 unmanaged devices reached the same lure and nothing can be said about what occurred on them, while the material loss, a browser full of administrative credentials, happened on a device that had stopped reporting. A block is a starting point for an investigation, not a conclusion.
3. Why could the investigation not simply recover the malicious code?
The organisation's own staff deleted the offending component through the hosting file manager on the afternoon of the incident, before any forensic copy was taken. That instinct is understandable and it did stop the attack, but it also removed the single artefact that would have confirmed the mechanism and revealed the campaign's wider infrastructure. Where an incident is still unfolding, preserving a copy before deleting costs minutes and preserves the entire investigation. Blackpanda's Emergency Incident Response team can direct that preservation remotely within the hour.
4. How long do we actually have before the evidence disappears?
Days, in most environments, and often less than that. In this investigation the request-level web logs were never archived, the endpoint telemetry for the incident window had expired within a week, and the three machines that mattered most had been re-imaged before triage began. Retaining web logs off the web server for at least 90 days, and isolating rather than re-imaging an affected device, are the two decisions that most reliably preserve the answers.
5. Should a compromised website be rebuilt or cleaned?
Rebuild from clean sources and migrate content, unless every remaining component can be checksum-compared against its released version. This kind of compromise conceals itself from logged-in administrators, so a site that looks clean from the inside can still be serving a lure to visitors, and a clean review of what remains cannot prove that no second injection point existed. The same reasoning applied when attackers hijacked a Hong Kong law firm's website and Blackpanda responded within hours.
WHAT THIS MEANS FOR YOUR ORGANISATION
Most organisations treat the corporate website as a marketing asset and the corporate network as the security problem. This case shows how little that distinction survives contact with an incident. One externally hosted site, governed by a single password with no second factor, redirected more than 20 of the organisation's own devices in a single morning, and the hosting account behind it governed a second website as well. Nothing about that arrangement was unusual, which is the point; it is the default configuration at a great many mid-market and listed companies.
Two decisions change the outcome, and both can be implemented immediately. Enforce multi-factor authentication on every administrative login, website and hosting account included, and stop administrators from saving credentials in a browser — one infected workstation should never be able to hand over the console that contains the incident. Ultimately, whether an incident leaves behind clear answers or unresolved questions depends on having an investigation team ready to act before crucial evidence vanishes. IR-1 exists for that window: a response team already engaged, already familiar with the environment, reachable the morning the alert fires rather than a week later.
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.







