I made this page to track current fake browser updates campaigns:
I made this page to track current fake browser updates campaigns:
@GustyDusty Agreed, if earlier in the infection chain I pass it characteristics of a non-domain joined device, I end up with a different payload.
They must do some sort of checking once the beacon is in place though, because I can't get the Cobalt Strike beacon to drop. I imagine my IP or other characteristics are not convincing enough.
newest #solarmarker infostealer malware:
#SEOPoisoning -> Fake Sites -> download via diggiski[.]com
If you are interested in steganography and browser fingerprinting, I wrote a follow up blog on a scam campaign that I've tracked for several years.
Reproducing & capturing this attack chain is quite difficult because of the number of checks performed. No doubt it contributes to why this scheme is working so well.
https://www.malwarebytes.com/blog/threat-intelligence/2023/08/wooflocker2
Great writeup. I had recently been stumped by exactly the scenario you've outlined.
If you track #malvertising campaigns, you may need to adjust your environment to account for more advanced fingerprinting techniques.
More details in this blog: https://www.malwarebytes.com/blog/threat-intelligence/2023/08/malvertisers-up-the-game-against-researchers
New #SocGholish C2:
hXXps://bvpix.photo.beyoudcor[.]com/editContent
bvpix.photo.beyoudcor[.]com
185[.]225.70.190
Added #EKFiddle rules to detect Google DNS injections used in tech support scam redirects.
Based on this Sucuri blog: https://blog.sucuri.net/2023/08/from-google-dns-to-tech-support-scam-sites-unmasking-the-malware-trail.html
Bad actors are elevating their malware campaigns by leveraging the DNS protocol to hide requests to their infrastructure. Learn how hackers are injecting malicious JavaScript to send requests to Google DNS, then using the responses to redirect users to tech support scams and adult websites.