We are about two months past the 5-year anniversary of WannaCry outbreak[1] and about a week past the 5-year anniversary of NotPetya outbreak[2]. Since both WannaCry and NotPetya used the EternalBlue[3] exploit in order to spread, I thought that it might be interesting to take a look at how many internet-facing systems still remain vulnerable to it.
As I explained in my diary entry "7-Zip & MoW", the MoW on a ZIP file can be set to be propagated by 7-Zip to Office files only (propagation setting "For Office files").
My tests showed that this was based on the file extension of the Office file. As I received some questions about this, I took a look at the 7-Zip source code.
Here is the code that determines whether to write a Zone.Identifier ADS or not depending on the setting for Zone.Identifier propagation:
It uses function FindExt2 to check if the extension of the extracted file (_diskFilePath) matches a list of predefined extensions (kOfficeExtensions).
This is the predefined list kOfficeExtensions:
Notice that the extension RTF is not in this list.
And while I was browsing the source code, I also took a look at the possible registry values for this setting:
7-Zip deletes registry values if they are not used (-1).
That is why you will find values 1 (all files) and 2 (Office files only) only in the registry.
Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Version 22.0 of 7-Zip introduces support for the propagation of the Mark-of-Web. This is an Alternate Data Stream with name Zone.Identifier that is added by browsers and email clients on Windows system with NTFS disks, to mark that a file was downloaded from and untrusted source ("The Internet").
Original release date: June 30, 2022
Actions to take today to mitigate cyber threats from ransomware:
• Prioritize remediating known exploited vulnerabilities.
• Train users to recognize and report phishing attempts.
• Enable and enforce multifactor authentication.
Note: this joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.
The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), the Department of the Treasury, and the Financial Crimes Enforcement Network (FinCEN) are releasing this CSA to provide information on MedusaLocker ransomware. Observed as recently as May 2022, MedusaLocker actors predominantly rely on vulnerabilities in Remote Desktop Protocol (RDP) to access victims’ networks. The MedusaLocker actors encrypt the victim’s data and leave a ransom note with communication instructions in every folder containing an encrypted file. The note directs victims to provide ransomware payments to a specific Bitcoin wallet address. MedusaLocker appears to operate as a Ransomware-as-a-Service (RaaS) model based on the observed split of ransom payments. Typical RaaS models involve the ransomware developer and various affiliates that deploy the ransomware on victim systems. MedusaLocker ransomware payments appear to be consistently split between the affiliate, who receives 55 to 60 percent of the ransom; and the developer, who receives the remainder.
Download the PDF version of this report: pdf, 633 kb
MedusaLocker ransomware actors most often gain access to victim devices through vulnerable Remote Desktop Protocol (RDP) configurations [T1133]. Actors also frequently use email phishing and spam email campaigns—directly attaching the ransomware to the email—as initial intrusion vectors [T1566].
MedusaLocker ransomware uses a batch file to execute PowerShell script invoke-ReflectivePEInjection [T1059.001]. This script propagates MedusaLocker throughout the network by editing the EnableLinkedConnections value within the infected machine’s registry, which then allows the infected machine to detect attached hosts and networks via Internet Control Message Protocol (ICMP) and to detect shared storage via Server Message Block (SMB) Protocol.
MedusaLocker then:
LanmanWorkstation service, which allows registry edits to take effect. svhost.exe or svhostt.exe) to the %APPDATA%Roaming directory and scheduling a task to run the ransomware every 15 minutes. MedusaLocker actors place a ransom note into every folder containing a file with the victim’s encrypted data. The note outlines how to communicate with the MedusaLocker actors, typically providing victims one or more email address at which the actors can be reached. The size of MedusaLocker ransom demands appears to vary depending on the victim’s financial status as perceived by the actors.
| Encrypted File Extensions | |||
|---|---|---|---|
| .1btc | .matlock20 | .marlock02 | .readinstructions |
| .bec | .mylock | .jpz.nz | .marlock11 |
| .cn | .NET1 | .key1 | .fileslocked |
| .datalock | .NZ | .lock | .lockfilesUS |
| .deadfilesgr | .tyco | .lockdata7 | .rs |
| .faratak | .uslockhh | .lockfiles | .tyco |
| .fileslock | .zoomzoom | .perfection | .uslockhh |
| .marlock13 | n.exe | .Readinstruction | .marlock08 |
| .marlock25 | nt_lock20 | .READINSTRUCTION | |
| .marlock6 | .marlock01 | .ReadInstructions | |
| Ransom Note File Names | |
|---|---|
| how_to_ recover_data.html | how_to_recover_data.html.marlock01 |
| instructions.html | READINSTRUCTION.html |
| !!!HOW_TO_DECRYPT!!! | How_to_recovery.txt |
| readinstructions.html | readme_to_recover_files |
| recovery_instructions.html | HOW_TO_RECOVER_DATA.html |
| recovery_instruction.html | |
| Payment Wallets |
|---|
| 14oxnsSc1LZ5M2cPZeQ9rFnXqEvPCnZikc |
| 1DRxUFhvJjGUdojCzMWSLmwx7Qxn79XbJq |
| 18wRbb94CjyTGkUp32ZM7krCYCB9MXUq42 |
| 1AbRxRfP6yHePpi7jmDZkS4Mfpm1ZiatH5 |
| 1Edcufenw1BB4ni9UadJpQh9LVx9JGtKpP |
| 1DyMbw6R9PbJqfUSDcK5729xQ57yJrE8BC |
| 184ZcAoxkvimvVZaj8jZFujC7EwR3BKWvf |
| 14oH2h12LvQ7BYBufcrY5vfKoCq2hTPoev |
| bc1qy34v0zv6wu0cugea5xjlxagsfwgunwkzc0xcjj |
| bc1q9jg45a039tn83jk2vhdpranty2y8tnpnrk9k5q |
| bc1qz3lmcw4k58n79wpzm550r5pkzxc2h8rwmmu6xm |
| 1AereQUh8yjNPs9Wzeg1Le47dsqC8NNaNM |
| 1DeNHM2eTqHp5AszTsUiS4WDHWkGc5UxHf |
| 1HEDP3c3zPwiqUaYuWZ8gBFdAQQSa6sMGw |
| 1HdgQM9bjX7u7vWJnfErY4MWGBQJi5mVWV |
| 1nycdn9ebxht4tpspu4ehpjz9ghxlzipll |
| 12xd6KrWVtgHEJHKPEfXwMVWuFK4k1FCUF |
| 1HZHhdJ6VdwBLCFhdu7kDVZN9pb3BWeUED |
| 1PormUgPR72yv2FRKSVY27U4ekWMKobWjg |
| 14cATAzXwD7CQf35n8Ea5pKJPfhM6jEHak |
| 1PopeZ4LNLanisswLndAJB1QntTF8hpLsD |
| Email Addresses | |
|---|---|
| willyhill1960@tutanota[.]com | unlockfile@cock[.]li |
| zlo@keem[.]ne | unlockmeplease@airmail[.]cc |
| zlo@keemail[.]me | unlockmeplease@protonmail[.]com |
| zlo@tfwno[.]gf | willyhill1960@protonmail[.]com |
| support@ypsotecs[.]com | support@imfoodst[.]com |
| Email Addresses | |
|---|---|
| traceytevin@protonmail[.]com | support@itwgset[.]com |
| unlock_file@aol[.]com | support@novibmaker[.]com |
| unlock_file@outlook[.]com | support@securycasts[.]com |
| support@exoprints[.]com | rewmiller-1974@protonmail[.]com |
| support@exorints[.]com | rpd@keemail[.]me |
| support@fanbridges[.]com | soterissylla@wyseil[.]com |
| support@faneridges[.]com | support@careersill[.]com |
| perfection@bestkoronavirus[.]com | karloskolorado@tutanota[.]com |
| pool1256@tutanota[.]com | kevynchaz@protonmail[.]com |
| rapid@aaathats3as[.]com | korona@bestkoronavirus[.]com |
| rescuer@tutanota[.]com | lockPerfection@gmail[.]com |
| ithelp01@decorous[.]cyou | lockperfection@gmail[.]com |
| ithelp01@wholeness[.]business | mulierfagus@rdhos[.]com |
| ithelp02@decorous[.]cyou | [rescuer]@cock[.]li |
| ithelp02@wholness[.]business | 107btc@protonmail[.]com |
| ithelpresotre@outlook[.]com | 33btc@protonmail[.]com |
| cmd@jitjat[.]org | 777decoder777@protonmail[.]com |
| coronaviryz@gmail[.]com | 777decoder777@tfwno[.]gf |
| dec_helper@dremno[.]com | andrewmiller-1974@protonmail[.]com |
| dec_helper@excic[.]com | angelomartin-1980@protonmail[.]com |
| dec_restore@prontonmail[.]com | ballioverus@quocor[.]com |
| dec_restore1@outlook[.]com | beacon@jitjat[.]org |
| bitcoin@sitesoutheat[.]com | beacon@msgsafe[.]io |
| briansalgado@protonmail[.]com | best666decoder@tutanota[.]com |
| bugervongir@outlook[.]com | bitcoin@mobtouches[.]com |
| best666decoder@protonmail[.]com | encrypt2020@outlook[.]com |
| decoder83540@cock[.]li | fast-help@inbox[.]lv |
| decra2019@gmail[.]com | fuc_ktheworld1448@outlook[.]com |
| diniaminius@winrof[.]com | fucktheworld1448@cock[.]li |
| dirhelp@keemail[.]me | gartaganisstuffback@gmail[.]com |
| Email Addresses | |
|---|---|
| emaila.elaich@iav.ac[.]ma | gavingonzalez@protonmail[.]com |
| emd@jitjat[.]org | gsupp@onionmail[.]org |
| encrypt2020@cock[.]li | gsupp@techmail[.]info |
| best666decoder@protonmail[.]com | helper@atacdi[.]com |
| ithelp@decorous[.]cyou | helper@buildingwin[.]com |
| ithelp@decorous[.]cyoum | helprestore@outlook[.]com |
| ithelp@wholeness[.]business | helptorestore@outlook[.]com |
| TOR Addresses |
|---|
| http://gvlay6u4g53rxdi5.onion/6-iSm1B1Ehljh8HYuXGym4Xyu1WdwsR2Av-6tXiw1BImsqoLh7pd207Rl6XYoln7sId |
| http://gvlay6u4g53rxdi5.onion/8-grp514hncgblilsjtd32hg6jtbyhlocr5pqjswxfgf2oragnl3pqno6fkqcimqin |
| http://gvlay6y4g53rxdi5.onion/21-8P4ZLCsMETPaLw9MkSlXJsNZWdHe0rxjt-XmBgZLWlm5ULGFCOJFuVdEymmxysofwu |
| http://gvlay6u4g53rxdi5.onion/2l-8P4ZLCsMTPaLw9MkSlXJsNZWdHeOrxjtE9lck1MuXPYo29daQys6gomZZXUImN7Z |
| http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-DcaE9HeHywqSHvdcIwOndCS4PuWASX8g |
| http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-kB4rQXGKyxGiLyw7YDsMKSBjyfdwcyxo |
| http://gvlay6u4g53rxdi5.onion/21-8P4ZLCsMTPaLw9MkSlXJsNZWdHe0rxjt-bET6JbB9vEMZ7qYBPqUMCxOQExFx4iOi |
| http://gvlay6u4g53rxdi5. onion/8-MO0Q7O97Hgxvm1YbD7OMnimImZJXEWaG-RbH4TvdwVTGQB3X6VOUOP3lgO6YOJEOW |
| http://gvlay6u4g53rxdi5.onion/8-gRp514hncgb1i1sjtD32hG6jTbUh1ocR-Uola2Fo30KTJvZX0otYZgTh5txmKwUNe |
| http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-OWQwD1w1Td7hY7IGUUjxmHMoFSQW6blg |
| http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-uGHwkkWCoUtBbZWN50sSS4Ds8RABkrKy |
| http://gvlay6u4g53rxdi5.onion/21-E6UQFCEuCn4KvtAh4TonRTpyHqFo6F6L-Tj3PRnQlpHc9OftRVDGAWUulvE80yZbc |
| http://gvlay6u4g53rxdi5.onion/8-Ww5sCBhsL8eM4PeAgsfgfa9lrqa81r31-tDQRZCAUe4164X532j9Ky16IBN9StWTH |
| http://gvlay6u4g53rxdi5.onion/21-wIq5kK9gGKiTmyups1U6fABj1VnXIYRB-I5xek6PG2EbWlPC7C1rXfsqJBlWlFFfY |
| qd7pcafncosqfqu3ha6fcx4h6sr7tzwagzpcdcnytiw3b6varaeqv5yd.onion |
| http://medusacegu2ufmc3kx2kkqicrlcxdettsjcenhjena6uannk5f4ffuyd.onion/leakdata/paigesmusic-leakdata-closed-part1 |
Disclaimer: Many of these observed IP addresses are several years old and have been historically linked to MedusaLocker ransomware. We recommend these IP addresses be investigated or vetted by organizations prior to taking action, such as blocking.
| IP Address | Last Observed |
|---|---|
| 195.123.246.138 | Nov-2021 |
| 138.124.186.221 | Nov-2021 |
| 159.223.0.9 | Nov-2021 |
| 45.146.164.141 | Nov-2021 |
| 185.220.101.35 | Nov-2021 |
| 185.220.100.249 | Sep-2021 |
| 50.80.219.149 | Sep-2021 |
| 185.220.101.146 | Sep-2021 |
| 185.220.101.252 | Sep-2021 |
| 179.60.150.97 | Sep-2021 |
| 84.38.189.52 | Sep-2021 |
| 94.232.43.63 | Jul-2021 |
| 108.11.30.103 | Apr-2021 |
| 194.61.55.94 | Apr-2021 |
| 198.50.233.202 | Apr-2021 |
| 40.92.90.105 | Jan-2021 |
| 188.68.216.23 | Dec-2020 |
| 87.251.75.71 | Dec-2020 |
| 196.240.57.20 | Oct-2020 |
| 198.0.198.5 | Aug-2020 |
| 194.5.220.122 | Mar-2020 |
| 194.5.250.124 | Mar-2020 |
| 194.5.220.124 | Mar-2020 |
| 104.210.72.161 | Nov-2019 |
MedusaLocker actors use the ATT&CK techniques listed in Table 1.
Table 1: MedusaLocker Actors ATT&CK Techniques for Enterprise
| Initial Access | ||
|---|---|---|
| Technique Title | ID | Use |
| External Remote Services | T1133 | MedusaLocker actors gained access to victim devices through vulnerable RDP configurations. |
| Phishing | T1566 | MedusaLocker actors used phishing and spearphishing to obtain access to victims’ networks. |
| Execution | ||
| Technique Title | ID | Use |
| Command and Scripting Interpreter: PowerShell |
T1059.001 |
MedusaLocker actors may abuse PowerShell commands and scripts for execution. |
| Defense Evasion | ||
| Technique Title | ID | Use |
| Impair Defenses: Safe Mode Boot |
T1562.009 |
MedusaLocker actors may abuse Windows safe mode to disable endpoint defenses. Safe mode starts up the Windows operating system with a limited set of drivers and services. |
| Impact | ||
| Technique Title | ID | Use |
| Data Encrypted for Impact | T1486 | MedusaLocker actors encrypt data on target systems or on large numbers of systems in a network to interrupt availability to system and network resources. |
| Inhibit System Recovery | T1490 | MedusaLocker actors may deny access to operating systems containing features that can help fix corrupted systems, such as backup catalog, volume shadow copies, and automatic repair. |
To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field-offices. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To report incidents and anomalous activity or to request incident response resources or technical assistance related to this threat, contact CISA at report@cisa.gov.
This product is provided subject to this Notification and this Privacy & Use policy.
Introduction
How do threat actors behind a Cobalt Strike server keep it running after its domain is taken down? If the server is not hosted through the domain registrar, it merely keeps running on the same IP address.
Today's diary is a case study where Cobalt Strike remained active on the same IP address at least one week after its domain was suspended.
Traffic Forensics
On Tuesday 2022-06-28, I generated a Qakbot infection in my lab and saw Cobalt Strike HTTPS traffic on 147.78.47[.]223 over TCP port 443 as shown below.
Shown above: Traffic from a Qakbot infection with Cobalt Strike on Tuesday 2022-06-28 filtered in Wireshark.
Examining the certificate in Wireshark reveals it's a Let's Encrypt certificate for moros[.]icu. Let's Encrypt is a legitimate free, automated, and open certificate authority (CA). While used by many valid websites, this service is commonly abused by threat actors, including those behind malicious Cobalt Strike activity.
Shown above: Reviewing certificate issuer data associated with Cobalt Strike traffic on 147.78.47[.]223 in Wireshark.
Investigating the Malicious Server
Viewing the certificate from 147.78.47[.]223 in a web browser reveals it was originally issued for moros[.]icu through Let's Encrypt on 2022-06-20 and is no longer valid for that IP.
Shown above: Connecting to the Cobalt Strike server using a web browser.
Shown above: Certificate data for moros[.]icu shown in a web browser.
The domain moros[.]icu was reported and suspended less than one day after it was registered through Namecheap, but its server was set up through a legitimate hosting provider at Flyservers. Kudos to @ian_kenefick and Namecheap for quickly taking action and suspending this malicious domain!
Shown above: Tweets showing moros[.]icu was suspended on 2022-06-21.
Shown above: My own confirmation that moros[.]icu no longer works.
Shown above: Whois lookup for 147.78.47[.]223 using whois.domaintools.com.
The certificate's validity did not matter for Cobalt Strike activity I found on Tuesday 2022-06-28. Since the traffic was generated by malware instead of a web browser, HTTPS still worked.
Flyservers has been a hosting provider since 2001, and it appears to be a legitimate company. I've emailed their abuse address to report the malicious server on 147.78.47[.]223.
Final Words
Threat actors continually abuse legitimate hosting providers and certificate authorities (CAs), presumably through fraudulent accounts. Both free and paid services are incredibly susceptible to criminal abuse. Even Cobalt Strike is a legitimate red team tool commonly abused by various threat actors.
Security professionals can quickly report abuse cases, and service providers can rapidly shut down individual violations. However, threat actors can easily recover, and malware-related servers will continue to be an issue for defenders everywhere.
This case study reveals how criminal activity can circumvent domain takedowns. It also illustrates how time-intensive the associated investigation and corrective actions can be.
Brad Duncan
brad [at] malware-traffic-analysis.net
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
HiBy is a brand of portable music players built around the Android operating system. Probably a bit comparable to the now-defunct iPod touch, the device does use a close to "stock" version of Android and adds its own "HiByMusic" application as a music player. The hardware includes a Snapdragon ARM CPU standard on Android devices and attempts to distinguish itself with DACs claimed to be better than those found in other devices.
The device offers a feature to load custom network radio station URLs via a "radio.txt" file. The file is a simple text file with a list of URLs. For example:
Radio Dismuke 1920s-30s pop/jazz, http://74.208.197.50:8020/stream.mp3
SomaFM: Heavyweight Reggae, http://ice2.somafm.com/reggae-256.mp3
SomaFM: Groove Salad, http://ice5.somafm.com/groovesalad-256.mp3
SomaFM: Groove Salad Classic, http://ice4.somafm.com/gsclassic-128.mp3
(sample of a radio.txt file found here: https://www.head-fi.org)
I was a bit surprised that we recently started seeing some scans looking for radio.txt files based on our "First Seen" report. The number of submissions is small. (see the URL History for radio.txt)
So the question is: why?
At least one more report is not linked to our data observing requests for radio.txt.
Any ideas about what's going on here?
—
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.
The first payload sent by a TLS client to a TLS server is a "Client Hello." It includes several parameters supported by the client, such as available cipher suites, to start negotiating a compatible set of TLS parameters with the server.
One particular option, the "Server Name Indication" (SNI), lists the hostname the client is looking for. The client hello is sent in the clear and has often been considered a privacy issue or, for some network defenders, the last straw to hold on to gain insight into TLS encrypted traffic.
Encrypted SNI (ESNI) was an initial solution to the privacy problem. As the name implies, it encrypts the SNI option in the client hello. The encryption uses a key communicated via DNS. You will first see a DNS lookup for a TXT record _esni.[domain name]. This TXT record will return the public key to encrypt the SNI option.
ESNI solves a significant part of the client hello privacy problem. But other client-hello options may be used to fingerprint clients. Encrypting the entire client hello message is the next obvious option. This idea, Encrypted Client Hello (ECH), is currently an IETF draft [ECH]. The encrypted client hello options are wrapped into an unencrypted "Client Hello Outer" that is used as a vessel to transport the encrypted blob. This blob will look like any other client hello option to a server not capable of ECH.
Instead of a TXT record to communicate the key, ECH uses new SVCB and HTTPS records. This record provides more flexibility to advertise different options and keys [HTTPSRR].
Despite these standards in the draft stage, browsers are adding support for them. For the most part, ESNI is considered "dead" at this point, and browsers actively support ECH, but it may not be enabled by default. One feature that may lead to SVCB and HTTPS records being more commonly used than similar protocols like DANE is that SVCB/HTTPS does not require DNSSEC. The client will be able to verify the authenticity of the server using the usual TLS certificates. The DNS messages remain unprotected. As pointed out in the IETF draft, a hostile resolve will be able to downgrade the DNS responses.
But back to the title: Is anybody using these fancy standards? I took a look at my DNS logs to see how many requests I am seeing (and how many of them result in answers):
DNS requests for HTTPS records are undoubtedly popular, with about one HTTPS request for every 4 A record requests. Also, about 20% of the responses to HTTPS queries include at least one answer. So this looks pretty good, but the answer section of the response will not provide an answer here. None of the answers included an HTTPS record. They exclusively include A or CNAME records, which is also perfectly legal.
And a little side note if you want to play with this: The "dig" utility, at least the version I used (9.16.1-Ubuntu), does not fully understand the HTTPS record type.
$ dig -t HTTPS example.com
;; Warning, ignoring invalid type HTTPS
This warning is easily overlooked. Instead, try:
$dig -t TYPE65 blog.cloudflare.com
…
;; ANSWER SECTION:
blog.cloudflare.com. 18 IN TYPE65 # 67 0001000001000C0268330568332D323902683200040008681229AEAC 40925200060020260647004400000000000000681229AE2606470044 00000000000000AC409252
…
To query HTTPS records.
But the short answer to the headline question: No. Clients try to use it, but servers are not yet supporting encrypted client hello. Know of any example sites using it? Any comments or other suggestions to improve the methodology? Please leave a comment.
Oh. And, of course, this looks like yet another DNS covert channel opportunity.
[ECH] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14
[HTTPSRR] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-10
—
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.
I received several reactions to my diary entry "Decoding Obfuscated BASE64 Statistically" and accompanying video.
I also made another example, this time with hexadecimal encoding.
The blog post: "Another Exercise In Encoding Reversing"
The video:
Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
