I appreciate this project and am further enhancing my detection queries and am incorporating the disk artifacts to detect the presence of RMM tools.
Currently it seems that specifying file paths by contributors is done in a free form format, what makes it difficult to use as a regex pattern. It would be great if all artifacts in the database are specified in a agreed format. Firstly, don't use regex if possible to detect the presence of an RMM. If not possible, use a wildcard format that is used by everybody. And third, using environment variables will never lead to detections as only literal interpreted paths are used in XDR logfiles.
These are examples that are fine for using manually by an human analist, but when using this data in KQL query there are to many variants to work with. Having KQL query language fixing this, is kind of dreadful.
Detection usually work with 'has' evaluations that don't work with regular expressions. So regular expression are actually the least favorite items to work with from a detection perspective.
Use of wildcards (*), substitutions (<>) and environment variables (%)
- *\Faronics\Insight Student\FIStudentAgent.exe
- *\tniwinagent.exe
- %TEMP%\*\agent.exe
- <impersonated-org>Agent.exe
- C:\Program Files (x86)\FleetDeck Agent\*\fleetdeck_agent.exe
- *\*\ScreenConnect.ClientService.exe (<string ID>)\*
- C:\Program Files (x86)\ScreenConnect Client (<string ID>)\*
- C:\Users\*\AppData\Local\Programs\RemSupp\RemSupp.exe
I appreciate this project and am further enhancing my detection queries and am incorporating the disk artifacts to detect the presence of RMM tools.
Currently it seems that specifying file paths by contributors is done in a free form format, what makes it difficult to use as a regex pattern. It would be great if all artifacts in the database are specified in a agreed format. Firstly, don't use regex if possible to detect the presence of an RMM. If not possible, use a wildcard format that is used by everybody. And third, using environment variables will never lead to detections as only literal interpreted paths are used in XDR logfiles.
These are examples that are fine for using manually by an human analist, but when using this data in KQL query there are to many variants to work with. Having KQL query language fixing this, is kind of dreadful.
Detection usually work with 'has' evaluations that don't work with regular expressions. So regular expression are actually the least favorite items to work with from a detection perspective.
Use of wildcards (*), substitutions (<>) and environment variables (%)