SEC536: Adversarial AI - Penetration Testing AI Systems


Experience SANS training through course previews.
Learn MoreLet us help.
Contact usBecome a member for instant access to our free resources.
Sign UpWe're here to help.
Contact UsRussian-speaking threat actors have breached Fortinet firewalls at organizations in nearly every country in the world. In all, nearly 74,000 Fortinet devices were compromised across more than 21,000 domains, and the credentials have been leaked online. The database of stolen information was discovered by security researcher Bob Diachenko, who found and accessed the threat actors' operational infrastructure. Affected organizations include Oracle, Chevron, Lenovo, Federal Express, a NATO defense contractor, and Fortinet. On June 17, researcher Kevin Beaumont confirmed that most of the compromised devices were still online, and that the compromised devices account for nearly half of all internet-facing Fortinet devices. Researchers at Hudson Rock published their analysis of the data, addressing the attackers' methodology, the scope of the breach, and a look into the attackers' logs. The UK's National Cyber Security Centre (NCSC) has also published guidance for Fortinet users, and the US Cybersecurity and Infrastructure Security Agency (CISA) is urging Fortinet users to secure their devices. Suggested mitigations include removing the devices from internet exposure; forcing credential rotation and upgrading hashing; assuming compromise and checking for backdoors; enforcing strict MFA; monitoring for stolen credentials; and upgrading to the most recent FortiOS release. Beaumont adds, "if you see suspect success logins to admin users, I would suggest replacing the device as they may have altered settings to backdoor a device."

Enterprise security appliances remain one of the biggest holes one can punch in their perimeter. Fortinet rightfully states that this event was possible because of missing MFA and patches. Customers are certainly not blameless: They select vendors. “FortiBleed” has become as big a story as it is because adversaries used compromised devices to collect additional credentials from traffic passing through the device. This is not a new technique. Incident playbooks for compromised perimeter security devices should always consider what traffic the attacker had access to.

If the reported scale of this compromise proves accurate, it represents one of the most significant exposures of perimeter security infrastructure in recent years. Affected organisations should not just rotate passwords and move on. Any device suspected of compromise should be thoroughly investigated, and in some cases, replacement may be the safest option. This incident also reinforces the importance of making your management interface only available from privileged devices on an internal network or via a VPN, having strong MFA implemented, and making sure it is actively monitored for unusual access patterns and attempts.

This attack has breached Fortinet devices in 194 countries. Hudson Rock has published a lookup tool to see if your device is compromised, and Fortinet is proactively contacting impacted customers. If you have a FortiGate appliance, affected or not, you should take the recommended actions. Verify that phishing-resistant MFA is required on all remote access and internet facing services. Further, make sure that no management interfaces are internet facing. Make sure your device logs are successfully feeding to your SIEM and that you can detect unexpected access. How often are accounts, and their access rights, validated? You not only want to detect unauthorized accounts, but also those with more privileges than they should have.
This development represents a significant threat vector for organizations utilizing Fortinet firewalls. First action should be an immediate rotation of all user credentials alongside continuous compromise monitoring, taking precedence over root-cause analysis. Culturally, this incident underscores the necessity of standardizing fundamental security hygiene, specifically rapid OS patch deployment and robust MFA implementation. Both are core to essential cyber hygiene and are foundational components of Implementation Group 1 (IG1) within the CIS Critical Security Controls: https://www.cisecurity.org/controls/implementation-groups/ig1
Ars Technica
The Register
Infosecurity Magazine
BleepingComputer
Hudson Rock
DoublePulsar
NCSC
CISA
Certificates for the cryptographic keys in the Secure Boot process on computers running Windows and Linux will expire on June 24, 2026. Users must ensure their certificates are upgraded in order to protect against attacks on the UEFI (Unified Extensible Firmware Interface), including bootkits, which inhabit a machine where the firmware initializes the boot process, outside the operating system. Secure Boot relies on cryptography to validate the trust in each piece of the boot process, protecting against unrecognized or malicious firmware. The expiring certificates were issued in 2011, and the replacements were created in 2023 after the discovery of a flaw dubbed "LogoFail," which exploits logo images displayed during startup to inject rogue certificates and bypass Secure Boot. Users of Windows 11 and of Windows 10 with extended security updates should receive the new certificates automatically through Windows Update, and many Linux distributions provide them in their software updaters; systems that do not receive the new certificates will still function, but will not have UEFI Secure Boot protection.

The certificates should be updated on supported operating systems through the normal update cycles. For your Windows systems you can check Windows Security Settings -> Device Security -> Secure Boot — look for a green checkmark. On Linux use mokutil --db to display the certificates and make sure they're updated.
An up-to-date asset inventory is essential for handling events like this. Windows and standard Linux distros seem to be covered automatically, but we need to focus on the 'other' assets that require manual certificate updates. Hopefully, Infosec has been on top of this since 2023 — otherwise a lot of teams are in for a rude awakening.
In the past week, the US Cybersecurity and Infrastructure Security Agency (CISA) has added four CVEs to the Known Exploited Vulnerabilities (KEV) catalog; of those, three have been assigned three-day mitigation deadlines for Federal Civilian Executive Branch (FCEB) agencies. CVE-2026-54420, a high-severity UNIX Symbolic Link (Symlink) following issue in LiteSpeed cPanel plugin before 2.4.8, was added to KEV on June 15 with a mitigation deadline of June 18. The vulnerability was addressed in a June 1 update from LiteSpeed. CVE-2026-20262, a medium-severity path traversal vulnerability in the web UI of Cisco Catalyst SD-WAN Manager, was also added to KEV on June 15; it has been assigned a mitigation deadline of June 29. This is the second Cisco SD-WAN Manager vulnerability that has been actively exploited this month. CVE-2026-48907, a critical improper access control vulnerability in the Joomla Content Editor (JCE) extension for Joomla was added to KEV on June 16 with a mitigation deadline of June 19. CVE-2026-20253, a critical Unauthenticated Arbitrary File Creation and Truncation in a PostgreSQL Sidecar Service Endpoint issue in Splunk Enterprise was added to KEV on June 18 with a mitigation deadline of June 21.
Great to see more entries added to the KEV catalog. I'm really curious to see if CISA's push to cut down patch deadlines actually translates to better security posture for FCEB agencies. If forcing a tighter turnaround works for them, there's no reason we shouldn't adopt that same fast-paced cadence as the standard for regular patch management cycles, especially once Fable 5, Mythos 5, and GPT-5.5-Cyber are generally available to the public.

Not all bad news here. The new SD-WAN issue has an update from Cisco which addresses the issue, with no workarounds, so you must apply the update. Similarly, the LightSpeed cPanel Plugin has an update you can apply. Address the Splunk issue by updating to 10.4, 10.2.4 or 10.0.7. Yes, this is the part where I urge you to move to Splunk Enterprise 10.4. If you're on Splunk Enterprise 9, update to 10. If you're running JCE in your Joomla site, update to JCE Pro 2.9.99.6.
NIST
LiteSpeed Tech
NIST
Cisco
The Register
NIST
SC Media
NIST
Splunk
Help Net Security
Research by cybersecurity journalist Zack Whittaker shows that among the 100 highest-revenue companies in the United States, about a third do not have a reporting channel for cybersecurity vulnerabilities. These companies lack what Whittaker characterizes as the "open door" that includes bug bounty programs, formal disclosure programs, web forms, or a dedicated email address, leaving researchers and consumers with no means of escalating issues. This rules out a means for companies to learn about issues and possible risks, and it chills the environment for researchers who may fear legal action or other repercussions for reporting: "Having a way to let people report flaws sends a message to the outside world that the company is willing to be helped, rather than ready to sue someone into silence." Whittaker notes that a basic measure companies can take is to create a security[.]txt file "in a well-known location on a company's domain that contains the best email address for researchers to contact;" only 17 companies in the Fortune 100 currently have this file. While 65 of the companies have a disclosure policy or bug bounty program, nearly half of the bug bounty programs do not offer financial rewards, "despite being run by some of the most revenue-driving companies in the United States." Whittaker recommends companies look into the security[.]txt project by EdOverflow and read Luta Security CEO Katie Moussouris's blog to learn about bug bounties and disclosure programs. Researchers can look for security contact information at disclose.io by Casey Ellis and at findsecuritycontacts.com.

The fact that in 2026 such a large number of Fortune 100 companies still lack a clear vulnerability reporting channel is very disappointing. Implementing a security.txt file, a dedicated reporting address, and a clear disclosure policy are relatively inexpensive measures that can significantly improve an organisation's security posture while fostering constructive engagement with the security community.

Setting aside issues around AI Slop, providing a mechanism for reporting flaws is far better than finding them because you've been breached. If you have a VDP, make sure that you're following current best practices, to include recognition of confirmed problems. If you don't have one, leverage the resources above as well as NIST SP 800-216, Recommendations for Federal Vulnerability Disclosure Guidelines, and CISA's Vulnerability Disclosure Policy Template introduced in Binding Operational Directive 20-01.
I agree that formal vulnerability disclosure channels are important, but you don't always need a full-blown bug bounty program. Many companies handle this effectively through their standard product support platform, provided the support team is properly trained to spot, triage, and route security issues.
This Week in Security
An independent security researcher discovered and disclosed a now-remediated flaw that rendered unchecked control of the entire FIFA World Cup 2026 internal Football Data Platform. The researcher registered a new account in the publicly available FIFA Agent Platform, requiring only an ID and an email address, and noted that the account was also added to FIFA's Microsoft Entra tenant. She tried to log into the Football Data Platform as well and was denied due to insufficient privileges, but discovered that only the client side involved any protection; the backend APIs served "whatever you asked for" without any checks. This included the official live production panel for managing the streaming of every FIFA World Cup 2026 match: controls to start, stop, and schedule video feeds of all camera angles, plus the full infrastructure of live video feed ingest URLs, broadcast output URLs, preview feeds, and stream keys. This could allow a bad actor to push their own video through every official FIFA feed at once — as the researcher noted, "an attacker could have rickrolled the entire FIFA World Cup." Many internal pages could be accessed and modified by an unprivileged account: competitions, matches, teams, tools, an exchange platform, an analysis dashboard, the information system used by live commentators, FIFA AI Pro, admin, and comprehensive data on each match and its officials. An attacker could modify commentary notes and scripts for broadcast, adjust the time of kick-off, or change scores and match statistics. The researcher was also able to access "transfer reports, revenue comparisons, board-level representation data, [and] referee and coach statistics" through an Azure Function App that exposed internal files. The same day, the researcher attempted disclosure via multiple official FIFA emails, WhatsApp, and phone numbers at FIFA, the International Broadcast Centre, and Host Broadcast Services and its parent company, and received no response. Contacts at MediaKind, the US Cybersecurity and Infrastructure Security Agency (CISA), and the FBI took the information, and the next day, the issue was fixed with no acknowledgment from FIFA. The researcher urges FIFA to use a security[.]txt file, publish a vulnerability disclosure policy, enforce authorization beyond the client side, and start a bug bounty program. Major companies' failures to implement vulnerability reporting channels are discussed in another story in this issue of NewsBites.

FIFA were very lucky not to concede an "own goal" with this issue. Any organisation that runs a major international event should realise that their threat profile increases dramatically and therefore they should ensure that adequate security controls are in place and, as stated in story about vulnerability disclosure programs in this issue of NewsBites, have open and transparent channels so those who find security flaws can report them easily.

A couple of takeaways here: First, separation of access. Verify that you're only granting needed access to external users. In the heat of delivery it's easy to talk yourself out of a comprehensive test, but these days the stakes are too high to skip validating security. Second, don't blow off security reports. For every friendly report, assume there are a lot of unfriendly unreported actors attempting to leverage those same flaws.

I hold the nation-state and other advanced adversaries responsible for not discovering this vulnerability first and using it to replace hydration-break commercials with meme videos.
The Texas Parks and Wildlife Department (TPWD) has published a notice disclosing a data security incident affecting a vendor that handles the system for hunting and fishing licenses. No information has been given about the timing or nature of the attack; Texas Cyber Command first alerted the TPWD to the activity, and investigation indicates that data belonging to over 3 million Texans over the age of 18 may have been stolen, including "driver license information, passport numbers (if provided), email addresses, phone numbers and residential addresses." The TPWD asserts that the data did not include Social Security numbers, dates of birth, or financial information, but a disclosure report with the state's Attorney General lists Social Security numbers and dates of birth in the data affected. The department is implementing additional access controls and security features to protect customer information, and is working with the license system vendor to add new safeguards and monitoring. Those affected are offered one year of free credit monitoring through Kroll.

Third party security strikes again. I used to have a schedule for making sure each of our third-party service providers were up to speed when it came to current security settings. This also included making sure we were taking advantage of current security best practices. If you have any sort of Texas hunting or fishing license, regardless of age, make sure that you're on the lookout for people attempting to leverage the breached information. If you don't already have it, take TPWD up on their offered credit monitoring.
TPWD
Texas OAG
SecurityWeek
BleepingComputer
The Register
TechCrunch
In May 2024, the Canadian Security Intelligence Service (CSIS) obtained a warrant to access servers, home routers, and Internet of Things (IoT) devices infected with malware to "neutralize two foreign-run botnets." The devices CSIS accessed were all on Canadian soil. "CSIS required the Cyber Threat Reduction Measures Warrant because the necessary threat reduction measures to neutralize the botnets, which are targeted at the devices, would likely constitute offences pursuant to the Criminal Code, RSC 1985, c C-46 [Criminal Code] and, as such, require judicial authorization in accordance with subsection 12.1(3.4) of the CSIS Act." Canada's Federal Court released a public version of the warrant on June 15, 2026. The Cyber Threat Reduction Measures Warrant was the first warrant of its kind to be issued in Canada. The warrant was granted on May 1, 2024 for a period of 120 days, and renewed for an additional 120 days on August 29, 2024.
Kudos to Canada’s intelligence establishment on the successful takedown. However, the reality is that these devices are probably still online, still vulnerable, and just sitting there waiting for the next botnet herder to compromise them again. Hopefully owners patch them before they get weaponized a second time.

Interesting compromise. Do you wait for consumers to clean infected devices in a fast-moving attack, or do you clean or isolate them for you to turn the tide? In this case, Canada obtained permission to intervene, and that permission was kept off the radar so the threat actors would not catch on. Problem is, reaching into privately owned devices and wiping data, including cleanup of malware, is considered criminal mischief under Canada's criminal code, so they needed the court's sign-off. This is similar to the FBI's efforts in 2023 to wipe the KV-botnet malware from US SOHO routers. The main difference is that the DOJ & FBI were operating under search-and-seizure authority as law enforcement agencies, while CSIS is an intelligence service operating under a threat reduction measure to actively disrupt a threat, rather than just collect intelligence on it — a recent power which went into effect in 2019, unused before now. It will be interesting to see how this is used in the future.

This case demonstrates how legal frameworks are evolving to allow authorities to intervene directly against cyber threats. However, such powers inevitably raise important questions around oversight, proportionality, transparency, and public trust. Striking the right balance between security and civil liberties will remain an ongoing challenge for policymakers worldwide.
City News Halifax
The Hacker News
FTC-CF Canada
Canadian power utility company London Hydro has disclosed that it experienced a "data security incident" that may have compromised personal data related to certain accounts. The utility first noticed suspicious activity on a customer account on Thursday, June 18; "the account was used to exploit a system vulnerability, which allowed access to certain information about other customers." London Hydro says it began notifying affected individuals on Friday, June 19, but has provided little additional information about the scope and impact of the incident, not specifying whether the incident affected its operational technology. The company provides electricity to more than 160,000 people in the London, Ontario area.

This appears to be a customer data breach and not an operational technology incident. The initial access reportedly came through a customer account that was used to exploit an application vulnerability. This serves as a reminder that protecting customer portals requires more than strong passwords; the applications themselves must be designed and tested to prevent one account from becoming a pathway to broader data exposure.

One of the biggest challenges during any cyber incident is not just understanding what happened, but understanding what needs to be reported, to whom, and when. Regulations such as the EU GDPR, EU NIS2, and EU DORA all have different notification requirements and timelines. Organisations operating within the EU should ensure these obligations are understood and incorporated into their incident response plans long before an incident occurs, as well as the reporting obligations for other jurisdictions and industry sectors.

It's great that London Hydro published a breach notification that let customers know what of their information was breached, and provided information on actions customers should take to protect themselves, to include a banner at the top of their website. However, they overlooked disclosing the impact on services, if any, caused by the event. Even if your incident has no impact on services and delivery, you need to state that.
Over the weekend, Brazil took the country's Public Alert Dissemination Interface (IDAP) system offline after a breach of the country's national emergency alert system allowed it to be used to send false emergency messages to mobile phones in the Brazilian states of São Paulo, Mato Grosso do Sul, Rio de Janeiro, Paraná, and the Federal District. "As an immediate response to contain the attack, the National Secretariat for Civil Protection and Defense (SEDEC) blocked all external access to IDAP and suspended the accounts of users involved in the incident, in addition to preserving system logs and logins for forensic analysis. The Government's Center for Prevention, Treatment and Response to Cyber Incidents (CTIR Gov) was also notified to monitor the case." Brazil's Ministry of Integration and Regional Development (MIDR) is investigating.

While the details are sketchy, consider this equivalent to someone sending a fake Amber Alert in the US. To add insult to injury, Brazil's Civil Defense Agency is in the process of developing a new dispatch system which has a greater emphasis on security and preventing unauthorized intrusions. While it may not seem like it, they are taking the pragmatic approach of working to clean and prevent recurrence on the existing system so it can be returned online, rather than disrupting the development of the new system, which could result in other security or function issues. When developing a replacement system, have conversations about this scenario, then stick to those decisions if the need arises.
SANS Internet Storm Center StormCast Tuesday, June 23, 2026
Webshells; GitHub Actions Update; FortiBleed Update; Private Access Control Tokens
https://isc.sans.edu/podcastdetail/9982
Webshells Remain Popular
https://isc.sans.edu/diary/Webshells+Remain+Popular/33096
Safer pull_request_target defaults for GitHub Actions checkout
Private Access Control Tokens
https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/
Fortibleed Update
SANS Internet Storm Center StormCast Monday, June 22, 2026
IPv4 Mapped Phish; NGINX Bug; Squidbleed; AMD Encryption Fix
https://isc.sans.edu/podcastdetail/9980
eBanking Phishing Delivered Through IPv4-Mapped IPv6 Address
https://isc.sans.edu/diary/eBanking+Phishing+Delivered+Through+IPv4Mapped+IPv6+Address/33090
NGINX ngx_http_v3_module vulnerability CVE-2026-42530
https://my.f5.com/manage/s/article/K000161616
Squidbleed (CVE-2026-47729)
https://blog.calif.io/p/squidbleed-cve-2026-47729
AMD will reinstate memory encryption on Ryzen 9000 CPUs through a BIOS update in July
SANS Internet Storm Center StormCast Thursday, June 18, 2026
QUIC Challenge; Android 17; Oracle CSPU; JetBrains Plugins
https://isc.sans.edu/podcastdetail/9978
The browser blind spot: Why your security tool may not be blocking what you think it is [Guest Diary]
Android 17 Security Patches
https://source.android.com/docs/security/bulletin/android-17
Oracle Critical Security Patch Update Advisory - June 2026
https://www.oracle.com/security-alerts/cspujun2026.html
Multiple JetBrains IDE plugins caught stealing AI keys
https://www.aikido.dev/blog/multiple-jetbrains-ide-plugins-caught-stealing-ai-keys
SANS Internet Storm Center StormCast Wednesday, June 17, 2026
VHDX to Remocs RAT; Fake Job Offer; OpenBSD Vuln; Copilot M365 Leakage
https://isc.sans.edu/podcastdetail/9976
From a VHDX File to a Remcos RAT
https://isc.sans.edu/diary/From+a+VHDX+File+to+a+Remcos+RAT/33080
A backdoor in a LinkedIn job offer
https://roman.pt/posts/linkedin-backdoor/
A 27-Year-Old Authentication Bypass in OpenBSD's PPP Stack
https://blog.argus-systems.ai/blog/openbsd-pap-27-year-auth-bypass.html
Copilot M365 Data Leakage
https://www.varonis.com/blog/searchleak
My Upcoming Classes
Catch up on recent editions of NewsBites or browse our full archive of expert-curated cybersecurity news.
How are security teams approaching AI in 2026? The State of AI Cybersecurity 2026 examines AI adoption, emerging threats, governance challenges, and the evolving role of AI in cyber defense. Get the report to access research-backed insights and learn how organizations are preparing for the next phrase of AI-driven security
Webinar | Agentic CTI Automation For Fun and Profit | Thursday, June 25 | Rebekah Brown & Jonathan Cran
Webinar | The Strategic Case for Web Traffic Inspection Beyond the Endpoint | Tuesday, June 23 | Aaron Cure & Dori Varas
SANS Demo Day 2026 | Wednesday, June 24, 10AM - 5PM EDT | See cutting-edge cybersecurity tools in action, compare solutions side by side, and gain expert insights to make smarter, faster security decisions for your organization