Skip to content
Sections
All notes

All notes · Security

Detecting Misuse of Your Own Tool

Whether the misuse comes from an attacker with stolen access or from inside, the signals are the same. What to watch.

Security · Procedure

An attacker who reaches your console behaves much like a technician, which is the difficulty. The distinguishing signals are about pattern rather than action.

Controls for “Detecting Misuse of Your Own Tool” need named owners and protected review time as well as technical safeguards. Using the full guide can make that recurring governance workload visible across the team, but it should never replace access logs, incident evidence or least-privilege administration.

For an independent operational benchmark, compare the local practice with CISA Secure Our World guidance; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

What to alert on

New administrator account, or permission escalation.

Script execution at multi-client scope.

Console login from an unusual location or at an unusual hour.

Bulk agent uninstall or policy change.

Access to a client a technician does not serve.

Five alerts, low volume, high signal, and most platforms can produce them.

The baseline

Normal looks like: technicians acting on their own clients, during their hours, at single-machine or single-client scope.

Establish what that is for your team, because the deviation is what matters and you cannot see deviation without a baseline.

A fortnight of logs is enough.

The signals that distinguish

Scope: a technician acts on one client; misuse frequently reaches many.

Timing: outside the person's normal hours, particularly if they are asleep.

Sequence: reconnaissance before action — browsing clients, listing machines, reading credentials.

And disabling things: security software, logging, alerting, which precedes most deliberate misuse.

Watching the logging itself

An attacker's first move against a logged system is frequently the logging.

Export logs somewhere the console cannot alter.

And alert on logging being disabled, which is a one-line rule and is rarely configured.

The insider case

Uncomfortable and real: a departing technician with full access, or somebody acting on a grievance.

The controls are the same — scope, logging, review — and the detection is the same.

What differs is the response, which is a human matter rather than a technical one and benefits from having been thought about before.

Reviewing

The alerts above are exceptions; somebody should look at them within the day.

Plus a monthly read of administrative actions: who ran what at wide scope, and did it make sense.

Twenty minutes, and it is the difference between logging and monitoring.

The culture that helps

Technicians should expect their actions to be logged and should not experience that as distrust.

Say it plainly at induction: this system reaches our clients' machines, so everything is recorded, including mine.

Logging that applies to everybody including the owner is accepted; logging that applies downward is resented.

What to check

Do you alert on new administrator accounts and wide-scope scripts?

Are logs exported outside the platform?

Would you notice a login from an unusual location?

And does anybody read the administrative log monthly?

The point

An attacker's first move against a logged system is frequently the logging.

Export logs where the console cannot alter them.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.