Hi, we run screenconnect on our network, and over the weekend it must have updated itself on all endpoints.
IDR has created an investigation for every case of the update. I cant seem to find a way to exclude this executable from the ‘remote file execution’ dection. Is this possible at all?
The remote file execution alert is from the UBA detections and therefore does not have an “exception” option however you can “modify” it through the investigations.
When closing the investigation there should be an option to “modify & close” which will give you a couple options as to the scope of the modification.
Same issue here, “modify and close” does not give any usable options.
I have this same issue and was told by support that an option to modify UBA’s is coming.
We actually have plans to migrate our UBA detections to use the same engine as our ABA detections, which would then allow for those rules to benefit from the existing ABA detection rule exception builder.
This effort is slated to happen in stages as you can imagine some of our UBA rules are far more complex than a simple log event being observed, I don’t have any firm ETA to share on this work at this time.
One thing to share is that earlier this year we migrated our AWS Guardduty alerts from UBA to ABA, this was the first of its kind, with many more to come.
David
1 Like
Is there any timeframe on this by chance? We get the same alerts constantly from ScreenConnect since this hits all workstations and servers, Detection Modification will only allow “Allow remote file execution on this asset” and “Alert whenever remote file execution occurs on this asset.” If there is another way to suppress these please let me know.
Ours is the same. Hundreds of ScreenConnect false positives which we can’t whitelist.
So the other thing you could do is simply change the action of the detection rule all together. If ScreenConnect is used thoroughly in your environment you can change the action for the detection rule as a whole to either “Track Notable events” or turn it off completely.
After that, depending on the logging you have, you could create your own custom rules based on the ScreenConnect actions if you still need some level of alerting on other use cases.
Hi @ntong and @tkonicek @kyle_cohne @dkoeppe
We recently added two new ABA detections to effectively replace the existing Remote File Execution UBA alert.
These alerts are named
- Attacker Technique - Service Installed Executing PowerShell
- Attacker Technique - Service Installed With Long Command Line
See them here
Essentially the old UBA rule had two elements, 7045 events with a long string in the service_cmdline or it contained powershell.
Now that these rules have been published you can simply turn off the existing UBA rule and you are covered by these two new ABA rules.
It’s also worth noting that the rule logic for the long string excludes ScreenConnect already, so thats why this rule hasn’t been firing (I’m assuming it hasn’t fired for you) whilst the original UBA alert has been.
You can see the logs that feed this alert under Endpoint Activity → Local Service Creation
These logs were recently added - with 7 days retention, to all of our IDR customers*. Along with the release of Enhanced Endpoint Telemetry - also 7 days retention, for free.
*(MDR and IDR Ultimate customers already had EET)
David
Hi David, thanks for this. We have changed the original ‘Remote file execution’ to just track rather than create investigation. With the ABA rule replacing this, we dont need two investigations for the single event.
I can see the Screenconnect exclusion in the rule logic so it looks like it is working as you describe.