[GH-ISSUE #1482] Feature Request: Change detection for collector scripts #2871

New issue

Open

opened 2026-03-14 05:46:27 +03:00 by kerem · 2 comments

kerem commented

2026-03-14 05:46:27 +03:00

Owner

Originally created by @NiceGuyIT on GitHub (Apr 13, 2023).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1482

Is your feature request related to a problem? Please describe.
The current setup using scripts, collector scripts, checks and tasks do not have a good way to detect if something changed. Possibilities include:

A list of installed programs to be alerted when a new program is installed.
A list of users to be alerted when a new user is created.
A list of file properties to detect certain conditions like legitimately encrypted files, weird filenames, etc.
Collector scripts to "monitor" business critical conditions or values. For example, detect when software has notified the user that there's an update.

Describe the solution you'd like
It would be nice if collector scripts could be hooked into the alert system to "alert" if the values changed.

A bonus is to include the old and new values.
A huge bonus is to provide a diff between the two.

Describe alternatives you've considered
Alternatives require a separate system (for storage) and too much complication.

Additional context
Writing a change detector script requires persistent storage which is not available to scripts.

Originally created by @NiceGuyIT on GitHub (Apr 13, 2023). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1482 **Is your feature request related to a problem? Please describe.** The current setup using scripts, collector scripts, checks and tasks do not have a good way to detect if something changed. Possibilities include: - A list of installed programs to be alerted when a new program is installed. - A list of users to be alerted when a new user is created. - A list of file properties to detect certain conditions like legitimately encrypted files, weird filenames, etc. - Collector scripts to "monitor" business critical conditions or values. For example, detect when software has notified the user that there's an update. **Describe the solution you'd like** It would be nice if collector scripts could be hooked into the alert system to "alert" if the values changed. - A bonus is to include the old and new values. - A huge bonus is to provide a diff between the two. **Describe alternatives you've considered** Alternatives require a separate system (for storage) and too much complication. **Additional context** Writing a change detector script requires persistent storage which is not available to scripts.

kerem commented

2026-03-14 05:46:33 +03:00

Author

Owner

@silversword411 commented on GitHub (Apr 18, 2023):

Couldn't you do this already with custom fields and a fancy script?

Store your values in a parsed string (comma, space etc delimited.)

Then read, test, set and exit your script based on your tests?

@silversword411 commented on GitHub (Apr 18, 2023): Couldn't you do this already with custom fields and a fancy script? Store your values in a parsed string (comma, space etc delimited.) Then read, test, set and exit your script based on your tests?

kerem commented

2026-03-14 05:46:38 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Apr 18, 2023):

Let's take for example checking the hosts files for changes. This can be done by 1) checking the contents for changes or 2) checking the filesystem for metadata changes (timestamp, size, etc.). Let's go through the various ways this can be accomplished in the current system.

Get-Content C:\Windows\System32\drivers\etc\hosts

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#       127.0.0.1       localhost
#       ::1             localhost

Get-ChildItem C:\Windows\System32\drivers\etc

    Directory: C:\Windows\System32\drivers\etc


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----          5/7/2022   1:22 AM            824 hosts
-a----          5/7/2022   1:22 AM           3683 lmhosts.sam
-a----          5/7/2022   1:22 AM            407 networks
-a----          5/7/2022   1:22 AM           1358 protocol
-a----          5/7/2022   1:22 AM          17635 services

Detecting the change on the agent means we need to know the previous state.
1. Passing the information on the command line is almost impossible without some encoding to make it command-line friendly.
2. Passing the information as an environmental variable is better provided that the system escapes special characters so that the output matches the input.
3. Passing an API key to query the server for the current state is not an option due to security reasons.
4. The script will need to perform the diff and exit accordingly.
  1. Returning the "diff" so that it's included in the email means the previous state is lost. The next run will not have the previous state.
  2. Returning the current output is necessary to preserve the previous state. This means the alert will not show the differences. This also implies the "diff" cannot be stored unless it's stored in some logs on the agent.
Detecting the change on the server would require two custom fields, one for the previous state and one for the current state.
1. An external process is required to perform the diff and set the appropriate alert.
Using a 3rd party system for storage.
1. A K/V server could be used to store the data. Comparing the data and generating the alert is extra work.
2. A git server could be used to store the data. Git will not allow a commit if the data hasn't changed. This sounds like an intriguing idea.
  1. An access token will need to be passed to the TRMM script which will need to perform the necessary git clone, git add, and git commit steps.
  2. Sending the alert could be as easy as subscribing to the repo.
  3. Maintaining a git server (Gitea) and/or multiple git repos (GitHub/GitLab/Gitea) means more work.

@NiceGuyIT commented on GitHub (Apr 18, 2023): Let's take for example checking the hosts files for changes. This can be done by 1) checking the contents for changes or 2) checking the filesystem for metadata changes (timestamp, size, etc.). Let's go through the various ways this can be accomplished in the current system. <details> <summary>Get-Content C:\Windows\System32\drivers\etc\hosts</summary> ```text # Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost ``` </details> <details> <summary>Get-ChildItem C:\Windows\System32\drivers\etc</summary> ```text Directory: C:\Windows\System32\drivers\etc Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 5/7/2022 1:22 AM 824 hosts -a---- 5/7/2022 1:22 AM 3683 lmhosts.sam -a---- 5/7/2022 1:22 AM 407 networks -a---- 5/7/2022 1:22 AM 1358 protocol -a---- 5/7/2022 1:22 AM 17635 services ``` </details> 1. Detecting the change on the agent means we need to know the previous state. 1. Passing the information on the command line is almost impossible without some encoding to make it command-line friendly. 2. Passing the information as an environmental variable is better provided that the system escapes special characters so that the output matches the input. 3. Passing an API key to query the server for the current state is not an option due to security reasons. 4. The script will need to perform the diff and exit accordingly. 1. Returning the "diff" so that it's included in the email means the previous state is lost. The next run will not have the previous state. 2. Returning the current output is necessary to preserve the previous state. This means the alert will not show the differences. This also implies the "diff" cannot be stored unless it's stored in some logs on the agent. 3. Detecting the change on the server would require two custom fields, one for the previous state and one for the current state. 1. An external process is required to perform the diff and set the appropriate alert. 4. Using a 3rd party system for storage. 1. A K/V server could be used to store the data. Comparing the data and generating the alert is extra work. 2. A git server could be used to store the data. Git will not allow a commit if the data hasn't changed. This sounds like an intriguing idea. 1. An access token will need to be passed to the TRMM script which will need to perform the necessary `git clone`, `git add`, and `git commit` steps. 2. Sending the alert could be as easy as subscribing to the repo. 3. Maintaining a git server (Gitea) and/or multiple git repos (GitHub/GitLab/Gitea) means more work.