guardyn actions

When a Windows server is under attack and nobody can reach it yet, guardyn can act on it. From Slack, the Investigate chat or the console, an owner or admin of the workspace can block an attacker’s address, stop a hacked site, move a web shell out of the site, sign an intruder out, disable an account or stop a process. The agent on the server does it within seconds and says what it did.

A block, a stopped site or a disabled account lasts for the time chosen, at most a day at a time, and the agent undoes it by itself when the time is up, even if it cannot reach guardyn. A file moved into quarantine stays there until someone at the server puts it back.

They are off until an administrator turns them on at each machine, and guardyn cannot turn them on itself. On a machine where nobody did, its agent refuses every action. Only the Windows agent has them so far; on Linux and macOS the checks and the 24/7 watch work as usual.

The six actions#

A timed one lasts 15 minutes, 1 hour (the default), 4 hours or 24 hours, and never longer than the machine allows. “Keep it longer” on the machine’s page renews it from that moment.

Turning them on#

guardyn cannot switch emergency actions on, and nothing it sends can. The switch is a setting on the server that only the agent’s own command writes, run there by someone with administrator rights, and the agent refuses every action while it is off. That is what keeps a stolen guardyn account, or guardyn itself, from acting on a server whose administrator did not agree to it.

It needs agent 0.17.0 or later, on a Windows server. In PowerShell as Administrator:

guardyn-agent actions on

To allow only some of them, list them by the names in the table above; to keep each one shorter than a day, give the most minutes it may last:

guardyn-agent actions on --only block_ip,stop_site --max 240

A Windows server being set up can have them on from the start. When you add an endpoint in the console, tick Allow emergency actions on this machine on the Windows tab, and the enrol command it gives ends with --allow-actions. Run that command in PowerShell as Administrator.

On the machine itself:

Taking one#

On the machine’s page, under Emergency actions, choose what to do and fill in what it needs: the address, the site, the file, the account, or the process and its program. Choose how long, and say why if you like; the reason goes into the activity log and the machine’s own log. Before anything is sent, a confirm says exactly what will happen on the server and when it ends.

The panel then shows what the agent did, what is in force with the time left, and buttons to undo it early or keep it longer. If no answer comes within a minute, it says so: the action may or may not have happened, and guardyn-agent actions status on the machine says which. It can be undone from the console in case it was.

Only owners and admins can take, undo or extend one. Everyone else in the workspace sees what was done.

The machine’s timeline and the findings page offer the ones that fit what happened: under a burst of failed sign-ins, a button to block the address behind it; under a web shell, to stop its site or move the file into quarantine. Each asks first, the same way.

From Slack#

An alert sent to a Slack place that can take presses carries the same buttons, under each event they fit. Slack asks before anything is pressed, and what came of it is said in the alert’s thread, for everyone in the channel: who asked, what, until when in each reader’s own time, and what the machine said, with buttons there to undo it early or keep it longer. A button works for a day after its alert was sent.

A press counts only for a member of that Slack workspace who is an owner or admin here: one whose Slack email, confirmed by Slack and looked up at the moment they press, is their guardyn email, or one who linked that Slack account to theirs. Someone from another organisation in a shared channel is refused, and so is anyone else. They are told so, alone, and nothing is done. Every press is in the activity log, a refused one too.

A member of your Slack whom guardyn does not recognise is given a link with the refusal, good for 15 minutes. An owner or admin who opens it signed in to guardyn sees the Slack account’s email, handle and id, and links it to their own account only if they confirm. A link lasts 90 days, and ends sooner when they sign out everywhere or reset their password. They and the other owners are emailed, and the place’s panel in Settings → Alerts lists linked accounts with Remove.

guardyn knows a press came from your Slack because Slack signs each one with the signing secret of the Slack app the place uses: your own app’s, or guardyn’s for a place added with Add to Slack. For a place connected with your own app’s token, turn on Interactivity in the app’s settings with the Request URL its panel in Settings → Alerts gives, then paste the app’s Signing Secret (Basic Information, under App Credentials) into that panel. Until then its alerts carry no buttons, and the panel says On once a press from Slack has passed the check. Pasting another app’s token turns presses off until that app’s Signing Secret is pasted. A place added with Add to Slack takes presses only once an owner or admin turns them on in its panel, and they can be turned off there. Either way the app must be allowed to see who presses (users:read and users:read.email): the app guardyn’s link makes has both, and a place added with Add to Slack before guardyn asked for them is added again first. The other owners are emailed when presses are turned on. A paused place’s buttons do nothing.

From the Investigate chat#

When the machine an investigation is about allows emergency actions, the analyst can propose one, from what it found: a card in the conversation saying what it would do, on which machine, for how long and why. The proposal does nothing by itself. An owner or admin who approves it on the card takes it, as themselves, with every check above made again; anyone else sees that an owner or admin can approve it. A proposal is approved once, and not after half an hour, when what it was about may have changed. The card then shows what became of it, and the analyst is told in its next answer. An owner or admin can undo a timed one early from the card, and the record says it was undone from the chat.

What guardyn will not do#

Every action is checked twice: on guardyn’s server at the moment it is sent, and again on the machine by the agent, which has the last word.

• Only these six, each with fixed arguments, compiled into the agent. No command, script or path pattern can be sent, and no new action can be added from guardyn.
• Only by an owner or admin of the workspace, signed in as themselves: one of guardyn’s operators signed in as a customer cannot take one. Only on a machine that allows that action, while its agent is connected.
• Never block guardyn’s own address, the address the machine reaches guardyn from, the server’s own addresses, or a loopback, link-local, multicast or broadcast address. From the console or the chat, never the address of the person asking either: a press in Slack reaches guardyn from Slack, which does not say where the person is.
• Never sign out or disable SYSTEM, LocalService, NetworkService, an NT AUTHORITY or NT SERVICE account, or the account the agent runs as. Never disable the last administrator who can still sign in. Only the machine’s own accounts can be disabled; a domain’s account is the domain’s to disable.
• Never stop the system’s own processes (process ids up to 4, csrss, wininit, winlogon, lsass, services, smss, svchost, Defender’s engine, the SSH listener) or guardyn’s own.
• Quarantine only a regular file inside a web folder the watch knows, on the same disk as ProgramData (usually C:), and never a web.config, .htaccess or .user.ini: those say how a whole folder is served, so stopping the site is the answer there. Windows moves a file only within one disk and the agent never copies one, so for a site on another disk, stop the site. A Windows path is taken by its full names only, never the short ones Windows makes up (WEB~1.CON for web.config), so no rail can be passed by another name for the same file.
• At most 10 on one machine in ten minutes and 30 in a workspace in an hour. Asking for something already in force answers with what holds it, and sends nothing again.
• guardyn’s operators can switch emergency actions off for everyone at once. What is already in force is still undone on time by the agents.

Where it is written down#

• On the machine, in the agent’s own audit log, which guardyn-agent audit prints: every action, refusal and undo, and every change to the switch, with who asked, from where and why.
• In the workspace’s activity log. The other owners are emailed when one is taken, and when one is undone early, because undoing one early is also what someone with a stolen session would do.
• On the machine’s timeline, under the 24/7 watch: a line for each one taken, undone or ended, beside what happened on the machine. Alert rules do not send these on; the owners’ email already does.
• On the machine’s page: what is in force, and the last twenty with who asked, from where and how each ended.

If guardyn itself were compromised#

The security model assumes guardyn’s server could be taken over. On a machine that never turned actions on, its agent refuses every action, so whoever controlled guardyn could only run checks there. On one that did, whoever controlled guardyn could take the same six actions an owner can, within the agent’s own guard rails; the limits guardyn’s server keeps, such as how many may be taken in an hour, would not hold. They could block addresses, stop sites and disable accounts for up to a day at a time (or less, with --max), and keep renewing them for as long as the agent stays connected, move files out of web folders into quarantine, sign accounts out and stop processes. They could not run a command of their own, read a file outside the forensic allowlist or turn actions on anywhere, and guardyn-agent actions off at the server undoes everything at once. Turn them on where that trade is worth it, and allow only the ones you need with --only.

Which plans include them#

On a plan without them, anything already in force can still be undone early from the console, and the agent ends each one on time.