Red Hat in the news, £5.5B in Bitcoin recovered from scammer, more Breaches
Hello! ArvinF is your editor of the F5 SIRT This Week in Security, covering 28 September to 4 October 2025. This week, Red Hat is in the news for their Consulting GitLab instance breach and an "Important" rated vulnerability in their OpenShift AI Service product. A win - UK's Metropolitan police have arrested a scammer and recovered £5.5B (!) in Bitcoin. Then came the breach disclosures from Alianz, Westjet, Motility and a "US tech company”. Finally, the ransomware and extortion gangs - Scattered LAPSUS$ Hunters 1B Salesforce record under ransom and Radiant Group's extortion attempt getting slammed by another extortion group. Let’s get to it! Red Hat's Consulting GitLab instance has been breached by an extortion group named Crimson Collective. The group initially bragged about the breach on Telegram, showing file listings and other sensitive data in Customer Engagement Reports (CERs) that are related to Redhat customers environments. Redhat published a security incident advisory: We recently detected unauthorized access to a GitLab instance used for internal Red Hat Consulting collaboration in select engagements. Upon detection, we promptly launched a thorough investigation, removed the unauthorized party’s access, isolated the instance, and contacted the appropriate authorities. Our investigation, which is ongoing, found that an unauthorized third party had accessed and copied some data from this instance. Crimson Collective threat group notes that they found authentication tokens inside these repos and have “already used these to compromise downstream Red Hat customers.” In an advisory from the Belgian government, it notes the incident is “High Risk” for Belgian organizations and has “potential supply chain impact if service providers or IT partners worked with Red Hat Consulting” From the same advisory, it provided recommendations: Revoke & Rotate all tokens, keys, and credentials shared with Red Hat or used in integrations. Engage Third-Parties – ask your IT providers or partners whether they have used Red Hat Consulting and assess your potential exposure. Contact Red Hat for guidance on your specific exposure. Increase monitoring of authentication events, API calls, and system access for anomalies. https://www.theregister.com/2025/10/03/red_hat_gitlab_breach/ https://www.redhat.com/en/blog/security-update-incident-related-red-hat-consulting-gitlab-instance https://www.theregister.com/2025/10/02/cybercrims_claim_raid_on_28000/ https://ccb.belgium.be/news/hackers-crimson-collective-use-leaked-authentication-tokens-access-customer-systems From standard user to Full Cluster Admin in Red Hat Openshift AI Service via CVE-2025-10725 Red Hat OpenShift AI Service has a 9.9 out of 10 CVSS Score CVE, tracked as CVE-2025-10725, thinly avoiding a 10 out of 10, due to a requirement of a Low-Privileged attacker. https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H In the advisory: A flaw was found in Red Hat OpenShift AI Service. A low-privileged attacker with access to an authenticated account, for example as a data scientist using a standard Jupyter notebook, can escalate their privileges to a full cluster administrator. This allows for the complete compromise of the cluster’s confidentiality, integrity, and availability. The attacker can steal sensitive data, disrupt all services, and take control of the underlying infrastructure, leading to a total breach of the platform and all applications hosted on it. To resolve the vulnerability, upgrade to RHOAI 2.16.3 or if Kueue features are not required, the Kueue component management state can be set to “Removed” in the RHOAI DataScienceCluster resource. For RHOAI 2.19+, a workaround is Prevent the RHOAI operator from managing the kueue-batch-user-rolebinding then Disable the ClusterRoleBinding by updating its subject to a different, non-existent, group. Once updates providing fixes have been applied, it's recommended to remove the clusterrolebinding. This “Important” rated CVE came out approx the same time as the Red Hat Consulting GitLab breach. https://www.theregister.com/2025/10/01/critical_red_hat_openshift_ai_bug/ https://access.redhat.com/security/cve/cve-2025-10725#cve-affected-packages £5.5B in Bitcoin recovered from scammer A scammer caught by the London Metropolitan Police after a seven-year investigation and recovered a record-busting Bitcoin seizure worth £5.5B. .. carried out what the police describe as a "large-scale fraud in China" between 2014 and 2017, and then attempted to launder the significant proceeds after arriving in the UK. The three-year fraud affected more than 128,000 people and netted 61,000 Bitcoin, which at current prices is worth more than £5.5 billion ($7.4 billion). At the point the crypto tokens were seized, they would have been worth around $404 million. The scammer fled using false documents and entered the UK and attempted to launder the stolen money by buying property, said the Met. An associate helped in attempting to cash in on the laundering by buying properties in the UK and Dubai. This associate was caught last year and was jailed/sentenced. The scammer may get additional time if they fail to pay up and return more than £3.1 million. The Crown Prosecution Service said the associate benefited by £3.5 million (c $4.7 million) from the fraud, led by the scammer, and the £3.1 million figure was the total sum of her available assets at the time. Reforms to crime legislation under the previous Conservative government aimed to make it easier for the UK authorities to seize, freeze and recover crypto assets, external. The changes would also allow some victims to apply for the release of their assets held in accounts. https://www.theregister.com/2025/09/30/met_police_bitcoin_fraud/ https://www.bbc.com/news/articles/cy0415kk3rzo https://news.met.police.uk/news/woman-convicted-following-worlds-largest-seizure-501569 https://www.gov.uk/government/news/new-powers-to-seize-cryptoassets-used-by-criminals-go-live 3.7M breach notification letters - The mailman and mail servers will be busy sending breach notification letters. From the Maine AG breach disclosure pages on affected persons: Insurance biz Allianz Life - 1,497,036 WestJet - 1.2 million Motility - 766670 From the news ... "US tech company" - 250,000 The Impact: Allianz Life - The attackers accessed the data of the insurer's customers, staff, and financial professionals WestJet - affected its online services and mobile app, exposed customer data - could include names, contact details, information and documents provided in connection with their reservation and travel, and data regarding victims' Motility Software Solutions - "unauthorized actor deployed malware that encrypted a portion of our systems. Although the malware primarily restricted our access to internal data, the forensic evidence suggests that, before encryption, the actor may have removed limited files containing customers' personal data ... could include full names, home and email addresses, telephone numbers, dates of birth, SSNs, and driver's license numbers." That’s a lot of names, SSNs, CCs, email addresses, addresses, IDs. All three businesses offered identity protection and credit monitoring services – Allianz Life and WestJet two years of coverage, Motility 12 months. https://www.theregister.com/2025/10/01/north_american_data_breaches/ Scattered LAPSUS$ Hunters 1B Salesforce Records under ransom Scattered LAPSUS$ Hunters gave Salesforce until October 10, a deadline to negotiate payment or leak their customer’s data. Scattered LAPSUS$ Hunters are 3 threat / ransomware groups - Scattered Spider, ShinyHunters, and Lapsus$ - that had a moment of solidarity "to break into businesses' networks, steal their data, and force an extortion payment." Per Salesforce advisory: "We are aware of recent extortion attempts by threat actors, which we have investigated in partnership with external experts and authorities," "Our findings indicate these attempts relate to past or unsubstantiated incidents, and we remain engaged with affected customers to provide support," "At this time, there is no indication that the Salesforce platform has been compromised, nor is this activity related to any known vulnerability in our technology." In August of 2025, there was the Salesloft drift breach that affected Salesforce customers. https://www.theregister.com/2025/10/03/scattered_lapsus_hunters_latest_leak/ https://www.theregister.com/2025/09/14/in_brief_infosec/ https://www.theregister.com/2025/09/08/drift_breach_entry_salesloft_github/ https://www.theregister.com/2025/08/12/scattered_spidershinyhunterslapsus_cybercrime_collab/ https://status.salesforce.com/generalmessages/20000224?locale=en-US Radiant Group extortion gang crosses the line and gets schooled by other ransomware groups Radiant Group stole data from Kido International, a school for young children with branches in the UK, US, and India. They then posted unblurred pictures of 10 children, along with their addresses, parents’ names, and other personal data, and threatened to expose more if a ransom wasn't paid. Parents of some children claimed to have received threatening calls after Radiant published the data. London's Metropolitan Police investigators are following up on the case. But now, Radiant says it removed the child data it had posted after receiving pressure from other ransomware groups. It seems they crossed a line in the criminal world and backed down when called out for it. Rebecca Taylor, a threat intelligence knowledge manager at security biz Sophos, tells The Register that the crew was called out by the well-established ransomware-as-a-service Nova gang on the Russian Anonymous Market Place (RAMP), an online souk for cybercriminals. One of Nova's affiliate members, going under the handle BlackBeard, told Radiant, "reputation important, don't attack child right." "We have disabled any attacks relating to them, is not allowed anymore," Radiant answered, and added, "Any data relating to under 18s who attended have been deleted." BlackBeard congratulated them and wished the extortionists good luck for the future and Nova offered to help in future raids. Radiant claimed to have information on over 8,000 children enrolled at Kido, as well as their family, teachers, and staff. Taylor told us that the Radiant Group seems to be new script kiddies on the block and have overstepped themselves, and are now trying to make nice with the rest of the criminal community. https://www.theregister.com/2025/10/02/ransomware_radiant_delete_kids_info/ https://www.theregister.com/2025/09/25/ransomware_gang_publishes_toddlers_images/ https://www.theguardian.com/technology/2025/oct/02/kido-nursery-hackers-say-they-have-deleted-stolen-data Outro The amount of breach news from this week was something - the leaked personal and financial information will surely be the foundation of future breaches and extortions. These breaches were perpetrated by ransomware and extortion gangs that utilized social engineering and known and unknown vulnerabilities in their campaigns. As defenders, we should advise our organizations to keep our systems updated, implement levels and layers of security defenses and keep ourselves and our peers educated on good security practices. The silver lining is the recovery of the £5.5B worth of Bitcoin from scammers caught in the UK. The many victims of scammers have an opportunity to recover their lost assets. Credit to the original source and posts! I hope the news I picked is informative and educational. Till next time - Stay Safe and Secure! As always, if this is your first TWIS, you can always read past editions. We also encourage you to check out all of the content from the F5 SIRT.Security Best Practices for F5 Products
My colleagues previously wrote this article as a security best practice guidance for BIG-IP and BIG-IQ. This is an updated overview of key recommendations and not an exhaustive list of steps for securing an F5 product. I’ve also included updates to keep it relevant including newly published product hardening guides. These include: K53108777: Hardening your F5 system and K45321906: Harden your BIG-IQ system along with the two newly published K000156803: Hardening NGINX and NGINX Plus and K000156807: Secure the AOM subsystem. Regarding BIG-IP, the F5 SIRT team recently collaborated with the F5 iHealth team to create new diagnostic heuristics that align with these hardening best practices. These heuristics are now included in the Security tab of QKViews under a new "Security Best Practices" panel. You can also filter the alerts in the Diagnostics tab to show "Security_best_practices". Beyond these resources, there is extensive documentation available on MyF5 detailing specific steps for configuring functionality, though many are version-specific due to changes and enhancements across major releases. The most relevant links for configuration can usually be found within the hardening guides listed above. Additionally, F5 documentation occasionally refers to the "control-plane" and "data-plane." The control-plane includes all methods for managing a device or installation, such as the Web UI (TMUI), iControl REST, iControl SOAP, SSH, and related daemons like big3d and bigd. The data-plane, on the other hand, refers to all constructs that handle user traffic, such as Virtual Servers, NATs, SNATs, and other similar components. Going forward, references in this context will pertain to these constructs. Step 1: Minimize access to the control-plane It is crucial to implement sound security practices for any system, especially those in privileged network positions like BIG-IP or edge firewalls. One fundamental principle is keeping the control-plane off the internet whenever possible, with limited exceptions such as big3d communications between BIG-IP DNS and BIG-IP LTM devices that may traverse the internet. Ideally, access to the control-plane should be restricted solely to authorized IT staff. Measures should be taken to control access to control-plane services (such as SSH, HTTP, and SNMP) to ensure traffic only comes from expected hosts, as outlined in K13092: Overview of securing access to the BIG-IP system and 10 Settings to Lock Down Your BIG-IP. Adding pre-login and post-login banners is another effective security step, as they can help enforce security policies—such as informing users that activities are logged—or notify users of system updates like scheduled maintenance. Guidance for configuring banners can be found in K6068: Configuring a pre-login or post-login message banner for the BIG-IP or Enterprise Manager system and K71515276: Configuring a pre-login or post-login message banner for the BIG-IQ system. Ideally, control-plane access should be managed via a management DMZ, and additional restrictions on lateral movement within the DMZ can be enforced through micro-segmentation or the use of on-device controls. For BIG-IP, these on-device controls were notably enhanced in version 14.1 and above with a robust management interface firewall. Access to the management DMZ itself should be through a jump box or VPN with 2FA enabled. Jump boxes provide a dedicated and secure environment for administrative tasks, offering substantial protection against attacks like XSS and CSRF, because administrators will use them solely for device administration rather than general browsing or other activities. In the absence of this infrastructure, using a local virtual machine or dedicated browser for administrative duties is still recommended to mitigate risks from phishing-delivered XSS and CSRF attacks. While changes to network design to accommodate a management DMZ may take time, the on-device management interface firewall can be implemented independently, along with a mandate for more secure administrative environments. Several articles provide guidance for minimizing access to the control-plane, including K5380: Specify allowable IP ranges for SSH access, K11719: Mitigating risk from SSH brute-force login attacks, K13309: Restricting access to the Configuration utility by source IP address (11.x–17.x), K9908: Configure an automatic logout for idle sessions, and K75211108: Configure automatic logout for idle sessions on the BIG-IQ system. Furthermore, articles like K80425458: Modifying the list of ciphers and MAC and key exchange algorithms used by the SSH service on BIG-IP or BIG-IQ systems, K92748202: Restrict access to the BIG-IQ management interface using network firewall rules, and K31401771: Restricting access to the BIG-IQ or F5 iWorkflow user interface by source IP address provide additional strategies for securing critical management interfaces. Step 2: BIG-IP Management and Self IPs To enhance security, ensure that all Self IPs are set to "Lockdown None" to prevent the exposure of control-plane services unless explicitly required. If a service such as big3d (port 4353) needs to be exposed, carefully restrict access to only the specific ports required. For dedicated management VLANs and non-routable HA VLANs, the "Allow Default" setting can be used, though it is recommended to allow only specific ports whenever possible for tighter access control. Relevant guidance can be found in K17333: Overview of port lockdown behavior (12.x–17.x), K39403510: Managing the port lockdown configuration on the BIG-IQ system, and K15612: Connectivity requirements for the BIG-IQ system. Out-of-band management via a dedicated interface or VLAN is strongly recommended for optimal security. This can be implemented using the hardware platform’s dedicated management interface or a dedicated management VLAN on production interfaces when a dedicated management interface is unavailable, such as in single-NIC cloud deployments. Step 3: Hardening the BIG-IP To improve security, consider using a Hardware Security Module (HSM) for storing sensitive information such as SSL keys. Options like an onboard FIPS HSM or NetHSM offer a high level of protection, while the built-in SecureVault functionality can provide additional security by making SSL key recovery more difficult for unauthorized users who gain access to the BIG-IP’s control plane. For more details about SecureVault, F5 offers a knowledge base article: K73034260: Overview of the BIG-IP system Secure Vault feature. Additionally, reduce your attack surface by provisioning modules only as needed instead of upfront, which can also decrease the frequency of applicable Security Advisories. For further access restriction, appliance mode is another option designed to limit BIG-IP administrative access, making it behave more like a typical network appliance rather than a multi-user UNIX device (K12815: Overview of Appliance mode). For authentication, the BIG-IP control-plane should integrate with enterprise-grade AAA solutions such as RADIUS, TACACS+, or LDAP, as these bring administrative accounts under pre-existing enterprise security practices. However, note that root and admin passwords are available as fallback authentication, so these should be configured with strong, secure passwords. Guidance for setting up AAA solutions can be found in articles such as K8811: Configuring TACACS+ authentication for BIG-IP administrative users, K11072: Configuring LDAP remote authentication for Active Directory, K17403: Configuring RADIUS authentication for administrative users, and corresponding BIG-IQ articles like K31586420: Configuring the BIG-IQ system to use TACACS+ based authentication and authorization, K00153876: Enabling LDAP remote authentication for Advanced Shell access to the BIG-IQ system, and K51458353: Configuring the BIG-IQ system to use RADIUS authentication. If remote authentication is not being used, it is essential to enforce a strong password policy for local accounts on the BIG-IP or BIG-IQ systems. Several articles on MyF5 provide detailed instructions for locking down authentication on F5 devices, including K15497: Configuring a secure password policy for the BIG-IP system, K13121: Changing system maintenance account passwords, K4139: Configuring the BIG-IP system to enforce the use of strict passwords, K32203233: The root and admin accounts are now subject to the enforcement restrictions of the secure password policy, K12173: Overview of BIG-IP administrative access controls, and K49507549: Configuring a secure password policy for the BIG-IQ system. For systems running BIG-IP 15.0.0 or later, remote APM authentication can be used to manage control-plane access while also implementing two-factor or multi-factor authentication (2FA/MFA) using the APM system. For further details, see https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-local-traffic-manager-implementations/implementing-apm-system-authentication.html . Step 4: Monitoring To maintain comprehensive security and monitoring, it is recommended to configure off-box syslog, ideally directed to a SIEM, to ensure you have a reliable and immutable record of events such as configuration changes, potential indicators of compromise, and system issues. Alerts based on these logs can be set up to monitor critical events in real-time. Additionally, consider utilizing SNMP traps and polling to keep track of system performance and load while monitoring for potential attack indicators against the data-plane, such as denial of service (DoS) attacks. Regularly uploading qkviews to iHealth is another beneficial practice—unless restricted by enterprise security policies—as iHealth’s built-in heuristics can identify potential device misconfigurations, vulnerabilities specific to your version, hardware, or configuration, and any indicators of compromise within your system. This process can be automated via BIG-IQ, which also has the capability to automate regular configuration snapshots. For enhanced awareness of system access, refer to resources such as K13426: Monitoring login attempts (11.x–17.x) and K08662997: Monitoring login attempts on the BIG-IQ system. Step 5: Maintaining It is highly recommended to run a recent software release, ideally within the last two LTS (Long-Term Support) branches, as F5 continuously enhances functionality to address new attack vectors and ensure rapid adoption of security fixes. While some customers opt for engineering hotfixes to resolve specific issues, it is advised to migrate back to a mainline branch as soon as the necessary fixes are incorporated to minimize time-to-patch for newly discovered defects or vulnerabilities. Useful references include K9957: Creating a custom RSS feed to view new and updated documents, K2200: Most recent versions of F5 software, K9502: BIG-IP hotfix and point release matrix, and K15113: BIG-IQ hotfix and point release matrix. To stay informed about significant vulnerabilities, customers should subscribe to the F5 Security mailing list to receive alerts for critical vulnerabilities, including Quarterly Security Notifications (QSNs) and out-of-band notifications for high-impact third-party vulnerabilities. For more information about the QSN process and scheduling, consult K67091411: Guidance for Quarterly Security Notifications and K9970: Subscribe to email notifications regarding F5 products and security announcements. Additionally, reporting software issues—whether security-related or not—ensures the continuous improvement of F5 software. Any issues reported to F5 allow developers to address them promptly, facilitating early fixes. Resources such as K4602: Overview of the F5 security vulnerability response policy and K4918: Overview of the F5 critical issue hotfix policy provide more insights into how F5 handles reported vulnerabilities. Regular backups of your devices are another critical aspect of maintaining security and stability. Backups ensure you have a reliable, uncompromised configuration to restore in case a device needs reimaging. BIG-IQ can assist in automating this process, but it is crucial to thoroughly test and validate backup scripts to ensure they capture valid data and do not unintentionally delete necessary files during backup rotation. Step 6: Recovery Although compromise is relatively uncommon, adhering to the outlined security steps and best practices can significantly reduce the likelihood of it occurring. However, preparation is critical to ensuring a successful recovery should a compromise take place. Since recovery efforts often involve multiple departments within an organization, having a documented recovery plan is essential. At a minimum, the plan should address key areas such as how to isolate the compromised device. For example, if a device pair is compromised, should a potentially compromised box remain online and serve customers despite serious implications like PCI or GDPR noncompliance? Does your application delivery design allow you to continue serving customers after losing a device pair, or should you activate Disaster Recovery? The plan should also define when and how devices can be reintroduced into service. If company policy requires devices to be held for forensic analysis, ensure you have spare devices available to maintain uninterrupted service. Include steps for reimaging devices from scratch and recovering configurations from backups, as well as revoking and replacing potentially compromised SSL keys. Additionally, consider other secrets that might need to be replaced, such as RADIUS, TACACS, or SNMP credentials. Although this level of preparation may seem burdensome, having these discussions in advance is far easier than making critical, service-impacting decisions under pressure. Moreover, your recovery plan should not be limited to only your F5 systems but should account for broader infrastructure. For additional guidance, refer to K11438344: Considerations and guidance when you suspect a security compromise on a BIG-IP system. Step 7: Secure Against Brute Force and Application Attacks Protecting your F5 system is only part of securing your network; it is equally important to protect the applications and application servers that sit behind it. F5 systems can be configured in numerous ways to provide protection not only for the system itself but also for your applications. Starting at the lower layers, protections can be implemented using TCP profiles or by adding additional modules like F5’s Advanced Firewall Manager (AFM). AFM is a high-performance, stateful, full-proxy network firewall designed to safeguard data centers from incoming threats. It supports widely used protocols such as HTTP/S, SMTP, DNS, SIP, and FTP. For further guidance, consult resources such as K25301105: Mitigate HTTP SLOWRead attacks, K37718515: Investigating BIG-IP AFM attack vector logs and tuning the DoS Vector Attack Type, and K41305885: BIG-IP AFM DoS vectors. At higher layers, HTTP applications can be protected using a Web Application Firewall (WAF). F5 offers several WAF solutions, including Distributed Cloud, NGINX App Protect WAF, and Advanced WAF/ASM. With the increasing complexity of web applications, adding a WAF has become essential. A WAF provides significant mitigation capabilities and can be configured to protect against emerging attacks, offering robust defenses against threats such as authentication attacks and brute-force attempts. For additional information, refer to K07359270: Succeeding with application security, K15405450: Overview of web scraping detection, K18650749: Configuring brute force attack protection (13.1.0 and later), and K14199: Determining if the BIG-IP ASM system has detected and prevented a Slow HTTP POST DDoS attack. Implementing these layers of protection ensures comprehensive security for both your F5 systems and the applications they support. Step 8: Prevent Data Leakage The BIG-IP system offers several HTTP protections even without utilizing a Web Application Firewall (WAF). For example, HTTP cookies can be encrypted to prevent the exposure of sensitive data, ensuring better security for client-server communication. Additionally, the BIG-IP system can be configured to remove sensitive HTTP response headers that might otherwise reveal information about the backend server, thereby reducing the risk of information leakage. Furthermore, an HTTP profile can be configured to enable Layer 7 inspections, ensuring that clients remain RFC compliant. These features collectively help safeguard against the leakage of sensitive data and enhance the overall security of HTTP transactions. For additional details, refer to resources such as K6917: Overview of BIG-IP persistence cookie encoding, K14784: Configuring cookie encryption within the HTTP profile, K23254150: Configuring cookie encryption for BIG-IP persistence cookies from the cookie persistence profile, and K40243113: Overview of the HTTP profile. Summary As noted earlier, this list is not exhaustive and should be considered within the context of your organization's existing guidelines for securing, monitoring, and maintaining systems, as well as any disaster recovery plans in place. While the technical details may evolve over time as F5’s product offerings expand—whether with BIG-IP or the NGINX suite—the overarching principles of system security will largely remain constant. To assist with these efforts, there is a wealth of documentation available on MyF5 that outlines specific technical steps, additional resources, and best practices for securing systems. A few key references include K67091411: Guidance for Quarterly Security Notifications, K9970: Subscribing to email notifications regarding F5 products, K27404821: Using F5 iHealth to diagnose vulnerabilities, K11438344: Considerations and guidance when you suspect a security compromise on a BIG-IP system, K53108777: Hardening your F5 system, K45321906: Harden your BIG-IQ system, and K000156803: Hardening NGINX and NGINX Plus.European airport software attack and zero day ‘s are here
A cyberattack disrupted automatic check in, boarding pass issuance, and baggage dispatch systems at several major European airports. The affected software was provided by Collins Aerospace (RTX subsidiary), and the attack left many airports resorting to manual operations (handwritten boarding passes, use of laptops, etc.). A critical vulnerability (CVE 2025 10035) in Fortra’s GoAnywhere Managed File Transfer (MFT) software was actively exploited as a zero day before the vendor publicly disclosed it. The flaw lies in the License Servlet and allows command injection via unsafe deserialization under certain conditions.Mobile Security: Current Challenges & A Vision For The Future
In today’s hyper-connected world, smartphones are far more than communication devices. They are personal assistants, financial hubs, health trackers, and corporate gateways. With over billions of smartphone users globally, these devices have become indispensable tools for work, entertainment, and daily life. However, their commonness has not gone unnoticed by cybercriminals, making mobile security one of the most pressing challenges of our time. From malicious apps to phishing attacks and zero-day vulnerabilities, threats targeting mobile devices are evolving rapidly. This article will explore the current mobile security landscape, the future of this field, and best practices for safeguarding mobile devices against growing cyber risks. The Current Mobile Threat Landscape Mobile devices have become lucrative targets for attackers, owing to their use in both personal and professional capacities. Nowadays, threats targeting mobile devices are more sophisticated, leveraging advanced technologies such as AI and automation. 1. Mobile Malware and Spyware: Malicious software crafted for smartphones has surged in recent years. Attacks like FluBot and Joker malware have compromised thousands of mobile devices globally. They steal sensitive information such as banking credentials and personal data. Spyware, such as Pegasus, has shown how attackers can exploit zero-day vulnerabilities to take control of a device remotely and exfiltrate information, including encrypted communications. 2. Smishing & Phishing Attacks: Phishing attacks have migrated from email to mobile messaging. Smishing (SMS phishing) and phishing through messaging apps like WhatsApp, Telegram, or Facebook Messenger are highly effective because users tend to trust these platforms. Attackers use tactics like fake package delivery notifications or password reset requests to trick victims into revealing sensitive information. 3. Mobile Payments Under Siege: The widespread adoption of mobile payment platforms (Google Pay, Apple Pay, PayPal) and QR-code-based payments has introduced unprecedented convenience. However, these systems are now lucrative targets for attackers. For example, malicious QR codes redirect users to phishing sites or download malware to compromise financial accounts. 4. IoT and 5G Vulnerabilities: As smartphones increasingly function as controllers for IoT ecosystems (smart homes, wearables, connected cars), attackers see an opportunity to exploit vulnerabilities across interconnected devices. With the rise of 5G networks, data is being transmitted faster than ever. This speed also introduces risks related to network attacks, unauthorized access, and greater attack surfaces. 5. Emerging AI-Powered Threats: Artificial intelligence has revolutionized how attackers create and execute cyberattacks. AI can be used to automate phishing campaigns, generate realistic text for scams, or even create deepfake audio and video to impersonate individuals in real time. These hyperrealistic attacks are harder to detect and even more effective at deceiving victims. Future of Mobile Security The challenges we face today are only the beginning. As mobile technology advances and becomes further integrated with every facet of human life, mobile security will define the frontlines of cybersecurity. 1. AI-Enhanced Defenses Just as attackers leverage AI for malicious purposes, defenders are increasingly using AI for anomaly detection and behavioral analytics. Machine learning tools can analyze user behavior in real time. They can detect unusual patterns such as unauthorized app activity or data exfiltration attempts. As AI improves, it will play a central role in combating AI-generated threats and various forms of malware. 2. Quantum-Safe Cryptography While quantum computing is still in its early stages, its eventual application will have profound implications for data encryption. Organizations are already exploring post-quantum cryptography. This ensures that mobile communications and sensitive information remain secure against the enormous processing power of quantum computers. 3. Zero-Trust Architecture for Mobile Devices Zero Trust principles, which by default trust no device, application, or user regardless of their network location, are being used more on mobile devices. Continuous verification, device posture checks, and contextual information (e.g., user behavior, location) will further tighten security for mobile endpoints accessing sensitive systems. 4. Hardware-Backed Security By 2025, most modern devices will come pre-equipped with secure enclaves (such as Apple’s Secure Enclave or Android’s Titan M chips). These hardware modules are isolated from the operating system. This keeps sensitive data like cryptographic keys, payment information, and biometric data secure from OS-level exploits. 5. Stricter Regulation and Compliance Privacy regulations like GDPR, CCPA, and other global frameworks will continue to evolve, ensuring that users' data is handled responsibly. Mobile app developers will embed compliance-by-design practices. They will focus on transparency, limited data collection, and permission management to align with user rights. 6. Interconnected Ecosystems and Broader Risks As IoT ecosystems mature, the smartphone will act as the central controller for a growing range of devices. Cybersecurity solutions for mobile devices will need to address the cascading risks posed by compromised IoT devices, interconnected networks, and 5G-enabled technologies. Best Practices to Protect Mobile Devices Both individuals and organizations must adopt proactive mobile security strategies. Here are some of the best practices for reducing exposure to threats: For Individuals: Enable Biometric, and Multi-Factor Authentication (MFA): Use biometrics like fingerprints or facial recognition alongside MFA for critical accounts such as banking, email, and corporate logins. Keep Devices and Apps Updated: Regularly update operating systems and apps to patch critical vulnerabilities. Many attacks target older, unpatched versions of software. Review App Permissions Carefully: Avoid granting unnecessary permissions to apps, especially for access to sensitive data like location, contacts, or storage. Use Trusted App Stores: Stick to verified marketplaces like Google Play and Apple’s App Store to avoid downloading malicious apps. Adopt Secure Communication Tools: Use encrypted messaging apps like Signal or WhatsApp for confidential communication. Beware of Smishing and Phishing Attacks: Avoid clicking on suspicious links in SMS or messaging apps. If something seems too urgent or too good to be true, validate its authenticity via official channels. Use Mobile VPNs: A Virtual Private Network (VPN) ensures secure browsing, especially on public Wi-Fi networks. Install Anti-Malware Apps: Consider a trustworthy mobile security app to monitor your device for malware and other threats. For Organizations: Adopt Mobile Threat Defence (MTD): Deploy MTD solutions that integrate with Mobile Device Management (MDM) and Enterprise Mobility Management (EMM) platforms. These tools provide real-time monitoring of mobile endpoints and threat mitigation. Implement Zero Trust Network Access (ZTNA): Use a zero-trust approach for mobile device access to corporate networks, continually verifying devices for access permissions. Enforce App Containerization: Use tools that separate corporate data from personal applications on mobile devices to prevent cross-contamination of information. Train Employees on Mobile Security: Regular awareness campaigns and training on recognizing smishing scams, fake apps, and account takeover attempts are critical. Monitor for SIM-Swap Attacks: Leverage tools capable of detecting and flagging suspicious account activity associated with SIM-swapping fraud. Restrict BYOD Access: For Bring Your Own Device (BYOD) policies, enforce strict security policies, such as requiring up-to-date OS and apps, to minimize risks. Conclusion There is no doubt that the future of cybersecurity is mobile-centric. As smartphones continue to act as gateways to digital assets, IoT ecosystems, and corporate networks, they will remain a primary battleground for attackers and defenders alike. The good news is that both individuals and organizations are empowered to improve their resilience. By adopting stronger authentication measures, AI-powered defenses, zero trust principles, and remaining vigilant with updates and monitoring, mobile security can evolve to meet even the most sophisticated challenges ahead. In the race to safeguard the digital future, proactive preparation, collaboration, and innovation in mobile security ensures that technology continues to empower, not endanger its users.Apple’s MIE, Fake Chrome Ext, and C2PA Content Credentials in Google Pixel
Notable security news for the week of Sept 7-13th, 2025, brought to you by the F5 Security Incident Response Team. This week, your editor is Dharminder. In this edition, I have security news covering Apple's new built-in memory safety system called Memory Integrity Enforcement, the emergence of fake Chrome extensions used to hijack Meta business accounts, Google's introduction of Trusted Photography with C2PA Content Credentials in Google Pixel a significant step towards digital media transparency and CISA's alert regarding the actively exploited Dassault DELMIA Apriso RCE vulnerabilityPost-Quantum Cryptography, OpenSSH, & s1ngularity supply chain attack
This week in security: PQC by default, and a supply-chain gut check. At F5, we are publishing a forward‑looking series of blog posts which help security and IT leaders anticipate tomorrow’s risks and capitalize on emerging tech. Think of it as a field guide to future threats—and how to stay resilient as they arrive. We are about half way through the series, here are some of the highlights from my point of view.
