Citrix Systems disclosed yesterday that the FBI had notified the company on the 6th of March of unauthorised access to Citrix's internal network, with the suspected access mechanism being password-spraying against employee accounts (Citrix statement, Stan Black blog post, March 8). The incident-response firm Resecurity has issued a corresponding statement attributing the activity to a threat group they call IRIDIUM and indicating that approximately six terabytes of internal documentation, business documents, and email were taken during a sustained access window of approximately ten years (Resecurity blog post, March 8).
The technical mechanism — password spraying — is unusual to see at this scale and at this level of impact. Password spraying is the credential-attack pattern in which the attacker tries a small number of common passwords against a large population of usernames, rather than the credential-stuffing pattern of trying many passwords against a small number of accounts. The pattern is well-suited to circumventing standard rate-limit-and-account-lockout controls because the per-account attempt rate is low; it is well-suited to environments where MFA is not enforced uniformly across the user population, because each compromised account is one with weaker authentication. The Citrix case suggests that the company's authentication posture against employee accounts had MFA gaps that the password-spraying attack found.
The vendor-side compromise category is the structural concern. Citrix's product portfolio includes Citrix ADC (formerly NetScaler), the application-delivery controller deployed at customer perimeters; XenApp and XenDesktop, the application-virtualisation products deployed at substantial scale across enterprise customer estates; ShareFile, the enterprise-content-management product. The internal documentation taken in the IRIDIUM intrusion includes, on Resecurity's preliminary description, source code, internal engineering documentation, customer-facing technical documentation, and business documentation. The source-code exposure is the operationally significant piece; the customer-organisation question is whether the source-code analysis will eventually produce specific vulnerabilities that affect deployed Citrix products. The answer to that question will, almost certainly, be yes — the only question is when the corresponding vulnerabilities surface in public disclosure or in active exploitation.
For the customer estates, the action this week is to identify Citrix product deployment, to verify patch state, to review customer-side authentication-and-access controls for Citrix-managed services, and to elevate alert posture for any indicators that suggest reconnaissance against Citrix-deployed surfaces. Browne Jacobson uses Citrix XenApp for partner remote access; the deployment is on current versions and is being audited. Towry uses NetScaler/ADC at the perimeter for a small number of services; on current versions, audit in progress. Northcott does not run Citrix. The manufacturer has substantial XenApp deployment for desktop virtualisation and is on a slightly older version that is being upgraded as part of a 2018-planned project; the project schedule has been brought forward. The financial-services firm uses Citrix for several customer-facing services and is on current versions. The retailer does not run Citrix.
The wider strategic point is that vendor-side compromise of products deployed at substantial scale across the enterprise customer base produces a multi-year overhang on the affected customer estates. The Juniper ScreenOS issue from December 2015, the various Cisco-facing items in the Shadow Brokers releases, the Cisco Smart Install issues from April 2018, the Citrix case now — each of these represents a vendor whose product surface has been, at some point in time, in adversary hands, and each of these produces a defensive response that has to assume the adversary has more knowledge of the affected products than the public CVE landscape suggests. The architectural disciplines that respond to this — defence-in-depth, segmentation that does not rely on single vendor's products being honest, monitoring that is independent of the vendor's product, supply-chain integrity verification — are now standard in the customer-programme conversations and are being deployed at varying paces across the portfolio.
I will return to this when the IRIDIUM-related public disclosures firm up. The investigation will produce specific vulnerability disclosures in due course; the customer-organisation programmes will need to absorb them as they land.