CB Blocking dbatools 2.0.3

[amanzeekverma]

With dbatools 1.x I was able to load it up (with some steps taken for CB to not block it) on powershell_ise.

With dbatools 2.0.3, it is being blocked by carbon black (CB).

It seems, the way dbatools.dat is being used is leading to "fileless script, obfuscation and suspected-encoding" and hence being blocked.

I tried to short circuit "serialimport as True" so that individual ps1 could be sourced, but then it later failed (not blocked) because of what I think is a bug where maintenance.dat and settings.dat are being "sourced" (instead of using Import-Command).
Example in dbatools-maintenance.ps1:

foreach ($item in (Get-ChildItem "$script:PSModuleRoot\private\maintenance" -File)) {
    if ($script:serialimport) {

        . $item.FullName

    } else {

        Import-Command -Path $item.FullName

    }
}

Any thoughts on getting away with these blocks OR, getting serialImport to work? or somehow getting away with ".dat" loads?

[wsmelton]

Please track issues on AV/EP software via issue #8241

We have had users reporting that CB has fixed this issue in latest release(s).

[wsmelton]

Please post in the issue then that it pertains to v2 release for your environment.

What we are doing is not malicious and simply a pattern that CB is flagging incorrectly. Other AV/EP products do not see it as malicious to date (Defender, CrowdStrike). We use this method for loading the module as it has to be there for performance reasons; other projects use this method.

[wsmelton]

Please also do report this to CB as a false-positive as maintainers cannot. That is all that can be done at this time.

[amanzeekverma]

The release notes/blog mentions about potential conflict on this process with AV. Is their a way to use Dot sourcing instead? (The serialImport option confuses me)

Also sorry, i am very new to dbatools, so i might be asking something naive.

With dbatools 1.x it was not fileless execution hence was straightforward to allow dbatools cert for any files to get excluded by CB.
With dbatools 2.0 this "dynamic script" is equating to 'fileless script being executed' and based on "av policies" this may qualify to be blocked? I do not have other AV to test dbatools 2.x but i would expect AMSI providers to be vigilant about such execution.

Are you suggesting i report it as issue?

[wsmelton]

Is their a way to use Dot sourcing instead? (The serialImport option confuses me)

As of v2 of the module if you are installing via PS Gallery there is no longer a serial import option, it was removed because the folder structure doesn't exist for it. If you require that method, you will have to clone the GitHub repo in its entirety.

I do not have other AV to test dbatools 2.x but i would expect AMSI providers to be vigilant about such execution.

To date we know that Microsoft Defender and Crowdstrike (both of which include AMSI) and are not flagging the module's use. It is not necessarily that the dat file exist, it also includes scanning what the data file contains. This "method" they are blocking has been around for a while now, and again our module is not the only "program" that uses it because it has a huge benefit for performance in programming when you have large payloads that have to be loaded into a process.

Are you suggesting i report it as issue?

Yes, a report to CB that this is a false positive.

[amanzeekverma]

Thank you for indulging. I will see how/where I can push it.

[amanzeekverma]

Raised to CB as well as here : #8949