CyberWire Daily - Bad building blocks: a new and unusual phishing campaign. [Research Saturday]

Episode Date: June 5, 2021

Guest Karl Sigler of Trustwave's SpiderLabs joins Dave Bittner to talk about their research: "Hidden Phishing at Free JavaScript Site". The research describes an interesting phishing campaign SpiderLabs encountered recently. In this campaign, the email subject pertains to a price revision, followed by some numbers. There is no email body, but there is an attachment about an ”investment.” The attachment’s convoluted filename contains characters the file-naming convention doesn’t allow, notably the vertical stroke, “|.” Even though "xlsx" is in the filename, double-clicking the attachment will prompt the user to open it with the default web browser. Thus, the file indeed appears to be an HTML document. Of course, it’s malicious. The research can be found here: HTML Lego: Hidden Phishing at Free JavaScript Site Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities,

solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. So one of the security research teams here at Trustwave Spider Labs focuses only on email security. And one of our researchers in the course of doing their regular research on phishing attacks discovered this one little phishing campaign that kind of stuck out as a little bit unique from what we usually see. That's Carl Sigler. He's the manager of the Spider Labs Threat Intelligence Group at Trustwave. The research we're discussing today is titled HTML Lego, Hidden Phishing at Free JavaScript Site. And now a message from our sponsor Zscaler, the leader in cloud security.

Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context,

simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. Well, let's walk through it together. I mean, you know, someone is, I don't know, sitting at home minding their own business, maybe at work, and they get a kind of odd email in their inbox. Describe to us what's coming through here.

So the email originally came to the victim's mailbox with the subject price revision. And then it had an attachment to it. And there was no body in the email itself. And we see this technique quite a bit where there's no body, but sort of an enticing subject line. This just sort of drums in curiosity and oftentimes gets a victim to actually try and figure out what the email is about. The subject price revision and the attachment, which seem to be an Excel spreadsheet, often is enough to, again, trigger that curiosity and get someone to open up the attachment itself. Yeah, I mean, it's interesting because price revision could be

good news or it could be bad news, right? Exactly. And if you're working for an organization where maybe you're involved with purchasing in some way, shape or form, perhaps you're in a department that recently just cut a PO for something, it can definitely get a lot of people to go ahead and open that attachment. Well, let's dig into some of the details here. I mean, there's more to this than meets the eye. Can you take us through the process that you all went through to kind of unpack this one? Sure. So the attachment itself had an Excel extension to it, the XLSX, but it was embedded in actually the file name. And we see this technique quite a bit as well, where basically the criminal is trying to trick the recipient, the victim, into thinking that the attachment itself is maybe something that they're used to opening up in an email, an Excel spreadsheet that maybe does have purchasing information or some file similar like that. In this case, although it had the Excel extension on it, the actual extension, if you look further down the file name itself, was HTML. So when you try to open the attachment, rather than opening up Excel, it's going to open up your web browser and display a web page to the actual victim. And what is in that web page that

displays? So the web page itself actually looks like you're looking at sort of a faded spreadsheet or a faded document in the background. And then it has a pop-up instantly that says, your session has ended. Please go ahead and log back in. And then it prompts you for a login for Office 365. And that login prompt has the Microsoft logo on it. They did everything they could to make the login prompt look as legitimate as possible. But the HTML page you're looking at is actually the attachment. And in the attachment is a bunch of JavaScript, which is triggering those pop-ups and triggering what we call a credential catcher. Now, am I correct here that the pop-up that looks like the Microsoft sign-in,

that that could have been pre-populated with the person's email address? Yeah, very, very tricky little trick. What the criminals did is they know the recipient of the email. They had their email address. So when they popped up the logon prompt, they actually embedded the email automatically into the user ID. So a lot of people, if they see their email address already typed into the user ID, it looks like maybe they had already saved their credentials. It looks more official to the actual victim and often will gain their trust enough to think, well, maybe my session did end.

I need to just type in my password since they already know my email address. since they already know my email address. Well, let's dig into that HTML file attachment itself because there's quite a bit going on here that you all explored in terms of obfuscation. Can we walk through it together? Absolutely. So it's a kind of unique technique. We see it in different forms and variants.

But basically what the attackers did was rather than embedding the JavaScript directly in the HTML file that was attached to the email, the JavaScript itself is hosted on another website called yourjavascript.com. And it's a valid website. It's a website that a lot of people use to basically keep their JavaScript if they need to reference it later in a page. Maybe they don't have hosting of their own, but they want to use it in some co-hosted website. There's a lot of valid reasons why people would want to store JavaScript on this little cloud site. But we're seeing criminals actually use that for malicious purposes. By storing their JavaScript on this cloud instance and not

having it in the HTML file, that gives the criminals, the attackers, a better chance of getting that email into somebody's inbox. Because all of the standard security controls that you might have on your mail server or the gateways on your perimeter leading to your mail server would inspect that HTML and not see anything malicious about it because all that malicious content was stored on yourjavascript.com and would not actually show until the victim opened up the attachment itself. Now, these files that are then opened, I mean, the stuff within the HTML file itself, are encoded. What was going on there? Yeah, so the JavaScript, another obfuscation technique,

another method to try and bypass security controls, the JavaScript was actually broken up into four individual parts. And then two parts were encoded differently from the other two parts. So the first two chunks of the JavaScript were URL encoded. This is just a typical encoding technique for HTML type content. And then the second two chunks were base64 encoded, which is another very common way of encoding data if you want to pass it through something that might not accept special characters

or something similar to that. So four parts in total, two that were URL encoded and two base64 encoded. And by doing this, again, they have a better chance of bypassing your protections since it's being brought down in chunks. Maybe your security controls can unencode the URL encoding automatically to look for malicious content, but then they might miss the base64 stuff. Or vice versa. Maybe your security controls, your email gateway, or whatever you might have can do base64 decoding to look for malicious content, but not the URL decoding. So by using two separate methods here, they have a better chance of just getting chunks in that are going to bypass those controls. methods here, they have a better chance of just getting chunks in that are going to bypass those controls. And your team there at Trustwave, you were able to dig in and I suppose

it didn't take too much effort to figure out what was going on behind the scenes there. You were able to decode these and then reassemble them in their proper order, right? Exactly. So the JavaScript was still up on the website. The attackers hadn't pulled down the code or the pages. So we were able to just recreate the email exactly as a victim's computer would automatically and bring down the chunks, analyze each individual chunk. And then in a safe environment, a sandbox-type environment, we could actually open it and see what it actually was trying to do. And in this

case, the JavaScript, its purpose was to fake a document in the background, prompt the user that their session has ended, and then prompt the user for just their password since the attacker's already had their email address. And when someone goes ahead and enters in their password, what happens next? Where does it go? So the password and the user ID automatically get posted and sent up to an attacker-controlled system. And then it redirects you to another website that looks like an Office 365 website, redirects you to another website that looks like an Office 365 website, but there's no real payoff there. And that in turn would redirect to another website, which has since been taken down by the attackers. So we're not able to see the actual, maybe the additional steps that the attackers are trying to get. The portion where the attackers cut off their trail was that credential capture part.

So as soon as you entered your email and your password, those credentials would automatically get sent up to the attacker, who could then log into your account, take over your account, reset your password for you, and see what sort of assets, what sort of data, what sort of useful information that they might be able to sell in the black market was available to that account. Do you have any notion, any insights on who might be behind this? No, it's hard to tell, especially with phishing campaigns, because phishers tend to throw such a wide net. This technique may only work 1%, 2% of the time. So they need to target thousands and thousands of email addresses in order to get a good return on the attack. So they need to target thousands and thousands of email addresses in order to get a good return on the attack. So with that sort of wide net, where it's not targeted

and focused on a specific organization, a specific industry, perhaps, it's a lot harder to not only figure out who the original attacker is, but to find out any sort of motivation behind just grabbing credentials, trying to get information, and possibly monetizing that down the line. We generally find that attribution in general, trying to figure out who the attacker is, while extremely important for law enforcement, for government agencies, for us and for our customers, the important takeaway here is to understand how the technique works and how to best protect your organization from those types of attackers. Knowing who they are doesn't necessarily play into those best practices and getting those best practices out

there is really our main goal. Well, I mean, let's go there then. I mean, what are your recommendations in terms of folks best protecting themselves against this sort of thing? You know, it's the same thing we've been preaching for quite some time. If you receive an email that has either an attachment or a link that you're not expecting, is not coming from somebody that said they're going to be sending you this file or they're going to be sending you a link to check, that should raise some red flags for you. Don't automatically open the attachment. Don't click on the link until you figure out why it's in your inbox from the get-go, even if it's coming from someone you trust. Perhaps the person that it's coming from has been breached and is being used to try and gain more trust and to get you to

further that breach. So if you receive anything in your inbox with a link or an attachment, don't automatically open it. Maybe verify out a ban via a separate email, a text message, or a phone call to the sender to make sure that they actually did send it and meant to send it to you. And if it's coming from someone you don't know or don't trust, you may want to get your local IT team or your security team or your organization involved with that. In the spectrum of these sorts of things that you all see, the phishing attempts that you all are tracking, where does this fit in in terms of the level of sophistication that we're seeing here? I would say it's sort of medium severity. here? I would say it's sort of medium severity. Generally, we start to see a lot more sophisticated techniques being used in the targeted attacks. So if somebody is targeting somebody with the

C-level email campaigns where they're trying to exploit the CFO of a company or CEO of a company, and there's a lot of reconnaissance involved and a lot of maybe precursor emails that get sent out, a test campaign. Those tend to have a lot of sophistication and use a lot of very sophisticated techniques. Then you have the low-level techniques that are pretty much just script kiddies that may be just playing around, testing these things out, maybe are not that experienced. This seems to be more mid-level. The fact that they're breaking up their code

into small little chunks to avoid detection, the fact that they're putting that code on a cloud server rather than embedding it directly in the email, all of those things do show a level of sophistication and a good bit of technique involved. So this definitely isn't the actors behind the campaign. This isn't their first time. This isn't their first rodeo. But so far as very sophisticated, this wouldn't be that hard for somebody to figure out or somebody to replicate. Just from reading our article, the technical details, you don't necessarily have to

be that technical to understand how these techniques work and how to use them. If you know some basic HTML, some basic JavaScript, it could be very, very easy to pull off this attack if you had that motivation. We want to make sure that people understand the sophistication behind a lot of these email attacks, these phishing attacks, so that people are better able to protect themselves. When it comes down to attacks that utilize social engineering and targets the psychology of the victim, education is really the only patch we have for that sort of thing. So by putting out these articles and giving an explanation of how these campaigns work, we're hoping to educate people so that when these emails end up in their inbox, they don't do the wrong thing. Our thanks to Carl Sigler from Trustwave for joining us.

The research is titled HTML Lego, Hidden Phishing at Free JavaScript Site. We'll have a link in the show notes. Cyber threats are evolving every second, and staying ahead is more than just a challenge. It's a necessity. That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely.

Visit ThreatLocker.com today to see how a default-deny approach can keep your company safe and securely. Visit ThreatLocker.com today to see how a default deny approach can keep your company safe and compliant. The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliot Peltzman, Puru Prakash, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Folecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Ivan, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening.