9 Replies Latest reply: Feb 20, 2013 5:04 PM by Dave Breslin RSS

APT1: Appendix C Audit

Synopsis:

 


Mandiant Intelligence Center Report  - APT1: Appendix C Audit

 


Description:


 

This audit file determines possible infections by several of the malware items identified in the Mandiant Intelligence Center Report - APT1: Exposing One of China's Cyber Espionage Units. It includes checks for 34 of the malware variants identified in Appendix C The Malware Arsenal. An additional 16 checks are included to cover items identified by the Symantec Security Response Whitepaper - Comment Crew: Indicators of Compromise. The audit file utilizes a combination of registry checks and file system checks to find hosts which might likely be at risk or infected.

Due to the nature of these checks it is possible that some false positive results could be encountered. If you receive a result you believe to be a false positive please contact Tenable Support so that we can research the issue.

 

1.png

 

2.png

 

Total Checks:

 

50

 

 

Malware coverage:


LIGHTDART
AURIGA
BANGAT
BISCUIT
BOUNCER
COMBOS
COOKIEBAG
DAIRY
GOGGLES
HACKSFASE
HELAUTO
KURTON
MINIASP
SEASALT
TABMSGSQL
TARSIP-MOON
TARSIP-ECLIPSE
WARP
WEBC2-AUSOV
WEBC2-ADSPACE
WEBC2-BOLID
WEBC2-CLOVER
WEBC2-CSON
WEBC2-GREENCAT
WEBC2-HEAD
WEBC2-KT3
WEBC2-RAVE
WEBC2-TABLE
WEBC2-TOCK
WEBC2-UGX
WEBC2-YAHOO
GETMAIL
LIGHTBOLT
MAPIGET

File indicators
Registry indicators
Service indicators

 

See Also:

 

Mandiant Intelligence Center Report - APT1: Exposing One of China's Cyber Espionage Units

Appendix C The Malware Arsenal

Symantec Security Response Whitepaper – Comment Crew: Indicators of Compromise

 

 

Files Included:

 

APT1.audit

 

Location:

 

Tenable Support Portal

  • Re: APT1: Appendix C Audit
    jhaar

    Hi there

     

    This looks very interesting. I'd like to run it over our WAN, but the very first section in the .audit file concerns me.

     

    Is "Select FileName From CIM_DataFile"  recursive? ie does this audit involve nessus having to scan the entire C: drive, or is it looking for files in particular directories only? Obviously trying to scan thousands of hosts where nessus will sit there for up to (say) an hour per PC whilst recurse directory listings occurred would be prone to failure.

     

    BTW, what makes Tenable choose between creating an audit file instead of a new nasl? There are tonnes of existing rules for detecting malware via a range of techniques within nessus, so why has this APT one shown up as an audit?

     

    Thanks!

     

    Jason

    • Re: APT1: Appendix C Audit
      Renaud

      We've done a full blog about this and released several different plugins ( http://www.tenable.com/blog/active-and-passive-mandiant-apt1-detection ). Some plugins leverage the MD5 of the running processes (something that we can get easily so the impact is near-nil), while the .audit approach is much more thorough and indeed takes more time but will find more traces of malware (not just the running processes but also the leftovers of such processes).

       

      So we provide different means to achieve your audit, with different level of intrusiveness / performance impact.

      • Re: APT1: Appendix C Audit
        jhaar

        Thanks for the speedy response, are there estimates for how much longer the APT1.audit will add to a run? I could be concerned about nothing: we have some LANs where nessus takes 5-6 hours to run, even if the APT1.audit file made an individual PC scan take 1 hour longer, that could actually mean the site scan will take 6-7hours(?) Which wouldn't be too bad. My concern would be if it made site-runs take double the amount of time/etc

         

        Jason

        • Re: APT1: Appendix C Audit
          Mehul

          Most of the scans we ran yesterday within our lab yesterday were done in less than an hour. But those scans only had the APT1 .audit enabled, so your times may vary.

           

          -Mehul

        • Re: APT1: Appendix C Audit
          Dave Breslin

          Jason Haar wrote:

           

          Thanks for the speedy response, are there estimates for how much longer the APT1.audit will add to a run? I could be concerned about nothing: we have some LANs where nessus takes 5-6 hours to run, even if the APT1.audit file made an individual PC scan take 1 hour longer, that could actually mean the site scan will take 6-7hours(?) Which wouldn't be too bad. My concern would be if it made site-runs take double the amount of time/etc

           

          Jason

           

          Are you working within strict scan windows where its impossible to run a one off scan of a few hosts to get timings more specific to your slowest networks? If so, why not try a lab as a best effort:

           

          1. Run a scan of a few lab systems using your usual scan policy

          2. Run a scan of a few lab systems with just the .audit

          3. Run a scan of a few lab systems with both your regular scan policy and the .audit enabled

           

          Compare some timings and work on percentages. A best effort approach. If that won't work and you are really, really concerned and really want to run the .audit file then escalate the benefits to your management and plan on a one off scan within some future scan windows. You might even split a production test up - on the next set of scheduled scans just use a policy with the .audit enabled on one of your slower LANs to scan. Reduce the risk of an overrun of a scan window that way.

           

          I am really an advocate of labs, especially if the risk of over running a scan window has a huge risk to operations. In a lab you can try and emulate the hosts you have and the software you are likely to have installed.

           

          Are you already auditing your AV host solution with Nessus to ensure its enabled and up to date, to at least feel some comfort that the malware you want to look for with the .audit is unlikely to be present on your hosts? I think in the big picture of things thats a burning question. I do understand zero days but working under a bigger picture and leveraging the great value add in Nessus that seems to be very important on an ongoing process above and beyond a one off specific malware hunt.

           

          If I can help in anyway let me know. I have lots of lab equipment - but I don't have bandwidth constrained connections emulating whatever WAN tech you are using. Although I have seen some novel tech that can emulate different WAN network tech in regards to slowing network connections down in a lab.

           

          Regards,

           

          Dave

          • Re: APT1: Appendix C Audit
            Dave Breslin

            p.s. If you have been auditing your AV with Nessus then its just a suggestion for prioritization but why not start the malware hunt on those hosts with AV issues rather than try and sweep everything in one go. Another alternative to picking one particularly slow remote LAN for a test.

            • Re: APT1: Appendix C Audit
              jhaar

              You're reading my mind - I'm way ahead of you on that :-)  I was simply thinking this must be such a common customer concern that Tenable would have some stats on impact in advance. If not, then we simply have to find out for ourselves

               

              Jason

              • Re: APT1: Appendix C Audit
                Dave Breslin

                Jason Haar wrote:

                 

                You're reading my mind - I'm way ahead of you on that :-)  I was simply thinking this must be such a common customer concern that Tenable would have some stats on impact in advance. If not, then we simply have to find out for ourselves

                 

                Jason

                 

                  

                Understood Jason, you are being very diligent which is commendable. Especially with large-scale enterprise VA. I also understand Renaud's comments; there are an awful lot of variables involved including the hardware and platforms Nessus is installed on, the network layer and the complexities of the host configuration.

                 

                The more I thought about it the more obvious it was to prioritize these types of audits - and Nessus supplies an awful lot of ways to do that like listing hosts with AV disabled, AV not up to date, critical vulns, vulns with known exploits etc etc. In the blog Ron put together there are more obvious ways to bring event data together in the prioritization like PVS letting LCE know about the likelihood of hosts contacting related command and control channels and focusing on those hosts with the Nessus .audit scans, all made possible through SecurityCenter quite easily. The USM approach.

                 

                Good luck,

                 

                Dave