Website defacement, or a Google warning on your site: the first hour
A replaced homepage, or a Chrome warning on your site. What to copy before you touch the server, and the CERT-In clause that puts a defaced site on a six-hour clock.
You can see it. That is what makes this different from an intrusion you have to go looking for — the damage is on the screen, and every instinct says delete it and move on.
Delete it and you will be reading this page again. The replaced homepage is the last step of the intrusion, not the first. What matters in the next hour is the step before it.
Here is the order.
1. Establish what Google is actually showing
What you see is not necessarily what a visitor arriving from search sees. Google's own guidance on hacked sites names the reason: cloaking, where a page serves "different content to different types of users". Google's worked example is blunt — when you open a page on your own site you "might see a page without any content", while "when a search engine like Google accesses www.example.com/cheap-drugs, it will see spammy words and links."
Three checks. Do all three before you touch anything:
- Search
site:yourdomain.comand read every page of the results, not just the first. The operator returns what Google has indexed, which is not the same set as the pages you built. - Open Search Console and go to the Security Issues report. Google groups what it finds into three categories. Hacked content — "This is any content placed on your site without your permission because of security vulnerabilities in your site." Malware and unwanted software — "This is software that is designed to harm a device or its users, that engages in deceptive or unexpected practices, or that negatively affects the user." Social engineering — "This is content that tricks visitors into doing something dangerous, such as revealing confidential information or downloading software." Which heading you are under decides the rest of your week.
- If you cannot get into Search Console yet, Google's Safe Browsing site status page in its Transparency Report will tell you what Google currently says about the host.
Search Console needs verified ownership, and it is a prerequisite for the review request in step 7 — so start it now if nobody at your organisation has. Google offers seven routes. Two are changes at the site itself — an HTML tag pasted into the <head> of your non-logged-in home page, or an HTML file uploaded to the web root, which Google grades at the same effort. An existing Google Analytics or Google Tag Manager container will do it with no change to the site at all. A DNS record at your domain provider is the one Google calls more complex, and it is the only route that verifies a Domain property — every protocol and subdomain variation at once.
Which warning you are looking at, and what it means
| What you see | Where | What Google says it is |
|---|---|---|
| This site may be hacked | Next to your site in Google Search results | Content was placed on the site without permission through a security vulnerability |
| This site may harm your computer | Next to your site in Google Search results | Malware or unwanted software served from the site |
| Deceptive site ahead | Full-page interstitial in Chrome | Chrome "may display" it when "Google detects that your website contains social engineering content" |
One thing about that last row catches people out. Google's social engineering documentation states that "Deceptive social engineering content may be included via resources embedded in the page, such as images, other third-party components, or ads", and that "Embedded social engineering content is a policy violation for the host page." Your own files can be untouched and the interstitial still fires. Check your ad tags and your third-party scripts before you conclude the server was breached — and check them again if you find nothing in the file system.
2. Copy the evidence before the rebuild removes it
Four actions destroy the investigation, and all four are attempts to restore service that overwrite the record of how entry was gained: re-image the server, restore over the top, delete the defaced file, or power-cycle the box.
Take copies first:
- The defaced files themselves, with modification times intact. A directory listing sorted by mtime dates the change, and those timestamps are overwritten by the first restore, re-image or redeploy.
- Web server access logs and error logs, pulled to somewhere off the host.
- A database dump.
- The application's own logs, and the control-panel or CMS user list as it stands right now.
Access logs rotate. On managed hosting they can roll on a schedule you do not control, and once the window passes the record of the request that wrote the file is gone. Pull them at hour one, not at hour six.
There is an obligation underneath this, and it is a positive one. Direction (iv) of the CERT-In Directions of 28 April 2022 puts the retention duty in mandatory terms: "All service providers, intermediaries, data centres, body corporate and Government organisations shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction." Its next sentence covers handing them over: "These should be provided to CERT-In along with reporting of any incident or when ordered / directed by CERT-In."
CERT-In gives an illustrative list at FAQ Q 37: "The logs that should be maintained depend on the sector that the organisation is in, such as Firewall logs, Intrusion Prevention Systems logs, SIEM logs, web / database/ mail / FTP / Proxy server logs, Event logs of critical systems, Application logs, ATM switch logs, SSH logs, VPN logs etc." CERT-In adds that "this list of logs is not exhaustive but has been mentioned to provide flavour of logs to be maintained" — an illustration, not the boundary. The extent is the one Direction (iv) sets: logs of all their ICT systems. Web server and proxy logs are named on the face of it, and both record the request that wrote the file. The same answer adds a line worth reading twice: "From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded." The failed attempts are how you find the attempt that worked.
Ask the retention question today rather than at the point you need the answer: does your host actually hold 180 rolling days of web server logs, and can it produce them?
And check your clocks. Direction (i) requires all service providers, intermediaries, data centres, body corporate and Government organisations to connect to the NTP Server of NIC or NPL, or to NTP servers traceable to them, for synchronisation of all their ICT systems clocks. CERT-In gives the reason at FAQ Q 39: "Without an accurate time stamp it is extremely challenging to re-create accurate sequence of events thus causing serious hindrance while handling cyber incidents." A web server an hour out from the database is a timeline nobody can defend.
The fuller version of this — what each of the four destructive moves costs you, and the preservation order — is in preserve it before you rebuild.
3. Take it off the internet, the way Google says to
Once you have copies, stop serving the compromised site. Google's instruction is specific: "Take your site offline so that it no longer serves content to users. For example, stop your web server or point your website's DNS entries to a static page on a different server that uses a 503 HTTP response code."
The reason is not only the visitors. Google's own wording: "By taking your compromised site completely offline, you can complete administrative tasks with less interference from the hacker, and meanwhile, malicious code or spammy files won't be exposed to visitors."
Two details in that instruction do the real work.
The 503 has to come from somewhere else. Google: "The 503 status code is a useful signal that your site is down temporarily, but the response should occur from outside your compromised server or site." A maintenance page served by the compromised application is still the compromised application.
Blocking crawlers is not taking the site down. Google: "Using a robots.txt disallow is also insufficient because it only blocks search engine crawlers. Regular users can still access harmful content."
Then change credentials — Google's list, verbatim: "Change the passwords for all site users and accounts. This includes logins for FTP, database access, system administrators, and content management system (CMS) accounts."
The objection this raises is ranking. Google answers it directly: "It's unlikely that taking your site offline intermittently or temporarily during the recovery process will affect future ranking of your site in search results." Serving defaced content while you deliberate is the more expensive option.
4. Treat a web shell as a scope question, not a file
Something changed content you control — a file in the web root, a row in the database behind the CMS, or a record at your registrar or DNS provider. Whichever it was, somebody had write access to it.
If a shell was left behind, the attacker's access does not depend on the page you are about to fix. It depends on a URL you have not found. Google's guidance on this is a warning against stopping early: "Because there may be multiple, independent hacks in place, even if you're able to find and fix one vulnerability, we recommend continuing to search for others."
The scope question then widens past the one site, and Google's list of entry routes is where to start looking:
- Administrator machines. "Check for viruses on administrators' systems. We recommend running several reputable antivirus (AV) scanners on every computer an administrator has used to sign in to the site."
- Credentials. "Weak passwords are easy for hackers to discover, providing them with direct access to your server."
- Out-of-date software. "Check that your server(s) have installed the latest version of the operating system, content management system, blogging platform, applications, plugins, and any other software the site uses."
- The application's own code. Google's category is "Permissive coding practices, such as open redirects and SQL injections" — user input that is not "validated and properly escaped".
Add the ones a shared environment gives you for free: other sites on the same account, a database user reused across all of them, a deploy key, a CI pipeline that will helpfully redeploy the compromised tree over your clean one.
5. Why a clean-up that stops at the page brings the page back
This is the part worth slowing down for.
Restoring from backup puts a clean page back in one action, and Google puts one condition on it before anything else: "First, check that your backup was created before your site was hacked."
Read that condition carefully, because it cuts both ways.
A backup taken after the intrusion contains the intrusion — the shell, the modified theme file, the extra administrator account.
A backup taken before the intrusion contains the way in — the same unpatched plugin, the same weak credential, the same writable directory. It restores you to the exact configuration that was successfully attacked, and it restores you to it with a public record that the attack works.
Either way, the page comes back, because the access never left. That is the whole mechanism, and it is why the entry point is the deliverable and the clean homepage is not.
If you have no clean backup at all, Google's advice is not to skip the step — it is "Make two backups of your site even though it's still infected". Google's stated reason is recovery: "Having an extra backup will help recover accidentally deleted content, or let you revert and try again if things go awry." Yours is a second one. That copy is the site in the state the attacker left it, and it is the only version of that state you will have once the clean-up starts.
The clean-up Google describes finishes with the fix, not the file deletion: "Install any software upgrades, updates, or patches available. This includes software for the OS if you're in control of the server, and all applications, such as the content management system, ecommerce platform, plugins, or templates." Then credentials once more — "Perform one last change of passwords for all accounts related to the site".
How the entry point is actually established, class by class, is in how your website was compromised.
6. The report you owe, and when the clock started
A defaced website is named in terms. Annexure I item (iv) of the CERT-In Directions lists, among the incident types mandatorily to be reported:
"Defacement of website or intrusion into a website and unauthorised changes such as inserting malicious code, links to external websites etc."
Direction (ii) puts everything in Annexure I on the clock:
"Any service provider, intermediary, data centre, body corporate and Government organisation shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents. The incidents can be reported to CERT-In via email (incident@cert-in.org.in), Phone (1800-11-4949) and Fax (1800-11-6969)."
CERT-In's own severity language runs the same way. FAQ Q 30's third criterion names "large-scale or most frequent incidents such as intrusion into computer resource, websites etc."
Note where the six hours starts: noticing, or being brought to notice. If a customer emailed you, if a researcher messaged you, if Google's own alert landed in a shared inbox — that is when it started, not when you confirmed it. Work out that time now and write it down, because you will be asked for it and because the form collects occurrence time and detection time as separate fields.
You will not have the full picture by hour five. FAQ Q 30 anticipates exactly that: "The entities may provide information to the extent available at the time of reporting. Additional information may be reported later within reasonable time to CERT-In."
Send what you have at hour five, and supplement it when you know more. That is what the answer above permits, in CERT-In's own words.
Two more things the Rules and the FAQ answer directly:
Rule 13(2) binds CERT-In to withhold your identity. Under the CERT-In Rules 2013 (G.S.R. 20(E)), CERT-In is bound to keep back information that would identify an organisation affected by a cyber security incident, and the rule conditions release of it on that organisation's explicit written consent or the orders of an Indian competent court.
The duty stays with you, whoever does the work. FAQ Q 13 is explicit: "The obligation of reporting of cyber incident is neither transferrable nor indemnified or dispense with." Security Brigade takes full ownership of CERT-In six-hour notification — the drafting and the filing — and the statutory obligation remains the entity's.
What actually goes in the report, field by field, and which other regulators are owed a filing in the same window, is in the six-hour report.
7. Ask Google to look again — then wait for the decision
The review is not a formality and it is not automatic. Google names four things that must be true before you request one:
"Verified ownership of your site in Search Console"
"Cleaned your site of the hacker's vandalism"
"Corrected the vulnerability"
"Brought your clean site back online"
That third line is the one this whole page has been about, and Google put it in the prerequisites.
Then the requirement that a maintenance page silently breaks: "Your pages must be available to be crawled by Googlebot to ensure that they're clean. Make sure they're not roboted out or blocked from indexing by noindex robots META tags or directives." The 503 and the robots block from step 3 have to come off before you submit, not after. Leave the maintenance page up and Googlebot cannot see the clean site, so there is nothing for the review to confirm.
Search Console's own help adds that you should confirm "all issues listed in the report are fixed in all pages" — all of them, not the ones on the sample URL list.
Write the request as an account of the fix. Google gives the shape of it: "For each category of hacked spam, include a brief explanation of how the site was cleaned (for example, 'For Content injection hacked URLs, I removed the spam content and corrected the vulnerability by updating an out-of-date plugin.')" Name the vulnerability, name the change, name the date.
What Google publishes about how long it takes
| Issue type | Google's stated processing time |
|---|---|
| Phishing | "about a day to process" |
| Malware | "a few days to process" |
| Hacked with spam | "can require up to several weeks to process" |
And on clearing: "If Google finds that your site is clean, warnings from browsers and search results will be removed within 72 hours."
Then wait. Search Console's help is direct about the cost of impatience — "Please don't resubmit your request before you get a decision on any outstanding requests." File once, and let it run.
The order, on one screen
- Look at what a search visitor sees —
site:your domain, and the Security Issues report in Search Console. - Copy the defaced files, the web server logs, the database and the user list, off the host.
- Note the time you were first told, from any direction. That is when the six hours started, and the report is due six hours after it.
- Take the site offline with a 503 served from somewhere the attacker does not control. Change every credential.
- Find the entry point. Assume more than one.
- Report to CERT-In inside that six-hour window, with whatever you have by then.
- Patch, clean, rotate credentials again, and bring it back.
- Request the review, with the crawl blocks removed and the fix described.
Steps 5 and 7 are where a defacement stops being a defacement and becomes an investigation. If the logs are thin, if there is a shell you cannot account for, or if the same page comes back after you clean it, that is the point to bring someone in.
Security Brigade has been CERT-In empanelled since 2008. Web and application compromise is one of the eight incident types we handle: defacement recovery, web shell detection, application-layer attack investigation, forensic imaging following chain-of-custody protocols, and timeline reconstruction from the logs you preserved in step 2. We close probable entry points and isolate compromised systems within hours, even before the full attack path is mapped.
24/7 incident response · +91 22 4164 2220
If this turned out to be bigger than the homepage, start with the first hour, and the first seventy-two.
About the authors
Abhinav Awasthi
Lead — VAPT & Security Assessments
Leads Security Brigade's VAPT delivery team, having progressed from Security Consultant to Team Lead. Has executed advanced penetration tests across BFSI, fintech, QSR, and telecom — including ICICI Bank, Domino's, and Jubilant FoodWorks.
Shalabh Devliyal
Lead — Managed Security Services
Security researcher and penetration tester passionate about making the internet safer. Active CTF player, bug bounty hunter, and hands-on practitioner across web, network, and application security.
Continue reading
All articles →Business email compromise — the money left this morning
A payment went to an account that was not your supplier's. The instinct is to chase the money, and that is right — but a BEC is a mailbox intrusion first and a fraud second, and the two run on different clocks. What to do in the first hours, in what order, and why the mailbox investigation cannot wait for the recovery attempt.
How they got in — and why your logs decide whether you can answer
The morning after, the question is how. A short list of entry classes, each confirmed from a different record — and every one of those records is a log with a retention window set by whoever runs the infrastructure. Where that window is shorter than the intrusion, the honest finding is 'root cause undetermined' — and this is how to write one.
What the ransom decision actually turns on
By the time the question reaches you it is usually framed as pay or don't. It is really five separate findings, and four of them can be established in the first two days: which strain it is, whether a decryptor already exists, whether your backups actually restore, and whether data left the building. The six-hour CERT-In filing is due either way.