LoFP LoFP / t1550

t1550

TitleTags
a service principal may be created by a system or network administrator. verify whether the username, hostname, and/or resource name should be making changes in your environment. service principal additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a user may have multiple sessions open at the same time, such as on a mobile device and a laptop.
administrator activity
although highly unlikely, legitimate applications may use the same command line parameters as mimikatz.
although unlikely, legitimate applications may use the same command line parameters as rubeus. filter as needed.
application credential additions 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. application credential additions from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
applications integrated with aws might assume roles to access aws resources.
assumerole from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
assumerole may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
automated processes that uses terraform may lead to false positives.
automated workflows might assume roles to perform periodic tasks such as data backups, updates, or deployments.
aws administrators or automated processes might regularly assume roles for legitimate administrative purposes.
aws services might assume roles to access aws resources as part of their standard operations.
custom applications may leverage the kerberos protocol. filter as needed.
developers may leverage third-party applications for legitimate purposes in google workspace such as for administrative tasks.
environments that use ntlmv1
getsessiontoken may be done by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. getsessiontoken from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
getsignintoken events will occur when using aws sso portal to login and will generate false positives if you do not filter for the expected user agent(s), see filter. non-sso configured roles would be abnormal and should be investigated.
go utilities that use staaldraad awesome ntlm library
if key credentials are regularly assigned to users, these events will need to be tuned out.
legacy hosts
legitimate applications may obtain a handle for winlogon.exe. filter as needed
legitimate logon activity by authorized ntlm systems may be detected by this search. please investigate as appropriate.
legitimate remote administration activity
role chaining can be used as an access control. ensure that this behavior is not part of a legitimate operation before taking action.
runas command-line tool using /netonly parameter
saml provider being updated from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
sts:getsessiontoken can be very noisy as in certain environments numerous calls of this type can be executed. this search can be adjusted to provide specific values to identify cases of abuse. in specific environments the use of field requestparameters.serialnumber will need to be used.
this is very uncommon behavior and should result in minimal false positives, ensure validity of the triggered event and include exceptions where necessary.
unlikely
web browsers and third party application might generate similar activity. an initial baseline is required.