Category: Password Cracking

Password Length: More than Just a Question of Compliance
Password length is a topic we’re asked about a lot, and that makes sense because it can be quite confusing. There are several different compliance models that organizations use – from PCI to NIST to OWASP and more. Each has its own standards for password strength and password length.

When it comes to penetration testing, weak password recommendations often are more rigorous than compliance standards, and this leads to a great deal of stress, especially for organizations that have already spent time and effort in implementing password rules that meet the compliance standards they’ve chosen.

Why So Many Different Standards?

First, speaking from experience, penetration testers see firsthand how weak and reused passwords are often a key part of achieving access over an entire domain (i.e. having administrative powers to view, add, edit, and delete users, files, and sensitive data, including passwords, for an organization’s Active Directory environment). While this is the type of success that pentesters strive to achieve, the true goal of a penetration test is to show organizations weaknesses so that they can close exploitation paths before malicious attackers find them.

For this reason, Raxis penetration tests recommend passwords of at least 12-16 characters for users and at least 20 characters for service accounts. Of course, we recommend more than length (see below for some tips), but Raxis password cracking servers have cracked weak passwords in minutes or even seconds on internal network penetration tests and red team tests several times this year already. We don’t want our customers to experience that outside of a pentest.

On the other hand, compliance frameworks are just that – frameworks. While their aim is to guide organizations to be secure, they do not endeavor to force organizations out of compliance with a stringent set of rules that may not be necessary for all systems and applications. For example, a banking website should require stronger credentials and login rules than a store website that simply allows customers to keep track of the plants they’ve bought without storing financial or personal information.

If you read the small print, compliance frameworks nearly always recommend passwords longer than they require. It’s unlikely, though, that many people read the recommendations when working on a long compliance checklist when they have several more items to complete.

Times are Changing

Of course, time goes on, and even compliance frameworks usually recommend at least ten-character passwords now. The PCI (Payment Card Industry) standards that are required for organizations that process credit cards now require 12 character passwords unless the system cannot accept more than eight characters. PCI DSS v4.0 requirement 8.3.6 does have some exceptions including still allowing PCI DSS v3.2.1’s seven-character minimum length that is grandfathered in until the end of March 2025.

This is a good example of PCI giving companies time to change. It’s been well known for years that someone who has taken the time and expertise to build a powerful password-cracking system can crack a seven-character password hash in minutes. This leaves any organization that still allows seven-character passwords with a strong threat of accounts becoming compromised if the hash is leaked.

OWASP (the Open Web Application Security Project), which provides authoritative guidance for web and mobile application security practices, accepts 10 characters as the recommended minimum in their Authentication Cheat Sheet. OWASP states that they base this on the NIST SP 800-132 standard, which was published in 2010 and is currently in the process of being revised by NIST. Keep in mind that OWASP also recommends that the maximum password length not be set to low, and they recommend 128 characters as the max.

The Center for Internet Security, on the other hand, has added MFA to their password length requirements. In their CIS Password Policy Guide published in 2021, CIS requires 14 character passwords for password-only accounts and eight character passwords for accounts that require MFA.

Other Factors

This brings up a good point. There is more to a strong password than just length.

MFA (multi-factor authentication) allows a second layer of protection such as a smartphone app or a hardware token. Someone discovered or cracked your password? Well, they have one more step before they have access. Keep in mind that some apps allow bypassing MFA for a time on trusted machines (which leaves you vulnerable if a malicious insider is at work or if someone found a way into your offices).

Also keep in mind that busy people sometimes accept alerts on their phones without reading them carefully. For this reason, Raxis has a service – MFA Phishy – that sends MFA requests to employees and alerts them (and reports to management) if they accept the false MFA requests.

MFA is a great security tool, but it still relies on the user to be vigilant.

Raxis’ Recommendations

In the end, there are a myriad of ways that hackers can gain access to accounts. Raxis recommends setting the highest security possible for each layer of controls in order to encourage attackers to move on to an easier target.

We recommend the following rules for passwords along with requiring MFA for all accounts that access sensitive data or services:
1. Require a 12-character minimum password length.
2. Include uppercase and lowercase letters as well as numbers and at least once special character. Extra points for the number and special character being anywhere but the beginning or end of the password!
3. Do not include common mnemonic phrases such as 1234567890, abcdefghijkl, your company name, or other easily guessable words. Don’t be on NordPass’s list!
4. Do not reuse passwords across accounts, which could allow a hacker who gains access to one password to gain access to multiple accounts.
There are two easy ways to follow these rules without causing yourself a major headache:
1. Use a password manager (such as NordPass above, BitWarden, Keeper, or 1Password amongst others). Nowadays these tools integrate for all of your devices and browsers, so you can truly remember one (very long and complex) password in order to easily access all of your passwords
  - These tools often provide password generators that quickly create & save random passwords for your accounts.
  - They usually use Face ID and fingerprint technology to make using them even easier.
  - And they also allow MFA, which we recommend using to keep your accounts secure.
2. Use passphrases. Phrases allow you to easily remember long passwords while making them difficult for an attacker to crack or guess. Just be sure to use phrases that YOU will remember but others won’t guess.
And I’ll leave you with one last recommendation. On Raxis penetration tests, our team often provides a list of the most common passwords we cracked during the engagement in our report to the customer. Don’t be the person with Ihatethiscompany! or Ihatemyb0ss as your password!
June 4, 2024
AD Series: How to Perform Broadcast Attacks Using NTLMRelayx, MiTM6 and Responder
Now that we setup an AD test environment in my last post, we’re ready to try out broadcast attacks on our vulnerable test network.

In this post we will learn how to use tools freely available for use on Kali Linux to:
- Discover password hashes on the network
- Pivot to other machines on the network using discovered credentials and hashes
- Relay connections to other machines to gain access
- View internal file shares
For the attacker machine in my lab, I am using Kali Linux. This can be deployed as a virtual machine on the Proxmox server that we setup in my previous post or can be a separate machine as long as the Active Directory network is reachable.

Most tools we will use are preinstalled on Kali:
- MiTM6: Download from GitHub
- Responder: Installed on Kali
- CrackMapExec: Installed on Kali
- Ntmlrelayx: Installed on Kali (run using impacket-ntlmrelayx)
- Proxychains: Installed on Kali
Setting up the Attack

Within Kali, first we’ll start MiTM6:
```
sudo mitm6 -i {Network Interface}
sudo mitm6 -i eth1
```
MiTM6 will pretend to be a DNS server for a IPv6 network. By default Windows prefers IPv6 over IPv4 networks. Most places don’t utilize the IPv6 network space but don’t have it disabled in their Windows domains. Therefore, by advertising as a IPv6 router and setting the default DNS server to be the attacker, MiTM6 can spoof DNS entries allowing for man in the middle attacks. A note from their GitHub even mentions that it is designed to run with tools like ntlmrelayx and responder.

Next we start Responder:
```
sudo responder -I {Network Interface}
sudo responder -I eth1
```
Responder will listen for broadcast name resolution requests and will respond to them on its own. It also has multiple servers that will listen for network connections and attempt to get user computers to authenticate with them, providing the attacker with their password hash. There is more to the tool than what is covered in this tutorial, so check it out!

With MiTM6 and Responder running, next we start CrackMapExec (CME):
```
crackmapexec smb {Network} –gen-relay-list {OutFile}
```
CME is a useful tool for testing windows computers on the domain. There are many functions within CME that we won’t be discussing in this post, so I definitely recommend taking a deeper look! In this post we are using CME to enumerate SMB servers and whether SMB message signing is required and also to connect to and perform post exploitation activities.

First we will use CME to find all of the SMB servers on the AD network (10.80.0.0/24) and additionally to find those servers which do not require message signing. It saves those which don’t to the file name relay.lst.

Now we’re ready to start ntlmrelayx to relay credentials:
```
impacket-ntlmrelayx -tf {File Containing Target SMB servers} -smb2support
impacket-ntlmrelayx -tf relay.lst -smb2support
```
Ntlmrelayx is a tool that listens for incoming connections (mostly SMB and HTTP) and will, when one is received, relay (think forwarding) the connection/authentication to another SMB server. These other SMB servers are those that were found earlier by CME with the –gen-relay-list flag, so we know they don’t require message signing. Note that the smb2support flag just tells ntlmrelayx to setup a SMBv2 server.

Almost immediately we start getting traffic over HTTP:

Running the Attack

So far the responder, mitm6 and ntlmrelayx screens just show the initial starting of the program. Not much is actually happening in any of them. The CME screen is just showing the usage to gather SMB servers that don’t require message signing.

To help things along with our demo, we can force one of the computers on the network to attempt to access a share that doesn’t exist.

While a user looking for a share that doesn’t exist is not needed for this attack, it’s a quick way to skip waiting for an action to occur automatically. Many times on corporate networks, machines will mount shares automatically or users will need a share at some point allowing an attacker to poison the request them. If responder is the first to answer, our attack works, but, if not, the attack doesn’t work in that instance.

Responder captures and poisons the response so that the computer connects to ntlmrelayx, which is still running in the background.

Below we see where responder hears the search for “newshare” and responds with a fake/poisoned response saying that the attacker’s machine is in fact the host for “newshare.” This causes the victim machine to connect to ntlmrelayx which then relays the connection to another computer that doesn’t require message signing. We don’t need to see or crack a user password hash since we are just acting as a man in the middle (hence MiTM) and relaying the authentication from an actual user to another machine.

In this case the user on the Windows machine who searched for “newshare” turns out to be an administrator over some other machines, particularly the machine that ntlmrelayx relayed their credentials to. This means that ntlmrelayx now has administrator access to that machine.

The default action when ntlmrelayx has admin rights is to dump the SAM database. The SAM database holds the username and password hashes (NTLM) for local accounts to that computer. Due to how Windows authentication works, having the NTLM hash grants access as if we had the password. This means we can login to this computer at any time as the local administrator WITHOUT cracking the hash. While NTLM hashes are easy to crack, this speeds up our attack.

If other computers on the network share the same local accounts, we can then login to those computers as the admin as well. We could also use CME to spray the local admin password hash to check for credential reuse. Keep in mind that the rights and access we get to a server all depends on the rights of the user we are pretending to be. In pentests, we often do not start with an admin user and need to find ways to pivot from our initial user to other users with more access until we gain admin access.

The following screenshot shows ntlmrelayx dumping all of the local SAM password hashes on one device on our test network:

While getting the local account password hashes and and gaining access to new machines is a great attack, ntlmrelayx has more flags and modes that allow for other attacks and access. Let’s continue to explore these.

Playing around with –interactive

Ntlmrelayx has a mode that will create new TCP sockets that will allow for an attacker to interact with the created SMB connections after a successful relay. The flag is –interactive.

When the relay is successful a new TCP port is opened. We can connect to it with Netcat:

We can now interact with the host and the shares that are accessible to the user who is relayed.
```
nc 127.0.0.1 11000
nc 127.0.0.1 11001
```
Playing around with -SOCKS

With a successful relay ntlmrelayx can create a proxy that we can use with other tools to authenticate to other servers on the network. To use this proxy option ntlmrelayx has the -socks flag.

Here we use ntlmrelayx with the -socks flag to use the proxy option:

Below we see another user has an SMB connection relayed to an SMB server. With the proxy option ntlmrelayx sets up a proxy listener locally. When a new session is created (i.e. a user’s request is relayed successfully) it is added to the running sessions. Then, by directing other tools to the proxy server from ntlmrelayx, we can use these tools interact with these sessions.

In order to use this feature we need to set up our proxychains instance to use the proxy server setup by ntlmrelayx.

The following screen shows the proxychains configuration file at /etc/proxychains4.conf. Here we can see that, when we use the proxychains program, it is going to look for a socks4 proxy at localhost on port 1080. Proxychains is another powerful tool that can do much more than this. I recommend taking a deeper look.

Once we have proxychains set up, we can use any program that logs in over SMB. All we need is a user that has an active session. We can view active sessions that we can use to relay by issuing the socks command on ntlmrelayx:

In this example I have backup.admin session for each of the other 2 computers. Let’s use secretsdump from impacket’s library to gather hashes from the computer.

When the program asks for a password we can supply any text at all, as ntlmrelayx will handle the authentication for us and dump the hashes.

Since I am using a private test lab, the password for backup.admin is “Password2.” Here is an example of logging in with smbclient using the correct password:

Using proxychains to proxy the request through ntlmrelayx, we can submit the wrong password and still login successfully to see the same information:

Next Steps

All of the tools we discussed are very powerful, and this is just a sampling of what they can be used for. At Raxis we use these tools on most internal network tests. If you’re interested in a pentesting career, I highly recommend that you take a deeper look at them after performing the examples in this tutorial.

I hope you’ll join me next time when I discuss Active Directory Certificate Services and how to exploit them in our test AD environment.

Want to learn more? Take a look at the next part in our Active Directory Series.
June 19, 2023
How to Create an AD Test Environment

Lead Pentester Andrew Trexler walks us through creating a simple AD environment.

Whether you use the environment to test new hacks before trying them on a pentest, or you use it while learning to pentest and study for the OSCP exam, it is a useful tool to have in your arsenal.

The Basics

Today we’ll go through the steps to set up a Windows Active Directory test environment using Proxmox to virtualize the computers. In the end, we’ll have a total of three connected systems, one Domain Controller and two other computers joined to the domain.

Setting up the Domain Controller (DC)

The first step is to setup a new virtualized network that will contain the Windows Active Directory environment. Select your virtualization server on the left:

This is a Windows based environment, but we’re using a Linux hypervisor to handle the underlying network architecture, so under System, select Network, and then create a Linux Bridge, as shown in Figures 2 and 3:

After setting up the network, we provision a new virtual machine where we will install Windows 2019 Server. Figure 4 shows the final configuration of the provisioned machine:

The next step is to install Windows 2019 Server. While installing the operating system make sure to install the Desktop Experience version of the operating system. This will make sure a GUI is installed, making it easier to configure the system.

Now that we have a fresh install, the next step is to configure the domain controller with a static IP address. This will allow the server to function as the DHCP server. Also make sure to set the same IP as the DNS server since the system will be configured later as the domain’s DNS server.

In order to make things easier to follow and understand later, let’s rename the computer to DC1 since it will be acting as our domain controller on the Active Directory domain.

Next, configure the system as a domain controller by using the Add Roles and Features Wizard to add the Active Directory Domain Services and DNS Server roles. This configuration will allow the server to fulfill the roles of a domain controller and DNS server.

After the roles are installed, we can configure the server and provision the new Active Directory environment. In this lab we will use the domain ad.lab. Other than creating a new forest and setting the name, the default options will be fine.

Setting Up the DHCP Service

The next step is to configure the DHCP service. Here we are using a portion of the 10.80.0.0/24 network space, leaving enough addresses available to accommodate static IP addressing where necessary.

There is no need for any exclusions on the network, and we will set the lease to be valid for an entire year.

Adding a Domain Administrator and Users

Additional configuration is now required within the domain. Let’s add a new domain administrator and some new domain users. Their names and passwords can be anything you want, just make sure to remember them.

First we create the Domain Administrator (DA):

Here we also make this user an Enterprise Admin (EA) by adding them to the Enterprise Admins group:

Next we will add a normal user to the domain:

Creating Windows PC

At this point we should have a functional Active Directory domain with active DHCP and DNS services. Next, we will setup and configure two other Windows 10 machines and join them to the domain.

The first step is to provision the resources on the Proxmox server. Since our test environment requires only moderate resources, we will only provision the machines with two processor cores and two gigabytes of RAM.

Then we install Windows 10 using the default settings. Once Windows is installed, we can open the Settings page and join the system to the ad.lab domain, changing the computer name to something easy to remember if called for.

Adding the system to the domain will require us to enter a domain admin’s password. After a reboot we should be able to login with a domain user’s account.

SMB Share

At this point, there should be three computers joined to the Active Directory domain. Using CrackMapExec, we can see the SMB server running on the domain controller but no other systems are visible via SMB. So let’s add a new network share. Open Explorer.exe, select Advance Sharing, and share the C drive.

I don’t recommend sharing the entire drive in an environment not used for testing, as it’s not secure: the entire contents of the machine would be visible. Since this is a pentest lab environment, though, this is exactly what we are looking for.

Creating the share resulted in the system exposing the SMB service to the network. In Figure 20 we verified this by using CrackMapExec to enumerate the two SMB servers:

Conclusion

At this point, our environment should be provisioned, and we are ready to test out different AD test cases, attacks, and other shenanigans. This environment is a great tool for ethically learning different exploits and refining pentesting techniques. Using a virtual infrastructure such as this also provides rollback capability for running multiple test cases with minimal downtime.

I hope you’ll come back to see my next posts in this series, which will show how to use this environment to test common exploits that we find during penetration testing.

Want to learn more? Take a look at the next part in our Active Directory Series.

April 27, 2023
Understanding the Why Behind Password Management

In this video, Brian will help you understand password management from the viewpoint of a hacker. It’s more than a how-to; it’s also a why-to. We’re hopeful that by seeing a little of what we see, you’ll make password management a high priority for your company.

Despite years of warning, cajoling, and even begging by security professionals, password mismanagement is still one of the most reliable (and one of our favorite) ways to breach a company network. This week, our chief technology officer, Brian Tant, continues his video series about the most common vulnerabilities we see during hundreds of penetration tests each year.

Remember: Complex passwords, unique to each account, and changed frequently are keys to effective password management and security. Also remember to check your service accounts and make sure that old passwords aren’t lingering on your devices.

Effective cybersecurity is a matter of behavior as much as it is technology. Let’s make strong password management a habit that catches on.

Download our list of Top 10 Cyber Attacks to learn more about ways to secure your company.

Want to learn more? Take a look at the next part of our Common Vulnerabilities discussion.

July 10, 2020
3 Steps You Should Take Right Now to Reduce Your Risk of a Cyberattack

Hi everybody, it’s Brian with Raxis, back with another video today!

This is a busy time for us all, with no signs of slowing down. Do you know who else is busy now? Hackers – especially ones that know just how easy it is for thousands of us to forget to update passwords, patch operating systems, and scan for new viruses.

I get it. Life happens. Seniors are graduating, families are acclimating, dogs are crashing Zoom meetings, and many of us are adjusting to completely new work environments. But if you can remember to lock your doors at home, you can get in the habit of locking out cyber attackers at work.

Watch the video above for the top 3 things I wish every company would do today to keep out intruders online:

These steps are the basics that every company should be taking, but, as hackers know all too well, not everyone does. Your company’s security is a 24-hour-a-day responsibility. Make sure your employees and your IT department know how critical it is for everyone to use the tools you already have to stay one step ahead of criminals.

If this video made you wonder how secure your company’s data is, contact Raxis and learn how our tests can help you assess and improve your cyber defenses. We partner with small- and mid-sized businesses, as well as Fortune 500 companies, to help protect your employees, your data, and your bottom line.

Follow us on this blog or social media, and we’ll share more ways that hackers can get in — and how we can help you keep them out.

Download our list of Top 10 Cyber Attacks to learn more about ways to secure your company.

Want to learn more? Take a look at the next part of our Common Vulnerabilities discussion.

June 22, 2020
IKE VPNs Supporting Aggressive Mode
In Raxis penetration tests, we often discover IKE VPNs that allow Aggressive Mode handshakes, even though this vulnerability was identified more than 16 years ago in 2002. In this post we’ll look at why Aggressive Mode continues to be a vulnerability, how it can be exploited, and how network administrators can mitigate this risk to protect their networks and remediate this finding on their penetration tests.

What is an IKE VPN?

Before we get into the security details, here are a few definitions:
- Virtual Private Network (VPN) is a network used to securely connect remote users to a private, internal network.
- Internet Protocol Security (IPSec) is a standard protocol used for VPN security.
- Security Association (SA) is a security policy between entities to define communication. This relationship between the entities is represented by a key.
- Internet Key Exchange (IKE) is an automatic process that negotiates an agreed IPSec Security Association between a remote user and a VPN.
The IKE protocol ensures security for SA communication without the pre-configuration that would otherwise be required. This protocol used by a majority of VPNs including those manufactured by Cisco, Microsoft, Palo Alto, SonicWALL, WatchGuard, and Juniper. The IKE negotiation usually runs on UDP port 500 and can be detected by vulnerability scans.There are two versions of the IKE protocol:
- IKEv2 was introduced in 2005 and can only be used with route-based VPNs.
- IKEv1 was introduced in 1998 and continues to be used in situations where IKEv2 would not be feasible.
Pre-Shared Keys (PSK)

Many IKE VPNs use a pre-shared key (PSK) for authentication. The same PSK must be configured on every IPSec peer. The peers authenticate by computing and sending a keyed hash of data that includes the PSK. When the receiving peer (the VPN) is able to create the same hash independently using the PSK it has, confirming that the initiator (the client) has the same PSK, it authenticates the initiating peer.

While PSKs are easy to configure, every peer must have the same PSK, weakening security.

VPNs often offer other options that increase security but also increase the difficulty of client configuration.
- RSA signatures are more secure because they use a Certificate Authority (CA) to generate a unique digital certificate. These certificates are used much like PSKs, but the peers’ RSA signatures are unique.
- RSA encryption uses public and private keys on all peers so that each side of the transaction can deny the exchange if the encryption does not match.
Cisco goes into details on these options in their VPN and VPN Technologies article.

Aggressive Mode vs. Main Mode

In this post, we are discussing the first phase of IKEv1 transmissions. IKEv1 has two phases:
1. Establish a secure communications channel. This is initiated by the client, and the VPN responds to the method the client requested based on the methods its configuration allows.
2. Use the previously established channel to encrypt and transport data. All communication at this point is expected to be secure based on the authentication that occurred in the first phase. This phase is referred to as Quick Mode.
There are two methods of key exchange available for use in the first IKEv1 phase:
1. Main Mode uses a six-way handshake where parameters are exchanged in multiple rounds with encrypted authentication information.
2. Aggressive Mode uses a three-way handshake where the VPN sends the hashed PSK to the client in a single unencrypted message. This is the method usually used for remote access VPNs or in situations where both peers have dynamic external IP addresses.
The vulnerability we discuss in this article applies to weaknesses in Aggressive Mode. While Aggressive Mode is faster than Main Mode, it is less secure because it reveals the unencrypted authentication hash (the PSK). Aggressive Mode is used more often because Main Mode has the added complexity of requiring clients connecting to the VPN to have static IP addresses or to have certificates installed.

Exploiting Aggressive Mode

Raxis considers Aggressive Mode a moderate risk finding, as it would take a great deal of effort to exploit the vulnerability to the point of gaining internal network access. However, exploitation has been proven possible in published examples. The NIST listing for CVE-2002-1623 describes the vulnerability in detail.A useful tool when testing for IKE Aggressive Mode vulnerabilities is ike-scan, a command-line tool developed by Roy Hills for discovering, fingerprinting, and testing IPSec VPN systems. When setting up an IKE VPN, ike-scan is a great tool to use to verify that everything is configured as expected. When Aggressive Mode is supported by the VPN, the tool can be used to obtain the PSK, often without a valid group name (ID), which can in turn be passed to a hash cracking tool.If you use Kali Linux, ike-scan is included in the build: We can use the following command to download the PSK from an IKE VPN that allows Aggressive Mode:
```
ike-scan -A [IKE-IP-Address] --id=AnyID -PTestkey
```
Here is an example of the command successfully retrieving a PSK:The tool also comes with psk-crack, a tool that allows various options for cracking the discovered PSK.Because Aggressive Mode allows us to download the PSK, we can attempt to crack it offline for extended periods without alerting the VPN owner. Hashcat also provides options for cracking IKE PSKs. This is an example Hashcat command for cracking an IKE PSK that uses an MD5 hash:
```
./hc.bin -m 5300 md5-vpn.psk -a 3 ?a?a?a?a?a?a -u 1024 -n 800
```
Another useful tool is IKEForce, which is a tool created specifically for enumerating group names and conducting XAUTH brute-force attacks. IKEForce includes specific features for attacking IKE VPNs that are configured with added protections.

What VPN Administrators Can Do to Protect Themselves

As Aggressive Mode is an exploitable vulnerability, IKE VPNs that support Aggressive Mode will continue to appear as findings on penetration tests, and they continue to be a threat that possibly can be exploited by a determined attacker.We recommend that VPN administrators take one or more of the following actions to protect their networks. In addition, the above actions, when documented, should satisfy any remediation burden associated with a prior penetration test or other security assessment.
1. Disable Aggressive Mode and only allow Main Mode when possible. Consider using certificates to authenticate clients that have dynamic IP addresses so that Main Mode can be used instead of Aggressive Mode.
2. Use a very complex, unique PSK, and change it on a regular basis. A strong PSK, like a strong password, can protect the VPN by thwarting attackers from cracking the PSK.
3. Change default or easily guessable group names (IDs) to complex group names that are not easily guessed. The more complex the group name, the more difficult of a time an attacker will have accessing the VPN.
4. Keep your VPN fully updated and follow vendor security recommendations. Ensuring software is up to date is one of the best ways stay on top of vulnerability management.
Also see our post on creating a secure password for more information on creating a strong PSK.
May 23, 2018
The Weakest Link in the Password Hash
Your password is strong – but is everyone else’s?

We spend considerable time trying to make sure our passwords are strong. But we also need to spend time educating our user base on why password strength is important.

It is not uncommon for a hacker to establish his foothold in an environment by first compromising a weak or insecurely stored password. Once a base level of authenticated access is established, it becomes a matter of time before privilege escalation is achieved.

So, while your password might be a strong 16 character, alphanumeric with symbols stronghold, your administrative assistant might still be using s0ftc@t1 (which, by the way, would crumble under a modest brute-force attack in less than 48 hours) as hers. If we can get that weak password we can extrapolate from there and gain access to other accounts.

Important lessons to teach:
- Use of symbols to recreate letters (i.e.: @ for a, ! for i, etc) is not that useful. Rule based brute-force attacks use dictionaries and account for common character substitution techniques.
- Longer is better – an 8 character password is trivial for a skilled hacker regardless of it’s complexity. Currently, adding a single character and increasing the length to 9 characters, extends the time it takes to crack the password to a couple of months.
- Use random letters and numbers.
- Capital letters should be used along with non-capitals, but refrain from making the first character the capitalized letter (we expect that and hack for it).
Consider multiple roots

One trick is to use a 10 character base such as:yyT73p@55c

Now remember that (see next section for tips).

Now make it unique. By adding a “-” or a “+” or “_” and then a system identifier such as:
```
yyT73p@55c-dr0p (say, for Dropbox)
```
```
yyT73p@55c+f@cE (for Facebook)
```
```
yyT73p@55c_BoA (for Bank of America)
```
Now you have a super strong random root, followed by a symbol with a dictionary word including caps and symbols if you wish.

Using this formulaic approach it’s possible to take a 10 character root and create a different password by creating an easy to remember tag. Now your passwords are 14+ characters long and easy to remember.

Consider rhyme and pattern

One trick I use for remembering that root is putting it in a rhythm and rhyme pattern that makes sense to me. This was a trick taught to me by a security engineer years ago and it’s worked. In the case of : yyT73p@55c every third letter (and 4th at the end) rhymes, and I have a pace to it.

Different root for types of systems

Now. If you want to supercharge the geek (and help save your butt from mass hack password releases) consider having a small handful of root passwords. Perhaps one you use for social, one for finance, and one for work.

Using that approach still only requires you to remember 3 base passwords, but, in doing so, you’ve strengthened your password repertoire considerably.

Change the root

Regardless of the strength of our passwords it’s still best practice to change them frequently. Using the root system all you need to do is periodically change the root and you’ve reset any exposure to compromise you may have had.

BONUS ROUND.

If you really care about security for a specific site (say, your bank), use a unique username. It doesn’t have to be crazy. If you tend to use “sally15” as your main username try using your last name “sanders15” for the bank. Use the same password root as above – but now you’ve got a unique username and a unique password that is associated with that one service.

The Struggle is Real

Getting your employees to use strong passwords is an uphill battle, but it’s a critical one. Remember – we are looking for the weakest link. Once we get a toe in the door it’s usually all we need before we spread like cancer in your system.

By utilizing a simple system, such as the one suggested here, you can increase the chances of your employees maintaining difficult passwords and strengthening their online security.
October 16, 2016
HP iLO Password Cracking
One of my favorite parts of information security is cracking password hashes. I have a dual nVidia GPU rig that I use to run hashcat on and sometimes my research leads me to crack hashes.

For those who don’t know, HP has a system for Integrated Lights Out, and it allows for remote management of systems. Usually these interfaces are located on a management network that is inaccessible unless you’re a systems admin.

Well, I got my hands on some hashes using the Metasploit module called IPMI 2.0 RAKP Remote SHA1 Password Hash Retrieval. There’s a few blogs that talk about how to do that, so I’ll let you refer to them on the how. What I thought was interesting though is that a lot of the systems I was working with were left to the default password – which is a random 8 digit number.

With a dual GPU hashcat instance, that is fairly trivial. I set a bruteforce attack using -a 3 ?d?d?d?d?d?d?d?d and the result below is what happened.
```
1416515636048
```
It took a mere 4 seconds to spin across 8 digits. If you’re a server admin, I hope you’re setting the administrator passwords on your iLO sessions to something other than digits. Also, and this goes without saying, keep your management network completely firewall off of the production network! There is no need to have the general user with any sort of access at all to these ports.

Still, a very strong password is your last line of defense in the event a breach occurs.
November 28, 2014