SEC595: Applied Data Science and AI/Machine Learning for Cybersecurity Professionals
SEC595Cyber Defense, Artificial Intelligence
SANS Community Benefits
Connect, learn, and share with other cybersecurity professionals
Top of the News
Citrix NetScaler Vulnerability Actively Exploited, Added to KEV with Three-Day Deadline
The US Cybersecurity and Infrastructure Security Agency (CISA) added a critical vulnerability in Cisco NetScaler to the Known Exploited Vulnerabilities (KEV) catalog on Monday, March 30, with a mitigation deadline for Federal Civilian Executive Branch (FCEB) agencies of Thursday, April 2. The critical memory overread flaw (CVE-2026-3055) was disclosed on Monday, March 23. At that time, Citrix made updates available to fix the issue. Researchers at watchTowr observed scanning for vulnerable NetScaler instances late last week, and active exploitation over the weekend. watchTowr has compared the vulnerability to CitrixBleed2, disclosed in June 2025: a critical insufficient input validation leading to memory overread vulnerability (CVE-2025-5777) affecting NetScaler when configured as a Gateway. watchTowr also says that CVE-2026-3055 is not a single vulnerability but instead comprises several memory leak issues: "What we can confidently conclude, post-analysis, is that CVE-2026-3055 is not one singular memory overread vulnerability. In fact, this CVE ID has been assigned to at least two memory overread vulnerabilities, affecting the following endpoints: /saml/login, and /wsfed/passive?wctx." The researchers have passed this information to the Citrix PSIRT team. The UK's National Cyber Security Centre has urged organizations to patch CVE-2026-3055 along with a second vulnerability, CVE-2026-4368, that was disclosed at the same time.
Editor's Notes
- Slide 1 of 2
Keep an active watch for updates and patches from Citrix. As more flaws are discovered and addressed, our adversaries are going to take steps to leverage them in hopes of beating your response time. Make sure your team is leveraging all the available automation and monitoring to reduce dependency and load on your team.
- Slide 2 of 2
Of late, CISA has moved to a 72-hour mitigation window. That’s to be lauded. Unfortunately, with adversary use of AI the exploit window continues to shorten. The best defense continues to be to implement patches as they become available, not waiting for an entry in the KEV catalog.
Slide 1 of 0- Slide 1 of 2
F5 BIG-IP Vulnerability Actively Exploited, Added to KEV with Three Day Deadline
The US Cybersecurity and Infrastructure Security Agency (CISA) added a critical vulnerability in F5 BIG-IP Access Policy Manager (APM) to the Known Exploited Vulnerabilities (KEV) catalog on Friday, March 27, with a mitigation deadline for Federal Civilian Executive Branch (FCEB) agencies of Monday, March 30. According to F5's security advisory, CVE-2025-53521 "was previously categorized and remediated as a Denial-of-Service (DoS) vulnerability with CVSS scores of 7.5 (CVSS v3.1) and 8.7 (CVSS v4.0). Due to new information obtained in March 2026, the original vulnerability is being re-categorized to an RCE with CVSS scores of 9.8 (CVSS v3.1) and 9.3 (CVSS v4.0)." The flaw was initially disclosed in October 2025. They also note that "when a BIG-IP APM access policy is configured on a virtual server, specific malicious traffic can lead to remote code execution. The BIG-IP system in Appliance mode is also vulnerable." The advisory lists vulnerable versions as well as indicators of compromise (IoCs).
Editor's Notes
- Slide 1 of 4
Even if you already patched, make sure you have those IoCs. If you were delaying due to a lower CVSS score, the wait's over: it's critical, and the flaw is not only being exploited but also recast as RCE rather than a DoS flaw. Not really the welcome to spring you were looking for. After applying the update, review the F5 hardening guides to make sure you stack the deck in your favor.
- Slide 2 of 4
The fact that this vulnerability has been changed to RCE is a big change, and organisations should reexamine their original assessment of their vulnerability and deal with it accordingly.
- Slide 3 of 4
Hopefully organizations didn’t wait for entry into the KEV catalog to download and patch the vulnerability. The best defense remains to implement patches as they become available.
- Slide 4 of 4
Deadlines apply only to government agencies, but they are an indicator of urgency for the rest of us.
Slide 1 of 0- Slide 1 of 4
Mitigations Available for Critical Vulnerability in PTC Windchill and PTC FlexPLM
The US Cybersecurity and Infrastructure Security Agency (CISA) and Germany's Federal Office for Information Security, Bundesamt für Sicherheit in der Informationstechnik (BSI), have published advisories for a critical code injection vulnerability in PTC Windchill and PTC FlexPLM product lifecycle management solutions. The flaw could be exploited via deserialization of untrusted data. PTC is currently working on updates to address the vulnerability. In the meantime, PTC has provided mitigations users can undertake to protect their systems, and a list of indicators of compromise (IoCs). Over the weekend of March 21-22, the vulnerability prompted Germany's Federal Criminal Police Office (BKA) to deploy law enforcement officers to alert companies they believed to be affected by the vulnerability.
Editor's Notes
- Slide 1 of 3
I heard from some of my European colleagues who received phone calls from police at 2 and 3 AM to alert them to this issue. When law enforcement is proactively warning organisations about a security issue, you know the risk is real and immediate and your vulnerability management process should accommodate how you react to such a call.
- Slide 2 of 3
Our old friend deserializing untrusted input is back again. If your Windchill or FlexPLM environments are internet-facing, you need to verify they are still copacetic. The fixes for IIS are more involved than for Apache, but both block the attempted exploit. Note these are mitigations, not long-term fixes; get everyone queued up to apply the patches when released.
- Slide 3 of 3
There are always workarounds. They are always less than optimal. Were they not, they would not be workarounds.
Slide 1 of 0- Slide 1 of 3
The Rest of the Week's News
Researchers Find Exposed API Keys
Researchers from Stanford University, University of California Davis, and Delft University of Technology (TU Delft) have published a paper describing their discovery of exposed API keys on the internet. In the paper, "Keys on Doormats: Exposed API Credentials on the Web," the researchers describe their analysis using the TruffleHog tool to "identify 1,748 distinct credentials from 14 service providers (e.g., cloud and payment providers) across nearly 10,000 webpages." Their investigation "reveal[ed] that most exposures are introduced during dynamic bundling, deployment, or resource inclusions rather than their occurrence in static website code that prior works have primarily focused on." They also found that the credentials were exposed for significant lengths of time, averaging 12 months. The paper includes suggested best practices to guard against credential exposure.
Editor's Notes
- Slide 1 of 3
Having API keys exposed is a big concern, and having API keys exposed for long periods of time indicates that management of API keys in some organisations is not as robust as it should be. If your secrets management strategy relies on developers not making mistakes, you already have a problem.
- Slide 2 of 3
The paper is only 18 pages and has good recommendations and insights we may be currently overlooking on API and credential exposure, as well as steps for developers, service providers, and tool and framework maintainers to counteract these discoveries.
- Slide 3 of 3
All private keys should be stored in high security modules (HSMs) that enable their use while hiding them. It took decades before we stopped storing passwords in the clear.
Slide 1 of 0- Slide 1 of 3
OpenAI Patches DNS Flaw in ChatGPT, Command Injection Flaw in Codex
Researchers at Check Point discovered a vulnerability in OpenAI ChatGPT that leaked data through a DNS side channel. Check Point notified OpenAI earlier this year and the flaw was addressed on February 20, 2026. In a blog post, Check Point writes that "The vulnerability we discovered allowed information to be transmitted to an external server through a side channel originating from the container used by ChatGPT for code execution and data analysis. Crucially, because the model operated under the assumption that this environment could not send data outward directly, it did not recognize that behavior as an external data transfer requiring resistance or user mediation. As a result, the leakage did not trigger warnings about data leaving the conversation, did not require explicit user confirmation, and remained largely invisible from the user’s perspective." Researchers at BeyondTrust Phantom Labs "identified a critical command injection vulnerability in OpenAI Codex that allowed for the theft of GitHub User Access Tokens." BeyondTrust reported the flaw to OpenAI on December 16, 2025, and it was fixed as of February 5, 2026.
Editor's Notes
- Slide 1 of 2
An interesting twist to the flaw discovered by Check Point is that that channel can be used for inbound command execution and shell access. While these flaws are fixed, keep an eye on your outbound comms from AI agents (not just ChatGPT) to make sure they are legit and not co-opted.
- Slide 2 of 2
LLMs are even more complex, less mature, and less stable than browsers. Like browsers, there are many instances and many applications per instance. One should assume that they leak, and use them accordingly.
Slide 1 of 0- Slide 1 of 2
GitHub to Train its AI on Copilot Data, but Users Can Opt Out
GitHub has announced a change to its terms of use: Starting April 24, 2026, user interactions with Copilot will be used for training GitHub's AI model to provide "more intelligent, context-aware coding assistance." Users who do not want their data to be used in such a way can opt out of the plan. The new arrangement applies to the Free, Pro, and Pro+ plans; Business and Enterprise plan users are not affected by the change. In addition, students and educators using the free Pro plan and users who have already objected to code matching are not affected. GitHub says that by allowing the data to be used, users will "help [their] models better understand development workflows, deliver more accurate and secure code pattern suggestions, and improve their ability to help you catch potential bugs before they reach production." The plan will collect and train with outputs accepted or modified by users; inputs sent to GitHub Copilot, including code snippets shown to the model; code context surrounding cursor position; comments and documentation; file names repository structure, and navigation patterns; interactions with Copilot features (chat, inline suggestions, etc.); and suggestion feedback. The plan will not use interaction data from Copilot Business, Copilot Enterprise, or enterprise-owned repositories; interaction data from users who opt out of model training in their Copilot settings; or content from issues, discussions, or private repositories at rest.
Editor's Notes
- Slide 1 of 4
While GitHub is working to eliminate enterprise and other less public repositories from Copilot integration as well as limiting the form of Copilot used, it’d be best to make opt-in the default; in essence, if the repo is public, it’s in. Regardless, double check the setting for your environment(s) to be sure they match your acceptable risk and expectations.
- Slide 2 of 4
Microsoft should take the high road and make this opt-in instead of opt-out. Just three years ago, Microsoft had a 38TB data leak when a misconfigured *Microsoft Azure storage bucket* used by the company’s AI research team was mistakenly configured to allow public access and exposed internal AI model development files, training data and logs, and credentials and access keys for other internal tools.
- Slide 3 of 4
GitHub is being clear on the intended use and value of its AI training model. That said, the default should always be to allow the user to ‘opt in’ to the arrangement. That ultimately, provides the user maximum flexibility with their data.
- Slide 4 of 4
User data — not Copilot data, not Microsoft data. This should be user opt-in. We are all asked to opt in to the use of our far less sensitive data. Neither Copilot nor Microsoft are likely to have enough "context" to judge the sensitivity of the data.
Slide 1 of 0- Slide 1 of 4
Healthcare Software Company CareCloud Discloses Network Disruption
In a filing with the US Securities and Exchange Commission (SEC) New Jersey-based company CareCloud disclosed that it "experienced a temporary network disruption in its CareCloud Health division that partially impacted the functionality and data access to 1 of its 6 electronic health record environments for approximately 8 hours." CareCloud notified its "carrier," brought in third-party experts "to perform external cybersecurity work and to assist with securing the environment, as well as to conduct a comprehensive IT forensic investigation to determine the nature and scope of this incident," and has notified law enforcement. The disruption occurred on March 16, 2026, and was contained the same day. CareCloud provides technology and software, including electronic health record systems, to more than 45,000 hospitals and medical practices.
Editor's Notes
- Slide 1 of 4
Looks like it was determined this was more than denial of service — it was an active compromise that may have included malicious access to sensitive information, enough to be declared a “material incident.” In a financial results briefing just days before the announcement, CareCloud’s CEO called 2025 a “transformational year” with accelerated profits. Looks like some of those profits should have been invested in security processes and controls and will now go to paying lawyers and fines.
- Slide 2 of 4
This is a good example of how “temporary disruption” often masks a potentially more serious security incident. While the outage was short-lived, eight hours is enough time for data exfiltration if controls are weak. Customers of CareCloud should be more concerned about what data was accessed during this "temporary disruption" and not how long the disruption lasted.
- Slide 3 of 4
There are not a lot of details of the incident, but suffice it to say, likely a ransomware event. The tells are: 1) Unauthorized third party, 2) Potential access to and exfiltration of data, and 3) Continued investigation. Ransomware actors have been shifting to data exfiltration vice data encryption as the primary means of ransom. What’s important is that they were able to bring it under control within eight hours. That’s impressive.
- Slide 4 of 4
This is more of a heads up than a definitive breach notification, but with the type of data processed and having so many hospitals and practices as customers, it’s appropriate. No group has taken credit for the attack, nor has any of their data been published/offered for sale yet. Healthcare systems remain a lucrative target, because opting out of electronic records isn’t a viable option, and while providers are working to better secure them, patients need to assume breach and protect themselves accordingly. If you’re handling or protecting sensitive information, you need to adopt an active posture where you validate and test your protections continuously.
Slide 1 of 0- Slide 1 of 4
European Commission Discloses Second Data Breach This Year
The European Commission (EC) has disclosed a breach that "affected its cloud infrastructure hosting the Commission's web presence on the Europa.eu platform." The EC discovered the intrusion on March 24, 2026. According to a statement, the EC took steps to contain the incident, and Europa websites remained available during the incident. An investigation suggests the intruders stole data, and the EC is notifying affected entities. According to BleepingComputer, the incident "affected at least one of the Commission's AWS (Amazon Web Services) accounts." AWS told BleepingComputer that they did not experience a security event. This is the second breach the European Commission has disclosed this calendar year; in February, the Commission disclosed that on January 30, 2026, it discovered that a mobile device management platform had been breached.
Editor's Notes
- Slide 1 of 3
A second breach in a matter of weeks raises questions about systemic security weaknesses rather than isolated incidents. Most cloud environments are only as secure as their configuration and access controls, and the reference to AWS accounts suggests this may be more about credential or configuration issues rather than a cloud provider failure. Remember: Cloud allows you to outsource the function, but does not mean you outsource your security responsibilities.
- Slide 2 of 3
The response from AWS indicates the attacker had compromised an EC account rather than compromising an AWS control. The unidentified hacker claims to have exfiltrated 350GB of data, which they are planning to leak later rather than leveraging it to extort (ransom) the EC. Make sure you’re aware of all your data protection controls and verify they use the strongest possible credentials. There really isn’t any such thing as a low risk account, particularly on hosted or cloud systems.
- Slide 3 of 3
There is a saying that goes something like "Fool me once, shame on you..." That said, once breached, trust is reduced for a long time, not to say forever. One of the first things that at a successful attacker is likely to do is to ensure persistent access.
Slide 1 of 0- Slide 1 of 3
Short Takes: Lloyds' Bank Data Exposed, Italian Regulator Fines Banking Group Over Failure to Protect Data
A "glitch" at *Lloyds Banking Grou temporarily exposed personal financial data of nearly 450,000 customers earlier this month. On March 12, customers using the Lloyds, Halifax, and Bank of Scotland banking apps were able to see other customers' account balances, transactions, and personal data, including national insurance numbers. The situation was due to a problem in a system update. Lloyds notified both the UK's Financial Conduct Authority and the Information Commissioner's Office. In a separate story, Italy's Data Protection Authority fined Intesa Sanpaolo SpA €31.8 million (US$36 million) for failure to adequately protect customers' banking information. An investigation revealed that an Intesa Sanpaolo employee accessed banking information of more than 3,500 customers over a 26-month period without having a reason to do so.
Editor's Notes
Beware of ‘move fast and break things’ when it comes to sensitive information. While pressure to release updates now and fix what breaks later will continue, tools which automate checks for flaws and function are more available and can help lessen the burden of validation. As such, the time impact for these needed validations can be minimized, and drive acceptance. Even so, you need human oversight. Remember, one oops cancels all attaboys.