One institutional domain, dozens of devolved IT teams, a population that renews by a third every year and a calendar that tells attackers exactly when to strike. A DNS-verified feed of active phishing domains gives every part of that estate the same answer to one question: is this host currently hosting a phishing page?
Everything that makes a campus work also makes it hard to defend with the tools written for a single corporate perimeter.
Ask a CISO at a research university how many people can publish a web page under the institutional domain, and the honest answer is usually a shrug followed by an estimate. Devolved IT is not a failure of governance; it is how research institutions have always worked, and it means the security model has to assume partial control rather than total control.
Faculties run their own web servers. Research groups stand up project sites for a three-year grant and forget them for five. A department buys a survey platform with a purchasing card and points a CNAME at it. Central IT owns the identity provider, the network core and the mail gateway, but it does not own the long tail — and the long tail is where an attacker finds a stale subdomain that still resolves and still looks official.
A commercial employer onboards a few percent of its headcount in a year. A university replaces something close to a third of its community every autumn, arrives at a fixed date with thousands of people who have never seen an institutional email before, and gives all of them credentials on day one.
Freshers do not know what the bursar's office sounds like, and nobody has yet told them the service desk will never ask for a password — the awareness module is scheduled for week four. Enrolment week, the fee-payment deadline, the exam results window and the start of the funding round are the four moments when a badly written phish stops being obvious and starts being plausible.
Tens of thousands of laptops, phones and tablets that the institution does not own, cannot image, cannot enrol in an MDM and cannot force a browser policy onto. A student reads institutional mail on a personal phone over a mobile network, clicks a link, and no campus control has touched that request at any point — the same is true of a visiting researcher on eduroam with a machine configured by a lab in another country.
Any control that depends on managing the endpoint covers a minority of the actual traffic, which is why campus security teams tend to push protection down into the mail path and the resolver, where coverage does not depend on who bought the hardware or who configured it.
Alumni relations holds addresses for people who left decades ago and still trust anything bearing the crest; admissions holds applicants who are anxious about an offer and will click almost anything that mentions their application; advancement runs donation campaigns with real payment links. A kit hosted at alumni-giving-portal.example.org is aimed squarely at the one group with money, goodwill and no security briefing.
Managed endpoints, one identity store, one mail path, one set of policies. A university has managed endpoints for some staff, a Shibboleth or SAML federation that brokers logins to hundreds of services it does not host, a central mail gateway that a medical school or a business school may partially bypass with its own tenant, and policies that a faculty IT officer can simply decline to adopt.
Not an agent and not a policy, but a fact about a domain name — delivered in a form that a mail gateway, a DNS resolver, a service-desk web tool and a departmental script can all consume without having to agree on anything else first. One answer, four consumers, no negotiation with devolved IT required.
On campus, this means a page that copies the institution's single sign-on or webmail login screen and collects the username, password and often the second-factor code in real time. Because SSO is the front door to the VLE, the student information system, the HR and payroll portal, library resources, research data stores and HPC access nodes, one harvested credential is not one account; it is a key to the federation. The page usually lives on a lookalike host registered days earlier, and the mail carrying it names a deadline the recipient recognises.
The sector uses this term for the protection of research from theft, undue foreign influence and unauthorised transfer, particularly where work is federally funded or touches controlled technology. In practice it covers who has access to pre-publication data, how collaborations are vetted, and how research computing accounts are protected. A phished principal investigator account is a research-security incident as much as an IT one, because it exposes grant material, unpublished results and the mailbox used to talk to partner institutions.
Students, academics and professional services staff are phished with different pretexts, lose different things, and need the check applied at different points.
Fake webmail and SSO login pages timed to enrolment and exam periods, campus job offers that turn into payroll-diversion or money-mule recruitment, tuition and accommodation payment demands that spoof the bursar's office, scholarship and bursary application fees, and messages about a library fine or a suspended account that must be resolved before results are released.
A student who loses a term's fee payment to a redirected bank account is rarely made whole, and the institution absorbs the distress and the dispute. A compromised student account becomes an internal sending platform: mail from a genuine institutional address passes every authentication check the receiving side applies, so the next wave of phishing looks entirely legitimate.
The link in the message is resolved against a database of currently active phishing hosts before the student ever sees the page, whether they open it on a managed lab machine or a personal phone on eduroam.
Grant-award notifications and funder portal re-authentication requests, journal submission and peer-review invitations that route through a lookalike editorial system, conference registration and speaker-invitation lures, co-author document shares, and requests to re-enter credentials for a research data store or an HPC access node during a supposed migration.
A principal investigator's mailbox holds unpublished results, grant budgets, ethics correspondence and the entire history of a collaboration. Loss of that material is a research-security and potentially an export-control matter, not just a helpdesk ticket. The account is also a trusted sender to every partner institution on the project, which turns a local compromise into an obligation to notify people you work with.
Lookalike funder, publisher and collaboration-platform domains that are resolving today are flagged at the gateway and at the resolver, so a busy academic reading mail at midnight does not have to be the control.
Vendor invoice redirection against procurement and estates, bank-detail change requests that arrive mid-project from a plausible contractor address, payroll self-service credential pages aimed at HR, executive-impersonation transfer requests during the closing weeks of the financial year, and supplier-portal logins for the systems that pay contractors and construction partners.
This is where the largest single losses occur. A capital project invoice redirected to an attacker's account is a six-figure problem that surfaces weeks later when the real contractor chases payment. Registry and HR compromises also touch student education records and staff personal data, which pulls privacy obligations into what began as a fraud.
Finance and procurement teams get a lookup they can run against any domain in an unexpected payment instruction, and the same intelligence blocks the lookalike supplier-portal host before the credential is ever typed.
None of these are exotic. They recur every academic year, they follow the calendar, and they nearly always depend on a domain registered within the last few weeks.
An IT service desk manager can predict the shape of the year's ticket queue from the academic calendar alone. Volume spikes at registration, again at the fee deadline, again in the run-up to exams, and once more when funding calls close. What changes between years is not the pretext but the hosting: a new set of domains, registered cheaply, given a valid certificate within minutes, and burned within days.
All six patterns below share a structure: a message referencing something the recipient is genuinely waiting for, a link to a host that is not the institution, and a form at the end. The intervention point is identical in every case — decide whether the host in that link is a known, currently active phishing domain before the page renders.
That churn is precisely why a static blocklist ages badly, and why a database rebuilt daily and pruned of hosts that no longer resolve behaves differently from one that only ever grows. Deciding at the host level needs no message reading, no page sandboxing and no user training — which matters when the user is a first-year student on a personal phone.
A pixel-accurate copy of the institution's Shibboleth or webmail sign-in screen, hosted at something like sso-login-verify.example.net and mailed during enrolment week or the exam period with a warning that access expires in 24 hours. Many kits relay the second factor in real time, so a push-approval prompt arriving at a plausible moment is accepted.
New students receive an offer of flexible campus work, complete an onboarding form, and supply bank details that are used either to divert a later legitimate payment or to recruit them as a money mule. Staff variants target the HR self-service portal, changing the destination account for salary before the next payroll run closes.
Messages that impersonate the bursar's or student accounts office demand a tuition instalment, an accommodation deposit or a processing fee for a scholarship, always with a deadline tied to registration or results release. The payment page sits on a lookalike host and the loss falls on a family, which makes the reputational damage disproportionate to the sum.
Principal investigators receive award notifications, funder portal re-authentication requests, peer-review invitations or manuscript-status updates that route through a copied editorial system. The pretext is professionally worded because the attacker has read the researcher's public profile, and the target is the account that reaches every collaborator on the project.
Fake registration sites for real conferences, bogus hotel-block booking agents that harvest card details, and speaker-invitation lures aimed at academics who travel often. Departmental travel budgets and personal cards both get hit, and the fraudulent site frequently outlives the event because nobody reports it once the trip is over.
Procurement and estates receive a bank-detail change from a contractor whose domain differs by one character, often mid-way through a capital project when invoices are large and expected. The supporting portal link points to a lookalike supplier site. This pattern produces the largest single losses in the sector and is usually discovered weeks after the payment clears.
Phishing infrastructure is disposable, so the intelligence has to be perishable too.
Every candidate domain that arrives from the curated threat-intelligence and OSINT sources is resolved through rotating proxies with a ten second timeout before it is admitted, and only hosts with an active A record are retained. Domains that stop resolving are pruned rather than accumulated, which keeps the false-positive burden on a service desk low and makes a hit worth acting on. The pipeline then deduplicates, classifies each entry as phishing or malware, diffs the result against the previous day to produce a changelog, and loads it into the API and the CSV export. Full mechanics are on the API documentation page and the daily feed page.
Each step stands alone, needs no departmental sign-off beyond its own owner, and adds coverage the previous step could not reach.
Extract link hosts at the secure email gateway and check them in batches. This covers every mailbox that still routes through the centre, including students, and needs one integration owned by one team.
Load the daily CSV into the recursive resolvers that serve wired, wireless and eduroam clients. This protects unmanaged and visitor devices, which no endpoint agent will ever reach.
Expose a small internal page or Slack command wrapping the single-check endpoint so faculty IT officers and the service desk can triage a reported link in seconds without holding an API key of their own.
Screen outbound and inbound links in the admissions CRM, the alumni and advancement mail platform and the donation flow, so the audiences with no training and no institutional mailbox are covered too.
A phishing incident on campus rarely stays a security incident; it becomes a privacy question, a funding question and a partner question.
FERPA protects the privacy of student education records, and a compromised registry, admissions or academic-advising account is a direct route into them. Grades, transcripts, disciplinary files, disability accommodations and financial-aid detail all sit behind the same institutional login as the mailbox that received the phish. Registrars and data-protection officers are usually the first people to ask a hard question after an account compromise, and the question is rarely “how did the attacker get in” but “what records could that account see, and for how long”.
Being able to say the destination host was a known active phishing domain, blocked at the gateway on the day, is a materially better position than reconstructing access logs after the fact.
The Safeguards Rule reaches further into higher education than many people outside the sector expect. Institutions that administer federal student aid are treated as financial institutions for these purposes and are expected to maintain a documented information security program, with designated responsibility, risk assessment, and safeguards proportionate to the risk. Auditors reviewing that program look for evidence that the institution actually does something about the threats it has identified, not merely that it has listed them.
Phishing against the student financial-aid and bursar functions is one of the most obvious risks a university can name, so a documented control that screens link destinations against threat intelligence refreshed daily is the kind of specific measure that reads well in a program description and in the annual reporting that follows it.
For institutions with EU students, EU campuses or European research partners, GDPR applies to the personal data they hold, and two articles matter most. Article 32 requires security measures appropriate to the risk, judged against the state of the art and the nature of the processing. Article 33 requires notification of a personal data breach to the supervisory authority without undue delay, generally within 72 hours of becoming aware of it, and a phished mailbox containing applicant files, student records or research participant data can start that clock.
Seventy-two hours is not long when the affected account belongs to a professor at a conference in another timezone whose mailbox holds fifteen years of correspondence. Preventive controls reduce how often the clock starts; documented preventive controls also help demonstrate that Article 32 was taken seriously beforehand.
Sponsors increasingly attach research-security and export-control conditions to awards, covering who may access controlled technical data, how foreign collaborations are disclosed, and how the computing environments that hold the work are protected. Where an award references a control framework, institutions typically map their environment against catalogues such as NIST SP 800-171 or the NIST Cybersecurity Framework rather than against a statute.
A phished PI account is not only an IT ticket; it may need to be reported through the research office, assessed for whether controlled information was exposed, and explained to the sponsor. Research computing leads and export-control officers care about the same lookalike domains the security team cares about, but for different reasons.
The last obligation is contractual and reputational rather than statutory. When a faculty mailbox is compromised, the attacker's most valuable use of it is not the data inside; it is the ability to send. Mail from a genuine institutional address, signed by the institution's own infrastructure, reaching co-investigators at partner universities, editors at journals, students at other institutions and staff at funding bodies, is the highest-quality phishing lure available.
Partners notice. Collaboration agreements increasingly include security and notification terms, and a university that repeatedly becomes the launch point for phishing against its own network of collaborators finds that conversation moving from the service desk to the pro-vice-chancellor for research. Preventing the initial compromise is cheaper than explaining the outbound wave.
Institutions comparing obligations across sectors may find the government and public sector, healthcare and legal services briefs useful, since academic medical centres and university legal offices sit under those regimes too. Nothing here is legal advice; the specific obligations that bind an institution depend on its jurisdiction, its funding sources and its own counsel.
Four places the check pays for itself, and one constraint that shapes every decision about where to put it.
The highest-value insertion point, because it is the one component almost every mailbox still traverses. Whatever the gateway is, it can be made to extract hostnames from message bodies and headers and submit them for a verdict before delivery, driving a quarantine action, a header stamp or a rewritten link on a hit.
Institutions running their own IdP control the login page, and that page sees a referrer or a RelayState value on many flows. Where a login attempt originates from a host that has no business initiating an institutional authentication, checking that host against a current phishing database gives the identity team an early signal to log, alert or interrupt.
Load the daily CSV export, which carries domain,category,dns_status columns, into whatever response-policy mechanism the resolvers use. Every device that takes DNS from the campus — including personal phones on eduroam and visiting researchers' laptops — inherits the protection with no client-side change at all.
Every institution has one, it fills up with forwarded suspicious mail, and triage is slow because a human has to look at each message. Extracting the hostnames from those submissions and screening them in batches turns a queue into a sorted list, so the service desk sees confirmed hits first.
The batch endpoint takes up to 100 domains per request and returns a per-domain result, so a mail queue can be screened in blocks rather than one host at a time. Because the answer is a domain-reputation lookup rather than content analysis, no message body ever leaves the gateway; only the hostname does.
Checking the originating host will not catch every proxy kit, because the better kits relay the genuine login page directly. It catches the lazy ones, and it produces exactly the evidence an incident responder wants: a timestamped record of which lookalike domain was driving traffic at the identity provider on a given morning.
The resolver layer is also what survives the fact that a student can be reading mail in a browser the institution has never seen. Teams building this out often pair it with the wider DNS filtering and email security patterns.
The script below reads reported URLs, deduplicates the hosts, and posts them 100 at a time to the batch endpoint. It runs server-side, as the API key must always do, and it is the sort of thing one person can put in place in an afternoon.
import requests
from urllib.parse import urlparse
API_KEY = "campus_it_key" # your registered username
ENDPOINT = "https://phishingdetectionapi.com/api/v1/batch"
# URLs pulled from messages forwarded to abuse@ over the last hour
reported = [
"https://sso-login-verify.example.net/idp/profile/SAML2/Redirect",
"https://student-accounts-payment.example.org/tuition/instalment",
"https://grant-award-portal.example.com/reauthenticate",
"https://library.example.edu/renew",
]
hosts = sorted({urlparse(u).hostname for u in reported if urlparse(u).hostname})
for i in range(0, len(hosts), 100): # max 100 domains per request
chunk = hosts[i:i + 100]
r = requests.post(ENDPOINT, json={"apikey": API_KEY, "domains": chunk}, timeout=15)
data = r.json()
for item in data["results"]:
if item["is_phishing"]:
print("BLOCK {0} category={1} dns={2} confidence={3}".format(
item["domain"], item["category"], item["dns_status"], item["confidence"]))
else:
print("clear {0}".format(item["domain"]))
print("checked={0} phishing_found={1} credits_used={2}".format(
data["checked"], data["phishing_found"], data["credits_used"]))
# BLOCK grant-award-portal.example.com category=phishing/malware dns=resolves confidence=0.98
# BLOCK sso-login-verify.example.net category=phishing/malware dns=resolves confidence=0.98
# BLOCK student-accounts-payment.example.org category=phishing/malware dns=resolves confidence=0.98
# clear library.example.edu
# checked=4 phishing_found=3 credits_used=4
One credit is consumed per domain checked. Single-domain triage uses GET /api/v1/check?domain=…&apikey=…; the same fields are returned. See the API documentation and pricing.
The constraint that shapes all of this is simple: devolved departments will not adopt an agent. A faculty IT officer running a research group's own mail and web infrastructure has neither the budget nor the mandate to install a central security client on machines they do not fully control, and asking them to do so turns a two-week rollout into a two-year negotiation. Anything that requires software on the endpoint will be adopted by the parts of the institution that were already easy and skipped by exactly the parts that carry the risk. A lookup, by contrast, is a URL. A department that will never install anything will happily call an endpoint from a script it already runs, and a resolver-level feed reaches those departments whether or not they ever agree to anything.
Every ingested candidate is resolved through rotating proxies using 50 concurrent threads with a 10 second timeout, and only domains returning an active A record are kept. Hosts that stop resolving are pruned from the database rather than left to accumulate.
It changes the economics of a hit. A verdict describes infrastructure that is live now, which is why it is reasonable to act on it automatically at the gateway and the resolver instead of routing everything to a human.
The database is rebuilt every 24 hours and the feed export runs at 04:30 UTC. The pipeline diffs each build against the previous day, so the additions and removals are explicit rather than implied by a growing file.
It lets a campus security team settle the question an incident review always asks: was this domain in the feed on the morning the message arrived, or did it appear afterwards?
A single lookup returns in under 50 milliseconds, and the batch endpoint handles up to 100 domains per request. That budget is small enough to place the check inside mail delivery or an identity-provider request path without users noticing added latency.
is_phishing, category, dns_status, last_checked and confidence — enough to drive a routing decision without any further enrichment.
This is a domain-reputation lookup and a daily threat feed. It answers one question quickly and consistently: is this host currently a DNS-verified active phishing domain? It does not run a mail gateway, render or sandbox pages, analyse message content, score URLs with a live classifier at request time, perform takedowns, deliver awareness training or return registrar data. Being clear about the boundary matters when a CISO is presenting an architecture to a university's information security committee, because every layer in that diagram has to be justified by what it actually does.
Underneath the components that do those other jobs. The secure email gateway still filters, the identity provider still enforces multi-factor authentication, the awareness programme still runs, and the incident response process still exists. What the feed supplies is the shared fact all of those layers can act on, delivered the same way to a mail gateway, a resolver, a service-desk tool and a departmental script that agree on nothing else. Read the endpoint reference or compare volume tiers on the pricing page.
Screen the central mail path, publish the feed to the campus resolvers, and hand the service desk and your devolved IT teams a lookup they can run in seconds. Credits start at $59 for 10,000 lookups and the daily feed subscription starts at $499 per month.
