The FBI is warning the public about sexual exploitation actors illegally accessing social media and personal accounts to steal explicit images and videos from adult and underage victims. The stolen material, also known as non-consensual intimate images (NCII), is being posted or sold on criminal marketplaces, often without the victim's knowledge.

According to the FBI, these actors use social engineering and cyber intrusion tactics to target specific individuals or general targets of opportunity. After gaining access to accounts, they steal explicit content and share it through community forums or illicit marketplaces.

The FBI said personally identifiable information, including a victim's name, date of birth, email address, phone number and social media username, is often posted alongside the stolen material. This can expose victims to continued harassment and re-victimization.

How Sexual Exploitation Actors Access Accounts

The FBI has identified several methods used by sexual exploitation actors to gain access to victims' accounts.

Password and PIN Targeting

In password/PIN targeting, actors use high-volume password and PIN attempts against social media and personal accounts. The information used in these attempts can come from data leak sites, social media and open-source information.

When victims are known to the actors, curated lists may include personal details such as names, date of birth or variations of those details.

Social Media Customer Service Impersonation

Another tactic involves social media customer service impersonation through text messages. Victims may receive messages claiming their account is being disabled or locked unless they provide a verification code.

The actor then requests a password reset, causing a code to be sent to the victim. If the victim shares the code, the actor can reset the password and access the account.

Phishing Emails

The FBI also warns about phishing campaigns using look-alike domains and email accounts designed to appear as social media customer support.

These messages may claim there has been a new login and contain an embedded link asking the victim to change their password. Clicking the malicious link can give the actor access to the account.

Stolen Content Can Lead to Further Attacks

Once explicit content is stolen, sexual exploitation actors may post or sell it while including personal information about the victim. The FBI said victims can subsequently face harassment, sextortion, stalking or other targeted attacks.

The actors may also advertise stolen content through a victim's own social media page, increasing the potential for further exposure.

FBI Shares Steps to Protect Accounts

The FBI advises people to avoid storing sensitive images or videos on social media platforms or other internet-accessible sites.

It recommends using unique, complex passphrases and PINs along with multi-factor authentication (MFA). Password information directly associated with a person's identity, including names or birthdays, should be avoided.

Users should also be cautious with links received through emails and text messages. The FBI recommends going directly to the relevant website to address account concerns and checking URLs before clicking.

Unrequested temporary passwords, PIN resets or access codes should also be treated with caution. The FBI advises users not to share login information, even when someone claims to represent a platform or service.

People who believe their explicit content was stolen or leaked can provide information through the FBI's NCII reporting site. The FBI also advises the public to continue reporting fraud, scams and cyber threats to the Internet Crime Complaint Center or a local FBI Field Office.

A vishing call to an overseas contact center agent. A fake IT ticket. A default setting nobody thought to lock down. That's all it took to expose the personal data of roughly 5 million Australians — and now the country's privacy regulator has decided Qantas isn't to blame for it.

The Office of the Australian Information Commissioner (OAIC) closed the book this week on its year-long preliminary inquiry into the June 2025 Qantas data breach, and the conclusion cuts against the instinct to punish the victim of a cyberattack.

Also read: Australia’s Qantas Confirms Cyberattack: 6 Million Service Records Compromised

According to the OAIC's report, the evidence gathered did not indicate a likelihood that Qantas had "failed" to take reasonable steps to protect the personal information it held, nor that it failed to ensure its overseas third-party provider complied with Australia's privacy principles. No investigation. No enforcement action.

"After more than a year of making inquiries and obtaining information on the data breach, we're satisfied that the evidence does not support the likelihood that a breach of privacy law occurred. As a result, we've decided not to commence a full investigation of Qantas at this stage." - Carly Kind, Australian Privacy Commissioner.

How It Happened

The breach traces back to a single phone call. A threat actor posing as "Qantas IT help" convinced a contact center agent to visit a website tied to the customer relationship management platform used by Qantas agents, walking them through steps framed as necessary to close an IT support ticket. That interaction connected the agent's CRM session to a data extraction tool controlled by the attacker, who then pulled data from every contact profile the agent could access. It was pure social engineering — no malware, no exploited vulnerability, just a convincing lie.

Qantas caught it fast. A staff member spotted an unusual spike in login-attempt alerts on the morning of June 30, two days after the call, and escalated it to the cybersecurity team. Within hours, the company had frozen the compromised account, assessed for data exfiltration, and triggered its incident response process. Public disclosure followed on July 2.

What Was Exposed — And What Wasn't

The regulator's numbers are more precise than what circulated publicly last year. Roughly 5.67 million customer records were compromised, with about 4 million exposing names, phone numbers, email addresses and Frequent Flyer details, and a further 1.7 million records including combinations of home or business addresses, dates of birth, gender and meal preferences. Critically, no credit card numbers, financial information or passport details lived on the compromised platform, and customer passwords and login credentials were never touched.

Also read: Qantas Airways Cyberattack Update: Customer Data Released, Security Measures Enhanced

Why The Regulator Let It Go

The OAIC's reasoning is a rare, explicit acknowledgment that good controls don't guarantee immunity. Investigators found that social engineering training generally targets credential theft, not the rarer tactic of talking an employee into authorizing a legitimate-looking system connection — meaning the attack likely would have succeeded even with standard training in place. They also noted the flaw was structural: a default configuration let the agent authorize a third-party app connection, a setting the CRM vendor has since changed for all its customers.

Commissioner Carly Kind put the broader stakes plainly in the OAIC's statement announcing the report, warning that AI-driven threats are only raising the bar. As she framed it, agentic and advanced AI will keep escalating the cybersecurity risks businesses face, making continuous review of security posture non-negotiable — not optional.

“Data breaches are a persistent feature of today’s digital world, and can occur despite organisations taking steps to protect personal information,” Commissioner Carly said. “Agentic and advanced AI will only increase the cybersecurity risks that businesses face, and it is critical that all organisations continuously review and enhance their security to protect against this growing threat.”

The takeaway here isn't that Qantas got a pass. It's that a regulator has now drawn, in writing, the line between negligence and the limits of what training and access controls can realistically stop.

The investigation into the Odido cyberattack has uncovered possible involvement of Dutch nationals, according to Dutch police, as authorities continue to investigate the ShinyHunters ransomware-linked attack that exposed the personal data of approximately 6.39 million customers. Law enforcement has urged the public to come forward with information as investigators work to identify those responsible for one of the country's largest telecom data breaches.

The cyberattack took place on February 5 and 6 after attackers allegedly used voice phishing (vishing) to deceive Odido's customer service team.

According to the company, the attackers posed as members of its internal IT staff, gaining unauthorized access before exfiltrating customer data. Odido said its teams detected the unauthorized access immediately on both occasions and revoked the attackers' access, but the incident still resulted in a large-scale data breach.

Odido Cyberattack Investigation Finds Possible Dutch Link

Under the direction of the National Public Prosecution Service, the High Tech Crime Team (THTC) of the National Investigation and Intervention Unit launched an extensive investigation into the breach.

Authorities said investigators have found strong indications that Dutch criminals may have been involved. One key lead centers on a phone call made shortly before the breach in which a Dutch-speaking man allegedly impersonated an Odido IT employee while speaking with customer service representatives. Police are continuing efforts to identify the caller and have indicated that his voice could be made public if necessary.

Investigators believe people within cybercrime circles may have information about those responsible and are encouraging anyone with relevant details to contact law enforcement.

ShinyHunters Named as Threat Actor

Odido attributed the attack to the cybercriminal group ShinyHunters, which the company said carried out the social engineering campaign.

Chief Executive Officer Søren Abildgaard acknowledged the incident in a public statement, apologizing to customers and outlining the company's commitment to strengthening its cybersecurity capabilities. He said Odido would continue investing in security, improve data protection practices, expand customer support, and share lessons learned from the incident.

The CEO also explained why the company refused to pay the ransom demand. According to Odido, paying cybercriminals would reward illegal activity and could encourage future attacks against other Dutch organizations. The company said the decision was made following guidance from authorities, despite knowing that stolen data could eventually be published.

Millions of Customers Impacted

Odido confirmed that approximately 6.39 million active and former customers of Odido and its Ben brand were affected by the breach. Customers of Simpel were not impacted.

The exposed information varied by individual and included names, addresses, mobile phone numbers, customer numbers, email addresses, IBAN numbers, dates of birth, identification details, nationality, and gender.

The company clarified that My Odido account passwords, call records, location data, billing information, and scans of identity documents were not compromised.

Odido also addressed reports claiming customer passwords had been leaked, stating that login passwords remain securely encrypted and were never accessible during the attack. Instead, a separate telephone verification field known as "password_c," used as a customer challenge code, was included for a limited number of customers. The company has since discontinued using that verification method.

Customer Support and Security Measures Expanded

Following the breach, Odido increased customer support by adding more than 140 service agents and introduced additional security measures. These include its "Check je Gesprek" verification service, allowing customers to confirm whether communications claiming to be from Odido are legitimate, along with access to the F-Secure digital security service.

The telecom provider said all customers identified as affected have been notified by email or SMS, while customer service teams continue assisting users with questions related to their specific data exposure.

Meanwhile, Dutch authorities expect investigations into the Odido cyberattack to continue for several months. Police have also warned that cyberattacks targeting businesses and institutions are becoming increasingly common, urging organizations to strengthen cybersecurity defenses and encouraging citizens to remain vigilant against follow-on fraud and phishing attempts.

The FBI Warns of Malicious Traffic Distribution Systems being increasingly used by cybercriminals to redirect internet users to phishing pages, malware downloads, ransomware attacks, and online financial scams. In a newly released Public Service Announcement (PSA), the Federal Bureau of Investigation cautioned that cybercriminals are leveraging Traffic Distribution Systems (TDS) to gain access to victim networks while evading traditional security controls. According to the FBI, TDS technology is designed to route internet traffic to different destinations after users visit websites, click advertisements, download applications, or engage with online promotions. While the technology itself has legitimate uses, cybercriminals are exploiting it to selectively redirect users to compromised websites and fraudulent login pages.

FBI Warns of Malicious Traffic Distribution Systems Used in Cyber Attacks

As the FBI Warns of Malicious Traffic Distribution Systems, the agency explained that cybercriminals often drive victims to a malicious TDS through various methods, including Social Engineering, phishing emails, malicious advertisements, and compromised websites. One common technique involves Search Engine Optimization (SEO) Poisoning, where fraudulent advertisements are designed to imitate legitimate websites. Users who click these links may unknowingly enter a redirection chain controlled by threat actors. Cybercriminals also compromise legitimate websites by exploiting weak passwords, outdated plugins, and vulnerable website themes. Once administrative access is obtained, attackers can modify website code to automatically redirect visitors to a malicious TDS infrastructure.

How Traffic Distribution Systems Help Evade Detection

According to the FBI, Traffic Distribution Systems (TDS) can bypass traditional firewall protections that would normally block access to malicious websites. The system uses multiple intermediate nodes before directing users to the final destination, making it more difficult for defenders to identify and block malicious activity. In addition to hiding malicious infrastructure, attackers use TDS platforms to gather information about visitors. Data collected may include:

• IP address
• Operating system
• Geographic location
• Device information
• Browser details

The FBI noted that this information allows attackers to determine whether a victim is a suitable target. It also enables cybercriminals to avoid detection by presenting harmless content to users they are not interested in targeting, including security researchers and analysts.

Phishing, Malware, and Ransomware Risks

The FBI warned that users reaching the end of a malicious redirection chain may encounter Phishing Pages, financial fraud schemes, or malware downloads. In some cases, attackers use malware delivered through a TDS to gain access to victim networks. The agency stated that compromised accounts and network access obtained through these methods may later be sold to other criminal groups, including Ransomware operators. The PSA highlights how a single visit to a compromised website or malicious advertisement can ultimately lead to broader cybersecurity incidents.

FBI Shares Protection Measures

To reduce the risk of compromise, the FBI advised individuals to verify website URLs before clicking advertisements or promotional links. The agency also recommended keeping software, website plugins, and themes updated to address known vulnerabilities. Additional recommendations include:

• Using strong passwords
• Enabling Two-Factor Authentication (2FA)
• Installing reputable security plugins and web application firewalls
• Downloading software only from trusted developers

For businesses, the FBI recommended monitoring endpoints for suspicious activity involving JavaScript, PowerShell, and script execution tools. Organizations are also encouraged to strengthen phishing awareness training, regularly audit website administration accounts, and patch content management systems and third-party components.

FBI Urges Victims to Report Incidents

The FBI encouraged individuals and organizations that believe they have been affected by activity linked to malicious TDS infrastructure to report the incident through the Internet Crime Complaint Center (IC3) and contact their local FBI field office. The agency emphasized that cybercriminals continue to evolve their techniques for delivering malware and conducting online fraud, making vigilance and proactive cybersecurity measures essential for both individuals and businesses.

The convergence of SRE and Security Engineering is reshaping how organizations build, operate, and protect modern cloud environments. As infrastructure grows more complex and distributed, reliability, security, identity management, and observability are becoming increasingly interconnected disciplines rather than separate functions.

Advait Patel, Senior Site Reliability Engineer at Broadcom and author of DockSec, has witnessed this shift firsthand. With experience spanning cloud infrastructure, DevSecOps, and observability platforms such as Wavefront (Tanzu Observability), he has worked on systems processing more than 10 million data points per second while leading initiatives in IAM, cloud migration, and security engineering.

In this interview, Patel shares his insights on securing observability platforms at scale, managing identity across multi-cloud environments, balancing automation with human oversight, and the role AI is playing in the future of DevSecOps and incident response.

Advait Patel Breaks Down SRE and Security Engineering 

TCE: How are you seeing SRE and security engineering converge in modern cloud environments? 

Advait Patel: The short version is that the failure modes started overlapping and the org charts are catching up. A misconfigured IAM policy that takes down a service and a misconfigured IAM policy that exposes data are usually the same mistake. SREs already own the deployment pipeline, the observability stack, and the incident process, which happen to be the three places security has to live if it wants to be effective instead of decorative.  What changed it for me was security as code. When I ran the zero-downtime migration of our observability platform from AWS to GCP, security could not be a review step bolted on at the end. It had to be expressed the same way reliability was, as policy in the pipeline, with the same testing and the same rollback story.   That is the real convergence. Not security and SRE attending the same standup, but security becoming something you can measure and enforce the way you measure latency or error rate. We are not all the way there as an industry. Plenty of shops still treat security as a gate at the end. But the teams moving fastest have stopped pretending the two disciplines are separate. 

TCE: What are the biggest challenges in securing large-scale observability platforms handling high-volume data streams? 

Advait Patel: This one is close to home, since I spent a long time on a platform ingesting north of 10 million data points per second. A few things make it genuinely hard.  First, telemetry is one of the most underrated attack surfaces in a company. Your metrics, traces, and logs describe your entire architecture. Get read access to that and you do not need to break into anything, the map is already drawn for you. And secrets leak into logs constantly. Someone logs a full request, the token rides along with it, and now your observability store is a credential store you never meant to build.  Second, at that volume you cannot inspect everything inline. Any control you add has to be cheap or it becomes the exact bottleneck you were hired to prevent. That single constraint rules out a lot of textbook advice.  Third is tenant isolation. When many teams share one pipeline, one team seeing another team's data is both a security incident and a trust failure at once. Getting that right without wrecking throughput was one of the harder problems in that migration. 

TCE: How do you approach identity and access management (IAM/CIAM/WIAM) in multi-cloud architectures? 

Advait Patel: I have spent enough time here to have written a couple of books on identity in the cloud, and the honest summary is that multi-cloud IAM is hard mostly because the providers disagree with each other. AWS, GCP, and Azure each have a different mental model for what an identity even is and how permissions attach to it. The abstractions do not map cleanly, so anyone selling you one tidy policy language across all three is usually hiding the seams.  The part I am most interested in right now is workload identity. For years, we secured machines the same way we secured people, with long-lived static credentials sitting in config files waiting to leak. That model is finally dying. Short-lived, attested identities through approaches like SPIFFE and workload identity federation are a much better answer, because the credential expires before an attacker can do much with it.  For human and customer identity, the rules are simpler, but the stakes are higher. Kill static keys, federate to one source of truth, and treat access review as something continuous rather than an annual audit nobody reads. Entitlement creep is the quiet killer here. People accumulate access and almost never lose it. 

TCE: What role do you see AI playing in improving reliability and security operations (AIOps/DevSecOps)? 

Advait Patel: I will give you the unfashionable version. AI is genuinely good at one specific thing in security operations and oversold at most of the rest.  The thing it is good at is the layer between detection and action. You run a scan, you get 200 findings, and historically, a human burns half a day working out which three actually matter for their system. AI is very good at that triage and at explaining a finding in the context of your specific setup. That is most of the real value, and it is the whole reason I built DockSec the way I did.  Where it gets oversold is autonomous action in production and the idea that it replaces the analyst. It does not. The right pattern is AI sitting on top of deterministic signals, not in place of them. A coding assistant telling you a Dockerfile looks fine does not survive an auditor's first question. You still need the scanner underneath and the human judgment on top.  And there is a twist people forget. AI is also a new attack surface. Agentic systems can be manipulated through their own inputs in ways we are only starting to score properly, which is part of why I put time into AI-specific vulnerability scoring. We are adding capability and risk in the same motion. 

TCE: How can teams balance automation with human oversight in incident response? 

Advait Patel: My rule of thumb is to automate the reversible and the boring and keep humans on the irreversible and the ambiguous.  Automation is excellent at the parts of incident response that are well understood and repetitive. Detect a known pattern, enrich it, page the right person, contain something you have contained a hundred times.   That should all run at machine speed. Where I get nervous is letting automation take actions with real blast radius on its own, because automation fails confidently and at scale. A human making a bad call breaks one thing. A bad automated remediation can take the whole fleet down before anyone has read the alert.  So I think of it as trust earned in increments. New automation runs in suggest mode first, where it only tells you what it would have done. Once it has been right enough times on low-risk actions, you let it act on those, and you keep the high-consequence decisions with a person. The piece people skip is the after. Humans own the retro and the learning. You do not automate understanding why it broke. 

TCE: What are the most important security practices for containerized environments today? 

Advait Patel: A few that matter more than the rest.  Start small. Minimal base images and multi-stage builds do more for your posture than almost any tool you can buy, because you cannot be vulnerable to something that is not in your image. Most containers ship with a full operating system that they never touch.  Do not run as root, and drop the capabilities you do not need. It is basic, and people still skip it.  Care about provenance. Sign your images, generate an SBOM, and know where your base layers came from, because you inherit every vulnerability in them, whether you wrote that code or not. The supply chain is where the interesting attacks are now.  But the practice I would push hardest is making your scanning actionable. A report with 200 CVEs that nobody can act on is security theater. The problem most teams actually have is not detection, it is prioritization and remediation. Coverage without a path to a fix just manufactures guilt. Closing that gap between found and fixed is what genuinely moves your risk down, and it is the problem I have spent the most time on. 

Conclusion

From securing observability platforms handling millions of data points per second to managing identity across multi-cloud environments, Advait Patel's experience highlights the practical challenges facing today's infrastructure teams. His views on automation, AI, incident response, and container security reinforce a common theme throughout the discussion: the growing overlap between SRE and Security Engineering.

As organizations continue to modernize their cloud environments, the ability to balance reliability, security, and operational efficiency will become increasingly important. For teams navigating that shift, Patel's insights offer a grounded perspective on what it takes to build and secure systems at scale.

A newly identified ClickFix-style macOS attack demonstrates how threat actors are refining their techniques to evade security defenses. The campaign moves away from the traditional reliance on Terminal and instead uses macOS Script Editor as the primary execution vector. This change allows attackers to bypass controls designed to detect or block suspicious Terminal activity.  The shift is notable because it preserves the familiar ClickFix social engineering approach while altering how malicious commands are executed. By rerouting execution through macOS Script Editor, the attack reduces exposure to newer protections and introduces a different pathway that may be less scrutinized by both users and security tools. 

A Shift in ClickFix-Style macOS Attack Techniques 

For years, ClickFix campaigns have relied on social engineering tactics that trick users into copying and pasting malicious commands into the Terminal app. These instructions are often disguised as troubleshooting steps or routine maintenance tasks. However, this newly discovered ClickFix-style macOS attack abandons that approach entirely. Instead, attackers now leverage macOS Script Editor as the primary execution vector. While Script Editor has previously been abused for malware delivery, its use in this context, combined with a browser-triggered workflow, represents a shift in strategy. Notably, the attack is initiated through an Apple-themed webpage, which plays a central role in deceiving users. Jamf researchers noted that Apple attempted to mitigate Terminal-based abuse in macOS 26.4 by introducing a feature that scans pasted commands before execution. While this adds friction, attackers have responded by simply moving to a different tool, demonstrating the ongoing cat-and-mouse dynamic in cybersecurity. 

The Role of the Apple-Themed Webpage 

The attack begins with a convincing Apple-themed webpage designed to look like an official support page titled “Reclaim disk space on your Mac.” The page provides step-by-step instructions that closely mimic legitimate system maintenance guidance.  Users are instructed to run a cleanup script to free up storage space. When they click the “Execute” button, the page triggers an applescript:// URL scheme, which initiates the next stage of the attack.  This mechanism introduces several key differences from traditional ClickFix campaigns: 

• The browser invokes the applescript:// URL scheme  
• Users are prompted to use script Editor to open  
• A pre-filled script appears automatically inside macOS Script Editor  
• The user is encouraged to execute the script  

This workflow reduces the need for manual input, making the attack smoother and potentially more convincing. 

Execution Flow and Obfuscation 

Once inside macOS Script Editor, the user is presented with a script that appears to perform legitimate cleanup operations. However, behind the scenes, the script executes an obfuscated shell command.  The command uses string manipulation via the tr utility to decode a hidden URL at runtime. Once decoded, it resolves to a remote server hosting the malicious payload. The command follows a familiar structure: 

• Obfuscation: Encoded strings are transformed into valid URLs.
• Payload retrieval: A curl request fetches remote content, with the -k flag disabling TLS certificate validation.
• Execution: The downloaded content is piped directly into zsh, allowing in-memory execution without writing to disk.

If successful, this step delivers a second-stage payload, which is further obfuscated using base64 encoding and gzip compression. 

Second-Stage Payload and Atomic Stealer 

After decoding, the second-stage script downloads a Mach-O executable file to the /tmp directory. The script performs several actions: 

• Downloads the binary from a remote server  
• Removes extended file attributes  
• Assigns execution permissions  
• Executes the binary  

The final payload has been identified as a variant of Atomic Stealer, an infostealer known for targeting sensitive user data.  This staged delivery method allows attackers to keep the initial script small and less detectable while reserving the primary malicious functionality for later execution. 

Behavior Across macOS Versions 

The behavior of macOS Script Editor during this attack varies depending on the operating system version. On macOS 26.0, the script opens directly, allowing immediate execution. However, macOS 26.4 introduces additional safeguards.  In newer versions, users see a warning indicating that the script originates from an unidentified developer. They must explicitly permit the creation and execution of the script document, adding another layer of user interaction.  Despite this, the attack still succeeds if users follow the prompts, highlighting the continued effectiveness of social engineering. 

Indicators of Compromise 

The researchers identified several indicators associated with this ClickFix-style macOS attack: 

• Domain: dryvecar[.]com (linked to the infostealer payload)  
• Malicious webpages:  
• storage-fixes.squarespace[.]com  
• cleanupmac.mssg[.]me  
• File: helper (Mach-O executable)  
• SHA256: 3d3c91ee762668c85b74859e4d09a2adfd34841694493b82659fda77fe0c2c44  

These indicators can help security teams detect and respond to related threats.