Thursday, February 05, 2015

toolsmith: Sysmon 2.0 & EventViz



Prerequisites
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!

Overview
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 124.207.29.185 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.

Acknowledgements 
Thomas Garnier, Sysmon 2.0 developer


Saturday, January 17, 2015

2014 Toolsmith Tool of the Year: SimpleRisk

Congratulations to Josh Sokol of SimpleRisk, LLC.
SimpleRisk is the 2014 Toolsmith Tool of the Year.
We mustered 933 total votes this year of which 438 went to SimpleRisk.
In Josh's own words, "I began writing SimpleRisk because I needed a tool to aide in my risk management activities and spreadsheets just weren't cutting it. But once I had a POC created, I knew that it was too good to keep to myself. I've always wanted to give back to the security community that has given so much to me. That's why I decided to release SimpleRisk under a Mozilla Public License 2.0. I hope it's as useful to you as it is for me."
Voters agree, SimpleRisk is definitely useful. :-)
Here's how the votes broke down.



Congratulations to all toolsmith entries and participants this year, and in particular to runners up Artillery from Dave Kennedy and Binary Defense Systems and ThreadFix from the Denim Group.
2015 promises us another great year of tools for information security practitioners and as always, if there are tools you'd like me to cover in toolsmith, please feel free to submit your favorites for consideration.

Friday, January 02, 2015

toolsmith: Kansa vs Operation Cleaver – PowerShell IR tactics



Prerequisites
Windows operating system with Windows Management Framework (includes PowerShell) 4.0. WMF 2.0 and 3.0 work but 4.0 is recommended.

Introduction
First of all, Happy New Year! I’m looking forward to a great 2015 and really appreciated your readership and support during the 2014 schedule.
I am both proud and humbled to announce that this is the ISSA Journal’s 100th toolsmith, and 100 consecutive columns at that. It’s really hard to think back to October 2006 and imagine what toolsmith would become; it’s helped shape my career, my personal philosophy, and I believe it has contributed to the improvement of information security practices for numerous individuals and organizations. Nothing makes me happier than hearing from readers with success stories and wins using the numerous and invaluable tools we’ve discussed on these pages. To that end, I’m pleased to cover Kansa for this 100th toolsmith. In his own words, Dave Hull’s Kansa is a modular framework for doing incident response (IR) data collection, analysis and remediation written in PowerShell that takes advantage of Windows Remote Management in order to scale up to thousands of systems. It evolved from a few PowerShell scripts that Dave had written for IR work. Through trial and error and some advice from Lee Holmes (@Lee_Holmes), Dave was able to convert those old scripts into a tool that relies on network logons using PowerShell’s default non-delegated Kerberos authentication. This ensures that the incident responder’s credentials aren’t as exposed to harvesting by common adversary tooling such as Mimikatz. This assumes one-hop scenarios (work station to server). In two-hop scenarios (workstation to server to server) the risk remains, as dictated by the necessity for CredSSP, where PowerShell performs a “Network Clear-text Logon”. Understand the risks and pitfalls and stick to one-hop scenarios easily supported by Kansa with its Target parameter, where you can run against numerous systems from a single list.
Per Dave, “Kansa is frequently used across enterprises to investigate thousands of systems relatively quickly. It can do lots of great things on its own, but also has the ability to push third-party binaries to remote hosts so more sophisticated tooling can be brought to bear – consider the Get-RekallPslist.ps1 module, that installs the WinPMem kernel mode driver on remote hosts and uses it to collect the list of running processes from a live system similar to the way Volatility does against a collected memory image, completely bypassing the Windows API. Because it’s written in PowerShell, extending existing modules or creating new ones is relatively easy and Kansa can even be used to clean up systems for tactical containment and remediation.
Dave’s written his own excellent Kansa overview and usage guide for PowerShell Magazine, which is a true “must read” for you, do nothing else before doing so. We’ll take a more tactical, scenario-based approach to our use of Kansa here so as to provide a different perspective. To that end, Stuart McClure’s Cylance group recently published their Operation Cleaver (#OPCLEAVER) report, also a must-read, an in-depth study of an Iranian hacker collective’s tools, tactics, and procedures (TTPs). A number of indicators of compromise (IOCs) are included in the report, amongst which are included MD5 hashes for specific malware types including TinyZBot and Lagulon. As described in the report, there are numerous references to “cleaver” inside the namespaces of the collective’s custom code, including TinyZBot, thus the name Operation Cleaver. For the best reference material specific to TinyZBot in the report, see the Persistence section starting on page 47. We’ll focus on using Kansa to find one of the Lagulon keylogging samples.   

Tuning Kansa

Kansa is really meant for use across many systems, this one target scenario is a bit trite on my part. You’ll need to imagine the horsepower you see working for this one compromised host across hundreds or thousands of similarly buggered hosts.
On your target servers, script execution needs to be enabled for Kansa use. If you’re not familiar with Powershell, that’s as easy as:
1)      Right-click the Windows PowerShell shortcut.
2)      Select Run as administrator.
3)      Choose Yes when the UAC window appears.
4)      Use the Set-ExecutionPolicy cmdlet; enter and execute Set-ExecutionPolicy unrestricted.
5)      You’ll also want to run ls -r *.ps1 | Unblock-File to unblock the scripts.

You may also need to execute winrm quickconfig and/or Register-PSSessionConfiguration -Name Microsoft.PowerShell to overcome remote connection errors you may see written to the Kansa output directory if it can’t connect to the target host. You may also need to work around Windows firewall issues for PowerShell remoting if any of your network connection profiles are set to Public. You can run Get-NetConnectionProfile on Windows 8 or Server 2012 and later to see how your connections are configured then run the likes of Set-NetConnectionProfile -InterfaceIndex 25 -NetworkCategory Private to reset the culprit to Private. You’ll modify –InterfaceIndex to the correct number matching your Public connection(s).
You should have read Dave’s PowerShell Magazine article already but I will remind you that any binaries you may wish to utilize on target hosts, such as autoruns.exe or handle.exe from the Sysinternals collection, should be stored in the .\Modules\bin\ directory. Beware possible EULA issues with the Sysinternals tools. Even though the Kansa Get-Handle script passes handle.exe /accepteula –a, handle.exe hung on me in my test scenario.
A successful pre-infection Kansa run on my intended victim system, as spawned by .\kansa.ps1 -Target localhost -Pushbin –Verbose, is seen in Figure 1.

Figure 1 – Kansa test run
Kansa vs. Cleaver

I acquired a few samples as described in Cylance’s Operaration Cleaver report from @VXShare, as always, my favorite repository. After investigating the run-time behaviors of a few of them, I found a specific sample, a Lagulon variant, that was a good representative for Kansa use as it hit marks for a few of the IOCs mentioned in the report. The sample, MD5: 53230e7d5739091a6eb51298a50eb616, is discussed generally on page 58 in the report as part of the wndTest analysis, observed attempting to impersonate Adobe Report Service.
After executing the sample on my victim system (I had to pwn a real Windows image as the malware didn’t run in a VM environment) I re-ran Kansa and collected results from the Output directory. I then went on a subsequent search for all things Adobe related and uncovered more than a few IOCs. As all output files are TSV by default, they play nicely in Excel. The first hit came from the Get-Autorunsc module, the results from which I filtered by infection date to reduce the noise. The output as seen in Figure 2 shows that adbreport.exe has been configured to run at logon via C:\Users\malman\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.

Figure 2 – Kansa uncovers an autorun entry
The next hit came from the Get-Handle module, the results from which I sorted alphabetically by Process Name to key on adbReport.exe. As you can see in Figure 3, adbReport.exe, as identified by Process ID 3396, has open handles on a number of files and registry entries.

Figure 3 – Kansa pivots on adbreport.exe handles
Note the \Device\KsecDD entry in Figure 3 as well, indicating direct device communication via the KsecDD driver.
More related IOCs were noted via the Get-ProcsWMI module which, per its own synopsis, “acquires various details about running processes, including command-line arguments, process start time, parent process ID and MD5 hash of the process image as found on disk”, the results of which you can see in Figure 4.

Figure 4 – Kansa closes the circle with the adbreport.exe MD5 hash
You’ve likely come to the conclusion that the hash referenced in Figure 4 is in fact that associated with the malicious binary acquired from VirusShare, thus closing the circle of discovery and incident enumeration with Kansa.
That said, again, single host scenarios with Kansa are cute, but it’s made to shine at scale. Viewing individual TSV files in Excel is definitely not a scale solution. How about viewing and parsing results via Log Parser? Better right? Integrate with SQL-based storage and you’re really off to the races. The Kansa Analysis folder includes a number of analysis-centric scripts to work with the results. They’re most often frequency analysis-oriented to work across a body of results from a plethora of hosts. Sadly my examples will only be from my one wee victim system, but you get the point.

 As an example in Analysis\Process you can use Get-HandleProcessOwnerStack.ps1 to pull frequency from all collected Get-Handle data based on Process Name and Owner. While I only collected one result set, .\Get-HandleProcessOwnerStack.ps1 | findstr "adbReport" tell me that adbReport.exe has 48 handles open as seen in Figure 5.

Figure 5 – Kansa frequency analysis across results
Had there been one or 1000 Get-Handle results in the working directory where Get-HandleProcessOwnerStack.ps1 was run from, it would count and sort ALL handles by process and owner.
If you need a frequency count of all instances of adbReport.exe via an MD5 hash match across all results from all hosts, you need only run Get-ProcsWMICLIMD5Stack.ps1. My favorite is sorting the same data set by creation date. This helps while conducting timeline analysis and will tell you when a process was created across all targets, the like of which is seen in Figure 6.

Figure 6 – Kansa determines creation dates across results
Response capabilities, analysis of the results, and even the premise of remediation via Kansa for the adventurous and innovative amongst you, all built into to one tidy PowerShell framework. For modern Windows environments, consider Kansa a must have in the IR toolkit.

In Conclusion

Come what may, in light of attacks as discussed in the Operation Cleaver report, tool frameworks such as Kansa help you leverage the real Windows workhorse that is PowerShell in order to better respond and analyze. Keep an eye on the Kansa Github site for updates and news and follow @davehull on Twitter. Dave and I also both follow @Lee_Holmes who we both consider to be the Don of the PowerShell family.
Remember to vote for your favorite tool of 2014, through January 15, 2015. I’ll announce a winner soon thereafter. Please vote and tell your friends and coworkers to do the same.
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.

Acknowledgements

Dave Hull (@davehull), Kansa developer and project lead

Tuesday, December 02, 2014

toolsmith: Artillery



Prerequisites
Linux or Windows system with a Python interpreter

Introduction
I was reminded of Dave Kennedy’s Artillery while attending and presenting at DerbyCon 4.0 in September given that Dave is a DerbyCon founder. Artillery has recently benefitted from a major update and formal development support as part of Dave’s Binary Defense Systems (BDS) company. The BDS blog announced version 1.3 on November 11, which further prompted our discussion here. Artillery first surfaced for me as part of the ADHD project I covered during my C3CM discussion in October 2013’s toolsmith. While Dave’s investments in the security community have grown, Artillery was initially maintained by Dave’s TrustedSec organization then transitioned to BDS, given that group’s "defend, protect, secure" approach to managed security solutions. Artillery is an open source project created to provide early warning indicators for various attacks. Artillery was included in ADHD, the Active Defense Harbinger Distribution, because it spawns multiple ports on a system, a honeypot-like activity that creates “exposures” for attackers to go after. Dave described the fact that it also made blue teaming a bit easier for folks. Additional Artillery features include active file system change monitoring, detection of brute force attacks, and generation of other indicators of compromise. Artillery protects both Linux and Windows systems against attacks and can integrate with threat intelligence feeds allowing correlation and notification when an attacker IP address has previously been identified. Artillery supports multiple configurations, different versions of Linux, and can be deployed across multiple systems with centralized event collection. With a ton of support, and additions coming in from all over the world to make Artillery better, Dave mentioned that plans for Artillery include much better support for Windows, and expansion to allow a server/client model, moving away from purely standalone implementations. BSD’s plan is to continue significant development for Artillery while ensuring it maintains its open source origins allowing continued contribution back to the community Dave so readily embraces.

Laying In Artillery

Artillery installation is well documented on the Binary Defense Systems site and is remarkably straightforward. Note that I only installed and tested Artillery on a Linux system.
On the Linux system you wish to install Artillery, simply execute git clone https://github.com/trustedsec/artillery, change directory to the artillery directory just created, run sudo ./setup.py, then edit to the config file to suit your preferences. I’ll walk you through my configuration as a reference.
1)      I created a directory called holisticinfosec, and added “/holisticinfosec/” to MONITOR_FOLDERS
2)      I enabled HONEYPOT_BAN=ON, you’ll want to consider your implementation before you do this or you may inadvertently block legitimate traffic. You could also use WHITELIST_IP to prevent this issue and allow specific hosts but, as good as they are, whitelists can quickly become arduous to maintain. Bans and IPS-like blocks suffer from ye olde false positive issues when left unchecked.
3)      I used Yahoo for my SMTP settings (USERNAME, PASSWORD, ADDRESS) and set ALERT_USER_EMAIL to my holistincinfosec.org address for alert receipt. Caution here as well as you can quickly SPAM yourself or your Security Operations Center (SOC) monitored mail, and even cause an inbox DoS if your Artillery server(s) is busy. You can control frequency with EMAIL_TIMER and EMAIL_FREQUENCY, I suggest default settings initially (email alerts off) until you fine tune and optimize your Artillery implementation.
4)      Brute force attempts monitoring is cool and worthwhile, I enabled both SSH and FTP via SSH_BRUTE_MONITOR and FTP_BRUTE_MONITOR. Experiment with “attempts before you ban” as, again, you may not ban initially.
5)      The THREAT_INTELLIGENCE_FEED and THREAT_FEED allow you to consume the BDS Artillery Threat Intelligence Feed (ATIF). It’s represented as banlist.txt. You can pull from the BDS site or establish your own ATIF server for all you Artillery nodes to pull from. As with any blacklist, again, ensure that you want to block them all as there are more than 86,000 entries in this list. You can also add other lists if you wish as well.
6)      One of the most important settings are for your syslog preferences, you can log locally or write to a remote collector. This speaks to my defender’s sensibilities and we’ll discuss this further later as such.

The South Base Camp blog (@johnjakem) also has a nice writeup on Artillery nuances; it’s a quick read and worth your time.

Indirect Artillery Fire

I conducted basic tests of Artillery functionality with email alerts and banning enabled.
For the folder monitoring feature I wrote a file called test to the /holisticinfosec directory including the sentence “Monkey with me” and restarted Artillery. When I monkeyed with test by adding snarky commentary, I was alerted via email and a log entry in the local syslog file. Figure 1 is the email alert indicating the change to the test file.

Figure 1 – Artillery alert for change to test file
To blast the honeypot functionality, a nice Nmap scan sufficed with nmap -p 1-65535 -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 192.168.220.130.
The result was an alert flood stating that [!] Artillery has detected an attack from the IP Address: 192.168.220.131 with example content as seen in Figure 2.

Figure 2 – Blocked and banned! Artillery stops attack traffic cold
I used Bruter to try and pound the FTP and SSH services but because the Artillery configuration was set to only four attempts before banning, my dictionary attacks were almost immediately kicked to the curb. Darn you, Artillery! For this experiment I enabled SYSLOG_TYPE=FILE in my Artillery configuration, which writes event to /var/artillery/logs/alerts.log instead of syslog.
Remember, if you find yourself unable to connect to your Artillery server on a specific port or aren’t writing test events, check your configuration file as you may have banned yourself. I did so more than once. Instantly solve this problem as follows: sudo ./remove_ban.py 192.168.220.1 where the IP address is that which you want to free from the bonds of iptables purgatory.

Direct Artillery Fire

Artillery represents a golden opportunity to harken back to my C3CM guidance, particularly Part 2, wherein I discussed use of the ELK stack, or Elasticsearch, Logstash, and Kibana. You can quickly set up the ELK stack up using numerous guides found via search engine and customize it for Artillery analysis.
Rather than repeat what I’ve already documented, I took a slightly different tack and utilized my trusty and beloved Security Onion VM. Doug Burks' (@dougburks) Security Onion includes ELSA (enterprise log search and analysis) which is a “centralized syslog framework built on Syslog-NG, MySQL, and Sphinx full-text search.” I could and should do a toolsmith on ELSA alone, but it’s so well documented by project developers and Doug, you’d do well just to read their content. To make use of ELSA I needed only point Artillery syslog to my Security Onion server by changing the /var/artillery/config file as follows:
1)      Changed SYSLOG_TYPE=LOCAL to SYSLOG_TYPE=REMOTE
2)      Set the IP address for my Security Onion server with SYSLOG_REMOTE_HOST="192.168.220.131"
3)      Restarted Artillery from /var/artillery with sudo ./restart_server.py
“That’s it?” you ask. Indeed. I logged into ELSA on my SO server after hammering the Artillery node with varied malfeasance, queried with host=192.168.220.130, you can see the results in Figure 3.

Figure 3 –Artillery events written to a remote Security Onion ELSA instance
ELSA provides you with a number of query options and filters so even if you have multiple Artillery servers you can zoom in on specific instances, dates, or attack types. A query such as host=192.168.220.130 groupby:program led me to program=”unknown” which, in turn, alerted me that I ended up being banned from Yahoo for spamming my account with alerts as seen in Figure 4.

Figure 4 – Artillery alerts me that I am a spammer
It’s always good to check your logs from a variety of perspectives. :-)
I intend to write some additional scripts for Artillery analysis and parsing, and devise additional means for incorporating threat intelligence to and from my Artillery instance. Let me know via the blog comment or Twitter how you’ve done the same.

In Conclusion

Artillery, on many levels, is the epitome of simplicity, which is part of why I love it. If you possess even the slightest modicum of Python understanding, the Artillery source files should make complete sense to you. Properly tuned, I can’t really think of a reason not to run Artillery on Linux servers for sure, and maybe Windows boxes where you have Python installed. Just remember to practice safe banning, you don’t want to drop production traffic. I’m really glad Dave’s Binary Defense Systems interest has taken over care and feeding for Artillery and can’t wait to see what’s next for this fine little defender’s delight.

It’s that time of year again! Be ready to vote for your favorite tool of 2014, I’ll soon post the survey to my website or blog and Tweet it out by mid-December. We’ll conclude voting by January 15, 2015 and announce a winner soon thereafter. Please vote and tell your friends and coworkers to do the same.
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.

Acknowledgements

Dave Kennedy (@HackingDave), TrustedSec, Binary Defense Systems, and DerbyCon