Security Recovery

A phishing or security warning on your own site

The warning is applied by somebody else and removed by somebody else. What you control is whether the cause is actually gone — and that is the part that determines whether the warning comes back.

The problem

A warning is a third party's conclusion about your site

Browsers, security vendors and search engines each maintain their own view of whether a site is dangerous, and they reach it from their own signals: scanning, crawl behaviour, reports from users, and the content actually served. When a warning appears it is that party's conclusion, and the only influence you have is over the evidence they are looking at. Fixing the site is what changes the evidence. Asking for a review before that is asking them to look again at the same thing.

A browser or search engine warns visitors that the site is deceptive or unsafe
A security vendor has flagged the domain and a partner or payment provider has noticed
Hosting has suspended the account or restricted it pending a review
The site redirects visitors to a destination nobody configured
An unexpected page has been indexed on the domain
Email from the domain is being filtered or blocked
The site looks normal to you and the warning persists
A previous cleanup was done and the warning returned

Who this is for

The people who usually bring us this problem

Someone whose site has just been flagged

Visitors are seeing a warning, and you need to establish what triggered it before anything else.

Someone whose flag returned after a cleanup

The site was cleaned, the warning was lifted, and it is back — which means the cause was not fully removed.

Someone flagged by a security vendor rather than a browser

A partner, payment provider or email filter has acted on a reputation signal and you need the underlying position established.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

The flag is not ours to remove, and no timeframe is ours to give

Removal is a decision made by whichever party applied the warning, against their own criteria and on their own schedule. What can be done is to establish and fix the cause and then submit the site for review with that evidence. Any provider offering a removal timeframe is describing somebody else's process, and any provider offering removal without fixing the cause is arranging a second warning.

A warning is frequently a symptom of a compromise

Phishing warnings usually mean pages are being served that you did not publish, or that the domain is being used for something else — a redirect, an injected page, a subdomain nobody watches. Treating the warning as the problem rather than as the report of a problem is how a site gets reviewed, cleared and flagged again.

Reputation damage outlives the warning

A warning is visible to visitors for as long as it is displayed; the reputation signals behind it, and the decisions third parties made on the basis of it, persist longer. Email deliverability, partner integrations and payment providers may each have acted independently, and each has to be addressed separately.

The visible site and the served site are different things

Malicious content is frequently served conditionally — to particular referrers, user agents or regions — so the site looks clean from your browser and is not. Establishing what is actually served to a visitor is part of the diagnosis, and it cannot be done by looking at the site the way you normally do.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

Establishing what triggered the flag

What the reporting party says, what their published criteria are, and what the site is actually serving. The warning itself is the first evidence, and its wording frequently indicates which signal was triggered — malicious content, deceptive behaviour, or an unsafe resource.

What the site serves, as a visitor would see it

Requests made the way a browser, a crawler and a mobile visitor would make them, including the conditional behaviours that serve different content by referrer, user agent or location. A site can look entirely clean to its owner and serve something else to everyone else.

Compromise diagnosis and removal

The general recovery discipline where the warning came from a compromise: what was changed, where it persists, and what has to be removed before a review is worth submitting. This is the same work as any recovery engagement, entered from a different starting point.

Injected page and redirect identification

Pages that were not published, redirects that were not configured, and subdomains nobody monitors. A flagged domain is frequently being used through a part of it the owner has forgotten exists, and the main site being clean is not sufficient.

The submission, with its evidence

Preparing and submitting the review request to the party that applied the flag, with the findings and the remediation attached. What can be controlled is the completeness of what is submitted; what cannot be controlled is the decision or its timing.

The other parties who acted

Security vendors, email filters, hosting providers, payment processors and partners who may each have taken their own action from their own signal. Each has a separate process, and the warning being lifted does not automatically restore any of them.

Email and domain reputation

Where the domain's mail has been affected: authentication records, sending reputation and the provider processes for reconsideration. Frequently the consequence that lasts longest and the one nobody thinks to check while the browser warning is the visible problem.

Prevention, so the same flag is not earned twice

The exposure that allowed it, closed — an unpatched component, an exposed administrative interface, an abandoned subdomain, a credential reused from a breach elsewhere. A review that clears a site still carrying its original exposure is a delay rather than a resolution.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

Read the warning before touching anything
What it says, who issued it, and what criteria it references. It is the reporting party's own statement about what they found, and it narrows the diagnosis more than any amount of inspection.
Look at the site the way a stranger does
From outside, as a browser, as a crawler, as a mobile visitor, and with the conditional headers that malware uses to decide what to serve. The owner's view of the site is the one least likely to show the problem.
Fix the cause before submitting anything
A review request against an unremediated site is asking the reporting party to look again at the same evidence. The submission follows the fix, and it is submitted with the findings so the reviewer has something specific to assess.
Check the whole domain, not the main site
Subdomains, forgotten staging environments, abandoned applications, parked records. A flagged domain is often being used through a part of it that nobody has looked at in years, and the main site being clean does not clear it.
Address the consequences separately
Each party that acted on the signal has its own process: the security vendor, the email provider, the payment processor, the host. They are not resolved by the warning disappearing, and each is tracked as its own item with its own owner.
State what is not known
Where the trigger cannot be established from the available evidence, that is said — along with what was checked and what remains unexplained. On a security warning an over-confident account is worse than an incomplete one, because the reader is deciding whether it is safe to trust the site.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

Diagnosis

What the warning says, who issued it, and which criteria it references
What the site serves to a browser, a crawler and a mobile visitor
The whole domain: subdomains, forgotten environments, unexpected pages
Whether the cause is a compromise, and if so, what was changed
What the trigger was, or a clear statement that it could not be established
Which other parties have acted on the signal

Remediation

The cause removed, not the symptom
Injected pages, redirects and unmonitored subdomains addressed
The exposure that allowed it, closed
The site verified clean by the same checks that found the problem
Nothing removed that the site needs, verified by exercising it afterwards

Reconsideration

The review submission, with findings and remediation attached
The other parties contacted, each with its own process
Email and domain reputation addressed where affected
A written account of what was found, what was changed and what was checked
What remains outside our control, stated plainly

Under the hood

Architecture and technology

Who can apply a warning, and why

Browser vendors, from their own scanning and from user reports
Security vendors, whose signals feed browsers, filters and partners
Search engines, from crawling and from their own abuse detection
Hosting providers, from their own monitoring of the accounts they host
Email providers, from sending reputation and authentication records
Payment processors and partners, from their own risk assessment

What a warning usually means

Pages are being served that were not published
A redirect sends visitors somewhere nobody configured
A subdomain or forgotten environment is being used
An injected resource is loaded from the domain
A credential or account has been compromised and used
The domain has been associated with a campaign through a part of it nobody monitors

Related work

Where we have done this

Engagements where this capability was the substance of the work rather than a line item.

Fintech & capital markets

Search engineering at stockbroking scale

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

225Msitewide impressions

All case studies →

Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

The site is compromised

Containment, eradication and verification — the general recovery discipline.

Hacked website recovery

The flag arrived through WordPress

Removing malware from a WordPress site and proving it is gone.

WordPress malware removal

You want this not to happen again

Assessment, access control and a remediation order across the estate.

Website security

Search visibility was affected

Recovering a position after a site has been removed or demoted.

SEO traffic recovery

Questions

Frequently asked

Can you get the warning removed, and how long will it take?

We cannot remove it and we will not give a timeframe, because both belong to whoever applied it. Browsers, security vendors and search engines each decide against their own criteria on their own schedule, and any provider quoting a removal period is describing somebody else's process. What we can do is establish what triggered the flag, fix the cause, verify the site is clean by the same checks that found the problem, and submit the review with that evidence. That is the part within anyone's control, and it is also the part that determines whether the warning comes back.

The site looks fine to us. How can it be flagged?

Because the owner's view is the least likely to show the problem. Malicious content is frequently served conditionally — to particular referrers, user agents or regions — so it appears to a visitor and not to you. It can also be on a subdomain, in a forgotten staging environment, or in a redirect nobody configured, none of which you would see by visiting the site. Establishing what is actually served, from outside and as a stranger would see it, is the first step of the diagnosis rather than an assumption that can be made from looking.

Do you have experience with this?

One published engagement involved a phishing and antivirus flag being identified and removed and domain trust being restored, and it is described on the case study page rather than restated here. What the record deliberately does not claim is a recovered trust score, because none was measured — the process is described and the outcome is not embellished. That is the honest version of this work: the flag being addressed and the cause removed, without a number attached to a reputation nobody can measure directly.

What if the warning returns after the site is cleaned?

It means something was missed, and it is the most common reason this work is commissioned twice. The usual causes are a persistence mechanism left in place, a part of the domain nobody checked, or the original exposure still open so the site was compromised again after being cleaned. Our removal is verified against the same checks that found the problem rather than by a different and weaker test afterwards, and the whole domain is examined rather than the main site — because a flag on a domain can be earned through a part of it that nobody has looked at in years.

Our email is being blocked too. Is that the same problem?

It is a separate consequence of the same signal, and it is addressed separately. Email providers, security vendors, hosting providers and payment processors each act on their own assessment, so the browser warning being lifted does not automatically restore any of them. Email is frequently the longest-lasting effect and the one nobody checks while the visible warning is the immediate problem — so authentication records, sending reputation and the provider's own reconsideration process are tracked as their own items with their own owners.

Related capabilities and work

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.

Discuss your engineering challenge View our work