FireEye Alerts: When does an alert indicate an infection?

Version 12

    DOC-4829 (Formerly "Best Practice Guide: Incident Response for FireEye Alerts")


    Responding to malware incidents should be done as part of an organized, systematic attempt to understand the environment, understand the threats that are present or introduced into the environment, remediate the threats, and gain a long-term understanding of the effectiveness of policy and response actions. The infographic below gives a very brief overview of FireEye Alerts, the difference between an exploit and an infection, and general suggestions on Incident Response.


    For more a more in-depth understanding of alerts, check out our Alert Analysis training course.




    Data Collection and Trend Tracking


    For tracking long-term trends, collect the following information when incidents occur:


    • The user / endpoint that was attacked (machine, username, level of access)
    • The vector that was used to introduce the attack into the environment (e-mail, web, drive-by, usb, physical)
    • If a drive-by or exploit occurrs, document:
      • the application that was exploited, and whether it was patched to patching standards or out of date
      • the site where it occurred
    • If a binary event occurs, document:
      • the file type and malware that was transferred into the environment
      • whether AV had coverage for the file at the time the malware was brought into the environment
    • If a callback event occurs, document:
      • the type of callback (DNS or beacon)
      • the IP it was beaconing to
      • the domain (if the beacon was by domain)
      • the port and protocol involved in the callback
    • Save all associated threat indicators with the event. Store all pcaps. For exploits, retain the zip file of the webpage as well. For binaries, retain the malicious file.
    • Document the policy response that was taken for this particular incident, the amount of time that elapsed between detection and remediation, and particular exposure during that time, if any.
    • Document the context and analysis of the attack – any details about what may have happened or why, based on the behavior, logs, or user input
    • Any additional information that may be relevant to understanding the event



    This infographic is based on a guide originally created by Systems engineer Alex L. and Solutions Architect tamhuynh. Thanks to Eric for providing it!