CyberWire Daily - Scam papers served. [Research Saturday]

Episode Date: May 16, 2026

⁠⁠⁠Thomas Elkins⁠⁠⁠, SOC L3 Analyst from ⁠⁠⁠BlueVoyant⁠⁠⁠, is discussing "Unpacking Augmented Marauder’s Multi-Pronged Casbaneiro Campaigns." BlueVoyant researchers uncovered a large-scale phishing campaign by a Brazil-linked threat group targeting Spanish-speaking users across Latin America and Europe, using fake judicial summons emails, WhatsApp attacks, ClickFix tactics, and email phishing to spread the Casbaneiro banking trojan through the Horabot malware framework. The campaign uses sophisticated evasion methods including password-protected PDFs, dynamically generated ZIP filenames, anti-sandbox checks, fileless execution, and customized phishing lures to bypass security tools while turning infected systems into self-propagating botnets that hijack Outlook and webmail accounts to spread further attacks. Researchers say the operation highlights how the Augmented Marauder group (also known as Water Saci) is rapidly evolving its malware ecosystem, combining WhatsApp automation, dynamic phishing infrastructure, and advanced banking malware delivery into a highly adaptable, multi-pronged cybercrime operation. The research and executive brief can be found here: ⁠Unpacking Augmented Marauder’s Multi-Pronged Casbaneiro Campaigns⁠ Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. Maybe that's an urgent message from your CEO, or maybe it's a deep fake trying to target your business. Dopple is the AI-native social engineering defense platform fighting back against impersonation and manipulation. As attackers use AI to make their tactics more sophisticated, Dopple uses it to fight back. from automatically dismantling cross-channel attacks to building team resilience and more.

Doppel, outpacing what's next in social engineering. Learn more at doppel.com. That's D-O-P-P-E-L.com. I would definitely just make sure that we teach the end users. You know, we have to ensure that we keep them up to date on such attacks because I think it's so easy when you're in a rush to just kind of looking at these things saying, oh, shoot, I'm some of the core. I got to verify this, you know.

And it's kind of scary because that's the scare tactic behind this all is, how can I get the users to kind of panic and just interact with these things? And I think we as security researchers and analysts have to just say, what is our best way to trying to train the end users to not all of a sudden be panicked? That's Thomas Elkins, a SOC-L-3 analyst from Blue Voyant. The research we're discussing today is titled Unpacking Augments. Marauders' multi-pronged Caspiñero campaigns. Here at Blue Point, we have a lot of clients that we ingest their data for on their security

side of things. So we will see any kind of potential incidents that come in from our clients. And one of the incidents that we observed was a fishing email that just was pretty plain in regards to the content of it, where it was in Spanish indicating that they were. It was in Spanish indicating that the user had to click on a link contained within a PDF file to confirm their, I guess, their appointment to the, how would you say, judiciary system within Spain. And it was to entice them to, you know, obviously confirm that they're going to be showing up because they were summoned to court. And from there, it's where we saw the user download a zip archive. and they executed the contents of the ZiparCive, which was an HTA file.

And honestly, that's where the attack ended from their standpoint. But we as researchers obviously want to get the full scope of what's going to happen. So I took it to the next level and started to investigate what happens if the H.T. file succeeds. And that's where I started seeing a whole bunch of VBA coding being launched on my own personal machine, which is when I started investigating the network traffic contained within the requests. And that's when I saw the back end of their servers providing a whole bunch of different VPA scripts that would be executed on the client side. And that's basically how we observed the attack was beginning from that aspect.

Well, let's jump into some of the reasons that this campaign is particularly notable. In the research, you describe this as a multi-prong. campaign. What did you uncover that that signaled this activity was broader than some of the things you've been tracking before? Originally, when we tracked it, we thought this might have been potentially just hitting Spain. But as we dug more into the IOCs, we observed other companies had also seen that this was not just attacking Spain. It was targeting multiple countries in Latin America, including Brazil and Mexico. So we were, we were a like, okay, well, this is clearly not just going to be contained to one specific country,

that they're clearly targeting Spanish-based users, Spanish-speaking users. So, and this is not something that, it has been done before. This is not like a novel aspect in terms of targeting Spanish users. What made it novel was the techniques they were using to automate their attack for them, essentially. Well, let's dig into that aspect of it. What were some of these things that really caught your eye? Yeah.

So what we saw when I was going through the payloads was how it was, what's the word? I'm trying to think of right now. It would basically find a way to replicate itself without requiring the attacker to have to keep sending the same fishing email. And what that means is one of the Casper narrow bank and Trojan specifically, when it contacted its C2, it contains the ability to execute commands contained from the C2. So if the C2 responds with a PowerShell script, the banking Trojan will be able to execute that PowerShell script in memory. And when we analyze the PowerShell scripts,

one of them was this self-replication where it would basically get a hold of the user's email Outlook account, and it was using that by using PowerShell objects and then once it got the contact list from their emails, it would craft a new email, and the email that was crafted at one of its own controlled infrastructure from the attacker,

and that email would essentially replicate the same process that we saw initially. And one of the issues that we have as researchers is how do we figure out where the source of this actually began, because what we're seeing right now is most likely the user that was impacted initially was probably, you know, they probably received a phishing email from someone that actually trusted that was in their own contact list, which was also impacted by this campaign. And that's one of the novel things that we saw was, okay, well, this is not just a typical fishing campaign.

This is a self-autonomous campaign where it's just going to keep spreading and finding the original source is going to be almost impossible at this point. Yeah. One of the things that caught my eye was the fact that that fishing attachment in the, I guess, the initial email was password protected. How does that help the attackers bypass defenses? Yeah, so a lot of times when you get password protected archives, even with simple passwords like 1, 2, 3, 4, the email scanning features, they can't bypass the zip archive passwords because they don't, I don't, I don't, I don't, I don't, I don't, I don't, I can't speak for sure, but I'm pretty sure that a lot of these email-based programs, they can't brute force the archives because I feel like that would probably be against the users. Right.

Against the user's will. So a lot of times these emails, they can't scan the PDF, they can't scan the archives or they can't scan what the contents of the PDF is because the password protected. And without being on the view of that, the contents will stay encrypted until the user enters the password. and then all of a sudden the contents are now decrypted and essentially after that, then it can do that. So allowing that password protected email, it's going to bypass a lot of security scanning features from email from email accounts or email providers,

should I say, email accounts. I see. Well, you've mentioned some of these items, but I think it would be helpful for our listeners to kind of walk through the infection chain step by step and the technical execution here. So once the victim interacts with the attachment, what happens next?

So the user, after they supply the password, the PDF populates the contents. And the contents is that court summons notification. And when there's a link saying confirm your appointment, it's in Spanish. And once they click that link, their browser opens up a new tab. And there's like a random message,

which is weird. I saw the message. I, fortunately I don't have a screenshot of it. But it's like a rainbowed message saying like waiting, something like about waiting. And then also a Zip Archive is shown at the top right where you get that little downloads notification on your browser. And the Zip Archive itself is very autonomous.

It has like some kind of UID automation from the back end of the servers, of their servers. And it provides the date as well. to kind of give this illusion of, okay, well, this might be some kind of official attachment or something that's required to help confirm my, you know, my appearance at the court. So contained within the Zip Archive is a HTA file,

and that contains a script that tells whatever Windows binaries associated, MSHT in this regard, will execute that script tag and the contents contained within that script tag. And that's when I was using my own programming on the back end. I was using Man in the Middle Proxy to capture the response of the server once MSHTA executes that script. And what we saw was three different VBA scripts being executed. The first one was to execute another one.

So it was an interesting chain of events where you don't start seeing the actual, I guess what they're actually want to do until you probably get to the third script specifically. And then that's when we start seeing a whole bunch of officiated code contained within the VBA script. And this is purposely to hinder

immediate execution and memory. So that way, if you have some EDR tool in the background trying to scan any open processes and if it catches MSHTA running and scans to see what the contents are, it won't see it right away because all that content is already

obfuscated. And each of their primary scripts contained a custom decoding routine for their strings. So that way, if you're a security researcher and you happen to pull their script off their server, you're not going to be able to reverse it right away because a lot of their content is obfuscated behind their custom decoding routines to make it harder for you to analyze it as a researcher and for EDR tools to immediately flag what is going on in the background. But once we started decoding these strings, that's when we really started to see

the nature of the scripts. And the first part of the script is to determine if it's running in a sandbox. And this is pretty typical of a lot of malware nowadays. They want to identify if they're running in the sandbox, see if they can just stop running in case they detect it. It's in the sandbox. And then once it determines that,

it has a pre-configured list of known sandbox names, usernames and sandboxes. And I think that's something that they probably pull off of GitHub, a whole bunch of different resources, just kind of giving an idea of what are the most basic known sandbox names and their device names. And once those checks pass,

then that's when it starts to identify if there's any running processes that are associated to this already running campaign. So it's going to check to see if MSGA is already running. It's going to check a specific folder path within C users public. with a random laptop dash. I don't remember the full name of the path, but that's their default path for their infection.

So it's checking to see if that folder path already exists. And if it does, again, the chain will break, and then they cancel the attack. And then if all those checks pass. Exactly, exactly. So they want to make sure this is a fresh situation. And if all those checks pass, then that's when it begins to down.

download its actual payloads. And again, what caught our attention. And this seems to be very typical of Latin American-based kind of malware is the usage of Auto-It scripts. Not saying that's always going to be Latin American, but for a reason, a lot of these attacks seem to be using Auto-It to kind of protect the contents of their actual payloads. What happens is it drops a whole bunch of Auto-It-based binaries. So you have the compiler and you have the actual Auto-It executable,

as well as their decompiled Auto-It scripts, which is also interesting. I actually haven't seen that before. I haven't seen them dropping an actual compiler on the back end because usually the script is already compiled. So that makes it easier for us as researchers because now we don't have to use additional tooling to decompile their scripts. They already gave us the raw script, which was very nice of them to do, honestly.

So we were able to analyze those autoids scripts without having to, like I said, decompile them ourselves. And that's when we realized that they're using and containing the scripts are their actual raw payloads that they want executed in memory. And that's another thing they can do too.

Instead of storing their encrypted scripts on the actual machine, they can execute in memory, which makes it harder for a lot of EDR hooking tools to be able to figure out what's happening in memory as well. And once, yeah, exactly, yeah. We'll be right back.

Most environments trust far more than they should, and attackers know it. Threat Locker solves that by enforcing default deny at the point of execution. With Threat Locker Allow listing, you stop unknown executables cold. With ring fencing, you control how trusted applications behave. And with Threat Locker, DAC, defense against configurations, you get real assurance that environment is free of misconfigurations and clear visibility into whether you meet compliance standards. Threat Locker is the simplest way to enforce zero-trust principles without the operational pain. It's powerful protection that gives CSO's real visibility, real control, and real peace of mind.

Threat Locker make zero-trust attainable, even for small security teams. See why thousands of organizations choose Threat Locker to minimize alert fatigue, stop ransomware at the source, and regain control over their environments. Schedule your demo at Threatlocker.com slash N2K today. When it comes to mobile application security, good enough is a risk. A recent survey shows that 72% of organizations reported at least one mobile application security incident last year, and 92% of responders reported threat levels have increased in the past two years.

Guard Square delivers. the highest level of security for your mobile apps without compromising performance, time to market, or user experience. Discover how Guard Square provides industry-leading security for your Android and iOS apps at www.gardsquare.com. The campaign deploys a pair of banking Trojans, right? You've got Horibot and Caspenero. How do these two components divide up the responsibilities during the intrusion? Yeah, definitely. So the Casper narrow one, the primary focus is to not only, obviously, see if a user is accessing their banking account and trying to create a splash screen that's fake and having the user input their information, which is your typical banking Trojan behavior. This also contains additional abilities that the attacker has created from their back end of the servers that they set up, where the Casper narrow, like I said, is not.

not only a Trojan in the sense that it can capture your input about trying to access banks, it has the ability to execute malicious code given if that's what the threat actor wanted to set up to begin with. So on the back end, the servers that they set up contain additional encrypted code that the banking Trojan would decode and then execute that content using Shell Execute ExW, which is one of the APIs that the Caspanero-Trojan has. What that allows it to do is if the attacker says, okay, I want you to download another payload from my remote server, the banking trojan can do that. And what it seems like the attackers want in this situation

is they wanted to create persistence with the banking Trojan. Additionally, they wanted to do the self-propagation aspect, which is what I discussed earlier, where they want to take control, not to control the user's email, but basically infiltrate their email, sent out a whole bunch of new wave phishing emails from the impacted user and that creates that trust element

when the impacted user sends the fake emails out to their own contact lists, those users are more likely to say oh, this must be legitimate, you know, because this is a user that I know this is not just some anonymous user from hotmail.com, you know, so that's the Caspanero aspect of this tech chain. The other one,

the horror bot, the horror bot is the other, I guess, it's like I said, it's two problems where they want to basically gain control of the user's email account

specifically. And what it does is it sits in the background and waits to see if the user navigates to Gmail, hotmail, or what's the other one, live account,

I believe. It's Gmail, Yahoo, and live. And it's, it sits to wait to see if the user accesses those. And if it does, the user is redirected to input their password. And what happens is the horror bot will get, it'll capture the keystrokes of the users.

They type in their password. And then now the threat actor has access to that user's whatever email account they were using in that specific instance. And again, that allows them to gain direct access to that user's email. and impose as that user and most likely craft additional emails, maybe in the future, maybe they don't do it right away,

maybe this will be part of another campaign they set up in the future too where they can access those legitimate users' email accounts to spread additional campaigns. I see. Another one of the interesting aspects here is, help me if I have this right,

that during the propagation of the phishing PDFs, The PDFs themselves are dynamically generated? Exactly. They come from remote server. So basically, the attacker can just change the format of what are the PDFs going to be. So if their campaign is going to change from court summons, they might change it to something else, maybe like a DHL package or something else to entice users to want to interact with it. So they can dynamically change whatever email, whatever the PDF document is supposed to contain.

they can dynamically change that. And the passwords too are also dynamically changing. Not always going to the same. The script functionality contains the logic to basically craft a randomly generated password, and that password is sent to the server. So when it generates the PDF files, that password will be used as that new wave of PDFs being sent out to users. I see. Now, your research connects this campaign to Maverick Malware Operations,

which had previously been documented in some WhatsApp automation attacks. What was the overlap here that helped you establish that connection? That was something I was going to bring up to. So I think it's back in October or September, we observed a campaign that was hitting multiple users specifically in Brazil.

And this Trojan was being self-propagated as you alluded to via WhatsApp. And it contains a similar attack situation where not only did it deploy the Maverick banking Trojan, the second binary was the self-propagation aspect. And that's when we realized that this is probably linked because not many, I mean, I haven't seen many other threat actors using the self-propagation aspect. And then that's when we started seeing other security companies confirming that that was the same exact behavior that we're observing from this new attack

that it was linked to the previous one from Maverick. And it kind of makes sense where you see these threat actors, they like to evolve where they try one thing if it doesn't work out. They'll try another thing. And I feel like that's the same thing we saw with this specific attack was back in September, we saw the initial wave

of WhatsApp and the automation of how to send that to multiple users without relying on the threat actor to have to keep creating new methods to get users to interact. with WhatsApp, why not just automate that process? And we see that again with this specific campaign, where they do a similar thing, where they get a hold of the user's emails through the Power Show objects in order to automate that

process as well, because it saves them time, but they don't have to keep doing it themselves. It can allow the users to keep spreading it. I see. How do you rate the sophistication of this particular threat actor? I would definitely say they're getting more and more sophisticated. it. I feel like, so I first saw this, like, not this specific campaign, but I've seen this threat actor before, and I think we linked him to something called Coyote as well in our previous research. We released something about Maverick 2 in September. And another, the author that helped me write this, Josh Green, he works on the threat intel piece of things. And he was able to link this to another malware strand called Coyote, which was another dot net based banking trojan. And initially, when I first saw this type of behavior from this threat actor, it was, like, year and they were targeting Mexican users by pretending to be SAT tax documents. And I would definitely say, seeing from that then, then it was just like, here's a zip archive and an email,

tried to execute the content. It's a password protected zip archive, you know, voila. There was no self-propagation aspect. Fast forward to September, we see them using WhatsApp for propagation. And now we move forward to not only that, we see them using, emails for self-propagation. And I feel like they keep ramping up how do we find ways to automate this process for us

so we don't have to put as much effort into it. Yeah. Well, given the information that you all have gathered here, what are your recommendations for the defenders out there who have to protect themselves from these sorts of things? I would definitely just make sure that we teach the end users. You know, we had to ensure that we keep them up to date on such attacks because I think it's so easy when you're in a rush to just kind of looking at these things saying,

oh, shoot, I'm some of the court. I got to verify this, you know. And it's kind of scary because that's the scare tactic behind this all is how can I get the users to kind of panic and just interact with these things? And I think we as security researchers and analysts have to just say, what is our best way to trying to train the end users to not all of a sudden be panicked? Like we had to step them through and say, okay, let's slow down. When you get something like this, let's analyze what is the goal here from the third actor's standpoint? What are they trying to do? And let's not rely on the motion.

Let's fly on logic as well. And I think in terms of how do we stop this going forward too, like if the user does interact with it, what protections can we put in place to ensure that this doesn't continue? Can we block MSHTA from executing remote code? Can we just have a blockage policy in place? on Defender, on Sentinel One, whatever EDR tooling you're using, to ensure that, okay, say the user does download the archive, they try to execute the HTA script,

let's ensure that MSHTA does not execute the contents. And same thing with just understanding scripts in general, like, can we change the default behavior of how scripts are interacted with on the end users part two? Can I just try to execute notepad instead? These are some things you can change from the back end of, you know, group policies and whatnot. Our thanks to Thomas Elkins from Blue Voyant for joining us. The research is titled Unpacking Augmented Marauders Multi-pronged Caspinero campaigns.

We'll have a link in the show notes. And that's Research Saturday, brought to you by N2K Cyberwire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app.

This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher, and I'm Dave Bittner. Thanks for listening. We'll see you back here next time.