Last December OWN analysts observed a phishing campaign impersonating HR departments and targeting corporate employees with malicious emails announcing fake salary increases. This is a recurrent social engineering theme occurring at the end of the year1 when salaries are being negotiated in many organizations, but this theme can also pop up at other times of the year, for instance during summer apparently in the education sector2.
While the phishing emails were quite common, the infrastructure used to deliver the credential stealing page struck us as unusually complex, with many redirections done between three different servers. So far, this behavior could not be related to any other known phishing kit. The infrastructure of this phishing platform has the propensity to use domain names beginning with a “Z” and ending in “is” or “ix” which sound like the Roman and Gaulish character’s names in the Asterix universe. We’ve thus named this phishing infrastructure “AZterix”.
AZterix combines three different layers of infrastructure
Emails we’ve analyzed such as the one in Figure 1 contain deceiving text and images, such as spoofing the target organization in the “From” field along with a fake AVAST “virus-free” notification.
Besides the social engineering content, the email displayed a link to a phishing URL disguised as an .xls document:
hxxps://60169490.zorventis[.]info/?44686900=[VICTIM_EMAIL]
The emails were sent by attacker-controlled servers linked to slightly “aged” domains. In this case, the email sending domain (mpoglobals[.]com) was registered in H1 2025, about 6 months before the phishing email was sent. On the other hand, the zorventis[.]info domain name used in the phishing link was instead registered only a few days before the phishing emails were sent.
If the victim clicked on the malicious link, the browser went through a series of calls, tests and redirections before the phishing server delivered the fake authentication page. These calls and redirections use an infrastructure composed of three layers which is the defining characteristic of the AZterix phishing platform, which we will analyze in further detail.
The 1st layer of the AZterix infrastructure performs some steps to avoid sandbox detection. When the user clicks on the malicious link, the browser follows a 302 server redirection to a page that performs a JavaScript challenge via the filepath “/challenge.php?t=[BASE64_VALUES]&r=[BASE64_VICTIM_EMAIL]”.
If this step fails an “Access denied” page is shown preventing some sandboxes and scrappers from uncovering the complete attack sequence. However, in some cases the OWN team noticed that the server answered with a benign page such as:
- an "under construction page",
- a simple blog page looking unfinished,
- or some code that causes the browser’s tab to crash.
If the test passes however, the server responds with another 302 redirection to a URL reaching out to the 2nd layer of the infrastructure. This layer delivers content through a second domain name using the following pattern:
hxxps://[VICTIM_DOMAIN].altavcence[.]com/[RANDOM_PATH]/[BASE64_FOR_?email=VICTIM_EMAIL]
The code delivered by the second layer performs the following actions:
- It creates an iframe to load more code from the same URL,
- It sets the title of the page randomly from a list of common names,
- It then uses window.History.pushState to reload the HMTL and sets the title of the page to a randomly generated path mimicking an IPFS URL (we assess that this step is probably performed to mask all future redirections),
- It tries to prevent some actions such as right-clicking or opening the debugger,
- It tries to trick the debugger into loading a blank page.
JavaScript code loaded in the iframe waits for 100 milliseconds before submitting a POST request to the same URL to which the server responds with, again, a 302 redirect to:
hxxps://[VICTIM_DOMAIN].altavcence[.]com/[RANDOM_PATH]/temp_@-8815e8481ab_[VICTIM_EMAIL]/index.php
The new location displays a spinner wheel and waits again for 100 milliseconds before redirecting the page to the 3rd layer of the infrastructure, this time by changing the window.location.href property to:
hxxps:// /[RANDOM_HOSTNAME].unsfudio[.]com/exvero.php?ip=[CLOUDFLARE_IPv4]&ua=Mozilla%2F5.0+%28Windows+NT+10.0%3B+Win64%3B+x64%3B+rv%3A146.0%29+Gecko%2F20100101+Firefox%2F146.0&email=[VICTIM_EMAIL] &token=[TOKEN]
The third layer of the AZterix platform uses a third domain name which may not displayed in the browser’s navigation bar because of the prior use of window.History.pushState method used in the previous layer.
The third layer then orders a series of redirections using either meta http-equiv='refresh' or 302 server redirections before loading content in nested iframes. One of these redirection passes the value “kasserver” to the “page” parameter:
/login.php?email==[VICTIM_EMAIL]&page=kasserver
This value is probably used by the phishing server to choose which login portal to deliver, as the landing page in this case imitated the Kasserver webmail service from German company All-Inkl.
Moreover, the credential landing page makes API calls to translate-pa.googleapis.com to display the content in the victim’s language.
This landing page contains a script that deciphers an AES-encrypted script.
This AES-encrypted script increments the number of attempts in a txt file available at “../report/count.txt“ and sends the stolen credentials to “../report/rp.php” using an XMLHttpRequest object. Once the credentials have been entered, the phishing attack ends with a final redirection to “../report/endpoint.html#[VICTIM_DOMAIN]”.
The phishing server most probably interacts immediately with the victim’s server to validate the credentials as the script awaits a response to either finish the phishing process or to ask the user to enter their password again.
So far, we do not know whether AZterix is capable of intercepting multiple authentication factors.
To synthesize, this phishing attack unravels in three steps, each step loading content from a distant server into an iframe. The first two layers are hidden behind Cloudflare while the third layer uses domains hosted on AS12586 managed by hosting provider GHOSTnet GmbH.
Tracking the AZterix infrastructure
It is possible to track domains used in the 1st layer using the challenge.php request with the specific ‘t’ and ‘r’ query fields. According to scans available on urlscan.io, the challenge.php test may have been first tested in August 2025. At this time, it was designed to send a POST request with several computed parameters to verify.php which would then respond with either an “Access denied” page or push further malicious HTML code depending on the result of the test.
It seems that domains are not specific to either the 1st or 2nd layer, rather they are used in both layers interchangeably. For instance, the altavcence[.]com domain used in the second layer in our example was also used to set up the challenge.php test a few weeks before.
When examining some of the domain names from the third layer on Internet scanning platforms such as ONYPHE, one can also notice that the servers answer some sort of characteristic default page on port 80 and 443:
It is thus quite easy to detect new infrastructure belonging to the AZterix platform by searching ONYPHE’s CTI Scan database for servers answering with either the same HTML title or the same content:
Looking at the results from the past 14 days we retrieved 26 IP addresses and 24 domain names. All IP addresses were routed by AS12586 managed by GHOSTnet GmbH and used for VPS hosting services. As already stated, these domain names have a feeling of character’s names that you could find in an Asterix comic album, for instance:
- zylorantis[.]info
- zumintra[.]info
- zornelix[.]info
- zalentris[.]info
- parvantis[.]info
- zumarix[.]info
- zentavix[.]info
- zoventrix[.]info
Contrary to domains used in the 1st/2nd layers, domains hosted through GHOSTnet seem to be used exclusively for the 3rd layer.
We also noticed that some of these IP addresses had PTR records for legitimate domains. Although no phishing emails sent from these IP addresses have been detected so far, OWN suspects these PTR records are set to spoof entities when sending phishing emails. On ONYPHE, one can filter IP addresses containing such PTR records by using the -exists:dns.reverse.hostname filter:
The following spoofed domains could be found in the past 14 days:
- mx2[.]svdepot[.]nl
- mail[.]euromilgame[.]com
- mx19-0056e903[.]pphosted[.]com
- mta6[.]e-mail[.]amtrak[.]com
- mail8a66241a[.]telepaie-app[.]com
- mta3[.]e[.]atlassian[.]com
- mail5f918711[.]de-magazine[.]de
- mail[.]poststelle[.]store
- messaging[.]xero[.]com
These spoofed entities could be used to send generic phishing emails.
A wider campaign
OWN uncovered dozens of domain names (around 150) that are part of this phishing infrastructure. These domains have mostly been registered throughout 2025, with an increase in domain registrations since September. As expected, these phishing campaigns exploit various social engineering themes such as the ones below:
- Authorization Requested for the New Payroll Policy
- Payment Plan Agreement for your Review
- Payment_Terms_Agreement
- Reminder: contract.pdf document awaiting review
- A file was sent to [VICTIM EMAIL] via WeTransfer
- [VICTIM EMAIL], a document has been shared with you
- You have a Voicemail
While most of the emails were spoofing business support teams such as “hr@VICTIM_DOMAIN”, “finance@VICTIM_DOMAIN” or “legal@VICTIM_DOMAIN”, some of them imitated often-used third-party services such as DocuSign or WeTransfer. Moreover, phishing content was found on forums and mailing lists such as the one below:
Other online services have been imitated as well, such as Office365, Outlook or a basic authentication screen:
Conclusion
The AZterix phishing platform seems to be a new phishing infrastructure that quietly evolved in 2025 and ramped up attacks during fall 2025. Of course, it may not have appeared in a vacuum and probably inherited code, functionalities and users from previously observed phishing platforms.
The pattern of performing many 302 redirections and loading HMTL and JS code in nested iframes piqued our curiosity, but it does remains easily detectable so far.
Detection
Attacks using the AZterix phishing platform can be detected and blocked by testing the following regular expression in the URL path field:
\/challenge.php\?t=[A-Za-z0-9]+&r=[A-Za-z0-9]+
New domain names and IP addresses used for credential theft and testing (3rd layer) can be detected with the following requests on ONYPHE:
category:ctiscan html.title.text:"S A M P L E PAGER"
category:ctiscan http.body.data.md5:"052816bd2fc247071f881488ee7e4a87"
IOCs
Footnote
[1] https://it.wisc.edu/news/phishing-alert-subject-salary-increase-notification - https://www.pcrisk.com/removal-guides/29784-salary-increase-email-scam
[2 ] https://security.utoronto.ca/phish-bowl/phish-notification-of-salary-increase
