APTs actively targeting small businesses in their Security Blindspot. Ongoing scanning and compromise campaign active now.

Jul 16
4 min read

Updated: Jul 18

On the 9th of July, the Australian Cyber Security Centre (ACSC) issued a critical alert about a large-scale APT campaign exploiting known vulnerabilities in website content-management systems (CMS) and their plugins. The campaign includes WordPress plugins, Craft CMS, MaxSite CMS, MetInfo CMS and Joomla JCE. Its reported aim is often simple: find a way to place a webshell on a vulnerable website, then use that access for disruption, credential theft, malware delivery or a route into the wider business network. Targeting is widespread and across companies of all sizes including Small and Medium sized Businesses (SMBs).

For SMBs, the important part is that APT's are discriminately discovering and exploitation organisations of every size. Smaller businesses are not invisible, they are often easier to find, may have less time to patch, and frequently have websites managed outside the normal IT and security controls.

What our network sensors observed

We checked Black Cat’s internet-facing sensor data for the period after the alert was published. From 9 to 14 July, one sensor recorded 342 WordPress-related probes from nine distinct source IP hashes. Activity peaked on 13 July, when it recorded 205 requests from six sources.

Out of those:

179 requests sought WordPress config files and backup variants such as .bak, .old, .save and ~. Those files can expose database credentials and other sensitive configuration data if they have been left accessible.
110 requests searched for randomly named wp-*.php files, a pattern consistent with looking for webshells or other malicious PHP files already deployed on compromised sites.
85 requests targeted WordPress admin, content, plugin, upload and core-application paths.
14 requests from 13 sources targeted a generic CMS/PHPUnit remote-code-execution path: /cms/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php.

Among the 14 July requests were probes for a WordPress file-manager plugin path, the uploads directory, several configuration backups and suspected webshell filenames.

The website security blind spot

Many businesses do not think of their public website as part of the core security estate. It may have been built by a marketing agency, maintained by a web developer, hosted by a third party, and managed day-to-day by the marketing team.

That arrangement can work well commercially. The risk appears when responsibility is unclear:

IT may not know which CMS, themes or plugins are installed.
Security may not receive vulnerability or patch notifications from the web supplier.
Marketing may assume the agency is applying updates.
The agency may assume that hosting, backups or security monitoring belong to the customer.

An attacker does not see those boundaries. They see an internet-facing application that may contain a known weakness and may have access to customer data, administrator credentials, payment integrations, email services or internal systems.

The ACSC warns that webshells can be used not only to deface a site, but also to capture credentials, distribute malware to visitors and create a pathway to broader network compromise. That makes website ownership a business-security question, not merely a marketing or supplier-management detail.

Questions to ask the people who manage your website

This does not need to become a technical audit led by marketing. It does need a short, clear conversation with the relevant agency, developer, hosting provider or internal team.

Ask these questions now:

What CMS, themes and plugins are in use, and who owns the inventory?Ask for the exact product and version list, not simply confirmation that the site is “up to date”.
Do we use any of the CMS products or plugins in the current alert?In particular, check WordPress plugins and extensions, Craft CMS, MaxSite CMS, MetInfo CMS and Joomla JCE. The ACSC’s alert names the affected products and CVEs.
Who is responsible for security updates, and what is the patching timeframe?Establish who receives the advisory, who applies the update, who tests it, and who confirms completion. If a critical plugin flaw is being exploited, a monthly maintenance window may be too slow.
Can the supplier show that the site has been checked for webshells and unexpected file changes?Ask them to inspect the web root and relevant plugin directories, and to look for unusual PHP files or changes that are not linked to an approved release.
Are web access and hosting logs retained and reviewed?The ability to look back matters. Ask how long logs are retained, who can access them during an incident, and whether suspicious requests and outbound connections can be investigated.
What does the website have access to?Review administrator accounts, database credentials, email-sending services, payment providers, customer data, cloud storage and any route from the hosting environment to the corporate network.
Are backups protected and tested?A backup is useful only if it is recent, known-good and can be restored quickly. Make sure the process includes a clean restoration path after a potential compromise.
What is the incident contact and response process?Ensure the supplier knows who to contact, including outside business hours, and that your security or MSP team can be brought in promptly.

What good looks like

The immediate priority is simple: identify any affected CMS and plugins, apply available security updates, and investigate signs of compromise before assuming that patching alone resolves the risk.

For internet-facing websites, good practice also includes restricting unnecessary file creation and execution, monitoring unexpected child processes launched by the web server, using least-privilege service accounts, separating the website from internal systems, and keeping security logs available for investigation.

For SMBs, the main lesson is organisational. Your website may be managed by marketing or a trusted third party, but it is still a public-facing business system. It needs a named security owner, an asset and plugin inventory, a rapid route for urgent patching, and a clear escalation path when active exploitation is reported.

The attackers are already scanning the internet which sites are exposed. Every business should be able to answer the basic question: who is looking after ours, and how do we know it is secure?