Phishing page found on your server: remove it and find the cause

Updated November 2026

If a fake login page for a bank, mail provider or delivery company is on your server, someone has broken into your site or hosting account and is using it to steal other people’s passwords. Save a copy for evidence, take the page offline at once, find out how it was uploaded, report it so warnings and blocklists are updated, and search for more files the attacker left.

Do this first.

  1. Archive the phishing directory and the web server logs (commands below), then make the pages unreachable. Every hour online means more victims.
  2. Change the passwords for the hosting control panel, FTP/SFTP and CMS administrator accounts from a clean computer.
  3. Answer your host’s or registrar’s abuse ticket, if you received one, to say the content is removed.
  4. Do not open the phishing page in your normal browser while logged in to anything.

How to recognize it

Phishing kits often email the stolen passwords to the attacker or write them to a text file on your server. That file contains other people’s credentials and must be handled with care.

Step 1: preserve evidence

Copy before you delete; the files and logs show how the attacker got in and who was hit. Examples use /var/www/html/secure-login; replace it with the real path.

sudo mkdir -p /root/evidence
sudo tar -czpf /root/evidence/phish-$(date +%F).tar.gz /var/www/html/secure-login
sudo tar -czpf /root/evidence/weblogs-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/httpd 2>/dev/null
sudo sh -c 'sha256sum /root/evidence/*.tar.gz > /root/evidence/SHA256SUMS'

# File times, owner and the email addresses the kit sends to
sudo find /var/www/html/secure-login -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' | sort
sudo grep -rEoh '[[:alnum:]._%+-]+@[[:alnum:].-]+\.[[:alpha:]]{2,}' /var/www/html/secure-login | sort -u

Keep the archive off the web root and away from public backups. If you share files with investigators, send the archive, not a working link.

Step 2: take it down

# Remove the kit (after archiving) and any ZIP it came in
sudo rm -rf /var/www/html/secure-login
sudo find /var/www -name '*.zip' -mtime -30 -ls

# Check that it is gone from the outside: expect 404 or 410
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/secure-login/

If the site runs behind a cache or CDN, purge the cached copy too. On shared hosting where you cannot use a shell, delete the directory in the file manager and ask the host to check the server logs.

Step 3: find how it got there

Use the oldest file time from Step 1 as your anchor, then search the access logs around it. The uploading request is often a POST to a plugin, an upload form or an unfamiliar PHP file.

# Debian/Ubuntu Apache: /var/log/apache2/   RHEL Apache: /var/log/httpd/   nginx: /var/log/nginx/
sudo zgrep -h 'secure-login' /var/log/apache2/access.log* | head -20
sudo zgrep -h '"POST ' /var/log/apache2/access.log* | grep '30/Oct/2026' | head -50

# Other PHP files changed in the same period
sudo find /var/www -name '*.php' -newermt '2026-10-29' ! -newermt '2026-11-01' -ls

# Logins to the server and FTP/SFTP around that time
last -a | head -30                     # Debian 13: install wtmpdb and use "wtmpdb last"
sudo journalctl -u ssh -u sshd --since '2026-10-29' --until '2026-11-01' | grep -i accepted

Common causes: an outdated WordPress, Joomla or Drupal plugin; a stolen control-panel, FTP or CMS password; a web shell left from an earlier break-in; or a forgotten test site. The anti-abuse group M3AAWG notes that phishing on hosted sites mostly comes from compromised accounts with out-of-date scripts. Fix the cause before you bring the site back: update the CMS and every plugin (WordPress), remove unused ones, and change all passwords.

Step 4: look for more

Attackers rarely leave just one file. Check every site on the server, not only the reported one.

# Web shells and obfuscated PHP
sudo grep -rlE 'eval\(base64_decode|gzinflate\(base64_decode|assert\(\$_(POST|GET|REQUEST)' /var/www
# PHP files in upload directories (should normally be none)
sudo find /var/www -path '*uploads*' -name '*.php'
# Unexpected .htaccess redirects
sudo find /var/www -name .htaccess -mtime -30 -ls

Follow Website hacked and Malware scan for a full clean-up. If you find signs of root access, rebuild the server instead (Find backdoors).

Step 5: report it

Reporting gets the URL into browser and security-vendor blocklists and helps others find copies of the same kit elsewhere. Report the phishing URL even after removal; include the exact URL and, if you have it, the lure email.

Google Safe Browsing
Report a phishing page at safebrowsing.google.com/safebrowsing/report_phish/. Once your site is clean, request a review in the Security Issues report of Google Search Console (verify your site there first if you have not). Google says a review can take several days. Check that no unknown owners were added to your Search Console property.
APWG
The Anti-Phishing Working Group accepts phishing emails forwarded to reportphishing@apwg.org (forward as attachment if you can) and URLs through its web form.
Netcraft
Report URLs at report.netcraft.com. Netcraft says validated reports are blocked in its feeds and passed to hosts and registrars for takedown.
National bodies
In the UK, the NCSC accepts suspicious website reports through its online form. If you or others lost money, report it to the police or your national fraud reporting service.

If the kit wrote stolen credentials to your server, those people’s data was exposed. Tell the brand that was impersonated through its abuse or security contact, and consider whether you have legal duties: see Personal data breach.

Confirm it is fixed

Prevent it

When to get help

Ask your host or a security professional if phishing pages keep returning after removal, if the server runs many customer sites, if you find a credential file with real victims’ data, or if law enforcement contacts you. Keep the evidence archive until any investigation is closed.

Sources