So, one of the sites i know got infected with malware, not a proud thing to say but sh*t happens, given that i had just updated wordpress and all the plugins that could safely be updated while maintaining full site functionality (in this case all the plugins that had the update option were updated) i was puzzled how this had happened.
SUMMARY OF FINDINGS
– My wordpress admin capatcha page rejected bot attempts to the wp-login or wp-admin page
– Bots (Internet Robots) are always scanning 24 hours a day 7 days a week both malicious and innocent bots.
– Site was accessed through the cherry-plugin vulnerability file upload feature that didn’t include access user validation (anyone could upload a file), a malicious payload uploaded and site hacked and updated with a redirect to a malicious website by modifying the .htaccess file
** Reference to an earlier article i wrote click here shows how access to a wordpress directory structure can allow php payloads and OS access.
– Cleanup was in removal of the redirect to the malicious website in the .htaccess file, deletion of virus wordpress accounts in the database wp_users table, and cleanup of both virus files and virus payloads amidst existing web files, used wordfence security plugin for this.
– Some of the existing virus files found, /hostdata4.php, user.php and many others
Note: The site cpanel was used to clean the files and directories that were infected.
I discovered the site was down when i found it suspended by the provider, given that it wasn’t due for renew anytime soon the only possibility was that it was spreading malware (they actually can use your site to spread viruses and malware, what is the world coming to ???)
I unsuspended it and using the sucuri security website i performed a scan to confirm the infection (primarily because it is easier than digging into the site files right away, i.e. visit their website at https://sitecheck.sucuri.net/ and lo and behold, it returns malware detected.
I take a backup of the hacked site, and go a head to fix the site, i realize that this particular malware had infected the .htaccess file and created multiple copies of the same to redirect to a malicious website that was infected, cleaning involved removing all the false .htaccess files from plugins, themes, images and other directories and cleaning up the legitimate .htaccess files to remove the redirect as well as there were other uploaded files like user.php, hostdata4.php, rnb_lea1.php e.t.c that had base64 encoded payloads, analysis showed that these were used to create remote access to the site to upload other files, discovering these files was abit tricky and various techniques were employed;
1) Timestamps of files were examined, any file that had a creation / access date of the attack date had to be examined to confirm that it was a legitimate file and that the contents were legitimate, you can tell his by simply looking at the latest files vs the last time you updated your website.
2) Using plugins like sucuri and wordfence i was able to detect other files, these plugins are very good because the full manual method might not be allow you to browse inside every file to discover which illegal function has been added to a legitimate file hence forcing re-infection and making cleanups extremely difficult, these plugins helped point me in the right direction of which file is either wrong or has contents modified to embed malware and exploit code like the code i found below in the wp-settings.php file as was pointed out by wordfence security plugin. e.g "* This hook is fired onc*/ eval(base64_decode("aWYgKCFkadfKajK .... contents truncated.....TsKfQ==")); 424 /*e WP, all plugins, and the theme are fully loaded and instantiated."
Fortunately it was a bot that was doing this, a human being could have done much worse because they have the knowledge to dig for better information troves (I can’t list other generic valuable information they could take, not wise 😉 )
With all the .htaccess files either deleted or cleaned, the malware files all cleaned / removed and the site malware check 100% clean from the sucuri website, I moved to finding how and who.
Bots behave very much based on the thinking of the human mind so i started to look for backdoors into the website, i found a wordpress database account with admin privileges had been created by the bot i.e. wp.service.controller.Y6LUs, at face value it looks like a legitimate account until you realize two things
1) The random identifier at the end to prevent random name clashing by the same bot or other bots on reinfection e.t.c, but the most important fact is;
2) The user_registered timestamp is 0000-00-00 00:00:00, only bots that either bypass the system or are trying hide would do that, i.e. it is a machine that modifies timestamps like that, thus i deleted the account.
A dive into the access logs based on the timestamps of the infected files i begun to recreate the picture of what had happened, digging into logs is not an easy task especially for public facing services, the internet is a garbage bin with clean sections in a few places, that said, the number of legitimate bots (search engine bots like google, bing, Baiduspider e.t.c) that crawl the internet are so many and they are always working followed by the malware bots that also crawl but can’t get in most times hence false positives so my dive was going to have to find a way to simplify my log analysis;
=== LOG ANALYSIS ===
The key to log analysis isn’t to read the entire log, most times because that is time consuming and you don’t have all the time in the world but also because proper forensic analysis of other parameters can help place you at sections of the log that are more beneficial and a reference point to back track and forward track.
An additional approach in my case was to exclude the most repetitive none important traffic to this task, using the command below excluding http response code 404 - failed requests, wordfence - wordfence security plugin scans, doing_wp_cron - wordpress cron jobs. This leaves me with http response codes other than 404 including 200 for success, response code 500 for errors and the interesting response code 406, this is rare but this is an authentication "request not understandstood" response code, since i had a captcha system, I suspect that is where this was arising from. cat .\logfile | grep -v 404 | grep -v wordfence | grep -v doing_wp_cron > logfilter2.log === END OF LOG ANALYSIS EXCERPT =====
Back in the access logs, i begin to notice my wordpress cherry plugin was being suspiciously crawled my suspicions let me do look for vulnerabilities in the cherry framework, i discovered that there was a known bug in the public_html/wp-content/plugins/cherry-plugin/admin/import-export/upload.php. The author though notified several times according to some posts hadn’t fixed it in an updatable version of plugin (there was no update option on the existing plugin), the bug allowed for upload of files without authentication, this means malicious php files could be uploaded, called and a reverse shell could be triggered and exploits and infections carried out.
The irony is that upon analysis i realized that the bot upon infecting the site updated the cherry framework upload.php to prevent it’s future use by other bots but my restoration removed that so to fix it, i visited the latest version of the cherry framework reference on github and copied it’s upload.php file that had a user authentication section added and replaced the one i had.
Response code 406 logs
Log format: (IP Address, DateTime,GET/POST,URL, HTTP Version, HTTP Response Code, Content length (i am guessing),-,UserAgent)
184.108.40.206 – – [05/Dec/2016:08:49:17 -0700] “POST /xmlrpc.php HTTP/1.1” 406 608 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
220.127.116.11 – – [05/Dec/2016:08:49:17 -0700] “GET /wp-login.php HTTP/1.1” 406 395 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
18.104.22.168 – – [05/Dec/2016:08:49:17 -0700] “POST /wp-login.php HTTP/1.1” 406 442 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
** A point to note, analysis of the logs showed various access IPs to the same malware created files in different geographic areas implying a masking utility like tor or something of the sort
Mitigation is always tricky for search primarily because they involve bugs, always updating your plugins and software is key as well a security plugin but this might not be enough because the security plugin probably looks for strands of code and infected files i would add wpscan, a tool that can provide a list of the latest CVEs in the themes and plugins and fixes if any.