DM_HH 0 Posted September 13, 2022 Share Posted September 13, 2022 Recently, while accessing certain content within the CP of our website, ESET has started detecting a "suspicious application" (JS/Packed.Agent.Q). This only appears when users with access to the control panel try to access the modules that allow for editing certain types of content. Our developer had installed a new plug-in somewhat recently, but has uninstalled it and the issue remains. We use a somewhat niche CMS (Expression Engine) and so it's difficult to determine exactly what JS or other component of the site is causing this potential false positive, as the URL for the content in question appears in the form of: "https://<websitedomainname>/<entryID>/<uniquesessionID>" rather than pointing to a path I'm able to follow or provide for analysis. If I tried to submit the path to the page for analysis, it would not be reachable. As far as I'm aware, the suspected threat is only detected when working in the backend, not when browsing the website itself. What is the best way for me to have ESET confirm if this is a false positive or if there is some problematic content on the site? Link to comment Share on other sites More sharing options...
Administrators Marcos 4,935 Posted September 13, 2022 Administrators Share Posted September 13, 2022 Technically the detection is correct; it's a detection of a special JavaScript obfuscation misused by malware writers to evade detection. You could create a detection exclusion. If there are more complaints on the detection, we'll change it to aggressive. Link to comment Share on other sites More sharing options...
DM_HH 0 Posted September 13, 2022 Author Share Posted September 13, 2022 Thanks Marcos. I had created an exclusion, but wanted to check to see if there was any way for me to determine if there was any actual compromise. Would I need to look at every JS that is being called on the page when accessing one of these modules? Dan Link to comment Share on other sites More sharing options...
Nevermind 8 Posted September 14, 2022 Share Posted September 14, 2022 23 hours ago, DM_HH said: Thanks Marcos. I had created an exclusion, but wanted to check to see if there was any way for me to determine if there was any actual compromise. Would I need to look at every JS that is being called on the page when accessing one of these modules? If I wanted to check what suspicious JS is being loaded I would use Fiddler that logs every http/s request. But unless you are somewhat skilled in JS debugging I would not do it. JS/Packed.Agent.Q obfuscation makes the file unreadable in terms of what the file actually does. Link to comment Share on other sites More sharing options...
opjose 0 Posted October 4, 2022 Share Posted October 4, 2022 FYI we are running into the same issue with our own web site backend. Link to comment Share on other sites More sharing options...
Administrators Marcos 4,935 Posted October 4, 2022 Administrators Share Posted October 4, 2022 44 minutes ago, opjose said: FYI we are running into the same issue with our own web site backend. Please provide logs collected with ESET Log Collector. Make sure to select quarantined files for collection as well. Link to comment Share on other sites More sharing options...
opjose 0 Posted November 2, 2022 Share Posted November 2, 2022 We resolved the issue. As stated, ESET correctly identified a problem with the remote site. It turned out that the backend of the site was utilizing components that had issues. We alerted the developer who deployed a different version of the backend components resolving the issue. Link to comment Share on other sites More sharing options...
Recommended Posts