- Huntress found an attacker compromised three web servers on a recreation management platform by registering an account and abusing the member file upload function.
- The attacker came back after one server returned to service too soon, and planted a trojan in the login page. Cleanup is not the same as closing the hole.
- Ask vendors what file types users can upload, where those files can run, and who confirms a cleaned server is safe before it returns to service.
The hardest door was not the one that opened
Security budgets tend to go toward the walls: firewalls, login protections, filters. A Huntress investigation published on September 30 shows that perimeter defenses do not help when a normal feature is the weak point.
Huntress observed an attacker spend roughly six hours throwing exploit techniques at a web server running a recreation management platform for municipalities, parks and recreation groups. Every access attempt failed. What worked was the front door. The attacker registered a new account and uploaded files.
The lesson here is that a feature meant for ordinary users can matter more than a flaw that needs expertise. Any feature that lets the public put files on your server deserves the scrutiny you give your login page.
How the upload trick works
A webshell is a small script placed on a web server. The attacker visits it in a browser and uses it to run commands on the machine. It turns a website into a remote control.
Huntress says the platform let a newly registered member upload files into a documents folder called /documents/MemberFiles/. The attacker uploaded 14 files there, in .aspx, .jpg and .pdf formats. The .jpg and .pdf files were a test to see whether uploaded files would run. Only the .aspx files were used to run commands.
That is the core flaw: a folder meant to hold member documents could also run code. The report does not describe a patch or a vendor fix.
What the attacker wanted: payment data
Once the shells worked, the attacker mapped the server. They used standard Windows and IIS administration tools to list sites and settings. IIS is Microsoft's web server software.
They then searched configuration files such as web.config and applicationHost.config for database credentials and keys. With SQL credentials in hand, Huntress says the motive became clear: card data. The attacker searched for terms like card numbers, CVV codes and expiry dates. They also went after logs from a Fortis payment webhook integration, a feed of payment events.
Huntress describes attempts to read those logs and extract card details. The report does not give a count of cards or people affected.
Cleaned is not the same as closed
The attacker adapted. On the second server they made less noise and were removed by the Huntress SOC. On the third, they copied and renamed five webshells to look like legitimate files. They also used timestomping, which rewrites file dates so new files look as old as the rest of the site.
Then came the part that matters most to an executive. Huntress says the third server went back into live use before it was fully secured. The attacker came back using the account they had registered earlier.
First they tried to call their old webshells, which had been removed. Then they uploaded new ones. Next they added code to a jQuery file loaded by the authentication page, /auth/default.aspx. Huntress says the plan was to make each browser that loaded that page connect to infrastructure the attacker controlled, and to collect credentials in real time.
Huntress says the aim was to harvest credentials from anyone who logged in, so the people exposed were the platform's users. The report does not say how many, if any, were captured.
The AI question, kept in proportion
Huntress says it suspects AI-generated scripts across the attack. It points to the large volume of failed early probes and to PowerShell scripts with extensive comments that include fragments of instructions, such as "append only - do not rewrite head/structure".
This is Huntress's suspicion, not a confirmed finding. The noisy early probing failed. The successful route was a manual one: making an account and finding the upload flaw.
Huntress also says user-agent strings suggest the attacker is based in China. It describes this as a deduction from a Simplified Chinese locale setting.
What to ask your team and vendors
This was a shared platform with multiple tenants, so the weak point sat in software many organisations rely on. Huntress observed three servers compromised and does not say how many others were affected.
Questions worth asking:
First, what can a newly registered user upload, and can anything in that folder be executed? Second, does your vendor treat self-registration as a trust boundary? Third, do payment logs or configuration files hold card data or database credentials that a web process can read? Fourth, who must sign off before a cleaned server returns to service, and does that check include accounts the attacker created?
A cleaned server with the attacker's account still active has only had the intruder removed. The way in is still there. Closing the hole matters more than removing the intruder.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Huntress.
