The Damage

I came back home from a friend at around midnight to an inbox full of worrisome emails. First, was the email from the owner of illozoo.com asking what happened to the site. When I visited the site, it was getting redirected to some other malware site which wants you to download a “missing font pack”.  It was pretty embarrassing and the worst part about it was that we found out because visitors complained. I was freaking out.


A chrome plugin called Redirect Path came in handy in finding out what’s going on:

After making sure that everything on my server was fine, I saw these 2 identical emails from Cloudflare warning about suspicious activity on the account and it all clicked together.

To top it off, I didn’t get these emails on time because my phone has died 3 hours earlier and my friend didn’t have USB-C charger nor did I bring mine. A series of unfortunate events.

The clean-up

I quickly logged into Cloudflare, enabled developer mode which bypasses everything, and after going through the settings I found two 301 Redirects to a bit.do shortening service. ( with wildcards to cover the entire domain, sub-domains, dirs, www and non-www version — pretty simple and evil)


301 Redirect = Nightmare from hell

If you’ve ever dealt with a permanent 301 redirect, you probably know it’s the Devil’s work. Once a browser caches a 301 Redirect it does cache it permanently… as in forever. It’s amazing that browsers to this day behave in this way.  The only way to “refresh” a cached 301 redirect is to clear your browser cache. Not just force refresh using Shift+F5 since there is no way you can press theses buttons while on the domain. It will get redirected before you press it. You’d need to clear cached images and files (Using Ctrl+Shift+Del on Chrome on Win). Requiring every affected visitor to do this just to fix your website is unacceptable. That’s how a hacker can completely toast a high-traffic domain name overnight without ever getting a hold of the domain. Fortunately for me, browsers also honor the expiry date of a redirect and Cloudflare has their set at a fixed 1 hour. This is the only thing that saved me.

To summarize, the clean-up was pretty straight-forward:

  1. Remove the 301 redirects from Cloudflare.
  2. Change password and enable 2-factor authentication on the account.
  3. Wait 1 hour for the cached redirects to expire.
  4. Disable developer mode

The Virus

Although I didn’t have the balls to run the fontpack.exe file from the malicious website on my machine, I ran an online test using virustotal.com and sure enough it was packed with “goodies”. (Notice that from the time of making the screenshot until the day of writing this article more antivirus groups have caught up to it)


Finally, I wrote a quick note to bit.do and they were kind enough to remove the shortened URL from their service:

Cloudflare’s fault?

My initial reaction was to blame it on #cloudbleed but after getting familiar with what it affects, it seems like this may be unrelated to it. Could it be that it’s just my account that got affected due to weak password? I highly doubt it. I’m using LastPass to randomly generate 16-bit alpha-numeric with special characters passwords and if my lastpass master pass was compromised, a lot more damage would have been done. What I’m definitely blaming Cloudflare for is being unable to require some additional identification upon identifying the suspicious login activity. Sending an email is simply not enough. Lastly, once they identify suspicious login why would they allow them to set up 301 redirect on the entire domain? This could have been thought out more thoroughly. Even if it was really me doing it, I wouldn’t mind having to confirm this action over email. I don’t know… I’m not a security expert but I’m not the only one with this problem and i’m sure they’re aware of it:


Oh, and 2 factor auth is not bullet-proof apprently:



Leave a Reply