Hacked website recovery help in New Zealand is available — and if you act quickly and systematically, most site owners can recover fully within 24 to 72 hours. The key is not to panic, not to delete anything yet, and to follow a proven, ordered process. This guide gives you exactly that, written specifically for New Zealand business owners and site administrators who are not security experts.

What Are the First Signs Your Website Has Been Hacked?

Before you can fix anything, you need to confirm you are actually dealing with a hack rather than a software bug or hosting outage. Common signs include:

Google Safe Browsing warnings appearing when visitors try to reach your site (Google Search Central documents these warning types in detail)
Your site redirecting to an unfamiliar or suspicious URL
Your web host suspending your account with a notice about malicious files
Customers reporting spam emails appearing to come from your domain
Unexpected admin users appearing in your CMS dashboard
Your site appearing in Google search results with spammy, irrelevant text beneath your page titles (known as Japanese keyword hack or pharma hack)
Strange files in your server directories that you did not upload

If you see two or more of these signs together, treat it as a confirmed incident and begin recovery immediately.

Step 1: Don't Panic — Gather Information First

Rushing to delete files or restore a backup immediately can actually destroy evidence you need to understand how the breach occurred. Before touching anything:

Put Your Site Into Maintenance Mode

If your site is still partially functional, use your CMS maintenance mode or ask your host to temporarily take it offline. This stops visitors from being exposed to malicious content and limits further damage.

Take Screenshots and Notes

Document everything you can see:

The URL and content of any redirect pages
Names of any unfamiliar files you can see in your file manager
Any unusual admin user accounts, including their email addresses and registration dates
Error messages your hosting control panel is displaying

This documentation matters if you later need to report the incident to CERT NZ (New Zealand's official Computer Emergency Response Team) or your cyber insurer.

Check Google Search Console

If you have Google Search Console set up (and you should), log in immediately:

Go to Security & Manual Actions → Security Issues
Google will often have already detected and categorised the attack type
Download or screenshot the full report — you will need it later to request a review

Step 2: Secure Your Accounts Before Anything Else

If an attacker still has valid credentials, cleaning your site without changing passwords is pointless — they will simply re-infect it.

Change All Passwords Immediately

Change passwords for:

Your hosting control panel (cPanel, Plesk, or your host's custom panel)
FTP and SFTP accounts
Your CMS administrator account (WordPress, Drupal, Joomla, etc.)
Your domain registrar account
Your database (MySQL/MariaDB) users associated with the site
Any email accounts used for site administration

Use a password manager to generate long, random passwords (20+ characters). Do not reuse passwords across accounts.

Enable Two-Factor Authentication (2FA)

Enable 2FA on every account that supports it, starting with your hosting control panel and CMS. Most major New Zealand hosting providers — including those offering shared, VPS and cloud hosting — support TOTP-based authenticator apps such as Google Authenticator or Authy.

Revoke Unknown or Suspicious Sessions

In your CMS, look for a "Log out all other sessions" or "Revoke all sessions" option and use it. In WordPress, this is found under Users → Your Profile → Sessions at the bottom of the page.

Step 3: Identify the Scope and Type of Attack

Understanding what kind of hack you are dealing with shapes everything that follows.

Common Attack Types Affecting New Zealand Websites

Malware injection — malicious PHP or JavaScript code inserted into your theme files, plugin files, or core CMS files. Often used to redirect visitors or mine cryptocurrency.

SQL injection — an attacker exploited a vulnerability in a form or URL parameter to extract data from or write data to your database. OWASP (the Open Web Application Security Project) lists SQL injection as one of the most critical web application security risks in its OWASP Top 10.

Cross-Site Scripting (XSS) — malicious scripts injected into pages that execute in visitors' browsers, often to steal session cookies or credentials.

Credential stuffing / brute force — attackers used stolen or guessed usernames and passwords to log into your CMS or hosting account directly.

Backdoor installation — the attacker has left a hidden PHP file (often with a name like wp-load.php, x.php, or a string of random characters) that allows re-entry even after you clean the obvious malware.

Supply-chain attack via plugin or theme — a third-party plugin or theme you installed contained malicious code, either from the beginning or after it was compromised by the plugin author's own account being hacked.

Use Your Hosting Logs

Ask your host for access to, or copies of, your access logs and error logs for the past 30 to 90 days. These are typically found at:

cPanel: /home/yourusername/logs/ or via the Logs section in cPanel
Plesk: Websites & Domains → Logs
VPS/dedicated: /var/log/apache2/access.log or /var/log/nginx/access.log

Look for:

POST requests to files that should never receive POST data (e.g., image files, static pages)
Repeated login attempts from overseas IP addresses
Requests to file paths you do not recognise
Large data transfers you did not initiate

Step 4: Clean the Infection

Option A: Restore From a Clean Backup (Recommended If Available)

If your host or your own backup solution has a verified clean backup from before the attack, restoring it is often the fastest path to a clean site — but only if you:

Confirm the backup predates the infection (check your logs to estimate when the attack began)
Change all passwords again after restoring (the attacker may have obtained credentials before the backup date)
Immediately update every theme, plugin, and CMS core to the latest version before putting the site back online

Most New Zealand hosting providers retain daily automated backups for 7 to 30 days. Check your hosting control panel under Backups or contact your host's support team.

Option B: Manual Cleaning (When No Clean Backup Exists)

If you have no reliable backup, you will need to manually find and remove malicious code.

For WordPress Sites

WordPress powers a large proportion of New Zealand business websites. These steps apply directly:

Download a fresh copy of WordPress core from wordpress.org and compare your core files against it. Do not edit the live server files directly — download a copy of your site first via SFTP.
Check these locations specifically for injected code:
- wp-content/themes/your-active-theme/functions.php
- wp-content/themes/your-active-theme/header.php
- wp-content/themes/your-active-theme/footer.php
- All plugin files in wp-content/plugins/
- wp-config.php (look for added code above or below the standard configuration lines)
- The root .htaccess file (look for redirect rules you did not create)
Search for common malware signatures. Using an SFTP client or your host's file manager, search all PHP files for these strings which frequently appear in malware:
- eval(base64_decode(
- eval(gzinflate(
- preg_replace('/./e',
- str_rot13(
- assert(
- FilesMan (common web shell name)
Check the database. Use phpMyAdmin (available in most cPanel and Plesk installations) to examine your wp_posts and wp_options tables. Look for:
- <script> tags in post content that you did not write
- Unfamiliar URLs in the siteurl or home options
- Base64-encoded strings in option values
Remove all unknown admin users via WordPress Admin → Users. If you cannot log in, remove them directly via phpMyAdmin in the wp_users and wp_usermeta tables.
Use a reputable scanning plugin. Wordfence Security (free tier available) and Sucuri Security are both widely used and can scan your files against known clean versions. Install them, run a full scan, and follow their removal recommendations.

For Other CMS Platforms

Joomla: Check configuration.php, all template files, and the administrator/ directory for unfamiliar files. Joomla's built-in Joomla! Update component will verify core file integrity.
Drupal: Run drush core:status and compare file checksums using drush php-eval "print drupal_get_hash_salt();" — consult the Drupal Security Team advisories for your version.
Custom PHP sites: Any PHP file containing eval(, base64_decode(, or system( that you did not write yourself should be treated as suspicious.

Look for and Remove Backdoors

After cleaning visible malware, search specifically for backdoor files. These are often hidden in:

Uploads directories (e.g., wp-content/uploads/ — PHP should never need to execute from here)
Directories named to look legitimate, such as wp-includes/cache/ or /images/
Files with timestamps that do not match surrounding legitimate files

You can prevent PHP execution in your uploads directory by placing a file named .htaccess inside wp-content/uploads/ with this content:

Step 5: Harden Your Site Before Going Back Online

Cleaning malware without fixing the underlying vulnerability means you will be hacked again, often within hours. CISA (the U.S. Cybersecurity and Infrastructure Security Agency), whose guidance is widely adopted in New Zealand government and enterprise security frameworks, emphasises that patching and hardening must accompany any incident response.

Update Everything

Update WordPress core, all plugins, and all themes to their latest versions
Remove any plugins or themes that are no longer maintained (no updates in 12+ months) or that you are not actively using
Delete (do not just deactivate) unused plugins and themes — deactivated plugins can still be exploited

Implement a Web Application Firewall (WAF)

A WAF sits in front of your website and blocks common attack patterns before they reach your code. Reputable options that work well for New Zealand websites include:

Cloudflare (free tier available; also provides DDoS protection and a New Zealand-accessible CDN)
Sucuri WAF (paid; specialises in CMS protection)
Wordfence (WordPress-specific; free and paid tiers)

Restrict File Permissions

Incorrect file permissions are a common way attackers maintain or expand access. On a Linux-based server (standard for most NZ web hosting), set:

Directories: 755 (use chmod 755 /path/to/directory)
PHP files: 644 (use chmod 644 /path/to/file.php)
wp-config.php: 600 or 640 (more restrictive — only the owner can read it)

Disable XML-RPC (WordPress)

If you do not use the WordPress mobile app or Jetpack's remote publishing features, disable XML-RPC entirely, as it is a frequent brute-force attack vector. Add this to your .htaccess file:

Order Deny,Allow Deny from all

Limit Login Attempts

Install a login-limiting plugin such as Limit Login Attempts Reloaded or use Wordfence's built-in brute-force protection to block IP addresses after repeated failed login attempts.

Step 6: Report the Incident

Report to CERT NZ

CERT NZ (cert.govt.nz) is New Zealand's government-backed cyber security agency. Reporting your incident:

Helps CERT NZ track attack trends across New Zealand
May result in useful guidance specific to your situation
Is completely free and confidential
Can be done online at cert.govt.nz/report

CERT NZ regularly publishes quarterly threat reports that identify the most common attack vectors targeting New Zealand websites and businesses — reviewing these can confirm whether your attack matches a known campaign.

Notify Affected Parties If Required

Under the Privacy Act 2020, New Zealand businesses are required to notify the Office of the Privacy Commissioner (OPC) and affected individuals if a privacy breach is likely to cause serious harm. If your hacked site stored customer data (names, emails, payment information, health data), contact a legal advisor and the OPC promptly. Report to the OPC at privacy.org.nz.

Notify Your Domain Registrar

If your domain's DNS settings were altered as part of the attack (check by comparing your current DNS records against what they should be), notify your registrar immediately. New Zealand domains under .nz are managed through the Domain Name Commission (DNC) — contact your registrar first, and the DNC if your registrar is unresponsive.

Step 7: Request Search Engine Review

If Google flagged your site, you need to formally request a review after cleaning.

Google Search Console Review Request

Log into Google Search Console
Go to Security & Manual Actions → Security Issues
Click Request a Review
In the text field, describe specifically what you found, what you removed, and what security measures you have now implemented. Be detailed — vague requests are frequently rejected.
Allow 1 to 3 business days for Google to re-crawl and respond

If your site received a Manual Action (a human penalty rather than an algorithmic flag), the review request is found under Security & Manual Actions → Manual Actions instead.

Bing Webmaster Tools

If you have Bing Webmaster Tools set up, check it for any security notices and use the URL Inspection tool to request re-crawling of key pages.

Step 8: Prevent Future Attacks

Recovery is only complete when you have systems in place to detect and prevent the next attack.

Set Up Automated Backups With Off-Site Storage

Configure daily automated backups that are stored somewhere separate from your web server — an S3-compatible bucket, Google Drive, or a dedicated backup service. Verify that backups are actually completing and are restorable. Many New Zealand hosts offer this as an add-on or include it in higher-tier plans.

Install a Security Monitoring Plugin or Service

Tools like Wordfence, Sucuri, or iThemes Security (now SolidWP Security) will alert you by email if:

A plugin with a known vulnerability is installed
A core file has been modified
A new admin user is created
Login attempts exceed a threshold

Use HTTPS Correctly

If your site is not already using HTTPS with a valid SSL/TLS certificate, implement it now. A free certificate from Let's Encrypt is available via most New Zealand hosting control panels. Ensure all HTTP traffic redirects to HTTPS via your .htaccess file or server configuration.

Adopt Principle of Least Privilege

Give CMS users only the permissions they actually need (editors should not be administrators)
Create a dedicated, lower-privilege database user for your CMS with only SELECT, INSERT, UPDATE, and DELETE permissions — not DROP or FILE privileges
Disable FTP and use SFTP only; consider restricting SFTP access by IP address if your own IP is static

When to Call a Professional

Not every site owner should attempt manual malware removal alone. Consider hiring a professional New Zealand web security specialist if:

Your site handles sensitive customer data such as payment card information or health records
You have been hacked multiple times despite attempting to clean it yourself
Your site is a significant source of revenue and every hour of downtime has a measurable cost
The logs reveal a sophisticated, targeted attack rather than automated scanning
You have no usable backup and your site has hundreds or thousands of files to audit

Search for professionals who hold certifications such as CEH (Certified Ethical Hacker), OSCP, or CompTIA Security+, or who are members of the New Zealand Internet Task Force (NZITF). Get a written scope of work and confirm they will provide a post-clean report explaining what was found

Hacked Website Recovery Help in New Zealand: A Complete Step-by-Step Guide