LoFP LoFP / t1552

t1552

TitleTags
a newly installed program or one that runs very rarely as part of a monthly or quarterly workflow could trigger this detection rule.
a newly installed program, or one that runs under a new or rarely used user context, could trigger this detection rule. manual interrogation of the metadata service during debugging or troubleshooting could trigger this rule.
a service principal used by a ci/cd pipeline may trigger this rule when the pipeline runs from a new ip range for the first time (e.g., migrating to a new runner pool). the 7-day history window will learn the new ips after the first occurrence.
a user may generate a shared access link to encryption key files to share with others. it is unlikely that the intended recipient is an external or anonymous user.
administrative activity
administrative or software activity
administrators accessing arc clusters from a new vpn endpoint or travel location. validate the caller identity matches an expected user and correlate with known travel or access patterns.
administrators reading kubeconfig or cloud profiles during migration can match; correlate with change tickets and bastion sessions.
administrators using service principal credentials to manage arc-connected clusters during maintenance windows may trigger this rule. correlate with change management records.
an agentcore agent that legitimately integrates with additional aws services will produce a first-time service call for its execution role. verify the role in \"aws.cloudtrail.user_identity.session_context.session_issuer.arn\", the action in \"event.action\" and \"event.provider\", and the origin in \"source.ip\" and \"source.as.organization.name\", and confirm the activity matches the agent's intended design. known agent integrations can be excluded after validation.
applications that intentionally allow unauthenticated identity pool access for legitimate purposes (for example, anonymous usage analytics or unauthenticated content delivery) will trigger this rule the first time that pattern is observed for a given identity pool. confirm whether the pool's unauthenticated role grants only the minimal permissions the application actually needs, and treat repeated alerts for the same pool as expected once validated.
approved scripts, ci jobs, or penetration tests may use generic http clients. validate tickets and identity scope before treating as compromise.
as the script block is a blob of text. false positive may occur with scripts that contain the keyword as a reference or simply use it for detection.
authorization rule additions or modifications 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. authorization rule additions or modifications from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
automated processes may need to take these actions and may need to be filtered.
automation, ci runners, and platform engineering scripts may legitimately print tokens or dump kubeconfig across providers in one session. baseline approved identities and runner images before tuning thresholds.
azure arc system components may create or update secrets and configmaps in the azure-arc and azure-arc-release namespaces during normal cluster management. filter by namespace to exclude these.
azure kubernetes admissions controller may be done by a system administrator.
backup, configuration management, and image scanners may open the same paths from scripted utilities; baseline trusted agents and narrow exclusions by process executable hash or parent chain.
break-glass debugging from platform engineers may include curl to the metadata ip or hostname.
break-glass debugging or vendor diagnostics may cat credential-adjacent paths. baseline approved operators and automation identities, then expand client.user.email exclusions as needed.
ci/cd pipelines that authenticate as a service principal and then access arc clusters as part of deployment workflows will trigger this rule. identify and exclude known automation service principal app ids.
cloud agents (ssm, waagent, cloud-init, instance connect) and authorized scanners may reach the same paths during provisioning or health checks. exclude known agent user agents, source hosts, or parent processes after baselining.
commonly run by administrators
credential reads under non-root home trees are intentionally excluded; clone the rule with explicit per-user file.path values and optional process.executable prefixes if you must cover interactive accounts with matching audit -w lines for those paths.
developer or documentation content that legitimately discusses the instance metadata service or aws key formats could match. review the prompt in \"aws.bedrock_agentcore.request_payload.prompt\" to confirm intent.
documentation, examples, or test content may include sample key material. confirm whether the key is live by reviewing \"aws.bedrock_agentcore.request_payload.prompt\" and the originating session and application.
engineers creating key pairs from home isp, corporate vpn, or colocation as names will match until baselined. geoip databases vary by vendor; organization labels may differ slightly from the excluded strings (for example alternate amazon or google legal names). tune exclusions on `source.as.organization.name` or principal arn after validation.
engineers listing secrets from home isp or corporate vpn as names may match until baselined. geoip organization labels vary by vendor; tune exclusions after validation.
files that accidentally contain these strings
gitleaks is a legitimate open-source tool used by security professionals and developers to search for sensitive information, such as passwords, api keys, and other secrets, within code repositories. it is commonly employed during security assessments and code reviews to identify potential vulnerabilities.
google cloud kubernetes admission controller may be done by a system administrator.
helm operations managed through arc may create release secrets (prefixed with sh.helm.release.v1). these are normal arc lifecycle operations.
if known behavior is causing false positives, it can be exempted from the rule.
in-cluster operators, csi drivers, gitops agents, and some platform controllers legitimately list or get secrets in namespaces they manage; exclude known service accounts, namespaces, or user agents after baselining.
internal automation built with generic libraries can resemble suspicious user agents; baseline known jobs and tune by service account, namespace, or stable source ip allowlists.
it's recommended that you rotate your access keys periodically to help keep your storage account secure. normal key rotation can be exempted from the rule. an abnormal time frame and/or a key rotation from unfamiliar users, hosts, or locations should be investigated.
key being modified or deleted may be performed by a system administrator.
key modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
key vault being modified or deleted may be performed by a system administrator.
key vault modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
legitimate access of the console history file is possible
legitimate administration activities
legitimate backup, compliance scanners, or admin scripts that enumerate paths under /home or /var/run/secrets may match. tune by parent process, image, or automation identity.
legitimate certificate exports by administrators. additional filters might be required.
legitimate ci/cd pipelines, infrastructure tooling, or configuration management systems may retrieve secret files from s3 as part of their normal operation. validate the calling identity, user agent, and source ip against known automation accounts and expected access patterns.
legitimate pre-commit hooks or ci/cd pipeline jobs that use a script to run a credential scanner as part of a security check.
legitimate software, cleaning hist file
legitimate usage of chflags by administrators and users.
legitimate usage of the utility by administrators to query the event log
legitimate use of trufflehog by security teams or developers.
legitimate users may travel, rotate through vpn egress ips, or run automation from new build hosts, producing a first-seen ip for an existing access key. baseline the principal, confirm with the key owner, and extend the history window or add exceptions for known automation networks if needed.
microsoft windows installers leveraging rundll32 for installation.
modifying the kubernetes admission controller may need to be done by a system administrator.
new automation, admission webhooks, or platform agents that legitimately call the tokenrequest api under a non-standard user string may require narrow exclusions by user.name or source ip.
not commonly run by administrators, especially if remote logging is configured
not commonly run by administrators. also whitelist your known good certificates
operators may use ad hoc http clients, scripts, or penetration-test images during approved exercises or break-glass maintenance; validate tickets, source ip, and identity before treating as compromise.
platform agents, admission webhooks, and ci jobs may legitimately call tokenrequest under non-standard identities. baseline approved automation by client.user.email after validation. expected gke and kube-system controllers are excluded; expand exclusions if additional managed components appear in telemetry.
prompts or completions that reference example or documentation keys (for example the aws sample access key ending in example) match the access-key pattern. review the matched value in \"gen_ai.prompt\" or \"gen_ai.completion\" and confirm whether it is a live credential before responding.
rare kubelet or node maintenance tooling may touch secret apis; validate against change windows and approved node management paths.
secrets being modified or deleted may be performed by a system administrator.
secrets modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
security testing, red-team exercises, or guardrail validation may intentionally send prompt-injection or credential-harvesting payloads to an agent. confirm the source session and caller, and exclude approved testing identities after validation.
startup, helm, or controllers may legitimately touch many secrets in one window; tune by client.user.email, namespace, or ip allowlists when baselined.
support engineers, infrastructure-as-code, and vm health automation may legitimately retrieve boot diagnostics during troubleshooting. the first occurrence per principal will alert; baseline expected support users, service principals, and managed identities and exclude them if the activity is verified as authorized.
the kubernetes dashboard occasionally accesses the kubernetes-dashboard-key-holder secret
the same automation identity may legitimately trigger a first-seen-ip alert and unrelated medium-or-higher findings in the same window (for example, a noisy compliance rule). review sibling `kibana.alert.rule.name` values, rule tags, and cloudtrail context for the access key before escalating.
there is a potential for false positives if the access to the service account token or certificate is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the service account token or certificate is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a risk of false positives if there are several containers named the same, as the rule may correlate the request to the wrong container.
this is an intentional action taken by aws in the event of compromised credentials. follow the instructions specified in the support case created for you regarding this event.
this is very uncommon behavior and should result in minimal false positives, ensure validity of the triggered event and include exceptions where necessary.
trufflehog is a legitimate open-source tool used by security professionals and developers to search for sensitive information, such as passwords, api keys, and other secrets, within code repositories. it is commonly employed during security assessments and code reviews to identify potential vulnerabilities.
unknown
unlikely
when a new application owner is added by an administrator
when and administrator is making legitimate appid uri configuration changes to an application. this should be a planned event.