Cracking WPS networks with Reaver

Last Updated on Friday, 27 January 2012 12:36

Using SET and the Teensy Controller in Penetration Tests

Using SET and the Teensy Controller

SET is the Social Engineering Toolkit, a framework bundled with Metasploit to be used by penetration testers to facilitate the following social engineering attacks:

1. Spearphishing
2. Web based attacks- Java, MITM, Credential Harvester, browser_autopwn
3. Infectious Media Generator
4. Payload and Listener
5. Mass Mailing campaign
6. Arduino-Based Attack Vector
7. SMS Spoofing – Send malicious SMS messages
8. Wireless Attacks

The benefit of SET is that it is menu driven, rapidly updatable and extendable, and integrates seamlessly with Metasploit.

Teensy is a USB-based microcontroller in a very small form factor. All programming is done via the mini-USB port controller. Teensy is used mainly by hobbyists for various projects such as game controllers, rhythm-based door locks, and home automation.

What makes the Teensy controller interesting for penetration testers is that is has a feature that allows an attacker to successfully compromise a victim computer, even if USB removable storage and AutoRun is disallowed by the organization. How can this be? We can configure Teensy to appear as a USB-based Human Interface Device (HID). Keyboards and mice are also in the HID category and are generally allowed by an organization. Once plugged in, Teensy will send a series of keystrokes to the Operating System as if a User were typing very quickly (and without error), building our attack payload and then executing it.

What does this mean for us? We have a very small attack vector that can be easily camouflaged, plugged into a victim host, and owned within 15 seconds, even if the host is configured to not allow USB thumb drives. The attack payload is limited only by our imagination, but generally is used to download a pre-generated payload and execute it, such as a Meterpreter reverse HTTPS shell that has been run through msfvenom or msfencode.

SET will step you through all the necessary steps for building the Teensy PDE file, selecting and encoding a payload –it will even help with evasion techniques such as backdooring a known good executable, or running through several encoders. It will even start up a Metasploit payload handler.

Attacking with Teensy is relatively simple. Plug it into an open USB port. For the

attack to succeed, the workstation must be unlocked, and the entire attack takes

about 10-30 seconds, depending on the speed of the victim host- the system has

to create Registry entries, prepare the system for the new device, etc. Once that

is done, Teensy will send keyboard commands to the desktop at about 65cps. It begins by sending a Ctrl+Esc, which opens up the Windows menu, then types “CMD.EXE /c” in the Run menu.  Once a command prompt is open, it will echo a short VBScript one line at a time into a .vbs file and then execute it. Typcially, SET will build a Teensy loader file that will have it echo out a HTTP downloader, which will pull a file from the attacker’s website and execute it.

Don’t touch the keyboard, as it will continue to send keystrokes to whatever window currently has focus!

On the Metasploit host, it is best to have an Autorun script that immediately migrates the shell off of the current process to a different common process, and kills the x.exe process. It is best to use Teensy when nobody is looking as this will show some desktop activity opening up a command prompt and the Run command. Use whatever excuse necessary to get the victim to look away for a few seconds. Be creative! Engage the target in some conversation, show off a magic trick, or just don’t shower for a few days.

What can we do with Teensy now that we have it set up for evil? Despite it’s small size, we can’t really go around plugging a penny sized chip with a USB cable sticking out of it…. so how about we camouflage it?

Here is just a cheap mouse from Best Buy, which I took the guts out. With a few additional lines of code, I can simulate cursor moves onscreen to make it appear as if the mouse functions. A clever attacker could play the role of a desktop support technician, or a fellow employee who thinks his mouse may be dead and wants to troubleshoot the problem to see if it’s the mouse or the computer.

In fact, this is what Netragard did recently, but expanded the concept by installing a USB hub, Teensy, and USB flash drive, all within a Logitech mouse body (which they didn’t destroy like I did). With some reconnaissance, they found a suitable victim and sent him a “promotional” mouse with all the marketing accessories to make it look legit. Three days after they FedEx’d the mouse, they got a connection back from their target. Trojan Horse? No. Trojan MOUSE.

People may begin to get wise to the “dropped USB stick” gag, or workstations may be locked down to prevent using removable storage, but new and novel attack vectors can still be employed to keep this vector fresh.

Fortunately, we are not limited to just pulling down a Meterpreter payload with Teensy. Whatever can be sent via keyboard and mouse can be sent by Teensy. Add a user, stop Windows Firewall, open a browser and visit a malicious website, stop Antivirus. The possibilities are only limited by what evil we can imagine. With some basic electronics, programming, and soldering skill, a complete and robust “plug and pwn” kit can be developed. A cheap mouse with some..ahem… new hardware, gussied up to look cutting edge and sent as a promotion is sure to get a good response.

As user awareness increases and workstations become more secure by default, we as penetration testers must seek new attack vectors. Teensy helps accomplish this as it does not appear as removable storage media to the Operating System. Linux and OSX will happily accept input from Teensy! Work is being done on Teensy to make it a more robust attack tool. The Programmable HID USB Keystroke Dongle project provides libraries and code examples to create unique attacks.  The Teensy USB Development board can be purchased at http://www.pjrc.com/teensy/ .

Last Updated on Wednesday, 30 November 2011 10:09

Rapid Malware Analysis

During a response to an intrusion, especially those involving sophisticated threats, the need for rapid malware analysis is paramount.  At some point in the investigation the adversary’s malware will be identified and an urgent need will exist for the incident responder, forensic examiner, or malware specialist to perform rapid malware analysis.  Rapid malware analysis is both quick static and dynamic malware analysis in order to quickly obtain the characteristics, artifacts, and indicators of the malware that allow an incident responder to identify other systems in the network that may be compromised by the same type of malware and/or adversary.  It generally does not involve any Reverse Engineering or Reverse Code Engineering-that is taking the malware and establishing pseudo code or source code that details the full behavior of the malware.  Although the Reversing process will generally detail the full functionality of the malware, this is generally a very long process requiring a specialized and experienced reverse engineer.  When responding to intrusions time is of the essence and the responders may not have the luxury of being able to send off the malware to a specialist and then wait days or longer for the results.

By performing Rapid Malware Analysis, a responder can quickly identify the file, registry, network, and a few other indicators made by the malware when executed and use those indicators as input for network appliances such as a proxy or IDS in order to help identify all systems compromised with similar malware.  The responder must pay special attention to any file, registry or network indicator that is either created, access, modified, or deleted as part of the malware’s execution.  As an example if it is determined that the malware always creates a file named ####tor.txt (where # represents random numbers) when executed then this serves as file indicator and the responder should leverage a custom script, SCCM, etc, to search the entire network for system drives that contain any file that matches *tor.txt pattern.  Discovering similar files will likely indicate that the system is also compromised.  In order to get to this stage of the response, the responder must first perform the rapid malware analysis process.

I will briefly describe manual methods for performing the Rapid Malware Analysis and then identify some more automated solutions.  The first part of Rapid Malware Analysis is static analysis-that is performing analysis on the malware without actually executing the malware.  For these discussions we will assume that the malware we are dealing are Microsoft Portable Executable files (.exe, .dll, .com, etc). The first part of static analysis involves fully documenting the file name of the malware, its size in bytes and the MD5 and/or SHA-1.  It is important to keep good record of these factual items for the malware obtained in order to avoid duplication of effort in analysis.  Once the malware has been hashed, it can be checked against various hash sets or online hash resources such as http://www.virustotal.com or http://fileadvisor.bit9.com. Next the analyst should scan the malware with several Antivirus programs with the latest definitions.  Both the hash checks and AV scans can quickly identify previously known malware samples that can either eliminate analysis on your part or speed your analysis by following someone else’s previous analysis of the same sample of malware.  In addition, during static analysis, the analyst should record the icon displayed by the malware and any file property or metadata associated with the icon.   The analyst should perform a manual review of the file with a Hex Editor and inspect for file signature, PE sections for indications of packer use, any notable strings, or possible overlay.  This information should also be extracted via third party tools such as GT2 (file signature), PEID (packer signature detection), Microsoft SysInternals Strings or Foundstone’s BinText (strings).  Using PEView, an Examiner can quickly determine the compile date/time and also inspect the PE file to determine if it is an .exe, .dll, or .sys.  When reviewing strings it is important to note items such as monikers, IP addresses, ports, execution parameters, author, version, domain, registry values, file names, and others.  Any indicators revealed in strings should be a sought out when performing dynamic analysis.

Several considerations should be taken into account when performing dynamic analysis.  The first is the dynamic malware analysis environment.  A small virtualization environment between two virtual machines is usually sufficient for most rapid malware analysis.  In order to help identify the machines, I regularly label the virtual machines as Victim and Destination to include a banner on the top of each screen. This virtual environment should be restricted so that only the two virtual machines can communicate with each other and have no Internet access.  This will require the Destination virtual machine to be able to simulate services that would normally allow for Internet access so that the malware’s network behavior can be analyzed.  Thus it may be necessary for the Destination VM to run services such as fake DNS resolution, Web Server, FTP Server, Mail Server, IRC Server, and also function as a sniffer by running a network monitoring application such as Wireshark.  Additionally, it is recommended to assign public IP addresses to the two virtual machines in case the malware inspects this component.  In some cases, the malware may be created with VM detection capabilities thereby preventing analysis in a virtual environment.  In these cases, it may be necessary to replicate the virtual environment with bare metal hardware, such as two laptops and a switch or hub, however, with the prevalence of virtual infrastructure, more and more malware authors have to allow their code to execute in a virtual environment. As always, leverage the snapshot feature of the virtualization software to quickly revert and repeat analysis.  Caution should be taken with inserting USB devices into an infected virtual machine as the malware may infect the removable media device.  The following image depicts the virtual environment.

Once the virtual environment is properly setup, the next challenge is determining how the malware executes.  In some cases, it will be as simple as double-clicking the malware.  In other cases it may be a DLL file that requires the rundll32 function along with a parameter in order to launch it.  And yet in others it may require modifying the registry in order to run it as part of a Windows Service.  Some malware may be a 64-bit application and require a 64-bit VM in order to execute.  Often due to lack of known file extension, file signature analysis coupled with PE file examination will reveal the true nature of a file.   Keep in mind that .exe files will execute in a Command Prompt even without a proper file extension. Using Microsoft’s Process Explorer one can validate if successful execution of the malware has been achieved.  Once the execution of the malware has been determined, it is recommended that a snapshot be taken with the malware just prior to execution.

Several strategies exist for performing dynamic analysis.  Again during dynamic analysis the malware is executed and its behavior is analyzed.  The first strategy involves simply executing the malware and then using tools such as those available from the Microsoft’s SysInternals Suite to examine the behavior of the malware.  Tools like Process Explorer, Regmon, Filemon, Proccess Monitor and others can reveal good indicators from the malware execution but will usually require the most work and knowledge to sort out normal system behavior from that of the malware.  The second strategy involves executing the malware using installation monitors.  These are generally applications used by Application Developers to monitor and troubleshoot the behavior of their applications.  These normally work by taking a snapshot of the system’s files and registry prior to execution and then another snapshot post execution of the malware, and finally displaying the difference as the results. Tools such as InCtrl5, Regshot, and InstallWatch will reveal any file or registry entries that were created, accessed, deleted or modified and can help accomplish this function. A third strategy for malware analysis is executing the malware within a sandbox application.  Several antivirus vendors now include a sandboxing feature.  An independent solution for sandboxing is Sandboxie from http://www.sandboxie.com.  Once executed, the Sandboxie application contains all the files created in a SandBox folder/directory and generates alerts to any new Windows service created.  A fourth strategy is to execute the malware as part of a debugger such as IdaPro, OllyDbg, or Immunity Debugger.  The goal here is not to perform reverse engineering but instead establish break points that may help reveal un-obfuscated strings or pause execution to reveal files that are created and immediately deleted.

During execution of any of these strategies it is important to have a network monitor such as Wireshark on the virtual network interface of the Destination virtual machine to capture any DNS requests or beacons.  The malware should be executed with fake DNS resolution and with no DNS resolution to see if its behavior is different.  Likewise some malware performs differently after extended periods of execution, so if possible, a last test would be to allow the malware to run in the virtual environment overnight.  It is important to note IP addresses and ports, beacon domains, user agents, and whether communication complies with standard RFC specifications.

The final dynamic analysis strategy is to use a sandbox solution that automates the dynamic analysis.  Using these solutions, the malware is provided via an interface and a report is generated that documents the indicators of the malware.  A great list of these sandbox solutions (some more automated than others) can be found at this URL: http://forums.malwr.com/index.php?/topic/4-malware-analysis-sandbox-projects/ .  These solutions may take some time to setup or cost some money but once setup can be leveraged to more quickly analyze numerous malware samples.

An Incident Responder's First Actions (Memory Analysis)

Long gone are the days when Incident Responders would simple “pull the plug” on computer systems and then perform a forensic acquisition of the system.  This method does not allow for capturing precious volatile data that can be obtained by performing memory acquisition and executing an automated incident response tool.  In many cases, information from volatile data, such as current established network connections, could be the vital investigative info that can be passed on to network sensors to quickly determine the extent of the compromise.  Without the capture of this volatile data, an Examiner’s job is made much more difficult for determining information such as running processes and services, network connections, and evidence of malicious code.

The new incident response process flows more along the following sequence:

Memory Acquisition -> Incident Response Tool -> Capture on Screen Info -> Remove the network cable -> Determine whether to pull the plug or gracefully shutdown the system -> Forensic Acquisition of the system

Fortuitously, Incident Responders now have several tools to choose from when performing memory acquisition on Microsoft Windows systems.  Below is a list of some of the more common memory acquisition tools.  It is important to note that as an Incident Responder, you want to be able to take a portable version of the memory acquisition tool and place it on an external removable media device, such as a USB-powered 1TB Western disk drive.  In this manner, you plug in your external drive into the target system, execute the memory acquisition tool, and store the memory dump to a separate folder on the same drive.  Ideally this external drive will also have the automated incident response tool and possibly an application for forensic acquisition so that all elements can be captured in sequence.  An Incident Responder should also always run these acquisition tools with administrative privileges, as many will not obtain all sections of memory unless executed with Administrative privileges, therefore use the “Run as” option.  In Corporate environments, Incident Responders should test the memory acquisition tool on a similar non-critical system in order to get a better understanding of the effect of corporate GPOs on the memory acquisition tool.   In other words, don’t make the first time you are executing a tool when you are attempting to run it on the target system.  Many memory acquisition tools also have free and paid for versions and come with limitations (i.e. will not capture memory over 6GB of RAM or will only capture memory on specific OSes).  Please be sure to become familiar with the limitations of the memory acquisition tool you are using; specifically for your target OS and the size of RAM.

Memory Acquisition Tools:

AccessData FTK Imager– free, GUI based, captures in raw format.  A portable version, FTK Imager Lite, conveniently allows for the minimum files necessary to run a program to be placed on a removable drive.
http://www.accessdata.com/support/adownloads

Guidance Software’s winen.exe & winen64.exe – Command line based tool included as part of the purchase of Guidance Software EnCase Forensic products. Captures in EnCase proprietary formatted (E01), which can be converted to raw using FTK Imager.
http://www.guidancesoftware.com/forensic.htm

Moonsols win32dd.exe & win64dd.exe – free command line based tools included as part of the Moonsols Windows Memory ToolKit , which comes in a Community and Professional edition.  Captures RAM to a raw format.
http://www.moonsols.com/products/

Mandinat Memoryze – free and once installed, the command line based tool can be copied to perform memory capture.  Captures RAM in a raw format but also captures supporting XML files for analysis.
http://www.mandiant.com/products/free_software/memoryze/

HBGary Fastdump & FastDump Pro – command line based tool that perform memory capture into raw format or HBGary analysis format.  Included as part of HBGary Responder and HBGary suite of tools.  Community edition is free with limitations.
http://www.hbgary.com/

ManTech mdd.exe – command line based tool released by ManTech but appears does not appear to be actively developed.
http://www.mantech.com/capabilities/mdd.asp

After successful memory acquisition, an Investigator will want to perform Memory Analysis on the captured memory image.  Although most of the Companies that make a memory acquisition tool also have tools for memory analysis, in this post we will discuss two free memory analysis tools; Volatile Systems’ Volatility and Mandiant’s Redline, each more suitable to different types of Users but also great compliments to each other.

Volatile Systems Volatility is a Framework of collection tools designed in Python for the extraction of digital artifacts from memory images.  To quickly configure Volatility for use with BackTrack follow these steps:

1.  Download volatility from https://www.volatilesystems.com/volatility/2.0/volatility-2.0.tar.gz .

2. Extract the contents of file
tar –zxvf volatility-2.0.tar.gz

3. Copy the volatility directory:
cp –ar volatility-2.0 /usr/local/src

4. Create a symbolic link:
ln –s /usr/local/src/volatility-2.0/vol.py /usr/local/bin/vol.py

5. Change permissions to execute for vol.py
chmod 755 /usr/local/src/volatility-2.0/vol.py

Refer to the command reference for a nice guide of the capabilities of Volatility, http://code.google.com/p/volatility/wiki/CommandReference .  The first step in performing analysis with volatility is to determine the OS profile to use.  This can be accomplished by executing the command:

Additional commands can now leverage the profile parameter to better query the memory image structure, such as this for a process listing:

The output from the volatility commands can be redirected to text files for easier analysis.  The output from volatility commands coupled with good investigative knowledge can help to quickly reveal malicious processes.

Mandiant’s Redline is another free Memory Analysis tools (http://www.mandiant.com/products/free_software/redline).  Designed to compliment memory acquisition from Memoryze, Mandiant’s Redline is also capable of processing raw memory images from third party memory acquisition tools.  The application requires .NET 4.0 to be installed.  Once installed it is designed to guide the User through the memory analysis process via GUI based navigation.  Redline leverages Mandiant MRI rating of processes.  In this example it quickly identified a suspicious iexplorer.exe process that had been compromised with Poison Ivy by flagging it with the color red.

Similar to volatility it also quickly and easily displays other memory artifacts such as network connections.

As with any great tool, it is recommended for the Examiner, Responder, or Investigator to obtain vendor training in order to become truly proficient with the application.

Last Updated on Thursday, 20 October 2011 12:12