A malware warning against a website does not always mean that the homepage itself contains a visible virus. Website compromises can involve hidden PHP files, web shells, backdoors, injected JavaScript, malicious redirects, compromised WordPress plugins, unauthorized administrator accounts, database injections, stolen FTP credentials or malicious files buried several directories below the public website.

The situation becomes more serious when multiple websites hosted under the same shared-hosting account start showing malware detections.

For example, a hosting account may contain:

/home/account/domains/
    companysite.example/
    blog.example/
    shop.example/
    clientsite.example/

If malware is discovered across several of these domains, the incident should normally be investigated at the hosting-account level, rather than treating each domain as an unrelated infection.

This article explains how to investigate this type of incident on Hostinger shared hosting, particularly when Hostinger Malware Scanner detects malicious PHP files while Google Search Console reports no current security issues and only a small number of VirusTotal security vendors continue to classify the domains as malicious.

1. Understanding the Different Security Results

A common and confusing situation looks like this:

Google Search Console

No issues detected

Hostinger Malware Scanner

Malicious files discovered and removed

VirusTotal

2 or 3 security vendors detect the URL as malicious while most vendors report it as clean.

These results are not necessarily contradictory.

Different security systems look for different things.

Google Search Console primarily warns site owners about security problems Google has detected that could affect visitors or search results.

A hosting malware scanner can inspect files stored inside the hosting account.

VirusTotal aggregates results from numerous independent security vendors.

Sophos and other reputation providers can maintain their own URL/domain reputation databases.

Therefore, a website can have been infected previously, subsequently cleaned, and still remain classified as malicious by one or more reputation services for some time.

2. Why a Small VirusTotal Detection Count Still Deserves Investigation

Suppose VirusTotal reports:

3 / 92

while approximately 89 vendors report the URL as clean.

This alone does not prove an active infection.

However, it should not automatically be dismissed as a false positive either.

Before requesting a false-positive reclassification, investigate:

• Hosting malware scan results
• Google Search Console
• Website files
• Website databases
• WordPress installations
• External JavaScript
• Redirects
• Downloadable software
• FTP/SFTP accounts
• Hosting credentials
• Cron jobs
• Recently modified files

If the hosting provider has independently detected malicious files, the incident should be treated as a genuine compromise until the environment has been cleaned and secured.

3. Why Multiple Websites on the Same Hosting Account Can Be Affected

Shared hosting frequently places multiple websites under the same account.

For example:

/home/account/domains/site1.example/public_html/
/home/account/domains/site2.example/public_html/
/home/account/domains/site3.example/public_html/

An attacker who gains sufficient access through one vulnerable website may potentially write files elsewhere that the same hosting user has permission to modify.

This does not mean shared hosting itself is inherently insecure.

The important issue is the permission boundary.

If several websites run under the same hosting account and one compromised application allows arbitrary file operations under that account, other accessible website directories may also be at risk.

4. A PHP Web Shell Is Particularly Dangerous

One of the most serious discoveries during a website investigation is a web shell.

A web shell is a malicious or unauthorized server-side script that provides remote management capabilities to an attacker.

A PHP web shell may allow operations such as:

• Browse directories
• Read files
• Upload files
• Download files
• Create directories
• Edit PHP files
• Delete files
• Change permissions
• Extract ZIP archives
• Compress files
• Search the server
• Execute PHP code
• Deploy additional files
• Create additional backdoors

This effectively gives the attacker a web-based file manager inside the hosting account.

Deleting one infected index.php therefore does not necessarily solve the problem.

5. Random Numbered Directories Containing index.php

A particularly suspicious pattern is:

/assets/768102/82550/74076/index.php

or:

/testing/assets/js/898179/627897/index.php

or:

/includes/360862/index.php

The fact that a directory has a numeric name does not by itself indicate malware.

Legitimate applications frequently create directories using:

• User IDs
• Product IDs
• Article IDs
• Upload IDs
• Cache IDs
• Image IDs
• Session identifiers

The suspicious combination is:

Unexpected numeric directories + unexplained PHP files + similar structures across unrelated websites + malware-scanner detections.

That pattern deserves immediate investigation.

6. Is index.php Automatically Malware?

No.

index.php is one of the most common legitimate PHP filenames on the internet.

For example:

/public_html/index.php

is completely normal.

WordPress itself uses:

/index.php
/wp-admin/index.php
/wp-content/index.php
/wp-includes/index.php

Therefore:

Never delete a file simply because it is named index.php.

Its location, contents, modification time and purpose must be considered.

An unexplained index.php buried in several randomly generated directories is a different situation.

7. Suspicious Malware Locations

Attackers frequently try to hide scripts inside legitimate-looking directories such as:

/assets/
/images/
/uploads/
/includes/
/cache/
/tmp/
/js/
/css/
/wp-content/uploads/

A PHP file appearing inside a directory expected to contain only images or JavaScript deserves investigation.

For example:

/images/resource/js/123456/index.php

is much more unusual than:

/public_html/index.php

8. Why Deleting Only the Detected File May Not Be Enough

Suppose a scanner removes:

/assets/123456/654321/index.php

The following may remain:

/assets/123456/
/assets/123456/654321/

If those directories were created entirely by the attacker and contain no legitimate application data, removing the malicious directory tree may be appropriate.

However, first establish that the parent directory is not used by the application.

Do not delete an entire legitimate directory such as:

/assets/

simply because malware was found somewhere underneath it.

9. Hostinger Malware Scanner

Hostinger shared hosting provides a Malware Scanner through hPanel.

Depending on the current hPanel interface and hosting plan, it can generally be accessed from the website's security section.

The scanner can report:

• Malicious files
• Compromised files
• Removed files
• Cleaned files
• Detection history
• Affected paths

A result such as:

22 detected
20 removed
2 cleaned

should be treated as evidence that malicious or compromised website files were present.

10. Removed vs Cleaned Files

These actions mean different things.

Removed

The scanner determined that the file itself was malicious and removed it.

Cleaned

The original file may have been legitimate but contained injected malicious code.

The scanner attempted to remove the dangerous portion while preserving the legitimate file.

A cleaned file deserves particular attention because it may indicate that attackers were modifying existing application files rather than merely uploading new files.

11. Important Limitation of File-Based Malware Scanning

A hosting malware scanner may primarily inspect website files.

That does not necessarily mean it has comprehensively examined application databases.

Malicious content can also exist inside a database.

For WordPress, areas worth investigating include:

wp_options
wp_posts
wp_users
wp_usermeta

Potential problems include:

• Injected JavaScript
• Spam links
• Malicious redirects
• Unauthorized administrators
• Modified site URLs
• Suspicious plugin configuration
• Hidden iframe code

Therefore:

A clean file scan does not automatically guarantee a clean database.

12. Check Hostinger Cron Jobs

Attackers sometimes establish persistence using scheduled tasks.

In Hostinger hPanel, navigate to the website dashboard and locate:

Advanced → Cron Jobs

Look for existing scheduled commands.

A normal WordPress-related command may involve:

wp-cron.php

However, simply seeing wp-cron.php in the Create a New Cron Job form does not mean an existing cron job has been configured.

The important section is the list of existing cron jobs.

If there are none, hPanel cron persistence becomes less likely.

13. No Cron Jobs Does Not Mean the Website Is Safe

An attacker does not need a cron job to maintain access.

Persistence can come from:

• PHP web shell
• WordPress plugin
• Modified theme
• Unauthorized administrator
• Stolen FTP credentials
• Compromised hosting password
• Database injection
• Hidden PHP backdoor
• Vulnerable upload form
• Abandoned WordPress installation

Therefore, an empty Cron Jobs page eliminates only one possible mechanism.

14. Check Forgotten WordPress Installations

Old WordPress installations are a significant security risk.

Examples include:

/demo/
/demo1/
/test/
/old/
/backup/
/new/
/staging/

Administrators sometimes forget these installations because they are no longer linked from the main website.

But they remain publicly accessible.

An outdated WordPress installation containing an old vulnerable plugin can become an attacker's entry point.

If a test/demo installation is no longer needed, back up anything required and remove it completely.

15. Update WordPress Core, Plugins and Themes

For every active WordPress installation:

1. Update WordPress core.
2. Update all plugins.
3. Update active themes.
4. Remove unused plugins.
5. Remove unnecessary themes.
6. Check administrator accounts.
7. Remove unknown users.
8. Change administrator passwords.

Deactivating a vulnerable plugin is not always equivalent to removing its files.

If a plugin is not required, deleting it reduces attack surface.

16. Check WordPress Administrator Accounts

Open:

WordPress Dashboard → Users → All Users

Look for:

• Unknown administrators
• Strange usernames
• Unexpected email addresses
• Recently created accounts
• Accounts with Administrator privileges that are no longer required

If an unauthorized administrator exists, removing malware files alone will not secure the website.

The attacker could simply log back in.

17. Secure the Hostinger Account

After a confirmed compromise, change the Hostinger account password.

Use a strong, unique password that has not been used elsewhere.

Enable two-factor authentication where available.

This is important because a compromise could originate from:

• Stolen browser credentials
• Phishing
• Password reuse
• Malware on an administrator's computer
• Exposed FTP credentials

18. Change FTP and SFTP Credentials

Inspect all FTP/SFTP accounts.

Remove accounts that are:

• Unknown
• Old
• Unused
• Created for previous developers
• Created temporarily

Change passwords for accounts that remain active.

Use SFTP/SSH-based access where supported and appropriate rather than transmitting credentials through insecure legacy protocols.

19. Check SSH Access

If SSH is enabled:

• Review authorized keys
• Remove unknown keys
• Rotate credentials if necessary
• Review recently modified files
• Search for unexpected scripts

Do not execute unknown PHP files while investigating them.

20. Find Recently Modified PHP Files

With SSH access, a useful read-only investigation is:

find ~/domains -type f \( -name "*.php" -o -name "*.phtml" \) -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort -r

This provides a chronological list of PHP files.

Look for groups of unrelated files modified within the same minute.

For example:

03:14 site1/assets/.../index.php
03:14 site2/includes/.../index.php
03:14 site3/uploads/.../index.php

Such synchronization can indicate automated deployment.

Do not delete files based solely on modification time.

21. Search for Commonly Abused PHP Functions

Another read-only check is:

grep -RniE \
"base64_decode|eval\s*\(|gzinflate|gzuncompress|str_rot13|shell_exec|passthru|proc_open|popen" \
~/domains \
--include="*.php"

These functions are not automatically malicious.

Legitimate PHP software may use some of them.

The objective is to identify suspicious combinations such as:

eval(base64_decode(...));

or heavily obfuscated code that dynamically reconstructs executable PHP.

Each result needs contextual review.

22. Check Upload Directories for PHP

For WordPress:

find ~/domains -path "*/wp-content/uploads/*" \
-type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -print

Unexpected executable PHP files inside media upload directories deserve investigation.

23. Check .htaccess Files

Find them using:

find ~/domains -name ".htaccess" -print

Review unexpected modifications involving:

RewriteRule
RewriteCond
Redirect
auto_prepend_file
php_value

Attackers sometimes create conditional redirects that behave differently for:

• Googlebot
• Mobile visitors
• Search-engine visitors
• Normal visitors
• Administrators

This can make an infected website appear completely normal to its owner.

24. Test the Website for Hidden Redirects

A basic check can be performed using:

curl -IL https://example.com/

Then test another user agent:

curl -A "Googlebot" -IL https://example.com/

And a mobile user agent:

curl -A "Mozilla/5.0 (Linux; Android 13)" -IL https://example.com/

Look for unexpected redirects to unrelated domains.

Normal HTTP-to-HTTPS redirection is not a problem.

25. Check External JavaScript and Iframes

Open the website in Chrome.

Press:

F12 → Network

Reload the page.

Review the domains contacted by the page.

Expected third-party services might include:

• Analytics
• Advertising networks
• Fonts
• CDN services
• Video embeds
• Social-media widgets

Investigate unfamiliar domains.

Also check:

F12 → Sources

for externally loaded JavaScript.

26. Check Downloadable Software Separately

Websites that distribute utilities may host:

.exe
.msi
.dll
.zip
.ps1
.bat
.cmd

Scan downloadable software separately from the website URL.

A domain can have completely clean PHP pages while one downloadable executable triggers security vendors.

Conversely, a clean executable does not prove that the website itself is clean.

Treat these as separate security assessments.

27. Why Google Search Console Can Say “No Issues Detected”

Google Search Console's Security Issues section is extremely useful.

A result of:

No issues detected

is a positive indicator.

However, it should not be interpreted as:

Every file and database record on this hosting account has been forensically verified as clean.

Google may not have discovered every hidden backdoor.

Use Search Console as one layer of evidence rather than the only security scanner.

28. Why Sophos May Continue Showing Malware

After malware has been removed, a reputation provider may continue to classify the domain based on previous observations.

Possible reasons include:

• Previously malicious URL
• Cached reputation
• Previously hosted malware
• Harmful download
• Malicious redirect observed earlier
• External resource
• Historical compromise
• Vendor false positive
• Reassessment not yet completed

Therefore, a Sophos detection after cleanup does not necessarily mean malware remains active.

But request reclassification only after confirming the website has been properly cleaned and secured.

29. Do Not Immediately Submit a False Positive

Suppose:

• Google reports clean
• Most VirusTotal vendors report clean
• Sophos reports malware

It may be tempting to immediately report a false positive.

Do not do this if the hosting provider recently detected actual malware.

First establish:

• Malware files removed
• No suspicious files remain
• Credentials rotated
• WordPress secured
• Plugins updated
• Old installations removed
• Cron jobs checked
• Databases reviewed as appropriate
• No reinfection occurs

Only then request vendor reassessment.

30. Monitor for Reinfection

This is one of the most important steps.

Suppose you delete:

/assets/123456/

and several hours or days later it returns containing:

/assets/123456/789012/index.php

That is strong evidence of ongoing persistence.

Possible causes include:

• Surviving web shell
• Vulnerable plugin
• Compromised administrator
• Stolen FTP password
• Malicious scheduled task
• Database-based payload
• Another infected website

Do not repeatedly delete regenerated files without finding their source.

31. Shared Hosting Should Be Investigated as One Security Boundary

When multiple websites under the same account are infected, create an inventory:

Website
CMS
PHP version
WordPress version
Plugins
Themes
Administrators
FTP accounts
Database
Last update
Old/test installations

This helps identify the weakest application.

A forgotten demo site may be more important than the main production website.

32. File Permissions

Typical web-hosting permissions are commonly around:

Directories: 755
Files: 644

Application requirements can differ.

Avoid unnecessarily permissive settings such as:

777

Do not blindly run recursive permission changes across a production website without understanding the application's requirements.

33. Backup Before Major Cleanup

Before manually removing uncertain application files or changing databases, maintain a backup.

However, remember:

A backup created after compromise may itself contain malware.

Label backups by date.

Do not automatically restore an infected backup over a newly cleaned website.

34. Change Database Passwords

After securing the applications, consider rotating database credentials.

For WordPress, the database connection information is referenced by:

wp-config.php

After changing a database user's password, update the application's configuration immediately so the website does not lose database connectivity.

35. Rotate WordPress Security Keys

After a WordPress compromise, consider regenerating the WordPress authentication salts/keys in wp-config.php.

This can invalidate existing authentication sessions.

It is useful when there is concern that authenticated sessions may have been compromised.

36. Check Administrator Computers

A website can be cleaned perfectly and still be reinfected if the administrator's PC contains credential-stealing malware.

Scan computers used for:

• Hostinger login
• WordPress administration
• FTP
• SFTP
• SSH

Keep browsers and operating systems updated.

Do not save high-value hosting credentials on untrusted computers.

37. Recommended Incident-Response Sequence

A practical sequence is:

Detection → Preserve necessary evidence/backups → Remove confirmed malware → Identify entry point → Secure credentials → Patch applications → Remove obsolete applications → Check persistence → Scan again → Monitor → Request reputation reassessment

Do not reverse the sequence by requesting blacklist removal before the security problem is addressed.

38. When Is It Safe to Request Sophos Reclassification?

Consider requesting reassessment when:

• Hostinger reports no new malware
• Google Search Console reports no security issues
• Suspicious directories do not reappear
• WordPress is updated
• Unknown administrators are removed
• Credentials have been changed
• Cron jobs have been reviewed
• External resources have been checked
• No unexplained redirects remain
• Website functions normally
• VirusTotal detections are limited to reputation vendors

At that point, a persistent vendor detection may reasonably be treated as a reputation/reclassification issue.

39. Important Lesson: Malware Removal Is Not the Same as Security Recovery

A scanner can successfully remove:

shell.php

but if the vulnerable plugin that uploaded shell.php remains installed, the website is still vulnerable.

Similarly:

Malicious files: 0

does not automatically mean:

Security problem completely resolved

The ultimate objective is not merely zero detected files.

It is:

Zero detected malware + closed entry point + secured credentials + no persistence + no reinfection.

40. Final Security Checklist

After a shared-hosting malware incident, verify:

• Hostinger malware scan completed
• Confirmed malicious files removed
• Suspicious attacker-created directories removed
• Old demo/test installations removed
• Cron jobs reviewed
• WordPress core updated
• Plugins updated
• Themes updated
• Unused plugins deleted
• Unknown administrators removed
• Hostinger password changed
• 2FA enabled
• FTP/SFTP credentials changed
• Unknown FTP accounts removed
• SSH access reviewed
• Database credentials considered for rotation
• WordPress authentication keys rotated where appropriate
• .htaccess reviewed
• Recent PHP files reviewed
• Upload directories checked
• External scripts reviewed
• Redirects tested
• Administrator PCs scanned
• Google Search Console checked
• Website rescanned
• Sites monitored for reinfection
• Security-vendor reclassification requested only after cleanup

Conclusion

When several websites on one Hostinger shared-hosting account contain malicious PHP files, the problem should be treated as a hosting-account security incident, not simply as several independent infected pages.

Random numeric directories containing unexplained index.php files, PHP web shells, malicious ZIP archives, modified legitimate files and malware appearing across unrelated domains are strong signs that an attacker obtained a method of writing files to the hosting environment.

Deleting detected malware is necessary, but it is only the first stage.

The more important questions are:

How did the attacker get access?

Does another backdoor remain?

Can the attacker recreate the deleted files?

Have credentials and vulnerable applications been secured?

Once the environment remains clean and no reinfection occurs, remaining Sophos or other low-count VirusTotal detections can then be investigated as reputation or false-positive classifications.

FAQ

1. Does a VirusTotal result of 2/92 or 3/92 prove my website has malware?

No. A small number of detections can be caused by vendor-specific reputation systems or false positives. However, if your hosting provider has independently detected malicious files, investigate the incident before assuming a false positive.

2. Google Search Console says “No issues detected.” Does that mean my hosting is completely clean?

No. It is an encouraging result, but Search Console is not a complete forensic scanner of every hosting file and database record.

3. Why does Sophos report malware when most VirusTotal vendors say clean?

Sophos may have previously observed malicious content, redirects, downloads or another security event associated with the domain. Reputation may persist after cleanup.

4. Is every index.php file suspicious?

No. index.php is a standard PHP filename. Its location, contents and purpose determine whether it is legitimate.

5. Are numbered directories automatically malware?

No. Many legitimate applications use numeric directory names. They become suspicious when they are unexplained, appear unexpectedly, contain executable PHP files and match known malware detections.

6. Can I delete an entire suspicious numbered folder?

If you have established that the directory was attacker-created and contains no legitimate application data, removing the entire malicious directory tree can be appropriate. Do not delete directories solely because their names are numeric.

7. What is a PHP web shell?

It is a server-side PHP script that can give an attacker remote file-management or code-execution capabilities.

8. Can a web shell upload more malware?

Yes. Many web shells can upload, create, modify and delete files and may allow execution of arbitrary server-side code.

9. Can one infected website affect other websites in the same hosting account?

Potentially, yes, if the compromised application can write to directories belonging to the same hosting user.

10. Should I delete my entire hosting account?

Usually not. First identify and clean the compromise, secure credentials, update applications and monitor for reinfection. Rebuilding may be considered in severe cases where integrity cannot be confidently restored.

11. Should I delete the entire assets directory?

No. assets normally contains legitimate website resources. Remove only confirmed malicious content or directories after verifying their purpose.

12. Can malware hide inside the database?

Yes. JavaScript, redirects, spam links, unauthorized users and malicious configuration can be stored in databases.

13. Does Hostinger Malware Scanner check the database?

Capabilities depend on the product and plan. Pay attention to the scanner's own notice regarding whether database content is included. If it states that only website files are scanned, investigate the database separately when appropriate.

14. What are compromised files?

These are often legitimate files that have been altered or injected with dangerous code.

15. What are malicious files?

They are files the scanner considers inherently malicious, such as a backdoor, web shell or other malware component.

16. Why should I check Cron Jobs?

A malicious scheduled task could periodically recreate deleted malware.

17. If Hostinger shows no Cron Jobs, am I safe?

Not necessarily. Malware can persist through web shells, plugins, database injections, compromised credentials and other mechanisms.

18. Is wp-cron.php malware?

No. It is a normal WordPress component. Its presence alone is not suspicious.

19. Should I remove old demo WordPress installations?

If they are no longer required, removing them reduces attack surface. Back up any information you genuinely need first.

20. Can an inactive plugin still be dangerous?

Unused plugin files can still increase attack surface depending on the vulnerability. Plugins that are not required should generally be removed.

21. Should I change my Hostinger password after an infection?

Yes, especially after a confirmed compromise.

22. Should I enable 2FA?

Yes. Two-factor authentication provides an important additional layer of account protection.

23. Should I change FTP passwords?

Yes. Rotate FTP/SFTP credentials after a confirmed compromise and remove unused accounts.

24. Should I change WordPress administrator passwords?

Yes. Also review the administrator list for unauthorized accounts.

25. Should I change database passwords?

It is worth considering after compromise, particularly when configuration credentials may have been exposed.

26. Why do malicious folders sometimes return after deletion?

A surviving backdoor, vulnerable plugin, compromised credential or another persistence mechanism may be recreating them.

27. What should I do if suspicious directories reappear?

Treat it as evidence that the compromise remains active. Stop repeatedly deleting symptoms and investigate the persistence mechanism.

28. Can .htaccess contain malware?

Attackers can modify .htaccess to create redirects, alter PHP behavior or implement cloaking. Review unexpected changes carefully.

29. Can JavaScript cause a website malware warning?

Yes. Injected or malicious external JavaScript can cause security and reputation problems.

30. Should downloadable EXE files be scanned separately?

Yes. Website URL reputation and downloadable-file reputation are different assessments.

31. Can a clean website still host a malicious download?

Yes.

32. Can a clean executable exist on a compromised website?

Yes. Website and file security should be evaluated independently.

33. When should I request a Sophos false-positive review?

After the site has been cleaned, credentials secured, vulnerabilities addressed and no reinfection is observed.

34. Should I restore an old backup immediately?

Not necessarily. Determine whether the backup predates the compromise. Restoring an infected backup can reintroduce malware.

35. Is changing file permissions enough to stop malware?

No. Permissions are only one security layer.

36. Should I use 777 permissions?

Avoid unnecessarily permissive permissions. Use the permissions appropriate for your hosting environment and application.

37. Can my own computer cause website reinfection?

Potentially. Credential-stealing malware on an administrator's computer can expose hosting, WordPress or FTP credentials.

38. Should administrator PCs also be scanned?

Yes, particularly after a confirmed hosting-account compromise.

39. Is deleting malware enough?

No. You must also identify or mitigate the entry point and persistence mechanism.

40. What is the most important sign that cleanup was successful?

No new malware appears after credentials are rotated, applications are patched and the websites are monitored over time.

#Tags

#Hostinger #HostingerSecurity #HostingerMalware #MalwareScanner #WebsiteSecurity #WebsiteMalware #MalwareRemoval #PHP #PHPMalware #WebShell #PHPWebShell #Backdoor #PHPBackdoor #HackedWebsite #CompromisedWebsite #WordPress #WordPressSecurity #WordPressMalware #WordPressHacked #CyberSecurity #WebSecurity #SharedHosting #SharedHostingSecurity #VirusTotal #Sophos #GoogleSearchConsole #WebsiteBlacklist #DomainReputation #MaliciousPHP #IndexPHP #MalwareDetection #MalwareCleanup #MalwarePrevention #WebsiteProtection #SecurityAudit #IncidentResponse #WebsiteRecovery #FTPsecurity #SFTP #TwoFactorAuthentication #2FA #CronJobs #WPCron #WebsiteBackup #PHPsecurity #MalwareReinfection #WebsiteAdministrator #WordPressPlugins #WebsiteHacking #CyberSafety