I can remember it like it was yesterday...  Casey, Hans, Jason, Scott, Sam, Bill and I were slowly destroying my hotel suite at Circle City Con while trying to win the 2015 CTF. (We took 2nd place and never got our GoPro prize... still sour, can you tell?)  Amongst all the teams’ brilliant ideas that evening, was that we really needed a blog. A few hours later, #_shellntel was born.

Our intent was (and still is) to focus on pentesting, hacking and offensive security; we feared that some articles may be too edgy for some corporate/professional readers. Therefore, we separated our #_shellntel articles from other SynerComm blogs. Over the past 7 years, things have changed and today everyone loves pentester articles.

We are grateful for the loyal support of our #_shellntel readers throughout the years. Please continue to read about the latest IT news, tech trends, and cybersecurity threats on our new blog at www.synercomm.com/blog or link directly to our #_shellntel articles at www.synercomm.com/blog/tag/shellntel/. All of our existing content was moved, and all new articles will be published here going forward.

Thank you always,

Brian Judd, VP Information Assurance

SynerComm, Inc.


Whether doing security research or troubleshooting networks, network sniffers and packet analysis can be invaluable tools. If you're a network engineer like me, you've probably been holding onto your favorite 4 or 8-port 10/100 hub for 25 years now. The reason is that hubs (not switches) make great network taps. By design, all Ethernet transmissions on a hub are sent to all ports. To monitor another device, you can place it on a hub along with your laptop/sniffer and then connect that hub to the rest of your network (if needed). All packets sent to or from this device will also be sent to your sniffer on the hub. Even 25 years later, the hub I bought during college still makes a great network tap. It was only recently that I needed something a little more powerful.

Hubs date back to the early years of Ethernet when twisted-pair cabling started being used for networking (like Cat-3/Cat-5). These networks initially ran at only 10 Mb/s and early hubs were also limited to that throughput. As technology advanced, Ethernet speeds increased to 100 Mb/s and new Ethernet switches were created. Unlike hubs, switches only forward packets to the port needed for the packet to reach its intended destination. This was done because hubs can suffer from "collisions" that occur when more than one device tries to transmit at the same time. Switches eliminate packet collisions and allow networks to remain efficient as the number of networked devices grow. Modern switches also support 10/100 Mbit/s and gigabit (1,000 Mbit/s) throughputs. While this is great for network performance, most inexpensive switches can't be used as a network tap.

So, what can you do when you need to monitor a highspeed gigabit link and can't afford an expensive network tap? How about the $39.99 10/100/1000 8-port Netgear GS308E switch with "Enhanced Features". As you probably guessed, one of those enhanced features, called Port Mirroring, allows this switch to be used as a network tap. And unlike a hub, port mirroring allows you to monitor another port without it also monitoring you.

How To:

Follow the instructions below to configure a high-speed (up to gigabit) network tap using the Netgear GS308E switch.

Physical connections:

Port 1 – Device (or Network Segment) Being Monitored

Port 2 – Sniffer (My Laptop)

Port 8 – Uplink to Network (optional)

  1. Log into your Netgear GS308E by going to it's management IP address with a web browser. The default URL is http://192.168.0.249 if there is no DHCP server available to assign an address. (See owners manual if you are having trouble accessing the switch management.)
  2. Click: System (top row) >> Monitoring (2nd row) >> Monitoring (left button)
  3. Port Mirroring Configuration:
    1. Click the Source Port of the port you want to monitor. In our example, this is Port 1. Multiple ports can be selected if you want to monitor several ports at the same time.
    2. In the Mirroring dropdown, select Enable.
    3. In the Destination Port dropdown, select the port that you will connect your sniffer to. In our example, this is Port 2.
    4. Validate that your settings are correct and click Apply.

A screenshot of a computer Description automatically generated.

That's all there is to it! Make sure your devices are connected to the proper ports and start your network analysis.

Warning: This blog contains purposeful marketing and gratuitous plugs for SynerComm’s CASM™ Subscription services. Seriously though, the following article will present the need for better external visibility and vulnerability management.

Whether you are vulnerability scanning to meet compliance requirements or doing it as part of good security practices, there is a universal need. At the time of this article, there are essentially three equally capable and qualified scanning solutions. They include products from Tenable, Rapid7 and Qualys. My point is that each of these scanning solutions, if configured correctly, should produce accurate and similar results. Therefore, as long as your scanning provider is using one of these three solutions, they should be able to detect vulnerabilities. SynerComm starts with a top scanner and then addresses all the gaps that your MSSP is missing. 

Vulnerability scanning and analysis is a critical process within all information security programs. Scanners should find missing patches, dangerous configurations, default passwords, and hundreds of other weaknesses. Their technology is based on probing systems over networks and trying to determine if the system exhibits specific vulnerabilities. While the process itself isn’t complicated, many organizations choose to outsource it to a managed service provider. If you need a provider or already have one, it’s time to upgrade to Continuous Attack Surface Management (CASM™). 

Ditch your Vulnerability Scanning MSSP

Vulnerability scanning MSSPs served their role well for many years but failed to keep up. They failed to keep with cloud migrations, failed to keep up with the rate of IT changes, and failed to provide tools that simplify and enable security for their subscribers. 

VS-MSSPs Lack Discovery of New Assets

VS-MSSPs are Plagued with False Positives and Fail to Accurately Describe Risk 

VS-MSSPs Lack Security Expertise

The benefits of Continuous Attack Surface Management include:

If you’ve ever wondered what your systems and exposures look like to a cyber-criminal, just ask a pentester. SynerComm’s CASM® Engine was originally designed to provide accurate and timely reconnaissance information to our penetration testers. Access to this data and our ‘Findings-Based Reporting’ is available to all CASM® and Continuous Penetration Test subscribers. 

Learn more about our Continuous Attack Surface Management, SynerComm’s CASM® Engine, and our industry-leading Continuous Penetration Test subscriptions. 

VS-MSSPsSynerComm CASM®
Scheduled Scanning of Known Assets✔️✔️
Ad-Hoc (Manual) Scanning✔️✔️
24/7 Online Dashboard Reporting✔️✔️
Discovery of New Assets✔️
Elimination of False-Positives✔️
Validated Findings✔️
Risk-Based Customizable Alerts✔️
Access to Penetration Testers✔️

#_SHELLNTEL

In penetration testing, it’s important to have an accurate scope and even more important to stick to it. This can be simple when the scope is limited to a company’s internet service provider (ISP) or ARIN provided IP ranges. But in many cases, our client’s public systems have grown to include multiple cloud hosted servers, applications, and services. It may seem obvious to say that anything owned or managed by the company should be in-scope for testing, but how do we know what is “owned or managed”? Ideally, we’d test everything that creates risk to an organization, but that isn’t always possible… read on.

I led this article by stating that an accurate scope is critical to penetration testing. If the scope only includes the IP blocks provided by your ISP, you’re probably missing systems that should be tested. Alternately, pentesting a system that you don’t have permission to test could land you in hot water. The good news is that hosting providers like Amazon Web Services (AWS) and Azure allow penetration testing of systems within your account. In other words, because you manage them, you have the right to pentest them. In these environments, pentesting your individual servers (or services) does not affect “neighboring” systems or the cloud host’s infrastructure.

In addition to the many compute and storage providers, you may also have websites and applications that are hosted and managed by a 3rd party. These still create risk to your company, but the hosting provider has complete control over who has permission to perform testing. When there is custom code or sensitive data at play, you should be seeking (written) permission to pentest/assess these systems and applications. If the host is unable or unwilling to allow testing, they should provide evidence of their own independent testing.

There are also going to be cloud systems that, despite creating risk to your organization, can’t be tested at all. This includes software as a service (SaaS) applications like SalesForce, SAP,  and DocuSign. 

And you guessed it… there are also systems like Azure AD, Microsoft 365, and CloudFlare that are not explicitly in-scope, but their controls may not be avoidable during external pentests. MS 365 uses Azure AD which is basically a public extension of your on-premise (internal) Active Directory; complete with extremely high-performance authentication services. Most authentication attacks today take place directly against Azure AD due to its performance and public accessibility. In other words, an attacker could have your passwords before they ever touch a system on your network. Likewise, if your company uses CloudFlare to protect your websites and web applications, it inherently becomes part of the scope because testing of these apps should force you through their proxy/control.

Hopefully this information will help you plan for your next pentest or assessment. If your company maintains an accurate inventory of external systems that includes all of your data center and cloud systems, you’re already off to a great start. Still, there is always value in doing regular searches and discoveries for systems you may be missing. One method involves reviewing your external DNS to obtain a list of A and CNAME records for your domains.  (For ALL of your domains…)  By resolving all of your domains and subdomains you can easily come up with a pretty large list of IP addresses that are in some way tied to your company. Now all you need to do is lookup each IP to see what it’s hosting and who owns it. Easy right?

If you don’t already have a tool for looking up bulk lists of IP addresses or you prefer not to paste a list of your company’s IP addresses into someone else’s website, we’ve got a solution. Whodat.py was written to take very large lists of IP addresses and perform a series of whois and geoip lookups. If the IP address is owned by Amazon or Microsoft, additional details on the service or data center get added based the host’s online documentation. This tool was designed for regular use by our penetration testers, but its concepts and capabilities are a core functionality of our CASM Engine™ and our suite of Continuous Attack Surface Management and Continuous Penetration Testing subscriptions.

Bridging the Gap Between Point-in-Time Penetration Tests 

“So, let’s say we fix all of the vulnerabilities that the pentest discovers… How do we know tomorrow that we’re not vulnerable to something new?”

~Customer

Having been part of the penetration testing industry for over 15 years, I’ve been challenged by many clients with this very question. The fact is that they are right, a penetration test is a point-in-time assessment and new vulnerabilities are discovered every day. We hope that our patch and vulnerability management processes along with our defensive controls (firewalls, etc.) keep our systems secure. Over the past 5 years, we’ve experienced a rise in the number of clients moving towards quarterly penetration testing and seeing the value of rotating through different penetration testers.

In 2017, SynerComm’s penetration testers decided to put their heads together to develop an even better solution. (Honestly, one of our top guys had been nudging me for two years with an idea already…) We agreed that nothing replaces the need for regular human-led penetration testing. As of today, no amount of automation or AI can come close to replicating the intuition and capabilities of an actual penetration tester. That said, if we can be confident that nothing (ok, very little) has changed since the last penetration test, we can be significantly more confident that new vulnerabilities are not present. Building on this idea, the continuous pentest was born.

Continuous pentesting combines the best of both worlds by using automation to continually monitor for changes, and human pentesters to react to those changes quickly. Computers are great at monitoring IP addresses, services, websites, and DNS. They can also monitor breaches and data dumps for names, email addresses, and passwords. What makes continuous pentesting successful, is taking actions based on changes and using orchestration to determine if additional scans can be run and if a pentester should be alerted.

There is no replacement for the validation provided by a thorough, skilled, and human-led penetration test. External and internal pentests with social engineering demonstrate precisely how a determined and skilled intruder could breach your company’s systems and data. Continuous Penetration Testing focuses on public systems and online exposures and should always follow a full, human-led, external penetration test. Partner with SynerComm and we’ll keep an eye on your perimeter security year-round.

Coming from someone who can officially say that information security has given me a few gray hairs, I'm writing this article from the perspective of someone who's been around the block. With over 15 years in information security, I feel like I've seen it all. And while I can't claim to be a great penetration tester myself, I can say that I work with (and have worked with) some truly talented pentesters. I can also feel confident stating that I've read more pentest reports than most.

So, having this background… I get asked by businesses and defenders all the time, "What advice would you give?" and, "What lessons can be learned?"

Well, thanks for asking…. (insert deep breath here)

1. [email protected] are still w3$k!

In fact, we've known that passwords are a weak form of authentication since the moment the first password-based authentication system was created. Passwords can be weak for several compounding reasons. Whether it be due to their limited length and complexity (keyspace) or the fact that they can be shared, guessed, written down, or reused, let's face it, they provide almost no security. Until we stop using passwords or ensure that every last account has a strong and unique password that can't be guessed or cracked, we accept significant risk.


2. Multifactor authentication

(MFA) is not enabled or required for all remote access. While it is almost common place now to find MFA on VPNs, we still find roles, groups, and even URLs allowing MFA to be bypassed. Further, other types of remote access like Citrix and Remote Desktop, Outlook Web Access, and SSH are more overlooked. Remember that when passwords are weak (and they probably are), attackers will be quick to take advantage when MFA is not enforced.


3. Two wrongs don't make a right

Your mom said it, and now I will too. In SynerComm's reporting, we consider both #1 and #2 to be high-severity findings in our pentest reports. When combined, these result in a critical weakness. Password spraying allows an attacker to easily guess common passwords (think Summer19) and gain immediate access to email and internal networks.


4. Vulnerability scanners provide a false sense of security

Don't get me wrong, get your EternalBlue and Heartbleed patched, but don't think just because you're well patched that you are secure. Vulnerability scanning is important, but at its best, it discovers live systems, missing patches, default credentials, weak services, and other well-known vulnerabilities. What it doesn't tell you is that your systems may already include a roadmap to access anything and everything on your network.

Pentesters, just like modern attackers, typically don't rely on missing patches to traverse networks, gather privileges, and access protected data. No vulnerability scanner will warn you that all laptops share the same local administrator password or that a domain admin RDP'd into one of them to troubleshoot an issue (and left their cleartext password cached in memory).


5. Your next-generation firewall and endpoint solution could also provide a false sense of security

Again, don't get me wrong, I am a big fan of solutions like Palo Alto and CrowdStrike.  BUT, simply purchasing and deploying these solutions doesn't make your networks and systems more secure. Like any control, all security solutions must be configured, tuned, and VALIDATED.

Lesson #5: It isn't uncommon to find best of breed security controls running in "monitor only" or "log only" state.  After all, the easiest way to start is to convert that old layer 3 ASA config and turn on the security features later. And let's not forget that ALL IT EMPLOYEES should always be whitelisted in these controls because we don't need that stuff in our way.


6. Maybe this should be #1, but I think hope we've all got this figured out…Compliance does not result in security

Contractual, industry, and especially regulatory compliance are all important, but don't let compliance get in the way of being secure. Information security programs should be designed to protect the confidentiality, integrity, availability, and usefulness of information; compliance should just be a benefit of good security.


7. Last, but not least…  If you develop your own apps, contract development of apps, or acquire custom developed applications, assess them!

Secure coding isn't a new concept, but the concept is (unfortunately) new still to many developers. Widely-used and commercial off the shelf (COTS) applications are heavily scrutinized, but your applications may be waiting for the right attacker to come along. A lesson worth sharing is that a breach can be far more costly than validating and potentially fixing issues before the attack.


If you've made it to this point, thank you for reading through. This often isn't what people expect to hear or even want to hear, but sometimes honesty can be blunt and surprising. My advice is always start with a solid foundation and then build on it. Use frameworks like the CIS Top 20 to provide a prioritized roadmap and don't get caught skipping ahead. Good security can be as simple as keeping to the basics.

Background

While experts have agreed for decades that passwords are a weak method of authentication, their convenience and low cost has kept them around. Until we stop using passwords or start using multi-factor authentication (for everything), a need for stronger passwords exists. And as long as people create their own passwords that must be memorized, those passwords will remain weak and guessable. This blog/article/rant will cover a brief background of password cracking as well as the justification for SynerComm’s 14-character password recommendation.

First things first: What is a password?

Authentication is the process of verifying the identify of a user or process, and a password is the only secret “factor” used in authentication. For the authentication process to be trusted, it must positively identify the account owner and thwart all other attempts. This is critical, because access and privileges are granted based on the user’s role. Considering how easily passwords can be shared, most have already concluded that passwords are an insufficient means of authenticating people. We must also consider that people must memorize their password and that they often need passwords on dozens if not hundreds of systems. Because of this, humans create weak, easily guessed, and often reused passwords.

Password Controls

Over the years, several password controls have emerged to help strengthen password security. This includes minimum password length, complexity, preventing reuse, and a reoccurring requirement to create new passwords. While it is a mathematical fact that longer passwords and a larger key space (more possible characters) do indeed create stronger passwords, we now know that regularly changing one’s password provides no additional security control. In fact, forcing users to regularly create new and complex passwords weakens security. It forces users to create guessable patterns or simply write them down. OK, I will stop here, we'll save the ridiculousness of password aging for a future blog.

So Why 14 Characters?

So why is 14 characters the ideal or best recommended password length? It is not. It is merely a minimal length; we still prefer to see people using even longer passwords (or doing better than passwords in the first place). SynerComm recommends a 14-character minimum for several reasons. First, 14-character passwords are very difficult to crack. Most passwords containing 9 characters or less can be brute-force guessed in under 1 day with a modern password cracking machine. Passwords with 10-12 characters and even 13-14 characters can still be easily guessed if they are based on a word and a 4-digit number. (Consider Summer2018! or your child’s name and birthday.) Next, and perhaps more importantly, 14-character minimums will prevent bad password habits and promote good ones. When done with security awareness training, users can be taught to create and use passphrases instead of passwords. Passphrases can be sentences, combinations of words, etc. that can be meaningful and easy to remember. Finally, 14 characters is the largest “Minimal Password Length” currently allowed by Microsoft Windows. While Windows supports very long passwords, it is not simple to enforce a minimum greater than 14 characters (PSOs can be used to increase this in Windows 2008 and above, and registry hacks from anything older, but it can be a tedious process and introduces variables into the management and troubleshooting of your environment).

The remainder of this article provides facts and evidence to support our recommendations.

Analysis of Password Length

SynerComm collected over 180,000 NTLM password hashes from various breached domain controllers and attempted to crack them using dictionary, brute-force, and cryptanalysis attacks. The chart below shows the password lengths of the over 93,000 passwords cracked. It is interesting to find passwords that fall drastically below the usual minimum length of eight characters. Although few, it is also worth noting that 20, 21 and 22-character passwords (along with one 27-character password) were cracked in these analyses.

Passwords Cracked = 93,706. Total unique entries of those passwords cracked = 68,161

Passwords of 9 or fewer characters account for 50% of those cracked; 12 or fewer, 75%

Password Length - Number of Cracked Passwords
1 = 3 (0.0%)
2 = 2 (0.0%)
3 = 137 (0.15%)
4 = 27 (0.03%)
5 = 405 (0.43%)
6 = 1527 (1.63%)
7 = 3827 (4.08%)
8 = 26191 (27.95%)
9 = 23677 (25.27%)
10 = 17564 (18.74%)
11 = 9098 (9.71%)
12 = 6267 (6.69%)
13 = 2915 (3.11%)
14 = 1063 (1.13%)
15 = 577 (0.62%)
16 = 276 (0.29%)
17 = 81 (0.09%)
18 = 39 (0.04%)
19 = 13 (0.01%)
20 = 10 (0.01%)
21 = 1 (0.0%)
22 = 4 (0.0%)
23 = 0 (0.0%)
24 = 0 (0.0%)
25 = 0 (0.0%)
26 = 1 (0.0%)
27 = 1 (0.0%)

Analysis of Password Composition

*Note: The password "acme" was used to replace specific company names. For example, if the password "synercomm123$" would have been found in a SynerComm password dump it would have been replaced with "acme123$". This change occurred only to serve the top 10 password and base word tables. Analyses of length and masks were performed without this change.

Top 10 passwords
Password1 = 543 (0.58%)
Summer2018 = 424 (0.45%)
Summer18 = 395 (0.42%)
acme80 = 368 (0.39%)
Fall2018 = 362 (0.39%)
Good2go = 350 (0.37%)
yoxvq = 345 (0.37%)
Gr8team = 338 (0.36%)
Today#08 = 308 (0.33%)
Spring2018 = 219 (0.23%)
Top 10 base words
password = 1993 (2.13%)
summer = 1663 (1.77%)
acme = 1619 (1.73%)
spring = 734 (0.78%)
fall = 706 (0.75%)
welcome = 652 (0.7%)
winter = 577 (0.62%)
w0rdpass = 562 (0.6%)
good2go = 351 (0.37%)
yoxvq = 345 (0.37%)
Last 4 digits (Top 10)
2018 = 3037 (3.24%)
2017 = 821 (0.88%)
1234 = 733 (0.78%)
2016 = 659 (0.7%)
2015 = 588 (0.63%)
2014 = 561 (0.6%)
2013 = 435 (0.46%)
2012 = 358 (0.38%)
2010 = 296 (0.32%)
2019 = 286 (0.31%)
Masks (Top 10)
?u?l?l?l?l?l?d?d (6315) (8 char)
?u?l?l?l?l?l?d?d?d?d (4473) (10 char)
?u?l?l?l?l?l?l?d?d (4021) (9 char)
?u?l?l?l?d?d?d?d (3328) (8 char)
?u?l?l?l?l?d?d?d?d (2985) (9 char)
?u?l?l?l?l?l?l?l?d?d (2742) (10 char)
?u?l?l?l?l?l?l?d (2601) (8 char)
?u?l?l?l?l?l?l?l?d (2371) (9 char)
?u?l?l?l?l?l?l?d?d?d?d (1794) (11 char)
?u?d?d?d?d?d?d?d?d (1756) (9 char)

Password Hash Cracking Speeds

When performing our own password cracking, SynerComm uses a modern password cracker built with 8 powerful GPUs (https://www.synercomm.com/blog/how-to-build-a-2nd-8-gpu-password-cracker/). Typically used by gamers to create realistic three-dimensional worlds, these graphics cards are remarkably efficient at performing the mathematical calculations required to defeat password hashing algorithms. The first screenshot below shows a brute-force guess of an 8-character password. It shows that most 8-character passwords will crack in 4.5 hours or less. While the same attack against a 9-character password could take up to 18 days to complete, we can reduce the key space (possible characters used in passwords) and complete 10-11 character attacks in just 1-2 days or less. The second screenshot shows an optimized character set mask attack against 11-character passwords. This attack completes in less than 8 hours and returns many poorly selected 11-character passwords.

Below is an optimized crack attempt for 11-character passwords using only common characters and format (e.g., beginning with an upper case letter or number):

Password Best Practices

  1. Do Not Share Your Password with Anyone!
  2. Do Not Store Passwords in Spreadsheets, Documents, or Email! Also avoid storing passwords in your browser (IE, Firefox, Chrome).
  3. Create passphrases instead of passwords. Long passwords are always stronger than short passwords. Passwords shorter than 10 characters can be easily and quickly cracked if their hashes become available to the attacker. SynerComm recommends enforcing at least a 12-character minimum for standard user accounts but suggests using a 14-character minimum to promote good password creation methods. Privileged accounts such as domain administrators should have even longer passwords.
  4. While password complexity is less critical with long (>=14 char) passwords, it still helps ensure a larger key space. Encourage users to use less common characters such as spaces, commas, and any other special character found on the keyboard. (Spaces can make an enormous difference!)
  5. Never reuse the same password on multiple accounts. While it is easier to remember 1 password than 100, our next best practice will provide a solution to that problem too. Dumps containing passwords from breaches are great starting places to guessing a user’s password.
  6. Use a password safe. Modern password managers can sync stored passwords between computers and mobile devices. By using a safe, most users only need to remember 2-3 passwords and the rest can be stored securely in a safe.
    1. When using a safe, it is best practice to allow the application to generate most passwords. This way you can create 15-20 character completely random passwords that you never need to know or memorize.
  7. Implement multi-factor authentication whenever possible. Passwords will always be a weak and vulnerable form of authentication. Using multi-factor greatly reduces the chances of a successful authentication attack. Multi-factor authentication should be used for ALL (no exceptions) remote access and should increasingly be considered for ALL privileged account access.

*For shared accounts (root, admin, etc.), restrict the number of people who have access to the password. Change these passwords anytime someone who could know the password leaves the organization.

AIT-Why14Characters-20190516_Blog.pdfDownload

~Brian Judd (@njoyzrd) with password analysis by Chad Finkenbiner

Why? … Stop asking questions!

Background

In February 2017, we took our first shot at upgrading our old open-frame 6 GPU cracker (NVIDIA 970).  It served us well, but we needed to crack 8 and 9-character NTLM hashes within hours and not days. The 970s were not cutting it and cooling was always a challenge. Our original 8 GPU rig was designed to put our cooling issues to rest.

Speaking of cooling issues, we enjoyed reading all of the comments on our 2017 build. Everyone seemed convinced that we were about to melt down our data center. We thank everyone for their concern (and entertainment).

"the graphics cards are too close!"

"nonsense. GTX? LOL. No riser card? LOL good luck."

To address cooling, we specifically selected (at the time) NVIDIA 1080 Founders Edition cards due to their 'in the front and out the rear' centrifugal fan design.  A couple months after our initial blog, we upgraded from NVIDIA 1080 to NVIDIA 1080 Ti cards.  And admitedly, we later found that more memory was useful when cracking with large (>10GB) wordlists.

OK, But Why?

Shortly after building our original 8 GPU cracker, we took it to RSA and used it as part of a narrated live hacking demo. Our booth was a play on the Warlock’s command center where we hacked Evil Corp from the comfort of Ma’s Basement. (yeah, a bit unique for RSA…)

Kracken 3 - RSA Debut

Our 1st 8 GPU rig built in February 2017

Shopping List

You have a little flexibility here, but we’d strongly suggest the Tyan chassis and Founders Edition NVIDIA cards. The Tyan comes with the motherboard, power supplies (3x), and arrives all cabled up and ready to build. We went with a 4TB SSD to hold some very large wordlists but did not setup RAID with a 2nd drive (yet). Higher CPU speeds and memory mostly help with dictionary attacks; therefore a different build may be better suited for non-GPU cracking.

Hardware

Software

Cost

The Build

Despite being a hash munching monster and weighing nearly 100 lbs. when assembled, this build is easy enough for novice.

Tyan B7079F77CV10HR-N

Hardware Build Notes

  1. Normally I like to install the CPU(s) first, but I ordered the wrong ones and had to install them 3 days later. Be sure to get V3 or V4 XEON E5 processors, V2 is cheaper but ‘it don’t fit’.

    1. When installing the (included) Tyan heat-sinks, we added a little extra thermal paste even through the heat-sinks already have some on the bottom.

  2. Install memory starting in Banks A and E (see diagram above). CPU 0 and CPU 1 each require matching memory. Memory Banks A-D are for CPU 0 and Memory Banks E-H are for CPU 1. We added 2x 32GB in Bank A and 2x 32GB in Bank E for a total of 128GB RAM.

  3. Install hard drive for (Linux) operating system. We chose a 4TB SSD drive to ensure plenty of storage for large wordlists and optimum read/write performance. The chassis has 10 slots so feel free to go crazy with RAID and storage if you wish.

  4. Prep all 8 GPU cards by installing the included Tyan GPU mounting brackets. They are probably not required, but they ensure a good seat.

  5. Install GPU cards. Each NVIDIA 1080 Ti requires 2 power connections per card. The regular 1080 cards only require 1 if you decide not to go the ‘Ti’ route. Again, Tyan includes all necessary power cables with the chassis.

  6. Connect or insert OS installation media. I hate dealing with issues related to booting and burning ISOs written to USB flash; so we went with a DVD install (USB attached drive).

  7. Connect all 3 power cords to the chassis and connect the other end of each cord to a dedicated 15A or 20A circuit. While cracking, the first 2 power supplies draw 700-900W with a less on the 3rd. They do like dedicated circuits though, it is easy to trip breakers if anything else is sharing the circuit.

Software Build Notes

Everyone has their own preferred operating system and configuration, so we’ve decided not to go telling you how to do your thing. If you are new to installing and using a Linux operating system, we did include a complete walk-through in our February 2017 post: How to build a 8 GPU password cracker.

The basic software build steps are as follows:

  1. Install your preferred Linux OS. We chose Ubuntu 18.04 LTS (64 bit - server). Fully update and upgrade.

  2. Prepare for updated NVIDIA drivers:

2a. Blacklist the generic NVIDIA Nouveau driver

sudo bash -c "echo blacklist nouveau > /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
sudo bash -c "echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
sudo update-initramfs -u
sudo reboot

2b. Add 32-bit headers

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install build-essential libc6:i386

2c. Download, unzip and install the latest NVIDIA driver from http://www.nvidia.com/Download/index.aspx



sudo ./NVIDIA*.run
sudo reboot

3. Download and install hashcat from https://hashcat.net/hashcat/

4. (Optional) Download and install hashview from http://www.hashview.io/

The Outcome

Go ahead, run a benchmark with hashcat to make sure everything works!

./hashcat-5.0.0/hashcat64.bin -m 1000 -b

Going to be at RSA 2019? Stop by and see us! https://events.synercomm.com/events/138/

@njoyzrd

About six years ago, social engineering penetration tests became the norm for the A-Team.  In many of these tests, our team would attempt as many as 10-20 unique exploits against various applications and operating system functions.  This often included exploits against Flash, Java, Adobe Reader, MS Office and IE.  While one or two exploit attempts may have succeeded, the majority would fail.  When it came time to present our report to the client, it would inevitably focus on the successful compromises and their associated vulnerabilities.  In almost every case, our clients would ask about the attacks that failed and what control(s) prevented them.

Consider the following...  I email you an infected PDF file with embedded Java script that, if you are running a vulnerable version of Adobe Reader, will provide me a command and control shell.  If I get a shell back, I know that the recipient received the attachment, they that opened it, that their system had vulnerable software, and that all of their controls (including security awareness) failed to prevent the infection.  However, if I never got a shell, it would be difficult or impossible to determine why the attack failed.  It could be that an email gateway (cloud or on premise) blocked the attachment, antivirus software on the Exchange server could have caught it, antivirus on the desktop, end-user security awareness, etc.  It's also likely that the end-users’ system was patched for the vulnerability I was trying to exploit.  Or, the recipient may have opened the infected document and successfully exploited their system.  In this case, egress filters like web gateways, firewalls, and proxies could also have prevented the command and control communications.  In any of these cases, I have little or no evidence as to why my attack failed.

It was this problem that lead to a unique and valuable solution:  Why not use penetration testing software and exploits to validate controls rather than to just exploit vulnerabilities?  We started by just re-sending the same exploits that we attempted during our social engineering penetration tests, but instead of attacking the workstations of unsuspecting end-users, we sent the exploits to our client's IT security staff.  Then, while receiving emails with infected attachments and while clicking links to browser-based exploits, our clients would monitor their controls to determine which control successfully prevented each attack.  This quickly evolved into much larger groups of exploits and a systematic approach to validating the effectiveness of the technical controls that protect end-user systems.

Today, we refer to this process as a Rapid Hybrid Pentest.  Using commercial penetration testing software, like Metasploit and Core Impact, we generate 25-30 unique exploits.  The exploits target all of the most common software and include both web-based and email-based attacks.  In general, we try to match the exploits up with the vulnerabilities currently being exploited by malware in the wild.  We deliver all of the links to our clients and have them click on them one-by-one as they monitor their controls to determine which get caught and which slip through.  Within a couple hours, we are able to determine which controls work, which are misconfigured, and which don't work at all.  While we've developed this into both a professional service as well as a self-service web application, the process is simple and can be done by anyone with a copy of Metasploit.

linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram