Blog

Archive for September 7th, 2021

"Stolen Images Evidence" Campaign Continues Pushing BazarLoader Malware, (Wed, Sep 8th)

Introduction

Another day, another wave of malware.  Although there’s plenty to find, I’ve been focusing on BazarLoader as it comes through various distribution channels.  One such channel is the “Stolen Images Evidence” campaign, which Microsoft describes here.  This campaign was pushing IcedID as we entered 2021, but it switched to BazarLoader as early as July 2021.

The “Stolen Images Evidence” campaign uses emails generated through contact forms on various websites.  So these messages don’t originate through normal spam methods.  They appear through contact form submissions describing a copyright violation to the intended victim.  These form-submitted messages include a Google firebase storage URL in the message text.  This malicious link supposedly provides proof of stolen images that resulted in a copyright violation.

However, Google’s service is being abused in this case, and the zip archive named Stolen Images Evidence.zip contains a JavaScript file designed to infect a vulnerable Windows host with BazarLoader.


Shown above:  Lnk from a copyright violation-themed form submission-generated email.

Downloaded zip archives

The downloaded zip archives are always named Stolen Images Evidence.zip.  They contain a JavaScript file named Stolen Images Evidence.js.


Shown above:  Example of a downloaded zip archive and extracted .js file.

BazarLoader from the JS file

If a victim double-clicks the extracted JavaScript file on a vulnerable Windows host, it retrieves and runs a DLL for BazarLoader malware.  The DLL is saved to the infected user’s AppDataLocalTemp directory with a .dat file extension.


Shown above:  BazarLoader DLL stored to an infected Windows host.

Infection traffic

Infection traffic is typical for what we normally see with BazarLoader.


Shown above:  Traffic from an infection filtered in Wireshark.

Indicators of Compromise (IOCs)

The following is malware retrieved from an infected Windows host.

SHA256 hash: c1cc9ec32368165e6625b2e2623ac0c3ca69bfa63a5b11e82a09bf18f6bd6410

  • File size: 4,763 bytes
  • File name: Stolen Images Evidence.zip
  • File description: zip archive downloaded after clicking Google Firebase Storage link

SHA256 hash: 5a22e9bde5aaed03b323e5c933c473e9ba3831f4473790a3d4394baefe809d8a

  • File size: 15,755 bytes
  • File name: Stolen Images Evidence.js
  • File description: JS file extracted from the above zip archive

SHA256 hash: dcf67fd6bfb62bea66f5e45d871d6c15b0c61d85c5fa9e9ded03e57f83dfc814

  • File size: 203,281 bytes
  • File location: hxxp://mabiorex[.]space/333g100/main.php
  • File location: C:Users[username]AppDataLocalTempmotHf.dat
  • File description: BazarLoader DLL retreived by the above JS file
  • Run method: rundll32.exe [filename],StartW

Google Firebase URL used to deliver the malicious zip archive:

  • hxxps://firebasestorage.googleapis[.]com/v0/b/app9-96feb.appspot.com/o/d-03rfdsbknu.html?alt=media&token=f7fc9a25-71b6-424d-aaf7-208fb11c27dd&f=025239220255728020

Malicious domain called when using the above Google Firebase URL:

  • 172.67.145[.]134 port 443 – zvanij[.]space – HTTPS traffic

Traffic generated by the extracted JavaScript file to retrieve BazarLoader DLL:

  • 104.21.10.6 port 80 – mabiorex[.]space – GET /333g100/index.php
  • 104.21.10.6 port 80 – mabiorex[.]space – GET /333g100/main.php

Bazar C2 traffic:

  • hxxps://194.15.113[.]160/workdir/tasks/run/handle
  • hxxps://198.244.180[.]69/workdir/tasks/run/handle
  • hxxps://89.41.182[.]134/workdir/tasks/run/handle
  • hxxps://172.83.155[.]144/workdir/tasks/run/handle

Final words

The associated malware samples have been submitted to bazaar.abuse.ch, and they’re available using links from the above SHA256 hashes.

This campaign uses “Stolen Images Evidence” and copyright violation as its primary theme.  However, it also used a “DDoS attack proof” theme last month.  Either way, this campaign has been fairly active in 2021, and we expect it to continue throughout the rest of this year.  It will probably continue into 2022 as well.

Brad Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Microsoft Offers Workaround for 0-Day Office Vulnerability (CVE-2021-40444), (Wed, Sep 8th)

Microsoft today published an advisory with a workaround to mitigate an unpatched vulnerability in Microsoft Office. This vulnerability is currently used in targeted attacks.

CVE-2021-40444 is a code execution vulnerability in MSHTML. The exploit would arrive as an Office document that includes a malicious ActiveX control. As a workaround, Microsoft recommends disabling ActiveX in Internet Explorer and the advisory includes the necessary registry changes. At this point, it should be pretty low impact to disable ActiveX, but of course, there may be individual enterprise applications that still use ActiveX. 

For more details, see Microsoft’s advisory here: 

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Why I Gave Up on IPv6. And no, it is not because of security issues., (Tue, Sep 7th)

IPv6 adoption is growing. Around 30% of the Alexa Top 1000 websites support IPv6. Comcast, the ISP I am using, rolled out IPv6 to every customer, and according to some statistics, around 70% are actually using it [1]. About 35% of traffic reaching Google uses IPv6 [2]. I have been using IPv6 myself for probably over a decade by now. Initially via Hurricane Electric tunnels, and later as Comcast made IPv6 available, I used the allocation provided by Comcast. So why stop using it now?

To better understand who is using IPv6, let’s “zoom in” on Google’s IPv6 statistic. The graph is notably “noisy.” But the reason it looks so broad isn’t noise: IPv6 usage is higher on Weekends compared to Weekdays.

The reason is pretty simple. For ISPs, IPv6 is needed in case they run out of IPv4 address space. Currently, not a lot of enterprises or businesses are adding IP address space. Actually, the opposite is happening: Enterprises are dismantling datacenters and are moving them into the cloud. 

This leaves home users, particularly mobile users, as the main growth area for IP addresses and, with that, the sole use case for IPv6. But ISPs still have to support IPv4 access as well, often via carrier-grade NAT (cgNAT). By having to support both IPv4 and IPv6, ISPs have not really been able to take advantage of everything IPv6 has to offer, and implementations have been “messy.”

How IPv6 is supposed to work

IPv6 has a lot of promise. Or should I say: IPv6 promises a lot of features. One of the big ones is end-to-end connectivity and the end of NAT. For a home user, NAT isn’t really a bit problem. But for carriers, NAT is getting complex and expensive. Some estimates talk about up to $40/year/user [3]. IPv6 also has the potential to be faster, but real-world results are mixed at this point. IPv6 works best if end-user networks are assigned a /48. This may sound like an excessive amount of addresses, but there is a reason for /48s being the “sweet spot.” First of all, the minimum network size in IPv6 is a /64. Your ISP will typically assign you at least a /64. But this allocation can not be split into various subnets, making it impossible to, for example, set up a distinct IoT subnet. With IPv4, we can use NAT to create various subnets. But with IPv6, we do not really have NAT as an option. 

Unless: If you have a /48!. A/48 is so “magic” because you have 16 bits to play with. This allows for the use of “Prefix Translation.” Yes! NAT for IPv6. The main advantage of this over plain old NAT is that each internal IP address will be mapped to a unique external address. But why do “NAT” in IPv6? Because you may need to renumber… For IPv4, having your external IP address change isn’t a big deal. NAT will make the change transparent to your network. But in IPv6, renumbering may have to happen too, and with all hosts in your network using publicly routed IP addresses, you will need to renumber every single host in your network. Sure… some of this can be automated… if it works.

RIPE, the European regional internet registry, suggests a “/48 for everybody” in its “Best Current Operational Practice” document [4] . From this document:

4.2.1. /48 for everybody

This is probably the most practical way to assign IPv6 prefixes to end customer CPE devices. In this case everyone has a /48 prefix and advanced end-users are less likely to make mistakes when addressing their networks and devices, resulting in much less call-centre time to sort out problems. It also has the advantage of sharing the same prefix size as ULAs and some transition mechanisms, so this facilitates a direct mapping of existing customer addressing plans to the delegated prefix.

Sadly, ISPs have made extra money selling IP address allocations and are unwilling to hand out /48s. IPv6 is a beautiful protocol. It removes many of the rough edges of IPv4 and turns IPv4, a research experiment that essentially was left running by mistake, into a global business network.

So let’s look at some current IPv6 implementations I have had first-hand experience with and why they fail.

AT&T Mobile

All AT&T mobile phones will be assigned a /64. Devices tethered to a mobile phone will receive addresses from this /64. This works well for mobile phones as you are not likely to run a complex network from a mobile phone. But AT&T has a special treat for you: NAT! All IPv6 traffic from the phone appears to be NAT’ed. This will remove the biggest advantage of IPv6 immediately. No idea why IPv6 would do that.

T-Mobile Mobile Phone

Again, your phone will receive an IPv6 /64. T-Mobile may also take advantage of “464 XLAT” if your phone supports it [5]. This protocol will encapsulate all your IPv4 traffic into IPv6. T-Mobile will only “see” IPv6 traffic on its network and NAT IPv4 at its border. Pretty neat set up but can be “messy” in that your phone no longer has a unique IPv4 address within T-Mobile’s network (not even a unique unroutable address, but instead, 464XLAT uses a small netblock set aside for 464-XLAT, so essentially all phones use the same IPv4 address) [6].

But from my own experience, neither T-Mobile nor AT&T allows inbound traffic to the phone’s IPv6 address. This negates some of the advantages of having a globally routable IPv6 address.

T-Mobile 5G Home Internet

This service is still rather new, and I have only been experimenting with it for a couple of days. But it appears to work pretty much like the T-Mobile phone-based internet service. Your T-Mobile gateway is assigned a NAT’ed IPv4 address and a single /64. You cannot use IPv6 if you are using your own router/firewall connected to the 5G access point, and for IPv4, you have to deal with double/tribble NAT. Unless all of your devices are directly connected to the access point, IPv6 is useless.

T-Mobiles gateway is also locked down and not allowing any “bridge mode” or other configuration options.

Comcast/Xfinity Business Service

Comcast will assign business users a /56. You may connect a router to the modem, and it may request a /59 allowing for multiple routers to be connected. But be aware that the modem doesn’t really track which router gets what /59, so after a reboot, your router may get a different /59 (out of the /56 assigned to the modem). Also, Comcast currently does not offer static IPv6 assignments. If you change your modem, you will get a new /59 even if your IPv4 address range remains the same (if you paid for a static IPv4 address). In the past, Comcast also changed its allocation policies without notice. For example, it used to be that the router received a /60 from the modem. Now it does receive a /59. The route MUST request the address via DHCP, or the modem will not know how to route it. Expiring DHCP leases or a modem reboot will break IPv6. (Comcast sometimes reboots modems without notice for firmware upgrades). Only obtaining a /56 and not having the ability to use special IPv6 features like mobile IP, failover to another carrier will not work.

By default, the Comcast supplied modem will block inbound IPv6, but this is easily adjusted (so actually a good thing to set it up secure by default). The firewall in the modem is a bit of a joke, but well, it blocks some packets…


Comcast IPv6 Firewall Configuration Options

All Carriers: Support

So far, I have not had a successful support call regarding IPv6 with any ISP. As far as the ISP is concerned: If IPv4 is working for you, your connection is working, and there is no reason for them to fix anything. 

Final words

No static IPv6 addresses, no /48 allocations, inability to do fail over to a different carrier, stability issues, and lack of support are why I now, after 10+ years, no longer use IPv6 in my network. There are pockets where I may still use it, but so far, there isn’t really a good reason to keep IPv6 enabled. Nothing “broke” so far. Lackluster implementations by ISPs that fix the current issue and no/limited use of ISPs by enterprise networks and cloud providers make it difficult to justify the time it takes. And maybe I am getting too old to play with my network configuration all the time.

Please comment if you had your own experience with IPv6 you would like to share.

[1] https://www.worldipv6launch.org/measurements/
[2] https://www.google.com/intl/en/ipv6/statistics.html
[3] https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf
[4] https://www.ripe.net/publications/docs/ripe-690
[5] https://datatracker.ietf.org/doc/html/rfc6877
[6] https://www.internetsociety.org/resources/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →