I have multiple locations triggering the recently released rule ET MALWARE [ANY.RUN] RisePro TCP v.0.1 (External IP) for traffic going to what appears to be team viewer servers *.router.teamviewer.com hosted by an IT service provider.
I assume this is a false positive and I cannot find any information about rise pro using teamviewer. I am unable to provide a pcap of the alerts triggering.
Hello there,
I’m sorry you’re experiencing issues with this rule. Would you mind answering a couple of questions to hopefully help me writing some modifications to the rule in order to reduce false positives?
Thank you for your cooperation,
-Tony
So far it appears to have only triggered on Team viewer traffic
| Dest port | src port | Count |
|---|---|---|
| 56582 | 5938 | 4 |
| 50435 | 443 | 2 |
| 62858 | 5938 | 2 |
| 12578 | 443 | 1 |
| 49192 | 443 | 1 |
| 49680 | 443 | 1 |
| 49733 | 443 | 1 |
| 50073 | 443 | 1 |
| 50135 | 443 | 1 |
| 50620 | 443 | 1 |
| 50638 | 443 | 1 |
| 50817 | 443 | 1 |
| 50990 | 443 | 1 |
| 51101 | 443 | 1 |
| 51334 | 443 | 1 |
| 51715 | 5938 | 1 |
| 52366 | 5938 | 1 |
| 52607 | 443 | 1 |
| 52778 | 443 | 1 |
| 53102 | 443 | 1 |
| 53373 | 443 | 1 |
| 53796 | 5938 | 1 |
| 54197 | 443 | 1 |
| 54588 | 443 | 1 |
| 54817 | 443 | 1 |
I performed lookups on the source IPs and all of the hostnames are *.router.teamviewer.com
so for the time being, I’ve added some port negations to the RisePro TCP rules on ports 5938,443, and port 80 in order to prevent the rules from matching on traffic on those ports, which are teamviewer’s default (5938), and fallback ports (443, then port 80 as a last result) to remedy this problem for now. These fixes will be available in today’s standard daily rule release. Typically, the rule release is published by around 6-7pm EST. Once today’s rule release is out, please push it out to your sensors, and let us know whether or not our changes resolved this issue, or if the problems persist.
Thank you for reporting this issue, and your assistance.
-Tony
Thanks for doing this. we havent had this rule trigger since the update way deployed.
alert tcp $EXTERNAL_NET ![80,443,5938] → $HOME_NET any (msg:“ET MALWARE [ANY.RUN] RisePro TCP v.0.1 (External IP)”; flow:established,to_client; dsize:19<>29; content:“|00 00 00 21 27 00 00|”; offset:5; depth:8; reference:md5,a1f3423e231abd59d45b2ec37f751bbc; reference:url,app.any.run/tasks/d4c145cc-6a2d-4512-9cd6-555f0f2e17ed; classtype:command-and-control; sid:2046267; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2023_06_14, deployment Perimeter, former_category MALWARE, malware_family RisePro, performance_impact Low, confidence High, signature_severity Major, updated_at 2023_06_16; target:dest_ip;)
alert tcp $HOME_NET any → $EXTERNAL_NET ![80,443,445,5938] (msg:“ET MALWARE [ANY.RUN] RisePro TCP v.0.1 (Exfiltration)”; flow:established,to_server; dsize:>1100; content:“|00 1F 27 00 00|”; offset:7; depth:5; reference:md5,a1f3423e231abd59d45b2ec37f751bbc; reference:url,app.any.run/tasks/d4c145cc-6a2d-4512-9cd6-555f0f2e17ed; classtype:command-and-control; sid:2046270; rev:3; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2023_06_14, deployment Perimeter, former_category MALWARE, malware_family RisePro, performance_impact Low, confidence High, signature_severity Major, updated_at 2023_06_23; target:src_ip;)
These updated rules ain’t working for us after modifying it according to our requirements, it’s still triggering the alert making it spam our channel.
Our modified rule based on the rule that you have provided:
alert tcp $EXTERNAL_NET any → $HOME_NET ![5938,443,80] (msg:“Possible MALWARE [ANY.RUN] RisePro TCP v.0.1 (External IP)”; flow:established,to_client; dsize:19<>29; content:!“.teamviewer.com”;nocase; content:“|00 00 00 21 27 00 00|”; offset:5; depth:8; reference:md5,a1f3423e231abd59d45b2ec37f751bbc; reference:url,app.any.run/tasks/d4c145cc-6a2d-4512-9cd6-555f0f2e17ed; target:dest_ip; priority:1; sid:2402175;)
It’s triggering for the port 5938 on the subdomains of teamviewer.com (router9.teamviewer.com, router10.teamviewer.com, routerpool9.rlb.teamviewer.com, routerpool10.rlb.teamviewer.com) Can you please check our modified rule and suggest any changes if required as this rule ain’t working for us.
Hey, thank you for reporting this issue. However, this rule should not be triggering on port 5938/tcp at all due to the port negations defined in the header for both rules that seem to be giving you problems. Based on what I can see, I know you have the latest version of the these rules downloaded of course, but has the Suricata daemon (or daemons, plural if your sensor runs multiple, concurrently) been restarted recently? Suricata will not load any newly downloaded or locally created rules until the service has been restarted. I suspect this is what is going on here.
Can you please try restarting the Suricata daemon(s)/service(s) on your sensor, and tell me if the problem persists? and if it does, can you provide us a copy of the eve.json output from the alerts triggering?
Again, thank you very much for your time, I hope this helps
-Tony R
Adding these keywords will significantly reduce the number of FP
stream_size: client, <, 100;
stream_size: server, <, 100;
To date, I have examined 47 samples and can offer a less proactive rule, using the magic constant
alert tcp $HOME_NET any -> $EXTERNAL_NET ![80,443,445,5938] (msg:"ET MALWARE [ANY.RUN] RisePro TCP v.0.1 (Exfiltration)";
flow:established,to_server;
dsize:>1100;
content: "|AD DA BA AB|"; depth:4;
content:"|00 1F 27 00 00|"; offset:7; depth:5;
reference:md5,a1f3423e231abd59d45b2ec37f751bbc;
reference:url,app.any.run/tasks/d4c145cc-6a2d-4512-9cd6-555f0f2e17ed;
classtype:command-and-control; sid:2046270; rev:3; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2023_06_14, deployment Perimeter, former_category MALWARE, malware_family RisePro, performance_impact Low, confidence High, signature_severity Major, updated_at 2023_06_23; target:src_ip;)
alert tcp $HOME_NET any -> $EXTERNAL_NET ![80,443,5938] (msg:"ET MALWARE [ANY.RUN] RisePro TCP v.0.1 (Activity)";
flow:established,to_server;
dsize:12;
content: "|AD DA BA AB|"; depth:4;
content:"|00 00 00 00 10 27 00 00|"; offset:4; depth:8;
reference:md5,a1f3423e231abd59d45b2ec37f751bbc;
reference:url,app.any.run/tasks/d4c145cc-6a2d-4512-9cd6-555f0f2e17ed;
classtype:command-and-control; sid:2046269; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2023_06_14, deployment Perimeter, former_category MALWARE, malware_family RisePro, performance_impact Low, confidence High, signature_severity Major, updated_at 2023_06_16; target:src_ip;)
Thanks, could you please explain me the content fields in detail:
content: “|AD DA BA AB|”; depth:4;
content:“|00 1F 27 00 00|”; offset:7; depth:5;
ADDA BAAB - magic constant
00 1f 27 00 00 - command
Magic bytes serve as an indicator that the connection is initiated by the client and not by the browser, for example.
1f 27 - command
there are 4 bytes of data length in front of them, but since they are less than 16 megabytes, the fourth byte is zero.
This discussion is a perfect example of why I joined this community. Thanks for taking the time to ask questions, @ksci, and propose solutions @trobinson667, @Manav2038 and @Jane0sint!
Thanks!!