I Tracked Down The Hacker Behind a Magento PolyShell Attack. Here's What They Told Me.

A conversation I probably should not have had. But did anyway — and what came out of it should be required reading for anyone running Magento.

It started with a name inside the code

I was reverse-engineering a PolyShell variant — reading through the files it drops, tracing the logic, mapping what it was actually trying to do. Standard forensic work.

Then I hit a variable name that stopped me. Then a credit — hackers embed their calling card in the tools they write, a "Coded by" or a greets line with their handle, their crew, sometimes their country. Then a function name written in a way that isn’t how English speakers write things.

The patterns were unmistakably Indonesian — a specific cadence, a specific shorthand that you only recognise if you know it.

I’m Indonesian. I know it.

That changed things. This wasn’t an anonymous blob of obfuscated script. There was a person on the other side, and they had left traces of themselves in the code. I kept reading. The breadcrumbs pointed to a site. The site pointed to Telegram.

I sent a message — blunt, in Indonesian:

This post is a summary of a real conversation, reviewed and verified by one of the threat actors behind PolyShell. How we communicate beyond the initial Telegram contact is anonymous and will not be disclosed. The information shared here is intended strictly for educational purposes — to help Magento merchants and developers understand how these attacks work and how to defend against them.

A word before the interview

During the conversation, they described themselves as curious — in it for the rank, not the money. They said they draw a line at the destructive stuff. We’re giving them the benefit of the doubt on that, and publishing accordingly.

But here’s what we also know: anyone can say they’re the curious kind. The tools, the CVE lists, the automated bots — they’re the same whether someone is chasing a leaderboard or dropping a skimmer on your checkout. Intent doesn’t change the exposure. So read this for the technique, not the character reference.

With that said — here is what they had to say.

The conversation

No Magento knowledge. No coding skills. A public CVE post and an AI assistant. That is the full development stack for the attack.

There are leaderboards for this. Whole communities built around who breaches the most notable targets. Zone-H — a public defacement archive that has been running since the early 2000s — is where findings get posted as proof, like a trophy wall. If your domain appears there, it is public record.

No list. No research into who you are. A range of IPs, a payload, and whatever responds. Tools like Shodan — a search engine for internet-connected devices — make this even easier: search for a specific software signature and it hands you a list of every exposed instance on the public internet. The spray doesn’t even need to be blind.

Your web server is a security control. NGINX with a tight config blocks full remote code execution on the exact payload that walks straight through Apache + cPanel. This is not a minor configuration preference — it is the difference between a nuisance and a total site compromise.

Who’s on the list — and yes, Google is there

Right. Hypernode ships with Sansec baked in — the best-known first-alert name in Magento security.

That last category is the one that should keep Magento merchants up at night. A ransomware attack announces itself. A checkout-API swap does the opposite — it leaves your store running perfectly, orders processing normally, while quietly routing every card number through a third-party server. You might not know for weeks. Your customers won’t know at all.

Whether the person that finds you is the curious kind or the destructive kind — the entry point is the same. The only thing that changes is what happens after they get in.

Apache + cPanel + Magento: how bad is it?

One agency site, fully compromised. Then more. Not hypotheticals — active findings with evidence. The combination of Apache, cPanel, and an unpatched Magento CVE is not a worst-case scenario for them. It is a routine outcome.

On WAFs: some good, most just expensive regex

The free tier of most WAFs is signature matching. It gets bypassed by anyone who has looked up the bypass list — which is public, maintained, and circulated in exactly the communities this person runs in. Awesome-WAF on GitHub is one such list: a comprehensive, community-maintained collection of WAF fingerprints and bypass techniques for virtually every major vendor.

crt.sh is a public certificate transparency log — every SSL certificate ever issued for your domain is listed there, including historical ones pointing to your old origin IPs before you moved behind a proxy. Combined with reverse DNS lookups, it can walk an attacker straight back to your server.

Lock your origin firewall to your CDN’s IP ranges only. And don’t underestimate what crt.sh and old DNS records reveal — they are a historical map to your real address.

How the attacks actually happen

IDOR in plain terms: if I can access /api/order/1001, I try /api/order/1002. If the server hands it over without checking whether I’m allowed to see it, I can walk the entire order history. Not a sophisticated attack — just trying the obvious thing. Tools like ffuf automate this at scale — fuzzing thousands of endpoint patterns in seconds to find the ones that shouldn’t exist.

The “no open ports” point pairs with nmap — the standard tool for port scanning. Before launching an API attack, a reconnaissance pass with nmap maps every open port on a server. Every unnecessary open port is a door that was already found before you even knew someone was looking.

Whether Google’s security team received it, triaged it, filed it, or it went into a blackhole — we don’t know. The claim is documented, the finding was reportedly sent, and the response was silence.

The agency story — and why the original target doesn’t matter

One agency WordPress site breached. We know their cPanel. We got their entire client list — and all those clients are compromised too. The original target didn’t even matter.

The agency was the skeleton key. Every client they managed, every site behind them — all of it from one WordPress install. And combine that with Google dorking from a single known breach. This alone will wreck havoc big time.

How I ended the call

I told them the truth:

Yeah. We can start tomorrow.

We didn’t continue. The StoreFrame team decided to learn on our own terms instead — Vibehacking. COK: Claude on Kali.

What to actually do with this

The scary part of this story isn’t a genius adversary. It’s the opposite. An automated bot, built with AI by someone who openly can’t code, pointed at a fresh public CVE, sprayed at the entire internet. You don’t get targeted. You get found.

“We’re too small to be a target” is not a defense. Being small just means you’re in the spray radius alongside Heineken, Samsung, and Google’s merch store. The spray doesn’t care about your revenue.

The actual defense is boring and it works: no Apache + cPanel, close your ports, protect your sensitive files, lock your origin to your CDN, patch CVEs fast, and keep an eye on Zone-H for your own domain.

And remember — whether the hacker that finds you is the curious kind or the destructive kind, you won’t know in advance. Build as if it’s the latter.

If you’re running Magento on Apache with cPanel and haven’t patched recent CVEs — this is your warning. It is not a matter of if. The spray is always running.

What this actually means for your Magento store

Run NGINX. This is not a brand preference — it is a structural advantage. Apache is not inherently insecure, but a correctly hardened Apache config is genuinely rare. Most Apache installs in the wild carry default settings that well-known payloads walk straight through. NGINX with a tight config eliminates entire classes of attack before a single line of PHP ever runs.

If you are running Magento on cPanel + Apache, that is not just a configuration risk — it is a shared blast radius. cPanel hosts multiple sites under the same environment. Compromise one, and everything else in that cPanel is exposed. Attackers know this. They target cPanel specifically because a single entry point pays off across every site on the account.

Sansec and Hypernode are genuinely among the best in the business — both for Magento hosting and eCommerce security. That is not a referral. It is what the attacker said, unprompted, when asked directly. When someone actively trying to breach Magento stores tells you a platform is secured, that endorsement carries more weight than any marketing page.

The dominant attack vector is API-based — and AI is making it cheaper by the day. Attackers are no longer writing exploits from scratch. They are prompting AI to do it. The gap between a CVE disclosure and a working automated exploit is now measured in hours, not weeks.

A Magento CVE with a high CVSS score is not just a patch notice — it is a starting gun. The higher the score, the more attractive the target. Hackers triage CVE lists the same way security teams do, and they move faster. Expect a working exploit within hours of a critical disclosure. Expect it to be automated and sprayed at scale within days. Once a store is breached, a webshell is persistent by design — it survives cache flushes, deployments, even server reboots. Getting rid of it cleanly is genuinely hard. Patching fast is not optional hygiene. It is the only window you have.