Fortinet Warns of Attackers Gaining FortiGate Access Via Now Patched Vulnerabilities
Fortinet has revealed that threat actors have now found a way to leverage multiple patched FortiGate vulnerabilities to maintain read-only access to devices after exploiting initial access vectors to breach devices.
The attackers are believed to have exploited known patched vulnerabilities tracked as CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762.
CVE-2022-42475 (CVSS 9.8):
EPSS Score: 92.86%
100% Percentile (Top 0%)
Exploitability Score: 3.9
Impact Score: 5.9
A heap-based buffer overflow vulnerability [CWE-122] in FortiOS SSL-VPN 7.2.0 through 7.2.2, 7.0.0 through 7.0.8, 6.4.0 through 6.4.10, 6.2.0 through 6.2.11, 6.0.15 and earlier and FortiProxy SSL-VPN 7.2.0 through 7.2.1, 7.0.7 and earlier may allow a remote unauthenticated attacker to execute arbitrary code or commands via specifically crafted requests.
CVE-2023-27997:
EPSS Score: 87.33%
99% Percentile (Top 1%)
Exploitability Score: 3.9
Impact Score: 5.9
A heap-based buffer overflow vulnerability [CWE-122] in FortiOS version 7.2.4 and below, version 7.0.11 and below, version 6.4.12 and below, version 6.0.16 and below and FortiProxy version 7.2.3 and below, version 7.0.9 and below, version 2.0.12 and below, version 1.2 all versions, version 1.1 all versions SSL-VPN may allow a remote attacker to execute arbitrary code or commands via specifically crafted requests.
CVE-2023-21762
EPSS Score: 90.72%
100% Percentile (Top 0%)
Exploitability Score: 3.9
Impact Score: 5.9
An out-of-bounds write in Fortinet FortiOS versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.6, 7.0.0 through 7.0.13, 6.4.0 through 6.4.14, 6.2.0 through 6.2.15, 6.0.0 through 6.0.17, FortiProxy versions 7.4.0 through 7.4.2, 7.2.0 through 7.2.8, 7.0.0 through 7.0.14, 2.0.0 through 2.0.13, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6, 1.0.0 through 1.0.7 allows attacker to execute unauthorized code or commands via specifically crafted requests
“A threat actor used a known vulnerability to implement read-only access to vulnerable FortiGate devices,”, Fortinet stated in an advisory released regarding the exploits. Fortinet stated that this was achieved via the attacker creating a symbolic link between the user file system and root file system in a folder used to serve language files for the FortiGate VPN.
The modifications took place within the user file system and managed to evade detection, which caused the symlink to be left behind despite the security flaws being patched. This then allowed the threat actors to maintain read-only access to the targets devices file system, which included the system configuration files. It is important to note that users that have never enabled FortiGate SSL-VPN are not impacted by this.
Fortinet have stated that the investigation into this activity has not highlighted any specific industries or countries being targeted by the4se attacks. Fortinet has notified all affected customers, and advised all affected users to apply the latest product patches seen below:
FortiOS 7.4, 7.2, 7.0, and 6.4 – The symlink was flagged as malicious so that it gets automatically removed by the antivirus engine
FortiOS 7.6.2, 7.4.7, 7.2.11, 7.0.17, and 6.4.16 – The symlink was removed and SSL-VPN UI has been modified to prevent the serving of such malicious symbolic links
New Phishing Techniques Allow Attackers to Vet Victims in Real-Time
Phishing threat actors are now employing a new evasion tactic labelled “Precision-Validated Phishing” that only shows fake login forms when a target user enters an email address that the threat actors are specifically targeting. What sets this new technique apart from the traditional en masse phishing campaigns, is that this new technique uses real-time email validation to show phishing content to only pre-verified targets.
While this technique may sound advanced, the reality is that this technique works simply by excluding all non-targets from the phishing process, essentially blocking their visibility into the phishing process.
The use of this technique also makes research into these attacks difficult. Usually, when investigating phishing campaigns, it is common for researchers to utilise fake email addresses to simulate what occurs during the phishing process. However, since this phishing technique only targets predetermined users, the use of fake emails will redirect researchers to benign sites or flag errors. This also affects the effectiveness of automated security crawlers and sandboxes, as these will have a harder time detecting phishing links utilising this technique.
Cofense, an email security firm, has documented the rise of this technique and has identified two main techniques utilised to achieve the real-time email validation. The first involves abusing third-party email verification services and integrating them into the phishing kit, as this checks the validity of the target’s email address in real-time using API calls. The second method deploys a custom JavaScript into the phishing page, which pings the attacker’s server with a list of email addresses provided by victims entering their details on the site, which then checks the emails with the pre-harvested list on the attacker server. If there is a match, the target user will be directed to the phishing site. If not, then the user will be redirected to a benign site.
It is reported that some campaigns have added even more steps to ensure that security researchers cannot replicate the steps of the attack by using a previously targeted email. Some of the campaigns observed utilise a pseudo two-step verification for their phishing, where the user will receive a code in their inbox, which they then input back into the site to confirm.
With the implementation of dynamic input validation, it is becoming harder and harder to detect phishing attacks. The Human Risk Management module from Norm can educate users on how to spot a likely malicious link. With this education, not only would users be more aware of the tactics used by attackers but also the content will enable them to exercise caution when clicking on suspicious links. It is also recommended to take a minute to assess a link before clicking and never give any remote access to your device.
Oracle Finally Confirms Data Breach from March 2025
Oracle has finally confirmed a significant data breach that saw the theft of legacy client login credentials that first came to light in March 2025. After previously denying the compromise, Oracle is now reportedly informing select customers of the intrusion that impacted outdated systems, which reportedly included data dated as recently as 2024.
In March 2025, a user under the alias of “rose87168” made a post on BreachForums, stating that they were selling 6 million Oracle customer records, which they had obtained via a breach to Oracle systems. Oracle insisted that there was no data compromise and dismissed any claims of such, reassuring customers that Oracle Cloud systems remained uncompromised. However, multiple cyber security firms have since validated the authenticity of the leaked data, which included usernames, encrypted SSO and LDAP credentials, Java Keystore files and JPS keys.
According to those briefed during Oracle’s internal investigation, the attack had targeted a legacy environment which was not used in active services and was decommissioned eight years ago. However, this was also put into question after a source familiar to the breach indicated that some of the stolen data was dated as recently as 2024. This then raised more questions to Oracle regarding their handling of the legacy data retention and the internal system segmentation.
The attack appears to have originated from exploiting a vulnerability within Oracle’s Gen 1 cloud infrastructure, which was followed shortly by a webshell and malware deployment into Oracle’s Identity Management (IDM) database, which allowed the attacker to exfiltrate sensitive authentication data. It was reported that the breach likely began back in January 2025 via the exploitation of a Java vulnerability within the Oracle infrastructure, and that Oracle became aware of the suspicious activity some time in February, shortly before the first ransom in March.
The attacker appeared publicly on 5th March 2025 and has since demanded a ransom from Oracle of $20 Million. However, the threat actor also showed a willingness to barter for the stolen data, specifically looking for zero-day exploits which suggests that their motivations may have been more than just financial.