Category: How To

  • New Metasploit Module: Microsoft Remote Desktop Web Access Authentication Timing Attack

    Editor’s note: Congratulations to Raxis Lead Penetration Tester Matt Dunn for discovering the following exploit and publishing it as a Metasploit Module. This is a tremendous professional milestone for Matt and for Raxis.

    “RD Web Access is susceptible to an anonymous authentication timing attack that can validate usernames within an Active Directory domain. Furthermore, RD Web Access exposes the connected domain name if the Remote Procedure Call (RPC) endpoint is accessible on the target server.”

    Raxis Lead Penetration Tester, Matt Dunn

    Microsoft’s Remote Desktop Web Access application (RD Web Access) is a popular web-based remote desktop client. It allows an organizations’ users to access their remote desktop services through a web browser. Recently, I discovered that RD Web Access is susceptible to an anonymous authentication timing attack that can validate usernames within an Active Directory domain. Furthermore, RD Web Access exposes the connected domain name if the Remote Procedure Call (RPC) endpoint is accessible on the target server. An anonymous attacker can exploit this behavior to gather intelligence about an organization’s Active Directory environment and build a list of valid domain users for use in secondary attacks.

    Description

    A similar timing-based authentication vulnerability exists for the Outlook Web Application (OWA), that reveals valid usernames based on comparing the response times between authentication attempts using both valid and invalid usernames. Valid usernames are likewise identified by the RD Web Access application by the differences in these response times. An example of an incorrect username authentication attempt with a response time of over 4 seconds can be seen here:

    Long Response Time with Invalid Username Authentication Attempt

    However, when authenticating with a valid domain and username pair but an incorrect password, the response time is much shorter (232 milliseconds), as seen here:

    Quick Response Time with Valid Domain and Username Authentication Attempt

    By analyzing how quickly the target server responds to these requests, we can determine that login attempts with valid usernames have significantly shorter response times than login attempts with invalid usernames. The timing difference is significant enough that we can use it to determine username validity.

    Note that knowing the target’s Active Directory domain is a prerequisite for this attack. However, if RPC is accessible, retrieving this information from the server is trivial. After issuing a specially crafted NTLM challenge, the encoded response will reveal the target’s Active Directory domain, as seen here:

    Active Directory Domain Revealed in Response

    With the Active Directory domain in hand, we can now fully enumerate the valid usernames for the domain.

    Affected Versions

    Raxis has confirmed the following Windows Server versions running the Remote Desktop Web Access application are vulnerable to this attack:

    • Windows Server 2016
    • Windows Server 2019
    Metasploit Module

    The original OWA/CAS timing authentication vulnerability was disclosed in 2014, and published tools are available to enumerate usernames and discover the domain from servers hosting the OWA. However, my research found that there were no readily available tools to exploit this vulnerability against a hosted RD Web Access instance. I took this opportunity to create a Metasploit module to automate and streamline the attack workflow. The module provides options for domain discovery, username enumeration, and password login attempts. The full module configuration options are shown below:

    Module Configurations for rdp_web_login Auxiliary Module

    After performing the enumeration, the module stores the discovered credentials in the database. An example of this Metasploit module successfully being used to enumerate valid usernames and passwords is shown below:

    rdp_web_login Metasploit Module in Use Against a Test Environment

    The new auxiliary module (auxiliary/scanner/http/rdp_web_login) has been approved by Rapid7 and merged to their master branch. The following links provide details to the module, its documentation, and the original pull request:

    Remediation

    The remediation for this attack is similar to the remediation for the related OWA authentication timing attack. Raxis recommends any of the following actions to mitigate the threat this attack poses:

    • Protect the Remote Desktop Web Access service from the Internet by requiring a VPN connection to access it.
    • Proxy the Remote Desktop Web Access traffic either through an ISA or Microsoft Federation Service as this mitigates the time-based attack.
    • Enforce Multi-Factor Authentication (MFA) for Remote Desktop Services to prevent unauthorized logins from discovered usernames
    Disclosure Timeline
    • January 6th, 2021 – Vulnerability reported to Microsoft
    • January 6th, 2021 – Microsoft begins investigation into report
    • February 4th, 2021 – Microsoft declines to service this vulnerability
    • February 24th, 2021 – Metasploit Module accepted and merged by Rapid7

    Be sure to check back for updates to this post as the status may change.

  • How to Pull Off a Mousejacking Attack

    What’s an easy, effective and potentially devastating cyberattack . . . that’s also named for a rodent?

    If you guessed mousejacking, you are a star student today. 

    A mousejacking attack occurs when an attacker scans for the wireless transmissions sent from your wireless mouse to the USB dongle plugged into your computer. These transmissions from a mouse contain data that describes the mouse’s actions. When an attacker is able to scan and find these transmissions, they may also be able to quickly intercept and, with a few quick keystrokes and clicks, impersonate the mouse and begin sending their own malicious commands through the wireless dongle and into the computer. 

    Users may see a brief pop-up screen with code, but things returns to normal quickly, and many times they don’t think it’s significant enough to notify their security team.

    To add a little insult to injury, an attacker doesn’t even have to be in the building or in close proximity to the workstation to pull this off. They can be in your parking lot or maybe that park across the street.

    Now, there are a lot more technical things that go into it, so take a look at the video above to learn the details.

    So how do you prevent a mousejacking attack? Since this attack only can occur on workstations that are open and running, remember (and remind your colleagues) to always lock your station if you are walking away or not actively working on it. Also, let your colleagues in IT security know about anything suspicious you see. Trust me, they want to know.

    Remember it only takes a few minutes for attackers to get into your network and start causing trouble. 

    Please share this blog and video with your team so they know what to look for and how quickly it can happen, and encourage them to report it immediately. 

    With years of penetration testing and general mischief making behind us, we at Raxis have learned that there is always a way in. And we can find it. Our team of experts are ready to help you and your organization find its weaknesses and help you strengthen your security. Talk with our team today.

  • AttackTek: How to Launch a Broadcast Resolution Poisoning and SMB Relay Attack

    Welcome to our first AttackTek installment, where we’ll go deeper into the tech side of our penetration testing. We’re going to start with a couple of the easiest and most consistent ways we’ve found to get inside corporate networks and gain domain admin rights – sometimes before we finish our coffee on Day 1.

    The first is broadcast name resolution poisoning, known more simply as the broadcast poisoning attack. The second, which we often use in tandem, is the SMB relay attack. 

    For those unfamiliar with these attacks, a broadcast poisoning attack targets users’ credentials as a means to further access corporate networks and data. An SMB relay attack is basically a man-in-the-middle attack in which the malicious actor tries to make the target machine believe that it is the authenticating server.

    These two attack methods work really well together and can be put into motion in a matter of minutes. 

    In this video, I will walk you through an entire attack chain and break down both of these attacks as I’m conducting them.

    Just a friendly heads-up: A lot of the ‘action’ in this video is code on a screen. If you’re a pen tester or a defender, you’ll probably find it very interesting. But if you’re a non-techie and you clicked here after watching your favorite surf video, well . . . enjoy!

    At Raxis, we offer a variety of penetration tests to help you and your company identify vulnerabilities and close the gaps before a cybercriminal finds them. During these tests our team of experienced, professional hackers use every trick in the book – plus some they make up on the fly – to get past your security. 

    If you are ready to explore more penetration testing and assessment options with Raxis, be sure to visit our contact page.

  • Goodies for Hoodies: TCP Timestamps

    The Picts were a tribal culture in northern Scotland that history has relegated to the realm of myth and enigmatic legend. Largely forgotten, the Picts fought off the military superiority of Rome’s army and built a sophisticated civilization on the whole before disappearing from history. These were a people dismissed by the advanced thinkers of the day as unimportant and trivial in their capabilities, only to rise up unexpectedly to great effect. What does this have to do with Security? Nothing really, unless your data center is staffed by Roman centurions on horseback. If that’s you, then I am ripe with envy. But all levity aside, so it was with the Picts, it is today with the humble and unassuming TCP Timestamp.

    What is a TCP Timestamp?

    If you’ve ever run a vulnerability scan, you’ve probably seen a low or informational severity finding associated with TCP Timestamp responses. The recommendation is always to disable them, but rarely is any background information provided. What are those little timestamps doing there and who really cares anyway? Like the Picts, much lies below the surface, and we dismiss them at our peril. Before we can get into the ramifications of this misunderstood protocol option, we must understand the mechanics behind TCP Timestamps, and what they actually are. The basis of TCP is that it is a stateful, reliable means of sending and receiving IP packets. In order for reliable communications to take place, there must be bidirectional communication between the sending and receiving nodes so that, in basic terms, the sender can know that the target system received the communication correctly, and the receiving node has confidence that the message it received was correct. To such ends, TCP communications are session-based, and the two nodes employ features in the protocol as a framework to manage the reliability of communications. This involves things like resets, syn-acks, re-transmissions, and the like, that you’ve probably seen in any number of network captures. TCP was designed to communicate reliably over any transmission medium at any speed; it provides the same level of communications integrity over dial up as it does on a LAN.

    It is important to understand that TCP was originally designed to overcome the challenges of unreliable communication channels. Not much thought was given to excessively reliable and fast communications.

    It seems counter intuitive, but, because TCP is synchronous and keeps track of packets, it can break down over high bandwidth connections. It sounds crazy, I know, but let’s look at how this might happen.

    Grab your pocket protector here, folks. We have to get a little nerdy.

    If you asked President Trump about packet loss on TCP communications, he might respond, “It’s bad, very, very, very bad.” And he would be correct. But packet loss does occur for any number of reasons, and TCP maintains reliability by using selective acknowledgments to tell the sending node what TCP segments are queued on the receiving node and what segments it is still waiting for. These segments are, like anything else in network communications, numbered in finite sequence numbers. This value occupies a 32 bit space and exists within the confines of a Maximum Segment Lifetime (MSL), which is enforced at the IP level by something we’re more familiar with, the Time to Live (TTL). This MSL is usually adjusted based on the transfer rate so that faster speeds have smaller MSLs. This works pretty well until we introduce things like fiber optics. The bandwidth on a fiber connection can be so high that a TCP session can exhaust all of its sequence numbers and still have segments queued up in the same connection, leading to sequence number reuse, aka TCP Wrapping. This causes problems.

    In short, as things get faster, it becomes more error prone to use timeout intervals to manage reliability.

    The number of sequence numbers can not exceed the 32 bit value of 4,294,967,295 so as transmission speed increases, the MSL values must get shorter to compensate. With enough bandwidth, they can shrink to the point that they are no longer able to provide message integrity. If only there was a way to identify whether packets were dropped based on actual timing rather than a sequence number, but how?

    Behold the mighty TCP Timestamp!

    TCP Timestamps are an important component of reliable high speed communications because they keep TCP from stumbling over its own sequence numbers!Officially, this benefit is referred to adoringly as “PAWS” or Protection Against Wrapped Sequence Numbers. PAWS operates within the confines of a single TCP connection under the assumption that the TCP timestamp value increases predictably over time. If a segment is received with an older timestamp than one that was expected, it’s discarded. In doing so, PAWS protects against sequence numbers being reused in the same connection. It’s worth pointing out that there are a lot of weird exceptions and math around how that actually takes place, but for purposes of a blog post, we’ll steer clear of that rabbit hole. It should be clear at this point that TCP Timestamps serve a purpose in network communications, and that disabling them as a standard practice is a perilous endeavor.

    Still awake? Good! Now we can talk about security!

    Strictly speaking, TCP Timestamps are no more a security risk than the TCP protocol itself. Why then are they subject to all the bad press and mob calls for their disablement? The security concerns arise with the underlying mechanisms that are used to populate the values within the timestamp option itself. As the name suggests, the timestamp makes use of a virtual “timestamp clock” in the sender’s operating system. This clock must approximate real time measurements in order to remain compatible with other RTT measurements. There is no requirement for the timestamp clock to match the system clock, but it often maps to it for ease of design. After all, why make a new clock if you can just use the existing clock to derive values to be presented as those belonging to the new clock?

    This leads to the one thing for which we hackers profess a deep and undying love for, unintended and predictable behavior. Am I right?

    By measuring multiple timestamp replies, we can determine what the clock frequency is of the target system. The clock frequency is how many “ticks” the timestamp clock increments per unit of real time. For example, if we measure 5 timestamp replies each 1 second apart, and each timestamp value increases by 100 with each reply, we can infer that the clock increments 100 ticks for every second of real time processed by the system clock.Since most (not all!!) clocks start at 0, we can compute the approximate uptime of the system. Using the above example, if the timestamp value is 60000, we know that each 100 ticks of that value equate to one second of real time. We can assume that 600 seconds have elapsed since the clock was started. In laymen’s terms, the system was rebooted 10 minutes ago. We’re using small whole numbers here for purposes of illustration, but you get the idea.

    In the real world, accurately fingerprinting the system will help with establishing timestamp validity, since clock specifications are documented.

    System uptime by itself is an arbitrary value and doesn’t give away much on it’s own. But consider that patch cycles almost always include mandatory reboots. By surveying these values over time, one might be able to determine patching intervals by correlating reboot times across systems. What if you surveyed the same IP address multiple times and received different but consistently disparate values in the timestamp responses? That might allow you to identify systems that are behind a NAT or a load balancer, and may even allow you to draw conclusions about the load balancing configuration itself. Suppose you were testing a customer for susceptibility to DOS attacks. You may be able to use timestamps to determine with certainty whether the target system was knocked over, or whether you were just shunned by the IPS.

    TCP Timestamps grant the hacker insight into a given system’s operational state, and how we use that information is limited only by our imagination.

    But to dismiss their presence as a low severity security finding just to be remediated is inappropriate, and it may do more harm than good. When to use TCP timestamps should be determined by operational requirements, not by blanket assumptions of their importance. Are you listening, vulnerability scanners?So next time you find yourself knee deep in informational findings from a vulnerability scan, put your ear close to a network cable. It’s possible you may hear the faint battle cry of a forgotten hero. Want to keep reading? Learn the difference between vulnerability scans and penetration tests, more about Vulnerability Management, and how a penetration test can help you understand which risks are most relevant to your network.

  • 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
    ike-scan in Kali Linux

    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
    ike-scan
    psk-crack

    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.

  • Raxis API Tool

    At Raxis we perform several API penetration tests each year. Our lead developer, Adam Fernandez, has developed a tool to use for testing JSON-based REST APIs, and we’re sharing this tool on GitHub to help API developers test their own code during the SDLC process and to prepare for third-party API penetration tests.This code does not work on its own… it’s a base that API developers can customize specifically for their code. You can find the tool at https://github.com/RaxisInc/api-tool.

    Here’s a basic overview of the tool from Adam himself:

    The Raxis API tool is a simple Node.js class built for assessing API endpoints. The class is designed to be fully extensible and modifiable to support many different types of JSON-based REST APIs. It automatically handles token-based authentication, proxies requests, and exposes several functions designed to make it easier and faster to write a wrapper around an API and associated test code for the purposes of a penetration test. This tool is not designed to work on its own, but to serve as a building block and quickstart for code-based API penetration testing.

     

  • 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.

  • 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.