We are about two months past the 5-year anniversary of WannaCry outbreak[1] and about a week past the 5-year anniversary of NotPetya outbreak[2]. Since both WannaCry and NotPetya used the EternalBlue[3] exploit in order to spread, I thought that it might be interesting to take a look at how many internet-facing systems still remain vulnerable to it.
Tag Archives: Security
7-Zip & MoW: "For Office files", (Mon, Jul 4th)
As I explained in my diary entry "7-Zip & MoW", the MoW on a ZIP file can be set to be propagated by 7-Zip to Office files only (propagation setting "For Office files").
My tests showed that this was based on the file extension of the Office file. As I received some questions about this, I took a look at the 7-Zip source code.
Here is the code that determines whether to write a Zone.Identifier ADS or not depending on the setting for Zone.Identifier propagation:
It uses function FindExt2 to check if the extension of the extracted file (_diskFilePath) matches a list of predefined extensions (kOfficeExtensions).
This is the predefined list kOfficeExtensions:
Notice that the extension RTF is not in this list.
And while I was browsing the source code, I also took a look at the possible registry values for this setting:
7-Zip deletes registry values if they are not used (-1).
That is why you will find values 1 (all files) and 2 (Office files only) only in the registry.
Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
7-Zip & MoW, (Sun, Jul 3rd)
Version 22.0 of 7-Zip introduces support for the propagation of the Mark-of-Web. This is an Alternate Data Stream with name Zone.Identifier that is added by browsers and email clients on Windows system with NTFS disks, to mark that a file was downloaded from and untrusted source ("The Internet").
AA22-181A: #StopRansomware: MedusaLocker
Original release date: June 30, 2022
Summary
Actions to take today to mitigate cyber threats from ransomware:
• Prioritize remediating known exploited vulnerabilities.
• Train users to recognize and report phishing attempts.
• Enable and enforce multifactor authentication.
Note: this joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.
The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), the Department of the Treasury, and the Financial Crimes Enforcement Network (FinCEN) are releasing this CSA to provide information on MedusaLocker ransomware. Observed as recently as May 2022, MedusaLocker actors predominantly rely on vulnerabilities in Remote Desktop Protocol (RDP) to access victims’ networks. The MedusaLocker actors encrypt the victim’s data and leave a ransom note with communication instructions in every folder containing an encrypted file. The note directs victims to provide ransomware payments to a specific Bitcoin wallet address. MedusaLocker appears to operate as a Ransomware-as-a-Service (RaaS) model based on the observed split of ransom payments. Typical RaaS models involve the ransomware developer and various affiliates that deploy the ransomware on victim systems. MedusaLocker ransomware payments appear to be consistently split between the affiliate, who receives 55 to 60 percent of the ransom; and the developer, who receives the remainder.
Download the PDF version of this report: pdf, 633 kb
Technical Details
MedusaLocker ransomware actors most often gain access to victim devices through vulnerable Remote Desktop Protocol (RDP) configurations [T1133]. Actors also frequently use email phishing and spam email campaigns—directly attaching the ransomware to the email—as initial intrusion vectors [T1566].
MedusaLocker ransomware uses a batch file to execute PowerShell script invoke-ReflectivePEInjection
[T1059.001]. This script propagates MedusaLocker throughout the network by editing the EnableLinkedConnections
value within the infected machine’s registry, which then allows the infected machine to detect attached hosts and networks via Internet Control Message Protocol (ICMP) and to detect shared storage via Server Message Block (SMB) Protocol.
MedusaLocker then:
- Restarts the
LanmanWorkstation
service, which allows registry edits to take effect. - Kills the processes of well-known security, accounting, and forensic software.
- Restarts the machine in safe mode to avoid detection by security software [T1562.009].
- Encrypts victim files with the AES-256 encryption algorithm; the resulting key is then encrypted with an RSA-2048 public key [T1486].
- Runs every 60 seconds, encrypting all files except those critical to the functionality of the victim’s machine and those that have the designated encrypted file extension.
- Establishes persistence by copying an executable (
svhost.exe
orsvhostt.exe
) to the%APPDATA%Roaming
directory and scheduling a task to run the ransomware every 15 minutes. - Attempts to prevent standard recovery techniques by deleting local backups, disabling startup recovery options, and deleting shadow copies [T1490].
MedusaLocker actors place a ransom note into every folder containing a file with the victim’s encrypted data. The note outlines how to communicate with the MedusaLocker actors, typically providing victims one or more email address at which the actors can be reached. The size of MedusaLocker ransom demands appears to vary depending on the victim’s financial status as perceived by the actors.
Indicators of Compromise
Encrypted File Extensions | |||
---|---|---|---|
.1btc | .matlock20 | .marlock02 | .readinstructions |
.bec | .mylock | .jpz.nz | .marlock11 |
.cn | .NET1 | .key1 | .fileslocked |
.datalock | .NZ | .lock | .lockfilesUS |
.deadfilesgr | .tyco | .lockdata7 | .rs |
.faratak | .uslockhh | .lockfiles | .tyco |
.fileslock | .zoomzoom | .perfection | .uslockhh |
.marlock13 | n.exe | .Readinstruction | .marlock08 |
.marlock25 | nt_lock20 | .READINSTRUCTION | |
.marlock6 | .marlock01 | .ReadInstructions |
Ransom Note File Names | |
---|---|
how_to_ recover_data.html | how_to_recover_data.html.marlock01 |
instructions.html | READINSTRUCTION.html |
!!!HOW_TO_DECRYPT!!! | How_to_recovery.txt |
readinstructions.html | readme_to_recover_files |
recovery_instructions.html | HOW_TO_RECOVER_DATA.html |
recovery_instruction.html |
Payment Wallets |
---|
14oxnsSc1LZ5M2cPZeQ9rFnXqEvPCnZikc |
1DRxUFhvJjGUdojCzMWSLmwx7Qxn79XbJq |
18wRbb94CjyTGkUp32ZM7krCYCB9MXUq42 |
1AbRxRfP6yHePpi7jmDZkS4Mfpm1ZiatH5 |
1Edcufenw1BB4ni9UadJpQh9LVx9JGtKpP |
1DyMbw6R9PbJqfUSDcK5729xQ57yJrE8BC |
184ZcAoxkvimvVZaj8jZFujC7EwR3BKWvf |
14oH2h12LvQ7BYBufcrY5vfKoCq2hTPoev |
bc1qy34v0zv6wu0cugea5xjlxagsfwgunwkzc0xcjj |
bc1q9jg45a039tn83jk2vhdpranty2y8tnpnrk9k5q |
bc1qz3lmcw4k58n79wpzm550r5pkzxc2h8rwmmu6xm |
1AereQUh8yjNPs9Wzeg1Le47dsqC8NNaNM |
1DeNHM2eTqHp5AszTsUiS4WDHWkGc5UxHf |
1HEDP3c3zPwiqUaYuWZ8gBFdAQQSa6sMGw |
1HdgQM9bjX7u7vWJnfErY4MWGBQJi5mVWV |
1nycdn9ebxht4tpspu4ehpjz9ghxlzipll |
12xd6KrWVtgHEJHKPEfXwMVWuFK4k1FCUF |
1HZHhdJ6VdwBLCFhdu7kDVZN9pb3BWeUED |
1PormUgPR72yv2FRKSVY27U4ekWMKobWjg |
14cATAzXwD7CQf35n8Ea5pKJPfhM6jEHak |
1PopeZ4LNLanisswLndAJB1QntTF8hpLsD |
Email Addresses | |
---|---|
willyhill1960@tutanota[.]com | unlockfile@cock[.]li |
zlo@keem[.]ne | unlockmeplease@airmail[.]cc |
zlo@keemail[.]me | unlockmeplease@protonmail[.]com |
zlo@tfwno[.]gf | willyhill1960@protonmail[.]com |
support@ypsotecs[.]com | support@imfoodst[.]com |
Email Addresses | |
---|---|
traceytevin@protonmail[.]com | support@itwgset[.]com |
unlock_file@aol[.]com | support@novibmaker[.]com |
unlock_file@outlook[.]com | support@securycasts[.]com |
support@exoprints[.]com | rewmiller-1974@protonmail[.]com |
support@exorints[.]com | rpd@keemail[.]me |
support@fanbridges[.]com | soterissylla@wyseil[.]com |
support@faneridges[.]com | support@careersill[.]com |
perfection@bestkoronavirus[.]com | karloskolorado@tutanota[.]com |
pool1256@tutanota[.]com | kevynchaz@protonmail[.]com |
rapid@aaathats3as[.]com | korona@bestkoronavirus[.]com |
rescuer@tutanota[.]com | lockPerfection@gmail[.]com |
ithelp01@decorous[.]cyou | lockperfection@gmail[.]com |
ithelp01@wholeness[.]business | mulierfagus@rdhos[.]com |
ithelp02@decorous[.]cyou | [rescuer]@cock[.]li |
ithelp02@wholness[.]business | 107btc@protonmail[.]com |
ithelpresotre@outlook[.]com | 33btc@protonmail[.]com |
cmd@jitjat[.]org | 777decoder777@protonmail[.]com |
coronaviryz@gmail[.]com | 777decoder777@tfwno[.]gf |
dec_helper@dremno[.]com | andrewmiller-1974@protonmail[.]com |
dec_helper@excic[.]com | angelomartin-1980@protonmail[.]com |
dec_restore@prontonmail[.]com | ballioverus@quocor[.]com |
dec_restore1@outlook[.]com | beacon@jitjat[.]org |
bitcoin@sitesoutheat[.]com | beacon@msgsafe[.]io |
briansalgado@protonmail[.]com | best666decoder@tutanota[.]com |
bugervongir@outlook[.]com | bitcoin@mobtouches[.]com |
best666decoder@protonmail[.]com | encrypt2020@outlook[.]com |
decoder83540@cock[.]li | fast-help@inbox[.]lv |
decra2019@gmail[.]com | fuc_ktheworld1448@outlook[.]com |
diniaminius@winrof[.]com | fucktheworld1448@cock[.]li |
dirhelp@keemail[.]me | gartaganisstuffback@gmail[.]com |
Email Addresses | |
---|---|
emaila.elaich@iav.ac[.]ma | gavingonzalez@protonmail[.]com |
emd@jitjat[.]org | gsupp@onionmail[.]org |
encrypt2020@cock[.]li | gsupp@techmail[.]info |
best666decoder@protonmail[.]com | helper@atacdi[.]com |
ithelp@decorous[.]cyou | helper@buildingwin[.]com |
ithelp@decorous[.]cyoum | helprestore@outlook[.]com |
ithelp@wholeness[.]business | helptorestore@outlook[.]com |
TOR Addresses |
---|
http://gvlay6u4g53rxdi5.onion/6-iSm1B1Ehljh8HYuXGym4Xyu1WdwsR2Av-6tXiw1BImsqoLh7pd207Rl6XYoln7sId |
http://gvlay6u4g53rxdi5.onion/8-grp514hncgblilsjtd32hg6jtbyhlocr5pqjswxfgf2oragnl3pqno6fkqcimqin |
http://gvlay6y4g53rxdi5.onion/21-8P4ZLCsMETPaLw9MkSlXJsNZWdHe0rxjt-XmBgZLWlm5ULGFCOJFuVdEymmxysofwu |
http://gvlay6u4g53rxdi5.onion/2l-8P4ZLCsMTPaLw9MkSlXJsNZWdHeOrxjtE9lck1MuXPYo29daQys6gomZZXUImN7Z |
http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-DcaE9HeHywqSHvdcIwOndCS4PuWASX8g |
http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-kB4rQXGKyxGiLyw7YDsMKSBjyfdwcyxo |
http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-bET6JbB9vEMZ7qYBPqUMCxOQExFx4iOi |
http://gvlay6u4g53rxdi5. onion/8-MO0Q7O97Hgxvm1YbD7OMnimImZJXEWaG-RbH4TvdwVTGQB3X6VOUOP3lgO6YOJEOW |
http://gvlay6u4g53rxdi5.onion/8-gRp514hncgb1i1sjtD32hG6jTbUh1ocR-Uola2Fo30KTJvZX0otYZgTh5txmKwUNe |
http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-OWQwD1w1Td7hY7IGUUjxmHMoFSQW6blg |
http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-uGHwkkWCoUtBbZWN50sSS4Ds8RABkrKy |
http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-Tj3PRnQlpHc9OftRVDGAWUulvE80yZbc |
http://gvlay6u4g53rxdi5.onion/8-Ww5sCBhsL8eM4PeAgsfgfa9lrqa81r31-tDQRZCAUe4164X532j9Ky16IBN9StWTH |
http://gvlay6u4g53rxdi5.onion/21-wIq5kK9gGKiTmyups1U6fABj1VnXIYRB-I5xek6PG2EbWlPC7C1rXfsqJBlWlFFfY |
qd7pcafncosqfqu3ha6fcx4h6sr7tzwagzpcdcnytiw3b6varaeqv5yd.onion |
http://medusacegu2ufmc3kx2kkqicrlcxdettsjcenhjena6uannk5f4ffuyd.onion/leakdata/paigesmusic-leakdata-closed-part1 |
Disclaimer: Many of these observed IP addresses are several years old and have been historically linked to MedusaLocker ransomware. We recommend these IP addresses be investigated or vetted by organizations prior to taking action, such as blocking.
IP Address | Last Observed |
---|---|
195.123.246.138 | Nov-2021 |
138.124.186.221 | Nov-2021 |
159.223.0.9 | Nov-2021 |
45.146.164.141 | Nov-2021 |
185.220.101.35 | Nov-2021 |
185.220.100.249 | Sep-2021 |
50.80.219.149 | Sep-2021 |
185.220.101.146 | Sep-2021 |
185.220.101.252 | Sep-2021 |
179.60.150.97 | Sep-2021 |
84.38.189.52 | Sep-2021 |
94.232.43.63 | Jul-2021 |
108.11.30.103 | Apr-2021 |
194.61.55.94 | Apr-2021 |
198.50.233.202 | Apr-2021 |
40.92.90.105 | Jan-2021 |
188.68.216.23 | Dec-2020 |
87.251.75.71 | Dec-2020 |
196.240.57.20 | Oct-2020 |
198.0.198.5 | Aug-2020 |
194.5.220.122 | Mar-2020 |
194.5.250.124 | Mar-2020 |
194.5.220.124 | Mar-2020 |
104.210.72.161 | Nov-2019 |
MITRE ATT&CK Techniques
MedusaLocker actors use the ATT&CK techniques listed in Table 1.
Table 1: MedusaLocker Actors ATT&CK Techniques for Enterprise
Initial Access | ||
---|---|---|
Technique Title | ID | Use |
External Remote Services | T1133 | MedusaLocker actors gained access to victim devices through vulnerable RDP configurations. |
Phishing | T1566 | MedusaLocker actors used phishing and spearphishing to obtain access to victims’ networks. |
Execution | ||
Technique Title | ID | Use |
Command and Scripting Interpreter: PowerShell |
T1059.001 |
MedusaLocker actors may abuse PowerShell commands and scripts for execution. |
Defense Evasion | ||
Technique Title | ID | Use |
Impair Defenses: Safe Mode Boot |
T1562.009 |
MedusaLocker actors may abuse Windows safe mode to disable endpoint defenses. Safe mode starts up the Windows operating system with a limited set of drivers and services. |
Impact | ||
Technique Title | ID | Use |
Data Encrypted for Impact | T1486 | MedusaLocker actors encrypt data on target systems or on large numbers of systems in a network to interrupt availability to system and network resources. |
Inhibit System Recovery | T1490 | MedusaLocker actors may deny access to operating systems containing features that can help fix corrupted systems, such as backup catalog, volume shadow copies, and automatic repair. |
Mitigations
- Implement a recovery plan that maintains and retains multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, or the cloud).
- Implement network segmentation and maintain offline backups of data to ensure limited interruption to the organization.
- Regularly back up data and password protect backup copies stored offline. Ensure copies of critical data are not accessible for modification or deletion from the system where the data resides.
- Install, regularly update, and enable real time detection for antivirus software on all hosts.
- Install updates for operating systems, software, and firmware as soon as possible.
- Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
- Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege.
- Disable unused ports.
- Consider adding an email banner to emails received from outside your organization.
- Disable hyperlinks in received emails.
- Enforce multifactor authentication (MFA).
- Use National Institute of Standards and Technology (NIST) standards for developing and managing password policies:
- Use longer passwords consisting of at least 8 characters and no more than 64 characters in length.
- Store passwords in hashed format using industry-recognized password managers.
- Add password user “salts” to shared login credentials.
- Avoid reusing passwords.
- Implement multiple failed login attempt account lockouts.
- Disable password “hints”.
- Refrain from requiring password changes unless there is evidence of password compromise. Note: NIST guidance suggests favoring longer passwords and no longer require regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
- Require administrator credentials to install software.
- Only use secure networks; avoid using public Wi-Fi networks.
- Consider installing and using a virtual private network (VPN) to establish secure remote connections.
- Focus on cybersecurity awareness and training. Regularly provide users with training on information security principles and techniques as well as overall emerging cybersecurity risks and vulnerabilities, such as ransomware and phishing scams.
Resources
- Stopransomware.gov is a whole-of-government approach that gives one central location for ransomware resources and alerts.
- Resource to mitigate a ransomware attack: CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide
- No-cost cyber hygiene services: Cyber Hygiene Services and Ransomware Readiness Assessment
Reporting
- To report an incident and request technical assistance, contact CISA at cisaservicedesk@cisa.dhs.gov or 888-282-0870, or FBI through a local field office.
- Financial Institutions must ensure compliance with any applicable Bank Secrecy Act requirements, including suspicious activity reporting obligations. Indicators of compromise (IOCs), such as suspicious email addresses, file names, hashes, domains, and IP addresses, can be provided under Item 44 of the Suspicious Activity Report (SAR) form. For more information on mandatory and voluntary reporting of cyber events via SARs, see FinCEN Advisory FIN-2016-A005, Advisory to Financial Institutions on Cyber-Events and Cyber-Enabled Crime, October 25, 2016; and FinCEN Advisory FIN-2021-A004, Advisory on Ransomware and the Use of the Financial System to Facilitate Ransom Payments, November 8, 2021, which updates FinCEN Advisory FIN-2020-A006.
- The U.S. Department of State’s Rewards for Justice (RFJ) program offers a reward of up to $10 million for reports of foreign government malicious activity against U.S. critical infrastructure. See the RFJ website for more information and how to report information securely.
Contact Information
To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field-offices. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To report incidents and anomalous activity or to request incident response resources or technical assistance related to this threat, contact CISA at report@cisa.gov.
Revisions
- June 30, 2022: Initial Version
This product is provided subject to this Notification and this Privacy & Use policy.
Case Study: Cobalt Strike Server Lives on After Its Domain Is Suspended, (Thu, Jun 30th)
Introduction
How do threat actors behind a Cobalt Strike server keep it running after its domain is taken down? If the server is not hosted through the domain registrar, it merely keeps running on the same IP address.
Today's diary is a case study where Cobalt Strike remained active on the same IP address at least one week after its domain was suspended.
Traffic Forensics
On Tuesday 2022-06-28, I generated a Qakbot infection in my lab and saw Cobalt Strike HTTPS traffic on 147.78.47[.]223 over TCP port 443 as shown below.
Shown above: Traffic from a Qakbot infection with Cobalt Strike on Tuesday 2022-06-28 filtered in Wireshark.
Examining the certificate in Wireshark reveals it's a Let's Encrypt certificate for moros[.]icu. Let's Encrypt is a legitimate free, automated, and open certificate authority (CA). While used by many valid websites, this service is commonly abused by threat actors, including those behind malicious Cobalt Strike activity.
Shown above: Reviewing certificate issuer data associated with Cobalt Strike traffic on 147.78.47[.]223 in Wireshark.
Investigating the Malicious Server
Viewing the certificate from 147.78.47[.]223 in a web browser reveals it was originally issued for moros[.]icu through Let's Encrypt on 2022-06-20 and is no longer valid for that IP.
Shown above: Connecting to the Cobalt Strike server using a web browser.
Shown above: Certificate data for moros[.]icu shown in a web browser.
The domain moros[.]icu was reported and suspended less than one day after it was registered through Namecheap, but its server was set up through a legitimate hosting provider at Flyservers. Kudos to @ian_kenefick and Namecheap for quickly taking action and suspending this malicious domain!
Shown above: Tweets showing moros[.]icu was suspended on 2022-06-21.
Shown above: My own confirmation that moros[.]icu no longer works.
Shown above: Whois lookup for 147.78.47[.]223 using whois.domaintools.com.
The certificate's validity did not matter for Cobalt Strike activity I found on Tuesday 2022-06-28. Since the traffic was generated by malware instead of a web browser, HTTPS still worked.
Flyservers has been a hosting provider since 2001, and it appears to be a legitimate company. I've emailed their abuse address to report the malicious server on 147.78.47[.]223.
Final Words
Threat actors continually abuse legitimate hosting providers and certificate authorities (CAs), presumably through fraudulent accounts. Both free and paid services are incredibly susceptible to criminal abuse. Even Cobalt Strike is a legitimate red team tool commonly abused by various threat actors.
Security professionals can quickly report abuse cases, and service providers can rapidly shut down individual violations. However, threat actors can easily recover, and malware-related servers will continue to be an issue for defenders everywhere.
This case study reveals how criminal activity can circumvent domain takedowns. It also illustrates how time-intensive the associated investigation and corrective actions can be.
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.
It's New Phone Day! Time to migrate your MFA!, (Wed, Jun 29th)
Possible Scans for HiByMusic Devices, (Tue, Jun 28th)
HiBy is a brand of portable music players built around the Android operating system. Probably a bit comparable to the now-defunct iPod touch, the device does use a close to "stock" version of Android and adds its own "HiByMusic" application as a music player. The hardware includes a Snapdragon ARM CPU standard on Android devices and attempts to distinguish itself with DACs claimed to be better than those found in other devices.

The device offers a feature to load custom network radio station URLs via a "radio.txt" file. The file is a simple text file with a list of URLs. For example:
Radio Dismuke 1920s-30s pop/jazz, http://74.208.197.50:8020/stream.mp3
SomaFM: Heavyweight Reggae, http://ice2.somafm.com/reggae-256.mp3
SomaFM: Groove Salad, http://ice5.somafm.com/groovesalad-256.mp3
SomaFM: Groove Salad Classic, http://ice4.somafm.com/gsclassic-128.mp3
(sample of a radio.txt file found here: https://www.head-fi.org)
I was a bit surprised that we recently started seeing some scans looking for radio.txt files based on our "First Seen" report. The number of submissions is small. (see the URL History for radio.txt)
So the question is: why?
- I found one vulnerability specific to HiByMusic: %%CVE:2021-44124%% . It is a simple directory traversal and may result in information leakage. I don't think this is all that interesting but sure. Maybe other vulnerabilities have not yet been made public, or the attacker is looking for generic Android issues
- radio.txt files may include internal audio sources that are not openly advertised. This could leak information.
- Or just someone essentially trying to build a "radio station spider" to find as many publicly available radio stations as possible. Anybody knows if this "radio.txt" file is unique to HiByMusic, or if other players use files like this?
At least one more report is not linked to our data observing requests for radio.txt.
Any ideas about what's going on here?
—
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.
Encrypted Client Hello: Anybody Using it Yet?, (Mon, Jun 27th)
The first payload sent by a TLS client to a TLS server is a "Client Hello." It includes several parameters supported by the client, such as available cipher suites, to start negotiating a compatible set of TLS parameters with the server.
One particular option, the "Server Name Indication" (SNI), lists the hostname the client is looking for. The client hello is sent in the clear and has often been considered a privacy issue or, for some network defenders, the last straw to hold on to gain insight into TLS encrypted traffic.
Encrypted SNI (ESNI) was an initial solution to the privacy problem. As the name implies, it encrypts the SNI option in the client hello. The encryption uses a key communicated via DNS. You will first see a DNS lookup for a TXT record _esni.[domain name]. This TXT record will return the public key to encrypt the SNI option.
ESNI solves a significant part of the client hello privacy problem. But other client-hello options may be used to fingerprint clients. Encrypting the entire client hello message is the next obvious option. This idea, Encrypted Client Hello (ECH), is currently an IETF draft [ECH]. The encrypted client hello options are wrapped into an unencrypted "Client Hello Outer" that is used as a vessel to transport the encrypted blob. This blob will look like any other client hello option to a server not capable of ECH.
Instead of a TXT record to communicate the key, ECH uses new SVCB and HTTPS records. This record provides more flexibility to advertise different options and keys [HTTPSRR].
Despite these standards in the draft stage, browsers are adding support for them. For the most part, ESNI is considered "dead" at this point, and browsers actively support ECH, but it may not be enabled by default. One feature that may lead to SVCB and HTTPS records being more commonly used than similar protocols like DANE is that SVCB/HTTPS does not require DNSSEC. The client will be able to verify the authenticity of the server using the usual TLS certificates. The DNS messages remain unprotected. As pointed out in the IETF draft, a hostile resolve will be able to downgrade the DNS responses.
But back to the title: Is anybody using these fancy standards? I took a look at my DNS logs to see how many requests I am seeing (and how many of them result in answers):
DNS requests for HTTPS records are undoubtedly popular, with about one HTTPS request for every 4 A record requests. Also, about 20% of the responses to HTTPS queries include at least one answer. So this looks pretty good, but the answer section of the response will not provide an answer here. None of the answers included an HTTPS record. They exclusively include A or CNAME records, which is also perfectly legal.
And a little side note if you want to play with this: The "dig" utility, at least the version I used (9.16.1-Ubuntu), does not fully understand the HTTPS record type.
$ dig -t HTTPS example.com
;; Warning, ignoring invalid type HTTPS
This warning is easily overlooked. Instead, try:
$dig -t TYPE65 blog.cloudflare.com
…
;; ANSWER SECTION:
blog.cloudflare.com. 18 IN TYPE65 # 67 0001000001000C0268330568332D323902683200040008681229AEAC 40925200060020260647004400000000000000681229AE2606470044 00000000000000AC409252
…
To query HTTPS records.
But the short answer to the headline question: No. Clients try to use it, but servers are not yet supporting encrypted client hello. Know of any example sites using it? Any comments or other suggestions to improve the methodology? Please leave a comment.
Oh. And, of course, this looks like yet another DNS covert channel opportunity.
[ECH] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14
[HTTPSRR] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-10
—
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.
My Paste Command, (Sun, Jun 26th)
More Decoding Analysis, (Sun, Jun 26th)
I received several reactions to my diary entry "Decoding Obfuscated BASE64 Statistically" and accompanying video.
I also made another example, this time with hexadecimal encoding.
The blog post: "Another Exercise In Encoding Reversing"
The video:
Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.