Mine just crashed, with the remediation applied

Investigate and possibly apply the gotham mitigation script from the ShareFile script. I am hearing that some copy and pastes are not working properly. The shell script creates the policy correctly for certain.

The same forged assertion came back. It reached nsaaad at 12528 and 12550 PM on ns-01, then at 12604 and 12625 PM on ns-02 after the failover: the identical 16-entry PrefixList="P P P …", idp.test.local / The policy didn't match it. It showed 0 hits and 0 undefined hits.

You mean you forgot the AAA vServer Bindings?

yes

doh'

I disabled our Authentication Virtual Server. Users are still able to log in, probably if they've logged in somewhat recently.

@Ryan : Any policy Hit now that is bound on AAA ?? As you seem you were a tgt

@Ryan Gallier are you working now? Im still crashing

i just applied the Auth vServer fix 20 minutes ago... but still up..

and you are talking about these right?

bind authentication vserver

image.png

yes

how do you have them bound?

image.png

yep

guess i should try now... sec

im changing all my bindings to 10 from 100

Here's what I just did

so this is a new responder policy? more strict

yes

i dont see any hits on my responder policy 😞

@c4rm0 are yours still rebooting?

i didn't see any hits on the responder policy, then it crashed again, hence why i tightened it

ok we are doing PA blocking now

Anyone see any hits on the resp pol? 😂 Citrix itself maybe?

by my estimates the next attack is in 7 minutes

you'll only see the hit if you are being attacked right?

that is my expectation

if it comes to it. privatebin.gallier.us/?…#…

would the policy drop it at the send and it sitting in log, or after the fact? We added the policies, and tested the exploit again:

how did you test it?

Sent a malformed payload similar to the WT blog.

ya'll get another reboot about 5 mins ago?

if you did, and I didn't, that would prove my new policy works

need to rename that policy RGPolicy.. hahaha

that pastebin link isnt working ryan

sorry, my home network geoblocks. pasting here

i crashed at 7.39pm GMT

so, 2 crashes at that time, but we didn't crash...

supposedly there is a v2 of the responder policy - has anyone seen that yet? I didnt see it on reddit

i mean, i wrote the one above...

ah i see the screenshot for the one you called v2 -did i miss it in text?

There's v2 in the naming convention, so I think you read past it. :p

anyone still seeing reboots in the near recent?

@Ryan Gallier thank you. Curious, is this a script you created or got from citrix?

been up for 2h20 here

i created it, from the data from my traces on the crashes

Citrix insinuated they have a V2 of the responder policy but we have to 'wait for support.' so im interested to if they are getting their solutions from the community

using Citrix's basic logic

the v1 we got from citrix matched everything here

Thats... not helpful?

call support

that article is a joke

"Wait until the AI is updated to tell you what to do cause we don't know yet, currently sourcing scripts from the community."

you could have atleast pointed to some in the article...

looks like another patch coming:

It will have to be as the responder policy is only going to block the current payload. Threat actor changes the payload and you are broken again. Two items good to know 1. IP Reputation had the IP address in the database already so enabling IP Reputation should stop it. • You can send the management logs (httpaccess.log etc.) to syslog now. • switches • managementlevel ◦ ALL ◦ SHELL ◦ NSMGMT ◦ ACCESS • mgmtloglevel ◦ ALL - All events. ◦ EMERGENCY - Events that indicate an immediate crisis on the server. ◦ ALERT - Events that might require action. ◦ CRITICAL - Events that indicate an imminent server crisis. ◦ ERROR - Events that indicate some type of error. ◦ WARNING - Events that require action in the near future. ◦ NOTICE - Events that the administrator should know about. ◦ INFORMATIONAL - All but low-level events. ◦ DEBUG - All events, in extreme detail. a. NONE - No events.

So we think the current policy from Citrix support is not blocking it?

that's accurate

pretty sure that for us blocking the IP's is what's actually doing the work.. don't see any hits on the ns

Yeah I haven't seen anyone get a hit on the policy

have a test environment that hasn't been hit at all yet.. with only the v2 that Ryan wrote

is 213.209.159.55 the only IP people are seeing for this issue?

I don't think so but it's the main one or the first one

38.134.148.238 - Payload host on :8080 (x.sh, client.py) and reverse-shell listener on :8888 167.148.88.236 - Exfil target on :5000 (uploads a /flash/nsconfig tarball) 213.209.159.55

The 213.209.159.55 is marked as BAD by Opentext, which is the IP-DB for NetScaler's IP-Reputation. Sadly, the two others not at the moment. Checked here support.threatintel.opentext.com/tools/url-ip-lookup.php

full credit.. those are the ip's that Ryan saw pretty early in the payload... we blocked them on our firewall for extra comfort should the payload actually find a way to run

I've reported the IP's now to opentext

Fantastic work