The Difficulties of Password Spraying Against a Citrix Netscaler
EDIT: I recently had more success with password spraying NetScalers, so when you're done reading this post, check out this one.
Password spraying against Citrix portals with Burp Suite Intruder can be very difficult to pull off. During pen tests, I usually avoid Citrix NetScalers for these types of attacks and target something easier, like OWA. However, I have found that sometimes the only target available is a Citrix portal. This can be difficult, because Burp Suite and Citrix don't seem to play nice together. It seems to have to do with the limited JavaScript support within Burp, though I could be wrong. The Citrix login failure error messages within Burp certainly do look different than what you get in a browser. (Feel free to comment, if you have a better explanation.) The traditional "Incorrect credentials" error text from Citrix simply does not show up in any of the raw responses coming within Burp:
I have noticed that both failed and successful login attempts against Citrix, nearly always result in a response length of 1,009 bytes, redirecting to another response with a length of 6,371 bytes. That doesn't help much. We need something that is both unique for login success and unique for login failure. I have also noticed that sometimes, for whatever reason, a Citrix portal will provide an initial response of 1,093 bytes, redirecting to another response - the length of which I can't remember, but it was always the same. I even found that this sometimes meant it was a successful login. This was not always the case though, leading to testing each one manually, and a lot of frustration. Ugh.
There is, however, one more method, which can work, if you are lucky: Citrix seems to be aware if the user's password has expired. If you are lucky during a large password spraying attack, you may end up cracking a password for an account that has an expired password. In this case, I've found that the response length will be 1,316 bytes, and the following error can be successfully parsed within the raw response:
"Password expired. Please enter a new password."
This finding was good news to me. After years of difficulty cracking passwords via Citrix portals, I finally had a way to perform password spraying - at least if there is an expired password. I also found that when I utilized the cracked credentials, Citrix would prompt me to change the password. This may not be the case on all implementations, but it was in my case. When I tried to change the password, Citrix rejected it, without explaining why. Eventually, I figured out that the new password I was using did not meet the complexity requirements, so keep that in mind.
Citrix still remains my less-favored choice for performing password spraying attacks. OWA and other portals are just too easy. However, at least I won't be at a dead end on the occasions that Citrix is my only choice.
Password spraying against Citrix portals with Burp Suite Intruder can be very difficult to pull off. During pen tests, I usually avoid Citrix NetScalers for these types of attacks and target something easier, like OWA. However, I have found that sometimes the only target available is a Citrix portal. This can be difficult, because Burp Suite and Citrix don't seem to play nice together. It seems to have to do with the limited JavaScript support within Burp, though I could be wrong. The Citrix login failure error messages within Burp certainly do look different than what you get in a browser. (Feel free to comment, if you have a better explanation.) The traditional "Incorrect credentials" error text from Citrix simply does not show up in any of the raw responses coming within Burp:
I have noticed that both failed and successful login attempts against Citrix, nearly always result in a response length of 1,009 bytes, redirecting to another response with a length of 6,371 bytes. That doesn't help much. We need something that is both unique for login success and unique for login failure. I have also noticed that sometimes, for whatever reason, a Citrix portal will provide an initial response of 1,093 bytes, redirecting to another response - the length of which I can't remember, but it was always the same. I even found that this sometimes meant it was a successful login. This was not always the case though, leading to testing each one manually, and a lot of frustration. Ugh.
There is, however, one more method, which can work, if you are lucky: Citrix seems to be aware if the user's password has expired. If you are lucky during a large password spraying attack, you may end up cracking a password for an account that has an expired password. In this case, I've found that the response length will be 1,316 bytes, and the following error can be successfully parsed within the raw response:
"Password expired. Please enter a new password."
This finding was good news to me. After years of difficulty cracking passwords via Citrix portals, I finally had a way to perform password spraying - at least if there is an expired password. I also found that when I utilized the cracked credentials, Citrix would prompt me to change the password. This may not be the case on all implementations, but it was in my case. When I tried to change the password, Citrix rejected it, without explaining why. Eventually, I figured out that the new password I was using did not meet the complexity requirements, so keep that in mind.
Citrix still remains my less-favored choice for performing password spraying attacks. OWA and other portals are just too easy. However, at least I won't be at a dead end on the occasions that Citrix is my only choice.
Comments
Post a Comment