First Response Guide to a Website Attack for Cybersecurity

From a cybersecurity perspective, if you see an unexpected redirect, a modified page, or an administrator account you do not recognize on your website, the first step is not to delete files at random but to restrict access and preserve evidence. First record when the incident occurred and which address was affected; then review the records in the hosting panel or the logs available to the server administrator to determine the scope of the problem.

In a cybersecurity incident, identify the environment and access first

If you use shared hosting, you will generally have a limited view consisting of the file manager, database tool, backup screen, and the error or access logs belonging to the site. On a managed or self-managed server, you may have access to web server, application, authentication, and system logs; however, every provider uses different menu names and retention periods. Therefore, do not assume that a record exists simply because it is not visible in the panel.

First list every account that can change the site: the hosting panel, CMS administration, FTP or SFTP, the database, and any deployment system. Since one of these accounts may have been compromised, renew the passwords from a trusted, clean device and, where possible, use multifactor authentication. However, while investigating an active incident, do not perform unnecessary actions that could change file dates, usernames, or log records. Note the original settings and the date of the existing backup.

Safe investigation steps that connect symptoms to evidence

1. Record the symptom: Note the affected URL, the message you saw, the device you used, and the approximate time. If only the home page is broken, the scope may be limited; if multiple pages redirect, the application, a plugin, or the server configuration must be considered together.
2. Make a new backup: Use the panel's file and database backup function to store the current state as a separate copy. If the backup fails, do not force it; check the provider's available snapshot or backup options. This copy is intended for comparison after an incorrect correction.
3. Find records matching the time: In the access and error logs in the hosting panel, or in the relevant log screen of the administrative server, look for lines close to the time of the incident. Many failed login attempts from the same IP address, unexpected requests to an administrative URL, or an error involving a particular file point to different paths. Do not assume that a single line explains the entire attack.
4. Restrict the unauthorized account or access path: If there is an unfamiliar CMS administrator, disable the account first instead of deleting it, and record its username, creation time, and role. If you see a suspicious FTP or SFTP key, remove only that key; do not change the permissions of all users at once. If the records point to an outdated file belonging to a particular plugin, disabling the plugin through its own management tool is a safer first correction than deleting files at random.
5. Repeat the same operation and check for new evidence: For example, if the problem is that a particular URL redirects visitors to an address they do not recognize, open the previous address again and note the time of the attempt. Then review the new access and error records for that same time. If the redirect continues but no new application error appears in the log, examine the modified configuration or database content; if a new plugin error appears, examine the version and change history of the relevant plugin.
6. Verify the result or roll back: If the symptom has disappeared, test the same page, administrator login, and basic form flow in a different browser session. If the symptom continues, restore your most recent change to the previous value you recorded and consider limiting the site with a temporary maintenance page. At this stage, asking the provider for time-stamped backups and access records is a safer next step than broad cleanup that could destroy evidence.

Which correction should be made based on the result?

If the records show an error occurring during a call to a particular file or plugin, first check the application's version compatibility and the latest change; disable only the relevant component and test the same URL again. If failed administrator logins are concentrated instead of an error being recorded, address account passwords, multifactor authentication, and login restrictions rather than changing application files. If the redirect continues for every user, clearing the browser cache alone is not sufficient evidence; the application configuration, database content, and server redirect rules must be examined separately.

Suppose that, in a content management system, a redirect to a foreign page appears only when a particular post address is opened. The record for the time of the incident shows a content change made using an administrator account, while there is no file-change record. In this case, it makes sense first to disable the account, renew its password, and compare the relevant content with a trusted backup; deleting all files would not explain the content-based path indicated by the record. Conversely, if a new attempt shows an error in a particular plugin file, the investigation should focus on that plugin's version.

Clean restoration and lasting measures

Once the source of the incident has been identified, restoring from a backup confirmed to be trustworthy may be more consistent than removing suspicious files one by one; however, the backup must date from before the incident and must not contain the same security vulnerability. Save the current state separately before restoring. After restoration, renew the passwords for administrator, panel, database, and file-transfer accounts; close unused accounts; and move the application and plugins to supported versions.

After the initial investigation, check that regular backups can actually be restored, that multifactor authentication works for administrator logins, and that access records are retained for a sufficient period. With shared hosting, it is important to learn in advance what the provider's incident investigation and backup-retention coverage includes; the scope of these services may vary by platform. When evaluating general hosting options, you can review the information on İyibirNet; in a technical incident, however, do not use the link alone as security evidence.

Safe next step if the symptom persists

If the same redirect or unauthorized change continues after the accounts have been renewed and the affected component has been restricted, temporarily reduce access instead of leaving the site open for normal use. Provide the provider with the incident time, affected URLs, the individual changes you made, and the relevant log times; do not share passwords, access keys, or personal data. Deleting files or changing all permissions at once before the investigation is complete can make both restoration and determining the cause of the incident more difficult.