#BruteRatel is difficult to detect without having access to WinAPI, NTAPI, and Syscalls as everything is done in memory. This hurts our efforts to hunt across behaviors upon executing the BRC4 payload.
Although all hope is not lost,there are some good indicators in the wires🧵👇
Although all hope is not lost,there are some good indicators in the wires🧵👇
Looking into the unencrypted network traffic, there are some indicators we can hunt for and create detections based on the default BRC4 profile:
➡️Multiple POST requests against certain destinations
➡️All responses (apart from initial check-in) have 0 content with 200 status👇
➡️Multiple POST requests against certain destinations
➡️All responses (apart from initial check-in) have 0 content with 200 status👇
➡️Base64 encoded body and encrypted upon deobfuscation
➡️Default user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
➡️Default user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
Because hunting in the network is not always possible, we can focus on the initial payload delivery and execution.
Looking for unusual persistence entries via common methods would also be a good idea for catching evil. Worth noting that many TAs will not opt in for this.
Looking for unusual persistence entries via common methods would also be a good idea for catching evil. Worth noting that many TAs will not opt in for this.
If you have other ways of detecting Brute Ratel, feel free to leave a comment 🙂
• • •
Missing some Tweet in this thread? You can try to
force a refresh
