Published: 2017-07-30

Text Banking Scams

Over the past few days I have been getting a few phone text scams that kind of look realistic except for certain flaws that are fairly easy to pick out, however this is where it is important to read the whole URL. First, if you don't have a banking account with the bank that appears to be texting you, you would just ignore and delete it. Most bank won't text or email you regarding issues with your account. However, if you do online banking with this bank you might be tempted to check it out.

The example that I picked is a text with this URL www.13bm0-olbanking-rec0nfirm-l0gin-secured.ml [1]. When you examine closely the details in the URL, it contains several errors; where it should be an "o" in bmo is has been replaced by a zero "0", the same with reconfirm and login and the country code is incorrect, it should be a dot com. Analysis of the site by urlscan shows the site is located in Amsterdam not in Canada but the picture of the scam [2] site looks very realistic compared to the real site [3].


Most banks have a mechanism to report such scams, BMO has a help page to either call or send them an email about this kind of scams [4] so other don’t get caught. If you are uncertain about your bank fraud policy, they usually have an online page about what to do.


[1] https://urlscan.io/result/78cc141d-5cb9-49c1-bd94-b44121042b2c/#summary
[2] https://urlscan.io/screenshots/78cc141d-5cb9-49c1-bd94-b44121042b2c.png
[3] https://www1.bmo.com/onlinebanking/cgi-bin/netbnx/NBmain?product=5
[4] https://www.bmo.com/home/popups/about/report-fraud

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


Published: 2017-07-30

SMBLoris - the new SMB flaw

While studying the infamous EternalBlue exploit about 2 months ago, researchers Sean Dillon (zerosum0x0) and Zach Harding (Aleph-Naught-) found a new flaw in the Server Message Block (SMB) protocol that could allow an adversary to interrupt the service by depleting the memory and CPU resources of the targeted machine on a Denial of Service (DoS) attack.

Tweet used to announce the flaw [2]

According to an article posted by ThreatPost [1], the flaw called SMBLoris was privately reported to Microsoft in early June, but the company considered it to be of moderate impact and that it would not be considered a security breach. In addition, it would probably not even be fixed.

As announced, some bug details were presented yesterday during a presentation at DEFCON 25 in Las Vegas. The attack is similar to another called SlowLoris [4] (hence also the similarity of the name) by allowing an attacker with a single machine and low bandwidth to be able to interrupt a service through a DoS attack. The difference is that SlowLoris affected Web servers.

Technically speaking, the problem occurs with the accumulation of a 4-bytes buffer called NBSS used during SMB session establishment which are allocated in the physical RAM and can not be swapped out. Triggering this, an attacker who initiates a large amount of connections to the service will be able to deplete the memory resources and after the CPU on the target.

NBSS buffer details

In the demonstration, an 8 GB memory server became unresponsive in a few seconds - note in the following figure the rapid increase in memory consumption during the attack.

SMBLoris attack demonstration

There is no update from Microsoft to fix the problem - so it has been considered a zero-day. For now, as a mitigation measure, the recommendation is to use a packet filter, like a Firewall, to limit the number of connections from a same source to the Windows servers on port 445 (SMB). 


[1] https://threatpost.com/windows-smb-zero-day-to-be-disclosed-during-def-con/126927/?utm_source=kasperskysocialchannel.com&utm_medium=REAL%20Solutions%20Technologies,%20LLC&utm_campaign=kasperskysocialchannel.com
[2] https://twitter.com/zerosum0x0/status/870862422327689216
[3] https://www.defcon.org/html/defcon-25/dc-25-speakers.html#Dillon
[4] https://web.archive.org/web/20090822001255/http://ha.ckers.org/slowloris/

Renato Marinho
Morphus Labs | LinkedIn | Twitter


Published: 2017-07-29

Maldoc Submitted and Analyzed

Reader Jason submitted a malicious document he received via email. Although it contains VBA code with string obfuscation that is not too complex, it has a very low VirusTotal detection score.

Let's start the analysis with oledump.py:

We have 2 streams with VBA code: A3 and A4

The for loop and the Chr$, Asc and Mid functions are clear indications that function sierra is a decoding function.

Let's look at stream A4:

And here we see a call to function sierra with 2 long strings which is executed when the document is closed. One string looks like encoded text, and the second string is a chain of digits. The decoding is actually simple. From each character in the first string, we substract the digit in the second string: f - 3 = c, n - 1 = m, g - 3 = d, ... That spells out as cmd...

It's clear that this is the payload command, here I decode it with a line of Python code:

The payload uses command "waitfor /t 3 hUZM" to wait for 3 seconds (hUZM is a signal that will never be received, /t 3 is a timeout after 3 seconds).

Then bitsadmin is used to download a file (cc.bin) and write it to disk as an .exe, which is then executed via start.

Finally, PowerShell is used to download a second file, but nothing is done with the download. It must be a tracker.

File cc.bin is indeed an executable:

And the second download is very small:




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


Published: 2017-07-28

Static Analysis of Emotet Maldoc

Brad wrote a great analysis of an Emotet maldoc send to us by a reader.

In this diary, I would like to show how this maldoc can be staticaly analyzed with a couple of tools.

oledump.py confirms it is an Office document with VBA macros, as we expected (the M indicators tell us which streams contain macros):

Selecting stream 9 (oledump.py -s 9 -v) shows the code that will execute automatically (Document_Open sub):

As expected, it is obfuscated, but we can still recognize some strings that look like BASE64. If we would manually concatenate them in the right order and decode, we would recover the payload. Fortunately, for this sample, there is an easier way by using an open-source VBA emulator: vipermonkey.

The VBA emulator encounters some errors during the emulation, fortunately for us, while outputing the concatenated base64 payload:

We can pipe this into base64dump to decode the base64 code (since vipermonkey outputs the base64 string as error in stderr, I combine stderr and stdout with 2>&1 to pipe it into base64dump.py):

The decoded base64 payload starts with powershell, so we are on the right track. Let's dump the full decoded payload:

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


Published: 2017-07-27

TinyPot, My Small Honeypot

Running honeypots is always interesting to get an overview of what’s happening on the Internet in terms of scanners or new threats. Honeypots are useful not only in the Wild but also on your internal networks. There are plenty of solutions to deploy honeypots with more or less nice features (depending on the chosen solution). They are plenty of honeypots[1] which can simulate specific services or even mimic a complete file system, computer or specific hardware.

That’s cool but often such honeypots require a lot of dependencies (Python/Perl modules) or must be compiled. Sometimes, you just need to collect basic data to understand who’s knocking on your door. I was looking for a quick & dirty solution that does not require the installation of many packages or extra-tools. What are my basic requirements:

  • Run on any Linux distribution
  • Accept connections on ANY port
  • Collect basic protocol details
  • Log everything (of course!)

The first step is to capture the traffic on any TCP ports. To achieve this, we can use iptables to redirect any incoming connection to a specific port:

# iptables -t nat -A PREROUTING -p tcp --dport 1:65534 -j REDIRECT --to-ports 10000

Note: I limited the range to port 65534 to allow binding my SSH daemon to port 65535 (if you need to access the honeypot remotely).

The next step is to accept and establish a connection on any port (at least the TCP handshake). netcat[2] is the perfect tool for this and is usually installed by default with many Linux distribution. Let’s bind it to our collection port 10000 (see above) and log all the junk received:

# netcat -l -k -p 10000 | tee -a /tmp/netcat.log

Finally, a full packet capture is always nice to have, let’s collect all the traffic hitting our honeypot except the SSH management port:

# tcpdump -i eth0 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65534

Finally, we can put all the commands in a single script tinypot.sh. I'm using the "screen" command (also available in most distributions) to detach the tools from the console and to keep an eye on them later.

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 1:65534 -j REDIRECT --to-ports 10000
/usr/bin/screen -S netcat -d -m /bin/netcat -l -k -p 10000 | tee -a /tmp/netcat.log
/usr/bin/screen -S tcpdump -d -m /sbin/tcpdump -i eth0 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65534
echo TinyPot running, use "screen -r [netcat|tcpdump] to access tools"

Here is an example of data dumped by netcat:

We can see classic stuff like bots scanning for open proxies, SMB shares or searching for admin interfaces. What's next? Wireshark can be used to export statistics (menu "Statistics -> Conversations"). The generated CVS file once indexed in Splunk gives us the classic top-20:

Nothing fancy here and  I'm sure that it can be improved but TinyPot just does the work!

[1] https://github.com/paralax/awesome-honeypots
[2] https://nmap.org/ncat/

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


Published: 2017-07-26

Malspam pushing Emotet malware

2017-07-26 update:  After publishing this diary, we were contacted by several people who provided samples of the emails.  Screenshots of these emails have been added after my signature block.  Thanks to everyone who responded!


On Tuesday 2017-07-25, we were contacted by a reader through our contact page.  He sent us a Microsoft Word document, and he included the following message:

Received a typical phishing email pointing to the site: anduron.com/XXGX911533.

This links downloads a doc with an open document macro.  Interestingly, the macro was not encrypted.  Understanding the payload however is outside my skill set...

I examined the Word document and found it's a downloader for Emotet malware.  We never obtained a copy of the associated email.  Emotet is generally known as a banking Trojan, although it's also been described as a downloader with worm-like propagation.  Emotet is commonly distributed through malicious spam (malspam).

This diary reviews my investigation of the anduron.com URL and associated Word document we received from the reader on Tuesday 2017-07-25.

Shown above:  Chain of events for malspam pushing Emotet.

The Word document

The Word document is a typical macro-based downloader.  You enable Word macros after opening the document, and the macro code attempts to download and run malware.  Without enabling macros, you can view the malicious macro code from this Word document as shown below.

Shown above:  The malicious Word document asks if you want to enable macros.

Shown above:  Menu path to view the macro code.

Shown above:  The macro name is Document_Open.  Click "Edit" to view it.

Shown above:  The highly-obfuscated macro code is shown in Microsoft's Visual Basic editor.

Enabling macros caused the code to download a Windows executable (an Emotet binary) to the user's AppData\Local\Temp directory with a file name of 5 random digits and an .exe file extension.  This file executed and promptly deleted itself from the AppData\Local\Temp directory.  Before that, the malware copied itself to the user's AppData\Local\Microsoft\Windows directory as shedulecart.exe, and it updated the Windows registry to make itself persistent after a reboot.

Shown above:  Downloaded Windows executable (the Emotet binary).

Shown above:  Emotet binary made persistent on an infected Windows host.

Infection traffic

At this point, I didn't know what the malware was, so I reviewed the network traffic.  The URL to download the malicious document was still active, so I retrieved the Word document from anduron.com and infected a Windows host.  I wasn't familiar with the traffic, but I had monitored the infection with a Security Onion host running Suricata and the EmergingThreats Pro ruleset.  Using Sguil to review the events, I saw some hits on Emotet.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Alerts on the infection traffic in Security Onion with 8 Emotet events.

Shown above:  Escalate the Emotet events, and you'll see all the destination IPs. 

Indicators of Compromise (IOCs)

Payload Security's reverse.it sandbox analysis (same as hybrid-analysis.com) of the Word document shows 5 other URLs from the macro that download the same Emotet malware binary.  Payload Security's analysis also shows a list of 35 different URLs, presumably links from the malspam that download the same malicious Word document.

Shown above:  Other URLs to download Emotet noted from analysis of the Word macro.

Shown above:  Some additional URLs leading to the Word document.

The following are IOCs associated with malspam pushing Emotet malware on 2017-07-25:

Word document from links in the emails:

  • SHA256 hash:  6cad070bd1a37291b207895bbb51b975fa07b4ad2f05fb9a1ee15fb7441d600e
  • File size:  120,320 bytes
  • Links:  VirusTotal , reverse.it , malwr.com

Emotet binary downloaded by the Word macro:

  • SHA256 hash:  48f3c89ea2f1e3190ae00f7ac7243ddb752364c076b40afc049424c6a0f75443
  • File size:  176,128 bytes
  • Links:  VirusTotal , reverse.it , malwr.com

Links from the malspam to download the word document:

  • anduron.com - GET /XXGX911533/
  • approxim.com - GET /RHKA318298/
  • beckiyore.com - GET /ECPT315356/
  • bluedevils.be - GET /joomla/language/MZQO136516/
  • boscoandzoe.com - GET /ICHY890603/
  • bravasav.net - GET /ENOD612941/
  • cohenbenefits.com - GET /office/custom/SIPQ546465/
  • cpkapability.com - GET /UKSV614228/
  • danielmerchen.com - GET /TZEX247131/
  • denbar.com.au - GET /UOOP149434/
  • driften.org - GET /MCGF919307/
  • euphorianet.com - GET /YQCB092598/
  • event-weekend.ch - GET /ICOT371647/
  • falconbilgisayar.com - GET /RIOC718921/
  • flexlogic.nl - GET /QBUP530634
  • ftpgmbh.ch - GET /VYXG951483 
  • getoutofthecube.com - GET /JZST874751/
  • goldencoyote.com - GET /ALLS580885/
  • hcsnet.com.br - GET /FDED220303/
  • hobbycoinexchange.com - GET /ssfm/ESIF185658/
  • homexxl.de - GET /images/articles/EYQD907375/
  • huiwei19.com - GET /YJPW400437/
  • intedyn.com - GET /PZFY613518/
  • interwatts.com - GET /jcgestio/report/XIND162748/
  • kovalantie.fi - GET /XOON622261/
  • lincolngroup.biz - GET /BCCC068652/
  • livablecity.org - GET /DFKR972152/
  • mariamartinezportfolio.com - GET /XLJF149270/
  • merz.com.ar - GET /POXE116744/
  • molodin.org - GET /YFUF766014 
  • phvfd221.org - GET /CVQP360485/
  • procebe.com - GET /MPKL050560/
  • prodevinc.com - GET /RPJI648495/
  • rehaunion.de - GET /GDOG943694/
  • rekonaudio.com - GET /TGVY210050/

Macros from the Word document downloading the Emotet binary:

  • ais-fo.fr - GET /kukajweln/
  • blushphotoandfilm.com - GET /ckgawd/
  • bugbbq.com - GET /awhwgra/
  • dzynr.com - GET /ev/
  • netoip.com - GET /rwibpm/

HTTP post-infection traffic:

  • port 8080 - - POST /
  • port 8080 - - POST /
  • port 443 - - POST /

Post-infection attempted TCP connections, but no response (or RST) from the server:

  • port 443
  • port 8080
  • port 8080
  • port 443
  • port 443

Final words

As mentioned earlier, we didn't obtain a copy of the email with a link to the Word document.  Last month, a similar report on Emotet was published on malwarebreakdown.com, but it was also without an example of the associated emails.  If anyone has an example of these emails, feel free to share a copy through our contact page.

If your organization follows best security practices, your risk of infection is minimal.  However, we continue to see reports on this type of malspam on a near-daily basis.  That implies the criminals behind it are at least somewhat successful.

Pcap and malware samples for today's diary can be found here.

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

2017-07-26 update:  Anther reader contacted us with additional info on yesterday's Emotet malspam.  From the reader:

We saw this campaign as well yesterday.  The senders were all random, but they seem to rely on the "from" field to lend increased credibility.  There were two emotet campaigns with the one before this using other employee names that work in the same department as the recipient.  This campaign used a very convincing "bill" from AT&T, with the exception of the odd characters for AT&T in the body everything else seemed pretty convincing.


AT&T Bill Message
AT&T Monthly Statement
AT&T Customer
AT&T Statement
AT&T Automatic Billing Message
AT&T Customer Support Notification

Shown above:  Screenshot from one of the emails pushing Emotet malware.

2017-07-26 additional update:  Thanks to everyone who emailed contacted us with examples of malspam they found pushing Emotet.  See additional screenshots below:


Published: 2017-07-24

Trends Over Time

The business goal of Critical Security Control #9: Limitation and Control of Network Ports is “To limit potential vulnerabilities on systems by limiting unauthorized ports, protocols, & services on systems”. Sounds totally reasonable and something everyone should systematically monitor in their respective environments. How can this be accomplished, especially if this has not been an area of focus?


One strategy is capturing data about the network traffic in order to develop and maintain a rolling trend over time. A specific area to focus on is the Top Ports that were targeted on a daily basis. This data will readily highlight trends that can be investigated and help detect changes in traffic that may or many not be “normal". This daily baseline, when added to the last 30 days worth of the same data can easily be to highlight and compare traffic patterns. What could this look like for your network? As a practical example, below is a visualization of data that has been sent to the Internet Storm Center.