2 Replies Latest reply: Feb 15, 2013 4:01 AM by igfloz RSS

    Backdoor: Acid Battery (false positive) ?


      Recently upgraded a solo NSM to V7.5 and applied relevant updates to a number of  I-1200/1400 and M-1250 IDS devices on our network.

      My IDS devices are configured "In Line"

      My estate OS updates are managed by a WSUS server. All workstations are AV managed by an ePO server and up to date.


      I have recently seen "BACKDOOR: ACID BATTERY" Trojan as a threat  - source= 4 different workstations, destination = my WSUS Server.

      I am seeing this "threat" on only one of the IDS devices  (all source PC's are passing traffic through the one IDS)


      Google  shows that Mcafee lists acid battery as Backdoor-DE, but I cannot find much information specific to Mcafee on how to remove , or anything regarding "acid battery trojan" as a matter of fact !


      I have wiresharked the source pc's and captured packets, but all packets seem to show benign WSUS update characteristics.

      i.e port activity for WSUS port is 8530, not the internet described acid battery port of 32418

      Source workstations have been scanned with McAfee Virusscan 8.8 with no result.



      My question or discussion is.............


      Is the Acid Battery threat a possible false positive ? how do I tell ?

      Does the detection engine work effectively with WSUS update traffic ?

      Do Mcafee have a known fix / removal method for Backdoor: Acid Battery trojan ?


      P.S. - The reporting IDS device policy is "IDS", not "IPS" - might that have something to do with it ?


      Any help or further questions would be most beneficial to me

        • 1. Re: Backdoor: Acid Battery (false positive) ?



          Looking at the signature definition


          Signature #1:

          This signature matches against one or more of the following strings:





          and non-string signature(s)


          Signature #2:

          This signature matches against one or more of the following strings:






          If you can find any of them in your traffic capture, that might explain why its firing (the non-string signatures part doesnt help us much). It doesnt look like the strongest signature I've seen.


          The content for this attack appears to have been updated in 2004 so this is some pretty old malware and, if you have an antivirus installed on each of the boxes, you would hope that catches it.


          For this to be the real acid battery, someone would have had to compromise all 4 workstations and, provided you are happy enough to rule out the insider threat, be issuing command and control (C&C) instructions from beyond your network. Depending on how your network is configured, these machines would probably have to beacon out to the C&C domain which may raise alerts and be an additional thing to look for. Additionally, if the alert always appears when there is an update being pushed, this might be another pointer to fale positive.


          Without looking at the traffic its difficult to be sure, but it sounds like a false pos.


          I couldnt find anything relating to tell tale registry entries from a quick google but if the AV doesnt catch this, given its age, ..... I would be shocked.


          The IDS policy will only mean the traffic isnt blocked by the device (unless you have made custom mods). If you apply an IPS policy, and the attack is recommended for smart blocking, the device will block the traffic.


          Hope that helps.

          • 2. Re: Backdoor: Acid Battery (false positive) ?

            Thanks very much for your reply.


            McAfee antivirus is running on all source machines and has not reported any threats (daily & weekly scans are carried out) - I also did a full on demand scan on the machines.


            I have captured packets from the source machines and cannot find any match against the suggested signatures.

            This makes me think that it is the non-string signature that is triggering the reported threat and coupled with the fact that I can match the report time to actual update times, this may in fact be a false positive.


            I also checked other traffic from the  source machines and haven't seen any other anomolous traffic, so I don't think any C&C instructions are being sent  or received.


            There were only a small amount of reported threats (9 in total) and for the moment they have stopped.

            I'll just keep an eye on it for now and take it as a false pos.