Impersonating Government Agencies To Deliver Infostealers - The HZZO Example
A prevalent form of malware involves infostealers, which focus on collecting and extracting sensitive data, such as login credentials and financial details, from compromised devices.
Infostealers typically target cryptocurrency wallets, browser extensions, two-factor authentication (2FA) tokens, and other valuable secrets stored in popular endpoint software. Threat actors often distribute this malware via emails containing attachments or links that masquerade as coming from reputable companies or organizations.
For example, recent months have seen frequent e-mail campaigns trying to install infostealer malware by impersonating HZZO, a Croatian government-run health insurance provider. As many Croatian citizens frequently interact with this organization, it's understandable the attackers try to use the HZZO "brand" to facilitate malware deployment.
But how can attacks impersonating government institutions be prevented in the future, especially if it's likely they will become more sophisticated? Let's understand the details and try to identify what can be done to improve the security posture.
In this particular case, the attacker is trying to persuade the recipient to open a document which contains a well known infostealer, the pretext being a registration confirmation to an insurance plan. The e-mail is badly written featuring some key grammatical errors, and requires the user to explicitly open a compressed archive and then execute and install the malware.
Furthermore, the attacker is making no serious effort to properly impersonate the HZZO brand, crafting the email in such a way that all modern e-mail providers should warn recipients this is indeed a suspicious message.
Overall, this is a very sloppy and naive attack, unworthy of any writing. Yet it appears such attacks, even in its most rudimentary form, are still a significant threat for many organizations in the region.
There are 3 key elements here to consider: the malicious sender, the victim recipient, and the impersonated brand (HZZO). So let's go through them.
First: The Malicious Sender
First, the sender: it appears the attacker is leveraging legitimate but poorly maintained email services at regional internet service providers (often bundled with web hosting). These include government institutions and private internet service providers. For example, one such campaign originated from the Faculty of Medicine at the University of Belgrade, in this case the service being run by the Academic research network of Serbia - AMRES, as shown below:
In another case, the originator is a business park in Hungary, the service being offered by a local internet provider.
In both cases, we see the providers are running the same webmail software called Roundcube. This is an open source package that aims to give you a webmail experience, sort of poor man's Gmail or Microsoft365, just run from your garage.
But as any self-installed software, Roundcube requires maintenance, patching, expert configuration and continuous monitoring in order to balance email deliverability and protect users against the latest threats. Also, lots of other open source software has to be expertly installed, maintained and configured, and security best practices such as multifactor authentication (MFA) has to be implemented. Nothing of this sort can be done profitably (and monetized) by the web hosting providers running these servers.
So it's no wonder they are easy prey for attackers: for example, CISA's Known Exploited Vulnerabilities Catalog shows many RoundCube bugs are already being used by attackers in the wild (see here). Even without those bugs, attackers nowadays will typically use leaked credentials to simply login as legitimate users and start mass-mailing. More often than not, attackers simply log in, they rarely break in.
Such providers effectively do not have the time and resources, nor is their business objective to run a secure modern email/business collaboration service. They effectively boot a Linux server, perform basic configuration and install some open source packages, and that's it. From then on, the user is on its own and often doesn't realize they have an attack surface to care about.
It turns out such configurations often allow sending email from arbitrary email addresses, as is the case here with HZZO (hzzo.hr being the domain used in the faked envelope sender address). In this case, it appears the attacker is not tech-savvy: they log-in on behalf of a legitimate user, manually create a new message, copy/paste a maximum number of emails allowed into the BCC field (1000?), select an arbitrary sender, and... click Send (yes, all this is discernable from the email headers from a sample we obtained). After that they rinse and repeat for each batch of emails until they send to the entire list, probably tens of thousands of addresses harvested from various dark web and illegitimate sources.
Unfortunately, the prevalence of the above described email service providers ensures plenty of room for threat actors to launch such trivial, yet dangerous attacks. We can be confident many more will follow in the future and not much can be done here (except stay clear of any regional provider running a similar setup for your own email, see more on that below).
Second: The Impersonated Brand
But let's turn to the impersonated brand, in this case HZZO. As any well known organization that can expect attackers to use their domain name to impersonate legitimate email, it has the option to publicly indicate the authenticated sources for its email.
The well known mechanisms here are the DNS-based protocols SPF, DKIM and DMARC, but there are other emerging options such as BIMI and Verified Mark Certificates (VMC), which can all help reduce the attack surface, if strictly and diligently configured.
Before these well established authentication standards, it was up to receivers to decide a reputable sender's email’s fate. Now email senders (such as HZZO in this case) can take the steering wheel by defining their authentication policy: what action should any receiver take when a message does not match the DKIM/SPF/DMARC policies.
This is the key lesson for any government or private organization whose brand or name could (and will!) be leveraged to facilitate malware delivery: promptly implement strict SPF, DKIM and DMARC configurations so that the community of recipients can benefit and block those emails.
Of course, this will not be the ultimate solution to all phishing and spoofing attacks, but will significantly reduce the scope for attackers.
In this particular case, it's worth noting the attack is so rudimentary that it would fail even the basic SPF authentication (a first checkpoint), allowing any recipient to block such messages before reaching the inboxes: HZZO dutifully published an SPF policy (and DKIM, DMARC as well) asking recipients to reject email supposedly sent from HZZO, but originating from unauthorized infrastructure or servers.
However, in order for this to work, it's up to each recipient to enforce it or honor the policy in its email filtering policy at the provider level. And that brings us to the last, third, element - the victim, a person relying on a particular inbox provider (say, Gmail, Microsoft365 or even a self-hosted service like the RoundCube-based described above).
Third: The Recipient or Victim
Nowadays, recipients rely on a range of service providers to host their inboxes. At one end of the spectrum are large SaaS providers like Microsoft365 or Google Workspace, while at the other end are budget web hosting providers or tailored hosting solutions that include email services as part of a bundle or wider offering. These are typically offered by local companies in the region, so let's call them "local" to distinguish from the first group (the large SaaS providers).
And here’s the problem for recipients hosted by local providers: these providers typically do not perform even basic authentication checks or filtering for incoming emails. The reason, as previously outlined, is that email filtering carries the risk of blocking legitimate mail. Given the many nuances involved, local providers prefer to avoid excessive helpdesk calls, manual rule adjustments, and the analysis required to determine why legitimate emails were blocked.
In practice, effective email filtering is a specialized service that costs money because it requires a constant balance between blocking malicious mail and avoiding the overblocking of legitimate emails, always preventing a 'storm' of angry users contacting the helpdesk.
Major SaaS email providers continuously adjust this balance because their scale gives them a stronger incentive to do so. Preventing their infrastructure from becoming a launching pad for attacks and avoiding customer churn are much more immediate concerns when millions of users are at risk—concerns that are less pressing for 'local' providers.
Ultimately, users hosted by local providers are more exposed to email attacks, such as the HZZO example discussed. This lack of basic filtering is a source of risk for many organizations in the wider region, particularly in the government sector where "custom" email hosting solutions are the norm - something ransomware/infostealer operators are well aware of.
In contrast, at SaaS providers, such emails are more likely to be filtered into the Spam/Junk folder. Additionally, the inbox interface at these providers typically offers more visual cues to warn users if something suspicious appears in their inbox (see screenshot examples below).
Recipients should therefore choose a modern email provider that incorporates all the latest emerging authentication and validation protocols, combined with advanced malicious content filtering. The email provider should constantly monitor and adjust filtering email content in order to block the latest spoofing, phishing and business email compromise attempts. All that should be managed and ON by default, at no extra cost.
Currently, it appears only large SaaS providers such as Microsoft 365, Google Workspace and similar ones are able to provide such services at scale and by default. Of course, local providers are sometimes doing it as well, but often more reactively and not by default (or at extra price).
Finally
So what's the conclusion?
From the sender perspective, government and private organizations should act quickly to publish properly configured and restrictive DKIM, SPF, and DMARC policies for their domains—don't stop at just SPF or leave permissive configurations! This is especially urgent for any brand or institution whose identity is likely to be targeted in spoofing or impersonation attacks.
At the same time, users or organizations at the recipient side should move their inboxes away from local providers. Unfortunately, these are a losing proposition, and ditching them could prove beneficial from two aspects.
First, these providers serve as launching pads for attacks, as demonstrated by the HZZO spoofing example above. Due to poor or minimal management, they often neglect to invest in strong multifactor authentication (MFA), rigorous patching, and integrated detection and response capabilities to counter persistent threats within their infrastructure.
Second, email recipients or customers at local providers are typically left exposed to attacks, with inadequate protection against rapidly evolving threats. Security is a service or process that requires continuous monitoring and improvement, often demanding significant effort. However, when done at scale, it doesn't have to be costly. Therefore, utilizing large email SaaS vendors who are incentivized to secure their users and infrastructure is the right choice for customers. Otherwise, they face increased exposure to modern threats and impersonation attacks.
