Tag Archives: SANS

EternalBlue 5 years after WannaCry and NotPetya, (Tue, Jul 5th)

This post was originally published on this site

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.

7-Zip & MoW: "For Office files", (Mon, Jul 4th)

This post was originally published on this site

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.

Case Study: Cobalt Strike Server Lives on After Its Domain Is Suspended, (Thu, Jun 30th)

This post was originally published on this site

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.

Possible Scans for HiByMusic Devices, (Tue, Jun 28th)

This post was originally published on this site

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.

image of hiby music device
Image of HiBy device from store.hiby.com

 

 

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)

This post was originally published on this site

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.

More Decoding Analysis, (Sun, Jun 26th)

This post was originally published on this site

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.