Hi. Today we discussed parallax, and now I propose a rule similar to sid:2032526; but for all ports and without flowbit.
alert tcp any any -> any any (msg: "ET MALWARE [ANY.RUN] Parallax RAT Check-In";flow: established, to_server;stream_size: server, =, 1;stream_size: client, <, 301; dsize:< 300;content: "|22f1 6e63|"; depth: 4; content: "|bd 26 09|"; distance: 1; within: 3; classtype: command-and-control; reference: md5, 263c1f2b25e33ce392b53d5a8169cd43;reference: url, https://app.any.run/tasks/99728558-769b-4eb3-a839-a7c09a6c7c96;metadata: attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, signature_severity Major, malware_family Parallax, created_at 2023_08_09;sid: 1; rev: 1;)
Best regards, Jane =^._.^= ∫ meow
Thanks once again for another great rule submission. This new rule should be a part of today’s rule release. The only change I made was that I removed the
stream_size option. The reason I did that was that there wasn’t enough evidence to show that its an accurate stream_size. Our backend database of samples, pcaps, etc. Uses Moloch as a front-end. So I have the ability to query for samples by network traffic criteria. So I searched for those first four bytes, and found one other sample we saw in mid-July that has the same byte pattern as the sample you and James found. In all cases, we never saw any traffic or response from the C2 server, just the call-out traffic. So without a large sample size, I felt that setting the
stream_size might be too restrictive.
If you have any evidence to the contrary, I’d be happy to put it back, but I would rather a rule be not restrictive enough, than too restrictive and miss possible activity we can’t account for due to dead C2s, etc.
As always, thank you for your contribution.
Thanks for the good remark. I also think that the bytes already available are enough for good detection. Also thinking that sometimes it is useful to indicate from whom the transfer is being made using streamsize. Thus if specify the server Stream in the value equal to one it means that the client sends the data first. I consider the number of bytes of the client stream to be excessive and agree with the deletion. After all, the rules must be proactive. I am sincerely glad that I receive detailed answers from you.
Have a good day!
For reference, this is SID 2047156. Thanks @Jane0sint @trobinson667 !