The Alert Is a Legitimate IT Tool

A notification arrived overnight on a file that turns out to be your remote monitoring and management agent. Four YARA rules matched it. Two threat reports have it linked. The automated verdict is not clean. Your service desk deployed the thing eighteen months ago and it is on most of the fleet, and the same alert has now fired three weeks running.

You are holding two readings of one screen, and both are defensible from what is on it. Either this is an intrusion using a remote access tool, which is the most common way an intrusion looks, or this is your own tooling matching intelligence written about somebody else's use of the same product.

The distinction is not a property of the file. It is a property of the deployment, and that is the whole trick of this page.

The outcome here is an opinion, not an escalation. This playbook ends with a recorded decision that changes what reaches your team next time. Resist the urge to open an investigation on a tool you already recognize.

Why does my own admin tool match threat intelligence at all?

Because attackers use the tools you use. Remote monitoring agents, remote-access utilities, credential vaults, archivers, and system administration binaries are all standard intrusion tooling, for the same reason they are standard IT tooling: they move files, run commands, and hold secrets on machines the operator does not physically have.

So when a vendor writes up a campaign, the report's indicator list contains the campaign's copy of a legitimate tool, and a YARA rule written to catch that campaign catches your copy too. Nothing has malfunctioned. A YARA rule states that a file has a certain shape, and your file genuinely has that shape.

This is worth internalizing rather than looking up each time. A match is evidence that a file resembles something described in intelligence. It is not a claim that anything happened. Treating every match on a dual-use tool as a detection burns an analyst hour a week and, worse, teaches your team to close this class of alert without reading it.

What will I know by the end?

Whether the file is your own tooling or somebody using the same product against you, which host to look at if the answer is not uniform, what to record so the decision is durable, and a silence narrow enough that a real use of the same tool still reaches you.

Why this works

Three ideas carry this one, and the first is the reason the page exists at all.

The distinction is not a property of the file. Your copy and an intruder's copy of the same remote access tool can be byte for byte identical, so no amount of looking at the file will separate them. What separates them is the deployment: where it sits, what it is called, when it arrived, and whether anyone owns it. That is why Steps 2 and 3 are about pattern rather than content.

Broad local prevalence is close to a definition of your own estate. An attacker who has reached 340 of your 500 endpoints is not producing one overnight notification, and an intrusion tool does not get installed by your deployment system on the machines your deployment system manages.

Authenticity is not authorization. A valid signature says the file is a genuine build from that publisher. It says nothing about who installed it or why, and for dual-use software that gap is the entire problem.

If you want the instruments themselves rather than this scenario, Investigate & Hunt covers each one on its own.

Step 1: What matched, exactly?

Open the object panel and read the names, not the counts.

"Four rules matched" tells you nothing. Which four tells you almost everything. A rule named for the tool's own family, or for a technique the tool implements by design, is describing the product. A rule named for a specific intrusion set, matching on a configuration block or an embedded address rather than on the tool's code, is describing somebody's deployment of it, and that is a different conversation.

Do the same for the threat report links. Read which indicator connected the file. A hash link is a strong statement: the report is about this exact build. A hostname or address link is much weaker, because the infrastructure a campaign used is often shared hosting that ten thousand unrelated things also use.

Decision point. If the only links are hostname or address links, and the hashes in those reports match nothing of yours, you are probably already done and the rest of this page is about recording that. If a report's hash matches your build exactly, keep going, and keep going carefully.

Step 2: How common is it across my own fleet?

Read prevalence, local first. This is the strongest single signal you have, and it is the one this playbook is built around.

Software on most of your machines is your estate. That is not a heuristic that occasionally works, it is close to a definition: an attacker who has reached 340 of your 500 endpoints is not producing one overnight notification, and an intrusion tool does not get itself installed by your deployment system on the machines your deployment system manages. Broad local prevalence with a consistent deployment pattern is what your own tooling looks like from the outside, and nothing else looks quite like it.

You can ask for the count directly. oac: is how many of your assets hold the object and ogac: is the global figure, so one line separates the cases. See StairQL.

hash:<the sha256> oac:100+

Then read the two figures against each other, which is where the useful pattern is:

Common locally and common globally. A widely deployed commercial product. This is the ordinary answer for a licensed tool, and it is the fastest close on the page.
Common locally and rare globally. Software built or packaged for you. Usually your own IT team's repackaged installer, occasionally an intrusion that has already spread. This one always gets Step 3.
Rare locally and common globally. A popular tool that is not part of your estate. Somebody installed it, and the question is who, on which machine, and whether they were supposed to. This is the shape that most often turns out to be real.
Rare in both. Do not close this. Go to An EDR Alert Just Fired and work it as an unknown.

Step 3: Does the deployment pattern hold up?

Open the Sightings tab and read the sightings as a deployment record rather than as a list of hosts.

Your own tooling leaves a recognizable trace. The file sits at the same path on every machine, under the vendor's own program directory. The filename is the same everywhere, because the name and path live on the sighting rather than on the file and a managed install writes the same ones each time. First-seen dates cluster on the days your service desk actually rolled it out, or arrive steadily as machines are provisioned. The publisher in the file's own metadata is the vendor you pay.

company:"Vendor Name" product:"Agent"

An intrusion using the same product leaves a different trace, and the differences are not subtle once you know to look for them: an install in a user profile, a temp directory, or a path with a random component; a renamed copy; a single host, or a small set that has nothing organizationally in common; and a first-seen date that is nobody's change window.

Two checks worth making explicitly:

Ask the owner. This is a real step, not a formality. Whether your service desk or your managed service provider deploys this product is a question with a yes or no answer, and it is the fastest way to end the investigation. A licensed tool with an owner is your tooling. A tool nobody can account for is not, whatever the prevalence says.
Read the signature for what it is. A valid signature says the file is an authentic build from that publisher. It says nothing about who installed it or why. Authenticity is not authorization, and for dual-use software that gap is the entire problem.

Step 4: Which host breaks the pattern?

This is the decision point the whole sequence exists to reach. When 340 machines match the deployment pattern and three do not, the file was never the question. Those three are.

Take each outlier and work it as its own small investigation. Open the asset, read what else arrived on it around the same time, and run Run-to-Ground from the file if anything looks off. Run-to-Ground works outward from the file to its variants, finds which of your assets held any of them, and then reports the rare files that landed on those machines within a day either side. On a managed fleet running a managed tool that result is boring, which is itself the finding. On a compromised host it is not boring, and the difference is visible immediately.

A clean result across every host, with a uniform deployment pattern and a named owner, is a real conclusion: this is your tooling, and the alert was a match on a product an attacker elsewhere also used. Write it down that way.

Step 5: How do I record the decision?

Set an opinion, with a comment, and pick the value deliberately. This is the step that changes the platform's behavior, and the two candidates mean different things.

Trusted is for a tool that is legitimate and authorized here. Your licensed remote monitoring agent, deployed by your service desk, at the managed path.
Grayware is for a tool that is not malicious and is not welcome. A remote-access utility your policy prohibits, a personal password manager on a production server, a dual-use administration binary you would rather nobody ran. Grayware records that it is unwanted without asserting that it is malware, which is the honest reading of most of these files.

Marking a file Trusted or Benign does three concrete things inside your environment: it makes the verdict your readers see safe, it stops the trigger notifications the file was generating, and it takes the file out of threat report match counts while leaving it visible in the results list. That last part matters here more than anywhere. A licensed tool linked to a dozen reports inflates every one of their numbers until somebody adjudicates it, and a report whose count is mostly your own software is a report nobody reads.

Write the comment. Name the product, name the team that owns it, name the path it belongs at, and date it. In six months the value of this record is entirely in the reasoning, and the reasoning is the part nobody can reconstruct.

Step 6: How do I silence the rest without going too broad?

An opinion handles the file. What it does not handle is a report indicator that keeps matching legitimate software you do not want to adjudicate file by file, and that is what a silence is for.

Silence the specific noise. Open the report, find the indicator in its IOC list, right-click it, and choose Silence hash, Silence hostname, or Silence IP. Write the comment the dialog asks for, and check the environment named in the dialog, because a silence applies to the environment you set it in and not to your others. Unsilence reverses it from the same menu.

That scope is the point of the feature. One indicator, in one report, in one environment. It is deliberately not a switch that turns off a category.

Why narrow, stated plainly, because this is the step people get wrong under time pressure. The reason your admin tool matched is that attackers use your admin tool. So the noise you are about to silence is generated by the same machinery that would tell you about a real intrusion using that tool. Silence the whole match type and you have not removed noise, you have removed the detection: the next time somebody drives that product against your fleet, the alert that would have told you is the one you turned off, and nothing in the interface will remind you that you did.

What that means in practice:

Never silence a whole match type to fix one file. A silence that suppresses every rule match, or every report match, in an environment is a silence that will hide something within the year. If a single tool is generating the volume, adjudicate the tool.
Do not unsubscribe from the report. You would lose coverage of every other indicator in it, including the ones this campaign has not published yet, and reports keep matching forward as well as backward.
Prefer the opinion when the answer is about the file. Trusted and Grayware are per-file judgments with an audit trail and a comment. Reach for a silence when the noise is one indicator matching many legitimate files, rather than one file matching many indicators.

If the problem is the indicator rather than the file, silence the indicator. When a report ships an address that turns out to be shared hosting, or a hash of a legitimate installer, right-click it on the report's Summary or IOCs tab and choose Silence hash, Silence hostname, or Silence IP. That removes it from the matching for the environment you choose, and it is reversible. This is the case the previous bullet is pointing at: one indicator matching many legitimate files. See Work With Threat Reports. If the indicator is wrong for everyone rather than only for you, [email protected] can silence or remove it from the report itself.

If notifications keep arriving after all of this, send the file and a sample of the notifications to [email protected] and ask for a silence scoped to that file's own name and path. Ask for the narrow one. Broad is always available and it is always the wrong trade.

That kind of silence is conservative on purpose, and the behavior is worth knowing before you ask for it: if the same file also turns up somewhere outside the path it was scoped to, it still notifies. That is what you want. A copy of your remote access tool in a temp directory is not the deployment you approved, and it should still wake somebody.

What still reaches me after this?

Worth checking, because a silence whose edges you cannot describe is a silence you should not have set.

A new build of the same tool is a different file with a different hash, so your Trusted opinion does not cover it and you will hear about it. That is correct. A version you did not deploy is worth one minute of somebody's attention.
The same tool on a host outside the pattern still shows up in prevalence, in sightings, and in Run-to-Ground results, because none of this removes data. It suppresses notifications and match counts, and the evidence stays where you left it.
Other indicators in the same report keep matching, since you silenced one and not the report.
The audit trail of who decided what, and why, sits on the History tab of the object panel, which is what makes this defensible rather than merely quiet.

What should I read next?

Prevalence, for the local and global figures that carried Step 2, and what each one does and does not prove.
Setting Opinions, for the full set of values and what each one changes.
What Is a Threat Report?, for why an indicator matches, what counts as a match, and why filenames deliberately do not.
You Just Acquired a Company, where you make this decision several dozen times in a week on a fleet you did not build.