First, I’d like to compliment Sucuri on a fine, detailed analysis of the Sign1 Malware.

 

Kathy Zant has also analyzed this on her YouTube channel.

 

A quick recap first, in the unlikely event you’re not familiar with this.

 

Originally Sucuri stated they found approximately 2,500 in the past 2 months. Their original analysis was published on March 20, 2024. We’ve been seeing this mainly over the same period, about 2 months. However, being we perform file integrity, database monitoring, access log streaming and process monitoring on just over 13.1 million sites now, we see quite a bit more than others.

 

As of March 25, 2024, we’ve seen 3,654 cases of infected sites abusing the Simple Custom CSS and JS plugin. Please note: This is not a plugin vulnerability of the custom-css-js plugin. It’s an abuse of it’s functionality.

 

In these infections, the functionality of the plugin is being abused to add code to a website. This code uses a variety of techniques to grab new malicious code and inject it into your site generally causing redirects.

 

The two sources mentioned above do an amazing job of analyzing the code and describing the functions so that will not be repeated here.

 

What’s the point of entry?

 

In the original analysis it was stated that some of the original points of entry were brute force attacks. Some could say it’s a dictionary attack, but either way, those two types of attacks leave an incredible trail of evidence in the logs.

 

 

 

 

 

From this snippet of a log file, you’ll see many attempts at logging in from a variety of IP addresses.  This data is not detailed enough to determine if this is a brute force attack or a dictionary attack, but it is an attack.

 

Sometimes you’ll also see this directed at the xmlrpc.php file. To me, it doesn’t matter if this is a brute force attack or a dictionary attack, the desired outcome for the attackers is the same – to gain entry as an admin to this WordPress website.

 

For either of these attacks to be successful, the hackers have to obtain/guess the correct username and password combination. If either of these attacks are successful, there will be evidence in the database and also in the access logs. After successfully logging in there will be various lines in the access logs to indicate a successful login.

 

For instance:

 

GET /wp-admin/load-styles.php?c=0&dir=ltr&load%5Bchunk_0%5D=dashicons,admin-bar,site-health,common,forms,admin-menu,dashboard,

 

might be seen in the logs. A combination of the access logs and the database is undeniable proof that a successful login, using the username and password, has occurred.

 

A brute force attack or a dictionary attack will have a series of the first log entries followed by one of the above entries if the attack was successful. One could argue that the second line of “…load-styles.php…” could have been a legitimate admin logging in, which is true. However, there is enough evidence in the complete log entry to positively indicate a successful attack versus a legitimate admin login.

 

In our analysis of the Sign1 Malware attacks, we see that out of the 3,654 attacks we witnessed, all of them were due to compromised username and password combinations. What we did not see was the numerous attempts before hand. We did not see the myriad of traffic from various IP addresses to the wp-login.php/wp-admin or xmlrpc.php. We saw straight logins from IP addresses that should not be logging in to WordPress sites. No lengthy attempts, just straight logging in.

 

On these 3,654 sites, we were able to go back and analyze the previous 6 months of data – and yet no sign of a successful brute force or dictionary attack was found.

 

Then how?

 

How could this be?

 

It’s our old fiend, the info stealer. We have way of proving that, but our research continually shows the prevalence of these nasty critters. The cybercriminals use them for a variety of purposes, but they love stealing login credentials or authentication cookies. In this case, in this analysis we did not see any evidence of the attackers gaining admin logins through the use of stolen session cookies. None.

 

100% of the 3,654 we saw, were all stolen username and password combinations.

 

Not all the sites we witnessed this on already had the plugin installed. ~26% of the cases, the hackers installed the plugin first, then added the malicious code to the plugin’s functionality to redirect the site.

 

What can you do?

 

First, as stated before, be certain your local device is malware free! In talking with many of these site owners, it was discovered that almost half of them use Macs. It was 47%. Of those 47%, only 9% were using any type of anti-virus/anti-malware software on their Macs. We heard the usual, “That’s why I bought a Mac because I was told I wouldn’t need anything to detect viruses!”

 

It’s like if you ask someone, “What kind of radon detector do you have in your home?”

 

And the person says, “None. We don’t have radon in our home!”

 

How would you know if you have nothing to detect it???

 

Arghh!!!

 

In this case, the other thing to do to prevent this attack is to install 2FA (Two Factor Authentication). When dealing with stolen or guessed passwords, one of the easiest preventative measures is to add 2FA. The hackers can’t get past this extra level of protection to login to your site, if they only have the username and password.

 

Info stealers are extremely popular in the cybercriminal world. There is data online about how they evaded detection and what they steal. Some will say, “Why would they want my site when they can steal the bank logins too?” They steal it all! They need legitimate websites for their other operations; phishing, DDoS, etc.

 

Don’t provide them more digital assets.