Detecting Administrator Changes Using RMM

Tom Wrigglesworth
RMMSecurity

The problem

In the world of the MSP, some clients have their own IT staff to deal with the simpler things such as faulty hardware and things that need hands on help. These people often have Domain Administrator or Enterprise Administrator rights, over there’s day-to-day account.

This often means that they are able to make changes of the fly, without thinking of the impact. Often we see, the client will add a user to one of the administrator groups, just to give them rights to install software and unfortunately, they get forgotten to be taken back out 6 months later.

This obviously is a massive security risk, should an end user with this level of access be breached or decided to install other bits of software.

What can be done

To combat this problem, we have developed a monitoring policy within our RMM, to take a note of the administrators and to report if the users change – either added or removed.

If the script is ran for the first time, it takes a list of the current users and assumes that is the correct list. We had this ran when our technicians went to the client sites for proactive support – so we knew that the administrators in the lists, were meant to be there.

One problem we came across was that the alarm was triggered for a legitimate temporary reason but the alarm kept going as the monitoring in RMM was set to be every minute. To stop this, we added a line that if the alert file got over 50MB, it would be removed. During testing, 50MB was around 1 week of alarm, which would have been dealt with by then for sure.

The script then gets the user and creates 3 files

  • A list of Domain Admins
  • A list of Enterprise Admins
  • Alerts – the change is documented and the change in this file, raises a ticket within or PSA

When an admin is added or removed to domain or enterprise users, the alerts file continues to populate which gives visibility of when the issue started.

How it works – part 1

The script moves through a series of tasks before taking a note of the domain and enterprise administrators. It needs to know the name of the group that it’s checking for on the DCs. This script can also be used to monitor other groups such as ‘Board Members’ or ‘HR Sensitive’, for this example we’ll just use the scary groups.

# Gathers the group and the targeted paths of the logs - note, this can be changed as well
$groupName = "Domain Admins"
$previousMembersFile = "C:\ProgramData\RMM_Monitoring\PreviousDomainAdmins.txt"
$folderPath = "C:\ProgramData\RMM_Monitoring\"
$logFile = "C:\ProgramData\RMM_Monitoring\DomainAdminsLog.txt"

# Check log file size and delete if over 50MB
$logFileSize = (Get-Item $logFile).Length / 1MB
if ($logFileSize -gt 50) {
    Remove-Item $logFile
}

# Check if the folder exists, create if it doesn't
if (-Not (Test-Path $folderPath)) {
    New-Item -Path $folderPath -ItemType Directory
}

After the process is done, it knows what to look for and where to store it, it knows if the log file is over it’s allowed limit (also changeable) and if it doesn’t, one will be created.. This will be created regardless of where it is chosen and RMM works as SYSTEM level.

However, the log files being stored in that path are not created at SYSTEM level so if you chose to store in in System 32, it’s going to fail.

The next step is to gather the users and either create the files needed or load the information within them.

# Get current members
try {
    $currentMembers = Get-ADGroupMember -Identity $groupName | Select-Object -ExpandProperty SamAccountName
} catch {
    Write-Host '<-Start Result->'"ERROR: Unable to retrieve current members of $groupName. $_"'<-End Result->'
    exit 1
}

# Check if admin file exists, create and populate if it doesn't
if (-Not (Test-Path $previousMembersFile)) {
    $currentMembers | Out-File $previousMembersFile
    # Set the file attribute to Hidden
    Set-ItemProperty -Path $previousMembersFile -Name Attributes -Value Hidden
    Write-Host '<-Start Result->'"STATUS: List created and populated with current Domain Admins."'<-End Result->'
}

# Load previous members list or initialize if file doesn't exist
if (Test-Path $previousMembersFile) {
    $previousMembers = Get-Content $previousMembersFile
} else {
    Write-Host '<-Start Result->'"ERROR=Previous members file not found. Please ensure the initial list is saved at $previousMembersFile."'<-End Result->'
    exit 1
}

In order for RMM monitoring to work, the outputs need to start with Write-Host ‘<-Start Result->’ and finish with ‘<-End Result->’. If there’s an error, the exit command needs to be a ‘1’, this marks this as an active alert which then shows on the RMM dashboard. If there is any other exit code, the alert is seen as inactive (nothing wrong).

Currently, the monitoring has got the group to check and created the required files to either create or review. The file is created as hidden, just as a precaution against wandering end users. 

# Compare current and previous members
$addedMembers = $currentMembers | Where-Object { $_ -notin $previousMembers }
$removedMembers = $previousMembers | Where-Object { $_ -notin $currentMembers }

The final step in the monitoring is to review the current group membership against the TXT files created in the first phase. This is done by taking the information from the TXT and comparing it against the variables populated with the TXT list and the current users.

The comparison has been made and there is a change in the membership, this will trigger two functions ‘removedMembers’ or ‘addedMembers’

## IF USER IS ADDED ##

if ($addedMembers) {
    $addedMembersList = $addedMembers -join ", "
    Write-Host '<-Start Result->'
    Write-Host "ALERT=New members found in Domain Admins group. Added: $addedMembersList"
    Write-Host '<-End Result->'

    write-host '<-Start Diagnostic->'
    write-host "User account added: $addedMembersList"
    write-host ""
    write-host "Current members of group: $currentMembers"
    write-host ""
    write-host "A user entry has been added to Domain Admin. Check the log found C:\ProgramData\RMM_Monitoring\."   
    write-host ""
    write-host "Domain Admins Log shows changes. Previous Domain Admins shows the list that the monitor expects the Domain Admin list to match."
    write-host ""
    write-host "Guide on correcting this issue..."
    write-host ""
    write-host "https://rmm_monitoring-tx-ltd.eu.itglue.com/618693005361331/docs/4036268211454085#version=published&documentMode=view"
    write-host '<-End Diagnostic->'

    Add-Content -Path $logFile -Value "$(Get-Date) - New members found. Added: $addedMembersList"
    # Set the file attribute to Hidden
    Set-ItemProperty -Path $logFile -Name Attributes -Value Hidden
    exit 1
## IF A USER IS REMOVED FROM THE TARGET GROUP ## 

} elseif ($removedMembers) {
    $removedMembersList = $removedMembers -join ", "
    Write-Host '<-Start Result->'
    Write-Host "ALERT=Members removed from Domain Admins group. Removed: $removedMembersList"
    Write-Host '<-End Result->'

    write-host '<-Start Diagnostic->'
    write-host "User account removed: $removedMembersList"
    write-host ""
    write-host "Current members of group: $currentMembers"
    write-host ""
    write-host "A user entry has been removed from Domain Admin. Check the log found C:\ProgramData\RMM_Monitoring\."
    write-host ""
    write-host "Domain Admins Log shows changes. Previous Domain Admins shows the list that the monitor expects the Domain Admin list to match."
    write-host ""
    write-host "Guide on correcting this issue..."
    write-host ""
    write-host "https://rmm_monitoring-tx-ltd.eu.itglue.com/618693005361331/docs/4036268211454085#version=published&documentMode=view"
    write-host '<-End Diagnostic->'

    Add-Content -Path $logFile -Value "$(Get-Date) - Members removed. Removed: $removedMembersList"
    # Set the file attribute to Hidden
    Set-ItemProperty -Path $logFile -Name Attributes -Value Hidden
    exit 1

Since this function exists with 1, all information written is added to the alert and if set, to the PSA ticket as well. In my example, this has the action, user adjusted, where the log is saved, what’s changed and a guide on the procedure to follow.

How it works – part 2

Currently, this script checks a TXT and then gives an 1 or a 0 – not very helpful at this stage. Next we need to add the script to the monitoring, within RMM and add to alarms. The benefit of this approach is you can add as many groups to a single alarm, so if there’s something new ‘HR Sensitive’ and it’s handed by the HoD and they make a unauthorized change, the MSP will know and can take appropriate action.

To set the alarm in RMM, we need to create a component and a monitoring policy. This allows us to target the alarm either at everyone or just specific customers that may have the premium support in the contract, with proactive monitoring.

Easy to do Automation > Components > Create Component

  • Name the component
  • Give the description (good habit to get into)
  • Category: Monitoring
  • Script: PowerShell

Copy your script into the the component and then target at either a global level or a site level, then save.

Next we need to build the policy that puts the output on the dashboard.

Policies > Monitoring > Create Policy

  • Name the policy
  • Set to global or site
  • Choose the monitors created
  • Chooses the targets
  • Save and deploy
  • Add a ticket to PSA (optional)

The end result looks similar to this, the server and all information included in the alert ready for the assigned technician.

How to respond

When the alert comes through, it’s usually the onsite technician making a change, without informing the MSP. The technician needs to confirm with the contact on site that this is legitimate and necessary.

Once verbally confirmed, get a confirmation via email and either delete the TXT file triggering the alert or create another component to reset the alert.

Note, this monitoring can be targeted at all DCs so if the alarm is set off, then each DC needs to be adjusted.

Reset admin alerts

The script to reset the alert just deletes the files and forces the scrip to re-create them. This is used when there’s more than one DC, just to save time and manual operation.

# Check if notepad.exe is running
if (Get-Process -Name notepad -ErrorAction SilentlyContinue) {
    # Close Notepad
    Stop-Process -Name notepad -Force
    Write-Output "Notepad was running and has been closed."
} else {
    Write-Output "Notepad is not running."
}

# Delete the directory and everything inside
Remove-Item -Path "C:\ProgramData\NetTeam" -Recurse -Force
Write-Output "Administrator alerting reset."

Conclusion

Having this is place has brought up changes in administrators as soon as it happens, allowing us to be much for vigilant with admin rights.

RMM is set to create a ticket and within the support ticket created, is all the information about the change, users and how to fix it through our knowledge base.

This is a basic monitoring method focused on alerting, not prevention.

Leave a Reply

Your email address will not be published. Required fields are marked *