Everything that goes wrong happens after the login succeeds
Authentication, MFA, approval, access policy — all of it fires in the first two seconds. After that, the session is a shell or a desktop with a privileged token behind it.
Which matters, because the damaging sequences need no second credential:
| The action | How long it takes | What it needs |
|---|---|---|
| Add an account to Domain Admins | One command | Rights the session already has |
| Stop and clear the event log | One command | Same |
| Disable endpoint protection on the host | One command | Same |
| Delete backup jobs, or the retention policy | A few clicks | Same |
| Copy a customer database out through the clipboard | As long as the copy takes | Nothing at all |
| Drop a file in, and run it | Two steps | A file transfer nobody restricted |
None of that is an exploit. Every line is the intended behaviour of an account that was, correctly, authorised to connect. And the two entries needing no privilege at all — clipboard and file transfer — are features of the remote session protocol, on by default, in both directions.
An attacker who reaches a privileged session doesn’t escalate. They just work.
The command line inside a web console
Say you do everything right. RDP and SSH go through the platform, command policy is written, wevtutil cl is blocked, escalation asks for approval.
Then an administrator opens the firewall’s web interface and clicks CLI Console.
There is now a full command line in a browser tab. Same device, same privilege, same command set — and outside every control you just built, because the session was classified as web, and web sessions were assumed not to have commands in them.
It is not an edge case. A command line hides inside a browser tab almost everywhere that matters:
| Where | What opens |
|---|---|
| Network appliances | A CLI console built into the web interface, with the same command set as SSH |
| Hypervisor consoles | The virtual machine’s own console — the guest operating system’s shell, reached without touching RDP |
| Out-of-band management — iLO, iDRAC, IPMI | A virtual console that reaches the machine below the operating system, where nothing you installed is running |
| Cloud provider consoles | A managed shell, one click from the dashboard, already authenticated |
| Container platforms | Exec into a running container, straight from the dashboard |
| Database clients | A query window, which is a command line by another name. One statement reads a table; one statement drops it |
The rule isn’t which protocol you connected with. It’s whether the session has a command line in it.
Mirket applies command policy wherever that is true. The CLI console in a firewall interface, and the query window of a database client published as a RemoteApp, are filtered by the same rules as an SSH session, with the same three responses.
Filing sessions by protocol is what leaves that gap open — a web application becomes a page to be recorded rather than a session that might contain a shell.
| Session type | What in-session control means there |
|---|---|
| RDP and SSH | Command policy, clipboard per direction, upload and download authorised separately, escalation challenge, recording and transcript |
| Web consoles — firewall, hypervisor, backup, storage, out-of-band | The same set, command policy included, wherever the interface exposes a command line |
| Desktop applications — ERP and database clients, bespoke terminal software | The same set, published as a RemoteApp, command policy included where there is a command or query line |
Enforcement sits where the session cannot reach it
A control installed on the target can be switched off by a privileged session on that target. That is not a theoretical weakness — it is the first thing anyone competent does.
A session that can clear the log it is being recorded in is not being recorded.
So Mirket terminates the session in the path between the administrator and the machine, and applies policy there. Nothing that matters runs on the host, which means nothing that matters can be stopped from the host.
Three answers, because commands are not all the same
A single allow-or-block setting is unusable in practice: it is too blunt for the commands you want to watch and too weak for the ones you want to stop.
- Mark it The command runs, and is flagged in the transcript. For things worth knowing about rather than preventing.
- Remove it The command is stripped before it reaches the target. The session continues; that instruction simply doesn't happen.
- End the session For the short list where the right answer is that the session stops.
Policy runs as a blacklist or a whitelist, and is matched rather than global — by user or group, by target or target group, by schedule. A rule that applies everywhere either blocks legitimate work or is written so loosely it catches nothing.
Start by watching, not by blocking
Most command-filtering projects die on the first outage, so the honest engineering answer becomes don’t constrain and it never gets revisited.
The way through is to separate observing from enforcing. Run a blacklist in mark only for a week, against real traffic, and you end up with a list of exactly what the rule would have caught — before anybody has to defend a decision in a change meeting.
Clipboard and file transfer are security controls
They rarely get treated as such. They are convenience settings in a connection profile, enabled in both directions, and nobody has ever been asked to write a policy for them.
But they are how data actually leaves a privileged session, and how code arrives in one. Pasting a command in and copying a configuration out are different risks, so they are different permissions — clipboard to the user, clipboard to the asset, upload, download, each decided separately per asset.
Worth remembering what that covers: a firewall interface will happily export the entire configuration to a file, and that export is the configuration.
Escalation is an event, not a line in a log
sudo -i, runas, a UAC prompt — the moment an identity changes inside a session is the moment most worth challenging, and it usually passes silently.
It can be made to require re-verification or an approval before it proceeds. Where it is allowed, it stays visible inside the recording rather than becoming the point where the trail turns into root.
It holds in the native client, not only in the browser
This is the requirement that decides who a control actually reaches.
In-session control that exists only in a browser-based session covers the people who had no other option — and misses everyone senior, because they are working in a native RDP or SSH session with their own scripts and keys.
Mirket applies the same policy on both paths. The people with the most privilege are inside the control rather than beside it, and nobody has to change how they work to be covered.
What changes with Mirket
| Before | With Mirket |
|---|---|
| Authorisation ends the moment the session opens | Policy runs for the length of the session |
| A privileged session can clear its own audit log | Enforcement sits where the session can’t reach it |
| Clipboard and file transfer are protocol defaults | Each direction is a decision |
| One setting: allow or block | Mark it, remove it, or end the session |
| A whitelist is too risky to try | Audit-only mode against real traffic first |
| Escalation to root is a log line | It is a challenge, and an event inside the recording |
| Control exists only in the browser session | It exists in the client your administrators actually use |
| Web consoles and ERP clients are out of scope | Same policy, same recording, same clipboard rules |
| Command policy stops at SSH, so a browser tab goes around it | Every command line is filtered the same way, whatever opened it |
Frequently asked questions
What is session control?
Controls that stay active for the length of a privileged session rather than firing once at connection — what commands may run, what may be copied in or out, what happens when somebody escalates, and what is recorded while it happens.
What is command policy, and how is it enforced?
A matched set of rules, as a blacklist or a whitelist, applied to what is typed in the session. A match can be marked in the transcript, removed before it runs, or used to end the session outright — three answers for three different kinds of command.
Why can't the operating system do this?
Because its own controls are all-or-nothing. You can grant local administrator or not grant it; there is no native way to say "administrator, but not wevtutil cl". So the grant gets made in full and the difference is left to somebody's judgement at two in the morning.
Why does enforcement have to sit off the target machine?
Because a privileged session on a host can switch off anything installed on that host. A session that can clear the log it is being recorded in is not being recorded. The control point has to be somewhere the session passes through and the person in it cannot reach.
Does command policy apply to web consoles?
Yes, and this is the part worth testing. A firewall's built-in CLI console, a hypervisor's guest console or a cloud provider's managed shell are command lines that happen to live in a browser tab. Mirket filters them with the same rules as an SSH session.
What about a database client's query window?
Treated the same way. A query window is a command line by another name — one statement reads a table, one statement drops it. Published as a RemoteApp, it carries the same command policy, clipboard rules and recording as any other session.
Can I run a policy without blocking anything at first?
Yes, and it is the recommended way to start. Run a blacklist in mark only for a week against real traffic, and you get a list of what the rule would have caught without having stopped anybody working. A product that only offers enforcement tends never to get switched on.
Can clipboard be allowed in one direction only?
Yes. Paste-in and copy-out are separate permissions, because they are different risks — one introduces code, the other removes data. Upload and download are separate decisions again.
What happens when somebody runs sudo or gets a UAC prompt?
Escalation can be made an event rather than a silent step: it can require re-verification or an approval before it proceeds, and it stays visible inside the recording either way. RDP & SSH Session Recording covers the evidence side.
Does this work in a native RDP or SSH session, not just in a browser?
Yes — not only in a browser. That matters because the administrators with the most tooling, and the most privilege, are the ones working in a native client. A control that only exists on one access path reaches the wrong half of your team.
Are policies global, or can they be narrowed?
Matched: by user or group, by target or target group, and by schedule. A rule that applies everywhere either blocks legitimate work or is written so loosely that it catches nothing, so narrowing is what makes it usable.
Can this run from the cloud?
No, and here the reason is structural rather than a preference. Enforcement works by terminating the session in the path between the administrator and the machine, so the platform has to sit inside that path — which is inside your network. Deployment covers which modules run where.
Related
Solutions — RDP & SSH Session Recording · Just-in-Time Access · Third-Party & Vendor Access · Web & Desktop Application Access · Privileged Password Vaulting
Product — Privileged Access Management
Industries — Finance · Manufacturing