Post-Exploitation Technique After Hacking Ivanti, Fortigate VPN Servers

Akamai researchers have delved into the often-overlooked threat of VPN post-exploitation, highlighting techniques that threat actors can use to escalate their intrusion after compromising a VPN server. The study focuses on vulnerabilities and no-fix techniques affecting Ivanti Connect Secure and FortiGate VPNs, potentially allowing attackers to gain control over other critical network assets.

VPN servers have long been targets for attackers due to their accessibility from the Internet and rich attack surface. Historically, these servers have been used as gateways into internal networks. However, the researchers aimed to explore what additional goals an attacker could achieve after compromising a VPN server.

Living Off the VPN

Researchers identified two main approaches to VPN post-exploitation: targeting the device’s OS and abusing the existing VPN management interface. The latter approach, dubbed “living off the VPN,” is more cost-effective and easier to execute, as it doesn’t require developing a custom implant.

1. This type of access can be easier to obtain than full RCE — access to the management interface can be obtained through an authentication bypass vulnerability, weak credentials, or phishing.
2. This approach can be more cost-effective, as we avoid the effort of developing a custom payload.

To demonstrate, Akamai researchers targeted Ivanti Connect Secure and FortiGate VPN servers, uncovering two CVEs and several no-fix techniques that attackers could use to take control of critical network assets, potentially turning a VPN compromise into a full network breach.

Are you from SOC and DFIR Teams? Analyse Malware Incidents & get live Access with ANY.RUN -> Get 14 Days Free Acces

Abusing Remote Authentication Servers

One critical asset handled by VPN servers is external credentials. The researchers found techniques to compromise these credentials, mainly when using LDAP and RADIUS authentication servers.

• LDAP Authentication: Both FortiGate and Ivanti were found to transmit LDAP credentials in cleartext when using simple authentication. Even when secure protocols like LDAPS and TLS are used, an attacker controlling the VPN can downgrade the configuration to capture credentials.
• RADIUS Authentication: The researchers discovered a method to register a rogue authentication server, allowing them to capture user credentials. This can be done by adding a rogue server to a user group or realm, causing the VPN to attempt authentication using the attacker-controlled server.

Capturing LDAP Credentials

When using plain LDAP for authentication, credentials sent to the VPN can be compromised by an attacker sitting between the VPN and LDAP server or by an attacker controlling the VPN server. To capture these credentials without dropping an implant, attackers can use the built-in packet capture feature in FortiGate and Ivanti to intercept LDAP packets.

Even if secure protocols like LDAPS and TLS are used, an attacker with control over the VPN can modify the configuration to downgrade it back to plain LDAP.

This can be done by changing the configuration for regular LDAP servers or by using AD connection details to configure a new LDAP server for Ivanti’s AD server. This change is transparent to users and causes the VPN to send passwords in cleartext, allowing attackers to obtain credentials and pivot into the domain easily.

Registering a Rogue Authentication Server

According to Akamai research, A security vulnerability has been identified in FortiGate and Ivanti VPNs, which can be exploited to compromise user credentials during authentication. The flaw involves manipulating the authentication process by registering a rogue authentication server.

FortiGate VPN: Users can be grouped to apply specific permissions, including remote groups from external servers like LDAP. However, when a user from a mixed group (local and remote) authenticates, FortiGate attempts to validate their credentials against all configured servers, granting access if any server approves, regardless of the intended server.

Ivanti VPN: Similar issues arise, though Ivanti restricts authentication realms to a single server. However, when an additional server is configured, Ivanti will validate credentials against both, succeeding only if both servers approve. This loophole can be exploited by attackers to compromise security.

Creating a Rogue Authentication Server to leak Credentials

An attacker can exploit vulnerabilities in FortiGate and Ivanti VPNs by setting up a rogue authentication server to capture user credentials. By adding this rogue server to a FortiGate user group or Ivanti realm, the VPN will send authentication attempts to the attacker-controlled server, leaking credentials.

This method targets both VPN clients and administrators. The attacker can use a RADIUS server to capture and decrypt credentials, leveraging the fact that credentials are sent in the initial request without verification and encrypted with a key controlled by the attacker.

The provided script demonstrates how to decrypt RADIUS passwords. To ensure successful authentication in Ivanti, the rogue server must be configured to approve any provided credentials.

The study also revealed that VPN configuration files contain sensitive information such as local user passwords, SSH keys, and third-party service account credentials.

These secrets are stored encrypted but can be decrypted using known keys. FortiGate uses a hard-coded key by default, which can be exploited to decrypt secrets. An attacker can revert the encryption to the default key even if a custom key is used.

The findings suggest that a compromised VPN server can be more than just a gateway into the network. It can be used to access additional resources and potentially lead to a complete network compromise. The researchers emphasize the importance of following best practices to minimize the risks of VPN post-exploitation techniques.

Mitigation

To minimize risks when using a VPN server, follow these four key principles:

1. Employ Zero Trust Network Access (ZTNA): Traditional VPNs grant broad network access, which is risky if compromised. ZTNA limits access based on identity and context, allowing users only the access they need while minimizing the impact of potential breaches.
2. Limit Service Account Permissions: Since VPNs may expose service account passwords in plaintext, restrict these accounts to minimal permissions, ideally read-only. This reduces the damage that could result from a VPN compromise.
3. Use Dedicated Identities for VPN Authentication: Avoid using existing authentication services like AD for VPN access, as compromised credentials could lead to wider network breaches. Instead, use separate, dedicated authentication methods, such as certificate-based authentication.
4. Monitor Configuration Changes: Regularly check for changes in VPN device configurations, comparing them to a baseline “golden image.” Monitoring these changes and analyzing logs can help detect and prevent unauthorized modifications.

These recommendations emphasize the importance of not blindly trusting your VPN and taking proactive steps to secure it.