Managing the Aftermath of a Web Phishing Attack: Strategies from Detection to Last Vendor False Positive Cleared
Background
In the latter part of February, specifically on a Thursday, our organisation was notified by the web agency that their website had suffered a phishing attack. Promptly on the same day, the web agency responded by restoring our website from the latest backup and implementing necessary patches to update any plugins and the core Content Management System. To ensure that the website was functioning optimally, we continuously monitored it using the MXToolbox, which checks if it is blacklisted.
Everything appeared to be working fine for three days, and no issues were reported. However, on the fourth day, some of our users began complaining that their emails were either not getting through or were blocked by the recipient. This was when we realised a bigger problem than initially thought and needed to escalate the issue further.
We immediately initiated our incident response plan to contain the situation and prevent further damage. We already knew the root cause of the problem, which was a phishing attack and found that the phishing attack had caused some email servers to flag our emails as spam, resulting in their non-delivery or being blocked by the recipient.
We immediately took steps to remediate the issue by working with the web agency, email service provider and endpoint security provider to resolve any outstanding issues. We contacted affected users to ensure we were doing everything possible to resolve the situation.
Solution
Here is the chronology of what’s happened and the steps that we took:
Ensure the website and web infrastructure are patched
The first week, as a typical website is outsourced to a web agency, we rely on them to tell us what has been done regarding the restore and security updates on both the website and hosting side.
We can only advise ensuring patching the code of the Content Management System, plugin/component updates, PHP version, and the back-end system they are using.
Ensure the DKIM and DMARC are in place
Once we receive the email that gets blocked (the first week), the first thing to do is to secure more on the Microsoft 365 Exchange in terms of spamming, just in case coming from the web server itself. The domain already has an SPF record, BUT to tighten security further, put places the DKIM and DMARC are in. This process took about 48 hours to propagate correctly.
Ensure the Microsft 365 Tenancy is OK
Entering the second week, with Microsoft Support’s help, we ensure this tenancy is OK – it did OK. We asked about the detail on how to check, and they said the information is only available from the backend.
Remove the blacklist from MXToolbox and Valli.org
After receiving the web agency’s information that the site got a phishing attack, we checked MXToolbox and Valli.org and found zero blacklists. We checked these first two days and found no blacklist.
Once we received the information that the email got blocked (the first week), we rechecked the MXToolbox and Valli.org and found one blacklist. We notified the web agency about this.
Entering the second week, the web agency did not action this, so we took action to remove this. We managed to contact the vendor, and it was removed within a day.
However, we still found a small number of users, not all, unable to receive a reply on the other end. We ran a mail trace under Microsoft 365 Exchange, and the email was delivered successfully. There is a potential for the other end to block the email. We then talk to the user, as backed up by Microsoft 365 Support, to let the other end recipient let their IT knows about whitelisting us. This approach is not well received by the user as this is not feasible to let the other end know. We explained that this is a common practice.
Content Filter
Entering the 3rd week, we look further at the individual cases and bring Microsoft Support to remote access to the user’s machine to see how the email is being sent. While doing some transmitted email testing, we found that the email gets blocked or bounced if we put the entire domain on the signature. This is an Aha moment!!! So the issue is related to the content filter on the recipient side.
The workaround for avoiding this content filter is not to include the website address or any related domain in the body, including the text signature. It may need to use the image as a signature in the future.
Submit the URL for analysis on Web Filter/Security Vendors
During the 3rd week, we research heavily on web filter and security vendors and found some, such as Fortinet, Palo Alto Networks, Trellix, ESET, Cisco etc. They have their webpage to submit “the URL for analysis”.
We wrote a template for the content to outline what happened and when and what the web developer did to secure the patch. Then we submit using this content to each vendor.
The tip for this is not to use the exact domain URL but try to change something like this: domainname[dot]com[dot]au or domainname[.]com[.]au, and this will avoid content detection.
While we went down this path, we searched on Google to find out how many web filter/security vendors there were and found a lot. Luckily, while researching this, then we found VirusTotal below.
Submit the URL for analysis listed on VirusTotal’s 86 Security Vendors
During the 3rd week, while we researched the web filter/security vendor above, we found this VirusTotal.com on Reddit. This VirusTotal is an aggregate web tool from 86 vendors reporting to this website. It’s a similar concept for MXToolbox, and it’s an aggregate blacklist community.
During this week, we found 12/86 vendors listed as phishing or malicious. Initially, we reviewed this list and then searched for the vendor and where we could submit “False Positive on the URL.” Then finally, we found some links on how to contact these vendors:
https://www.getvisible.com/false-positive-virus-malware-scans/
https://tickets.onehoursitefix.com/kb/faq.php?id=163
https://github.com/yaronelh/False-Positive-Center
Not until one day, we had 1/86 vendors listed and bounced emails to contact them saying that the email didn’t exist, so we signed up for the VirusTotal and raised a ticket with them, and they gave the exact list above.
Please check out the article to see the updated list we wrote below.
Entering the 5th week, as we submitted the false positive already to the vendor, the tally for VirusTotal was down 4/86 vendors listed, which is excellent progress.
Then in mid 5th week, we finally managed to remove the last one (Avyl-AVL) from the VirusTotal list, and now it is 0/86 vendor listed.
What’s from here?
We keep monitoring the domain via MXToolBox, Valli.org and VirusTotal.
We also look at the individual case about blocking email and try to accommodate the resolution by contacting the vendor even though this particular organisation has no direct connection with the mail provider, Bigpond for instance.
At the same time, as backed up by Microsoft 365 Support, the approach will be if the email is delivered successfully from our end on Microsoft 365 Mail Tracer and then it bounces or the receiving end does not receive the email. Then we say to the internal user that needs to report to the recipient end that they need to check their junk mail or quarantined email and then escalate to their IT to either the whitelist or look a the issue – this a common practice!
Summary
A website is typically outsourced to a web agency, and they should be responsible for hosting and maintaining the website and hosting security. Typically, the developer sets and forget in term of website security. This is alarming because domains get blocked by the content filter, and emails get blocked if a domain name is contained in the body. Also, the URL gets blocked on the browser. As an IT, we are not controlling this part, so all we can do is be advised to have a regular update (once a month) on the website and explore the private server with limited clients host. Unless the website is e-commerce, a private server is a way to go.
In our case, this organisation has a Third-party Partner that supports Microsoft 365 as 1st level support. Then if it’s needed, escalate to Microsoft 365 support directly. This support model was frustrating as we wanted to talk directly to Microsoft 365 support. Still, this Partner tried to solve it but with limited knowledge. There was some delay in the escalation process due to inconsistencies, such as:
- Not providing the Microsoft Support ticket and sometimes missed the call, and when to call back and they ask for the support ticket, and that support ticket is not listed in the Admin Portal
- On Microsoft 365 1st level (Partner), some take ownership of the case, and some don’t
- The operating time of this issue is Microsoft 365 1st level (Partner) support 9 to 6
- Microsoft 365 engineer support time zone is different for each person.
On the VirusTotal, once submitted the False Positive on the domain, there is a waiting time. It can take a while – a week or more. The method of submitting this False Positive was web form and email, but we also found submitting via GitHub, in this case, Phishing Database.
Not all security vendors are listed on VirusTotal, but the majority does. There is no Cisco Talos Intelligence on this list. The solution is to report false positives to their website directly or through their portal.
After we signed up with Cisco, we found that each company has a database with standard fields such as detection dates, web reclassification before and after the incident, and expiry dates. Whether they are enforcing these or not, we do NOT know. After talking to a few security vendors, web reclassification for phishing or malicious is considered at the top of the list. It can be up to 4 weeks or one month for expiration. We could NOT confirm that if we do not report false positives, and after 4 or 5 weeks (passed the expiry date), would it be automatically removed? We could not get this answer from the vendor – they will not reveal this. Usually, this detection intelligence is handled by other divisions within the company, or it might be outsourced to a specialised third party.
Please let us know what your thought is. You can participate in this discussion on dewachat.com
Credits
- Featured image by rawpixel.com on Freepik
- TechSupportAlert.com
- GetVisible.com
- OneOurSiteFix.com
- Github: Yaronelh
