Most phishing analysis assumes a link either leads to something bad or it does not, and that whoever tests it will see the same thing an intended victim sees. Research the SANS Internet Storm Center published on September 1 describes a campaign built to break that assumption on purpose. A Brazilian Portuguese email led a lab researcher to a link that answered a question before it answered the request: is this visitor actually in Brazil, and are they actually running a browser and operating system set to Brazilian Portuguese. Get both answers right, and the link handed over a banking trojan. Get either one wrong, and it handed over a legitimate Android Studio installer instead.
A Link That Decides What You Deserve to See
The malware family involved, known as Guildma or Astaroth, has targeted Brazilian users with banking-credential theft for years, and this campaign shows why it keeps working. The malicious behavior is not encoded anywhere in the email itself, and it is not a fixed property of the link either. It is a live decision the attacker’s server makes for each individual visitor, based on the requesting IP address’s geolocation and the language and regional settings the browser reports. A researcher, a sandbox, or a security tool checking that link from outside Brazil, or from a machine set to English or Spanish, gets served the real Android Studio installer: functional, harmless, and a convincing reason to conclude the link is clean. Only a visitor who is both physically in Brazil and configured for Brazilian Portuguese ever sees the actual payload.
From a Shortcut File to a Hidden Data Stream
For the visitors who pass both checks, the link delivers a ZIP archive containing a Windows shortcut file. Running it reaches back out to a web server and saves what comes back into an NTFS Alternate Data Stream, a way of attaching extra data to a file that most file listings and casual inspection never show. That hidden stream holds a 64-bit DLL, which in turn retrieves and installs an AutoIt package that runs the Guildma malware itself. Every step after the initial click is built the same way the geofencing check is: designed so that a defender who does not reproduce the exact conditions of a real Brazilian victim never sees what actually happens.
Why DMARC Was Never Built to Catch This
DMARC evaluates one message at delivery time: did the domain in the From header authorize the infrastructure that sent it. It has no mechanism for evaluating what a URL inside that message does when someone clicks it, and even less for a URL whose behavior changes based on who is clicking and from where. A domain can be perfectly authenticated, with SPF, DKIM, and DMARC all passing cleanly, and still be the delivery vehicle for a link that behaves like malware for one visitor and like a software download page for the next hundred. The geofencing and locale check in this campaign are not aimed at DMARC specifically. They are aimed at every automated and manual verification step that happens after a message clears authentication, which is precisely the territory DMARC hands off to someone else the moment a message reaches the inbox.
What This Means for Your Program
Do not treat one clean test click as proof a link is safe. A link tested from your security operations center, likely outside Brazil and set to English, can look completely benign while still being live and malicious for the population it actually targets.
Match your testing conditions to the threat you are investigating. When a suspicious message is written in a specific language for a specific region, validating its links from a matching IP address and locale is the only way to see what a real recipient would see.
Treat regionally targeted banking trojans as a standing risk wherever your organization has Brazilian operations or Portuguese-speaking staff, regardless of where your mail security stack is centrally managed.
Make sure your endpoint tooling actually inspects Alternate Data Streams, not just a file’s primary content, since this campaign relies on that gap to hide its payload in plain sight.
The Takeaway
This campaign’s cleverest move was not the banking trojan at the end of the chain. It was building a link that shows almost every checker, researcher, and automated scanner exactly what they expect to see, and reserves the real attack for the one population it was built to reach. DMARC authenticated whatever domain sent the original email and then had nothing further to say, because everything that mattered happened in a server-side decision no authentication protocol was ever designed to evaluate.
DMARC confirms a domain had the authority to send a message. It cannot tell you that the link inside that message behaves differently depending on who clicks it and from where, showing a security researcher a harmless installer while showing an intended victim a banking trojan. Excello Mail turns your DMARC aggregate reports into a clear, continuous record of every domain and service sending as you, so the authentication layer stays airtight while your team investigates what a link actually does for the audience it was built to deceive. Sign up for free to Excello Mail and get that foundation in place.