Are you running a small business ? Then you need to read this !

One of my friend, who owns a small printing studio, was extorted after he downloaded & opened a file sent via email from a suspicious “customer”. He said that all of his files including printing materials, designs, contracts & other documents are encrypted and the screen showed a message telling him that if he want to restore those files, he had to buy & send Bitcoin to an unknown crypto wallet. Luckily, those files were not that critical so he reinstalled Windows and contacted customers for recovering design files. Only the emotion is damaged then.

But not every victims was lucky like that. In fact, many organizations also were attacked by the same way but the encrypted files now was the database – which is not easy to recover, especially when some companies forgot to back it up.

The software that encrypts files on victim computers then extorts victims for recovering is called Ransomware. Below table lists a few security incidents occurred recently that related to Ransomwares and its damages:

1. What is Ransomware ?

1.1. Definition

Ransomware is a type of malicious software that has two main functions:

• Encrypt all files on a computer.
• Instruct victims how to pay a ransom in exchange for a decryption key.

Ransomware itself does not infect computers on its own. Instead, it is typically delivered through phishing campaigns, fake software downloaded from the Internet, malicious advertisements, compromised websites, or email attachments containing infected documents or archives.

Hackers often disguise ransomware as legitimate files or applications to trick users into opening or installing it. For example, it may appear to be a software installer, software crack, game, invoice, delivery receipt, PDF document, Microsoft Office file, or compressed ZIP archive. Once the victim opens the malicious file, the ransomware is executed, encrypts the victim’s files, and displays a ransom note demanding payment, usually in cryptocurrency, in exchange for the decryption key.

1.2. Why cryptocurrency ?

Ransomware attackers almost always demand payment in cryptocurrencies such as Bitcoin or Monero because these digital currencies can be transferred worldwide without banks or payment processors. Cryptocurrency transactions are also more difficult to trace than traditional bank transfers, making it harder for law enforcement to identify the attackers. In particular, Monero provides stronger privacy features that even hide the sender, receiver, and transaction amount, making it a popular choice for cybercriminals.

2. A Sample Attack

It is unclear how each incidents in above tables happened internally, but here we can look into a sample attack that was caught in the wild. This attack abused shortcut files (.LNK files) on Windows and was delivered via email attachments & a Github public repository. The attack plan was like so:

Step 1. The Bait

The attacker sends an email to the victim, posing as a potential customer with an attractive business offer. The email includes an attachment named “Deal Details.zip”. At this stage, many business owners and sales professionals are likely to download and open the attachment out of curiosity or in hopes of reviewing the proposed deal.

Step 2. The Camouflage

The victim opens downloaded ZIP file. A file is extracted with name: “Deal Details.txt.lnk” with a familiar icon like so:
Deal Details.txt.lnk

Everything looks familiar: from the icon of Notepad app to the “.txt” part, except the “.lnk” suffix. But without knowing what .LNK is, most people will double click it with expectation to see the deal details.

What is LNK file ?

An LNK file is a Windows shortcut that points to another file, folder, or program. Instead of containing the actual content, it stores the location of the target and opens it when double-clicked. Although LNK files are commonly used as convenient shortcuts, attackers can also abuse them to execute malicious commands while appearing to be harmless documents.

In this case, if we open the Properties (use right-click), we can see these malicious settings:

In summary, this LNK file is intentionally named as “Deal Details.txt” to trick user to think that it is a common text file (note that the “.txt” here is a part of filename, it does not specify file type). But because it is a Shortcut file, when double click on it, the command set in field “Target” will be executed. As we can notice, this shortcut actually point to the powershell.exe with a few parameters which looks like will download something from a Github repository.

What is PowerShell ?

PowerShell is a command-line shell and scripting language developed by Microsoft for Windows system administration and automation. It allows administrators to execute commands, manage files, configure system settings, and automate repetitive tasks using scripts.

Unlike the traditional Windows Command Prompt, PowerShell is much more powerful because it can interact directly with Windows components and execute complex scripts. It is installed by default on modern versions of Windows and is widely used by IT professionals for legitimate administration.

However, these same capabilities also make PowerShell attractive to cybercriminals. Instead of shipping a complete malware program, attackers can use a small PowerShell script to download malicious files from the Internet, execute them in memory, modify system settings, and launch attacks – all while using a trusted Windows application that may not immediately raise any suspicion.

In this case, as parameters on above image, the LNK file will use the built-in PowerShell to download another file from https://raw.githubusercontent.com/lrqdz/a/refs/heads/main/bot (file behind this link is already removed after this campaign is reported by researchers ). According to the lab that analyzed this case, that another file on Github is a ransomware written in PowerShell language, which looks like so:

Step 3. The Ransomware

Ransomware, in this case, is the PowerShell script stored on a Github repository. Once downloaded, it is executed by the PowerShell and scans the computer for files that are likely to be valuable. It targets folders such as: Desktop, Documents, Downloads, Pictures, OneDrive.

Instead of stealing data, it focuses on encrypting data that victims cannot easily replace. Once the scan is complete, the ransomware encrypts the discovered files. Each document, spreadsheet, presentation, photograph, and database becomes unreadable without the corresponding decryption key.

After encryption finishes, the ransomware leaves a ransom note for the victim. The message explains that the files have been encrypted and provides instructions for purchasing the decryption key. In this example, the attackers request payment in Monero (XMR), a cryptocurrency designed to provide strong transaction privacy. Here is what victim will see:

3. How To Defend ?

As you can see, Ransomwares can not infect your computer by itself, it needs a phishing campaign to trick you to download and execute it. Problem is if you are doing a business, download attachments & files from Internet is inevitable. So how to know which file is safe, which file is not ? Here is some security practices that can help minimizing the risk of malwares in general, not just ransomwares.

3.1. Always Show File name Extensions

By default, Windows hides the extensions of known file types, making it easier for attackers to disguise malicious files. For example, a file named Invoice.pdf.exe may appear simply as Invoice.pdf, tricking users into believing it is a harmless PDF document. Enabling “Show file name extensions” in Windows File Explorer allows you to see the real file type, making it much easier to identify executable or script files before opening them. This simple setting can help prevent many malware and ransomware infections caused by deceptive filenames.

3.2. Only Open Known File Extensions

Only open files with extensions that match what you expect to receive. For example, a report should typically be a .pdf or .docx file, while a photo should be .jpg or .png. Be cautious of executable or script files such as .exe, .msi, .bat, .cmd, .vbs, .js, .ps1, and .lnk, especially if they arrive through email, messaging apps, or downloads. If you were expecting a document but receive an executable or shortcut instead, do not open it.

3.3. Use Antivirus Softwares

Modern antivirus software can detect many ransomware families by identifying known malware signatures and suspicious behaviors, such as mass file encryption or unauthorized PowerShell execution. Antivirus can act as the last defense line on user’s computer, prevent malicious files from running if users already get tricked by a phishing attempt.

3.4. Backup Data Regularly

The most effective defense against ransomware is maintaining reliable backups of important files. Follow the 3-2-1 backup rule: keep three copies of your data, store them on two different types of media, and keep one copy offline or off-site. If ransomware encrypts your computer, you can restore your files from a clean backup instead of considering the ransom demand. Regularly test your backups to ensure they can be successfully restored when needed.

If you are watching videos via VLC Media Player and do not know much about video formats, then you should read this because you can be hacked just by opening a video.

This is not the first time a security flaw in a video player has been found that potentially lead to Remote Code Execution (RCE) – a type of attack that could allow hackers to run arbitrary code and potentially steal data from a victim’s computer. In the past, many flaws have been discovered in how video players read files MP4, MKV, and MOV. This time, the spotlight is on AVI files with MagicYUV codec.

1. What is AVI file ?

1.1. A Lossless Video Format

AVI (Audio Video Interleave) is a multimedia container format. “Container” means that it stores video, audio, subtitles, and other data together in a single file, but it does not define how the video or audio is compressed. Instead, an AVI file can contain media encoded with many different codecs, such as DivX, Xvid, MJPEG, H.264, or MagicYUV.

1.2. What is MagicYUV codec ?

MagicYUV is a lossless video codec designed for very fast encoding and decoding while keeping the video quality identical to the original. It is commonly used in professional video editors & screen recorders. Y, U, and V here represent the three components of the YUV color space – which is different from RBG color space. YUV separates an image into brightness and color information instead of Red-Blue-Green like in RBG:

• Y (Luma): The brightness or luminance of each pixel (how light or dark it appears). This carries most of the visible detail in an image.
• V (Chrominance Red): The red color difference, indicating how much redder a pixel is compared to its brightness.
• U (Chrominance Blue): The blue color difference, indicating how much bluer a pixel is compared to its brightness.

YUV color space stems from a fact that our eyes detect brightness much better than color details. For example, you can easily notice if text becomes blurry, but you probably won’t notice if its color is slightly blurred while the edges remain sharp. It means that if 4 pixels in a block 2×2 pixels use the same color, human eye won’t notice it. So that YUV format stores brightness – or the Y plane- separately in full resolution (1 value for each pixel) and compress color information – the U plane & V plane – by let each block of 4 pixels use same color. This way is called the 4:2:0 chroma subsampling format.

1.3 Why does MagicYUV is preferred in video editors ?

MagicYUV was specifically designed to be an intermediate codec for video editing, not for final video distribution. When editing video, video editors usually have to edit frame-by-frame. MagicYUV is well suited for frame-by-frame editing because it is an intra-frame codec, which means: every frame is compressed & decompressed independently.

Unlike H264 codec, where it stores video data like this: Frame 1 -> Changes from Frame 1 -> Changes from Frame 2 … , MagicYUV stores: Frame1, Frame2, Frame3, Frame4 … . Suppose an editor is editing frame 12,345:

• With: H.264 codec: The editor may first need to decode preceding keyframes and all dependent frames that leading up to frame 12,345, which requires more work.
• With MagicYUV: The editor reads and decodes only frame 12,345, so it appears almost instantly.

This is why MagicYUV is preferred when editing video, and H264 is used for the final export. The process is like this:

Record / Capture (raw data)
        ↓
MagicYUV
        ↓
Edit in Video Editors
        ↓
Export to H.264 or H.265
        ↓
Upload to YouTube or distribute

1.4 Why does this matter here ?

Because MagicYUV compresses color data in YUV color space, it need to be decoded back to RBG color space so that computer know what colors to display. And the decoding process requires memory allocations, and that is where Buffer Overflow can happen if memory size is not calculated accurately.

2. MagicYUV Decoder

A MagicYUV video does not store raw pixels like a bitmap (BMP). Instead, each video frame is stored in a compressed format to save space. Before it can be displayed, the video player must decode it back into an image. The process looks like this:

MagicYUV Video
       │
       ▼
FFmpeg MagicYUV Decoder
(Decompresses the frame)
       │
       ▼
YUV Image Buffer
(Brightness + Color planes)
       │
       ▼
Color Conversion
(YUV → RGB)
       │
       ▼
Bitmap / Pixel Buffer
(RGB pixels)
       │
       ▼
Graphics API
(DirectX, OpenGL, Metal, Vulkan)
       │
       ▼
Your Monitor

Step 1: Read the compressed video

The AVI file contains compressed MagicYUV data, not individual pixels.

Step 2: Decode the frame

FFmpeg’s MagicYUV decoder decompresses the data into memory. The result is a complete image stored as YUV color space. At this stage, the image is not yet RGB.

What is FFmpeg ?

FFmpeg is a large open-source multimedia framework that provides libraries for:

• Reading video/audio files (AVI, MP4, MKV…)
• Decoding video codecs (H.264, H.265, MagicYUV, VP9…)
• Encoding video
• Color space conversion
• Resizing images
• Audio processing

Applications like VLC, mpv, Shotcut, and many others often use FFmpeg’s libraries instead of writing their own decoders which will be time-consuming and error-prone.

Step 3: Convert YUV to RGB

Since computer’s monitors display Red, Green, and Blue pixels, FFmpeg converts the YUV image into RGB. Now the image is essentially a bitmap in memory.

Step 4: Display on screen

The RGB bitmap is sent to the operating system’s graphics system (such as DirectX, OpenGL, Metal, or Vulkan), which draws the pixels onto your screen.

Source Code

Vulnerable MagicYUV decoder source code can be found here: MagicYUV.C (version 8.1.1)

3. How does the hack happens ?

3.1 The Normal State

When VLC opens an AVI file, it does not decode the video itself. Instead, it relies on FFmpeg to process the media stream. FFmpeg has a decoder to decode and convert each video frame from YUV color space to RBG color space. Each video frame in compressed YUV color space looks like this:

                MagicYUV Encoded Frame
┌─────────────────────────────────────────────────────┐
│ Frame Header                                        │
│ • Width, Height                                     │
│ • Pixel Format (YUV420, YUV422, YUV444, RGB...)     │
│ • Bit Depth                                         │
│ • Slice Information                                 │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│ Slice 0                                             │
│ ┌──────────────┐                                    │
│ │ Compressed Y │                                    │
│ ├──────────────┤                                    │
│ │ Compressed U │                                    │
│ ├──────────────┤                                    │
│ │ Compressed V │                                    │
│ └──────────────┘                                    │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│ Slice 1                                             │
│ ┌──────────────┐                                    │
│ │ Compressed Y │                                    │
│ ├──────────────┤                                    │
│ │ Compressed U │                                    │
│ ├──────────────┤                                    │
│ │ Compressed V │                                    │
│ └──────────────┘                                    │
└─────────────────────────────────────────────────────┘
                         │
                        ...
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│ Slice N                                             │
│ Compressed Y / U / V data                           │
└─────────────────────────────────────────────────────┘

For efficiency reason, MagicYUV divides each video frame into horizontal slices so they can be decoded independently. To decode a MagicYUV encoded frame, FFmpeg uses slice_height field to calculate memory size that will contain decoded data. Problem can happen if slice_height is always trusted by the decoder but AVI files can be altered by anyone who has knowledge about AVI format. Then, an intentionally modifying at field slice_height can lead to a Heap Overflow error.

3.2 The Edge Case

When FFmpeg begins decoding a MagicYUV frame, it first reads the frame metadata, including the frame width, frame height, and the slice height. The slice_height tells the decoder how many rows of pixels are contained in each compressed slice.

For example, a video frame is 1920 × 1080 pixels, and the frame’s metadata specifies a slice_height= 8. Given that the decoder processes each frame one slice at a time. For each slice, the decoder must allocate temporary memory regions before it can decompress the compressed data into those regions. The calculation is like so:

For Slice Height = 8
Allocate Y plane: 1920 × 8 pixels (a memory region)
Allocate U plane: 960 × 4 pixels (another memory region)
Allocate V plane: 960 × 4 pixels (another memory region)

The Y plane receives all 8 rows of pixels (full resolution) and the U and V planes store only half the slice_height , so they need only 4 rows of pixels each. (this is just how MagicYUV compress color information). The decoder then decompresses each slice conceptually like so:

for (row = 0; row < slice_height; row++) {
    decode_one_row(src, dst);
    dst += stride;   // move to the next row
}

Everything works correctly because the slice_height is an even number. At every decode_one_row(src, dst) call, the decoder decode compressed data (src) and write decompressed pixels to allocated memory (dst). For this example, decoder will write 8 rows of 1920 pixels after decoding Y plane, 4 rows of 960 pixels after decoding U & 4 rows of 960 pixels after decoding V planes.

Now imagine an attacker creates a MagicYUV file whose metadata declares a slice_height= 5. The decoder starts exactly the same way:

For Slice Height = 5
Allocate Y plane: 1920 × 5 pixels
Allocate U plane: ?
Allocate V plane: ?

In the vulnerable versions of FFmpeg, U and V were supposed to have half the height of Y without double checking before decoding. For a slice height of 5, that calculation becomes:

5 ÷ 2 = 2.5 rows

The decoder must decide whether to allocate 2 rows or 3 rows of pixels. Normally, decoder uses ceil() that will return the bigger one: 3 rows. But in vulnerable versions, there were an edge case that can end up deciding to use 2 rows. This is where attacker can exploit: they can craft an AVI file that can trigger this edge case.

By algorithm, the decoder always writes one complete row (1920 pixels for plane Y, 960 pixels for plane U &V) at a time. If the edge case makes the decoder allocates memory for only 2 rows, but later decoding operation still output 3 rows, the third row is written beyond the allocated buffer – which causes Heap Overflow error.

3.3 The Heap Overflow

Here is a PoC from a security lab that demonstrate how to craft a malicious AVI video that can exploit this edge case: MagicYUV-CVE-2026

Based on the PoC’s build_oob_payload() function and the exploit write-up, the malicious MagicYUV frame is intentionally crafted so that only the U plane contains the exploiting payload. The Y plane and V plane contain mostly valid image data so the decoder reaches the vulnerable code (the edge case) path normally.

Overall malicious frame

MagicYUV Frame (1280 × 32, YUV420P)
+---------------------------------------------------------------+
|                       Frame Header                            |
|  width = 1280                                                 |
|  height = 32                                                  |
|  slice_height = 31   <-- malicious value                      |
|  nb_slices = 2                                               |
+---------------------------------------------------------------+
Plane Y (1280 × 32)
+---------------------------------------------------------------+
| Slice 0 (31 rows) | Slice 1 (1 row)                           |
| Legitimate pixels | Legitimate pixels                         |
+---------------------------------------------------------------+
Plane U (640 × 16)
+---------------------------------------------------------------+
| Slice 0 (16 rows)                                             |
| Normal chroma pixels                                          |
+---------------------------------------------------------------+
| Slice 1 (should be 0 rows, but decoder believes 1 row exists) |
| *** Exploiting payload (640 bytes) ***                        |
+---------------------------------------------------------------+
Plane V (640 × 16)
+---------------------------------------------------------------+
| Mostly normal data                                            |
+---------------------------------------------------------------+

The 640-byte exploiting payload

The PoC constructs a payload (byte array) that is exactly one row wide:

build_oob_payload()
640-byte payload
┌──────────────────────────────────────────────────────────────────────┐
│ Offset                                                               │
├──────────────────────────────────────────────────────────────────────┤
│ 0x000                                                        ...     │
│ +---------------------------------------------------------------+    │
│ | Command string (NUL terminated)                               |    │
│ | e.g. "curl https://some-prepared-url/\0"                      |    │
│ +---------------------------------------------------------------+    │
│                                                                  │
│ Remaining unused bytes stay zero (0x00)                          │
│                                                                  │
├──────────────────────────────────────────────────────────────────────┤
│ Calibrated offsets*                                                  │
│ +---------------------------------------------------------------+    │
│ | glibc heap metadata copied back exactly                        |    │
│ | (fd, bk, size fields, etc.)                                    |    │
│ +---------------------------------------------------------------+    │
│                                                                  │
├──────────────────────────────────────────────────────────────────────┤
│ AVBuffer overwrite*                                                │
│                                                                  │
│      AVBuffer structure                                           │
│                                                                  │
│      refcount = 1                                                 │
│      free     = system()                                          │
│      opaque   = command_string_address                            │
│                                                                  │
└──────────────────────────────────────────────────────────────────────┘

In summary, the payload is assembled in three parts:

1. Place the command string at the beginning of the overflow region. This is the command line that attacker wants to execute on victim computer if the exploitation is successfully executed.
2. Restore glibc heap metadata so it can pass the heap consistency checks. (We will learn more about glibc in the post that explains Heap Overflow)
3. Overwrite selected fields of the adjacent AVBuffer object (refcount, free, and opaque). (We will learn more about AVBuffer object in the post that explains Heap Overflow)

When the vulnerable FFmpeg decoder reads this malicious frame, it allocates memory as usual then decodes color data into U plane, and the 640-byte payload also is decoded and then overwrite adjacent memory region, which here is region of AVBuffer .

Note that this payload aims to overwrite the pointer of function free() to pointer of function system() . As a result, when FFmpeg later calls function free() to deallocate memory as usual, the actual function is called will be system(). system() is the system API that hands the command string to the shell (usually /bin/sh) and then that shell parses and executes the command line. It’s a library wrapper that forks a process, runs the shell with -c "your command", and waits for it to finish. This is where Heap Overflow usually try to reach to: execute arbitrary command line on exploited computers.

4. How to defend ?

4.1. Use modern Operating Systems

Modern Operating Systems such as latest Window, Linux and MacOS themself include several built-in security mechanisms that make Remote Code Execution (RCE) from a Heap Overflow much harder than it was in the past.

• First, Data Execution Prevention (DEP) or NX (No-eXecute) marks heap memory as non-executable, preventing attackers from simply placing shellcode on the heap and executing it.
• Second, Address Space Layout Randomization (ASLR) randomizes the locations of the heap, libraries, and executable code each time a program starts, making it difficult to predict the addresses needed for an exploit.
• Third, Control Flow Integrity (CFI) and related defenses validate indirect function calls and returns, reducing the chance that corrupted pointers can redirect execution to attacker-controlled code.
• In addition, modern memory allocators such as glibc’s ptmalloc include integrity checks and metadata protections that detect many forms of heap corruption before they can be exploited.

Together, these built up layers of defenses that requires a Heap Overflow exploitation to bypass all at once, making RCE nearly impossible to happen inside a modern operating system.

4.2. Upgrade Related Softwares

Because FFmpeg is an open-source framework and is embedded in hundreds of applications, a vulnerability in FFmpeg can affect a wide range of software that processes audio or video files. Potential cases include:

• Media Players
• Video Editing Softwares,
• Streaming and Conferencing Applications
• Browsers

Although RCE won’t happen easily, the chance is not 0%. While the chance can be 0.1%, we should not let our guard down. To mitigate as much as possible security risks from Zero Day flaw in media files, we need to:

• Update applications that has FFmpeg embeded to latest versions.
• For some softwares utilize self-installed FFmpeg module, upgrade that self-installed FFmpeg to latest versions as soon as possible.

4.3 Verify source of media files as carefully as EXE files

Media files should be treated with the same level of caution as executable files. Modern multimedia formats are highly complex and require parsers and decoders that process large amounts of untrusted data.

A maliciously crafted image, audio, or video file can exploit vulnerabilities in these parsers, allowing arbitrary code execution without the user intentionally running a program.

Therefore, users should only:

• Open media files obtained from trusted sources,
• Verify their authenticity whenever possible, and
• Avoid opening unexpected attachments or files downloaded from untrusted websites.

Treating media files as potentially executable content significantly reduces the risk of exploitation through multimedia codec vulnerabilities.

5. What can we learn from this ?

5.1. Not every hacks look simple

Many successful cyberattacks are the result of years of:

• research into operating systems,
• memory management,
• programming languages, and
• software internals.

Unlike popular misconceptions that hackers only need to type a few commands to gain access to a system, real-world attacks often require discovering:

• subtle software flaws,
• bypassing multiple security mitigations, and then,
• carefully crafting inputs that behave differently at each stage of execution.

The MagicYUV vulnerability demonstrates that a single exploit may involve detailed knowledge of multimedia codecs, heap allocation, CPU architecture, and operating system defenses before arbitrary code execution becomes possible.

5.2. High-skilled hack does not mean high-success rate

A technically sophisticated exploit does not necessarily translate into a large-scale attack. Many advanced exploits rely on:

• specific software versions,
• specific operating systems,
• specific memory layouts, or
• specific application configurations.

Security mechanisms such as ASLR, DEP, CFI, and timely software updates reduce the success rate of exploitation. Consequently, although developing such an exploit requires super expertise, reliably deploying it against a broad range of targets is often much more difficult.

5.3. Every file formats can contain security flaws

Security vulnerabilities are not limited to executable files. Any file format processed by complex software, including images, videos, audio, documents, fonts, archives, and even subtitles, can potentially contain malformed data that triggers implementation bugs. The vulnerability discussed in this post originated from a specially crafted video frame rather than executable code.

This highlights that the security of a system depends not only on the file type itself but also on the correctness and robustness of the software that parses it. Therefore, developers should treat all external file formats as untrusted input and implement secure parsing practices accordingly.