Tuesday, March 03, 2015

toolsmith: Faraday IPE - When Tinfoil Won’t Work for Pentesting

Typically *nix, tested on Debian, Ubuntu, Kali, etc.
Kali 1.1.0 recommended, virtual machine or physical

I love me some tinfoil-hat-wearing conspiracy theorists, nothing better than sparking up a lively conversation with a “Hey man, what was that helicopter doing over your house?” and you’re off to the races. Me, I just operate on the premise that everyone is out to get me and I’m good to go. For the more scientific amongst you, there’s always a Faraday option. What? You don’t have a Faraday Cage in your house? You’re going to need more tinfoil. :-)

Figure 1 – Tinfoil coupon

In all seriousness, Faraday, in the toolsmith context, is an Integrated Penetration-Test Environment (IPE); think of it as an IDE for penetration testing designed for distribution, indexation, and analysis of the generated data during the process of a security audit (pentest) conducted with multiple users. It was some years ago when we discussed them in toolsmith, but Raphael Mudge’s Armitage is a similar concept for Metasploit, while Dradis provides information sharing for pentest teams
Faraday now includes plugin support for over 40 tools, including some toolsmith topics and favorites such as Openvas, BeEF Arachni, Skipfish, and ZAP.
The Faraday project offers a robust wiki and a number of demo videos you should watch as well.
I pinged Federico Kirschbaum, Infobyte’s CTO and project lead for Faraday.
He stated that, as learned from doing security assessments, they always had the need to know what the results were from the tests performed by other team members. Sharing partial knowledge of target systems proved to be useful not only to avoid overlapping but also to reuse discoveries and build a complete picture. During penetration tests where the scope is quite large, it is common that a vulnerability detected in one part of the network can be exploited somewhere else as well. Faraday’s purpose is to aid security professionals and its development is driven by this desire to truly convert penetration testing into a community experience.
Federico also described their goal to provide an environment where all the data generated during a pentest can be transformed into meaningful, indexed information. Results can then be easily distributed between team members in real time without the need to change workflow or tools, allowing them to benefit from the shared knowledge. Pentesters use a lot of tools on a daily basis, and everybody has a "favorite" toolset, ranging from full blown vulnerability scanners to in-house tools; instead of trying to change the way people like to work the team designed Faraday as a bridge that allows tools to work in a collaborative way. Faraday's plug-in engine currently supports more than 40 well known tools and also provides an easy-to-use API to support custom tools.
Information persisted in Faraday can be queried, filtered, and exported to feed other tools. As an example, one could extract all hosts discovered running SSH in order to perform mass brute force attacks or see which commands or tools have been executed.
Federico pointed out that Faraday wasn't built thinking only about pentesters. Project managers can also benefit from a central database containing several assessments at once while being able to easily see the progress of their teams and have the ability to export information to send status reports.
It was surprising to the Infobytes team that many of the companies that use Faraday today are pentest clients rather than the actual pentest consultant. This is further indication of why it is always useful to have a repository of penetration test results whether they be internal or through outside vendors.
Faraday comes in three flavors - Community, Professional and Corporate. All of the features mentioned above are available in our Community version, which is Open Source. I tested Community for this effort as it is free.
Federico, in closing, pointed out that one of the main features in the commercial version is the ability to export reports for MS Word containing all the vulnerabilities, graphs, and progress status. This makes reporting, a pentester’s bane (painful, uncomfortable, unnatural even), into a one-click operation that can be executed by any team member at any time. See the product comparison page for more features and details for versions, based on your budget and needs.

Faraday preparation

The easiest way to run Faraday, in my opinion, is from Kali. This is a good time to mention that Kali 1.1.0 is available as of 9 FEB 2015, if you haven’t yet upgraded, I recommend doing so soon.
At the Kali terminal prompt, execute:
git clone https://github.com/infobyte/faraday.git faraday-dev
cd faraday-dev
The installer will download and install dependencies, but you’ll need to tweak CouchDB to make use of the beautiful HTML5 reporting interface. Use vim or Leafpad to edit /etc/couchdb/local.ini and uncomment (remove semicolon) for port and bind_address on lines 11 and 12. You may want to use the Kali instances IP address, rather than the loopback address to allow remote connections (other users). You can also change the port to your liking. Then restart the CouchDB service with service couchdb restart. You can manipulate SSL and authentication mechanisms in local.ini as well. Now issue ./faraday.py -d. I recommend running with –d as it gives you all the debug content in the logging console. The service will start, the QT GUI will spawn, and if all goes well, you’ll receive an INFO message telling you where to point your browser for the CouchDB reporting interface. Note that there are limitations specific to reporting in the Community version as compared to its commercial peers.

Figure 2 – Initial Faraday GUI QT
Fragging with Faraday

The first thing you should do in the Faraday UI is create a workspace: Workspace | Create. Be sure to save it as CouchDB as opposed to FS. I didn’t enable replication as I worked alone for this assessment.
Shockingly, I named mine toolsmith. Explore the plugins available thereafter with either Tools | Plugin or use the Plugin button, fourth from the right on the toolbar. I started my assessment exercise against a vulnerable virtual machine ( with a quick ping and nmap via the Faraday shell (Figure 3). To ensure the default visualizations for Top Services and Top Host populated in the Faraday Dashboard, I also scanned a couple of my gateways.

Figure 3 – Preliminary Faraday results
As we can see in Figure 3, our target host is appears to be listening on port 80, indicating a web server, and a great time to utilize a web application scanner. Some tools such as the commercial Burpsuite Pro have a Faraday plugin for direct integration, you can still make use free Burpsuite data, as well as results from the likes of free and fabulous OWASP ZAP. To so, conduct a scan and save the results as XML to the applicable workspace directory, ~/.faraday/report/toolsmith in my case. The results become evident when you right-click the target host in the Host Tree as seen in Figure 4.

Figure 4 – Faraday incorporates OWASP ZAP results
We can see as we scroll through findings we’ve discovered a SQL injection vulnerability; no better time to use sqlmap, also supported by Faraday. Via the Faraday shell I ran the following, based on my understanding of the target apps discovered with ZAP.
To enumerate the databases:
sqlmap -u '' –dbs
To enumerate the tables present in the Joomla database:
sqlmap -u '' -D joomla –tables
To dump the users from the Joomla database:
sqlmap -u '' --dump  -D joomla -T j25_users
Unfortunately, late in the game as this was being written, we discovered a change in sqlmap behavior that cause some misses for the Faraday sqlmap plugin, preventing sqlmap data from being populated in the CouchDB and thus the Faraday host tree. Federico immediately noted the issue was issuing a patch as I was writing; by the time you read this you’ll likely be working with an updated version. I love sqlmap so much though and wanted you to see the Faraday integration. Figure 5 gives you a general sense of the Faraday GUI accommodating all this sqlmap mayhem.

Figure 5 – Faraday shell and sqlmap
That being said, here’s where all the real Faraday superpowers kick in. You’ve enumerated, assessed, and even exploited, now to see some truly beautified HTML5 results. Per Figure 6, the Faraday Dashboard is literally one of the most attractive I’ve ever seen and includes different workspace views, hover-over functionality and host drilldown.

Figure 6 – Faraday Dashboard
There’s also the status report view which really should speak for itself but allows you really flexible filtering as seen in Figure7.

Figure 7 – Faraday Status
Those pentesters and pentest PMs who are looking for a data management solution should now be fully inspired to check out Faraday in its various versions and support levels. It’s an exciting tool for a critical cause.

In Conclusion

Faraday is a project that benefits from your feedback, feature suggestions, bug reports, and general support. They’re an engaged team with a uniquely specialized approach to problem solving for the red team cause, and I look forward to future releases and updates. I know more than one penetration testing team to whom I will strongly suggest Faraday consideration.
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.


Federico Kirschbaum (@fede_k), Faraday (@faradaysec) project lead, CTO Infobyte LLC (@infobytesec

Thursday, February 05, 2015

toolsmith: Sysmon 2.0 & EventViz

Windows operating system
R 3.1.2 and RStudio for EventViz

Congratulations and well done to Josh Sokol for winning 2014 Toolsmith Tool of the Year with his very popular SimpleRisk!

Sysmon 2.0 was welcomed to the world on 19 JAN 2015, warranting immediate attention as part of The State of Cybersecurity focus for February’s ISSA Journal. If you want to better understand the state of cybersecurity on your Windows systems, consider System Monitor (Sysmon) a requirement. Sysmon is “a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time.” The real upside is that you can ship related events using Windows Event Collection or the agent provided as part of your preferred SIEM implementation. You can also conduct simple exports of EVTX files during forensic or malware runtime analysis for parsing and queries. I built EventViz in R, as a Shiny app, to simplify this process and read CSV exports from Windows Event Viewer. It’s a work in progress to be certain, but one you can make immediate use of in order to pivot on key data in Sysmon logs.
I pinged Thomas Garnier, who along with Microsoft Azure CTO Mark Russinovich, created Sysmon. Thomas pointed out that the need to understand our networks, how they are used or abused, has never been higher. He also reminded us that, unfortunately, there is a gap between the information needed by network defenders and the information provided by operating systems across versions. To that end, “Sysinternals Sysmon was created to provide rich information across OS versions while running in the background staying resident across reboots. It provides detailed information on process creation, image loading, driver loading, network connections and more. It allows you to easily filter generated events and update its configuration while it is still running. All the activities are captured in the Windows event log to integrate with existing Windows Event Collection or SIEM solutions.
Of the eight Event IDs generated by Sysmon, you can consider six immediately useful for enhancing situational awareness and strengthened defenses. You’ll want to tune and optimize how you configure Sysmon so you don’t flood your logging systems with data you determine later isn’t as helpful as you hoped. The resulting events can be quite noisy given the plethora of data made available per the following quick event overview:
·         Event ID 1: Process creation
o   The process creation event provides extended information about a newly created process.
·         Event ID 2: A process changed a file creation time
o   The change file creation time event is registered when a file creation time is explicitly modified by a process. Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system, but many processes legitimately change the creation time of a file.
·         Event ID 3: Network connection
o   The network connection event logs TCP/UDP connections on the machine. It is disabled by default.
·         Event ID 4: Sysmon service state changed
o   The service state change event reports the state of the Sysmon service (started or stopped).
·         Event ID 5: Process terminated
o   The process terminate event reports when a process terminates.
·         Event ID 6: Driver loaded
o   The driver loaded events provides information about a driver being loaded on the system.
·         Event ID 7: Image loaded
o   The image loaded event logs when a module is loaded in a specific process. This event is disabled by default and needs to be configured with the –l option.
I love enabling the monitoring of images loaded during malware and forensic analysis but as the Sysmon content says, “this event should be configured carefully, as monitoring all image load events will generate a large number of events.” I’ll show you these Event IDs come to play during review of a system compromised by a Trojan:Win32/Beaugrit.gen!AAA sample using EventViz to analyze Sysmon logs. Beaugrit.gen is a rootkit that makes outbound connections to request data and download files while also interacting with Internet Explorer.

Sysmon installation

I had the best luck downloading Sysmon and unpacking it into a temp directory.  From an administrator command prompt I changed directory to the temp directory and first ran Sysmon.exe -accepteula –i. This accepts the EULA, installs Sysmon as a service, and drops Sysmon.exe in C:\Windows, making it available at any command prompt path. I exited the first administrator command prompt, spawned another one, and ran sysmon –m.  This step installs the event manifest, which helps you avoid verbose and erroneous log messages such as “The description for Event ID 5 from source Microsoft-Windows-Sysmon cannot be found.” I followed that with sysmon -c -n -l -h md5,sha1,sha256. The -c flag updates the existing configuration, -n enables logging of network connections (Event ID 3), -l enables logging the loading (can be noisy) of modules (Event ID 7), and -h defines what hashes you wish to collect as part of event messaging. You may be happier with just one hash type configured to again reduce volume. Once installed and properly configured you’ll find Sysmon logs in the Event Viewer under Applications and Services Logs | Microsoft | Windows | Sysmon | Operational as seen in Figure 1.

Figure 1 – Sysmon Operational log entries in Event Viewer
The physical system path is %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx. You can optionally define configuration preferences with a config.xml file, refer to Sysmon documentation for specifics. To create Sysmon CSV files that can be analyzed with EventViz, right click the Operational log as seen in Figure 1 and Save All Event As sysmon.csv. The will result in a CSV version of all Sysmon log entries written to the system your analyzing. Remember that all Windows event logs are set to 65536KB and to overwrite as needed by default. You’ll likely want to factor for updating this to ensure an appropriately sized log sample in order to conduct proper investigations, particularly if you’re not shipping the logs off system.

Analysis with EventViz

Collecting logs is one thing but making quick use of them is the real trick. There are so many ways and means with which to review and respond to particular events as defined by detection and rules logic. Piping Sysmon logs to your collection mechanism is highly recommended. Windows Event Collection/Windows Event Forwarding are incredibly useful, the results of which can be consumed by numerous commercial products. Additionally there are free and open source frameworks that you can leverage. Enterprise Log Search and Archive (ELSA) immediately comes to mind as does the ELK stack (Elasticsearch, Logstash, Kibana). See Josh Lewis’ Advanced ThreatDetection with Sysmon, WEF and Elasticsearch (AKA Panther Detect) as a great reference and pointer.
There are also excellent uses for Sysmon that don’t require enterprise collection methods. You may have single instances of dedicated or virtual hosts that are utilized for runtime analysis of malware and/or other malfeasance. I utilized just such a Windows 7 SP1 virtual machine to test Sysmon capabilities with the above mentioned Beaugrit.gen sample. You can of course utilize the built-in Windows Event Viewer but ease of use and quick pivots and queries are not its strong suit. I’ve started on EventViz to address this issue and plan to keep developing against it. For folks with an appreciation for R, this is a nice exemplar for its use. If you need a good primer on using R for information security-related purposes, I’ve got you covered there. In January, ADMIN Magazine published my article SecurityData Analytics and Visualization with R, which is a convenient and directly useful way for you to get your feet wet with R.
Use of EventViz currently assumes you’ve got a version of R installed, as well as RStudio. At an RStudio console prompt be sure to run install.packages("shiny") as EventViz is a Shiny app that requires the Shiny package. Create a directory where you’d plan to store R scripts, and create an apps directory therein, and an EventViz directory in the apps directory. Mine is C:\coding\R\apps\EventViz as an example. Copy server.R and ui.R, as well as the example CSV file we’re discussing here, to the EventViz directory; you can download them from my Github EventViz repository.  Open server.R and ui.R and click Run App as seen in Figure 2.

Figure 2 - Run the EventViz Shiny app
Give it a few minutes it may take a bit to load as it is a crowded log set given the verbosity of Event ID 7 (Image loaded), again, enable it with caution. I’m working on EventViz performance with larger files but you’ll see how Event ID 7 helps us here though. Once it’s loaded you’ll have Figure 3 in a Shiny window. You also have the option to open it in a browser.

Figure 3 - EventViz UI
Each of the drop-down menus represents a column heading in the sysmon.csv albeit with a little manipulation via R where I renamed them and added a header for the messages column.
I’ll work with a bit of insider knowledge given my familiarity with the malware sample but as long as you have a potential indicator of compromise (IOC) such as an IP address or malicious executable name you can get started. I knew that the sample phones home to 920zl.com. When I conducted a lookup on this domain (malicious) it returned an IP address of in Beijing. You may now imagine my shocked face. Let’s start our results analysis and visualization with that IP address. I copied it to the EventViz search field and it quickly filter two results from 9270 entries as seen in Figure 4. This filter is much faster than the initial app load as the whole data set is now immediately available in memory. This is both a benefit and a curse with R. It’s performant once loaded but a memory hog thereafter and it’s not well known for cleaning up after itself.

Figure 4 - EventViz IP address search results
Sysmon Event ID 3 which logs detected network connections trapped C:\tmp\server.exe making a connection to our suspect IP address. Nice, now we have a new pivot options. You could use the Event ID drop-down to filter for all Event ID 3’s for all network connections. I chose to filter Sysmon Event ID 7 and searched server.exe. The results directly matched Virus Total behavioral information for this sample, specifically the runtime DLLs. Sysmon’s Event ID 7 ImageLoad logic clearly shows server.exe acting as indicated by VirusTotal per Figure 5. 

Figure 5 – EventID 7 ImageLoad matches VirusTotal
Drill in via Event ID 1 ProcessCreate and you’ll find that server.exe was spawned by explorer.exe. The victim (me) clicked it (derp). There are endless filter and pivot options given the data provided by Sysmon and quick filter capabilities in EventViz. Eventually (pun intended), EventViz will allow you to also analyze other Windows event log types such as the Security log.

In Conclusion

Sysmon clearly goes above and beyond default Window event logging by offering insightful and detailed event data. Coupled with collection and SIEM deployments, Sysmon can be an incredible weapon as part of your detection logic. Marry your queries up with specific threat indicators and you may be both pleased and horrified (in a good way) with the results. Watch the TechNet blog and the Sysinternals site for further updates to Sysmon. For quick reviews during runtime analysis or dirty forensics a viewer such as EventViz might be useful assuming you export to your Sysmon EVTX file to CSV. Keep an eye on the Github site for improvements and updates. I plan to add a file selector so you can choose from a directory of CSV files. For other feature requests you can submit via Github.
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.

Thomas Garnier, Sysmon 2.0 developer