When a website hack check seems necessary, the first 30 minutes are not for deleting malicious files or changing passwords right away. Record who can access the admin and hosting accounts, which files changed and when, and which point in time your backups cover. Only then can you plan the response without wiping out the evidence of the cause.
What this article covers
- The order for checking access rights and login status before changing anything
- What to record about file changes in your hosting file manager
- Why file backups and database backups must be checked separately
- Deletions, restores, and reinstalls to hold off on during the first 30 minutes
- How to document management standards once you have taken over access
Before a website hack check, why not fix the screen first?
When unfamiliar text shows up on the homepage, a search result redirects to another address, or an unknown user account appears in the admin, it is tempting to jump straight into editing. But deleting files or restoring an older backup at that point also erases the clues to “what changed” and “since when things went wrong.”
The first step is to record the public site and the admin separately. Open the site in a private window, note the URLs where something looks wrong, and take screenshots. Then log in with your existing admin account and capture the user list, the recently edited posts and pages, and the plugin or theme update screen. The dates, account names, and file names on these screens are the records you will need later to decide what to restore to.
If visitors are actively being harmed — for example, redirected to another site or prompted to download files — record the evidence first, then decide in the hosting panel whether to suspend the site or switch to a maintenance page. This step does not fix the cause; it stops further exposure. Information on reporting and responding to security incidents is also available from KISA KrCERT/CC.
First 10 minutes: how do you check admin access?
Start by writing down, on one note, whether you can log in to the site admin, the hosting control panel, and the domain account. Getting into the site admin does not mean you control the server and the domain. Conversely, if you only have the hosting account and not the site admin login, it is hard to check content and user permissions right away.
In the admin, open the Users (or members) menu and check which accounts have administrator rights. For any account among the owner’s, staff, or former developer’s that you cannot explain, capture the account name, role, registration date, or last activity. Do not delete them yet — just keep the list. You will need to tell later whether a deleted account was a trace of outside access or one a previous operator used.
In the hosting control panel, check the account holder details, login accounts, connected domains, and how file management is accessed. If you use Cafe24, locate the account and per-service management screens by following the Cafe24 Help Center. Changing passwords comes after you have recorded this list and the current login status. If you change everything at once without knowing which accounts have access, you may lose permissions you need during recovery.
Next 10 minutes: what should you record about file changes?
Open the file manager in your hosting control panel and go to the folder where the site is installed. Sort the file list by “modified date” and check the files and folders that changed recently. The task here is not deletion but writing down or capturing each file path, file name, and modified date.
Flag any change that does not match when you published posts or edited the design. If many files share modified dates on days when nobody edited content in the admin, or if you see files with names you do not recognize, that list becomes the set to review before any restore. Do not conclude the site was hacked from a single file, because normal updates or hosting maintenance can also change modified dates.
If your host provides server error logs or access logs, keep the logs for the same time window. File lists and error logs can disappear after a restore, so if a download option exists, save the originals to a separate folder with the check date in the file name. Hold off on opening files to edit or overwrite them at this stage.
Last 10 minutes: check file and database backups separately
Knowing that backups exist does not settle what to restore to. A site usually returns to a previous state only when its files and database match. On the hosting backup screen, check the file backup dates and the database backup dates separately, and note whether any point appears to predate the first signs of trouble.
Automatic backups, manual downloads, and backups kept by a previous provider may live in different places. For each backup, note where it is stored, when it was created, whether it is files or database, and whether you actually have permission to download it. The most recent backup may have been created after the problem started, so do not pick it as the restore point just because it is the newest.
After checking the backups, move on to changing passwords for the admin, hosting, and domain accounts, removing unnecessary accounts, and deciding the scope of the restore. If search visibility was also affected, check the problem pages in search tools after recovery, using the items in 5 things to check when your site does not show up after Google registration.
Decide on recovery and a change of operator only after the records exist
The output of the first 30 minutes is not a technical fix but three lists: admin accounts that can log in, files with confirmed modified dates, and backups by date. With these three, it is clear who needs to check what, even if you cannot reach the original developer. If you report the incident to an outside authority, the procedure is described in the KISA KrCERT/CC incident reporting guide.
If it is hard for you to manage the site directly, use these lists to divide what to hand over. Recurring monthly items such as blog publishing, hosting health, and newsletter operation can be bundled into a single operations subscription like WOR-PRO Lab Managed Hosting, so that after an incident you are not hunting for where the admin and backups are.
The work is not over after a restore. Record in your operations document who owns the admin accounts, who renews the domain, when backups were checked, and when updates were checked. The party managing a website is not the one who builds new pages, but the one who, when something goes wrong, locates the accounts, files, and backups and decides the next step.
References
- KISA KrCERT/CC (Korea Internet & Security Agency)
- KISA KrCERT/CC — Incident Reporting Guide
- Cafe24 Hosting Help Center
자주 묻는 질문
If my website redirects to another site, should I restore a backup right away?
First, record the URL where the redirect happens and the screen, using a private window.
If you restore before checking hosting file modified dates and backup dates, you can lose track of the file that caused it and when it started.
If visitors are being harmed, decide on suspending the site or switching to a maintenance page right after recording.
Should I change the admin password the moment I notice a problem?
First record the list of admin, hosting, and domain accounts you can currently log in to.
Changing passwords without recording login status and account permissions can cut off access you need for recovery.
After checking the list and backup status, change passwords on the relevant accounts and remove unnecessary ones.
If I have a backup, do I still need to check whether the site was hacked?
A backup is only a restore candidate, not proof that nothing is wrong.
Check the dates of file backups and database backups separately and compare them with when the first signs of trouble appeared.
Keep a list of recent file changes and admin accounts before restoring, so you have evidence to trace the issue if it happens again.