toolsmith: Testing and Research with BlackArch Linux

Introduction

It’s the 24^th of May as I write this, just two days prior to Memorial Day. I am reminded, as Wallace Bruce states in his poem of the same name, that “who kept the faith and fought the fight; the glory theirs, the duty ours.” I also write this on the heels of the Department of Justice’s indictment of five members of the Chinese People’s Liberation Army charging them hacking and cyber theft. While I will not for a moment draw any discussion of cyber conflict together with Memorial Day, I will say that it is our obligation and duty as network defenders to understand offensive tactics to better prepare ourselves for continued digital conflicts. To that end we’ll focus on BlackArch Linux, “a lightweight expansion to Arch Linux for penetration testers and security researchers.” I was not familiar with Arch Linux prior to discovering BlackArch but found myself immediately intrigued by the declarations of its being lightweight, flexible, simple, and minimalist; worthy goals all. Add a powerful set of information security-related tools as seen in BlackArch Linux and you’ve got a top notch distribution for your tool kit. Likely, any toolsmith reader has heard of BackTrack, now Kali, and for good reason as it set the standard for pentesting distributions, but it’s also refreshing to see other strong contenders emerge. BlackArch is distributed as an Arch Linux unofficial user repository so you can install it on top of an existing Arch Linux installation where packages may be installed individually or by specific categories. There is also a live ISO which I utilized to create a BlackArch virtual machine. Arch Linux, while independently developed, is very UNIX-like and draws inspiration from the likes of Slackware and BSD.

According to Evan Teitelman, the founder and one of the primary developers, BlackArch started out as ArchTrack. Arch Track was a small collection of PKGBUILD files, mostly collected from the Arch User Repository (AUR), for his own personal use. PKGBUILDs are an Arch Linux package build description file (a shell script) used when creating packages. At some point, Evan created a few metapackages and uploaded them to the AUR; these metapackages allowed people to install packages by category with AUR helpers. He also created an unofficial user repository but only a few people used it. About six months after ArchTrack began, Evan merged with a smaller project called BlackArch which consisted of about 40 PKGBUILD files at the time, while ArchTrack had about 160. The team ultimately decided to use the BlackArch name as it was more favorable and also came with a website and a Twitter handle. The team abandoned the AUR metapackages and put their focus on the unofficial user repository. Over time, they picked up a few more contributors and the original BlackArch contributor left the project to focus elsewhere. Around the same time, noptrix joined the group who redesigned the website, created the live ISO, and brought in many new packages. Elken and nrz also joined the team and are currently two of the most active members. There are currently about 1200 packages in the BlackArch repository. The team’s goal is to provide as many packages as possible and see no reason to limit the size of the repository but are considering trimming down the ISO.

If you would like to contribute or report a bug, contact the BlackArch team or send a pull request via Github. Evan describes the team as one with little structure and no formal leader or rank; it’s just a group of friends working together who welcome you to join them.

Quick configuration pointers

When booting the ISO in VMWare I found making a few tweaks essential. The default display size is 800x600 and can be changed to 1440x900, or your preferred resolution, with the following: 

xrandr --output Virtual1 --mode 1440x900

BlackArch configures the network interface via DHCP, if you wish to assign a static address right-click on the desktop, choose network, then wicd-gtk.

System updates and package installations are handled via pacman. To sync repositories and upgrade out of date packages use, pacman -Syyu. To install individual packages use pacman –S .

Using BlackArch Linux

BlackArch exemplifies ease of use, as intended. Right-click anywhere on the desktop and the menu is immediately presented. Under terminals I prefer the green xterm as I am in fact writing this from the Nebuchadnezzar while flying through the tunnels under the megacities that existed before the Man–Machine war. J “You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit hole goes.” Sorry, unavoidable Matrix digression. Anyway, you’ve got Firefox and Opera under browsers, and we’ve already discussed using network to define settings. It’s under the blackarch menu that the magic begins on your journey down the rabbit hole as seen in Figure 1.

FIGURE 1: Down the rabbit hole with BlackArch

Pick your poison, what are you in the mood for? The options are clearly many. I was surprised to see Gremwell’s MagicTree under the threat modeling menu having just discussed threat modeling last month. While not quite classic threat modeling, magictree allows penetration testers to organize and query nmap and Nessus data, list all finding by severity (prioritize for ordered mitigation), and generate reports. This activity most assuredly supports both good threat models and penetration testing reporting, the bane of the pentester’s existence.  I was even more amused, given our emerging theme for this month, to note that MagicTree includes a Matrix view.

Malware analysts will enjoy an entire section dedicated to their cause under the malware menu, including cuckoo and malwaredetect (checks Virustotal results from the command line) as seen in Figure 2. I downloaded a Blackhole payload (Zbot password stealer) from my malware repository and ran malwaredetect updateflashplayer.exe.

FIGURE 2:  malwaredetect identifies malware

The forensic options are vast and include your regular odds-on favorites such as Maltego and Volatility as well as hash computation tools such as hashdeep, md5deep, tigerdeep, whirlpooldeep, etc. Tools for the EnCase EWF format are included such as ewfacquire, ewfdebug, ewfexport, ewfinfo, and others. Snort fans will enjoy the inclusion of u2spewfoo which I mention purely for the pleasure of the crisp consonance of the tool name. For forensicators investigating Windows systems with Access databases you can utilize the MDB Tools kit included in BlackArch. To acquire schema execute mdb-schema access.mdb, to determine the Access version run mdb-ver access.mdb, to dump tables try mdb-tables access.mdb, and if you wish to export that table to CSV use mdb-export access.mdb table > table.txt, all as seen in Figure 3.

FIGURE 3: Carving up Access DBs with MDB Tools

While threat modeling, malware analysis and Access forensics may be interesting to some or many of you, most anyone interested in BlackArch Linux is probably most interested in the pwn. “Show us some exploit tools already!” Gotcha, will do. In addition to the Metasploit Framework you’ll find Inguma, the killerbee ZigBee tools, shellnoob, a shellcode writing toolkit, as well as a plethora of other options.

Under the cracker menu you’ll find the likes of mysql_login useful in bruteforcing MySQL connections. As seen in Figure 4 the syntax is simple enough. I tested against one of my servers with mysql_login host=192.168.43.147 user=root password=password which of course failed. You can utilize dictionary lists for usernames and passwords and define parameters to ignore messages as well.

FIGURE 4: Bruteforcing MySQL connections

In fact, BlackArch includes the whole patator toolkit, the multi-purpose brute-forcer, with a modular design and a flexible usage and login brute-forcers for MS-SQL, Oracle, Postgres, as well as other non-database options too as seen in Figure 5.

  

FIGURE 5: Patator

For your next penetration testing engagement you definitely want BlackArch Linux in your toolbag. For that matter, incident response and forensics personnel should carry it as well as it’s useful across the whole spectrum.

In Conclusion

This is one of those “too many tools, not enough time” scenarios. You can and should spend hours leveraging BlackArch across any one of your preferred information security disciplines. Jump in and help the project out if so inclined and keep an eye on the website and Twitter feed for updates and information.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter @holisticinfosec.

Cheers…until next month.

toolsmith: Microsoft Threat Modeling Tool 2014 - Identify & Mitigate

Prerequisites/dependencies

Windows operating system

Introduction

I’ve long been deeply invested in the performance of threat modeling with particular attention to doing so in operational environments rather than limiting the practice to simply software. I wrote the ITInfrastructure Threat Modeling Guide for Microsoft in 2009 with the hope of stimulating this activity. In recent months two events have taken place that contribute significantly to the threat modeling community. In February Adam Shostack published his book, Threat Modeling: Designing for Security and I can say, without hesitation, that it is a gem. I was privileged to serve as the technical proof reader for this book and found that its direct applicability to threat modeling across the full spectrum of target opportunities is inherent throughout. I strongly recommend you add this book to your library as it is, in and of itself, a tool for threat modelers and those who wish to reduce risk, apply mitigations, and improve security posture. This was followed in mid-April by the release of the Microsoft Threat Modeling Tool 2014. The tool had become a bit stale and the 2014 release is a refreshing update that includes a number of feature improvements that we’ll discuss shortly. We’ll also use the tool to conduct a threat model that envisions the ISSA Journal’s focus for the month of May: Healthcare Threats and Controls.

First, I sought out Adam to provide us with insight regarding his perspective on operational threat modeling. As expected, he indicated that whether you're a system administrator, system architect, site reliability engineer, or IT professional, threat modeling is important and applicable to your job. Adam often asks four related questions:

1)      What are you building?

He describes that building an operational system is more likely to be building additional components on top of an existing system and that it's therefore important to model both what you have and how it's changing.    

2)      What can go wrong? 

Adam reminds us that you can use any of the threat enumeration techniques, but that, in particular, STRIDE relates closely to the “CIA” set of properties that are desirable for an operational system. I’ll add OWASP Risk Rating Methodology to the tool’s KB for good measure, given its direct integration of CIA.  

3)      What are you going to do about it? 

Several frameworks can be used here, such as prevent, detect, and respond as well as available technologies. 

4)      Did you do a good job at 1-3? 

Adam points out that assurance activities (which can include compliance) can help you.  More importantly, you can also use approaches such as penetration testing and red teaming to help you determine if you did a good job. I am a strong proponent for this approach. My team at Microsoft includes both threat engineers for threat modeling and assessment as well as penetration testers for discovery and validation of mitigations.

To supplement the commitment to operational threat modeling, I asked Steve Lipner, one of the founding fathers of Microsoft’s Security Development Lifecycle and the Security Response Center (MSRC), for his perspective, which he eloquently provided as follows:

“While threat modeling originated as an approach to evaluating the security of software components, we have found the techniques of security threat modeling to have wide applicability.  Like software components, operational services are targets of attack and can exhibit vulnerabilities.  Threat modeling and STRIDE have proven to be effective for identifying and mitigating vulnerabilities in operational services as well as software products and components.”

With clear alignment around the premise of operational threat modeling let’s take a look at what it means to apply it. 

Identifying Threats and Mitigations with TMT 2014

Emil Karafezov, who is responsible for the Threat Modeling component of the Security Development Lifecycle (SDL) at Microsoft, wrote a useful introduction to the Microsoft Threat Modeling Tool 2014 (TMT). Emil let me know that there are additional details and pointers in the Getting Started Guide and the User Guide which are part of the Threat ModelingTool 2014 Principles SDK. You should definitely read the introduction as well as the guides before proceeding here as I will not be revisiting the basic usage information for the TMT tool or how to threat model (read the book) and will instead focus more in depth on some key new capabilities. I will do so in the context of a threat model for the operational environment of a fictional medical services company called MEDSRV.

Figure 1 includes a view of the MEDSRV operational environment for its web application and databases implementation.

FIGURE 1: A MEDSRV threat model with TMT 2014

Emil offered some additional pointers not shared in his blog post that we’ll explore further with the MEDSRV threat model specific to data extraction and search capabilities.

Data extraction:

From a workflow perspective, the ability to extract information from the tool for record keeping or bug filing is quite useful. The previous version of the TMT included Product Studio and Visual Studio plugins for bug filing but Emil describes them as rather rigid templates that were problematic for users syncing with their server. With TMT 2014 there is a simple right-click Copy Threats for each entry that can be pasted into any text editor or bug tracking system. For bulk threat entry manipulation there is another feature ‘Copy Custom Threat Table’ which lets you dump results conveniently into Excel, which in turn can be imported into workflow management systems via automation. When in Analysis View with focus set in the Threat Information list use the known Ctrl+A shortcut to select all threat entries and with right-click you can edit the constants in the Custom Threat Table as seen in Figure 2.

FIGURE 2: TMT 2014’s Copy Custom Threat Table feature

Search for Threat Information:

Emil also pointed out that TMT 2014’s Search for Threat Information area, while seemingly a standard-to-have option, is new and worth mentioning. This feature is really important if you have a massive threat model with a plethora of threats; the threat list filter is not always the most efficient way to narrow down your criteria. I have found this to be absolute truth during threat modeling sessions of online services at Microsoft where a large model may include hundreds or thousands of threats. To find threats that contained keywords specific to a particular implementation of your mitigations as an example, using Search is the way to go. You might be focusing on data store accessibility as seen in Figure 3.

FIGURE 3: Search for threat information

I also asked Ralph Hood, Microsoft Trustworthy Computing’s Group Program Manager for Secure Development Policies & Tools (the group that oversees the TMT) what stood out for him with this version of the tool. He offered two items in particular:

1)      Migration capability of models from the old version of the tool

2)      The ability to customize threats

Ralph indicated that the TMT tool has not historically supported any kind of migration to newer versions; the ability to migrate models from earlier versions to the 4.1 version is therefore a powerful feature for users who have already conducted numerous threat models with older versions. Threat models should always be considered dynamic (never static) as systems always change and you’ll likely update a model at a later date.

The ability to customize threats is also very important, particularly in the operations space. The ability to change the threat elements and information (mitigation suggestions, threat categories, etc.) for specific environments is of significant importance. Ralph points out as an example that if a specific service or product owner knows that certain threats are assessed differently because of specific characteristics of the service or platform, they can change the related threat information. Threat modelers can do so using a Knowledge Base (KB) created for all related models so any user going forward can utilize the modified KB rather than having to always change threat attributes for each threat manually. According to Ralph, this is important functionality in the operations space where certain service dependencies and platform benefits and/or downfalls may consistently alter threat information. He’s absolutely right so I’ll take the opportunity to tweak the imaginary MEDSRV KB here for your consideration using Appendix II of the User Guide (read it).  The KB is installed by default in C:\Program Files (x86)\Microsoft Threat Modeling Tool 2014\KnowledgeBase. Do not tweak the original, create a copy and modify that. I called my copy KnowledgeBaseMEDSRV and saved it in C:\tmp. I focused exclusively on ThreatCategories.xml and ThreatTypes.xml. Using the OWASP Risk Rating Methodology I added Technical Impact Factors to ThreatCategories.xml and ThreatTypes.xml. Direct from the OWASP site, “technical impact can be broken down into factors aligned with the traditional security areas of concern: confidentiality, integrity, availability, and accountability. The goal is to estimate the magnitude of the impact on the system if the vulnerability were to be exploited.”

·         Loss of confidentiality

o   How much data could be disclosed and how sensitive is it? Minimal non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9)

·         Loss of integrity

o   How much data could be corrupted and how damaged is it? Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9)

·         Loss of availability

o   How much service could be lost and how vital is it? Minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9)

·         Loss of accountability

o   Are the threat agents' actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9)

Note: I renamed the original KnowledgeBase to KnowledgeBase.bak then copied KnowledgeBaseMEDSRV back to the original destination directory and renamed it KnowledgeBase. This prevents corruption of your original files and eliminates the need to re-install TMT. If you’d like my changes to ThreatCategories.xml and ThreatTypes.xml hit me over email or Twitter and I’ll send them to you. That said, following are snippets (Figures 4 & 5) of the changes I made.

FIGURE 4: Additions to ThreatCategories.xml

FIGURE 5: Additions to ThreatTypes.xml

Take notice of a few key elements in the modified XML. I set OTI1 for OWASP Technical Impact and O to O for OWASP. J Remember that each subsequent needs to be unique. I declared source is 'GE.P' and (target is 'GE.P' or target is 'GE.DS') and flow crosses 'GE.TB' because GE.P defines a generic process, GE.DS defines a generic data store and GE.TB defines a generic trust boundary. Therefore, per my modification, data subject to technical impact factors flows across trust boundaries between processes and data stores. Make sense? I used the resulting TMT KB update to provide a threat model of zones defined for MEDSRV as seen in Figure 6.

FIGURE 6: A threat model of MEDSRV zones using Technical Impact Factors

I’m hopeful these slightly more in depth investigations of TMT 2014 features entices you to utilize the tool and to engage in the practice of threat modeling. No time like the present to get started.

In Conclusion

We’ll learned enough here to conclude that you have two immediate actions. First, purchase Threat Modeling: Designing For Security and begin to read it. Follow this by downloading the Microsoft Threat Modeling Tool 2014 and practice threat modeling scenarios with the tool while you read the book. Conducting these in concert will familiarize you with both the practice of threat modeling as well as the use of TMT 2014.  

Remember that July’s ISSA Journal will be entirely focused on the Practical Use of InfoSec Tools. Send articles or abstracts to editor at issa dot org.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter @holisticinfosec.

Cheers…until next month.

Acknowledgements

Microsoft’s:

Adam Shostack, author, Threat Modeling: Designing for Security & Principal Security PM, TwC Secure Ops

Emil Karafezov, Security PM II, TwC Secure Development Tools and Policies

Ralph Hood, Principal Security GPM, TwC Secure Development Tools and Policies

Steve Lipner, Partner Director, TwC Software Security

Browse this: & Oryon C Portable & WhiteHat Aviator

Please take a moment as you read this toolsmith to honor those lost in the Oso, WA landslide disaster and those who have lost loved ones, friends, and homes. Pro Civitas et Patria.

Prerequisites/dependencies

Windows for Oryon C Portable

Mac OS X or Windows for WhiteHat Aviator

Introduction

Spring is upon us and with April comes a focus on Security and Cloud Computing in the ISSA Journal and as such a focus on security-centric Chromium-based web browsers in toolsmith. It also freaks me out just a bit to say this but with April also comes the 90^th consecutive toolsmith. I sure hope you enjoy reading it as much as I do writing it; it’s been a fabulous seven year plus journey so far.

Those of you who enjoy the benefits of rich web content, fast load times, and flexible browser extensibility have likely tried or use the Chrome browser. What you may not be aware of is that there are other Chromium-based browsers that are built with a bit more attention to privacy than might be expected from Chrome proper.

Full disclosure right up front: as a reminder, I work for Microsoft, and the one thing this article won’t be is any kind of a knock on Google Chrome privacy posture or a browser comparison beyond these two Chromium variants. There are plenty of other battles to fight than one in the Browser Wars. We will however have a usability and features-based discussion on Oryon C Portable, an OSINT-focused browser built on the SRWare Iron version 31.0.1700.0 of Chromium, and WhiteHat Aviator, also Chromium based. Note that Chromium, no matter the variant, includes sandboxing which has obvious security advantages.

Oryon C Portable is a web browser designed to assist researchers in conducting Open Source Intelligence (OSINT) investigations, with more than 70 pre-installed tools, while WhiteHat Aviator describes itself the “best and easiest way to bank, shop, browse, and use social networks while stopping viruses, advertisers, hackers, and cyber-crooks.”

According to Marcin Meller of OSINT Insight, the next version of Oryon C will be named Oryon C OSINT Framework and will be based on their own build of Chromium. They’ve made some changes to the tool sets and information sources. While there will be a few new interesting solutions, they also managed to reduce features that proved to be unnecessary. The browser will be lighter, clearer, and more effective, and the new version will offer a cross-platform support including Windows, Linux, and Mac OS X along with a special edition of Oryon F based on the Mozilla source code, specifically for Firefox enthusiasts. These new releases should appear online sometime this summer at the latest. Marcin says that thanks to great feedback from users, including some excellent OSINT specialists, they are highly motivated to make Oryon an even more solid and powerful tool. The active users are the strength of this project, thus, Marcin invites everyone to share their experiences and support Oryon.   

When I pinged Jeremiah Grossman, now WhiteHat’s CEO, he reminded me that Robert ‘RSnake’ Hansen, VP of WhiteHat labs, leads the Aviator project. Ah, the fond memories of April Fools’ Day past (5 years ago now) and the birth of the Application Security Specialist (ASS) certification. Jeremiah is the master of April Fools’ mayhem. It’s not often that you get the opportunity for a photo opp with both Jeremiah and RSnake, but if you’re wearing your ASS shirt at the BlueHat conference, you just might.

FIGURE 1: Robert, Russ, and Jeremiah: certified

Robert filled me in in the Aviator project: “WhiteHat Aviator started off being a more private and secure browsing option for our own internal users. It has morphed into being a consumer product (Mac and Windows) that has additional and originally unforeseen merits.  For instance, it is significantly faster due to having no ads, and by virtue of making Flash and Java a "click-to-play" option.  Users on GoGo inflight wireless love it, because it makes the web usable over latent connections, not to mention it uses less power on your laptop.  We are giving the browser away for free for now, and all users who download it will be grandfathered in, but in the future we will charge for the browser to ensure that our interests are aligned with the user and to help pay for development without requiring us to steal personal information from our users. ;-)  We will quite possibly be the first browser with tech-support!”

Both of the browsers offer the added benefit of enhanced privacy but serve rather different purposes, so let’s explore each for their strengths.

Oryon C Portable

OSINT fans rejoice, there’s a browser dedicated to your cause! Oryon includes more than 70 pre-installed tools, more than 600 links to specialized sources of information and online investigative tools, additional privacy protection features, and a ready-to-use OPML file containing a sorted collection of information sources specific to OSINT, Intelligence, InfoSec, defense, and more. Oryon C Portable is also quite literally…portable. You can run it from all sorts of USB and optical media. I’ll pause for a second so you can take in all the glorious OSINT power at your fingertips as seen in Figure 2.

FIGURE 2: Revel in the OSINT majesty

 You can manage the Oryon C tools from the, yep, you guessed it, the Oryon C tool button. As you do so you’ll see the related button appear on the toolbar and a popup notice that the extension has been enabled. From the same tools button as seen in Figure 3 you can open the full tools menu to create extensions groups and search/sort your extensions.

FIGURE 3: Enable Oryon tool families

There are so many tools to explore with it’s hard to discuss them all but I’ll mention a few of my favorites. Do keep in mind that you may find part of the feature set using Polish as Oryon C is developed by Mediaquest in Poland. The IP Geolocator uses Google Maps and MaxMind to zoom in on the location of IP addresses you enter in the form field. Fresh Start is a cross browser session manager that allows you to save a session and reimport it or recover if it’s crashed. I love Split Screen as it lets you conduct two sessions side by side for comparison. Wappalyzer is a browser extension that uncovers the technology used on websites including content management systems, eCommerce platforms, web servers, JavaScript frameworks, analytics tools and many more. Want to spoof your user-agent? Rhetorical question; yes you do. Make use of the Chrome UA Spoofer. Don’t hesitate to dive into the hyperlinks folders as that represents an entire other level of exploration. The All in one Web Searcher aggregates results from a plethora of search results in one UI as seen in Figure 4.

FIGURE 4: All in one Web Searcher results

Oryon C = playtime for OSINT nerds, and I proudly count myself as one. I literally spent hours experimenting with Oryon and am certain to spend many more similarly. At least I can count it as time towards work. ;-)

WhiteHat Aviator

For Aviator I thought I’d conduct an interesting study, albeit not following optimal scientific standards.

On a Windows 7 virtual machine, I conducted default installations of Aviator and Chrome and made no setting changes. With no other applications running, and no processes generating any network traffic, I executed the following:

Step 1

1)      Started Wireshark

2)      Initiated a capture on the active interface

3)      Started Aviator

4)      Browsed to http://holisticinfosec.blogspot.com

5)      Terminated Aviator

6)      Stopped Wireshark with 5250 frames captured

Step 2

1)      Started Wireshark

2)      Initiated a capture on the active interface

3)      Started Chrome

4)      Browsed to http://holisticinfosec.blogspot.com

5)      Terminated Chrome

6)      Stopped Wireshark with 5250 frames captured

Step 3

1)      Open aviator.pcap in NetworkMiner 1.5 and sorted by Hostname

2)      Open chrome.pcap in NetworkMiner 1.5 and sorted by Hostname 

3)      Compared results

The results were revealing to be sure.

I’m glad to share the captures for your own comparisons; just ping me via email or Twitter if you’d like copies. Notice in Figure 5 the significant differences between counts specific to hosts, files, images, credentials, sessions, DNS, and Parameters.

FIGURE 5: Comparing the differences between Aviator and Chrome browser session network traffic

Aviator is significantly less chatty than Chrome.
Supporting statistics as derived from results seen in Figure 5:
120% less host contact in Aviator capture vs. Chrome capture
69% less file interaction (download of certs, gifs, etc.) in Aviator capture vs. Chrome capture
86% fewer images presented (ads) in Aviator capture vs. Chrome capture
63% fewer total sessions in the Aviator capture vs. the Chrome capture
69% fewer DNS lookups in the Aviator capture vs. the Chrome capture
Hopefully you get the point. :-)

These differences between default configurations of Aviator and Chrome are achieved as follows:

• Aviator's privacy and security safeguards are preconfigured, active and enabled by default
• Aviator eliminates hidden tracking and uses the Disconnect extension to block privacy-destroying tracking from advertisers and social media companies
• WhiteHat is not partnering with advertisers or selling click data
• Unwanted access is prevented as Aviator blocks internal address space to prevent malicious Web pages from hitting your websites, routers, and firewalls

It’s reasonable to ascertain that those with an affinity for strong default privacy settings will favor WhiteHat Aviator given the data noted in Figure 5 and settings provided out of the gate.

In Conclusion

These are a couple of fabulous browsers for your OSINT and privacy/security pleasure. They’re so easy to install and use (I didn’t even include an installation section, no need) that I strongly recommend that you do so immediately.

Take note, readers! July’s ISSA Journal will be entirely focused on the Practical Use of InfoSec Tools. Rather than put up what is usually just me going on about infosec tools, you should too! Send articles or abstracts to editor at issa dot org.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter @holisticinfosec.

Cheers…until next month.

Acknowledgements

Marcin Meller, OSINT Insight

Robert ‘RSnake’ Hansen, VP WhiteHat Labs, Advanced Technology Group