BobSoul

Thanks Just ran scan on one that was always hitting and it came out clean

Ok Heres the second one i grabbed -- running scans now to see if any further false hits richvideouninstall.zip

I will have another one I hope with a different MD5 - from the last machine that has been getting hits

Ok got one from a machine I didnt restore from richvideouninstall.zip

I'll try to get it from last one - I have just been removing the software from each workstation as I have so many to deal with. It appears its the 2020 - 2021 version of the Cyber link Media suite that being detected.

Still detecting on several endpoints -- I'm just removing now since I cant seem to get them to see the update -- unless only stand alone got the update and not Nebula endpoints - So far still getting detections on this file -- I know its a false ID Emsisoft and others are seeing it clean -- and its always the preinstalled dell version that is getting detected. Yesterday and all through the night scans went fine still the update this morning. Any suggestions on getting these endpoints to actually see the correction ?

Some endpoints appear to grab the updated and scan fine others dont even after restarts... Any suggestions?

Even After updating the endpoint agent and protection files -- still detects these after I restore when I rescan-- Its happening across about 100 machines - ( all not on same network ) Should I wait longer to try again?

I am still getting this across several machines just now 11:14 am eastern - I am updating all endpoints manually and then will see how it goes - maybe the update hasnt trickled down to all my endpoints

Thank You !

Did an update and restored and then re ran - it still detected but also removed an additional file - as well as the zip file The machine run scans every 4 hours everyday and prior scans were fine no detection on same files Category: Malware Group name: ITmachines Public endpoint IP: Endpoint name: OS platform: Windows OS release name: Microsoft Windows 10 Pro Location: C:\USERS\NFHRA\APPDATA\ROAMING\Microsoft\Windows\Recent\richvideouninstall.lnk Policy name: ITmachines Report time: June 2nd 2023, 12:14:57 UTC Scan time: June 2nd 2023, 12:06:10 UTC Action taken: Quarantined Threat name: Malware.AI.2019312709 Type: file Ran a scan against the file with EMSISOFT and it came back as clean

Hi Got the following detections on my nebula endpoints detecting cyberlink media suite registry entries and uninstall file - Which is present on most dell system. Category: Malware Group name: ITmachines Public endpoint IP: Endpoint name: OS platform: Windows OS release name: Microsoft Windows 10 Pro Location: HKLM\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS\CURRENTVERSION\SHAREDDLLS|C:\PROGRAM FILES (X86)\CYBERLINK\SHARED FILES\RICHVIDEOUNINSTALL.EXE Policy name: ITmachines Report time: June 2nd 2023, 11:10:16 UTC Scan time: June 2nd 2023, 11:01:00 UTC Action taken: Quarantined Threat name: Malware.AI.2019312709 Type: reg_value Category: Malware Group name: ITmachines Public endpoint IP: Endpoint name: OS platform: Windows OS release name: Microsoft Windows 10 Pro Location: C:\PROGRAM FILES (X86)\CYBERLINK\SHARED FILES\RICHVIDEOUNINSTALL.EXE Policy name: ITmachines Report time: June 2nd 2023, 11:10:16 UTC Scan time: June 2nd 2023, 11:01:00 UTC Action taken: Quarantined Threat name: Malware.AI.2019312709 Type: file The diagnostics zip file is to large to upload if you need it let me know which file in the zip to send. I did attach file though richvideouninstall.zip

Here's the log file incase you need MWB_jerryhomenew_Diag_2023_04_29_14_49_18.zip

Had this happen once again - triggering on windows store apps - offcourse it wont let you get file or restore etc cause its a windows protected file and from the last time it was a false detect assumning this again -- Im generating logs now and rerunning scan incase its alreayd been updated/fixed again Category: Malware Group name: offsite Public endpoint IP: Endpoint name: OS platform: Windows OS release name: Microsoft Windows 10 Home Location: C:\PROGRAM FILES\WINDOWSAPPS\A278AB0D.DISNEYMAGICKINGDOMS_7.9.9.0_X86__H6ADKY7GBF63M\A278AB0D.DISNEYMAGICKINGDOMS.EXE Policy name: Retina Consultants Report time: April 29th 2023, 11:34:42 UTC Scan time : April 29th 2023, 11:01:03 UTC Action taken: Quarantined Threat name: MachineLearning/Anomalous.97% Type: file

@ceckelberry Thank you - I never want to just assume something with out testing etc and then verifying -- This way can tell the boss its fine forget about it lol

Update info just incase its helpful - spoke with netgate themselves - the router is clean and they believe its the actual ip address itself with the 5.1 in that is triggering the error based on this from the debug log {"@timestamp": "2023-04-17T22:21:27.277Z", "session": "1681770081858", "message": "ANY: Just matched '5.1' in database: spyware", "level": "INFO"} {"@timestamp": "2023-04-17T22:21:27.277Z", "session": "1681770081858", "message": "OM: (PAGE_BLOCK) malware (spyware) match found on https://xxx.xxx.5.1:xxxx/ for https://xxx.xxx.5.1:xxxx/ changing the routers IP is not actually a quick option since it requires redoing an entire network of statics and other devices pools of address as well as IPsec tunnels and VPN connection profiles etc. With out doing anything to the browser guard can change to using the hostsname.domain inplace of the ip and it does not get blocked

Malwarebytes Nebula scans and active web blocker so clean as well - I just went through all the nebula logs etc for various machines and several scans on the machines I have been testing this on as well ( Emsisoft brower still sees it as fine as does adguard - default chrome protection only sees the self signed Cert and warns on that but that is normal and is documented by netgate pfsense as normal

Thanks - from what I can tell by the debug logs its the 5.1 that is hitting a match versus when using the host name of the router whihc they both load the same php pages and webgui in the same manner just different address. Ive extensively scanned machines etc - they are all clean -- have other pfsense routers connected via ipsec tunnels as well that dont detect but they do not have the 5.1 ip. this started on friday afternoon prior to that no problem earlier in the day accessing ( until after update on the browser guard) Just trying to give you as much info as possible

this is when accessing by host name versus ip which works with no issues just when using the IP If I do a factory reset it works fine again then a bit later starts second log is with doing a factory reset again BG-Logs_v2.6.0_2023-04-17_18261.txt BG-Logs_v2.6.0_2023-04-17_182834.txt

It still will work fine as long as I dont use the IP after factory reset it worked a few times than started again .. however works fine when accessing via the hostname I'll upload debug with accessing that way as well

ok I jumped the gun abit on that after closing the browser and trying again a few times it started again here is the debug file BG-Logs_v2.6.0_2023-04-17_182138.txt

That fixed it .... I tested across 2 machines after factory reset and no further blocking issue - when using the LAN IP. ( made sure allow list was blank as well... though I did that prior to testing with using the host name and domain name combo -which these routers use there own or you can use the network domain - which made a easy way to test for a real issue versus a false detection )

further info if i connect using the routers ( hostname and local domain ) it does not trigger the detection.. only when using the IP -- so this would then appear to be a false detection based on the IP since its fine using the hostname and local domain of the router lan side

Well after lots of testing it is only malwarebytes browser guard that does this - ( latest version ) - no other browser guards have blocked it- From what I can tell it appears to be caused by the sshguard feature of the webgui which monitors for attempts to log in from untrusted sources or locations thats triggering the browser guard in combination with the specific lan ip I know for a fact this router is not infected.... pfsense software is very good at preventing that and as I stated ( rebooted and went backwards to an backup image of the router ) verified with netgate documentations etc -- The combination of self signed certs and the sshguard appear to be triggering browser guard when in combination with the IP

Thats the screen shot I can continue or add to allow list -- its actually the router webgui thats being accessed -- I have checked router rebooted etc even rolled back to a previous config of the router and backup just to be sure Also other webblockers dont flag it and neither does endpoint nebula as I mentioned