Phishing and Fake Login Forms for NZ Schools

Quick answer

A fake login form is a phishing page that mimics a real one — the school portal, Microsoft 365, Google Classroom, a staff intranet — and captures the credentials the user types into it. The reason fake-login-form phishing is so common against NZ schools is that the scanning tools bots use to find vulnerable sites routinely surface exposed secrets, exposed admin panels, and exposed credential files; those leaks give attackers everything they need to make a convincing fake. Detection hinges on three signals: the URL does not match the real one, the form posts to a different domain than the page is served from, and the page is missing the security headers that a legitimate site would always set.

For the broader phishing picture — how to spot a phishing email, what to do when a student clicks, the legal obligations under the Privacy Act 2020 — see the Phishing Hub for NZ Schools and How to Spot Phishing Emails, Scam Texts and Fake Google Alerts.

Why fake-login-form phishing keeps working against NZ schools

A fake login form does not need to be perfect. It needs to be good enough that the user does not look twice at the address bar before typing their password. The phishing page can copy the layout, fonts, and brand colours of the real portal from public sources — most NZ school websites are visible to everyone, including the login page if the school has not set proper access controls (1).

What makes this particularly hard for NZ schools is the data path that feeds it:

• The NZAI scanner's findings across NZ school sites frequently include exposed .env files, exposed phpinfo or phpMyAdmin pages, open directory listings, exposed git repositories, and leftover WordPress admin panels. Each of these is a source of credentials or login URLs that an attacker can use to make the fake more convincing (2).
• A single exposed admin URL — even if it returns 403 — tells the attacker the school runs WordPress, Joomla, Moodle, or whatever platform it is. That is enough to choose the right template for the fake login.
• The actual phishing email can be drafted from public staff lists (many NZ schools publish staff directories), public school newsletters (parents' first names visible), and public domain registrations (admin email addresses).

The result is a phishing campaign that looks, reads, and visually behaves like a real school communication. The only technical giveaways are in the URL, the form action, and the response headers.

Treat any finding of an exposed file or admin panel as a phishing risk, not just a configuration issue. The leak that looks harmless — /.git/ returning 403 — is exactly the signal an attacker needs to make a convincing fake of your portal.

What a fake login form looks like — three things to check

A phishing page is almost always served over HTTPS now (free Let's Encrypt certs are widely used by attackers). So the padlock in the address bar is not a reliable signal. Three things that are reliable:

1. The URL does not match the real one

A real school portal lives at a stable, predictable domain — portal.yourschool.nz or login.microsoftonline.com for Microsoft 365. A phishing page lives at a domain that looks like the real one but is not:

• portal.yourschool.nz-login.attacker-domain.com — subdomain trick
• yourschool-portal.attacker-domain.com — domain concatenation
• yourschool.nz.attacker-domain.com/login — path-based
• yourschoo1.nz — character substitution (the l is a 1)

Hover over the link in an email, do not click, and read the actual destination. If the destination does not match the real portal's domain exactly, do not log in (1).

2. The form posts to a different domain than the page is served from

In a real login page, the form's action attribute points to the same domain as the page — you are on https://login.microsoftonline.com/... and the form posts back to https://login.microsoftonline.com/.... In a phishing page, the page is served from a domain that looks right but the form posts somewhere else entirely.

This is checkable from the browser: right-click the login form, choose Inspect, look for the <form action="..."> attribute, and confirm the URL is the same origin as the page. If the form action is on a different domain, the credentials will be exfiltrated to that other domain the moment the form is submitted (3).

3. The page is missing the security headers that a legitimate site would always set

A real NZ school portal will set:

• Strict-Transport-Security — required for any HTTPS-only site
• Content-Security-Policy with form-action 'self' — restricts where the login form can post
• X-Frame-Options or CSP frame-ancestors — prevents the page being framed on a phishing page
• Referrer-Policy — limits where the URL gets sent

A phishing page typically sets none of these. Open DevTools (F12), switch to the Network tab, click any request, and inspect Response Headers. Empty headers in this list are a strong signal the page is not what it claims to be (4).

For the full set of recommended security headers with copy-paste fixes for nginx, Apache, Express and Cloudflare, see Security Headers Explained for NZ Sites. A free scanner that checks the headers on your own school portal is at the Free Website Security Check.

How exposed-secret scan findings connect to phishing campaigns

This is the part most phishing-awareness training skips. The NZAI scanner finds exposed files and admin panels; those findings are usually treated as "configuration issues". But they are also the raw material for phishing.

A concrete example. Suppose the scanner finds:

• /.env exposed — contains a database password
• /wp-admin/ accessible — confirms the site runs WordPress
• A staff email address on the public website

An attacker now has:

• A list of staff emails to target
• Confirmation the portal they need to fake is a WordPress login
• (Often) the admin URL pattern to use in the phishing email link

The phishing campaign that follows is not generic. It is tailored to your school, uses your real portal's login page (copied from screenshots, archive.org, or simply from a previously-leaked image), and arrives in a teacher's inbox looking exactly like an internal IT communication asking them to re-confirm their credentials because of a "security update".

The fix is not just to clean up the exposure (although that matters). The fix is to recognise that every exposed file is a phishing campaign starter pack.

Detection patterns for fake-login-form phishing

For staff and IT teams, here is a decision flow that catches most fake-login-form phishing.

When you receive an email asking for credentials

• Is the link's actual destination the real portal's domain? If not, do not click. Hover, do not click.
• Does the email match the real sender? A real IT team email will come from the school's domain or a known vendor (Microsoft, Google). A phishing email often comes from a free webmail address or a similar-looking domain.
• Is the request urgent or threatening? "Your account will be locked in 24 hours" is the single most common phishing pressure tactic.
• Does the message ask you to re-confirm credentials by logging in? Real IT teams reset passwords through official channels, not by email links.

When you are on a login page and unsure

Open DevTools (F12) and check three things:

1. Network → Response Headers. Look for Strict-Transport-Security, Content-Security-Policy, X-Frame-Options. Missing = suspicious.
2. Elements → find the form. Look for <form action="...">. Is the action on the same domain as the page? If not = phishing.
3. Console → check for mixed content warnings. Mixed content (HTTPS page loading HTTP resources) on a real login page is unusual; on a phishing page it is common.

When you have already typed credentials into a suspected phishing page

Stop reading now and:

1. Change the password immediately from a different device, on the real portal (typed into the address bar, not from a link).
2. Enable multi-factor authentication if it is not already on (see MFA Setup Guide for Everyone in New Zealand).
3. Check the account's recent activity for logins from places you have not been.
4. Tell IT — phishing that succeeded is reportable under the Privacy Act 2020 if it touches student or staff data (5).
5. Tell the school community — phishing that worked on one staff member will be retargeted at others.

For the full incident playbook including what to do when a student clicks a phishing link, see What to Do When a Student Clicks a Phishing Link.

Common fake-login-form patterns against NZ schools

From running the NZAI scanner and the broader phishing-incident reports through CERT NZ, the most common fake-login-form patterns targeting NZ schools are:

• Microsoft 365 / Google Workspace credential capture. The phishing page looks like the real Microsoft or Google login. The URL is on a free hosting provider or a lookalike domain. Targets teachers and admin staff.
• School portal / LMS login capture. The phishing page mimics the school's own portal (Moodle, SEQTA, Hero, SchoolBridge, Kamar). Targets students and parents. The fake looks like the real one because the school's branding is public.
• "Verification required" landing pages. The phishing email contains a link to a page that says "to continue using your account, please verify your password". The page is a fake login form. The verification step is the credential capture.
• Fake IT support / helpdesk. The phishing email is from "IT support" asking the recipient to log in to a helpdesk portal to "fix a ticket". The portal is a fake login form.
• Parent payment portal phishing. The phishing email targets parents, claiming a fee is overdue, with a link to a "payment portal". The portal is a fake credit-card capture form. Common around the start of school terms.
• Google Classroom / Microsoft Teams impersonation. Targets students especially; the phishing email looks like a class invitation or assignment notification.

Phishing targeting NZ schools usually exploits three things: public staff/parent directories, public branding on the school website, and any exposed admin panels or credential files. Tighten all three and most campaigns will pass your school by.

School-context checklist — what every NZ school should do this term

For NZ schools and small kura, the following controls close the most common fake-login-form attack paths:

• Enable MFA on every staff and student account that has access to school data. See the MFA Setup Guide for Everyone in New Zealand.
• Set Content-Security-Policy: form-action 'self' on the school portal. This stops any third-party script from rewriting a login form's action — a defence against some advanced phishing kits. See Content-Security-Policy Deep Dive for NZ Sites.
• Tighten the staff directory — move it behind a login, or remove direct email addresses and replace with a contact form. Each public staff email is one more phishing target.
• Lock down exposed admin panels — WordPress, Moodle, phpMyAdmin, and similar. Run the free scanner to find them.
• Rate-limit the login endpoint — see Rate Limiting and Bot Protection for NZ Sites. Most fake-login-form phishing kits submit credentials in real time as users type them; rate-limiting stops the kit's submission loop from working.
• Set up DKIM, SPF, and DMARC on the school's email domain. These do not stop phishing of your users, but they stop attackers spoofing your domain to phish others. CERT NZ has guides on each (6).
• Run a phishing simulation with staff and seniors once a term. The CERT NZ phishing simulation guide is a good starting point.

Reporting and responding to a phishing incident

If a staff or student account is compromised through a fake login form, the response under the NZ Privacy Act 2020 and the broader CERT NZ guidance is:

• Contain: change the password, force sign-out of all sessions, disable the account if needed.
• Assess: what data was accessible? Was student data in scope? Was the breach "serious" under the Act's threshold (harm to individuals, financial loss, etc.)? (5)
• Notify: the school leadership, the school's DPO if there is one, and CERT NZ via cert.govt.nz/report.
• Notify the Privacy Commissioner if the breach is serious and the threshold is met. The OPC's "Notify Us" tool is the standard channel (5).
• Document: what happened, when, what data was exposed, what actions you took.

For the full incident playbook covering containment, eradication, recovery and post-incident review, see Incident Response for NZ Schools.

How to teach fake-login-form detection to staff and students

For school leaders, the most effective phishing training has three properties:

• It uses real-looking examples that staff and students will actually receive. The CERT NZ guide has NZ-context examples.
• It rewards reporting, not just avoidance. A staff member who reports a phishing email should be thanked — not embarrassed for not spotting it.
• It runs often — quarterly at minimum. Phishing patterns change; training that is two years old is stale.

For students, age-appropriate lessons are in the Cyber Safety Curriculum Alignment guide. For staff, the Building Cyber-Safe Habits as an NZ Educator guide covers the broader safety pathway.

Common mistakes when defending against fake-login-form phishing

From CERT NZ's published incident patterns and the NZAI scanner's findings across NZ schools, the most frequent missteps are:

• Telling users to "look for the padlock". HTTPS is free and universal; even phishing sites have it now. The padlock is no longer a reliable signal.
• Telling users to "hover over the link" without teaching them what a real destination looks like. Hovering reveals a URL, but most users do not know how to read one.
• Training once and never again. Phishing patterns evolve faster than annual training.
• Punishing staff who click. The staff member who reports a successful phishing click is your best early warning system. Punishing reporting stops the reporting.
• Not running the school's own site through a scanner. The NZAI free scanner finds the exposed .env, exposed admin panel, and exposed credential file that the attacker will use to craft the phishing. Most NZ schools have not run their own site through a free scan recently.
• No monitoring of the school's brand outside its own domain. Tools like Google Alerts and PhishTank can catch lookalike domains registered by attackers.

Knowledge check

Test your understanding of fake-login-form phishing with these questions. Click or tap each card to flip it and see the answer.

Sources and references

[1] CERT NZ. (2025). Phishing — what to do if you've been hooked. https://www.cert.govt.nz/individuals/guides/phishing/

[2] CERT NZ. (2025). Critical controls for small organisations. https://www.cert.govt.nz/

[3] Mozilla. (2025). MDN Web Docs — Form action and cross-origin submissions. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form

[4] Mozilla. (2025). MDN Web Docs — Content Security Policy (CSP). https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

[5] New Zealand. Parliament. (2020). Privacy Act 2020. https://www.legislation.govt.nz/act/public/2020/0031/latest/whole.html

[6] CERT NZ. (2025). Email security — SPF, DKIM and DMARC. https://www.cert.govt.nz/it-specialists/guides/email-security/

[7] Netsafe. (2025). Online safety for schools. https://www.netsafe.org.nz/

What to do next

• Run the Free Website Security Check on your school portal. The scanner finds exposed .env files, exposed admin panels, and exposed credential files — the exact raw material a phishing campaign needs to make a convincing fake of your portal.
• For the broader phishing pathway covering email, text message, and fake Google Alert phishing, see How to Spot Phishing Emails, Scam Texts and Fake Google Alerts and the Phishing Hub for NZ Schools.
• For the specific case of a student who has clicked a phishing link, see What to Do When a Student Clicks a Phishing Link.
• For the response-side (containment, eradication, recovery, post-incident review) when a phishing credential capture has succeeded, see Incident Response for NZ Schools.
• For the response-header side (CSP, HSTS, X-Frame-Options) that prevents many phishing pages from working at all, see Security Headers Explained for NZ Sites.
• For the MFA side — the single most effective control when a credential has been phished — see MFA Setup Guide for Everyone in New Zealand.
• Phishing and Fake Login Forms for NZ Schools — how exposed-secret scan findings connect to phishing campaigns, with fake-login-form detection and NZ Privacy Act 2020 response steps.
• Content-Security-Policy Deep Dive for NZ Sites — what unsafe-inline, unsafe-eval, nonces, hashes, wildcards and report-only mode actually do, with per-directive copy-paste fixes for nginx, Apache and Express.
• Rate Limiting and Bot Protection for NZ Sites — why scan-probing differs from real attacks, with copy-paste nginx limit_req and fail2ban-style heuristics for nginx, Apache, mod_evasive and Cloudflare.