LoFP LoFP / T1651

T1651

TitleTags
automated configuration management or monitoring scripts that use lolbins via ssm for legitimate purposes. consider excluding known automation accounts or specific command patterns.
command execution on a virtual machine may be done by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. command execution from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
infrastructure-as-code, configuration management, and patching automation may create or update managed run commands. the first occurrence per principal will alert; baseline expected service principals, managed identities, and admin users and exclude them if the activity is verified as authorized.
infrastructure-as-code, configuration management, and patching automation routinely create, update, and delete vm extensions. the first time a given extension resource name is operated on from a new source as number will alert. baseline expected management networks (corporate egress, ci/cd runners, third-party automation saas) and exclude their as numbers if the activity is verified as authorized. read operations are typically not emitted to the azure activity log; the rule predominantly fires on write and delete.
legitimate administrative tasks using ssm to run system utilities may trigger this rule. review the command context, user identity, and timing to determine if the activity is authorized.
legitimate administrators and automation may deploy custom script, run command, dsc, or monitoring extensions during provisioning, patching, or guest configuration. baseline expected principals, vms, and extension types before tuning exclusions.
legitimate automation that deploys configuration via azure run command and launches powershell with unrestricted policy and numbered script files (for example `script1.ps1`) may match. baseline known deployment pipelines, vm names, and principal ids before tuning.
legitimate configuration management, extension deployment, or automation that uses azure run command with the same powershell or shell script paths may match. baseline approved vm names, script naming, and deployment windows before tuning.
legitimate operators using aws systems manager session manager to administer instances will spawn child processes under the session worker. tune with host, user, or command-line exclusions for known automation and break-glass workflows.
legitimate provisioning, patching, and configuration-management automation may deploy an extension to a host for the first time. the first occurrence per host will alert. baseline expected automation principals and hosts and exclude verified-benign ones.
legitimate use of the `sendcommand` api call to execute commands on ec2 instances using the ssm service may be done by system administrators or devops engineers for legitimate purposes.
legitimate users may create ssm command documents for legitimate purposes. ensure that the document is authorized and the user is known before taking action.
the ssm agent may invoke short-lived utilities (for example identity or environment probes) during session setup. additional exclusions may be required in your environment.
the vast majority of vm writes are benign: provisioning, resizing, tagging, extension/identity changes, autoscale, and configuration management by users, service principals, and managed identities. this rule is informational only and is intended for correlation and baselining, not standalone alerting.
topic creations may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. topic creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
verify whether the user identity should be using the triggered api. if known behavior is causing false positives, it can be exempted from the rule. the \"history_window_start\" value can be modified to reflect the expected frequency of known activity within a particular environment.