Trustwave Rapid Response: CrowdStrike Falcon Outage Update. Learn More

Trustwave Rapid Response: CrowdStrike Falcon Outage Update. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Cracking IKE Mission:Improbable (Part 2)

A couple of weeks ago I posted Part 1 of Cracking IKE, detailing some useful techniques when cracking Aggressive Mode PSK hashes. In that post we saw that a hash is not always 'crackable' and additional steps are required in order to find a correct group name or ID. In this post I will be discussing a more recent vulnerability I discovered on the Cisco ASA platform that allows you to do just that.

A Quick Recap

Going back to the previous post we saw that it was possible to enumerate group names by analyzing subtle differences in the response from the ASA firewall, specifically the presence of a DPD (Dead Peer Detection)payload. So by sending requests to the device with a list of potential group names it's possible to find a valid group name if the ASA software isn't patched.

What's New?

So I decided to look for any additional signs that may leak information about the validity of the group name. I did this by analyzing genuine IKE negotiations and sending a variety of different requests, looking for anything that may provide a clue. I eventually noticed that some differences remain even in the latest version of ASA software. Basically, a correct group name elicits four (this can vary depending on the software version) attempts to continue the handshake and an additional encrypted phase 2packet, while the device will only respond twice to an incorrect group name. This is probably better described in images.

Incorrect group name:


Correct group name:



The differences are quite obvious so to demonstrate I've written a proof of concept python script that enumerates the group names using this technique, which can be found here. Although it's incredibly slow because of the need to wait for the response packets each time a request is made. It requires a wordlist and a target as input, allows the hash type to be specified (MD5 or SHA1) and looks like this:


The group name (or ID) can then be used to capture a genuine hash for cracking using a cracker of your choice, as described in Part 1:


Personally I prefer Hashcat:


How Do I Protect Against This?

Cisco have released software updates to address this issue, further details/updates can be found  here. Administrators with affected software versions should be aware that this information could be potentially revealed, it is recommended that these updates are applied if your devices are allowing PSK authentication. It is also recommended that default or easily guessable group names should not be used and strong Pre-Shared Keys are a must. The keys should be rotated as often as is practically possible and Aggressive Mode IKE negotiations should be disabled where possible, but of course this is not always a possibility with Remote Access setups. In an ideal world PSK negotiations should be replaced with certificates.

Now What?

Stay tuned for Part 3 which will cover the next steps where Mission: Improbable becomes a reality…

Latest SpiderLabs Blogs

Trustwave Rapid Response: CrowdStrike Falcon Outage Update

Trustwave is proactively assessing and monitoring our clients who may have been impacted by CrowdStrike’s recently rolled-out update for its Windows users. The critical issue identified with...

Read More

Using AWS Secrets Manager and Lambda Function to Store, Rotate and Secure Keys

When working with Amazon Web Services (AWS), we often find that various AWS services need to store and manage secrets. AWS Secrets Manager is the go-to solution for this. It's a centralized service...

Read More

Facebook Malvertising Epidemic – Unraveling a Persistent Threat: SYS01

The Trustwave SpiderLabs Threat Intelligence team's ongoing study into how threat actors use Facebook for malicious activity has uncovered a new version of the SYS01 stealer. This stealer is designed...

Read More