探花视频

The big cybersecurity companies want you to believe a single tool is all you need. Buy their product and you are 100% 鈥淪ecure鈥� and protected against all attacks. At Scinary, we have seen too much to believe that. Having tools builds security but only when they鈥檙e part of a wholistic defense strategy. Let鈥檚 look at a real example.

Last month, analysts at Scinary detected active exploitation on a client鈥檚 network. The attacker used CVE-2026-0257 to bypass the client鈥檚 restrictions in their affected PAN-OS (Palo-Alto) deployment. This vulnerability involves grabbing a cookie that is normally offered to previously authenticated admin accounts, that provides for 鈥渁uthentication override鈥�. When successfully exploited on an internet facing GlobalProtect portal or gateway this gives the attacker access to the Palo Alto appliance as the user 鈥淎dmin鈥�. Our attackers found themselves with access to the internal network, but no credentials or knowledge of what data may be found other than the profiles in the firewall. So, they set out to discover what would be available to them.

Upon initial entry into the environment, the threat-actor attempted to Kerberoast accounts on the domain. Kerberoasting leverages the Kerberos ticket granting service (that allows for authenticated users to use various services on a domain) responds to queries for tickets related to user accounts that are also designated 鈥渟ervice accounts鈥�. To be a service account, the account is assigned a 鈥淪ervice Principal Name鈥�, or SPN. The attacker can use their newly acquired account to query LDAP for all users with SPN values and even see what groups they are assigned. Once you know who to query for you can send a ticket request to Kerberos for that SPN and you are given a response ticket that contains the NTLM hash for that account. If the account password is simple enough or the attacker has enough time and resources, then the hash can be cracked offline.

It was this brute forcing and Kerberoasting activity that alerted our SOC to an attacker. Fortunately, most brute forcing is loud and with our Centurion M-NDR appliance, the Active Directory Logs are forwarded into the appliance where our SOC can monitor the activity and see the numerous failed logins. This activity is unusual due to the volume of attempts, there being only one IP attempting the logins, and the absurdity of some of the usernames tried, like 鈥淕oldenTicket鈥� (our attacker did not choose a very targeted wordlist). Our analysts found this anomalous spike in traffic and started investigating the offending IP further.

Most readily available Kerberoasting tools prefer to use downgraded encryption suites, specifically RC4, to try and get a hash that is easier to crack. It was this downgraded suite that gave away the kerberoasting attack to our analysts, since each time it tried to use RC4 when AES encryption was enforced the Key Distribution Center (KDC) that is part of Kerberos blocked the usage due to an insecure encryption type.

Now our analysts were positive that this was not some out of sync service having issues negotiating with the domain, this was an attack. What鈥檚 more is we had a singular IP that we could track down.

The client was contacted and the known compromised accounts were shut down. However, it was unknown where the requests were coming from as the IP was not in any documented range. History has shown us that when in doubt, check the VPN. During our review of the Palo Alto logs provided by the client, we found that the attacker was able to leverage the new CVE in part due to an old authentication realm that had been left from a previous configuration. This meant that although the accounts the client used for authenticating to the Palo Alto were protected by DUO MFA the default accounts tied to this old realm, specifically the 鈥渁dmin鈥� account, were not protected.

We had our ingress point. The authentication realm had a VPN pool that matched the IP from the investigation, and the admin account was local explaining the lack of LDAP logs for authentication. All that was left was to find the initial vector. How did the attacker get the admin account? Here we finally arrive at the Palo Alto CVE-2026-0257. There in the logs is a known indicator, the hostname GP-client requesting the admin gateway-auth cookie. Shortly after that we see the cookie used to access the VPN and activity related to the account from Mexico on a Kali Linux machine.

This is the power of defense in depth. Could it have been easier to detect if we had logging from the Palo Alto itself? Absolutely, we are now working with the client to integrate these types of telemetry into our Scinary Connect service, but there are always blind spots or the potential for a new type of attack to get around a singular defensive solution.

When we have multiple data sources, we are imposing multiple obstacles for an attacker to try to evade. They may succeed on one but are unlikely to succeed on all. This investigation proves the efficacy of using defense in depth to not only stop attacks but also identify those blind spots so that your defensive posture can continually improve.

EDR alone wouldn鈥檛 have seen this attack at all. Nor would three teams watching three separate tools have detected or stopped this attack. Only by using a combined, defense-in-depth strategy, the way that Scinary does, are these types of attacks caught.