Behavioural analysis of Flash files

2009-12-01

Ken Dunham

iSIGHT Partners, USA
Editor: Helen Martin

Abstract

We have seen a notable escalation in web-based attacks over the past few years, especially with regard to malicious Flash files - which are capable of redirection, execution of embedded malicious code and exploitation via vulnerabilities. Here, Ken Dunham provides an overview of the behavioural analysis of Flash files.


A notable escalation in web-based attacks has been seen over the past few years, especially with regard to malicious Flash files. Flash files are capable of redirection, execution of embedded malicious code and exploitation via vulnerabilities that exist in certain versions of Flash. Analysis of Flash files can quickly be made more complicated through the obfuscation of bytecode within malicious files, using common JavaScript obfuscation techniques in addition to professional tactics for obfuscating entire files to hinder analysis. Static and behavioural analysis can provide incident response teams and malcode researchers with a quick indication of the possible malicious activity associated with Flash files.

Introduction to Flash file format

Flash files have a MIME type of application/x-shockwave-flash and contain one of two possible header values: FWS or CWS. FWS represents a normal Flash file while CWS represents a compressed Flash file (SWF). Compression is very common and can be seen in the example shown in Figure 1.

A hostile Flash file containing a CWS header.

Figure 1. A hostile Flash file containing a CWS header.

The general format of a Flash file begins with the header, an eight-bit version number, and a 32-bit file length field:

[FWS/CWS] [Version] [Length] [Header] [[Tag Code + Length] [Tag Contents]]

Tags within Flash files may contain a variety of media such as image files, ActionScript, video streams, buttons and JavaScript. ActionScript and JavaScript are frequently the focus of malicious research. It is also advisable to look for unknown and undocumented tags within a Flash file which may be corrupt or have malicious content.

Identifying malicious content

A variety of tools exist to analyse Flash content. Some are limited to working only with older versions of ActionScript when such content is present in a file. Others only work to decompress compressed (CWS) Flash files so that the decompressed file (FWS) can then be analysed with other tools. There are a select few applications that are solid choices for triage of potentially malicious Flash files. While these tools fall short of in-depth reverse engineering and deeper analysis, they are excellent choices for the busy professional seeking to quickly triage potentially hostile content and/or egress communications.

Online scanners

Two free online scanners stand out above the rest for rapid triage of code. Wepawet and Adopstools are both excellent tools for the analysis of Flash files. In some cases dynamic analysis is also available.

Wepawet: http://wepawet.cs.ucsb.edu/Wepawet enables a researcher to upload both files and URLs that point to potentially hostile content. This is an excellent option for both real-time analysis of a threat or string extracted from an IDS log as well as incident response and/or forensic investigations that may turn up potentially hostile Flash content. At the time of writing this article, the scanner does not support dynamic analysis of Flash 9 files.

Static output from the tool includes possible malicious methods (such as ‘Loader.loadBytes method detected’), hash, submission and process date and time, and Flash version. It also includes a VirusTotal scan report and any URLs referenced in the file. Note that it is common for legitimate Adobe.com URL references to be found in such code.

Wepawet analysis of a hostile SWF file reveals several GetURL addresses and other malicious identification.

Figure 2. Wepawet analysis of a hostile SWF file reveals several GetURL addresses and other malicious identification.

Adopstools: http://www.adopstools.net/index.asp? section=tools&page=clickcheckerFor the Adopstools scanner the results are split into five sections: header and resources, preview and click test, tags list, GetURLs and ActionScripts, and dumping code. The last two are especially helpful for a busy professional attempting to identify any possible malicious URLs or scripts. Unfortunately this scanner can be a bit slow at times. The interface is more raw-code-analysis-oriented than the GUI-based Wepawet scanner.

Note: If you upload a defanged file such as badfile.swf_ this scanner will display a warning that it’s not a Flash file, but it will proceed with scanning if the ‘Scan’ button is selected.

Adopstools includes a ‘Dumping Code’ section to view code within a Flash file.

Figure 3. Adopstools includes a ‘Dumping Code’ section to view code within a Flash file.

Identification and capture of potentially hostile scripts and/or URLs is critical for a security researcher. It is common at this point to attempt to capture code related to all possible remote files or links related to the Flash file for domain and abuse research, and/or de-obfuscation of extracted scripts of interest.

Decompiling using Trillix

Eltima offers one of the most easy-to-use, robust GUI applications for Flash analysis. The program enables a security researcher to quickly identify tags and scripts, and also to export scripts of interest. If Adobe Flash Studio is installed, editing of FLA files (Flash Source) is also supported. ActiveX must be installed in order to use this program. Figure 4 shows how non-obfuscated URL content is clearly revealed via scripts decompiled by Trillix.

Trillix decompiles and displays scripts as well as running the Flash file via preview mode.

Figure 4. Trillix decompiles and displays scripts as well as running the Flash file via preview mode.

Caution: this program runs Flash file content dynamically by default. Be careful only to run this within a Windows lab environment to avoid accidental damage to other systems.

URLs or scripts of interest can be exported simply by using copy and paste or by using the ‘Extract SWF objects’ button. When the extraction option is used Trillix automatically extracts all scripts by default to a working directory and then displays that directory in a new window. For example, the case illustrated in Figure 4 resulted in Frame 0 and Frame 20 exports and associated ActionScript (.as) exports which contain getURL statements such as the following:

//Action tag #0

getURL(“hxxp://5173vip.seawww.cn/cuteqq.htm \r”, “_blank”);

text = “?!”;

Script analysis is becoming increasingly difficult as both the ability and adoption of techniques for obfuscating scripts within Flash files advances.

Decompiling with Flash Tracer

Flash Tracer is one of the easiest ways to dynamically analyse the behaviour of a Flash file – once you get it set up properly. The set-up can be a bit tricky, requiring the installation of a Flash debugger, flashtracer.xpi for use with Firefox, and then a special configuration file. A debugger version of Flash sends output from the trace() method to a log file which is then viewed with the Flash Tracer extension within Firefox. If a non-debugger version exists, uninstallation of the player is required for a debugger version to be installed.

Caution: this results in a dynamic execution of Flash content. Be careful only to run this within a lab environment to avoid accidental damage to other systems.

The following is an overview of how to install Flash Tracer on a Linux operating system such as Ubuntu. Three core steps are followed: installation of a debugger version, mm.cfg creation, and Flash Tracer installation and use.

Flash Player debugger installing on a Linux computer.

Figure 5. Flash Player debugger installing on a Linux computer.

  1. Go to http://playerversion.com/ and view the report to see if Flash is installed and if a ‘debugger’ version exists.

  2. If a Flash Player is installed but it is not a debugger version, uninstall it using Synaptic or other Linux tools.

  3. Install Flash Player Debugger for Linux by downloading it from http://www.adobe.com/support/flashplayer/downloads.html. Extract files and navigate to the /plugin/debugger directory. Run the ‘flashplayer-installer’ in the terminal and follow the prompts to complete the installation.

  4. Go to http://playerversion.com/ and confirm that a Flash Player ‘debugger’ version is installed correctly.

  5. Create a log file by running a Flash file or creating it as a placeholder for the debugger. Locate and run a SWF file or create a placeholder at /home/{username}/.macromedia/Flash_Player/Logs/ flashlog.txt. Replace {username} with the current user account name for Linux.

  6. Create a file in the home directory for Linux called ‘mm.cfg’ with the following data:

    ErrorReportingEnable=1
    
    TraceOutputFileEnable=1
  7. Download and install Flash Tracer from http://www.sephiroth.it/firefox/flashtracer/. If you saved it as a file, drag flashtracer.xpi over Firefox and restart Firefox after installation.

  8. Open Firefox and configure Flash Tracer to point to the flashlog.txt file, replacing {username} with the user name for the current account: /home/{username}/.macromedia/Flash_Player/Logs/ flashlog.txt. Note: be sure to show invisible directories in the Home folder of Linux (right-click on the directory listing window) to browse to flashlog.txt file. You may also just type in the path manually and click OK.

  9. Load a hostile SWF and watch Flash Tracer read the trace() output to the Firefox sidebar. Note: any changes you make using this tool directly impact the flashlog, such as clearing the log file as you clear the Flash Tracer window.

    Flash Tracer configuration requires invisibles to be revealed if browsing to the flashlog.txt file.

    Figure 6. Flash Tracer configuration requires invisibles to be revealed if browsing to the flashlog.txt file.

    Flash Tracer displays the contents of flashlog.txt in a sidebar when a SWF is loaded from a remote server.

    Figure 7. Flash Tracer displays the contents of flashlog.txt in a sidebar when a SWF is loaded from a remote server.

Flash Tracer options are intuitive for pausing and clearing log file displays. Analysts should be looking for URLs that display, possibly pointing to remote exploit sites or redirected targets, and other actions such as getURL statements and undefined tags. Help with interpretation of debugger comments can be gained from the runtime error research published at http://livedocs.adobe.com/flex/201/langref/runtimeErrors.html. For example, FScommand and getURL issues that may exist in a suspect Flash file may be linked to JavaScript actions and egress communications as shown in the Flash Tracer example below for a known hostile file:

*** Security Sandbox Violation ***

FSCommand halted (AllowScriptAccess is ‘’): FSCommand:showmenu

Common ActionScript references of interest for hostile activities include but are not limited to FSCommand, getURL, LoadMovie, LoadMovieNum, ExternalInterface, navigateToURL and URLRequest.

Flash security

More information on Flash security as a whole can be found at https://www.flashsec.org/wiki/Main_Page.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.