Skill · Security

Security work I have been hired to do

I am a Jetpack Security Partner, and malware cleanup has been part of my listed skill set since I started. But the jobs that matter most are rarely dramatic. They are usually about access: who still has it, what they are still being told, and whether anybody has checked since the last developer left.

This is defensive work. Audits, hardening, cleanup, monitoring and reporting, on sites I am authorised to work on.

418

User accounts enumerated and reviewed on one offboarding job

844

Login attempts on non-existent usernames in one reported month

738

Requests blocked by the firewall in that same month

$6.7k

Discount abuse found on one store during an unrelated audit

What I am usually asked for

Malware cleanup and post-compromise hardening
Access audits: users, roles, application passwords, sessions, API keys, webhooks
Offboarding a previous developer or agency properly, with evidence
Firewall configuration and operations, and removing the ones fighting each other
Two-factor enforcement and admin account hygiene
Monthly security reporting for clients who have to answer to a board or a regulator
Investigating a specific worry: strange logins, unexplained emails, suspicious traffic
Secrets hygiene: finding live API keys sitting in database dumps and exports

How I work

Read-only first, always. On a security engagement the first thing I produce is a factual picture of what exists, before anything is changed, because changing things destroys the evidence of what was wrong.

Then findings in priority order with the risk stated plainly, remediation proposed for approval, and the changes applied with backups and a written record.

If the honest answer is "this is not an attack, it is a search engine crawler and your real problem is elsewhere", that is what I will tell you, even though it is a less impressive answer.

Past jobs

Five security jobs and what happened

Client names withheld, and deliberately so on this page in particular.

Offboarding a previous agency from a clinical assessment platform

Access audit

Brief: A healthcare assessment provider had parted company with its developer and had no documented picture of what access remained.
What I did: Enumerated all 418 accounts and roles, every form notification across five forms and nineteen notifications, the commerce mailer recipients, the firewall and activity-log alert configuration, webhooks, cron jobs, application passwords and active sessions, plus a database and filesystem sweep for any reference to the old agency.
What I found: The site administrator email and eighteen other settings still routed to the departed developer. Five of their accounts were still live, including user 1 as an administrator. A client's own account had been given a permission that exposed every other client's assessment entries.
Result: All of it remediated with the affected rows backed up first, mail delivery re-tested to confirm, and a written report the client could hand to their own compliance people. They now receive a monthly security report from me.

Monthly security reporting for a regulated client

Reporting

Brief: A nine-page monthly report covering staff and client logins, failed attempts, external attack activity, software versions, integrations and data integrity checks, readable by non-technical directors.
What I did: Pulled the data live from the server each month. One month's figures: 66 staff and admin logins, 135 client logins, 45 wrong-password attempts on existing accounts (all client accounts, none on administrator or assessor), and 844 attempts on usernames that do not exist, from 247 or more distinct addresses, of which the firewall blocked 738 requests.
How it is handled: Clients anonymised as numbered references, attacker email usernames masked, staff shown by role and first name only, and the finished output searched for client names and for a live API key before it is saved anywhere.
Result: A report they can file. And an honest limitation stated on its face: the audit log only retains about a week of detail, so that section covers five days, not the month. I would rather say so than pad it.

The firewall that was logging the wrong attacker

Finding

Brief: Discovered while building the report above, not while looking for it.
What I found: The firewall's visitor-IP detection setting was unset on a site sitting behind a CDN. So for 555 of those 844 attack attempts, and for 39 successful logins, it had recorded the CDN's edge address rather than the actual visitor. The attack-source data was incomplete, and IP blocking and rate limiting were unreliable for all of that traffic.
Result: Logged as an item for attention with the fix specified, and deliberately not changed in the same pass, because altering IP handling mid-reporting-period would have made the month's figures incomparable. Sequencing matters.

A client convinced she was being targeted

Investigation

Brief: A client reviewed her firewall log, saw blocks attributed to Russia, connected it to her own public activity, and was genuinely frightened.
What I did: Investigated read-only on the server before replying. Every one of the ten blocks attributed to Russia resolved by reverse DNS to Yandex's search crawler. The ones attributed to Apple were Apple's crawler. Login history showed only the two legitimate users, both from their usual country, with no foreign login attempts at all. The largest group of failed logins was forty attempts from a developer with a typo in his username.
Result: Told her plainly that search engines were being blocked, not intruders. Then reported the real gaps the panic had obscured: zero two-factor enrolment across all four administrator accounts, an outside developer and a dormant account from a former agency both still holding administrator access, no full scan in two months, and two plugins behind on security updates. Also recommended unblocking Apple's crawler, which was costing visibility for nothing.

Alerts still going to the previous developer

Access audit

Brief: A routine check of a site whose original developer had moved on some time earlier.
What I found: Every firewall alert was still being delivered to the former developer's personal address: around 45 IP-block notifications, fourteen daily scan reports, seven administrator login alerts and the weekly summaries, up to the previous evening. The CDN plugin was still keyed to his account, and the site's connection to its hosting platform services was owned by a third party nobody at the client could identify.
Result: Alerting re-pointed and confirmed by watching the next alert arrive at the correct address. All of it documented with dates, because "who was being told about your security events, and until when" is a question that deserves an evidenced answer.

Also part of the job

Commercial security, not just technical

Discount abuse worth $6,700

Found during an unrelated audit on a store: two discount codes offering $20 off with no minimum spend, no expiry and no usage cap, redeemed 334 times. One customer was systematically reusing them through alias email addresses, while also being a fifty-order regular, which made it a commercial judgement rather than a simple ban. I wrote up the findings and a hardening plan and left the decision with the owner rather than changing live discount rules on my own initiative.

Live payment keys sitting in a database export

A site options export, generated for legitimate debugging, contained live payment provider secret keys. Anything like that needs finding before it reaches a repository. I now scan file contents, not just filenames, before anything gets committed.

Hardening

What I check on every site

Administrator count, and whether any of them is a person who has left
Two-factor enrolment, actual enrolment, not just the setting being enabled
Where security and system alerts are being delivered
Whether two security suites are both loading on every request
Admin-side file editor and file manager plugins, which are pure attack surface
Application passwords and active sessions nobody remembers creating
Visitor IP detection when the site sits behind a CDN
Whether transactional email is actually being delivered, or silently failing
Core, plugin and theme versions, and whether a bulk update would break the site

Scope note: I do offensive work only where it is my own authorised testing of a client site. I will not attack, probe or test infrastructure that is not mine to test, and I will ask for written authorisation before any intrusive testing.

Reviews

Clients on the maintenance and security work

Terrific service. Great attention to detail, and he made sure the changes were tested and re-tested before signing the job off. I will definitely work with Josh again in the future.

Justin Hill Google

We love working with Josh. He is knowledgeable about any web issues we run into, and always responds quickly.

Jennifer Yacio Google

Communication was very good from the start, and a prompt resolution to my issue was found and actioned. Josh was a massive help!

Fraser C. Codeable

Josh is fantastic.

John B. Codeable

The rest of the skill set

Most jobs touch more than one of these. I can take the whole thing or just the part you are short of.

Contact

Tell me about the role or the job

Contract, part-time, one-off fix or white-label work for another agency: all fine. Say what you need and when you need it, and I will tell you honestly whether I am the right person for it.

Email: hello@josh-morley.com
Based: Liverpool, United Kingdom
Hours: 10am to 5pm GMT
Reply: Within one business day
Languages: English (native)

Prefer to talk first? Book a discovery call, or download my CV.

You can also hire me through Codeable, where the rating, project count and reviews are all independently verifiable.

Your name

Email

What kind of work is it?

Main skill needed

When would it start?

Website, if there is one

What needs doing?

The more specific you are, the more useful my first reply will be.

Or email hello@josh-morley.com