FAQ

  1. General
    1. What is Wepawet?
  2. SWF Analyzer
    1. Supported SWF Versions
    2. What are the possible detection results?
    3. URL Detection
    4. Shellcode Detection
  3. JS Analyzer
    1. What kind of malicious pages are detected?
    2. What are the possible detection results?

1. General

  1. What is Wepawet?
    Wepawet stands for Web Engine to Protect from and Analyze Widespread and Emerging Threats. It is a collection of tools that use static and dynamic techniques to analyze web content to identify possible malicious behavior. It currently supports analyzing Adobe Flash, JavaScript and PDF files.

2. SWF Analyzer

  1. Supported SWF Versions
    Wepawet supports both static and dynamic analysis of ActionScript 2.0 and SWF files up to and including Flash 8. Only static analysis of Flash 9 files is currently supported.
  2. What are the possible detection results?
    The three possible detection results for the SWF analyzer are benign, suspicious, and malicious. Malicious means that the resource is anomalous and attempts to run one or more exploits that we know about. Suspicious is used for resources whose behavior is anomalous but does not attempt any known exploits or malware related behavior. Benign is used for resources that do not appear as anomalous. NOTE, the suspicious and benign classifications do not ensure that the SWF resource is non-malicious. If you know that a certain SWF file is indeed malicious but is not classified as so, please let us know.
  3. URL Detection
    The SWF Analyzer uses two forms of URL detection: runtime and static. The runtime url detection exposes URLs that the SWF file references during its runtime execution. This includes URLs used in network connections made during execution, or URLs that are generated by dynamic ActionScript execution.

    Static URL detection analyzes the uncompressed data of the SWF file directly. This exposes URLs that are contained within the SWF file but are not necessarily accessed during normal execution. For instance, this may include URLs stored within SWF TextFields that may only be accessed when a certain user action is done (clicking a button, for instance), or URLs that may be involved in the execution of shellcode. An file offset will be given for URLs that are statically detected which indicates where the URL was found. A XOR key will also be given for URLs that have been encrypted with the given key. This is a common technique to hide URLs in shellcode.

    Detected URLs will also be checked against a database of known malware hosting domains. Any domain that have been associated with malware will be indicated on the report. The Malware Domains database is currently used.
  4. Shellcode Detection
    Shellcode detection is accomplished by applying GetPC heuristics to the uncompressed SWF byte data. See libemu for more information on this technique.

    When shellcode is detected, the file offset of its location is given, along with a disassembly of the surrounding bytes. NOTE, the complete shellcode is not given, nor is the entire disassembly actually shellcode. The disassembly is only shown to give a rough idea of what the shellcode is doing. Often, the disassembly only includes a few instructions of a XOR decryptor with the rest of the disassembly being meaningless due to being XOR encrypted. A more in depth analysis of the shellcode should be done to determine exactly what it is trying to accomplish.

3. JS Analyzer

  1. What kind of malicious pages are detected?
    The JS Analyzer is designed to detect pages that attempt to exploit vulnerabilities in the browser or its plugins to take control of the victim machine. These attacks are generally called drive-by downloads. Note that other kinds of questionable web pages (e.g., those that push fake codecs or run fake antivirus checks) are currently out-of-scope and, thus, typically, will not be flagged as malicious.
    PDF files are analyzed to determine if they use malicious JavaScript content. Exploits that do not rely on JavaScript, generally, will not be detected.
  2. What are the possible detection results?
    An analyzed resource can be classified in one of three ways: benign, suspicious, malicious. Malicious means that the resource code is anomalous and attempts to run one or more exploits that we know about. Suspicious is used for resources whose code or behavior is anomalous but cannot be classified into one of the known exploits. 0-day exploits or older exploits for which we don't have a signature yet should be classified as suspicious. Finally, benign resources do not appear as anomalouos and do not launch known attacks.