Archive for August 4th, 2020

Traffic Analysis Quiz: What's the Malware From This Infection?, (Wed, Aug 5th)


Today’s diary is a traffic analysis quiz where you try to identify the malware based on a pcap of traffic from an infected Windows host.  Download the pcap from this page, which also has the alerts.  Don’t open or review the alerts yet, because they give away the answer.

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

Shown above:  Screenshot of the pcap for this quiz opened 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.

So if you’re new to this type of analysis, beware.  There’s malware involved.

Background on the infection

This infection was caused by a malicious Excel spreadsheet.  It has macros designed to infect a vulnerable Windows host, so I infected one in my lab.  Default settings in recent versions of Microsoft Office would prevent these type of macros from causing an infection.  This is much more effective against older versions of Windows like Windows 7.

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

Enabling macros on this spreadsheet caused my vulnerable host to download a malicious Windows executable (EXE) and save it as C:UsersPublicsvchost32.exe where it was initially run.

Shown above:  The initial location of the malicious EXE on my infected lab host.

After a minute or two, the malware was deleted from C:UsersPublicsvchost32.exe and saved under a randomly-named directory under C:Program Files (x86) using a random file name.  The directory and new file name are different for each infection.  The malware was made persistent through an update to the Windows registry as shown below.

Shown above:  Windows registry update and location of the malware persistent on my infected host.

This method is used by different families of malware.  The chain of events:

  • Victim receives a malicious Microsoft Office document (usually an Excel spreadsheet or Word document)
  • Victim enables macros on a vulnerable Windows host
  • Vulnerable Windows host retrieves a Windows EXE or DLL through web-based traffic
  • EXE or DLL is saved to disc
  • The EXE or DLL infects the vulnerable Windows host and is made persistent

Fortunately, this chain is rarely effective against an up-to-date version of Windows with default security settings.  In this case, Microsoft Office would not run the macro unless I disabled some key security functions.

Shown above:  Warning message I initially saw on my lab host.

Reviewing the pcap

If you’ve set up Wireshark according to the previously-mentioned tutorials, open the pcap and use the basic web filter to find an HTTP request to aromaterapiaclinicabrasil[.]com[.]br on 162.214.51[.]208.

Shown above:  Traffic from the quiz pcap filtered in Wireshark.

This HTTP request ends with .jpg, but it returned an EXE.  Left click on that line and follow the TCP stream, so we can confirm this is, in fact, an EXE.

Shown above:  HTTP request ending with .jpg returns a Windows EXE or DLL.

Is this is an EXE, or is it a DLL?  They both look the same in a TCP stream.  The ASCII characters MZ show as the first two bytes, and This program must be run under Win32 could be used by an EXE, or it could be used by a DLL.  To get more information on the file, we can explort it from the pcap.  A word of caution: this is Windows malware, so you should export this file in a non-Windows environment.

Use the menu path File –> Export Objects –> HTTP and export the file returned from aromaterapiaclinicabrasil[.]com[.]br as shown in the next two images.

Shown above:  Exporting objects from HTTP traffic in the pcap.

Shown above:  Saving the file returned from aromaterapiaclinicabrasil[.]com[.]br.

In a Linux environment, it’s easy to confirm what type of file this is.  Use the file command in a terminal window.  Get the SHA256 hash of the file using the shasum -a 256 command as shown below.  I prefer a Debian or Ubuntu-based Linux environment, but any Linux environment will do.

Shown above:  Using a terminal window to confirm this is an EXE and get the SHA256 hash.

Once you have the SHA256 hash, search for it in VirusTotal or publicly-available online sandboxes like,, and other sites. You can also do a Google search.

Shown above:  Google results when I searched for the SHA256 hash of the EXE.

Keep in mind the Office document is a delivery mechanism.  The actual malware is based on the EXE retrieved after enabling macros.  What is the malware family in this case?  The answer is not as straight-forward as you might think.  Different vendors often have their own names for the same type of malware.  In this case, alerts from the post-infection traffic will reveal what family of malware caused this infection.

Shown above:  Alerts from the infection using Security Onion with Suricata and the EmergingThreats Pro (ETPRO) ruleset.

Final words

If you’re an experienced malware analyst, this quiz might provide a minute or two of interest.  If you’re tempted to immediately know the answer, just review the alerts and find ones for the CnC traffic.  If you’re new to this type of analysis, hopefully this quiz has helped.

Once again, a pcap of the traffic and the associated alerts are located here

A copy of the spreadsheet that caused this traffic can be found here.

A copy of the EXE 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) →

Internet Choke Points: Concentration of Authoritative Name Servers, (Tue, Aug 4th)

A utopian vision of the Internet often describes it as a distributed partnership of equals giving everybody the ability to publish and discover information worldwide. This open, democratic Internet is often little more than an imaginary legacy construct that may have existed at some time in the distant past, if ever. Reality: Today, the Internet is governed by a few large entities. Diverse interconnectivity and content distribution were also supposed to make the Internet more robust. But as it has been shown over and over again, a simple misconfiguration at a single significant player will cause large parts of the network to disappear. 

Today, I played a bit with top-level domain zone files that I have been investigating recently. I have been looking at close to 900 different zones. Many of them are meaningless and not used, but it also included the big once like .com, .top (yes. this is the 2nd largest zone now), .net and .org. Any guesses on the 5th largest zone file? Either way, for this experiment, I extracted the NS records, and also A/AAAA records for all these TLDs. These are about 477 Million records and 2.7 Million different name server hostnames. These hostnames resolve to 1 Million IPv4 IPs (ok.. so many of these “redundant” name servers resolve to the same IP. No news here)., and only 37k AAAA records (showing how much more fragile the IPv6 internet is).

Note that we are talking about authoritative name servers here, not recursive name servers (which may have similar concentration issues with the increased popularity of services like Cloudflare, OpenDNS, and Quad9).

Now the real problem: How many name servers, out of 2.7 Million, does it take to “turn off” 80% of the Internet. Good old overused Pareto rule would tell us 20% (roughly 550000). Wrong… It only takes 2,302 name servers or about 0.084%! 0.35 % of nameservers are responsible for 90% of all domain names.

This ratio does not change substantially if I use IP addresses or if I try to summarize name servers owned by different organizations. But a simple misconfiguration at one major DNS provider (see Cloudflare a couple of weeks ago) or a DDoS attack against one (DYN and Mirai) will bring down large parts of the “Internet” or at least make them accessible to people who can’t remember IP addresses (maybe making the Internet a safer place in the end).

Here are a couple of graphs to illustrate this issue.

While not necessarily the most intuitive way to look at this data, but the only way to actually display the data in a meaningful way is to use a logarithmic x-axis. Note that 80% is around 380 Million (3.8×10^8).

lograithmic number of name servers and records

Zooming in on the first 5,000 name servers will give us a bit better insight into how many domains they are responsible for. The green line (just like above) follows the cumulative number of NS records represented by the name servers. The red line indicates 80%, and the blue line 90%.

first 5000 hosts

And for effect, the entire dataset using a linear scale. Note how the green line is mostly horizontal.

So what can you learn from this: Using a cloud-based DNS service is simple and often more reliable than running your name server. But this large concentration of name services with few entities increases the risk to the infrastructure substantially. Couple ways to mitigate this risk:

  • Keep secondary name servers for zones you rely on in-house (this can be tricky for cloud providers you rely on. but you can try it for your domains and maybe some partners)
  • Use more than one DNS provider. A second provider should not be difficult to set up if you use a second provider and configure the name servers as secondary to your primary name servers.
Provider Number of records
Godaddy ( 94,536,346
Google Domains 20,134,705 (Xiamen Diensi) 15,642,026
IONOS (ui-dns) 15,599,972
hichina 15,118,733
Cloudflare 13,759,936 / 11,159,866 9,170,163 7.334.904 7.321,327

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) →

Reminder: Patch Cisco ASA / FTD Devices (CVE-2020-3452). Exploitation Continues , (Tue, Aug 4th)

Just a quick reminder: We are continuing to see small numbers of exploit attempts against CVE-2020-3452. Cisco patched this directory traversal vulnerability in its Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) software. The exploit is rather simple and currently used to find vulnerable systems by reading benign LUA source code files. 

Example attempts:

GET /+CSCOE+/translation-table?=mst&textdomain=/%bCSCOE%2b/[email protected]&lang=../ HTTP/1.1
GET /+CSCOE+/translation-table?=mst&textdomain=/+CSCOE+/[email protected]&lang=../
GET /translation-table?=mst&textdomain=

Out honeypot isn’t emulating this vulnerability well right now, so we are not seeing followup attacks.

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) →