MALWARE attacks are the equivalent of a COVID-19 infection to a website or a server.
Since the Brain virus was deployed nearly 40 years ago, cybercriminals and “for the glory” hackers had picked on servers and websites–finding enjoyment in even the most resilient ones, either for profit or gain notoriety.
One of the most dangerous concerns any webmaster will face is malware. Either on a website and even more devious, in an office or hosting server.
The easiest way to penetrate a corporate system is to overcome the site firewall and gain access to the domain. This can be done mostly by social engineering attacks, including clever ways of using ports and unseen vulnerabilities to steal the richness of that domain (in terms of hits and views).
This happens to any website produced through any Content Management System (CMS). A lot of websites are now built using WordPress, because not only is it powerful, but also versatile. There are other CMS platforms like Joomla, Drupal, build-it-yourself sites like Wix and e-commerce specialized ones like Shopify and Woo Commerce.
Custom coded sites
Custom site coding either from ground-up programming or a modification of available CMS themes is also done by website owners–especially those with e-Commerce and payment capabilities to be able to protect sites and their users from attacks. This is because these sites utilize personal sensitive information like credit card numbers.
Sites built on Drupal need a lot of custom coding which has steered many web builders away from it. Those with no coding experience find it tricky to manipulate the site, how to change the appearance, or add extra functionality. It’s definitely not as beginner-friendly as WordPress. Moreover, most Drupal websites have a heavily customized theme created by a developer, which can be very expensive.
“Good” malware developers
A good malware developer can be defined by “having an ability to usually find loopholes and vulnerabilities” in a website. In some countries, including the Philippines this has become an actual paying job.
Hackers creatively develop code that is embedded by various means–a system vulnerability, phishing–through social engineering, a server gap, a USB, a self-executable code that happens when a seemingly innocuous file is sent via email and enters the network. Sometimes hiring someone to provide access–an inside job is also used. But since hackers always work through the system’s back door, and enjoy the demented pleasure of hacking with great difficulty. Thus having an entry through the front gate is easy and therefore not appealing to the true hacker.
Once in the system, all that is required is shooting a payload of virus into a computer and this one penetrates the network. Code intrusion that targets a specific website, or an entire CMS can ruin how a site works, and it can be quite difficult to remove.
A ransomware attack
The worst kind of malware attack is ransomware.
A form of malware, that hijacks the site, freezes its content, making it very difficult for site owners to gain control of their web assets without first paying a specific amount of money.
Recently, a local website was attacked by ransomware from Chinese bad actors (judging from the language used in the pages) shutting down the site and asking for a ransom of 10 Bitcoins–the equivalent of P19,107,454.95 for the site owners to regain access. The Bitcoins were supposed to be deposited via an anonymous BT transaction through a link provided that transacts over the Dark Web.
Instead of giving in, the site owners pulled down its site, change the domain name assets, and pointed it elsewhere. But so much damage was made–both from a notorious malware called the “Japanese redirect” that changes index functions, embeds itself into the system and starts showing up Japanese (Hiragani) characters before redirecting the traffic to a gaming site.
The ransomware purveyors could not penetrate the highly secure core assets of the site and thus were only able to get low-level access. Still, the damage was severe–causing site users to be redirected. This affected the website’s reputation and ate part of its 2.5 million daily, organic, pageviews. Site visitors were also pissed off at not being able to access the information they wanted from the website.
Site reputation is difficult to build and recover. This site ran on the power of its all organic followers–which also was very attractive to hackers. Paying hijackers however encourages the proliferation of this practice.
This is why it’s critical to eradicate ransomware at the onset by not paying hijackers anything. There are ways to do this including a domain redirect, a delinking (gives the hackers the impression they are still under control), and recovering from database backups. The rules for backups are clear–one backup is no backup. So this site had three. On the Cloud, in a local server NAS and in the server hosting service.
Comments section
In the case of this site, using an unknown vulnerability in the site’s comments section, cybercriminals were able to inject a payload that not only diverted the site. This hidden content contained malicious links that may also appear throughout a website. In the three days that the website was plowing against the attack, the malware was being detected in over 1,000 locations on the site. Such malware carrying malicious links can damage a website’s reputation and rank within search engines.
The second result of this creative way of site penetration resulted in what is known as “cross-site scripting,” which is done without any sort of admin access. Essentially, by way of insecure code on the website, an attacker can manipulate the information passed to the visitor’s browser, to make a popup that is not a part of the site appear to be part of the site. This was detected on day one of the attack and it was immediately thwarted. All pop-up messages written in really bad English were discovered and removed.
cWatch Comodo, hired to create the malware cleaning of the index file reported over 1,114 attacks of malware and 11 attempts to rewrite the site’s code.
Site agnostic
While hackers may prefer to attack servers and websites that are outdated, the malware shows no prejudice and can appear on any website or server — even ones using the most updated versions of WordPress or any other CMS. In the case of this website it had already been updated to the latest WordPress 5.8 before the attack happened.
An organization known as The Open Web Application Security Project (OWASP) were very helpful in the discovery of the kind and extent of the software vulnerability in that site. OSWAP is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences. It is the source for developers and technologists to secure the web.
What happened to the site?
This particular site has been attacked profusely since the start of the pandemic–over 700 listed attacks halted by Site Lock. This attack, since it was so clever and pretended to be coding work being done of the site was not detected. The first sign of the attack were messages hosting provide Hostgator, asking for code verification (an OTP of sorts) which of course was not provided.
The second level was when it was redirecting its traffic got redirected to a dubious gaming site that contained many malicious links. This was stopped only four days after the first attack due to the complexity of how it embedded itself in the site public index. By this time, Google’s search engine began penalizing the site for having malware.
At the same time, it also developed multiple broken or redirected links within the site. Since the malware will interfere with the website’s code, there’s a chance your site will be broken. Search engine crawlers can flag these broken or hijacked links or pages, further harming your search engine ranking.
The worst part is the hosting server did not notice these errors, for more than a week. Not until the site owners gave them notice. The reason for this is that the changes in the site happened inside the databases came from inside–like like an authorized change–so the server inoculation system–SiteLock–did not detect the changes and left the damage for 1 and ½ weeks.
Recovery
To recover, the site managers separated the site domain from the main landing page–which suffered the most infections–and instead created links to individual parts of the site and posted these links on their social media pages. But not before doing a complete malware removal.
To fix the situation a skilled “white hat” hacker–known in the circles as an ethical hacker–was hired alongside an adept WordPress programmer. Together with the site’s webmaster, they recovered the site, recovered from backup (some of the backed-up databases were scanned and revealed the presence of malware) thus the Cloud stored backup was used. A new domain was purchased and a the site was rebuilt this time with each database carrying a poweful payload of anti-malware code.
The white hat cleaned all incidences of injection malware to the databases, (SQL, NoSQL, OS) as well as low-level LDAP injections were defeated. But not before making a copy of the notorious payload. At this time the ransomware actors thought they still controlled the site and continued to ask for the 10BT to be paid on or before August 1–the day they will shut down the site.
Around July 28, the site owners pretended to give up the site and were ready to pay the ransom. But they did the reverse.
On the morning of August 1, the cybercriminals shut down the not knowing a malware load was waiting for them. On the afternoon of that day, using a different domain and a strengthened site, they went back live.
“Do unto others what others have done to you.”
It is hoped the cybercriminals had learned their lesson the hard way. “Do unto others what others have done to you,” is a completely wrong motive but it is a powerful one. At the time of the site surrender and lockdown, site owners sent hostile malware data to the ransomware site accessing the account remotely, by providing log-in accesses that pretended to be secure data unleashing a reverse storm of the same malware they used on the site. This “trusted data” was sent to an interpreter on the hacker’s site as part of a command or query.
The seemingly benign data tricked the server on the cybercriminals side into executing unintended commands that delivered a payload of its the same virus it sent over–a remote access Trojan (RAT). After doing this, the site managers allowed the black hat hackers to take control of the old site. It was completely shut down.
Since the domain ownership was not transfered, the old domain was de-linked in preparation for a “malware scrub” to disassociate any and all kinds of malicious links to the domain. At a later date, a redirect of a popular domain would be done. But not until the domain was tested over and over again as safe.
The news site has now reopened with an even greater level of security and a healthy fear of hackers.
