Automox Community Forum

Hi, everybody! Since announcing our strategic alliance that pairs our two platforms, Automox has developed customized Worklets for SentinelOne that includes pre-built scripts for automatic deployment of the SentinelOne agent across Windows, Linux and macOS devices - without manual intervention or wasted IT cycles. Below you’ll find the worklet for Linux. Big thanks to @Zac-Automox for getting these written. Worklet Details: Install SentinelOne Agent (Linux) Evaluation Code #!/bin/bash #================================================================# HEADER#================================================================# SYNOPSIS# Installs the SentinelOne agent on the endpoint.## DESCRIPTION# This worklet will check to see if the SentinelOne agent is# installed on the target device.## USAGE# ./evaluation.sh##================================================================# IMPLEMENTATION# version STRAT-1_install_sentinelone_agent (www.automox.com) 1.0# author Zac Youtz##================================================================# HISTORY# 8/13/2021 : Zac Youtz : Script creation# #================================================================# END_OF_HEADER#================================================================ # evaluate the device to see if the Sentinel One is installedif sudo sentinelctl version > /dev/null; then echo "Software is already installed" exit 0else echo "Software not installed - Flagging for installation" exit 1fi Remediation Code #!/bin/bash #================================================================# HEADER#================================================================# SYNOPSIS# Installs the SentinelOne Agent on the target device## DESCRIPTION# This worklet checks to see if the SentinelOne Agent is installed# on the target device and if it isn't, installs and registers the# SentinelOne Agent on the device.## USAGE# ./remediation.sh## EXAMPLE# rpm_filename="SentinelAgent_linux_v21_6_3_7.rpm"# deb_filename="SentinelAgent_linux_v21_6_3_7.deb"# site_token="ABCD123"##================================================================# IMPLEMENTATION# version STRAT-1_install_sentinelone_agent (www.automox.com) 1.0# author Zac Youtz##================================================================# HISTORY# 8/13/2021 : Zac Youtz : Script creation###================================================================# END_OF_HEADER#================================================================ #########################rpm_filename=""deb_filename=""site_token=""########################## CONSTANTSrpm_installer="$(pwd)/$rpm_filename"deb_installer="$(pwd)/$deb_filename"######################### # Check if SentinelOne is already installedif sudo sentinelctl version > /dev/null; then echo "Software is already installed" exit 0fi install_command=""# Define install command based on system typeif [ -x "$(command -v dpkg)" ]; then echo "Installing $deb_installer" install_command="sudo dpkg -i $deb_installer"elif [ -x "$(command -v rpm)" ]; then echo "Installing $rpm_installer" install_command="sudo rpm -i --nodigest $rpm_installer"else echo "Unable to install software; either rpm or dpkg package manager must be present on system" exit 1fi if eval "$install_command"; then echo "Software successfully installed" echo "Registering SentinelOne agent" sudo /opt/sentinelone/bin/sentinelctl management token set "$site_token" sudo /opt/sentinelone/bin/sentinelctl control start exit 0else echo "Software failed to install" exit 1fi

Hi everyone We sometimes have a requirement to replicate the behaviour of GPOs that run in the user context. This means you need to execute a task under the current logged on user and trigger it to occur only when user logs on. To achieve this, we can use a scheduled task with 2 special settings: It is triggered only when a user logs on It runs under the context of the local “USERS” group. With #2, you are able to access all the usual user-context-specific data such as %USERNAME%, HKCU, etc. And, this approach makes the scheduled task run under the context of ANY user that logs on. Say for example you have 2 users - USERA and USERB logging on, the scheduled task will take on the security context of USERA or USERB depending on who logs on. Unfortunately, you cannot achieve this with the New-ScheduledTask cmdlet. You will have to use COM programming. Here’s the code: $ShedService = New-Object –comobject 'Schedule.Service' $ShedService.Connect() $Task = $ShedService.NewTask(0) $Task.RegistrationInfo.Description = "Test Task - Runs when user logs on, and under user's context" $Task.Settings.Enabled = $true $Task.Settings.AllowDemandStart = $true $trigger = $task.triggers.Create(9) $trigger.Enabled = $true $action = $Task.Actions.Create(0) $action.Path = "cmd.exe" $action.Arguments = "/c echo %temp% > c:\temp\out.txt" $taskFolder = $ShedService.GetFolder("\") $taskFolder.RegisterTaskDefinition("Run at user logon", $Task , 6, "Users", $null, 4) You can examine the file “c:\temp\out.txt” and see that the text in there points to the temporary folder of the user who just logged on.

This is an older CVE that was reissued by Microsoft January 21 2022. There is no patch for this vulnerability. It affects all current and previous versions of Windows OS. And is considered “opt-in” with no plans to enforce stricter verification. This is listed in the CISA known exploited vulnerabilities catalog. Updated reissue:CVE-2013-3900 - Security Update Guide - Microsoft - WinVerifyTrust Signature Validation Vulnerability Other: https://nvd.nist.gov/vuln/detail/CVE-2013-3900 https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-098 Evaluation Code: #Clears all errors prior to running script$Error.Clear() #All values tested$Value1 = Test-Path -Path "HKLM:\\SOFTWARE\Microsoft\Cryptography\Wintrust\Config"$Value2 = Test-Path -Path "HKLM:\\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Wintrust\Config"$Value3 = Get-ItemPropertyValue -Path "HKLM:\\SOFTWARE\Microsoft\Cryptography\Wintrust\Config" -Name "EnableCertPaddingCheck"$Value4 = Get-ItemPropertyValue -Path "HKLM:\\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Name "EnableCertPaddingCheck" #Test that both $Value1 and $Value2 are Trueif (("True" -ne $Value1) -or ("True" -ne $Value2)){ Exit 1}#Test that both $Value3 and $Value4 equal 1elseif (("1" -ne $Value3) -or ("1" -ne $Value4)){ Exit 1}#Test that there were no errors. When testing $Value3 and $Value4, if no entry exists a non-terminating error will be thrown.elseif ("0" -ne $Error.Count){ Exit 1}else{ Exit 0} Remediation Code: <#.SYNOPSIS Creates two registry entries to mitigate WinVerifyTrust Signature Validation Vulnerability CVE-2013-3900.DESCRIPTION This script creates the two necessary registry entries to mitigate WinVerifyTrust Signature Validation Vulnerability CVE-2013-3900 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900 Automox runs as a 32-Bit process, so the script must execute in a 64-Bit shell. Inspiration for script block to trigger 64-Bit shell found here: https://help.automox.com/hc/en-us/articles/5352120268820-Enforce-Windows-Registry-Settings-Worklet#> $scriptBlock = { #Final registry key paths $32bitpath = "HKLM:\\SOFTWARE\Microsoft\Cryptography\Wintrust\Config" $64bitpath = "HKLM:\\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" #Registry entry name $RegentryName = "EnableCertPaddingCheck" #Required registry key paths $path1 = "HKLM:\\SOFTWARE\Microsoft\Cryptography" $path2 = "HKLM:\\SOFTWARE\Microsoft\Cryptography\Wintrust" $path3 = "HKLM:\\SOFTWARE\Wow6432Node\Microsoft\Cryptography" $path4 = "HKLM:\\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Wintrust" #Creates required keys New-Item -Path $path1 -Name "Wintrust" New-Item -Path $path2 -Name "Config" New-Item -Path $path3 -Name "Wintrust" New-Item -Path $path4 -Name "Config" try { #Creates registry in final key path New-ItemProperty -Path $32bitpath -Name $RegentryName -Value "1" New-ItemProperty -Path $64bitpath -Name $RegentryName -Value "1" return 0 } catch { return 1 }} Write-Host $returnCode #Execute the scriptblock above in 64-bit shell. Will return 0 for ScriptBlock in a 64-bit shell. This will return 0 for success and 1 for fail used to determine script success.$returnCode = & "$env:SystemRoot\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -NoProfile -NonInteractive -Command $scriptBlock Exit $returnCode