#0045: Resolving a website security compromise

Preamble

I find that I have gotten into the habit of using ChatGPT in my daily routine. Mostly asking it to make visual assets for my D&D Underdark campaign. But also as a general stepping off point for research. It has replaced Wikipedia in that regard. In this line of activity, I recently started asking it to review my articles. Initially out of curiosity; however later, because I genuinely found its output useful. I mean how often in life do you get someone who actually is willing to proof-read something that you wrote, give critical feedback, and on demand no-less. Rare as hen’s teeth almost.

Well the other day I decided to go one step further, and asked it on a whim to give me recommendations to improve my website as a whole. This is where our story begins. It listed a bunch of stuff. SEO things, formatting, general tips, a whole bunch of things that I frankly did not care about. However, in that list it also contained a directive to remove the spam links in the footer of my ‘post index page’. Just another line item. Reading this I was stunned for a moment. Holding my breath in disbelief. Then upon checking the website itself. There they were. And not just on that page. But all of the pages of my website. From the homepage to about-me. The same line of malicious spam links in the footer.

Defining the security compromise

It was at this point that I realised that my website was compromised. The reason why I was so initially shocked is because: well, up until now running this website has had zero issues from a security perspective. I thought I was good. I just implemented basic turn-key solutions to get secured. And with both Bluehost and WordPress reporting no security issues. Nothing but green flags, err- icons. Naturally I thought that my little blog was fine.

It was not. At the bottom of every page of my blog contained a line of text that I did not put there. It consisted of six hyperlinked words; with each connecting to a separate online domain. Initially they looked like nonsense words to me. A random computer generated string of letters followed by numbers. However a cursory (DDG search) look into the spam text itself, revealed that it consists of the names of online gambling platforms in east Asia. Albeit shady and rather low rent, judging from their advertising media.

Just look at the AI art they use to advertise themselves. Call me a hypocrite if you like, but I do not think it looks good employing this kind of art for a professional business. Just look at that lion’s tablet holding hand. Yikes. Who the heck green lighted this advert? It is signs like this that make the thing look shady. Oh yeah, and the whole injected spam links fiasco doesn’t help either. All signs point to scamming.

Now interestingly, the hyperlinked web-addresses behind the gambling platforms’ names, are actually for completely unrelated websites. They cover a varied mix of topics. At least judging by the web address names themselves. Things like ‘Arabian travel news’, ‘Chinese medicine’, ‘plan your website’, and ‘getting paid’. Not only this, but they also employ varying top level domains such as ‘.co’, ‘.com’, and ‘.org’. With the lack of any semantic connection to the hyper-linked text itself, coupled with the sheer variety of websites present: leads me to believe that these are potentially compromised websites themselves. Formerly legitimate domains that have been hijacked to be used for illicit purposes. It is the scenario that makes the most sense to me at the moment, with the limited information that I have.

Alternatively they could be legitimate websites (i.e. a website that offers an actual legal service) – that have contracted a shady third-party agent to improve their traffic metrics. And the contracted agent decided to do that via injecting backlinks into WordPress blogs. Honestly, it is plausible. I mean there are a lot of WP blogs, and they all pretty much use the same security packages, setup, and general infrastructure. Once a vulnerability is found for one, chances are good it’d work for nigh all.

Either or, there is no reason to actually click any of these links to try to verify my claims. As there is nothing tangible to be gained from it, especially when stacked against the unknown risks of visiting a potentially malicious website. Now back to the spam itself. The footer read something like this below, albeit in a randomised order. Same names, same links behind them, just in a random order upon page refresh, or page change.

“benteng786 | piton786 | berjayatogel | benteng786 | benteng786 | benteng786”

So now we know what this essentially is: illicit advertising. Spam. Interestingly this is the main reason why I do not allow comments (or even ping-backs) on my articles. I removed that vector for spam as I did not want anything here like: malware links, or gibberish bot comments. Anything that I would have to actively manage and remove. As genuine reader comments are not worth the overhead that an open comment section would incur. And I don’t want to go to the lengths of employing things like CAPTCHA technology to filter them out. Or even use the built-in Akismet tech for that matter. My primary efforts (and attention) in regards to this website needs to go to producing content. Not reading and moderating comments.

Moving on. Here we have a scenario where an agent has managed to place its spam into my website’s footer. Where is it stored? How can I remove it? And how did it do this? These are the three questions that need answering. And even as I write this post initial fix: I am still not sure how to answer. As I am waiting to see if the spam comes back, using a regenerative method that I missed. One that is hidden elsewhere, deeper in the code.

My experience with tools and resource management

I have noticed something about technology in general, specifically software. Whenever you try to do something that is non trivial – very quickly it becomes apparent just how crap everything actually is made. How it’s all just assorted pieces of balsa wood, struck together with rubber bands and PVA glue. In this case dealing with the Bluehost interface, as well as WordPress’s. I had to bounce back and forth between them constantly. As core necessary functionalities were spread across both platforms. Not to mention the use of third-party tools, each with their own eccentricities and learning curves.

With regards to BH and WP: they did not work as expected half the time. Either functionality was hidden in segments that weren’t named in a manner where intuitive deduction would get a user to them. OR when they were found – they glitched out and did not function – either as expected, or as the tutorial explicitly demonstrated that they would. For example my Bluehost FTP section no longer loads. Just doesn’t load. Full stop. Do I have connections available? Yes. I know this because I am using them. Can I see them on Bluehost? No.

Honestly if it wasn’t for the AI chat bots holding my hand, as well as Bluehost’s tutorials I would be lost at sea on this one. So thank you both. ChatGPT, and Bluehost AI. They saved me a lot of time trawling through forums like Stack Overflow, or asking in IRC. Time I honestly can’t afford right now. Because time isn’t just flat time, it is also momentum. Starting and stopping projects like this with large breaks to work and take care of responsibilities seriously staggers these types of efforts.

Tools used

• web-browsers (Brave, Firefox)
• FTP client program (Filezilla)
• online host provider (Bluehost)
• website management suite (WordPress)
• online file manager (cPanel File Manager)
• local file manager (Nemo)
• text editor (Xed)
• AI chatbots (ChatGPT & Bluehost AI)

Troubleshooting procedure – step summary

Step 0.0 – back up the website (using either FTP or in-browser download)

Step 1.0 – process all files and remove vulnerability vectors in a systematic sweep (test between each sub-step)
Step 1.1 – eliminate possibility of active hack via login credentials (change PW, install 2FA)
Step 1.2 – update core software suites/services (WordPress, SQL, PHP)
Step 1.3 – process all WP plug-ins (delete unused, update in-use)
Step 1.4 – process all WP themes (delete unused, update in-use)

Step 2.0 – target location of suspect file(s) in other areas
Step 2.1 – identify suspect file(s)
Step 2.2 – confirm presence of malicious code within any suspect files

Step 3.0 – remove infected file(s) from codebase
Step 3.1 – verify spam footer removal

Step 4.0 – housekeeping (closing tasks)
Step 4.1 – clear/setup website page cache (via WordPress settings)
Step 4.2 – reduce page revisions (via WordPress settings)
Step 4.3 – close FTP functionality (via host provider settings)
Step 4.4 – verify that the job (and clean-up) is done.

Troubleshooting procedure – write up

Step 0.0 – back up the website (using either FTP or in-browser download)

The first hurdle arose before the main troubleshooting actually began. Step 0 is making a backup of my website as it is. All read sources as well as common sense recommended this as an initial action. Unfortunately this proved to be an issue because firstly the website was larger than I expected. It turned out to be around 8-9 GB. Downloading this archive using the Brave browser, from Bluehost itself throttled the speed to around 200-300 Kb/s. This took around 10 hours total. Nothing I could do about the speed.

The first night the damn thing failed five hours into it, while I slept. The second time it succeeded however. I had it running in the background while I used the computer during the day. I took time to pause and resume the download using the Brave browser’s functionality. As I rather irrationally thought that this action ‘refreshes’ the download. I mean why did it fail during the night when left alone? Yet succeeded during the day with far more potentially destabilising activity around it, as well as active tampering? The truth is that there is actually no way to know at this level. We’d need to expend a huge amount of resources to find out. That’d be a far bigger project than this one.

An alternative method of backing up my blog includes downloading to my local machine using FTP protocol. I used Filezilla as my program of choice. Good reviews, popular, well documented, works for Linux. Also took about the same time. Albeit without the binary pass/fail of downloading via the browser. Since I could just stop downloading at anytime, shut the PC down. Then start-up later and just resume on the specific files and folders that I left off on. The entire website wasn’t packaged into a single archive file, as it was above. The versatility of using FTP is a far superior method for this reason.

Step 1.0 – process all files and remove vulnerability vectors in a systematic sweep (test between each sub-step)

Now that I think I know what I am dealing with. It is time to do something about it. Let’s start by trying to answer the first question. Where is it stored? In other words: where is the actual code for this bullshit written. What file, and in what folder of my website is it in? ChatGPT recommended that the compromising code could be hiding in a number files. It could be within out-of-date or compromised third-party plug-ins, WordPress website themes, or software suites, or put into the website itself using hacked user credentials.

Step 1.1 – eliminate possibility of active hack via login credentials (change PW, install 2FA)

I had little suspicion that it was the latter because I only access my website via the one account, on the one computer, on the one network. So it’s not like they’d get a chance to capture my credentials on a public network or anything like that. Additionally I use Bluehost’s two-factor authentication (2FA). Which sends me an email with an extra temporary code every time I try to log into my website. So a malicious agent hacking into my account and getting past all that – just to then post spam links in the website’s footer and seemingly nothing else – seems dubious to me. There are cheaper ways to achieve this given result. Never-the-less, change the password.

Step 1.2 – update core software suites/services (WordPress, SQL, PHP)

What are those cheaper ways? The one that jumps to mind is exploiting a known vulnerability in an underlying software service. I don’t keep up with the niche news, but anyone who does would naturally know them as they are made public. So the first thing I did in this regard is try to plug all these potential holes by updating all the software that I use. Specifically the WordPress suite, as well as what SQL and PHP versions the site was running.

WordPress was up-to-date, SQL and PHP were not. I don’t recall what version SQL was before updating to the current version. This updated within WP. Now PHP I updated from the 8.2.x version that I was running to the current 8.5.x version (as of 2026-10). This was done on BH because WP could do nothing but recommend I write an email to my host provider asking for an update. It genuinely made me laugh to read that.

Once SQL and PHP were updated I checked the website to see if the spam footer was still there. Yes, it was. I took a little time off, refreshed everything, then checked again. Confirmed that I was indeed running the latest version, then checked once more. At this point I think it is fair to say that the malicious code itself was not embedded into whichever database or PHP components that I have installed to run on my site. In other words the malicious code is not part of the PHP/SQL codebase currently underlying the website. Since its presence is still observable post update, with new and intact versions running.

I do suspect that a vulnerability in an outdated version, specifically of PHP may have been used as an ingress point to put the malicious code into my website initially. However with the update to current, this potential point of ingress should now be plugged. It’s not definitive, nothing is at this high level. However this effort does represent a genuine hardening of security.

(As an aside, can you tell that I don’t actually know what either SQL or PHP are or do? I don’t want you to walk away thinking that I’m more knowledgeable than I am. I’ve heard about them before. I know one is used for managing databases, and the other is critical to the underlying internet infrastructure as a whole. That’s about it. Honestly it’s more sorcery than science to me. Additionally I am not sure why I completely dismissed SQL as an attack vector at this stage. I likely tunnel-visioned on PHP, because I knew that it could be used to actively do things like inject malicious code. Whereas SQL is just a type of databasing language to my limited knowledge.)

Step 1.3 – process all WP plug-ins (delete unused, update in-use)

Moving on. The next suspect consisted of the host of out-of-date plugins that I had installed. Active, and deactivated alike. I removed many that I had no longer use for. Then updated the ones that survived the purge. Thirdly, I set these survivors to auto-update. After this I tested the website again. Refresh, look, wait, refresh, look again. Look again on another device. And unfortunately the spam links where still there.

Plugins processed:

1. Akismet Anti-spam: spam protection
2. Code Embed
3. Embed HTML5 game
4. Enhanced Text Widget
5. Jetpack
6. Mouse cursor customizer
7. Stop User Enumeration
8. The MOJO marketplace

Step 1.4 – process all WP themes (delete unused, update in-use)

Once the plugins were sorted, I turned to the themes. All were out-of-date. Same procedure. Delete anything that is not of use, and update all that are. I removed all except the actively employed theme. Deleted number one to four. And updated five. Then set it to auto-update.

After this the website was tested again. The spam links were still there, on every page as before. To eliminate the active theme from suspicion of harbouring malicious code, I installed and applied a completely new theme. Named “BlogArise” by Themeansar. And sure enough the spam links were still present in this new theme’s footer. With a little deductive reasoning, we can conclude that the active malicious code is not in the free WordPress “Coral Dark” theme that I use. As it did not go with it.

Themes processed:

1. Twenty Twenty-Two
2. Twenty Twenty-Three
3. Twenty Twenty-Four
4. Twenty Twenty-Five
5. Coral Dark
6. BlogArise

Step 2.0 – target location of suspect file(s) in other areas

At this point I have eliminated the main hiding places for the malicious code. It is not in the up-to-date Coral Dark theme. It is not in the updated plugins. And it is not in any of the infrastructure software suites: WordPress, PHP, and SQL. All of which were recently updated, and verified.

Before we go on I will acknowledge that nothing is 100%. Obviously I could have missed it in my sweep, and it is hidden in one of these things mentioned. I know that, however for expediency one cannot keep second guessing oneself. All these vectors were sufficiently addressed. As in there is nothing that immediately pops to mind that I could do further to validate their file health. I.e. confirm a lack of infection.

Step 2.1 – identify suspect file(s)

This involves picking over all directories to find a suspect file. Now with a lot of the file base eliminated, it narrows the search perimeter to those files that were not in the initial sweep. Looking over the directories I located more plugins. Within the WordPress “Plugins” directory, under the “Must-Use” sub-directory. This sub-directory was not featured in the initial sweep. It contains 3 items.

‘Must-use’ plugins:

1. Endurance Page Cache
2. SSO
3. worked.php

One of these is not like the other two. Both “Endurance Page Cache” and “SSO” had version numbers, credited authors, as well as being easily searchable with plenty of hits describing exactly what each does. Whereas “worked.php” had none of these things. No version, no author, and no real hits when looking it up. Plus it is the only one with the ‘.php’ affix in its display name. Likely mirroring its actual file name. A little rough touch that gives it away. Especially when viewed in conjunction with everything else. Still at this point it was just mounting suspicion. I did not have anything concrete.

From the WordPress UI I could not enter to view nor edit this file. However it did contain the direct file path directory for these specific (3) plugins. In this case “/wp-content/mu-plugins”. In hindsight I realised that the sentence around this file path directory is yet another clue. One that explains the observable behaviour of the spam links themselves. See below.

“Files in the ‘/wp-content/mu-plugins’ directory are executed automatically.”

Alternatively, if I did not find the suspect file in this manner. Then I would have tried to track it down more directly via a web-browser’s diagnostic tools while the file is actively running on my website. This could be done by pressing ‘F12’ (in Brave & Firefox) while observing a webpage. This will allow one to view the HTML code for the webpage. From this one could navigate to the subject element. Then inspect it for clues. In the example image, I should have clicked the ellipsis to expand this out. From this one could potentially get the file name, and/or its location in the codebase.

If not that, then weaker (i.e. less direct) clues. For example the HTML for the spam footer has a class name of “pdn-footer-links”. With “pdn” likely standing for “Public Display Network”: i.e. advertising. (Source ChatPGT.) In addition this HTML class name is found verbatim in the ‘worked.php’ file as part of a function name.

If all else fails then a hail-Mary Ctrl+f keyword search on the whole local codebase could be done. Example known keywords: footer text names (e.g. “piton786”), hyperlinked domains, or any class names found in method above. Any hits would likely be contained within a lead file, if not the target file containing the malicious code itself. This is is also a good way to find supporting files. Such as code regeneration files, designed to reinstall the main file once/if it’s deleted.

Step 2.2 – confirm presence of malicious code within any suspect files

To access the “worked.php” file itself: I used my OS’s file-browser to locate the local copy that I had on my computer using the above file-path. Sure enough. The code is malicious. Upon opening the file in a text editor I found this (below).

Code snippet:

function pbn_footer_links_config() {
		return array(
			array(
				'url'    => 'https(colon)//planyoursite(dot)com/',
				'anchor' => 'benteng786',
				'title'  => 'benteng786',
			),
      ...

Step 3.0 – remove infected file(s) from codebase

To remove the file from the online website’s live codebase itself; I connected utilising the FTP protocol via the Filezilla client; and the previously established host settings to enable this functionality. Within Filezilla I used its built-in file-browser to navigate to the same directory as I did in the local version. Then simply deleted the malicious file within Filezilla. And hey presto! It is gone. That’s it. (As an alternative you can use the cPanel file manager from the host provider.)

Step 3.1 – verify spam footer removal

After refreshing my website the spam footer was gone. If it is not gone, check that the file is indeed gone in the WP UI. If it is then move to step 4.1: clearing the page cache. As likely the live website that you are viewing is a cached version of the one that you are editing.

Step 4.0 – housekeeping (closing tasks)

Housekeeping. I define ‘Housekeeping’ as the assorted miscellaneous tasks that are not part of the core repair, however they are necessary for properly finishing off a job. For example: When repairing my bicycle, housekeeping in that job consists of cleaning and putting all the various tools away properly. Back in their proper place where they won’t get damaged or lost. It is essentially clean up, with the aim to prevent any future complications.

Step 4.1 – clear/setup website page cache (via WordPress settings)

Here we start with purging all cached copies of the website. In my case I did not have any, I (unknowingly) never set the site to create them. I only thought that I did because I confused it with page revisions. This is where WordPress would make copious copies of anything that I publish every time that I edit it. I decided to correct this situation by setting up a website cache.

Caching tools are within the host provider’s settings section. Specifically with Bluehost it is under the ‘Performance’ tab Bluehost. Here within ‘Caching Control’ it gave three options for enabling caching. ‘Assets Only’, ‘Assets & Web Pages’, and ‘Assets & Web Pages – Extended’. I chose the middle option and left it at that. Done. My website is now cached.

Coincidentally there are other relevant tools on this page. ‘Clear Cache’ to remove any cached copies when desired. Obvious, really. However a very important step, I would have had to take if I had any cached copies of my website. A more interesting tool is Google’s ‘Page Speed Insights’. This seem like a tool that loads up a website and then assigns a score out of 100 to represent the speed that it loaded in.

Initially with no cache I got a 98/100, then once I set up a cache and retested. I got a 100/100. Honestly I don’t put too much stock in these types of tools when they report too positively like this. On one hand yes my blog is primarily simple images and text. And little more. However when it is a little more, things go south quickly. Loading video times is abysmal. It slows everything down. Including trying to navigate off page. Obviously this tool did not try to load up an article containing embedded video clips otherwise the score would not be as it is.

Before moving on I will say one thing. It occurred to me while editing this article for publication: if my website did have a cached version active, then my entire workflow would have been upset by it. This is because any changes made would not immediately be live to see. Since I would be visiting a cached copy each time I clicked to check on the footer. It only occurred to me now at the end of process. With that in mind I think it would be good practice to clear and remove website caches at the start of the process going forwards, just after backing up the website. I guess it’s true what they say about experience.

“Experience is something that you don’t get until just after you need it.” – Steven Wright.

Step 4.2 – reduce page revisions (via WordPress settings)

Now that the cache is all sorted. It is time to do something about reducing the website size. I wanted to try to do this by reducing the number of page revisions. That way I didn’t have to store every past copy of an article. However as I was looking in to it. I realised that I could not find it in the settings. Any of them. And upon getting frustrated and asking ChatGPT. It told me that there is no setting in the WordPress GUI for it. Upon reading this I decided that this tangent was simply not worth the time and effort. Of trying, testing, and verifying. At least not at this moment. It is a project in itself. We have to keep moving while we have momentum.

(You may wonder as to why I would keep this section here, if nothing got done? It is because I am documenting my workflow. And often I would hit dead-ends like this. Although this isn’t necessarily a dead end; it’s just a side-quest that is going to take more time and effort than which I have portioned for it. It is important to know when to move on with these things. I will pin it for a future visit however, as I find the topic interesting.)

Step 4.3 – close FTP functionality (via host provider settings)

This is a perfect exemplar that demonstrates the clean up analogy I used previously. Here we put away our tools so that they don’t cause any issues in the future. Here we close/remove the FTP connections that we setup in order to access and download the website previously. This closes a potential attack vector to the website going forwards. If you need to use FTP again, just set it up again if and when you need it. Keep it while you need it, and then remove it when the job is done. It is good general OPSEC.

Step 4.4 – verify that the job (and clean-up) is done.

Verify stage. Test the website thoroughly. Flip through a lot of pages, scroll, refresh. Close it and reopen. Across different devices (mobile/desktop), and browsers. Until one’s mind is set to ease. This is the final housekeeping task. It is the last look before turning off to do something new. Once satisfied that nothing was missed. Nothing in the project. Either the project piece itself, or the clean up after. Then we are actually done.

Acronyms used

AI – Artificial Intelligence
BH – BlueHost
ChatGPT – Chat Generative Pre-trained Transformer
DDG – DuckDuckGo
GUI – Graphics User Interface
FTP – File Transfer Protocol
HTML – Hypertext Markup Language
IRC – Inter Relay Chat
LLM – Large Language Model
OPSEC – Operational Security
OS – Operating System
PC – Personal Computer
PHP – “PHP: Hypertext Preprocessor” (recursive acronym)
PDN – Public Display Network
PVA – Polyvinyl Acetate (glue)
PW – Password
SEO – Search Engine Optimisation
SQL – Structured Query Language
SSH – Secure SHell
SSO – Single Sign On
TFA/2FA – 2/Two Factor Authentication
UI – User Interface
WP – WordPress

Closing thoughts

I am finishing this article on the 22nd of October 2026. Around two/three weeks after this issue was fixed and it seems like it has not resurfaced. In the interim a mechanism for replanting the spam footer file has not been activated. This means that in all likelihood I solved this problem. I identified and removed the malicious file causing the spam footer, and likely purged the files that constituted the security hole that allowed ‘worked.php’ to be implanted within the ‘mu-plugins’ directory in the first place.

Unfortunately I did this without knowing the exact file vector that the hacker used to infiltrate my website. It was likely one of the out-of-date themes or plugins that were deleted. However I cannot know for certain at this point. Additionally I did not record key information that could serve as clues, such as the file creation date/time of “worked.php”, or last modification date/time of all the themes/plugins. Alas. What I do know is that A Tinkerer’s Blog seems safe (enough for now).

Since I now have a copy of the website archived locally (while actively infected); with all the out-dated themes and plugins. I could pore-over them to see if their code deviates from the official versions of that same revision (version number). To compare and contrast, looking for modifications. OR edit timings that match up with ‘worked.php’.

Additionally I could try to look up news of security holes within their general architecture. (If no code mods are found.) However that is like looking for a needle in a haystack in my opinion. Including using AI, because the robustness of an LLM’s output for extremely technical or niche things such as this, often relies on excellent prompting. Guided prompts that require a high degree of working knowledge on the subject. Something that I do not have.

Without labouring the point too much – I want to say that there is a lot more that I could do with what I have here. In order to find out exactly what happened. However that would require an order of magnitude more concerted effort on my behalf to get results. Something that I am not inclined to do at this season of my life. I hope that I do not sound like I am lazy, it’s more that I have pressures on my time and attention that are of a higher priority than finding out exactly how my website was compromised.

If I do decide to pursue this in the future. I will of-course post about it here.

Thank you for reading (my spam free article <3).