nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Banyan-admin.exe -> Banyan-admin-worker.exe -> Powershell.exe -> "disinfection in progress"

DSperber

This has started recently at my cousin's home computer, on which I have installed Bitdefender Total Protection (which has been running for many many years without issue).

She uses her home computer to connect remotely through her office network and then to her office personal computer. Recently the office IT staff upgraded all the office computers (details unknown to me just yet), and I suspect they have made "security upgrades/changes" at the same time. I suspect the remote connectivity software they installed on her home computer may well have also been upgraded (unknown to me) at the same time.

There is a product named SonicWall (Cloud Secure Edge) from Banyan which is installed on her home computer, which is part of the whole remote connectivity software instrastructure they have responsibility for. And this product appears to be invoking Powershell as part of the remote connection process, and Bitdefender appears to be unhappy with this. An attempt is made REPEATEDLY to disinfect Powershell.exe, each time producing a popop message with obviously gets annoying.

I haven't yet spoken with the IT people at my cousin's office to learn more about the whole process. I don't know if she were actually to sign in at Windows boot time (when the Banyan software prompts for credentials):

whether or not this might stop the subsequent repeated actions that are triggering the repeated Bitdefender "disinfections" of Powershell.

I will know more tomorrow. But what might be going on here?

Find more posts tagged with

Comments

Alexandru_BD

Hello @DSperber and welcome back to the community.

Based on the process chain you described and the screenshots attached, Bitdefender is probably not attempting to disinfect the legitimate powershell file itself, it's more likely reacting to the command, ****** or behaviour being launched through powershell by the Banyan/SonicWall Cloud Secure Edge administrative service, since the process is flagged by the Advanced Threat Defense module. This security layer is responsible for behavioral detection using advanced heuristic methods which differs from traditional malware detection, that involves identifying malware using the virus signature database.

The Banyan admin component runs with elevated privileges and can perform device checks, configuration changes and other operations required for remote access. If the office IT team recently updated the client or changed its security policies, the new version may now be launching a powershell command that resembles behaviour commonly used in malicious scripts. Bitdefender may consequently block that action as a precaution.

The repeated notifications could mean that banyan-admin-worker.exe keeps retrying the same powershell operation after Bitdefender interrupts it. I would not recommend adding a general exception for powershell.exe, as this would weaken protection against unrelated powershell-based attacks.

Since this software is installed and managed by her employer, the office IT team should verify that the Banyan/SonicWall client is genuine, fully updated and correctly deployed. They may also be able to inspect the Banyan logs and determine exactly which powershell command is repeatedly failing. If the command is confirmed to be legitimate, the relevant logs and detection details should be submitted to Bitdefender Support for investigation as a possible false positive or compatibility issue.

Signing into the Banyan client may stop the retries if the command is related to enrollment, authentication or device registration, but that cannot be confirmed without seeing the detection details and the Banyan logs.

Logs can be submitted to Bitdefender Support using the dedicated Support Tool. You can find the complete instructions here:

https://www.bitdefender.com/consumer/support/answer/1733/

To submit the logs, you can contact the Support teams using this link:

https://www.bitdefender.com/consumer/support/help/

State your contact reason, choose request category, then select from the available contact channels, chat, phone and email/ticket. Chat would be the fastest way to reach them.

I hope this helps.

DSperber

Well, some progress, but I fear I don't have enough yet to really give you what you want in order to truly identify the underlying details that 100% define this "false positive". I have some things which probably will be helpful. But unfortunately you probably will want more.

Anyway, here's what I can pass on.

(1) Temporarily, in order to allow the Sonic (VPN) connection software to operate on her PC so that she can successfully connect to her office network to do her work, I have in fact added a BitDefender exception for PowerShell.exe. Obviously this is undesirable and wrong, but temporarily that's all I can do until you can implement a proper "white listing" of this action that currently is causing you to take "protective action".

I mention that the 3rd-party "tech support" consultants that support her work computers and network infrastructure made the outrageous suggestion that I should simply uninstall BitDefender on her home PC. They had apparently (and also unbeknownst to me) installed SentinelOne on her PC! So she actually has BitDefender and Malwarebytes Premium which I installed) and now also SentinelOne!!

And since SentinelOne clearly did not have a "false positive" reaction to this new PowerShell usage coming out of this week's software upgrade from the Sonic software, but BitDefender did, that meant I should uninstall BitDefender and simply have SentinelOne!!! No need for both, and clearly SentinelOne must be better than BitDefender!

Can you imagine that attitude?

Anyway, the problem that needs fixing is clearly just the BitDefender "false positive" that must be corrected.

(2) Looking at the LOG file produced by Sonic, unfortunately the actual PS1 ****** (i.e. PowerShell command lines as invoked from the Sonic software) does not show the physical PS1 command line. So I don't know what it is. According to the Sonic web site I believe it is supposed to be found at:

C:\ProgramData\SCS\Invoke-EventHook.ps1

but in fact there is no such folder, and there is also no such file name anywhere.

(3) I do have a snippet of the LOG file which may or may not be helpful. I believe it captures when my cousin attempted to log in through Sonic, but failed (because the PowerShell function was blocked). Here is that log snippet:

log-snippet.txt

(4) I've just now heard back from the IT consultant. Apparently they did not implement Sonic such that the PS1 file I thought I should have found would be relevant. Turns out it is NOT part of their implementation, hence why I can't find it.

Instead, he says that the following is the PowerShell invocation:

powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -NoExit -Command -

(5) He has explained:

The final hyphen after "-Command" is important. It tells PowerShell to receive commands through standard input from the parent CSE process rather than load a PS1 file from disk. Consequently, there may be no corresponding PS1 file anywhere on the computer.

Bitdefender's timeline confirms that the parent process is a SonicWall CSE component, and the PowerShell event data shows Microsoft NetSecurity/IPsec activity. To determine the complete content passed through standard input, Bitdefender will need its own diagnostic package captured while the issue is reproduced, together with the CSE diagnostic logs and the screenshots already collected.

There is also a date distinction worth clarifying: SonicWall's changelog lists CSE desktop app 4.3.1 as released on June 17, 2026. July 24 is the date the Event Hooks documentation page was updated, not the documented release date of version 4.3.1.

I will open a case through our SonicWall support account and request confirmation of:

Whether this PowerShell invocation is expected behavior in CSE 4.3.1.
The executable responsible for supplying the commands through standard input.
SonicWall's recommended Bitdefender exclusion or vendor allowlisting procedure.
Whether SonicWall can provide Bitdefender with the appropriate application sample or technical details.

For security reasons, our SonicWall support credentials cannot be shared. I can submit the case and relay the response and requested diagnostic information.

DSperber

Just need to add a bit more context to today's event…

(1) When I originally posted my questions and screenshots there was an "older" version of SonicWall installed. The screenshots of the BitDefender timeline showed Banyan..exe versions of the two programs leading up to the Powershell invocation which was considered potentially malicious.

Yesterday, I allowed their "update to a new version" to be applied, which got us to v4.3.1 of SonicWall. And obviously because of significant internal software changes the BitDefender timeline now showed different program names leading up to the Powershell invocation. This time the programs involved were named Sonic…exe.

So same false-positive detected by BitDefender, but somewhat different vendor software programs now involved than the other day.

(2) As I mentioned in my previous post today, I've temporarily added a BitDefender exception for PowerShell to allow my cousin to at least for now successfully connect to her office network and do her work.

But for some reason, before I did that I saw timeline details titled "POTENTIALLY malicious behavior blocked" by BitDefender. And the captured data actually presents the complete PowerShell command line (identical to what I was sent by the IT consultant this afternoon).

For an unknown reason, a bit later on something in the environment must have occurred (I have no idea what) which then changed the timeline details to now be titled "[absolutely] MALICIOUS behavior blocked" by BitDefender. And because of this change the captured details no longer showed the complete PowerShell command.

I don't know that this is relevant, but I pass it along as "interesting" and potentially of value in eliminating the false positive.

Alexandru_BD

Hi and thank you for the detailed follow-up. This provides considerably more context and helps clarify what is happening there.

Let me address what I can here.

I understand why you added the exception as a temporary measure so they could connect and work. However, you are correct that excluding powershell.exe globally is not a safe permanent solution, like I mentioned previously. To dive a bit more into the specifics here, powershell is of course a legitimate windows component, but unfortunately it's also frequently used by malware and fileless attacks. A broad exception could prevent Bitdefender from inspecting unrelated malicious powershell activity in the future. Once the required diagnostic information has been collected (or another temporary workaround is available) the exception should ideally be removed.

Both Malwarebytes and SentinelOne together with Bitdefender is a highly relevant detail, because the device now has three security products with active protection capabilities and I will explain why this can be a problem.
Running multiple real-time antivirus or endpoint detection products simultaneously is generally not recommended. They can inspect, intercept or modify the same processes and network operations, potentially causing conflicts, performance problems, incomplete remediation or inconsistent detection results. Thus, it's recommended to avoid multiple active security solutions on the same system. AV comparatives also wrote an insightful piece about this here.
Now, Sentinelone not blocking this particular operation doesn't necessarily mean that Bitdefender is wrong, nor does it establish that one solution is categorically better than the other. Security products use different detection engines, behavioral rules, risk thresholds and cloud intelligence. One may flag activity that another permits, particularly when powershell, execution-policy bypassing and dynamically supplied commands are involved. And yes, of course they will tell you to uninstall Bitdefender, if they are already using another security product. But at least they are using something else and don't fall into that category of "IT specialists" who claim that macOS doesn't need an antivirus, for instance. For what it's worth, Bitdefender is the official Cybersecurity Partner of Scuderia Ferrari HP, so I guess it must good enough.😄

Anyway, I'm not here to convince people of anything, each with its own. I think the more important issue here is determining which security product is intended to provide primary protection. Since SentinelOne was installed by the employer’s IT provider, they should clarify whether it is mandatory and centrally managed. If it is required for corporate access, the IT team should coordinate compatibility with Bitdefender rather than simply recommending that another product be removed without investigating the detection. I think it depends entirely on their internal policy regarding security solutions, because in many cases companies have a contract with a cybersecurity provider and they make it mandatory for employees to use that one, because it's usually an enterprise solution managed by IT teams and specifically configured to adhere to certain policies that the company must meet security wise, and other custom settings, as the attack surface is considerably larger when we're talking about a business.
They should also confirm whether Malwarebytes is running with all real-time protection modules enabled. Nevertheless, three simultaneous cybersecurity solutions make troubleshooting considerably more difficult…

Going forward, the absence of C:\ProgramData\SCS\Invoke-EventHook.ps1 now makes more sense based on that explanation. As far as I know, Sonicwall has an optional implementation in which an administrator deploys several files, including invoke-eventhook.ps1, to run custom actions after a CSE tunnel connects. It is not necessarily part of every CSE deployment. If the company did not deploy that Event Hooks implementation, the missing folder and s.cript are not evidence of a failed or incomplete installation. They are simply unrelated to the powershell instance currently being launched by the CSE application.

But the command provided by the tech support consultant is also an important detail. powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -NoExit -Command -

The final hyphen means that PowerShell is not being directed to execute a named .ps1 file. Instead, another process can launch powershell and supply the instructions through its standard-input stream. This explains why searching the disk for the corresponding s.cript did not produce a result. It also explains why Bitdefender may consider the activity suspicious. From a behavioral-detection perspective, the combination includes several potentially sensitive characteristics:

powershell is launched by another application
user profiles are not loaded
the execution policy is bypassed
the command content is not present in the visible command line
instructions are delivered dynamically through standard input
the activity apparently performs NetSecurity or IPsec configuration
-NoExit keeps the powershell session open after executing the supplied content

You see the underlying problem here, these options are not malicious by themselves and can be used by legitimate administration software. However, like I said earlier, very similar techniques are also used to conceal malicious powershell operations. Bitdefender therefore responds to the complete behavior and process chain rather than merely detecting powershell.exe. The remaining unanswered question is exactly what banyan-admin-worker.exe, or another CSE component, writes to powershell’s standard-input stream. For the record, I doubt that there's something malicious in there, and I think this detection is more of a consequence of having certain administrative processes in effect, and bundling those three security solutions together..

Please note that I cannot analyze the logs you have attached on the public forum, and I totally understand why Sonicwall support credentials cannot be shared. We rely more on peer-to-peer suppor here and don't have the required tools to investigate such technical issues. That's a task for Bitdefender Support.
If the respective company allows having Bitdefender installed, then it should become the only security solution on that PC. As for Bitdefender Support, because the command content is supplied dynamically, screenshots and the visible command line alone may not be sufficient. A Bitdefender diagnostic package should ideally be collected while reproducing the issue, before adding a permanent exception. But they will tell you the same thing, that there's surely a conflict there and they will probably advise on removing both SentinelOne and Malwarebytes in order to proceed with troubleshooting.. so at the end of the day, I think this becomes a question of which security solution is allowed by that company, if it's mandatory to use SentinelOne or not, because they can't really have all three of them, for the reasons explained previously.

Regards