Antivirus false positive on an HMI simulator file

What each finding points to

One alert can mean several things, and the checks in this article tell them apart:

• One file flagged, inside the software's own install folder, on one workstation: most often a false-positive signature, an extra or damaged file left by an interrupted install, or a file that was added and does not belong to the software. The comparison and test steps below separate these.
• The same file exists on a known-good install of the same release: this strengthens the false-positive track, and a hash comparison of the two copies settles it.
• The file is missing on the known-good install: the file may be extra. Presence in the software's own folder is not proof that the file belongs to the software, so keep it quarantined and let the test decide.
• The simulator runs with the file quarantined: your release demonstrably runs the functions you tested without the file, so the false-positive track stays open and the file goes to the vendor's submission channel.
• The simulator fails with the file quarantined, or the alert returns after a repair from a verified installer: treat the alert as unresolved, escalate to your security team, and submit through the vendor's portal.
• The same alert appears on several workstations or on several software titles: treat this as a possible real infection, stop, and follow your incident-response process. The rest of this page is for the single-workstation case.

Record the alert before you touch anything

Write down four things while the alert is still on screen, which takes about 5 minutes: the detection name exactly as printed, the full path to the flagged file, the file's date and size, and the version of the endpoint security suite. Take a screenshot or export the alert details if your suite can. The detection name and full path are the first two things a vendor support engineer or your security team asks for, and the date and size tell you later whether a reappearing file is the same file. Keep this record with the machine's documentation; the same record serves when you plan any later change to the workstation's screens, including shop-floor HMI displays that the engineering PC programs.

Quarantine the file, do not delete it or allowlist it

Quarantine is a locked store the suite controls: the file cannot run or spread from inside it, and it stays available for review, submission or restore. That is exactly what you want while the file's status is open. Use the suite's quarantine action on the flagged file, and do not use restore while the alert is unresolved.

Deletion removes the copy that your security team or the software vendor needs for analysis. An allowlist entry is worse: it tells the suite to stop checking the only file it flagged, and a wrong entry removes your only warning. If your suite already deleted the file automatically, work from the four recorded details and go straight to the repair section.

One adjacent case: suites sometimes quarantine licensing or activation files too. If that is what happened to you, recovering activation files after an antivirus quarantine is its own documented job.

Compare against a known-good install of the same release

Find a second workstation that runs the same software release as the flagged machine, read the release string from the editor's about box on both machines, and write both down. This comparison takes about 10 minutes when the second workstation is on the same bench.

If the reference machine has the same file, compare the two copies by hash. SHA-256, the 256-bit hash in the SHA-2 family, writes its digest as 64 hexadecimal characters; two copies match only when all 64 characters agree, and one differing character means the two files are different. Many tools also print MD5, a 32-character digest of 128 bits; treat it as the weaker identity check, because MD5 collisions are documented.

If the reference machine has no such file, treat the absence as a clue that the file may be extra, and decide it with the test below. A filename and a folder location are not an authenticity check, so a folder diff on its own settles nothing about the file's content.

Test the simulator with the file quarantined

With the flagged file still in quarantine, launch the editor and open a non-production test project, one with no connection to a live machine. Run the simulator functions your current work needs: open the screens, drive a few tags, watch a trend. Allow about 15 minutes for this test. Note any startup message, missing-file warning or failed function.

If everything you need works, your release demonstrably runs its simulator without the file, and the false-positive track stays open. If the simulator fails, leave the protection on and the file quarantined, capture the failure details, and go to the repair section. Do not restore the file to see whether that fixes it, and do not lower the suite's protection to make the message go away.

Example: one flagged file, two workstations

Workstation A runs your HMI development software, and its suite flags dadobra.fuo in the Simulator folder under Program Files, naming a Trojan. The file is 812 KB, dated 2024-03-11, one file among the 46 files in that Simulator folder. You record four details: the detection name, the full path, the file date and size, and the suite version, in about 5 minutes.

Workstation B runs the same release, read from the editor's about box. Its Simulator folder also holds 46 files, but contains no dadobra.fuo, so there is no second copy to hash. The measurable difference is 47 files on A and 46 on B. A hash comparison would have meant checking 64 characters, 4 bits each, 256 bits in all, with a single differing character failing the pair; here you cannot run it, because B has nothing to hash.

You keep dadobra.fuo in quarantine, open a non-production project, and the screens, tags and trend all work in the simulator after a 15-minute test. Result: the software on this release demonstrably runs without the file, so you submit the file through the suite vendor's documented portal and keep the workstation off programming work until the analysis comes back clean.

Repair from a vendor or distributor installer

Get the installer from the software vendor or its distributor, for the exact release you run, and scan it with your suite before you run it. Some vendors publish a checksum next to the download; if yours does, compute the SHA-256 digest of the file you received and compare all 64 hexadecimal characters before installing, since a single differing character means the file is not the one the vendor published.

Run the installer's repair or modify option for the simulator components, following your site's change process, then run a full scan, which takes 20 to 30 minutes on a typical engineering workstation. If the editor misbehaves before you repair, work through the HMI editor crash diagnosis first, because a repair can wipe the evidence of what actually failed. If the vendor installer hangs at a dialog when it starts, that problem has its own fix.

After the repair, a clean scan plus a working simulator closes the false-positive track. An alert that returns after a verified installer does not, and that goes to the portal and to your security team. If the alert survives the repair, submit the file for malware analysis through the suite vendor's documented portal, which takes files you believe were classified incorrectly.

Release the workstation after both checks pass

Two checks close the job. Application: the simulator opens your project and every function you need behaves, with the flagged file still quarantined or gone after a verified repair. Security: a full scan reports no unresolved detections, and no allowlist entry was created for the file. Write down the release, the detection name, the test result and the disposition, and keep the workstation off machine programming until the security check is clean.

The decision

Recommendation: Quarantine dadobra.fuo the moment your suite names it a Trojan, record the detection name, full path, file date and size, and suite version, and keep the file quarantined through every step that follows. Test the simulator on a non-production project for about 15 minutes, repair from an installer supplied by the vendor or its distributor, and submit the file through the vendor's documented portal if the alert survives the repair. Create an allowlist entry only when the vendor or your security team confirms the file in writing.

Questions