Threat Detected: Plot Twist, It’s Tenable

“It's a trusted application. We've been using it for years.”

One of the frustrating parts of working in cybersecurity is having a legitimate concern dismissed because the application involved is already approved and widely used.

Fair enough. But does being a trusted application automatically make every action it performs safe or compatible with the rest of our security controls? Not necessarily.

And this investigation became a perfect example of why we shouldn't confuse an application's reputation with its actual behavior.
_**

It Started With Three Notifications
**_

It was a Tuesday afternoon when three users reported unusual security notifications appearing in the Windows notification center.
_**

At first, nothing seemed particularly alarming.
**_

Endpoint security classified the threat as low severity. There was no corresponding incident or alert in our SIEM, and nothing immediately suggested an active compromise.
_**

The notifications appeared around the same time each day, approximately 1 PM.
_
Initially, I thought this might be an isolated endpoint issue. But over the following days, more users started reporting the same behavior.
_

What began as one notification per day eventually became multiple notifications, sometimes four times in a single day.
**_

Users started confusing the security warnings with application errors or other system problems. At that point, it was no longer just a low-severity detection. It was becoming an operational nuisance, generating unnecessary concern and potentially contributing to alert fatigue.

I needed to understand what was triggering it.

Investigation: I established three objectives:

1. Determine the scope - How many devices were receiving the notifications without manually contacting every employee?
2. Identify the source - Was the activity caused by a legitimate application, scheduled automation, misconfiguration, or an actual security threat?
3. Prevent recurrence. - How could we stop the unnecessary notifications without weakening endpoint protection?

First Clues:

In security protection history, I found that the activity had been blocked by an Attack Surface Reduction (ASR) rule:

Block process creations originating from PSExec and WMI commands

This was important because WMI is commonly used for legitimate system administration, inventory, monitoring, and automation. However, threat actors can also abuse WMI to execute commands, establish persistence, or move laterally across an environment.

time: 4:02
Blocked:VmiPrvSE.exe & ASR

> Let's Hunt!

Rather than ask users whether they had received notifications, I used Advanced Hunting to investigate the activity across managed devices.

**Queries:**
_| **where Timestamp > ago(1d)_ **- I used this one to focused for the latest alert device got.
_|** where ActionType** == "AsrPsexecWmiChildProcessBlocked"_ - this is the clue that ASR from security endpoint blocked it. 
_**ProcessCommandLine,**_ - This is the most important to verify what process, application or process running.
_**Timestamp,**_ - to compare the exact time from the threat history and hunting dashboard
_**DeviceName,**_ - to know how many devices got the alert

This allowed me to identify which devices were repeatedly affected and how frequently the blocks occurred. The recurring pattern suggested that the activity might be associated with a scheduled process or a centrally deployed application.

> Second clue:

For additional validation, I also checked the events directly on an affected endpoint, The path was:

**

> Event Viewer → Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational

**

I filtered for:

Event ID 1121 — Attack Surface Reduction rule triggered in Block mode

I correlated the event timestamp, process information, and command-line details with my Advanced Hunting results.

**

Third clue:

**

The command was encoded, making it difficult to understand its purpose by simply reviewing the initial detection. Before drawing conclusions, I decoded the command for static analysis.

For PowerShell commands using the standard -EncodedCommand parameter, a Base64-encoded UTF-16LE string can be decoded without executing its contents:

_$encoded = "<Base64 string>"

[Text.Encoding]::Unicode.GetString(
    [Convert]::FromBase64String($encoded)
)_

Important: Decoding a command is not the same as executing it. Unknown commands should be inspected as text, preferably in a controlled analysis environment, rather than copied into an interactive PowerShell session for execution.

After decoding the relevant command, I discovered references to operations such as:

_
$ret | ConvertTo-Json -Compress |
    Out-File -Encoding Unicode -FilePath ..._

And a temporary file similar to: C:\Windows\TEMP\nessus_azure_ad_join_*.txt

The command was writing collected information to a file with a name suggesting Azure AD or Microsoft Entra device configuration checks. That filename immediately stood out.

_**nessus_azure_ad_join**_

Now the investigation was pointing toward our vulnerability scanning infrastructure.

Look at the paw print! We're getting closer to the answer!

further research led me to:

{% embed https://www.tenable.com/plugins/nessus/177646 %}

According to Tenable's official plugin documentation:

1.this plugin collects information about Microsoft Entra-joined or hybrid-joined Windows devices.

1. configuration attributes can include the tenant identifier, device identifier, join type, and other Entra-related details.

In our environment, I also investigated the Tenable agent components, including the local Nessus scripting engine executable:

> C:\Program Files\Tenable\Nessus Agent\nasl.exe

The combination of the decoded command, temporary artifact naming, repeated execution pattern, installed agent components, and vendor plugin documentation provided a strong indication that the behavior was connected to Tenable's local scanning activity.

**

So Was It a False Positive?

**

No, Both applications function according to their design while their is a compatibility conflict.

Remediation:

"Can you help me figure out what Blue wants to do?"

After identifying the likely source, my next objective was to eliminate the repeated notifications without unnecessarily disabling ASR protection.

I investigated and deploy configuration for exclusion options for the affected process, the Tenable installation path, and nasl.exe, including endpoint security policy configuration and Defender indicators.

Unfortunately, the attempted allowlisting did not stop the recurring detections. With the evidence collected, I raised the issue with Tenable Support.

The response brought three important points to light.

• This was not an isolated customer experience - Support acknowledged awareness of similar reports by other customers and indicated that the issue was still being investigated.

• plugin-level control was subject to licensing limitations - I was advised that the option to disable the relevant plugin through the available configuration controls required a higher-tier plan than the one we were using.

That was frustrating. We had already licensed and deployed security product, yet a potentially useful workaround was not available under our existing entitlement.

• the support case was assigned Category 2 - From a vendor-support perspective, the issue might not represent a critical product outage.

Not for me the repeated notifications were affecting users, creating unnecessary noise, and consuming investigation time.

> What this investigation taught me?

"Imagination and creativity will help us solve the mystery!"

• _ “Trusted” Does Not Mean “Never Investigate”_ - An approved application shouldn't receive an automatic exemption from security scrutiny.
• Low-Severity Events Can Have High Operational Impact - A single low-severity notification might be easy to dismiss and a lot of us guilty about this but Repeated alerts across numerous endpoints are a different problem.
• When Security Fights Security - The investigation identified the likely source and clarified the underlying security-control conflict, although a permanent resolution remained outstanding

_**

But as security engineers, our responsibility isn't to accept an application's reputation as proof that every action is expected.
**_

It's to investigate the evidence, understand the behavior, evaluate the risk, and make sure our controls work together.

_**

Because sometimes the most difficult security incidents aren't caused by attackers. They're caused by the security tools we trust to protect us.
**_