Archive for September 14th, 2020

Traffic Analysis Quiz: Oh No… Another Infection!, (Tue, Sep 15th)


Today’s diary is another traffic analysis quiz (here’s the previous one) where you try to identify the malware based on a pcap of traffic from an infected Windows host.  Download the pcap for today’s quiz from this page, which also has a JPG image of the alerts list.  Don’t open or review the alerts file yet, because it gives away the answer.

As before, I’ll provide the requirements for this quiz and give some background on the infection.

Shown above:  Screenshot of the pcap for this quiz open in Wireshark.


This type of analysis requires Wireshark.  Wireshark is my tool of choice to review packet captures (pcaps) of infection activity.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That’s why I encourage people to customize Wireshark after installing it.  To help, I’ve written a series of tutorials.  The ones most helpful for this quiz are:

Another requirement: use a non-Windows environment like BSD, Linux, or macOS.  Why?  Because this pcap contains HTTP traffic sending Windows-based malware.  If you’re using a Windows host to review the pcap, your antivirus (or Windows Defender) may delete the pcap or malware.  Worst case?  If you extract the malware from the pcap and accidentally run it, you might infect your Windows computer.

As always, beware, because there’s actual malware involved here.

Background on the infection

This infection was caused by a link from an email that returned a Word document.  Unfortunately, I do not have a copy of the email.  The downloaded document has macros designed to infect a vulnerable Windows host.

Shown above:  Link from an email returning a Microsoft Word document.

Here is a link to’s sandbox analysis of a document retrieved from the initial URL.  Normally, I state how this type of malware is ineffective against an up-to-date Windows 10 host running the latest version of Microsoft Office with default security settings.

However, I was able to download the Word document from this link without any warnings from Windows, and I merely had to click twice: once to get past Protected View, and one more time to enable macros.  Tamper Protection and all other security measures were in place, but my Windows 10 lab host still became infected.

Shown above:  After downloading the Word document, I checked it with Microsoft Defender, which said it was okay.

Shown above:  Default security settings still allowed me to click twice and get past two warnings (exit Protected View, then enable macros).

Shown above:  Malware binary retrieved by Word macro was not detected or stopped by Microsoft’s security measures.

This is a good example of how malware authors can evade security measures baked into Windows 10 and Microsoft applications.  Of course, this type of email has to get through the spam and virus filters before this could happen…  I mean, what are the odds?

Shown above:  A recent email that made it past my spam filters to my inbox.

Apparently, if malware distributors send out enough spam, some of it’s bound to reach somebody, somewhere.  This malware is updated often enough, that someone might receive it, click their way through some warnings, and infect their computer.

I guess that’s why we still have a thriving market for security vendors and endpoint protection.

Reviewing the Pcap

I went over some of the basics last time, so I won’t do that here today.  The alerts should let you know what type of malware is involved, and if more than one type of malware is involved.

Final words

As usual, this quiz might not be hard for an experienced malware analyst, but some of you might find this interesting.  The alerts really give this one away.

Again, a pcap of the traffic and a jpeg image showing associated alerts can be found here.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Not Everything About ".well-known" is Well Known, (Mon, Sep 14th)

More than 10 years ago, a first RFC was published describing the “.well-known” directory for web servers. The idea is pretty simple: Provide a standard location for files that are mostly intended for signaling and automatic retrieval. Before the introduction of .well-known, these files often ended up litering the document root, like for example robots.txt being probably the most popular example. Currently, .well-known is defined by RFC8615 [] . 

Over the years, a number of locations were added to .well-known. You can find the authoritative list at IANA [] and I would like to highlight a few of them here:

  • acme-challenges

This is likely the most “famous” .well-known location. This directory is used by clients speaking the “ACME” protocol to leave challenges as they are retrieving TLS certificates from services like Let’s Encrypt. Your ACME client (e.g. certbot or will drop files in this location. You will not manage these files yourself typically.

  • change-password

Oddly not listed at the IANA site, but already implemented in Safari and some large web sites. This URL will redirect to a page that will allow users to change their password. The feature, at least as implemented in Safari, does not appear terribly useful. Only if you change your password using Safari’s built in password manager (“Keychain”), will you have the option to be redirected to the “change password” page. But this feature is particularly meant for password managers. I played a bit with it, and find it doesn’t work well as you typically need to log in first before changing your password.

  • dnt / dnt-policy.txt

A place to leave a privacy polity (DNT = Do Not Track). There are fairly detailed standards describing how to implemented various policies. There are machine and human readable versions of the policy. This feature was a bit designed around the European GDPR rules.

  • mta-sts.txt

This file describes the STARTTLS policy for a particular domain. A DNS record will alert a mail server that supports the feature of the policy. The policy will describe which mail servers are covered by it, and what encryption to expect. This feature is supposed to reduce the risk of MitM attacks being used to strip the STARTTLS headers.

  • security.txt

A security contact for a particular domain (this is currently a draft, and the URL is not yet listed with IANA). We talked about this in a recent diary. The main goal is to make it easier for researchers to notify a website’s owner of vulnerabilities.

  • sshfp

Lists SSH server fingerprints. This is a bit interesting but also dangerous. You could end up publishing a great resource for attackers by giving them nice fodder for recognizance. But it is also an ongoing issue that it is difficult to distribute public SSH keys for servers, and they are often not verified correctly by users.

So what’s your favorite “.well-known” feature that may not be so well known?


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →