Hi everyone, first let’s see what examples of connections we have.
At the same time, we know for sure that this backdoor does not install a fake TLS-Handshake and immediately begins transmitting pseudo application-layer messages. We will use this for the condition in the rule.
I do not pretend that these rules will always work and we can see with what probability these rules will work. And in the end, I will propose a +new rule because there are obvious contradictions between the real protocol and the messages sent by the client in keepalive mode.
app.any.run/tasks/e00ac558-f3d6-4fea-8164-012233197afd/
app.any.run/tasks/4f37df15-548c-4804-8949-f999ce456684/
app.any.run/tasks/d9cfa1e3-9db6-4da9-ab66-6f4a1b622eea/
app.any.run/tasks/9c66816a-900a-4909-9d8b-e39cadbcee0e/
The most interesting thing that I focused on, in general, is how the first 256 bytes of the first packet are formed, and that’s where the xor key is actually located.
As you know, each byte has a low and high part, and let’s look at the fact that the low bytes (4 LSB, mask 0b00001111) in the columns formed by a line length of 16 are the same. We will use this as a condition.
For some samples, the key is formed so that the high part of the byte is sometimes an increasing counter in steps of one.
We could immediately use this feature (counter) of key formation, but the first sample and its key were formed somewhat differently. There, the condition for equality of low bytes was preserved, but the key was formed as a repetition of a subkey of length 64. Which ruins the idea of detecting the counter.
Since checking all columns for equality of low bytes is too expensive an operation, I took 2 bytes with the values 0x00 and 0x01. Found them by the content in the first packet (where the key was stored) and checked whether after 16 bytes there was the same low byte value as the one discovered via mask. That is, if I am looking for byte 0x00, then after 16 bytes I look if the low part is equal to zero.
content: "|00|"; offset: 5; depth: 256;
byte_test: 1, =, 0, 15, relative, bitmask 15;
byte_test: 1, =, 0, 31, relative, bitmask 15;
Now add a check that there was no Handshake before the packet with the key. Check the conditions so that the server don’t transmit anything to client (server, =, 1;) and client have already send a certain number of bytes in one packet
dsize: 271<>337;
stream_size: server, =, 1;
stream_size: client, >, 272;
stream_size: client, <, 337;
As a result, I have two rules for 0x00 and for a byte equal to 0x01 because a zero byte is not always found in the key and it can also be located somewhere at the end, which will not make it possible to check two more lines of 16 bytes each (byte_test: 1, =, 0, 31,).
Rules:
alert tcp any any -> any 443 (msg: "ET MALWARE [ANY.RUN] BACKDOOR [ANY.RUN] ToneShell FakeTLS Check-In (APT Mustang Panda / Earth Preta)";
flow: established, to_server; dsize: 271<>337;
stream_size: server, =, 1;
stream_size: client, >, 272;
stream_size: client, <, 337;
content: "|1703 0301|"; depth: 5;
byte_test: 1, >, 15, 0, relative;
byte_test: 1, <, 49, 0, relative;
content: "|00|"; offset: 5; depth: 256;
byte_test: 1, =, 0, 15, relative, bitmask 15;
byte_test: 1, =, 0, 31, relative, bitmask 15;
classtype: command-and-control;
reference: md5,7e8f8043fe50cb6ce19b41a6e979a02f;
reference: url,app.any.run/tasks/6d271aa7-302c-4f3b-8cde-2fade4caa2f6;
metadata: attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, signature_severity Major, malware_family toneshel, tag apt, tag mustangpanda, created_at 2024_01_27;
sid: 1; rev: 1;)
alert tcp any any -> any 443 (msg: "ET MALWARE [ANY.RUN] BACKDOOR [ANY.RUN] ToneShell FakeTLS Check-In (APT Mustang Panda / Earth Preta)";
flow: established, to_server; dsize: 271<>337;
stream_size: server, =, 1;
stream_size: client, >, 272;
stream_size: client, <, 337;
content: "|1703 0301|"; depth: 5;
byte_test: 1, >, 15, 0, relative;
byte_test: 1, <, 49, 0, relative;
content: "|01|"; offset: 5; depth: 256;
byte_test: 1, =, 1, 15, relative, bitmask 15;
byte_test: 1, =, 1, 31, relative, bitmask 15;
classtype: command-and-control;
reference: md5,7e8f8043fe50cb6ce19b41a6e979a02f;
reference: url,app.any.run/tasks/6d271aa7-302c-4f3b-8cde-2fade4caa2f6;
metadata: attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, signature_severity Major, malware_family toneshel, tag apt, tag mustangpanda, created_at 2024_01_27;
sid: 2; rev: 1;)
Next rule:
The fake protocol after decryption has three layers:
- The first is a system one that ensures the connection is maintained and the first registration packet is transmitted to the server.
- The second level is the console, here the cmd process appears in the process span. This process executes console level commands.
- The third layer is a built-in file manager protocol that I have not yet analyzed.
As you can see, in connection Keep-Alive mode, the server and client exchange very short packets of 7 bytes length (header + opcode). The packet containing the application layer data of the TLS protocol cannot be so short as it must contain additional information HMAC for version 1.2 and AEAD data for version 1.3.
This oddity can be used to detect fake connections.
For example, such a rule can be combined with the first two via flowbits, thus making fewer conditions in the first rule. Of course, a threshold will help here.
Here I am giving you complete freedom of action, thank you for your attention, I hope this detection will last for some time.
ps: And I would also like to apologize for the slight inaccuracy on Twitter, where I wrote the key length as 128, of course I meant 256.
