GravityZone ATC (atc.sys) throttling custom PLC CLI tool + Device Control blocking FTDI Composite USB-RS485 adapters on Shop Floor

coreblastsolutions

Hey folks,

Looking for some guidance from anyone managing Bitdefender GravityZone (Enterprise / EDR enabled) in a manufacturing or OT/industrial automation environment. At Core Blast Solutions, we build automated abrasive blasting machines (suction/pressure blast cabinets with PLC automation). We are having a dual headache with Advanced Threat Control (ATC) and Device Control on our field commissioning laptops.

Issue 1: ATC / HyperDetect Behavioral Throttling on CLI Sensor CalibrationWhen our engineers calibrate a new blasting cabinet—specifically tuning the VFD dust collector curve and the abrasive media metering valve (for steel grit and glass beads)—we run an internal CLI utility (blast_cal_cli.exe). This tool opens a high-speed serial COM stream (115200 baud), allocates shared memory buffers for real-time sensor telemetry, and spawns a headless child process to write CSV/JSON diagnostic logs.

Even though blast_cal_cli.exe is signed with our internal enterprise code-signing certificate and excluded under Antimalware -> Exclusions (Process & Path), we noticed via Process Monitor (ProcMon) that epag.exe and atc.sys are heavily hooking its thread creation and serial I/O calls. If HyperDetect is set to Aggressive or Normal, ATC occasionally terminates the calibration ****** mid-run with a behavioral detection (Gen:Variant.Behav / ATC.ProcessHollowing false positive) because our CLI injects a diagnostic hook into the vendor PLC communication DLL (S7onlinx.dll).

Question 1: In GravityZone Control Center, when you exclude an .exe by path for ATC/IDS, does that exclusion automatically cascade to ** child processes or unsigned third-party PLC vendor DLLs** loaded by that parent process, or do we have to whitelist the specific command-line arguments and DLL hashes inside the EDR/ATC exclusion rules?

Issue 2: Device Control Blocking Industrial USB-to-RS485 IsolatorsTo protect our PLCs from shop-floor ESD (dry abrasive blasting generates massive triboelectric static), we use galvanically isolated USB-to-RS485 adapters based on FTDI (VID_0403&PID_6001) and Moxa UPort chipsets.

In our GravityZone Device Control policy, we have External Storage and Unknown USB Devices set to Blocked to prevent unauthorized flash drives on the shop floor, while Serial Ports (COM & LPT) are set to Allowed. However, when plugged in, Windows first enumerates the FTDI isolator under the USB device class (USB\VID_0403&PID_6001) before loading the Virtual COM Port (FTDIBUS) driver. GravityZone blocks the parent USB enumeration before the COM port can even mount!

Question 2: When creating a Device Control Custom Exclusion by Device ID (USB\VID_0403&PID_6001), do we need to add two separate rules—one for the USB Controller/Bus class and one for the Serial/COM class—so GravityZone doesn't block the parent composite device during handshake?

Appreciate any insights from anyone running GravityZone alongside PLC programming stacks!

Thanks in Advance

https://coreblastsolutions.com/

Andrei_S Enterprise

Hello @coreblastsolutions ,

1. The exclusion is applicable per process and it will only exclude that process that is matched by the exclusion rule. You will need to add all other process (child processes) if these are created, not necessary all of them have to be added but it might require to identify that one specific child process which is blocked by ATC. Alternatively, you can exclude a folder and it will exclude everything inside.
   
2. We no longer filter the devices from COM/LPT class so you need to add exception by DeviceInstanceId for every blocked USB device until COM port is mounted.
   
   If you need additional information or if you tried what I suggested and still does not work you can reach out to our enterprise support team and we can investigate the issue further.
   https://community.bitdefender.com/home/leaving?allowTrusted=1&target=https%3A%2F%2Fwww.bitdefender.com%2Fen-us%2Fsupport%2Fcontact-us

Kind Regards,

Andrei