northgate-advisors.com

A copy of the main WordPress configuration file was left in the public folder under a different file extension. Because the extension is not .php, the server does not execute it, it hands over the text. Requesting that address from the internet returns the whole file, and it contains the database name, database user, database password, all nine authentication keys and salts, and the Mailgun sending key. We confirmed the file is served on 30 July 2026 and did not keep a copy of its contents.

What this means in practice. The mail key lets anyone send email that appears to come from your domain, which is a ready made phishing capability against your own customers. The authentication keys let an attacker tamper with sessions and forms. The database password is limited by the fact that your database only accepts connections from the server itself and the database port is not reachable from outside, which we checked, so it is not directly usable from the internet, but it becomes immediately usable to anyone who gets any foothold on that server.

Four separate folders hold customer documents that the web server hands to anyone who asks. We confirmed one file from each set downloads successfully from the public internet, and kept none of them.

• 5,606 tax documents in uploads/client-statements/, named in a simple sequence (statement_5393.pdf, statement_3084.pdf). Nothing protects the folder and the numbering is guessable, so the whole range can be walked. Automated scanners do this routinely.
• 27 invoices in wp-content/billing_invoices_temp/, named invoice-4395.pdf and similar, equally guessable. The folder does contain an access rule, but it is written for Apache and your site runs on nginx, so it does nothing.
• 1,113 files submitted through your forms in uploads/fluentform/.
• 1,248 attachments across 248 support ticket folders in uploads/fluent-support/. These are the most sensitive of the four sets: the file names alone, visible in the address, announce tax certificates, bank statements, insurance policies and investment account summaries, each next to a customer surname.

One distinction matters for how urgent each set is. The tax documents and the invoices are numbered in sequence, so anyone can enumerate them without knowing anything about your site. The form and ticket files carry a random string in their names, so they cannot be guessed one by one, but nothing stops access either: the name is enough, and names leak through browser history, referrer headers, shared links, and to anyone who reaches the database. Obscurity is not protection.

This is customer tax, billing and correspondence data, which under the GDPR is sensitive personal data. Treat the possibility of unauthorised access as real rather than theoretical, since the site was also under attacker control in the same period.

Your security plugin does try to stop PHP files from running inside the media folder, but it does that with an .htaccess rule, and .htaccess files are an Apache feature that nginx ignores completely. Every rule of that kind on this site is inert, including this one.

We verified this directly. An existing PHP file in the media folder was requested from the internet and the server executed it rather than returning its text. Your site's own protective rule check recorded the same conclusion on 27 July: PHP execution in the media folder is not blocked.

This matters more than it sounds. The backdoor found on 28 July was a PHP file in exactly this folder, disguised with a GIF89a header so it would pass as an image on upload. Deleting that file removed the symptom. As long as uploads can execute, the next file upload flaw in any of your 54 plugins produces the same result again.

Three accounts with full administrator rights logged into the site between 22 and 23 July. Their email addresses name the tooling used: shellcode.lol, shelltool.invalid, and a machine generated name at a plausible looking domain. Each logged in successfully on the first attempt with no failed attempts before it, which rules out password guessing and means the accounts were created by whoever then used them.

Your team deleted all three between 23 and 26 July, and no unexpected administrator remains today. That is the right outcome, but an account with administrator rights can do anything before it is removed: install a plugin, edit theme files, read the whole database, export customer data. Assume all of that was possible during those days.

On 28 July at 01:03 your site's malware scan flagged a file in the media folder as malicious at severity 100. The file was disguised to look like an image (it began with the text GIF89a) and its code assembled the names of dangerous functions letter by letter to slip past scanners. Those functions were the ones for accepting an uploaded file, writing files to disk, and running system commands. In plain terms: a tool for uploading anything and running commands on your server.

The file is gone from the site today and we confirmed the address now returns a not found response. The alert, however, is still recorded as new and unhandled, and alerting was switched on with a valid destination address at the time, so someone should have received an email about it on 28 July. The same scan also lists 35 outdated plugins and themes, none of which have been acknowledged either.

There is a self contained diagnostic tool installed at the top level of your site. We confirmed the address answers on 30 July. It is not part of WordPress and it does not use WordPress logins, it is protected by one single password of its own. The tool can read your debug log, can rewrite your main configuration file, and records the full text of database queries, which is why SAVEQUERIES is switched on in your configuration and why a database interception file sits in wp-content.

Database query text is not harmless content. It contains password hashes, session identifiers and whatever your forms submit, which for this site includes customer data. Two further details make this worse: the configuration backup that leaks your credentials in C-1 was created by this same tool, and your malware scanner is explicitly configured to skip this directory, so it is the one place on the site nothing is checking.

We reviewed its code and found no hidden malicious behaviour: the sensitive actions are behind its password and a request token. The problem is not that it is malicious, it is that it exists on a production site handling tax data.

Your main administrator account currently holds eight concurrent logged in sessions, all from the address 192.0.2.117 (a hosting provider, not an office connection), all identifying themselves as node rather than a browser. They were created in pairs on 23, 24, 26 and 28 July and remain valid until 11 August.

These were not created by someone typing a password: that account's stored password is still in the older format, and WordPress upgrades the format automatically the first time a correct password is used. So something is creating administrator sessions programmatically. We ruled out the WP Umbrella management connection, which uses different addresses and works differently.

The most likely explanation is your own integration, given that a user account named PortalApp exists on the site. That would make this expected behaviour with poor hygiene. The alternative is that it is not yours, in which case it is standing administrator access. We cannot tell these apart from the outside, and the window during which attacker accounts were active overlaps these dates.

Your scanner flags those four as running a version for which a vulnerability has been published, meaning the technical details are public. In total 35 plugins and themes are behind, including the whole Thrive suite, WooCommerce, Amelia and the Fluent suite.

This is the most probable way in. The backdoor arrived as an image looking file in the media folder, which is the signature of an upload handling flaw, and Fluent Forms is the component on this site that accepts customer file uploads. We cannot prove which flaw was used without your server access logs, but leaving these versions in place keeps the door in the same state it was in on 22 July.

WordPress ships an editor that lets an administrator rewrite theme and plugin files from the browser. On this site it is enabled. That turns any administrator session into the ability to run arbitrary code, with no upload and no file transfer needed.

Given that three attacker administrator accounts were logged in during July, this was available to them. It should be switched off permanently: legitimate changes go through your agency's deployment process, not the browser editor.

Over the last seven days the site recorded 393 failed logins from 221 distinct addresses, plus 56 attempts stopped by the login protection and 21 attempts to enumerate usernames. Over the longer plugin log the campaign is larger: the display name Daniel was targeted around 500 times and Rossi Marta around 179.

The important detail is that these are real names of real people on your site, not the usual admin guesses. That means the attackers scraped author names from your pages and are working through passwords for known accounts. One address per name, spread thin, deliberately slow enough to look like ordinary traffic.

Exactly one of your eight administrator accounts has two factor authentication enabled. For the other seven, a correct password is the only thing standing in the way, and passwords are the one thing this campaign is designed to eventually get right.

The OneDrive integration caches its authorisation data in a folder with no access control, and we confirmed a file in it is served over the internet. The filename alone already discloses the connected account address and your Microsoft tenant identifier. In the state we reviewed, the token file itself was empty, but on a live site this path is where a valid access token to your OneDrive sits.

A valid token of that kind is read and write access to the connected document storage, without any password and without triggering a login notification.

Eight accounts hold full administrator rights on a site processing tax and payment data. All eight resolve to people or organisations you work with, so none is a rogue account, but two stand out as dormant.

• An agency account created in October 2022, unused since January 2025, whose stored password is still in the old format.
• A vendor support account created on 21 May 2026, used once from an address in Bangladesh, unused since. The address is consistent with the support team of one of your plugin vendors, so it is probably legitimate access your agency arranged, but it should not still be open.

Every dormant administrator is a full set of keys nobody is watching.

A remote site management plugin remains installed but deactivated, and two administrator accounts still carry its connection settings, including a stored connection key. Its scheduled tasks are still registered, and it left a server clone folder inside the media directory.

A tool like this is a remote administration channel by design. Deactivated is not removed: the files are still on disk and reactivation restores the channel. It is most likely your agency's own management setup, which is fine, but it should be either in use and current, or gone.

Ninety one compiled PHP template files were left inside the media folder by a translation plugin that is no longer installed. Their content is harmless, but they are executable code in the one folder that should never contain any, and as C-3 establishes, that folder does run PHP on this server.

Separately, a complete second copy of the OneDrive plugin is present at version 3.5.2.1 while the live copy is 3.8.1. It is not active, but every file in it is still reachable and executable, which means an old version's flaws remain available even though the plugin appears updated.

Three files that describe how your server is set up are served to anyone who asks. We confirmed all three on 30 July:

• /.user.ini (112 bytes), which your scanner already reported on 27 July and which is still listed as unresolved. It discloses the absolute path of the site on disk.
• /.htaccess (1,901 bytes), which hands an attacker your complete rule set, including which paths you believe are protected and which security plugin wrote the rules.
• /wp-content/debug.log (220 bytes), which is where PHP errors are written. Debug logs routinely contain file paths, query fragments and occasionally submitted data.

None of these is dangerous by itself. Together they are the reconnaissance an attacker does before choosing a technique, and they are collected automatically by scanning tools.

We found 24 access rule files across the site, written by your security, backup and form plugins. All of them use Apache syntax. Your server is nginx, which ignores these files entirely.

The consequence is systematic rather than isolated: the block on PHP in the media folder (C-3), the protection of the configuration file, the Deny from all on the invoice folder (C-2) and on the backup staging folder all read as active protections in a plugin dashboard while doing nothing at all. This is the single reason several findings in this report are as severe as they are.

Open registration is on, with new accounts receiving the subscriber role. That is plausibly deliberate given the shop, the booking system and the online courses, and the account list is consistent with genuine customers: the February and March registration peaks match the tax filing season.

It is listed here because an open registration form is the standard first step in privilege escalation attacks. Several of the plugins on this site have historically had flaws that only a logged in user could exploit, and open registration means anyone can become one.

A handful of accounts use disposable or anonymous email domains. None of them holds any privileges.

Two plugins that are no longer installed left credentials behind: a file manager left its access key, and a backup plugin left stored HTTP authentication settings. We did not read the values.

A file manager is worth noting for a second reason. It gives full filesystem access from the browser, and traces of one are present in several places on this site, so it did run here at some point. That is the kind of tool that turns a single compromised administrator account into complete server access.

Three settings, none dangerous alone, each of which widened the impact of what happened.

• Full database query logging is switched on in production, which is what fills the query log described in H-1 with password hashes and customer data.
• The default wp_ table prefix, which lets automated attack tools guess your table names without probing.
• Automatic updates are switched off, so the site is entirely dependent on the managed update schedule, and 35 updates are currently pending.

Your database credentials themselves are sound in shape: the password is not empty or trivially short, and the security keys are unique rather than left at their placeholder values. They now need changing only because C-1 published them.

Both addresses respond rather than refusing the request. That matters more than it looks: backup plugins write full site archives into these folders, and a single archive contains the entire database, meaning every password hash, every customer record and every key on the site in one downloadable file.

We are being explicit about the limit of what we can say here. The contents of these folders are outside what this review can see, so we are not reporting them as exposed and not reporting them as clean. What we know is that the paths are live and that nothing refused us.

Twenty eight comments linking to gambling and adult sites are sitting in the spam queue. The filter caught all of them, none was ever published, and none of your pages contains this content. This is ordinary inbound spam, listed only so you know it was checked.

Ten embedded frames inside page builder content still point at a staging subdomain. Not a security flaw in itself, but worth checking that the staging site is not publicly reachable, since a copy of a site usually holds the same data with none of the maintenance.

The site carries a visible history: scheduled tasks belonging to a security plugin, a translation plugin, an activity log and a management tool that are all long gone, an option name still carrying a former table prefix, several stale cache folders, a leftover maintenance page referencing the oldest server path, and a copy of an index file. Fourteen randomly named folders in wp-content look alarming and are in fact the cookie banner plugin's asset cache, containing only JavaScript, twelve of them empty.

None of this is malicious. It matters because clutter is where malicious files hide, and because a person reviewing this site in a hurry cannot tell the difference.

Malware can occasionally hide inside the database engine itself, as a trigger or a stored procedure that reinstalls a payload whenever a page loads. This is the one category of hiding place that cannot be ruled out from the material available, so it is reported as unresolved rather than clean.

Three queries settle it in seconds, run against the live database:

SELECT TRIGGER_NAME, EVENT_OBJECT_TABLE, ACTION_TIMING, ACTION_STATEMENT
  FROM information_schema.TRIGGERS;
SELECT ROUTINE_NAME, ROUTINE_TYPE, ROUTINE_DEFINITION
  FROM information_schema.ROUTINES;
SELECT EVENT_NAME, STATUS, EVENT_DEFINITION
  FROM information_schema.EVENTS;

On a normal WordPress site all three return nothing. Anything listed should be read carefully.

Every PHP file was checked for hidden and scrambled code, for code that runs whatever a visitor sends it, and for the small loaders that reinstall deleted malware. Nothing was found. WordPress core, the active theme, the three automatically loaded plugins and the site's entry files are all as the vendors ship them, with no inserted code.

The two places on this site that can run arbitrary code are legitimate tools, reviewed line by line: the code snippet manager and the diagnostic console in H-1. Both keep that capability behind an administrator check.

No injected scripts, no hidden links, no search engine spam and no redirect code in any page or page setting. Every embedded frame and script resolves to something expected: your own site, your analytics, your consent banner, Google Maps, YouTube and a financial modelling tool. Outbound links point at Swiss cantonal and federal tax authorities, Wikipedia and similar. Nothing in your published content was touched.

This is the check that matters most after a compromise, because it is what survives a file cleanup. All ten stored code snippets were read in full and all are your own or your agency's legitimate work. No scheduled task contains code. No setting holds an encoded payload. Every active plugin has a matching folder on disk, so there is no hidden plugin running from the database alone. Your site address settings are correct and there is no pending administrator email change.

Every plugin update source points at its real vendor, and there is no sign of pirated plugin copies, which are a common way for malware to arrive with a site owner's own consent.

Mail volume is a steady 11,000 to 14,000 messages a month over more than three years, matching your newsletter schedule, with the usual January and July peaks. There is no burst and no unexplained sending, so the attacker access in July was not used to turn the site into a spam relay. That also means your domain's sending reputation is intact.

All 317 accounts were reviewed against their stored permissions. The eight administrators all resolve to your team, your agency or a plugin vendor, and no account carries permissions granted outside the normal mechanism. The customer registration pattern is consistent with your business, including the tax season peak. The three attacker accounts described in C-4 are confirmed gone.