Secnora INC

10/20/2026

👤 𝗛𝘂𝗺𝗮𝗻 𝗮𝗽𝗽𝗿𝗼𝘃𝗮𝗹 𝗶𝘀 𝗮 𝘂𝘀𝗲𝗳𝘂𝗹 𝗰𝗼𝗻𝘁𝗿𝗼𝗹 𝗳𝗼𝗿 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀, 𝗯𝘂𝘁 𝗮𝘀 𝗮 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗯𝗼𝘂𝗻𝗱𝗮𝗿𝘆 𝗶𝘁 𝗵𝗮𝘀 𝗹𝗶𝗺𝗶𝘁𝘀

A human clicking "Approve" does not necessarily mean the action being authorised is the action that will execute.

As AI agents which are autonomous gain access to production systems, to cloud infrastructure and to enterprise APIs, human-in-the-loop (HITL) approval is becoming a common form of safeguard since it provides oversight and accountability. A security boundary, on the other hand has a more limited role, it must hold whenever a component behaves in an unexpected way, no matter what context the reviewer was in at that time.

The approval gap can appear in a few places.

A reviewer could end up seeing a natural-language summary rather than the exact details of the operation and the target resources. Since the agent is the one that produces the summary, if untrusted content affects it by means of prompt injection, then it can also influence the approval prompt. OWASP includes prompt injection as item LLM01 in its Top 10 for LLM Applications.

Approvals can also become older or broader. Parameters can change between authorisation and ex*****on and one approval can start further tool calls that receive less scrutiny. The large volume of prompts contributes to the problem even careful reviewers have a limited amount of time available for each decision and this is a matter of system design rather than something that reflects on the people carrying out the reviews.

Approval means more when it is bound to the executed operation, parameters and target included, rather than to the agent's description of its intent.

For security leaders, a few controls can narrow the gap:
🔹 Independent policy enforcement. Checks outside the model validate each tool call against permissions, scope and permitted operations.
🔹 Execution-bound approvals. Sign-off covers the specific action and parameters with revalidation when material details change.
🔹 Least-privilege, short-lived credentials. With sandboxing and egress allow-listing, they limit how far one approved action can reach.
🔹 Audit trails. Linking the request, the context shown and the actual ex*****on gives teams a reliable record after an incident.
🔹 Human approval for high-impact or irreversible actions. Fewer prompts mean each one gets proper attention.

No control completely eliminates all risk and human oversight is still useful for making judgements and understanding the business context, whereas the enforcement of permissions and scope should be incorporated into the system architecture.

For CISOs and security architects, a practical starting point is to document what "Approve" authorises for each agent with production access and which control enforces that limit.

🎯 A human can authorise an action. The system should still enforce what that authorisation permits.

10/19/2026

🚨 𝗚𝗵𝗼𝘀𝘁𝗔𝗰𝘁𝗶𝗼𝗻 𝗖𝗮𝗺𝗽𝗮𝗶𝗴𝗻 𝗨𝘀𝗲𝘀 𝗔𝗯𝗼𝘂𝘁 𝟭,𝟵𝟬𝟬 𝗖𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲𝗱 𝗚𝗶𝘁𝗛𝘂𝗯 𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝘀 𝘁𝗼 𝗧𝗮𝗿𝗴𝗲𝘁 𝟯𝟬,𝟬𝟬𝟬+ 𝗥𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝗶𝗲𝘀

The credential theft campaign known as GhostAction accelerated in early October 2026, targeting more than 30,000 repositories. The spike resulted from the compromise of about 1,900 GitHub accounts. The campaign has been active since 2025 and according to researchers, never really stopped. The latest wave was larger than earlier ones and appears to rely in part on old, unrotated secrets.

📊 𝗧𝗵𝗲 𝗦𝗰𝗮𝗹𝗲
The campaign attempted to extract thousands of secrets from the CI environments of public repositories. It has targeted CI/CD secrets, cloud credentials, registry tokens such as npm, PyPI and DockerHub and AI provider API keys.

🛠️ 𝗛𝗼𝘄 𝗜𝘁 𝗪𝗼𝗿𝗸𝘀
Attackers appear to gain write access to repositories using stolen credentials, likely sourced from leaked tokens, infostealer logs and credential dumps. Using the hijacked maintainer account, they push a malicious workflow file disguised under deceptive names such as security-audit.yml or github_actions_security.yml.

🔄 𝗣𝗮𝘆𝗹𝗼𝗮𝗱 𝗘𝘃𝗼𝗹𝘂𝘁𝗶𝗼𝗻
• The first version added a git history secret-scanning feature to hunt for AWS key IDs, GitHub and GitLab personal access tokens, AI-related secrets and other cloud secrets.
• The second version added context retrieval around AWS key IDs to extract the corresponding secrets.
• The final version added support for retrieving that secret context during the git history scan itself.

🚀 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗣𝗵𝗮𝘀𝗲𝘀
The payload was deployed in multiple phases, first against previously observed victims and then against a much larger set of new repositories. Some of the victims had already been compromised in earlier waves which suggests the threat actors are likely relying in part on secrets that were never rotated. GitHub started preventing the malicious workflow from running on October 9, so later waves using the same payload could not extract any secrets.

✅ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• Rotate every secret that may have been exposed. Repeat victims suggest old, unrotated secrets are being reused.
• Find and revoke the GitHub credential that allowed the workflow injection, otherwise it can be used again.
• Tighten governance of developer accounts and tokens, since compromised credentials appear to be the entry point.

🔐 Strengthening CI/CD security starts with knowing which credentials exist, who can change workflows and how quickly exposed secrets can be rotated.

🔗 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲: https://blog.gitguardian.com/ghostaction-github-actions-supply-chain-attack-returns/

10/16/2026

🚨 𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘄𝗵𝗲𝗻 𝗮 𝗱𝗿𝗼𝗻𝗲 𝗴𝗲𝘁𝘀 𝗵𝗮𝗰𝗸𝗲𝗱 𝗶𝗻 𝗺𝗶𝗱𝗮𝗶𝗿?

Drones are no longer just flying cameras. They're connected computers operating in increasingly sensitive environments. And that makes cybersecurity a serious concern.

🎙️ In the latest episode of 𝗦𝗲𝗰𝘂𝗿𝗲 𝗯𝘆 𝗗𝗲𝘀𝗶𝗴𝗻, powered by 𝗦𝗲𝗰𝗻𝗼𝗿𝗮, our host 𝗗𝗮𝗻𝗶𝗲𝗹 𝗞𝘂𝗹𝗶𝗴 sits down with 𝗠𝗶𝗰𝗵𝗮𝗲𝗹 𝗛𝗶𝗹𝗹, known as "𝗧𝗵𝗲 𝗗𝗿𝗼𝗻𝗲 𝗣𝗿𝗼𝗧𝗠️", to explore the rapidly evolving world of drone technology and cybersecurity.

From GPS spoofing and autonomous flight to data protection, supply chain vulnerabilities, and real-world cyber threats, this conversation reveals why securing the skies is becoming just as important as securing our networks.

Michael brings years of hands-on experience and a fascinating perspective on where the drone industry is heading.

🎧 𝗖𝗮𝘁𝗰𝗵 𝘁𝗵𝗲 𝗳𝘂𝗹𝗹 𝗰𝗼𝗻𝘃𝗲𝗿𝘀𝗮𝘁𝗶𝗼𝗻:
▶️ Spotify: https://open.spotify.com/episode/3jXMCDFJNqnwjAefHCU7G9?si=QeVB-LuuT724v8UQs6kOYw

𝗧𝗵𝗲 𝗳𝘂𝘁𝘂𝗿𝗲 𝗼𝗳 𝗮𝘃𝗶𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗮𝘂𝘁𝗼𝗻𝗼𝗺𝗼𝘂𝘀. 𝗕𝘂𝘁 𝗶𝘀 𝗶𝘁 𝘀𝗲𝗰𝘂𝗿𝗲?

SECNORA Podcast · Episode

10/14/2026

🔍 𝗙𝗼𝗿𝗲𝗻𝘀𝗶𝗰 𝗔𝘁𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻 𝗼𝗳 𝗔𝗜-𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗲𝗱 𝗘𝘅𝗽𝗹𝗼𝗶𝘁𝘀

An exploit can run flawlessly without establishing who wrote it or whether AI contributed to its development.

The forensic challenge is separating how the code was developed, how it was executed and who controlled the activity.

🧩 𝗔𝗜 𝗜𝗻𝘃𝗼𝗹𝘃𝗲𝗺𝗲𝗻𝘁 ≠ 𝗔𝗰𝘁𝗼𝗿 𝗔𝘁𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻
"AI-generated" means AI-assisted development, code generated by a specific model or a process directed by a particular actor. Each claim needs separate evidence, since proving one does not prove the others. Exploits may combine generated snippets, public proof-of-concept code and manual edits. Inherited bugs, unusual constants and copied typos are code-lineage clues, not proof of AI involvement. Compare against known implementations before attributing similarities to a source.

⚖️ 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝘃𝘀. 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗘𝘃𝗶𝗱𝗲𝗻𝗰𝗲
Development evidence includes repository history, IDE or agent session records, prompt logs and provider API records. In order to link an AI response to a recovered exploit, it is necessary to obtain corroboration by means of a code comparison, examination of file revisions or use of hashes.

Evidence relating to ex*****on such as process trees, command lines, network flows and memory artifacts can show how an exploit was carried out, not how it was developed.

The git history should be examined since the dates for both author and committer can be configured, rebases and amended commits have the ability to rewrite the history and the compile timestamps can be changed or set to zero. Checks should be made by comparing the commits with the records kept by the hosting platform with the local reflogs and with other independent evidence.

🧪 𝗪𝗵𝘆 𝗖𝗼𝗱𝗲-𝗕𝗮𝘀𝗲𝗱 𝗔𝘁𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻 𝗛𝗮𝘀 𝗟𝗶𝗺𝗶𝘁𝘀
Even with corroboration, code-based methods have limitations. Formatting, renaming and structural changes can weaken stylometry and code watermarks. A missing watermark doesn't prove human authorship and a detected one does not identify the operator. Evidence independence matters too. Multiple artifacts derived from one compromised log do not constitute independent confirmation.

🔗 𝗕𝘂𝗶𝗹𝗱 𝗮 𝗗𝗲𝗳𝗲𝗻𝘀𝗶𝗯𝗹𝗲 𝗙𝗶𝗻𝗱𝗶𝗻𝗴
The strongest approach tests competing hypotheses, preserves evidence, hashes acquired artifacts and maintains chain of custody. Timestamp normalization should account for clock differences and uncertainty.

Classify conclusions as Observed, Inferred or Unresolved to distinguish direct evidence from interpretation and remaining gaps. "Consistent with AI assistance" may be defensible. Attributing code to a specific model and actor requires corroborating evidence.

🎯 AI exploit attribution is a provenance investigation, not a code-styling verdict. The strength of the conclusion must match the strength of the evidence.

10/12/2026

🚨 𝗚𝗼𝗕𝗮𝗹𝗮𝗻𝗰𝗲 𝗙𝗹𝗮𝘄 𝗣𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹𝗹𝘆 𝗘𝘅𝗽𝗼𝘀𝗲𝘀 .𝗼𝗻𝗶𝗼𝗻 𝗔𝗱𝗱𝗿𝗲𝘀𝘀𝗲𝘀 𝘁𝗼 𝗛𝗶𝗷𝗮𝗰𝗸 𝗮𝘀 𝗔𝘁𝘁𝗮𝗰𝗸𝗲𝗿𝘀 𝗥𝗲𝗰𝗼𝘃𝗲𝗿 𝗠𝗮𝘀𝘁𝗲𝗿 𝗦𝗶𝗴𝗻𝗶𝗻𝗴 𝗞𝗲𝘆𝘀

A signing bug in GoBalance lets attackers recover the master signing key behind an affected .onion address from public information alone and redirect it to their own site. Dread, a prominent darknet forum, had its two addresses redirected to a rival platform, Conclave, between 5 and 7 October 2026 and the second takeover is most closely linked to the flaw. Several marketplaces on the same software were also reportedly affected.

🔬 𝗥𝗼𝗼𝘁 𝗖𝗮𝘂𝘀𝗲 𝗶𝗻 𝘁𝗵𝗲 𝗗𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗼𝗿 𝗦𝗶𝗴𝗻𝗶𝗻𝗴 𝗦𝘁𝗲𝗽
An .onion address is a public key, so whoever holds the matching private key controls the address. GoBalance is a Go rewrite of Onionbalance. A Tor private key is 64 bytes and GoBalance passed only the first 32 to the signer. The dropped half is what keeps each signature’s nonce secret. Without it, the nonce becomes publicly computable, so a single public descriptor carries enough information to recover the master secret scalar.

🎯 𝗔𝗳𝗳𝗲𝗰𝘁𝗲𝗱 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻𝘀
GoBalance ships with EndGame, a toolkit built by darknet operators to keep sites online during DoS attacks. The flaw sits in the Go rewrite only and the original Onionbalance and Tor itself are not affected. Exposure depends on how the master key was created. Sites storing it in Tor’s native format are affected while standard ed25519 keys are not. Dread’s founder says every released version is affected and other hidden services may be too and the full extent is unknown.

🧭 𝗜𝗺𝗽𝗮𝗰𝘁 𝗕𝗼𝘂𝗻𝗱𝗮𝗿𝗶𝗲𝘀
Hijacking an address lets an attacker redirect visitors to a copy of the site. It does not by itself grant access to servers, databases or stored user data. A notice on the hijacked address claimed control of Dread’s key and sensitive data and neither claim is verified. Visitors reach an attacker-run copy, so credential capture or traffic interception remains possible and Dread’s founder advised changing passwords.

🛡️ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• A patch alone does not close the exposure. Because descriptors are public, a vulnerable Tor-format key can be recovered by anyone, so affected operators may need a new address.
• Key handling and code flaws are separate risks. Dread's administrators first blamed the main takeover on a key upload, while the backup takeover is seen as the stronger sign of the flaw.
• Reimplementations carry their own risk. The weakness lies in the Go rewrite and not in Tor or the original Onionbalance, so code that slices or converts key material deserves close review.
• Users should confirm new addresses through signed announcements and avoid unverified mirrors.

🔗 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲: https://www.slcyber.io/research/leaking-the-keys-to-the-kingdom-how-a-single-slip-handed-over-a-darknet-empire

10/09/2026

🚨 𝗖𝗮𝘀𝗲 𝗦𝘁𝘂𝗱𝘆 - 𝗣𝗲𝗻𝘁𝗮𝗴𝗼𝗻 𝗗𝗠𝗗𝗖 𝗕𝗿𝗲𝗮𝗰𝗵: 𝗢𝗻𝗲 𝗙𝗶𝗹𝗲-𝗦𝗵𝗮𝗿𝗶𝗻𝗴 𝗩𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆, 𝗔𝗿𝗼𝘂𝗻𝗱 𝟯 𝗠𝗶𝗹𝗹𝗶𝗼𝗻 𝗣𝗲𝗼𝗽𝗹𝗲 𝗔𝗳𝗳𝗲𝗰𝘁𝗲𝗱

A breach at the Defense Manpower Data Center (DMDC) has exposed the personal data of around 3 million people. Unauthorized users accessed a file-sharing server holding unencrypted personal data for roughly nine months before the vulnerability was discovered. This case is a reminder that a single exposed system holding unencrypted data can contribute to an incident of this scale.

🔍 𝗧𝗵𝗲 𝗧𝗮𝗿𝗴𝗲𝘁 𝗮𝗻𝗱 𝗦𝗰𝗼𝗽𝗲
The DMDC maintains personnel records for the Department of Defense. Reported figures put the breach at approximately 2.76 million living individuals and around 294,000 deceased individuals. The unencrypted data included Social Security numbers, names, dates of birth, contact details and in some cases military occupational specialties. The exposed fields varied by person.

⚙️ 𝗧𝗵𝗲 𝗔𝘁𝘁𝗮𝗰𝗸 𝗩𝗲𝗰𝘁𝗼𝗿
Unauthorized users accessed a DMDC file-sharing server through a security vulnerability. DMDC has not named the affected product, described the flaw or said who was behind the access. It is also unclear whether a patch was available before the issue was discovered, so the root cause remains unconfirmed.

⏳ 𝗧𝗵𝗲 𝗗𝘄𝗲𝗹𝗹 𝗧𝗶𝗺𝗲
Access began in October 2025 and went undetected until July 2026, roughly nine months. A gap of that length may point to limitations in continuous monitoring and anomaly detection, though DMDC has not shared details on how the access occurred or whether it was continuous.

🛡️ 𝗧𝗵𝗲 𝗥𝗲𝗺𝗲𝗱𝗶𝗮𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲
After discovering the vulnerability in July 2026, DMDC updated the file-sharing system to patch it and restored operations. No public claim of responsibility has been reported at the time of writing. Affected individuals are being offered 12 months of credit monitoring.

💡 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• Encrypt Data at Rest: Sensitive PII stored unencrypted on a file-sharing server can significantly increase the impact of any unauthorized access. Strong encryption at rest, combined with tight access controls and data minimisation, is a baseline control for compliance and risk reduction.
• Accelerate Patch Management: File-sharing platforms can be attractive targets for initial access. Timely patching, asset inventory and regular vulnerability scanning help reduce the external attack surface.
• Strengthen Threat Hunting: Automated alerts alone may not surface every intrusion. In this case, the issue appears to have come to light through the vulnerability rather than detection of the access itself. Proactive threat hunting and well-tuned SIEM monitoring can help detect unauthorized access sooner and shorten dwell time.

10/08/2026

🔐 Cybersecurity Awareness Month

Many security incidents begin with an assumption nobody questioned.

Some cybersecurity beliefs sound right until you look a little closer. A strong password, two-factor authentication, a clean-looking email or a familiar search result can all feel like proof that things are safe. But those signals alone don’t always tell the full story.

This Cybersecurity Awareness Month, 10 common cybersecurity beliefs deserve a closer look. They range from MFA and password reuse to fake CAPTCHA pages, sponsored search ads and AI chatbots. Each slide takes one belief and busts it.

The most dangerous assumption is the one you never question.

➡️ Swipe through and see how many of these you have believed. Pause. Verify. Think before you trust.

10/05/2026

🚨 𝗝𝗔𝗗𝗘𝗣𝗨𝗙𝗙𝗘𝗥 (𝗦𝘁𝗼𝗿𝗺-𝟯𝟭𝟲𝟴) 𝗟𝗶𝗻𝗸𝗲𝗱 𝘁𝗼 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗲𝗱 𝗔𝘁𝘁𝗮𝗰𝗸 𝗼𝗻 𝟭𝟬𝟬+ 𝗔𝘇𝘂𝗿𝗲 𝗦𝘁𝗼𝗿𝗮𝗴𝗲 𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝘀

Microsoft recently disclosed Azure activity linked to JADEPUFFER (tracked by Microsoft as Storm-3168), including resource deletion in a compromised Azure environment. Microsoft frames this as part of a broader shift toward AI-orchestrated attacks at greater speed and scale. It did not observe a ransom note or confirm data exfiltration.

🔍 𝗧𝗵𝗲 𝗔𝘁𝘁𝗮𝗰𝗸 𝗩𝗲𝗰𝘁𝗼𝗿 𝗮𝗻𝗱 𝗥𝗲𝗰𝗼𝗻𝗻𝗮𝗶𝘀𝘀𝗮𝗻𝗰𝗲
Microsoft says it is unclear how the service principal was initially compromised. A service principal's client ID, secret and tenant ID had been exposed in a public GitHub issue and remained accessible through its edit history, though Microsoft could not confirm this secret was used in this activity. Two compromised service principals from the same tenant were involved. One performed extended discovery with 300+ successful read operations.

⚡ 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻
The second service principal began deleting resources less than a second after a failed "ListKey" call against a non-existent storage account. Microsoft says the timing and division of work strongly indicate automated or scripted ex*****on. This identity attempted 150+ deletion or credential-collection operations:
• 100+ storage account deletion attempts, most of which succeeded.
• Deletion of a Key Vault, a Function App and an App Service plan.
• Failed attempts against Azure SQL databases (caused by an unsupported API version) and against Site Recovery and Backup protection locks.

🛡️ 𝗪𝗵𝗮𝘁 𝗛𝗲𝗹𝗱 𝗮𝗻𝗱 𝗪𝗵𝗮𝘁 𝗗𝗶𝗱𝗻'𝘁
The identity held Storage Account Contributor, Contributor and SQL DB Contributor roles. Even so, Azure resource locks and storage account deletion protection blocked deletion for a few storage accounts, and the attempts against backup protection locks were unsuccessful. Most targeted storage accounts were still deleted. This shows that independent safeguards can remain effective even when a compromised identity has broad administrative permissions.

💡 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗰 𝗗𝗲𝗳𝗲𝗻𝗰𝗲 𝗥𝗲𝗰𝗼𝗺𝗺𝗲𝗻𝗱𝗮𝘁𝗶𝗼𝗻𝘀
• Govern non-human identities and workload service principals under least privilege.
• Treat any publicly exposed credential as compromised. Rotate it and investigate its historical use because editing or deleting the post does not invalidate it.
• Apply resource locks and backup protections to production storage and recovery infrastructure, independent of identity permissions and monitor attempts to modify or remove them.
• Deploy automated detection and response capabilities that can investigate and respond on the same timescale as automated threats.

🔗 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲: https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/

10/02/2026

🔐 Security tools with standing admin rights can be a higher-value target than the assets they protect

Security platforms are bought to reduce risk. To do that job, many are given broad, persistent privileges across the environment, that makes them high-value control plane and an attractive entry point. What that access often looks like.

🔹 EDR and XDR consoles can push commands and isolate or modify agents across endpoints.
🔹 Vulnerability scanners frequently run with credentialed access to servers, network devices and cloud accounts.
🔹 Backup platforms can read, restore and delete production data.
🔹 Secrets vaults and PAM tools hold the credentials for other systems.
🔹 SIEM and log pipelines hold broad read access and sometimes write access to connected systems.

Compromising a hardened database gives an attacker one foothold. Compromising a tool with authenticated reach into hundreds of systems can provide broad, high-impact access from a single point. Because the tool is trusted and often allow-listed, its activity may also draw less scrutiny.

Standing privilege extends that window. Credentials that stay active, stay elevated and get reviewed infrequently give an adversary time to find and use them.

These tools also tend to sit in an ownership gap. Security teams deploy them, infrastructure teams maintain the servers underneath, and service accounts are created once and rarely revisited. Rollout exceptions such as broad allow-listing or monitoring exclusions can stay in place long after anyone remembers why.

Six controls that shrink the blast radius:

🔹 Map the access: Inventory security tools and service accounts with admin or root rights, and assign each an owner.
🔹 Apply least privilege to the tools: NIST SP 800-53 AC-6 covers least privilege for users and processes acting on their behalf including service accounts.
🔹 Use just-in-time access: Grant elevated rights for the task and window that need them, then remove them.
🔹 Protect the management plane: Require phishing-resistant MFA, segmentation and a separate admin path for consoles.
🔹 Monitor the tools: Alert on unusual console logins, new integrations, policy changes and bulk actions.
🔹 Test the blast radius: Run a tabletop or red team exercise assuming a tool's console is compromised and record what it could reach.

Start with the platforms that have the widest reach, usually the EDR console, the backup system and the secrets vault. Just-in-time access adds friction, so a monitored break-glass account with a documented approval path can cover urgent incident access without leaving standing rights in place.

NIST SP 800-207 on Zero Trust Architecture states that implicit trust is not granted to assets based on network location or ownership. Security tooling falls under the same principle.

🎯 For every privileged security tool, one question is worth asking, what could an attacker reach if it is compromised?

09/30/2026

🚨 𝗥𝗲𝗽𝗹𝗮𝘆𝗮𝗯𝗹𝗲 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿 𝗧𝗼𝗸𝗲𝗻𝘀: 𝗔 𝗚𝗮𝗽 𝗶𝗻 𝗖𝗹𝗼𝘂𝗱 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻

Multi-Factor Authentication remains a key safeguard for cloud identities. Infostealer activity also shows that the protection it provides depends on how issued tokens are handled. When threat actors obtain replayable provider tokens, they can bypass the login step.

🛠️ 𝗧𝗵𝗲 𝗠𝗲𝗰𝗵𝗮𝗻𝗶𝗰𝘀 𝗼𝗳 𝗧𝗼𝗸𝗲𝗻 𝗥𝗲𝗽𝗹𝗮𝘆
Infostealer families such as LummaC2 and Vidar collect saved passwords and also target session cookies, Microsoft Entra ID tokens and OAuth access tokens from browser storage. Because bearer tokens act as proof of identity, a stolen token replayed from another browser or script may grant access without a new login prompt. Long-lived AWS access keys in local files on developer machines present a separate exposure.

🔍 𝗛𝗼𝘄 𝗮 𝗧𝗼𝗸𝗲𝗻 𝗥𝗲𝗽𝗹𝗮𝘆 𝗔𝘁𝘁𝗮𝗰𝗸 𝗨𝗻𝗳𝗼𝗹𝗱𝘀
• An employee installs software from an untrusted source or runs a command from a fake verification prompt and an infostealer executes on the endpoint.
• The malware collects saved passwords, session cookies and tokens from the browser and sends them to the operator as a log.
• Logs can be traded or sold, so the person who uses the session may not be the one who infected the device.
• A threat actor loads the valid session into their own browser or script. The identity provider may see a valid token and no failed login is generated.
• Access may continue until the session expires or is revoked.

🛡️ 𝗪𝗵𝗲𝗿𝗲 𝗧𝗿𝗮𝗱𝗶𝘁𝗶𝗼𝗻𝗮𝗹 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝘀 𝗛𝗮𝘃𝗲 𝗟𝗶𝗺𝗶𝘁𝘀
MFA and conditional access policies mainly protect the initial sign-in. Once a token is issued, the session is generally trusted until it expires or is revoked. A replayed cookie can resemble normal activity and no failed login attempts are generated to trigger an alert. Some platforms such as Entra ID Protection, provide anomalous token detections and availability depends on licensing and application support.

⚙️ 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗥𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝘁 𝗗𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗗𝗲𝗳𝗲𝗻𝗰𝗲
Organisations can reduce token replay risk by pairing strong authentication with continuous monitoring:
• Endpoint Visibility: Monitoring for non-browser processes reading browser cookie databases, credential stores or files such as ~/.aws/credentials can surface infostealer activity.
• Proactive Threat Intelligence: Monitoring infostealer log sources for corporate session cookies supports early detection and faster token revocation.
• Continuous Access Evaluation and Token Binding: Continuous Access Evaluation enables near-real-time revocation after events such as password resets. Where supported, token binding such as Entra Token Protection or Device Bound Session Credentials can reduce the value of a token replayed from an unrecognised device, though protection is limited if the attacker operates on the compromised device.