Cyber Intelligence Briefing: 11 Aug 2025. Canadian insurer denies claim due to MFA implementation failure

Assured’s CISO reacts:

Why do we think the insurer didn’t pay out? There are two possible reasons:

1. Minimum Security Standards condition: This is something we used to see certain underwrites put in their Cyber insurance policies and hence why we did no business with them while this existed. It basically says that if an incident occurs and the forensics discover you didn’t comply with any of the minimum security standards (e.g. MFA for all users), then the insurer won’t pay the claim. Normally, insurers ask this as a question in their application forms and will expect all policyholders to adhere to these controls BUT understand that sometimes it’s just not possible/there will be some exceptions. We’re human after all and humans make mistakes. The minimum security standards condition acts as a double negative from the insurer and gives them an easy get-out in large incidents (Ontario city ransomware attack is case & point).
2. Application form misrepresentation: Ontario might have ticked YES to the insurer’s question around “Do you enforce MFA for all users for all remote access to your network?” Then when the incident happened and it turned out they didn’t have MFA (so they’d misrepresented their risk), then the insurer declined to cover the claim. We hear from claims teams every day that they pay these sorts of claims (where the risk has been misrepresented slightly), but the reality is when you are facing an $18M (CAD) loss then you are going to seek a way out of paying it. This highlights the importance of picking up on the nuance and exceptions of where a control like MFA hasn’t been enforced.

The attack began with an exploited internet-facing server and missing MFA, impacting 80% of the network. Containment was achieved within two days, with critical services maintained throughout. Attempts to destroy backups failed, and most systems were restored directly from available backups.

Authorities have not linked the incident to any criminal group or malware variant, nor disclosed details of remote access use or lateral movement. These details are likely withheld due to the ongoing investigation. Key lessons from the known facts include:

• Ensure 100% MFA coverage with conditional access rules applied
• Undertake permitter (external attack surface) scans to explore what the cyber criminals can see (open ports, vulnerable hosts)
• Segment the networks and services
• Ensure back-ups are immutable

And finally, the transparency of the incident is wholly refreshing and undoubtably helped the public perception of Hamilton City. Their thorough PR: updates, include costs, enhancements with more details really dwell on customer-focus and improvements, not cyber. By turning the messaging of the incident away from cyber tooling and technical speak, into an issue of service, they’ve made it more relatable and engaging for the people they serve.

Assured’s CISO reacts:

The attack appears to impersonate IT to trick internal staff into installing a fake version of Data Loader (a legitimate SalesForce) app, with which they gain the ability to access, query, and systematically exfiltrate sensitive information. Other common tactics include using Mullvad VPN services for accessing victim networks and the deployment of Okta phishing panels.

If this comes up, we recommend:

• Block:
  • The installation and use of Data Loader
  • Download and block Mullvad IPs at the firewall or ZTNA level.
• EDR Detection:

  • mullvad.exe or OpenVPN/WireGuard clients running

  • TUN/TAP interfaces being created

  • Large .csv/.json/.xml file uploads to cloud shares (OneDrive, Dropbox).

  • Non-standard versions of Data Loader (or similar exfiltration tools like DBeaver, Jitterbit, Boomi).

• Monitoring:
  • Watch for DNS requests to api.mullvad.net, mullvad.net, or WireGuard config endpoints.

  • API calls to Bulk, QueryAll, or Retrieve with more than typical volume or frequency.

  • Unusual outbound traffic from hosts using domains like login.salesforce.com but not matching known user behavior.
  • Regularly check executable hashes against known-good versions from Salesforce.

• Salesforce-Specific Controls:

   

  • Restrict API Access by IP: Configure Salesforce API access restrictions to allow only sanctioned IPs/subnets.
  • Permission Set Hardening:
    • Remove View All Data, Modify All Data, API Enabled from unnecessary users.
    • Enable Transaction Security Policies to detect bulk extract behavior.