The challenge is called “sshd” and provides the fileystem of a debian machine, which is pretty empty. In var/lib/systemd/coredump, there is a core dump file of a crashed sshd process, which is worth investigating.In order to do that, we can chroot to the extracted file system, and examine the core dump with gdb: gdb /usr/sbin/sshd /var/lib/systemd/coredump/sshd.core.93794.0.0.11.1725917676. Displaying the backtrace with bt, we see:

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f4a18c8f88f in ?? () from /lib/x86_64-linux-gnu/liblzma.so.5
#2  0x000055b46c7867c0 in ?? ()
#3  0x000055b46c73f9d7 in ?? ()
#4  0x000055b46c73ff80 in ?? ()
#5  0x000055b46c71376b in ?? ()
#6  0x000055b46c715f36 in ?? ()
#7  0x000055b46c7199e0 in ?? ()
#8  0x000055b46c6ec10c in ?? ()
#9  0x00007f4a18e5824a in __libc_start_call_main (main=main@entry=0x55b46c6e7d50, argc=argc@entry=4, 
    argv=argv@entry=0x7ffcc6602eb8) at ../sysdeps/nptl/libc_start_call_main.h:58
#10 0x00007f4a18e58305 in __libc_start_main_impl (main=0x55b46c6e7d50, argc=4, argv=0x7ffcc6602eb8, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcc6602ea8) at ../csu/libc-start.c:360
#11 0x000055b46c6ec621 in ?? ()

Seemingly, the process crashed due to invalid memory access at address zero, called from liblzma.

XenoRAT is a relatively new RAT, that is open-source and used by low-sophisticated cyber criminals but also APT groups. In this post, we will look at how we can detect XenoRAT C2 servers through scanning. But, before we come to that, we need to take a quick look at XenoRAT’s C2 protocol.

XenoRAT’s C2 Packet Formats

In general, implant and C2 server communicate over raw TCP while using dedicated packet formats which are set as TCP payload. The packet formats are different, depending on whether the internal server state doProtocolUpgrade is true or false. When a new client connects, this state is always false. Then, the following the packet format is used:

Looking for indicators in order to detect C2 servers of the QuasarRAT family is nothing particularly new. Up to now, two main approaches are already known:

• It is trivial to identify QuasarRAT/AsyncRAT/DcRAT/VenomRAT when default TLS certificates are used. Then, we can look at the certificate’s Subject/Issuer CN which directly gives us the information we look for. E.g., for AsyncRAT, Issuer CN and Subject CN are AsyncRAT Server. This approach has been explained in various reports and blog posts.
• Fingerprints like JA3S, JA4S/JA4X and JARM also allow for detecting these RATs.

However, both approaches have their drawbacks. Certificate-based indicators don’t work anymore once the server doesn’t use the default certificate. And using a non-default certificates is not a high burden at all. E.g., for AsyncRAT, a Subject and Issuer CN different from AsyncRAT Server is even definable via the GUI. Fingerprinting approaches may also be not sufficient since it has been shown that especially JA3S and JARM are heavily prone to false positives.