Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: Internet Storm Center - Internet Security | DShield Internet Storm Center

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Brazilian malspam sends Autoit-based malware

Published: 2017-02-18
Last Updated: 2017-02-18 03:23:19 UTC
by Brad Duncan (Version: 1)
1 comment(s)


Nothing really exciting this week, so let's review malicious spam (malspam) we received at our ISC handers email distro. The message is in Portuguese, and it claims to be from Detran.  Detran is an abbreviation for Departamento Estadual de Trânsito, an institution responsible for supervision of ground vehicles in Brazil.  The malspam concerns a ticket for running a red light, but the message is ultimately a vehicle for transporting AutoIt-based malware.

Shown above:  Brazilian malspam disguised as a message from Detran.

I received a zip file from a link in the email, and it easily infected a Windows computer on Friday 2017-02-17.  Let's take a closer look at this infection.

Shown above:  Flowchart for the infection.


Original message text in Portuguese:

Subject: Detran "Prezado(a) Condutor(a) Informe Detran (Notificacao *2 via Multa Transito*) - ***** (58825)

Infração de Trânsito, Notificação da Autuação.

A multa por avançar o farol vermelho, está descrita no artigo 208 do Código de Trânsito Brasileiro.

Ja pode Baixar o Aplicativo do Sistema de Notificação Eletrônica (SNE DETRAN), que permite receber as notificações a qualquer momento e lugar, oferecendo ainda desconto de 40% no valor da multa para pagamento até a data de vencimento da mesma.

Detran 2017 - Todos os direitos reservados - Aspectos Legais e Responsabilidades.

Google translation:

Subject: Detran "Dear Conductor Report Detran (Notification * 2 via Fine Traffic *) - ***** (58825)

Traffic Infringement, Notification of the Assessment.

The fine for advancing the red light is described in article 208 of the Brazilian Traffic Code.

You can download the application of the Electronic Notification System (SNE DETRAN), which allows you to receive notifications at any time and place, also offering a 40% discount on the fine for payment until the expiration date of the same.

Detran 2017 - All rights reserved - Legal Aspects and Responsibilities.

The download

Clicking on the link presented a zip archive.  I tried several times and saw at least seven different file names for the zip archive.  They all contained the a .js file inside with the same file hash, regardless of the actual file name.

Shown above:  What I got after clicking the link.

Shown above:  The zip archive contained a .js file.

I emailed to notify them of the URLs I found.  The following HTTPS URLs over TCP port 443 provided the initial zip archive:

  • - GET /s/m9vu2mwquasfhr3/
  • - GET /s/7dwinqclpdxt6q8/
  • - GET /s/b9u8rdqigk5ycnr/
  • - GET /s/lpbxa75s9vutq6r/
  • - GET /s/d3k0u4ircpyt861/
  • - GET /s/7ann3m0bno2pe6x/
  • - GET /s/e8yqpvl8wb0jpgt/


Because the Dropbox URLs were sent encrypted over HTTPS, I didn't see any alerts when downloading the zip archive.  After opening the zip archive and double-clicking the enclosed .js file, my Windows computer became infected.

Shown above:  Traffic of the infection filtered in Wireshark.

The follow-up malware was sent as an 7.9 MB ASCII text file that represented hexadecimal characters for an executable binary.

Shown above:  The follow-up malware sent as ASCII text.

The 7.9 MB of ASCII text was saved to the Windows host as C:\Users[username]\AppData\Local\TaJKgtThuk\  That fake .zip file was still ASCII text.  It was then converted to a 3.97 MB binary.  The binary was as an .exe saved to the local host, and it was made resident through a Windows registry update.

Shown above:  Follow-up malware saved to the host and made persistent.

The ASCII text (that fake zip file) was deleted during the infection process.  However, I grabbed a copy before it deleted itself, so I could double-check.  I took that 7.9 MB of ASCII text, copied it into a hex editor, and saved the result as an .exe file.  It had the same file hash as the .exe from the infected Windows host.

I only saw one alert on the traffic.  It was an ETPRO rule for Autoit.LOX checkin.  The alert is an older rule that originally appeared back in August 2014 [1].

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

Indicators of Compromise (IOCs)

The following are malicious URLs associated with this infection:

  • port 80 - - GET /Multa/
  • port 80 - - GET /Multa/Multa.php?ass=[long string of characters]
  • port 80 - - GET /manhazinha/cedo/osso.dat
  • port 80 - - GET /manhazinha/cedo/
  • port 80 - - GET /maisvc/notify.php

The extracted .js file:

  • SHA256 hash:  ed8d7c4201c4e2a670e3418242cc02f9509e02e2e580f1b77a9ccb6e0455dc80
  • File name:  Infracao[Multa].js  (and various other file names)
  • File description:  .js file extracted from zip archives associated with this malspam

The followup .exe malware:

  • SHA256 hash:  da9172f1e1d81c2a9300a5028bc419ea8d43518bcdb61b022180646aa2539c68
  • File location:  C:\Users\[username]\AppData\Local\TaJKgtThuk\KmNgRErtY6.exe
  • File description:  Follow-up malware downloaded by .js file

Final words

This malspam wasn't well-targeted.  But our ISC handler email distro occasionally receives this type of malspam, so I like to share when I can.  As usual, my lab environment is designed to be vulnerable to such malware.  By the time you read this, some of the infrastructure for this campaign may already be blocked or taken down.

I don't think many people will become infected by this malspam, but it's always interesting to see what the criminals are putting out there.

From what I understand, AutoIt is a scripting language that's not inherently malicious.  However, it provides a convenient environment that criminals can use to quickly develop malware.  A VirusTotal search for comments tagged #autoit reveals several recent examples of AutoIt-based malware.  A Google search for "autoit malware" returns several articles on the subject.

Pcap and malware for this diary can be found here.

Brad Duncan
brad [at]



1 comment(s)

RTRBK - Router / Switch / Firewall Backups in PowerShell (tool drop)

Published: 2017-02-17
Last Updated: 2017-02-18 01:47:42 UTC
by Rob VandenBrink (Version: 1)
7 comment(s)

Have you ever been asked for the config of a router or switch you (or someone else) put in so long ago you didn’t remember that device was there?  So long ago that the layer of dust inside that switch is probably why the fan stopped spinning and melted it?

Yup, me too.  So when it comes time to rebuild it, you go to that customer’s CATTOOLS directory (or configuration manager, or whatever backup tool that they have), and find out that:

  • They retired that VM and didn’t tell you
  • They let the license lapse
  • They forgot about that device when they set up their backups
  • They “upgraded” the backup tool, but then never started the service?
  • They installed something else that broke the backup service

Yes, “stuff” happens, and backups sometimes don’t, for lots of reasons.  This got me to thinking that what I really want (this week) is a PowerShell backup utility for an arbitrary list of network gear at any given client. This beats my previous method of snarfing up cattools directories (when I remember) or backing things up manually whenever I change them (and when I remember) - you see the recurring problem in that method?

Why PowerShell?  There’s so many other approaches with Python, Expect, Ansible and so on (all of which can do way more than just backups) – why build something new in PowerShell?  Mostly because I can run that on any customer Windows machine and expect it to work, without installing anything the client might have a problem with.  Plus I really wanted to play with Carlos Perez’s Posh-SSH code ( )

So, first, what to back up?  What most of my clients run is some subset of:

  • Cisco IOS
  • Cisco Nexus
  • Cisco ASA
  • HP Procurve
  • HP Comware
  • Palo Alto Networks Firewall

Seems like a reasonable starter list?  OK, now how to back them up?  Again, with the theme of “don’t install anything, don’t change the host you’re running on, and (to quote Ed Skoudis), to 'live off the land' " – this is all in SSH, and all in PowerShell.  Essentially for each device: login, do a “show running-config” (or equivalent for that platform), capture the output and save it to ASCII.  The credentials never get saved, but you can likely scrape them out of memory if you wanted to make a point.

The input file looks like this (a fictional is shown):



The code reads the file as a CSV, so populates a “devices” variable with properties of:, devices.IP  (which can also be a CN or FQDN, it just needs to resolve), and devices.devtype

The 7 device types are covered in the file above.  Note that the Palo Alto is in there twice, devicetype 6 for “set” commands - the commands to rebuild the box, devicetype 7 for XML output - which you would use for a full backup, or if you wanted to manipulate that file in another app (stay tuned for that).

Running the Code:

If you run the script with no arguments, you of course get help text:


Running it “for real”, it uses get-credential to collect the userid/password for the devices in the input file.  I could save these out, but I’d really rather not leave credentials like this laying around in a file.


The script then motors through the list, device by device.  It takes a few minutes, and I could likely make it faster, but I’d rather it be reliable (and done) than a never ending project that never quite works – I really did write this to collect those backups!

Error checking?  Umm, not so much, or better stated "not yet".  If you specify a device that doesn’t exist, or if the credentials don’t match, it’ll error out on that device and just go on to the next one in the list.  That’d be a good thing for me to get around to fixing (sometime soon maybe)..

The code itself is on my github ->

Where do I go from here?  Give the code a spin,and you tell me!  If you’ve got devices you’d like to see added, or other features you’d like to see, please use our comment form to let me know!

Rob VandenBrink

7 comment(s)

AVM Private Key Leak Puts Cable Modems Worldwide At Risk

Published: 2017-02-16
Last Updated: 2017-02-18 01:47:26 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

In November, Heise, a german technology news publisher, broke a story that AVM cable modems included not only the manufacturer's certificate authority certificate as part of the firmware but also the corresponding private key [1]. The news didn't get a lot of attention back then. AVM is the maker of "Fritz!Box" routers and modems which are almost exclusively sold to german speaking countries only. When I read the news initially, I also considered it only a risk to cable modem's in the area AVM operates. But it turns out, that the leak may have larger repercussions, as pointed out in a note published by CableLabs, the organization in charge of the DOCSIS cable modem standard. A reader forwarded us this note:

"All operators globally may be exposed to a security issue related to the EuroDOCSIS PKI and need to take action. AVM cable modems were shipped with the device private key and the AVM CA private key in the firmware which is now publicly exposed. As a result illegitimate cable modems can be created which could cause network problems such as theft of service. Major CMTS vendors ship their product with both the DOCSIS and EuroDOCSIS Root CA installed as a trust anchor in their CMTSs. As a result, CableLabs recommends all operators blacklist (untrust) the compromised AVM CA in their CMTSs, regardless of whether or not they have AVM equipment deployed in their network or they actively use the EuroDOCSIS Root CA." [2]

So what does this all mean? DOCSIS is the standard cable modem operators adopted to allow manufacturers to create interoperable equipment. EuroDOCSIS is the European version of this standard. I will refer to both standards as "DOCSIS" going forward. 

DOCSIS requires that each cable modem contains a unique certificate to authenticate the cable modem to the provider. The certificate is signed by the manufacturers CA, which in turn is signed using the DOCSIS CA. Cable modem operators trust cable modems that can present a properly signed certificate. 

Due to AVM's mistake, the private key for AVM's is now public, and anybody could create new certificates that will be trusted by cable modem ISPs that trust the EuroDOCSIS CA. This could, for example, allow someone to spoof a cable modem owned by a different provider, or create a cable modem with rogue firmware that will not obey configurations sent by the ISP.

Heise in a follow-up story stated that the key was already used in the wild to sign fake certificates [3]. The fake certificates were apparently used well before Heise broke the story.

As an end user, there is nothing you can do. As outlined by the note from CableLabs, ISPs will have to distrust the AVM CA. This could potentially cut service for users who use modems that provide certificates derived from the AVM CA. But most cable modem ISPs will not allow any modem to connect to their network, but only a subset of DOCSIS certified modems that are compatible with the particular head-end equipment used by the ISP. So the impact is likely small. AVM does not distribute cable-modems outside Europe as far as I know, but I may be wrong.

[1] (German Only)
[2] (Login Required)
[3] (German Only)

Johannes B. Ullrich, Ph.D.

0 comment(s)

OpenSSL 1.1.0e Update: No need to panic #openssl

Published: 2017-02-16
Last Updated: 2017-02-18 01:47:16 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

OpenSSL released an update for OpenSSL 1.1.0. The latest version is now OpenSSL 1.1.0e. OpenSSL 1.0.2 is not affected.

The vulnerability, CVE 2017-3733 can lead to a crash in either clients or servers. In order to trigger the vulnerability, an attacker would first negotiate an SSL connection without the "Encrypt-Then-Mac" extension. Later, the attacker would use the extension during a renegotiation handshake. The vulnerability is rated as "High" by OpenSSL, below the maximum level of "Critical".

I recommend you wait for your respective vendor/Linux distribution to provide an updated OpenSSL library, which should be available shortly if it isn't already available. Not too many systems are using OpenSSL 1.1.0. Many current Linux distribution use the non-vulnerable 1.0.2 branch. So no need to panic.

Johannes B. Ullrich, Ph.D.

0 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

RTRBK - Router / Switch / Firewall Backups in PowerShell (tool drop)
Feb 18th 2017
2 days ago by Rob VandenBrink (6 comments)

AVM Private Key Leak Puts Cable Modems Worldwide At Risk
Feb 18th 2017
2 days ago by Johannes (0 comments)

OpenSSL 1.1.0e Update: No need to panic #openssl
Feb 18th 2017
2 days ago by Johannes (0 comments)

Microsoft February Patch Tuesday Now Rolled into March Update
Feb 18th 2017
2 days ago by Johannes (4 comments)

How was your stay at the Hotel La Playa?
Feb 18th 2017
2 days ago by Xme (4 comments)

Microsoft Patch Tuesday Delayed
Feb 18th 2017
2 days ago by Johannes (7 comments)

Stuff I Learned Decrypting
Feb 18th 2017
2 days ago by Rob VandenBrink (10 comments)

Do You Use VirusTotal? Give PacketTotal a Spin!
Feb 18th 2017
2 days ago by Rob VandenBrink (2 comments)

View All Diaries →

Latest Discussions

Platform Markings on Headlines
created Feb 9th 2017
1 week ago by Anonymous (0 replies)

Automation Software, Consultant or Both?
created Jan 25th 2017
3 weeks ago by Anonymous (1 reply)

Importance of File Integrity Monitoring software
created Jan 18th 2017
1 month ago by Promisec (0 replies)

New Incident Response/Forensics tool : srum-dump.exe
created Jan 12th 2017
1 month ago by Mark (1 reply)

How to make the social media accounts safe from hacking?
created Jan 6th 2017
1 month ago by Brad4333 (5 replies)

View All Forums →

Latest News

View All News →

Top Diaries DDoS Attack
Oct 21st 2016
4 months ago by Johannes (9 comments)

Microsoft Patch Tuesday Delayed
Feb 18th 2017
2 days ago by Johannes (7 comments)

Critical Vulnerability in Cisco WebEx Chrome Plugin
Jan 24th 2017
3 weeks ago by Johannes (10 comments)

Port 7547 SOAP Remote Code Execution Attack Against DSL Modems
Nov 29th 2016
2 months ago by Johannes (21 comments)

Quick Analysis of Data Left Available by Attackers
Feb 1st 2017
2 weeks ago by Xme (2 comments)