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 ?

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.

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.