If your browser doesn't support IFRAMEs, you can vote directly here.
Create your own user feedback survey
Russ McRee's HolisticInfoSec™ includes articles and research, as well as feedback and an occasional rant. HolisticInfoSec™ promotes standards, simplicity, tooling and efficiency in achieving holistic information security.
Thursday, December 17, 2015
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.
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-*
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.
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
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.
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.
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.
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.
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?
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.
 |
| Yep, that kind of crazy :-) |
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 |
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 |
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 |
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 |
 |
| Figure 5: Filtered beacons |
 |
| Figure 6: Beacons |
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? |
 |
| Figure 8: Scanning |
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:
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.
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.
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.
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.
Similar results are derived from the File Summary tab including total and standby memory utilized.
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.
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.
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 |
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 |
 |
| Figure 5 |
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
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.
- Opened CapLoader
- Selected File then Carve Packets from File
- Selected compromised.raw from Open dialog
- 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,
- Left all Carving Options enabled and clicked Start as seen in Figure 1.
 |
| Figure 1: CapLoader memory image network carving options |
 |
| Figure 2: Selected flows |
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 |
Cheers…until next time.
Wednesday, September 02, 2015
toolsmith #108: Visualizing Network Data with Network Data
Prerequisites
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
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.
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
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 |
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 221In 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)
Saturday, August 01, 2015
toolsmith: There Is No Privacy - Hook Analyser vs. Hacking Team
Prerequisites
Hook Analyser
Windows OS
Introduction
As we explore privacy in this
month’s ISSA Journal, timing couldn’t be better. Since last we convened, the
Hacking Team breach has informed us all that privacy literally is for sale.
Hacking Team’s primary product is Remote Control System (RCS), “a solution
designed to evade encryption by means of an agent directly installed on the
device to monitor. Evidence collection on monitored devices is stealth and
transmission of collected data from the device to the RCS server is encrypted
and untraceable.” While Hacking Team initially claimed their products are not
sold to “governments or to countries blacklisted by the U.S., E.U., U.N., NATO
or ASEAN” the data dump made public as result of their breach indicated
otherwise. In fact, their customers include major players in finance, energy,
and telecommunications. Among all the 0-days and exploits in the Hacking Team
dump, it was even discovered that they offered UEFI BIOS rootkit to ensure “that
it silently reinstalls its surveillance tool even if the hard drive is wiped
clean or replaced.” With industry giants willing to seemingly utilize the likes
of RCS, we’re left to wonder where the line will be drawn. I long ago assumed
there is no line and therefore assume there is no privacy. May I recommend you
join me in this gloomy outlook?
Perhaps a little proof may
help you come to terms with this simple rule: don’t store or transmit via
digital media that what which you don’t want read by anyone and everyone.
To get to the heart of the
matter, we’ll assess some Hacking Team “products”, pulled from the public dump,
with Beenu Arora’s Hook Analyser. Beenu
just celebrated the release of Hook Analyser 3.2 as of 19 JUL. You may recall
that I mentioned Hook Analyser via the Internet Storm Center Diary for the
Keeping The RATs Out series, we’ll
put it through its paces here. Per Beenu, Hook Analyser is a freeware project
which brings malware (static & dynamic) analysis and cyber threat
intelligence capabilities together. It can perform analysis on suspicious or
malware files and can analyze software for crash-points or security bugs. The
malware analysis module can perform the following actions:
·
Spawn and Hook to Application
·
Hook to a specific running process
·
Static Malware Analysis
o Scans
PE/Windows executables to identify potential malware traces
·
Application crash analysis
o Allows
you to analyze memory content when an application crashes
·
Exe extractor
o Extracts
executables from running process/s
The Cyber Threat Intelligence
module provides open source intelligence where you can search for IP addresses,
hashes or keywords. It will collect relevant information from various sources,
analyze the information to eliminate false-positives, correlate the various
datasets, and visualize the results.
What better to run Hacking
Team binaries through. Let’s begin.
Hacking Team Samples
I pulled four random binaries
out of the Hacking Team dump for analysis, sticking exclusively to EXEs. There
are numerous weaponized document and media files, but I was most interested in
getting to the heart of the matter with Hook Analyser. Details for the four
samples follow:
1.
agent 222.exe
a.
MD5: fea2b67d59b0af196273fb204fd039a2
b.
VT: 36/55
2.
agent 1154.exe
a.
MD5: c1c99e0014c6d067a6b1092f2860df4a
b.
VT: 31/55
3.
Microsoft Word 2010 2.exe
a.
MD5: 1ea8826eeabfce348864f147e0a5648d
b.
VT: 0/55
4.
my_photo_holiday_my_ass_7786868767878 19.exe
a.
MD5: e36ff18f794ff51c15c08bac37d4c431
b.
VT: 48/55
I found it interesting that one
of the four (Microsoft Word 2010 2.exe) exhibited no antimalware detection via
Virus Total as this was written, so I started there.
Hook Analyser
Hook Analyser is stand-alone
and runs in console mode on contemporary Windows systems. For this effort I ran
it on Windows 7 x32 & x64 virtual machines. The initial UI as seen in
Figure 1 is basic and straightforward.
 |
| Figure 1 – Hook Analyser UI |
For Microsoft
Word 2010 2.exe I opted to use Spawn
and Hook to Application and provided the full path to the sample. Hook
Analyser exited quickly but spawned C:\tools\Hook
Analyser 3.2\QR7C8A.exe, with which I repeated the process. The result
was a robust output log to a text file named by date and time of the analysis,
and an XML report, named identically, of the high-level behaviors of the
sample. A few key items jumped right out
in the reports. First, the sample is debug aware. Second, it spawns a new
process. Third, Hook Analyser found one trace of a potential PDB/Project at offset
00007F0. When I ran strings against the sample I found c:\users\guido\documents\visual studio
2012\Projects\fake_office\Release\fake_office.pdb, confirming the
project and even the developer. I’d have to err on the side of threat related in
this scenario, just on project name alone. Further analysis by Microsoft’s
Malware Protection Center revealed that it checks for the presence of a
legitimate instance of winword.exe
on C: or D:, then executes C:\a.exe.
As a results, this sample has been classified “threat related”. Based on naming
conventions followed by Hacking Team, one can reasonably conclude that C:\a.exe is likely an RCS agent. By
the way, Guido, in this case, is probably Guido Landi, a former senior Hacking
Team software developer.
You can see the overall output from both reports in a
combined Figure 2.
 |
Figure 2 – Hook Analyser results
|
I took a different approach with the next sample
analysis, specifically agent 222.exe.
I first executed the sample, then chose Hook
to a specific running process. Hook Analyser then provides a listing of
all active processes. Agent 222.exe
showed itself with process ID 3376. I entered 3376 and Hook Analyser executed a
quick run and spawned GVNTDQ.exe.
I reran Hook Analyser, selected 3 for Perform
Static Malware Analysis, and provided C:\tools\Hook
Analyser 3.2\GVNTDQ.exe. GVNTDQ.exe
is simply a new instance of Agent
222.exe. This time another slew of very interesting artifacts revealed
themselves. The “agent” process runs as TreeSizeFree.exe, an alleged hard disk
space manager from JAM Software, and runs as trusted given that it is signed by
a Certum/Unizeto cert. It also appears to be anti-debugging aware and packed
using an unknown packer. The sample manipulates GDI32.dll, the OS’s graphic
device interface and
WINHTTP.dll (mapped in memory) with a WinHttpGetIEProxyConfigForCurrentUser
call, which provides the Internet Explorer proxy settings for the current
active network connection. Remember that privacy you were so interested in
maintaining?
Let’s say you’re asked to investigate a suspect system,
and you have no prior knowledge or IOCs. You do discover a suspicious process
running and you’d like to dump it. Choose Exe Extractor (from Process), reply
no when it asks if you’d like to dump all processes, then provide the process
ID you’d like extracted. It will write an EXE named for the process ID to your
Hook Analyser working directory.
You can also run batch jobs against a directory of
samples by choosing Batch Malware Analysis, then providing the path to the
sample set.
I’d be remiss if I didn’t use the Threat Intelligence
module with some of the indicators discovered with Hook Analyser. To use it, you
really want to prep it first. The Threat Intelligence module includes:
·
IP Intelligence
·
Keyword Intelligence
·
Network file analysis
o PCAP
·
Social Intelligence
o Pulls
data from Twitter for user-defined keywords, performs network analysis
Each of these is managed by a flat text file as described
in Beenu’s recent post. One
note, don’t get to extravagant with your keywords. Try to use unique terms that
are tightly related to your investigation and avoid using broad terms such as agent in this case. I dropped a Hacking
Team-related IP address in the intelligence-ipdb.txt
file, the keywords Certum, Unizeto, Hacking Team, and RCS in keywords.txt, and Hacking Team in channels.txt. Tune these files to your
liking and current relevance. As an example URL.txt has some extremely dated
resources from which it pulls IP information, there’s no reason to waste cycles
on all of the default list. I ran the Threat Intelligence module as a
standalone feature as follows: ThreatIntel.exe
-auto. Give it a bit of time, it checks against all the provided sources
and against Twitter as well. Once complete it will pop a view open in your
default browser. You’ll note general information under Global Threat Landscape including suspicious IPs and
ASNs, recent vulnerability data, as well as country and geo-specific threat
visualizations. More interesting and related to your investigation will be the
likes of Keyword based Cyber
Intelligence. The resulting
Co-relation (Bird Eye) view is pretty cool, as seen in Figure 3.
 |
| Figure 3 – A bird’s eye view to related Hacking Team keywords |
Drill into the complete view for full keyword content
results. I updated channels.txt to
include only hackingteam and intelligence-ipdb.txt with related
Hacking Team IP addresses. While I was unable to retrieve viable results for IP
intelligence, the partial results under Social
Intelligence (Recent Tweets) were relevant and timely as seen in Figure
4.
 |
| Figure 4 – Recent Hacking Team related Tweets per the Threat Intelligence module |
There are a few bugs that remain in the Threat
Intelligence module, but it definitely does show promise, I’m sure they’ll be
worked out in later releases.
In Conclusion
The updates to the Threat Intelligence module are reasonable,
potentially making for a useful aggregation of data related to your
investigation, gleaned from your indicators and analysis. Couple that with good
run-time and static analysis of malicious binaries and you have quite a
combination for your arsenal. Use it in good health, to you and your network!
Ping me via email or Twitter if you have questions (russ
at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.
ACK
Beenu Arora, @beenuar, Hook
Analyser developer and project lead
Wednesday, July 01, 2015
toolsmith: Malware Analysis with REMnux Docker Containers
Prerequisites
Docker, runs on Ubuntu, Mac OS X, and Windows
Introduction
ISSA Journal’s theme of the
month is “Malware and what to do with it”. This invites so many possible
smart-alecky responses, including where you can stick it, means by which to
smoke it, and a variety of other abuses for the plethora of malware authors
whose handy work we so enjoy each and every day of our security professional
lives. But alas, that won’t get us further than a few chuckles, so I’ll just
share the best summary response I’ve read to date, courtesy of @infosecjerk,
and move on.
“Security is easy:
1)
Don't install malicious software.
2)
Don't click bad stuff.
3)
Only trust pretty women you don't know.
4)
Do what Gartner says.”
Wait, now I’m not sure
there’s even a reason to continue here. :-)
One of the true benefits of
being a SANS Internet Storm Center Handler is working with top notch security
industry experts, and one such person is Lenny Zeltser. I’ve enjoyed Lenny’s
work for many years; if you’ve taken SANS training you’ve either heard of or
attended his GIAC Reverse Engineering Malware course and likely learned a great
deal. You’re hopefully also aware of Lenny’s Linux toolkit for reverse-engineering
and analyzing malware, REMnux. I covered REMnux in September 2010, but it, and
the landscape, have evolved so much in the five years since. Be sure to grab
the latest OVA and revisit it, if you haven’t utilized it lately. Rather than
revisit REMnux specifically this month, I’ll draw your attention to a really
slick way to analyze malware with Docker and specific malware-analysis related
REMnux project Docker containers that
Lenny’s created. Lenny expressed that he is personally interested in packaging
malware analysis apps as containers because it gives him the opportunity to
learn about container technologies and understand how they might be related to his
work, customers and hobbies. Lenny’s packaging tools that are “useful in a
malware analysis lab, that like-minded security professionals who work with
malware or forensics might also find an interesting starting point for
experimenting with containers and assessing their applicability to other
contexts.”
Docker can be utilized on
Ubuntu, Mac OS X, and Windows, I ran it on the SANS SIFT 3.0 virtual machine
distribution, as well as my Mac Mini. The advantage of Docker containers, per the
What Is Docker page, is simple to understand. First, “Docker allows you to
package an application with all of its dependencies into a standardized unit
for software development.” Everything you need therefore resides in a
container: “Containers have similar resource isolation and allocation benefits
as virtual machines but a different architectural approach allows them to be
much more portable and efficient.” The Docker Engine is just that, the source
from whom all container blessings flow. It utilizes Linux-specific kernel
features so to run it on Windows and Mac OS X, it will install VirtualBox and
boot2docker to create a Linux VM for the containers to run on Windows and Mac
OS X. Windows Server is soon adding direct support for Docker with Windows
Server Containers. In the meantime, if you’re going to go this extent, rather
than just run natively on Linux, you might as well treat yourself to Kitematic,
the desktop GUI for Docker. Read up on
Docker before proceeding if you aren’t already well informed. Most importantly,
read Security Risks and Benefits of Docker Application Containers.
Lenny mentioned that he is
not planning to use containers as the architecture for the REMnux distro,
stating that “This distribution has lots of useful tools installed directly on
the REMnux host alongside the OS. It's fine to run most tools this way.
However, I like the idea of being able to run some applications as separate
containers, which is certainly possible using Docker on top of a system running
the REMnux distro.” As an example, he struggled to set up Maltrieve and JSDetox
directly on REMnux without introducing dependencies and settings that might
break other tools but “running these applications as Docker containers allows
people to have access to these handy utilities without worrying about such
issues.” Lenny started the Docker image repository under the REMnux project umbrella
to provide people with “the opportunity to conveniently use the tools available
via the REMnux Docker repository even if they are not running REMnux.”
Before we dig in to REMnux
Docker containers, I wanted to treat you to a very cool idea I’ve implemented
after reading it on the SANS Digital Forensics and Incident Response Blog as
posted by Lenny. He describes methods to install REMnux on a SIFT workstation, or
SIFT on a REMnux workstation. I opted for the former because Docker runs really
cleanly and natively on SIFT as it is Ubuntu 14.04 x64 under the hood. Installing
REMnux on SIFT is as easy as wget
--quiet -O - https://remnux.org/get-remnux.sh | sudo bash, then wait a
bit. The script will update APT repositories (yes, we’re talking about malware
analysis but no, not that APT) and install all the REMnux packages. When
finished you’ll have all the power of SIFT and REMnux on one glorious
workstation. By the way, if you want to use the full REMnux distribution as
your Docker host, Docker is already fully installed.
Docker setup
After you’ve squared away
your preferred distribution, be sure to run sudo
apt-get update && sudo apt-get upgrade, then run sudo apt-get install docker.io.
REMnux Docker Containers
Included in the REMnux
container collection as of this writing you will find the
V8 JavaScript engine, the Thug low-interaction
honeyclient, the Viper binary analysis framework, Rekall and
Volatility memory forensic
frameworks, the JSDetox JavaScript analysis tool, the Radare2 reverse engineering
framework, the Pescanner static malware analysis tool, the MASTIFF static analysis
framework, and the Maltrieve malware samples downloader. This may well give you
everything you possibly need as a great start for malware reverse engineering
and analysis in one collection of Docker containers. I won’t discuss the Rekall
or Volatility containers as toolsmith readers should already be intimately
familiar with, and happily using, those tools. But it is mighty convenient to
know you can spin them up via Docker.
The first time you run a
Docker container it will be automatically pulled down from the Docker Hub if
you don’t already have a local copy. All the REMnux containers reside there,
you can, as I did, start with @kylemaxwell’s wicked good Maltrieve by executing
sudo docker run --rm -it
remnux/maltrieve bash. Once the container is downloaded and ready, exit
and rerun it with sudo docker run --rm
-it -v ~/samples:/home/sansforensics/samples remnux/maltrieve bash after
you build a samples directory in your home directory. Important note: the -v parameter defines a shared
directory that the container and the supporting host can both access and
utilized. Liken it to Shared Folders in VMWare. Be sure to run sudo chmod a+xwr against it so it’s
world readable/writeable. When all said and done you should be dropped to a
nonroot prompt (a good thing), simply run maltrieve
-d /home/sansforensics/samples/ -l /home/sansforensics/samples/maltieve.log
and wait again as it populates malware samples to your sample directory, as
seen in Figure 1, from the likes of Malc0de, Malware Domain List, Malware URLs,
VX Vault, URLquery, CleanMX, and ZeusTracker.
 |
| Figure 1 – Maltrieve completes its downloads, 780 delicious samples ready for REMnux |
So nice to have a current
local collection. The above mentioned sources update regularly so you can keep
your sample farm fresh. You can also define your preferred DUMPDIR and log
directories in maltrieve.cfg for ease of use.
Next up, a look at the REMnux
MASTIFF container. “MASTIFF is a static analysis framework that automates the
process of extracting key characteristics from a number of different file
formats” from @SecShoggoth.
I ran it as follows: sudo docker run --dns=my.dns.server.ip --rm
-it -v ~/samples:/home/sansforensics/samples remnux/mastiff bash. You
may want or need to replace --dns=my.dns.server.ip
with your preferred DNS
server if you don’t want to use the default 8.8.8.8. I found this ensured name
resolution for me from inside the container. MASTIFF can call the VirusTotal
API and submit malware if you configure it to do so with mastiff.conf, it will
fail if DNS isn’t working properly. You need to edit mastiff.conf via vi with you API key and enable submit=yes. Also note that, when invoked with --rm parameters, the container will be ephemeral and all
customization will disappear once the container exits. You can invoke the
container differently to save the customization and the state.
You may want to also instruct the log_dir
directive to point at your shared samples directory so the results are written
outside the container.
You can then run mas.py
/your/working/directory/samplename with your correct preferences and the result should resemble
Figure 2.
 |
| Figure 2 – Successful REMnux MASTIFF run |
All of the results can be found in /workdir/log under a folder named for each sample analyzed. Checking the
Yara results in yara.txt will inform you that the while the payload is a PE32 it
exhibits malicious document attributes per Didier Steven’s (another brilliant
Internet Storm Center handler) maldoc rules as seen in Figure 3.
 |
| Figure 3 – Yara results indicating a malicious document attributes |
The peinfo-full and peinfo-quick results will provide further
details, indicators, and behaviors necessary to complete your analysis.
Our last example is the REMnux JSDetox container. Per its
website, courtesy of @sven_t, JSDetox “is a tool to support the manual analysis
of malicious Javascript code.” To run it is as simple as sudo docker run --rm -p 3000:3000
remnux/jsdetox, then
point your browser to http://localhost:3000
on your container host system. One of my favorite obfuscated malicious
JavaScipt examples comes courtesy of aw-snap.info and is seen in its raw,
hidden ugliness in Figure 4.
 |
| Figure 4 – Obfuscated malicious JavaScript |
Feed said script to JSDetox
under the Code Analysis tab, run
Analyze, choose the Execution tab, then Show Code and you’ll quickly learn
that the obfuscated code serves up a malicious script from palwas.servehttp.com,
flagged by major browsers and Sucuri.net as distributing malware and acting as
a redirector. The results are evident in Figure 5.
 |
| Figure 5 – JSDetox results |
All the malware analysis horsepower you can imagine in the
convenience of Docker containers, running on top of SIFT with a full REMnux
install too. Way to go, Lenny, my journey is complete. J
In Conclusion
Lenny’s plans for the future include maintaining and
enhancing the REMnux distro with the help of the Debian package repository he
set up for this purpose with Docker and containers part of his design.
Independently, he will continue to build and catalog Docker containers for
useful malware analysis tools, so they can be utilized with or without the
REMnux distro. I am certain this is the best way possible for you readers to
immerse yourself in both Docker technology and some of the best of the REMnux
collection at the same time. Enjoy!
Ping me via email or Twitter if you have questions (russ
at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.
ACK
Thanks again to Lenny
Zeltser, @lennyzeltser, for years of REMnux, and these Docker containers.
Subscribe to:
Posts (Atom)
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ... -
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...
