Web injections are back on the rise: 40+ banks affected by new malware campaign

[Caute_cautim]

Hi All

Watch out for this one over the festive season:

Our analysis indicates that in this new campaign, threat actors’ intention with the web injection module is likely to compromise popular banking applications and, once the malware is installed, intercept the users’ credentials in order to then access and likely monetize their banking information.

Our data shows that threat actors purchased malicious domains in December 2022 and began executing their campaigns shortly after. Since early 2023, we’ve seen multiple sessions communicating with those domains, which remain active as of this blog’s publication.

Upon examining the injection, we discovered that the JS script is targeting a specific page structure common across multiple banks. When the requested resource contains a certain keyword and a login button with a specific ID is present, new malicious content is injected.

Credential theft is executed by adding event listeners to this button, with an option to steal a one-time password (OTP) token with it.

https://securityintelligence.com/posts/web-injections-back-on-rise-banks-affected-danabot-malware/

Regards

Caute_Cautim

[Early_Adopter]

Plus ca Change!

This is a pretty complete attack to de-monetise you over the festive period complete with OTP snaffle - beware!

[ericgeater]

"threat actors’ intention with the web injection module is likely to compromise popular banking applications"

This is why I won't use apps for banking.  There's not a value proposition substantial enough to accept this risk.

[Early_Adopter]

That’s a good strategy if viable.

I think however in some countries it’s a difficult proposition - Singapore banking for instance is completely driven by applications, and it would be maybe not impossible, but extremely difficult to avoid using them.

Lots of work goes into security, but yeah no system is perfect, so there is a lot of attack/scam awareness training.

[JoePete]

@Caute_cautim, as always thank you for curating these stories. This one seems a bit scary.

I'm a little lost on the details of how the script tag gets injected. They reference a man-in-the-middle, but assuming the entire app is run under HTTPS, that would be rather tricky (unless the application is mixing HTTP and HTTPS, which is sloppy to the point of negligence for a bank). I guess this could be done with cross site scripting, but what banking app has third-parties posting data to it somehow? Again, if in the interest of content management or "social media" a bank allows this, it is sloppy to the point of negligence. The real issue seems in the design/architecture stage and not in the code.

Frankly, I think the risk and annoyances contained in browser-side scripting outweigh any possible benefit. I'd say this is another nail in the coffin of JavaScript, but JS is like the zombie apocalypse. It just keeps rising and growing.

[Caute_cautim]

@JoePeteThis is a well organised and deployed attack, by owning malicious domain since 2022, and injecting the malicious script when their victims arrive at their web sites. 

Yes, no matter how good your OWASP security controls, JS appears to be at the brunt of it.

Regards

Caute_Cautim

[Early_Adopter]

Yes, as CC points out it’s running on the client.

Singapore banks started banning their apps from android devices with side loads etc earlier this year:

https://www.channelnewsasia.com/singapore/dbs-uob-anti-scam-sideloaded-app-malware-measure-latest-ba...

[JoePete]

---

@Caute_cautim wrote:

This is a well organised and deployed attack, by owning malicious domain since 2022, and injecting the malicious script when their victims arrive at their web sites. 

---

From what I gathered in the story, the malicious domains host the malicious JS. When users visit their banking sites (legit domain/site), a script tag, using a src of the malicious scripts on the malicious domains "gets injected" in the HTML that gets sent back to users' browsers. Perhaps I didn't read correctly, but the story didn't seem to offer much detail on the injection. They reference a man in the middle, but that shouldn't be possible with HTTPS (correct?), and a cross-site issue would only happen if they are allowing third-party content (unfiltered comment positing, content/ad management, iframes), but again I wonder if I am missing something. 

[ericgeater]

@JoePete when you said, "but what banking app has third-parties posting data to it", I keep thinking about websites like Plaid.  I stand by my decision to live without banking apps, but at least once I was highly uncomfortable with a requirement to insert my banking password into Plaid.

I changed my password immediately once I'd completed what was required by Plaid, anyway.

I don't know if it helps, but it's the best example I can think of when it comes to third-party access to my banking.