In this post I will talk about some incident response work I did for a non-profit organization dear to my heart.

One of their front-facing websites was experiencing trouble, it was redirecting some of its visitors to a strange human verification page..

Some Context

Before reaching out to me they had already contacted their ISP and the developer of the website for help, both of which weren’t able/willing to contain the problem. No matter how many times the developer removed the malicious code from an infected page, the attacker would simply infected it again while spreading to other pages.

By the time they contacted me the website was already in pretty bad shape. Some links on their homepage pointed towards a 404 of their ISP, others pointed to a static page of the developer while some others were just blank 404 pages. The rest of the pages were redirecting the user towards some social engineering trick which tried to make the visitors accept (malicious) push notification. It was masquerading as a sort of intermediary human verification step, much like what you sometimes see when using a VPN service while trying to access Google services.

Their ISP ran a vulnerability scan on all of their websites and found some SQLi vulnerabilities in one of them (not the one under attack). The assumption at the time was that attackers used this to insert the malicious javascript in the other website, causing the redirects to the malicious human verification page. A bit far fetched but possible.
Since those SQLi issues were already raised four months ago in my vulnerability assessment, they contacted me.

The Findings

I made sure to continually send my findings and recommendations to the staff.
In the first few days I discovered the following:

• The malicious human verification page where the users ended up was made specifically for Chromium browsers.
  • It used chrome-specific API calls to request push notification permissions.
• The attackers inserted up to three malicious scripts into an infected page:
  • One malicious piece of javascript attempted CSRF attacks on the admin panel of the website.
    • Notably, this piece of malware was present in every page, even those not infected by the redirect script.
  • Two redirect scripts, each using a different chain of redirects, one long and one short
    (they could both end up in one of five landing pages which were variations on the same malicious human verification request with different images and styling).
• Before arriving at the landing pages there were many redirects, in varying amounts.
  • I wasn’t able to find malware in the few redirection pages that I checked.
  • The history of the browser was cleared by javascript to make this less obvious to the user.
    

Four days into my investigation the attackers began cloning and replacing many of the resources in the targeted website, filling them with more of the malicious javascript that redirected users. When alerting the staff of this discovery the homepage already counted 52 references to the attacker’s domain.

Then the worst-case scenario happened, the attackers successfully attacked and gained control over the admin panel, locking us out on their way in. By this time the staff had already redirected the domain to to another one, to safeguard the visitors. The staff established that the top priority was to find out if the attackers also infected a different important website which allegedly relied on the same database as the infected website. They were fearful the infection might spread to this other more sensitive website. I was to be tasked with fully investigating the attack, focussing on a potential spread via the database.

Before I was able to get started however, they found conclusive evidence that the database of the infected website was completely separate. They decided to give up on repairing the infected website as it seemed more work than the website was worth (especially since they had already planned to replace it in the medium term). This also means the website had been attacked using another venue. Since the website (and all of its plugins) were rather dated the attackers probably exploited one of those to gain access and implant their malicious javascript, this is however pure speculation as I did not conduct any more research towards this end.

That marks the end of this tale. The website was quickly put out of its misery, defeated by complexity and cyberspace pirates.

Conclusion

Investigating a real attack was very interesting and I have learned heaps. Although I was presumably only asked to help out because they had nowhere else to go, I would still like to thank them for placing their trust in me. :)

The tactics that the attackers used were pretty ingenious, at least if I’m not reading too much into their actions.. Breaking only some parts of the websites with something rather innocent looking while lining the rest of the website with a hidden privilege escalating exploit. This way owners/administrators would be tempted to log in to their admin panels to check out what was happening, not knowing their sessions were probably the real target. Failing that, the attackers would infest every resource on your website, maximizing the amount of users which would be redirected towards their malicious second stage. I never figured out what the attackers had in store for the users which accepted these malicous push notifications though. I presume they could use it as a sort of C2 implant although this would probably require additional exploitation of the push notification mechanism in the browser. In any case, the implant would probably produce a pretty stable connection since cleaning out accepted push notifications isn’t something people do frequently, and neither is removing/switching browsers.

I was rather excited to take on this investigating challenge and was sad to see them give up on recovering their website. Although it was true the website was somewhat aged and the blend of plugins they used made it difficult to upgrade without making many breaking changes. I believe this last bit in particular to be the website’s undoing, if it would’ve been easy to fix they’d have done it.

The complexity of patching also deterred them from maintaining the website, which over time lured in attackers.
I would say complexity was the true killer of this website, a point I drove home in my later conversations with them. Luckily they have learned, and have aimed for simplicity and better security in their future digital investments.

A Tail

Approximately two weeks after the story above unfolded I stumbled upon another website which seemed infected with the same affliction, this time a company fell victim. They were in an early stage still, uncloned and with only a few pages carrying malicious javascript. I immediately reached out to them, condensing my findings and warning them to keep anyone with a live session to their admin panel away. They did not respond, over their website succumbed and after a few months they advertised their new website.. A sad display indeed.

Due Diligence

Since this was now a repeat attack on Belgian websites I urged both victims to inform the Belgian CERT of their respective attacks. I also informed the non-profit in question about the privacy-implications of a full website takeover, GDPR-wise.