标签：#SEC

Disclosure: I work on Tessera, which is one of the tools in the gap I am describing. Ask a fifty-person engineering organisation how they control production access and you will hear the same answer with small variations: a bastion host, SSH keys distributed by configuration management, a shared kubeconfig somewhere, and a spreadsheet or a Notion page that is out of date. Nobody chose that. It is what remains after the alternatives were priced. How the category got shaped Privileged access management grew up serving banks, telcos and governments in the 2000s. Those buyers had specific characteristics: thousands of administrators, regulators with written opinions, dedicated security teams, and procurement processes measured in quarters. Products shaped themselves accordingly. Six-figure entry prices. Deployments measured in months with professional services attached. Feature sets covering every mainframe and network appliance in a bank's estate. Sales motions that start with a discovery call and a mutual NDA. That was a reasonable fit for those buyers. It is a terrible fit for a company with sixty engineers, no dedicated security team, one person who is security-adjacent, and a procurement process that consists of a founder approving a card payment. So the mid-market did what people do when a category prices them out: they built the minimum themselves. A bastion is a bastion because it was free and it was Tuesday. The problem this leaves The bastion answer works, up to a point, and it is worth being specific about where the point is. A bastion controls the door. It does not control the room. Once someone is through, there is no per-command record, no way to reduce their privileges while they are working, and no session replay. And keys still have to be distributed and revoked behind it, which means the original problem is intact — it just has a nicer front entrance. Three things then converge, usually in the same year: The first enterprise customer. Their security que

Disclosure: I work on an access tool (Tessera), mentioned once at the end. Everything before that is about evidence, and applies whatever you use. The most common surprise in a first SOC 2 or ISO 27001 audit is not that a control is missing. It is that a control exists, works, and cannot be evidenced — so it counts as absent. The distinction is worth stating precisely, because it is not obvious until it has cost you something. A control is a thing that is true about your system. Only authorised engineers can reach production. Evidence is an artefact, produced by a system rather than by a person, that demonstrates the control was operating throughout the audit period — not on the day someone checked. Most organisations have decent controls. Most cannot produce evidence, because their controls live in places that do not emit artefacts: a bastion's authorized_keys file, a spreadsheet, a Slack thread where someone approved something, and the collective memory of three engineers. What gets asked for Reconstructed from what people have told me, this is the shape of the questions: "Show me everyone who could access production on 14 March." Not today. A specific date in the past, usually chosen by the auditor. This is the one that catches people, because most systems can tell you the current state and cannot tell you a historical one. authorized_keys has no history. A spreadsheet has whatever history git gives it, if it is in git, which it usually is not. "Show me that this person's access ended when their employment ended." Both timestamps, from two systems, matched. HR has the first. The second is the problem. "Show me the approval for this elevated access." Not that a policy requires approval — the specific approval, for this specific grant, with who approved it and when. "Show me what was done in this session." Increasingly common where production access to customer data is involved. Not "we log commands", but the actual record for a named session. "Show me that these c

Disclosure: I work on Tessera, which is self-hosted. That is the position I am arguing from, and the costs of that position are in the last section. Security questionnaires ask where customer data is processed. Access-control tools tend to get a shallow answer to that question, because people think of them as gatekeepers rather than as data processors. They are both. Here is what a hosted access broker necessarily knows about you. Your infrastructure inventory. Every registered target: hostnames, addresses, cluster endpoints, database names, environment labels. That is a map of your estate, and it is the document an attacker would most like to read before deciding where to spend effort. Your organisational structure. Who has access to what, which teams exist, who approves for whom, who was granted production access at 2am during an incident. Org charts are inferable from access graphs with unpleasant accuracy. Your session content, if recording is on. Every command, every query, every screen of output. That includes whatever your engineers pasted into a terminal, which — be honest about your own estate here — includes secrets sometimes. Timing. When your incidents happen, how long they last, who gets pulled in. That is commercially sensitive on its own. None of that requires the vendor to hold your credentials. It is the metadata, and the metadata is the part that survives every architectural mitigation. Where this shows up GDPR and processor chains. Session recordings contain personal data — identified individuals performing identified actions at identified times. A hosted vendor is a processor, which means a DPA, transfer mechanisms if data leaves the EEA, and a sub-processor list you have to monitor. It also means their sub-processors become your problem, which is a chain you do not control and cannot easily audit. Sector rules. Financial services, healthcare and public sector procurement in most European jurisdictions have specific requirements about where data

Disclosure: I work on Tessera, which is on the buy side of this. I have tried to cost the build side properly, because a comparison where the build option looks stupid is a comparison nobody believes. Every engineering team that has this problem considers building it. That instinct is correct. SSH certificates are a well-understood, well-documented mechanism, everything you need ships with OpenSSH, and the first working version takes a competent engineer about a week. The week is not the cost. Here is what is. The build, honestly The CA itself. You generate a key pair, configure targets with TrustedUserCAKeys , and sign user keys with a short validity. This part genuinely is a week, and it works. Protecting the CA key. This is where the estimate starts moving. The CA private key can now grant access to every host in the fleet. On a laptop it is an incident waiting to happen. So you want it in an HSM or a KMS, which means an integration, which means the signing operation now has an availability dependency, which means a runbook for what happens when that dependency is down. Call it two to four weeks including the operational work. Issuance. Someone has to request a certificate and something has to decide whether to give them one. That means integrating with your identity provider, mapping groups to principals, building a request path, and building an approval path if you want anything time-boxed or justified. This is the real project, and it is measured in months rather than weeks, because it is where the requirements keep arriving. Rollout across the estate. Editing sshd_config on every production host. Technically trivial, organisationally not: change window, sign-off, rollback plan, and the discovery that four hosts are not in configuration management and one of them is important. Audit. Certificates tell you a session was authorised. They do not tell you what happened in it. If your requirement includes per-command history or session replay — and if you have audi

Disclosure: these are decisions from Tessera, which I work on. They are all small enough to copy into your own service, which is why they are worth writing up. Security feature lists are made of nouns: encryption, RBAC, SSO, audit. The things that actually decide whether a system holds up are smaller than that and never make the list. Here are four of ours, with the reasoning, including the case where we made the trade in the direction most people do not. 1. The login rate limit ignores X-Forwarded-For Rate limiting a login endpoint is table stakes. The question is what you count against. The natural implementation reads X-Forwarded-For , because your service is behind a load balancer and the real client address is in that header. Almost every tutorial does it this way. The problem: X-Forwarded-For is a request header. If your service trusts it, an attacker sets a different value on every request and each one gets its own bucket. You have not built a rate limit, you have built a counter that resets on demand, and the dashboards will look perfectly healthy while the endpoint is being brute-forced. We count against the real TCP connection address instead. That is the peer address of the socket, which an attacker cannot forge without actually controlling that address. The cost is real and worth naming. Behind a reverse proxy, every request arrives from the proxy's address, so the limit applies to the proxy as a whole rather than per client. That is a worse experience in some topologies, and people will file bugs about it. We took that trade because a rate limit that can be bypassed by setting a header is not a degraded rate limit, it is the absence of one — and the absence is worse than useless, because it looks like presence. If you do want per-client limits behind a proxy, the answer is an explicit allowlist of trusted proxy addresses whose forwarded headers you accept, not blanket trust of a header. 2. Target addresses are validated to prevent SSRF Our controller is

Disclosure: I work on Tessera, which is one of the proxy-shaped tools. Both shapes are legitimate and I try to be fair to the other one below. Most comparisons of access-control tools start with feature tables. That is the wrong end. The decision that actually determines whether a rollout finishes is the deployment shape, and there are only two. Shape one: agents and certificates You run an internal certificate authority. Hosts are configured to trust it. Users get certificates that expire in a few hours. For Kubernetes, an agent runs inside the cluster and brokers access from there. What this buys you is genuinely good. Expiry does revocation automatically, which removes the human step that fails. The credential on the user's laptop is worthless tomorrow. The model scales well because the CA does not sit in the data path — once the certificate is issued, the user talks to the target directly, so there is no proxy to size and no bandwidth to plan. What it costs is that you have to change production before you get anything. sshd_config gets rewritten across the estate to add TrustedUserCAKeys . An agent gets deployed into every cluster. In some setups the tool's binary is copied onto hosts. None of that is technically hard. It is organisationally hard. You need a change window, sign-off from whoever owns those hosts, and a rollback plan — for a project whose entire benefit is "nothing bad will happen later". That conversation is where access-control rollouts stall, and it stalls most reliably in exactly the organisations that need the tool most: the ones where nobody is quite sure who owns which box. The other cost is that the CA private key becomes the most sensitive object your company owns, and now you operate a CA. Shape two: a proxy The credential stays on a controller. The user authenticates to the controller. The controller opens its own connection to the target, authenticates with the real credential, and relays. The target sees a normal connection from a nor

Every infrastructure post-mortem contains the same paragraph, and it is never the one anyone expected to write. The initial access was not sophisticated. It was a credential that existed, that worked, and that nobody had a reason to look at — because it had been legitimately issued months earlier, for a reason that had since ended. That is standing access. It is not a vulnerability, so no scan finds it. It is not a misconfiguration, so no posture report flags it. It is the residue of a hundred reasonable decisions: a key added for a migration, a database password shared during an outage, a kubeconfig sent to a contractor who did good work and left on good terms. It stays invisible to the risk register because a risk register asks what could go wrong, and standing access is the record of things that already went right. The distribution problem The mechanism is worth being precise about, because it explains why the usual fixes only partly work. Infrastructure access is almost always handed out rather than granted . A key is copied to a host. A kubeconfig is copied to a laptop. A password is copied into a password manager and then, at two in the morning, into a chat window. Once a credential has been copied, the organisation has permanently lost the ability to list its copies. There is no query that returns the answer. Revocation stops being an operation and becomes an investigation — carried out by people, at the exact moment the person who knew where everything was has left. This is why the honest test of an offboarding process is not "did we remove their access". It is: can we show a third party, at any point in the future, that access ended when we say it ended? Most organisations that pass the first test fail the second, and usually find out during an audit or a due-diligence review, which are the two worst moments to find out. Why the obvious fixes fall short Configuration management as the source of truth is a real improvement. It makes access declarative and pu

The Problem: Testing Across Regions Is Hard If you're a developer, you've probably faced...

1. Overview Article Title : Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams Source : Unit 42 Published Date : 2026-08-31 Original Source : Unit 42 Related Sources : None Related Malware, Threat Groups, CVEs, Products : Spring Ring, PowerShell RAT, Microsoft Teams, Microsoft Quick Assist, Microsoft Edge, Active Directory Severity : High 2. Executive Summary Spring Ring uses external Teams accounts to impersonate corporate IT staff. It uses voice calls to trick targets into running RMM tools or custom malware. In advanced cases, the campaign attempts NTLM Relay against domain controllers using PetitPotam. 3. Attack Flow From External Teams Chat to Attempted Domain Privilege Escalation The attacker sets up an external onmicrosoft.com tenant and a display name to impersonate the IT department. The attacker sends a one-on-one Teams chat to the target, followed immediately by a voice call to build trust and urgency. In Campaign A, the attacker tricks the target into running an RMM tool like Quick Assist to enumerate devices and the domain. The attacker downloads an obfuscated PowerShell RAT, attempts to bypass AMSI, and connects to the C2 server. In Campaign B, the attacker delivers an executable file via an S3 URL tailored to the target, establishing persistence, a hidden Edge instance, and extensions. The attacker uses Python to scan internal TCP/445 and triggers NTLM authentication toward the domain controller. The attacker forces authentication using PetitPotam and attempts to gain domain privileges via NTLM Relay, though this was blocked in observed cases. 4. Attacker Positioning and Execution Location External attackers connecting to Teams from a Microsoft 365 external tenant. After running RMM or malware, the attacker reaches the internal network and Active Directory from the user device. 5. Victim and Administrator Visibility Victim Receives a chat and voice call on Teams from a display name that looks like internal IT staff, followed by

1. Basic Information Article Title : ServiceNow Patches 3 Critical Code Injection Vulnerabilities Source : SecurityWeek Publication Date : 2026-08-31 Original Article : SecurityWeek Related Sources : ServiceNow August 2026 CVE Advisory , BleepingComputer Related Malware, Threat Groups, CVEs, Products : CVE-2026-18885, CVE-2026-18886, CVE-2026-74820, CVE-2026-6876, ServiceNow AI Platform, Now Platform Severity : Critical 2. Executive Summary ServiceNow patched three unauthenticated CVSS 10.0 vulnerabilities—code injection in the GraphQL Composite Data API, an access control flaw in configuration image upload processing, and SQL injection in dynamic schema ORDER BY clauses—along with an unauthenticated sandbox escape in the ServiceNow AI Platform. 3. Attack Flow From Unauthenticated Request to Instance Compromise An attacker sends a crafted request to an externally accessible ServiceNow AI Platform. CVE-2026-18885 causes code injection in the GraphQL Composite Data API. CVE-2026-18886 exploits an access control flaw in configuration image upload processing to create and modify data and escalate privileges. CVE-2026-74820 injects SQL into dynamic ORDER BY clauses to manipulate the underlying database. CVE-2026-6876 escapes the sandbox to execute code within the Now Platform. Successful exploitation can spread to instance data, integration credentials, approval workflows, and external systems. Active exploitation is not observed. 4. Attacker Position and Execution Context An unauthenticated external attacker with network access to the HTTP(S) endpoint of the ServiceNow instance. Operates with the privileges of the Now Platform or the underlying database upon successful exploitation. 5. Visibility for Victims and Administrators Victims Because exploitation requires no user interaction, it may appear on the screen as unauthorized changes to data, settings, permissions, or approval workflows. Administrators Clues include abnormal GraphQL requests, configuration image uploa

1. Basic Information Article Title : Microsoft warns of TerminalFix attacks deploying reverse tunnels Publisher : BleepingComputer Publication Date : 2026-08-31 Original Source : BleepingComputer Related Source : Microsoft Security Research Related Malware / Threat Groups / CVEs / Products : TerminalFix, client.py reverse tunnel, Windows Terminal, PowerShell, LockScreenContentServer.exe, Active Directory Severity : High 2. Executive Summary TerminalFix uses a fake Cloudflare CAPTCHA on compromised websites to trick users into pasting PowerShell commands. It then performs DLL side-loading, extracts payloads from PNG images, establishes dual persistence, and enumerates Active Directory to set up a reverse WebSocket tunnel that reaches the internal network. 3. Attack Flow From Fake CAPTCHA to Network Pivot Point A compromised website displays a fake Cloudflare Turnstile page and copies malicious PowerShell code to the clipboard. The user pastes the code into the terminal, extracting a ZIP file to C:\ProgramData and executing 1.bat . The legitimate LockScreenContentServer.exe side-loads a malicious dui70.dll . PowerShell restores the executable and DLL fragments from three PNG images. The infection creates a Run key and a 60-minute scheduled task, then hides the folder. It enumerates Active Directory and internal servers, setting up a file-monitoring command execution loop. It deploys the Python runtime and client.py to relay arbitrary TCP traffic from the external C2 to internal targets over a TLS WebSocket. 4. Attacker Position and Execution Location External attackers direct victims to view compromised websites. After execution, the compromised endpoint is operated as a pivot point between the external C2 and the internal network. 5. Visibility for Victims and Administrators Victims Tricked into opening the terminal from a realistic Cloudflare verification screen and pasting multi-line verification commands. Administrators Observable indicators include random-name fo

1. Overview Title : Chinese Fire Ant hackers turn Cisco routers into spying platforms Publisher : BleepingComputer Publication Date : 2026-08-31 Original Source : BleepingComputer Related Sources : Sygnia Related Malware, Threat Groups, CVEs, Products : Fire Ant, BridgeAgent, TacTap, Medusa rootkit, Cisco IOS XR, TACACS+, Linux, Zabbix Severity : High 2. Executive Summary Fire Ant compromised Cisco IOS XR routers, TACACS authentication servers, and Linux management hosts. The actors used GRE tunnels, suppressed logs and CLI outputs, captured network traffic, stole credentials, and deployed multiple long-term backdoors to explore connected high-value networks. 3. Attack Flow Turning Trusted Management Infrastructure into Relay Points Fire Ant gains high-privileged access to Cisco IOS XR routers and Linux management hosts. The initial access vector is not disclosed. The actors place persistence scripts and IOS XR-specific components on the routers, manipulating syslog and show outputs. They operate GRE tunnels with VRF and outbound Telnet connections that rarely appear in configurations or history logs. They capture network traffic into PCAP files on the routers and send them to external FTP servers to gather internal network topology and authentication flows. They deploy BridgeAgent, rootkits, custom SSH, and packet-triggered backdoors on the GRE-connected Linux hosts. They inject libraries into tac_plus using TacTap to harvest TACACS credentials. They probe connected SSH, HTTP(S), SMB/RPC, and RDP services to verify reachability to high-value networks, including critical infrastructure. 4. Threat Actor Positioning and Execution Environment External actors with high-privileged access to routers, TACACS servers, and Linux management hosts. The initial access vector is unknown. After the compromise, they explore connected target networks from inside organizational interconnections and management paths. 5. Visibility for Victims and Administrators Victims The activity r

It's the lightest Bentley in 85 years.

1. Why build another multi-tool? How many of you have often found yourselves wanting to buy a Flipper Zero? I thought about it many times, but there were always problems holding me back: stock is often limited, the price tag is quite high, and above all, you miss out on the thrill of building such a powerful tool literally from scratch. From these observations, my project was born: designing and developing a low-level "Swiss Army Knife". It all started a few months ago. I was thinking about buying an M5Stick S3 after watching some videos online where people spoke very highly of it, especially for one major detail: unlike the Flipper, it has Wi-Fi and Bluetooth modules already built-in. Digging deeper, I quickly realized the advantages of the ESP32-S3 over the classic Arduino. The key features that convinced me were: Dual-core processor: It opens the door to serious features, like managing firmware tasks separately. More RAM: It allows integrating very complex external libraries (like heavy graphical interfaces) without killing performance. Native USB HID: It allows emulating peripherals like keyboards or mice natively and quickly. So, the hardware was decided. But why build a multi-tool? The main reason is to explore and understand the technical background of as many tools as possible. Lately, I feel there is a tendency to overlook the ingenuity of the mechanisms operating right in front of our eyes. We prefer having a ready-made tool, usable perhaps without even knowing the basics of computer science. I wanted to go in the opposite direction and understand exactly how these things work at the code level. 2. Fluid Graphics and Multitasking: How not to blow up an ESP32 A major problem when rendering a graphical interface on a microcontroller is that the CPU has to calculate and send every single pixel. Since this is a time-consuming operation, the entire device gets blocked until the whole interface is completely redrawn. In a multi-tool, if the ESP32 is stuck drawin

This is part four of the Defender Access series. Each part is standalone, but here is the thread if...

The company, which distributes medicines and medical devices to hospitals and healthcare practices across the U.S., said it was hacked and expects intermittent service degradation.

In exchange for free stuff, devices make home connections part of a proxy network.

AI is proving effective at finding and exploiting vulnerabilities. Some say this will make it harder for governments to use hacking tools and spyware and could reignite calls to backdoor devices.

In eleven days, on 11 September 2026, the reporting obligations of the EU Cyber Resilience Act start applying to anyone who puts a product with digital elements on the European market. Not the full regulation. Just the part where, if you find out an actively exploited vulnerability is in your product, you have 24 hours to tell ENISA about it. I have watched a lot of engineering teams meet this class of deadline for the first time. It usually goes the same way. Somebody in sales gets a security questionnaire. Somebody in engineering gets forwarded the questionnaire. Three weeks later there is a shared folder called evidence-final-v3 with 200 screenshots in it, and nobody can tell you which screenshot answers which question. I have spent the last several months building a tool whose entire job is that folder, so I read the instruments properly. This is what I found out. It is written for engineers, not for a compliance team, and I try to be specific about what the text says rather than what a vendor blog says it says. Where SOC 2 came from, and why that still shapes it SOC 2 exists because of a misuse. In 1992 the AICPA published SAS 70, an auditing standard for service organisations. Its purpose was narrow: if you outsourced your payroll, your auditor needed some assurance that your payroll provider's internal controls did not corrupt your financial statements. It was an accounting instrument, for accountants, about financial reporting. Then the industry outsourced everything else. By the mid-2000s companies were sending their customer data to service providers, and they wanted assurance about that , not about financial reporting. There was nothing designed for it, so they asked for the thing that existed. Vendors started waving SAS 70 reports around as proof they were secure. They were not proof of that. SAS 70 had no defined control set at all: the service organisation wrote its own control objectives, and the auditor tested against whatever had been written. Two S

This is the second article in a series on time to revoke, following our piece on The Hacker News . The first explains how to measure the amount of time an exposed credential remains usable. This article focuses on the operational changes security teams can make to shrink that exposure window. TL;DR: Reducing time to revoke means addressing the operational blockers that keep exposed credentials valid after detection. Security teams need to validate which credentials still work, route them to the right owners, make revocation safer, and remove avoidable manual delays. Provider-specific runbooks, risk-based remediation paths, short-lived credentials, automation, and closure verification can all reduce the amount of time exposed access remains usable. Why time to revoke matters for AI-era non-human identity risk Every security team can find an exposed secret, but most can't tell you how long it kept working after they found it. Over 28.6 million new hardcoded secrets hit public GitHub in 2025, up 34% year over year, with AI-service secrets up 81% ( State of Secrets Sprawl 2026 ). AI-assisted development and agentic tooling cut both ways. Defenders find and triage more, but creation is outpacing governance. So while detection keeps up, revocation is where teams fall behind. And that disconnect is what this article is about. If an exposed credential remains valid, an attacker doesn't need to breach the same system twice. They can use it directly against any service that trusts the identity behind it, like a cloud console or a production database. And these credentials stay valid far longer than teams expect: 64% of secrets confirmed valid in 2022 were still valid when we retested them four years later. That is especially dangerous for non-human identities (NHIs). Service accounts and OAuth apps often run on long-lived tokens and deploy keys that no one rotates for months, sometimes years. Their access is broad, their ownership unclear. And because these identities keep cr