How Do Malware .ico Files Get Uploaded

Cleaning an infected WordPress website (.ico virus)

Summary

I've recently been hired to clean an infected WordPress website. This write-up is about the solution I constitute to locate and remove all infected files and successfully clean the website. At the stop, you'll find a summary of all the steps I used to clean the WordPress website from malicious files.

I hope these explanations will be useful to people having the aforementioned problem. Y'all can discover other related articles that helped me on this mission at the end.

Context

A redirections being made from the main folio of the infected website to some advertising websites triggered the attention of the website's possessor. Later a quick look on the server, he constitute some weird-looking PHP lawmaking in both alphabetize.php and wp-config.php files.

They both contained the following piece of lawmaking :

          @include "[redacted]/\167p-\143on\164en\164/p\154ug\151ns\057ct\055ul\164im\141te\055gd\160r/\05614\06356\1419e\056ic\157";

This include statement shouldn't exist here and it includes a file catastrophe with the .ico extension. The website's owner also ran an anti-virus scan and gave me the result to start the mission with :

Files detected as malwares past the anti-visrus scan

As you tin can meet, many .ico files were detected every bit trojans.

Before the mission started, the website'south owner tried to clean the server on his ain, from what he saw with the anti-virus scan. He also migrated the website to another server making sure to modify all access passwords. Even so, the website got compromised again a few days after. Information technology is an important point : if all passwords are dissimilar, it means that the attackers must take at least one backdoor on the server.

I also had at my disposal the past 16 days server'due south logs.

Step 1 : Analyzing the malware

The very get-go step is to understand a picayune meliorate how the malware works in order to later create a detection mechanism.

Commencement, lets decode the malicious @include argument found in index.php and wp-config.php. At kickoff sight, nosotros can judge that parts of the payload are hexadecimal characters. After a quick search on google, I institute a website which allows you to decode such lawmaking : malwaredecoder.com.

The decoded value looks every bit follow :

          @include "[path_to_website]/wp-content/plugins/ct-ultimate-gdpr/.14356a9e.ico";

As nosotros tin see, this line of code simply include a .ico file with a random looking name.

Well-nigh of the time, ICO files are images corresponding to icons. However, by looking at the content of this one (using the strings command on linux) we come across that information technology contains obfuscated PHP code.

Content of wp-content/plugins/ct-ultimate-gdpr/.14356a9e.ico

From the malware analysis provided at the outset of the mission, we know that this is a malicious file even though we don't exactly know what information technology does (and we won't try to sympathize information technology here). Now we know what malicious files wait like, it is time to notice them all.

Step ii : Finding all infected files

Now we know that an @include statement in infected files loads malicious .ico files which triggers a redirection when a user admission the website. The included .ico files contains obfuscated PHP lawmaking.

1- Finding all files with a malicious @include statement :

To practice that, lets list all PHP files on the website containing the "@include" string and manually checking them i past i.

First, we connect the server using SSH and we move to the website folder location. The following control listing all PHP files in the electric current directory and all the sub-directories containing "@include" :

          find . -blazon f -proper name '*.php' | xargs grep -l " *@include *"

Only nine files were institute and just 3 of them contained malicious includes statements (in red in the flick below) :

Listing of files containing the "@include" statement (infected files in cerise)

2- Finding all .ico files containing obfuscated PHP :

The next stride is to find all .ico files containing malicious PHP code. It shouldn't exist very difficult because there is usually very few .ico files on a website. In improver, from what we saw to a higher place, it seems that all malicious .ico file names start with a "." followed with 8 random characters. It makes them easy to spot using the following command :

          discover . -proper noun '*.ico'

With this command yous can list all files with the .ico extension. When I ran this command from the website binder information technology returned 23 results. After quickly checking all of them, only two were valid icons (in dark-green on the pic beneath). The attacker probably added the others :

List of all .ico files on the website (only two are valid images)

We at present take all our malicious .ico files.

Just in that location still is one thing nosotros demand to figure out. The website's possessor already cleaned the website one time (only by removing the malicious "@include" statements of infected files) and moved information technology to some other server, taking care of irresolute all passwords. But the website got infected once more. Information technology tin can just mean one thing : the aggressor found a way to infect the website once more. Therefore, it is probable that there is a backdoor somewhere.

Pace iii : Finding all the back-doors

A backdoor is a cover method to bypass hallmark. They are ofttimes used by attackers to gain remote access to a server and perform malicious actions. On a WordPress website it is nigh of the time in the course of obfuscated PHP code.

1- Finding one back-door

While looking on the internet for people having the aforementioned problem, I came across an commodity about virtually the same virus than this one. In this article, the author found PHP back-doors in unusual places similar CSS or JavaScript folders. I decided to look for the same thing. The idea is to list all PHP files that would be in a CSS or JS folder :

          observe . -name '*.php' | grep "css"          discover . -proper noun '*.php' | grep "js"          find . -proper noun '*.php' | grep "javascript"

Afterward running those commands, I immediately spotted two PHP files in a CSS folder :

wp-admin/css/colors/hvijeera.php
wp-admin/css/colors/ialwtnhp.php

As nosotros could imagine, those files contained obfuscated PHP lawmaking :

two- Finding more back-doors

Good ! Nosotros at present have the confirmation that the attacker left back-doors on the website. And we have two of them. Just if there are two back-doors, there may exist more…

The idea at present is to find a rule that would aid us detect all the remaining back-doors. With the assistance of this article and the two dorsum-doors we found, nosotros can meet that the dorsum-doors filenames contains what appears to exist eight random characters. Therefore, nosotros demand to list all PHP files on the server having a filename of exactly viii characters :

          find . -type f | egrep './[a-z]{8}\.php'

This command returned all PHP files having a filename equanimous with viii letters. I decided to isolate all files with random looking names. After several minutes, I could notice more than 30 PHP files with random names. They contained obfuscated PHP lawmaking similar to the i above in the last screenshot.

Here is the list of all these files :

wp-admin/css/colors/hvijeera.php
wp-admin/css/colors/ialwtnhp.php
wp-admin/includes/fodhbsvi.php
wp-admin/js/widgets/onbveaiq.php
wp-content/languages/themes/wbvamiuh.php
wp-content/languages/phgkiyku.php
wp-content/plugins/woo-payrexx-gateway/languages/tegzukkb.php
wp-content/plugins/sendgrid-e-mail-delivery-simplified/lib/oqjcoswk.php
wp-content/plugins/sendgrid-email-delivery-simplified/pnvsgzto.php
wp-content/plugins/sendgrid-e-mail-commitment-simplified/gewuxkar.php
wp-content/plugins/webleman_special_product/rqtsomdx.php
wp-content/plugins/wp-google-map-gold/xndsaozt.php
wp-content/plugins/woocommerce-pre-orders/woo-includes/horiejka.php
wp-content/plugins/secupress-pro/avails/gkvrmzih.php
wp-content/plugins/contact-form-7/admin/dcrywpqp.php
wp-content/plugins/contact-course-7/includes/dlnemjkc.php
wp-content/plugins/indistinguishable-post/compat/eyfjqksu.php
wp-content/plugins/google-analytics-dashboard-for-wp/install/ddhvusfh.php
wp-content/plugins/slide-anything/php/kztgmfli.php
wp-content/plugins/redirection/matches/dzukjmhv.php
wp-content/themes/Divi/css/dkbxdzwy.php
wp-content/themes/Divi/js/cycbglvr.php
wp-content/uploads/backup/slider2/echqojau.php
wp-content/uploads/backup/2020/divfsfqb.php
wp-content/uploads/revslider/templates/xlabqngc.php
wp-content/cache/min/i/zdxmwssv.php
wp-content/cache/min/bcmvwtre.php
wp-includes/IXR/ezgrjpgr.php
wp-includes/SimplePie/XML/prredjoz.php
wp-includes/css/dist/block-library/oaezpkmi.php
wp-includes/css/dist/components/atnugdta.php
wp-includes/css/rdhqdxtp.php
wp-includes/images/crystal/pznbisdy.php
wp-includes/images/jsavtgnq.php
wp-includes/js/jcrop/ytnmrliz.php
wp-includes/js/jquery/pfuksarv.php
wp-includes/sodium_compat/src/PHP52/bsqlgpxg.php

That'southward a great news ! We at present accept located many back-doors. Only we merely found back-doors corresponding to files created by the assailant with random looking names. What if they decided to hibernate a backdoor in an already existing file ? For that, we tin can count on the server's logs.

3- Checking the logs

Now nosotros have a lot of back-doors, it is fourth dimension to check the log files. Unfortunately, I only had logs from the past two weeks. My aim was to find all requests made to one of the 38 back-doors to know if the attackers are notwithstanding active and employ the server. The idea is to run a string search in the log file :

          cat <log_file> | grep "<backdoor_name">

I was lucky enough to detect several requests made to 7 of 38 dorsum-doors listed above. What immediately caught my attending was that all the requests were made from different IP addresses between v:42am and 5:44am the aforementioned day. Knowing that, I decided to cheque all the requests made during this time period.

Log file from five:42am to v:44am the mean solar day of the final assault on the server.

On the picture to a higher place, we have all the files already known as back-doors in green and in red all legitimate looking files that were accessed around the same fourth dimension than the assail. By checking all the reddish files manually, I plant out that some of them contain PHP back-doors (see next screenshot). The post-obit files were infected :

wp-content/plugins/wp-rocket/views/settings/folio-sections/media.php
wp-content/plugins/secupress-pro/core/functions/3rdparty.php
wp-content/plugins/secupress-pro/inc/functions/pluggable.php

Now we know some legitimate files have been infected, nosotros need to look for a fashion to find all of them. Fortunately, nosotros can find the verbal same PHP code in most of the back-doors. The malicious PHP lawmaking is always a one line slice of code starting with many spaces. Most of information technology isn't human readable. Withal, I could detect a subset of man readable characters in every infected files : Array();global

In red a man readable pieace of lawmaking found in all infected files.

Because the malicious PHP code is on single line, there is no carriage return afterward ";" which makes it easier to discover. I used the following command to identify all PHP file containing this cord :

          find . -blazon f -proper noun '*.php' | xargs grep -l " *Array();global*"

Later reviewing the results manually, I found two new files containing back-doors :

wp-content/plugins/imagify/classes/Imagifybeat/Core.php
wp-content/plugins/wp-seopress/inc/functions/options-oembed.php

At this betoken, after double checking everything I had done so far and trying other searches I couldn't discover any more than obfuscated PHP lawmaking on the server. Note that virtually anti-virus softwares don't detect those back-doors.

four- Checking the crontabs

Cron is a software on Unix similar systems used to schedule jobs (scripts) to run periodically. When an attacker compromises a server, he often add together malicious scripts in the cron tabular array. That way, fifty-fifty if you clean the server, malicious script tin still run periodically. That is why it is important to check the crontabs :

          cat /etc/crontab

Fortunately there was nothing to report in the crontabs.

Step 4 : Finding how the attacker got access to the server

The all-time thing now would exist understanding how the aggressor gained admission to the server in the kickoff identify. For that, I tin can recall of two possibilities : either the attacker establish a leaked password (either SSH, FTP or a WordPress administration password) or he found a vulnerability somewhere on the website allowing him to run arbitrary lawmaking.

I didn't investigate the commencement possibility because the solution to it is cleaning the server and changing all passwords which nosotros will practise anyway. I started looking at every installed plugins. For each of them we can search online to encounter if known vulnerabilities associated to the installed version exist. I couldn't observe annihilation considering the website'south owner updated all the plugin and the WordPress version before the mission started. Keeping all plugin up to engagement is a adept fashion to avert vulnerabilities.

I also used an automated tool called WPScan that looks for vulnerabilities on WordPress websites. But information technology didn't find anything that could have helped an attacker infecting the website.

Considering I didn't have much time on the mission I didn't become farther. My guess is the attacker used a known vulnerability on one of the plugins when they weren't up to date.

In any example, here is a list of thing to check when looking for a way an attacker could infect your website :

Known vulnerabilities on installed plugins.
Known vulnerabilities on WordPress version.
Misconfiguration on WordPress installation that could lead to code execution.
Any file upload functionality on the website (make certain arbitrary file upload isn't possible).
Any lawmaking and functionality manually added past developers.

Pace 5 : Cleaning the mess

Now nosotros have everything we need, nosotros tin can start cleaning the server. For that, I followed this process (update : this article contains a lot more details) :

Remove all the PHP back-doors institute.
Remove malicious @include mentions in infected files.
Remove all malicious .ico files found.
Analyse once over again all the website files with unlike anti-virus softwares.
Alter all access passwords to the websites (SSH, FTP, WordPress assistants, fifty-fifty users passwords if possible…).
Verify that all existing administration accounts belong to known users. If non, remove the business relationship.
Update WordPress to the latest version available.
Update all plugins to the latest version bachelor.
Brand sure to employ only well-known plugins broadly used past the community.
Install an antivirus plugin on the website.
Expect at all accounts that tin can access the database. If one of them await suspicious, remove information technology.
Change the access countersign to the database.
Verify all .htaccess files to brand certain they don't contain unwanted rules.
On a unix server, check all files and folders rights on your website. None should have 777 rights. All must have 644 or less.
Prevent the employ of xmlrpc.php file in the server configuration.
Check the crontab to brand certain no malicious script has been installed by attackers.
If possible drift the website on a new server for more security.

In our instance, in addition to all the back-doors and infected files, we realised that the attackers inverse the file permissions on "wp-content/*". To detect that nosotros did a search on file permissions every bit follow :

          find . -blazon f -perm 0755
find . -blazon f -perm 0777
notice . -type d -perm 0777

All files in "wp-content" had 755 permissions. We inverse everything back to 644 with the following command :

          find . -type f -exec chmod 644 {} \;

References

Here is the list of references that helped me during this mission or that y'all can use to improve your WordPress security :

Decode malicious include statements
Very expert article with a malware similar to this i
Ameliorate WordPress security (official website)
WordPress hardening article
Other articles near kinda similar malwares
Same malware on Drupal
File permission on WordPress
Security scanner WordPress
Another good article about cleaning an infected website

Thank you for reading this. I promise it can be useful to some of you. Do not hesitate to tell me if you can think of any improvement I could brand to this article or if I did a mistake somewhere.