An eight-month international operation targeting West African organized crime groups has resulted in 58 arrests and the identification of 263 suspects across 22 countries, according to INTERPOL. Operation Jackal IV, conducted from November 2025 to June 2026, focused on disrupting criminal networks, tracing illicit funds, identifying high-value targets and supporting arrests and prosecutions. The operation brought together countries across six continents to tackle the growing global threat posed by West African criminal networks, including Black Axe and similar groups. These networks have been linked to a significant share of global cyber-enabled financial fraud, including romance scams, cryptocurrency and investment scams, and business email compromise fraud.

Operation Jackal IV Targets West African Organized Crime Groups

Operation Jackal IV also targeted money laundering activities used to move and conceal criminal proceeds across borders. INTERPOL coordinated cross-border intelligence sharing, analysis and operational support during the operation. It also provided specialized training to strengthen international investigations into financial crime. Tomonobu Kaya, Director of the INTERPOL Financial Crime and Anti-Corruption Centre, said the operation showed the importance of international cooperation in following illicit financial flows and disrupting criminal networks. [caption id="attachment_113806" align="aligncenter" width="600"] Image Source: INTERPOL[/caption]

Major Arrests and Financial Crime Investigations

In Argentina, authorities identified 196 individuals linked to a major Crime-as-a-Service network suspected of providing website domains and money laundering support to West African organized crime groups. The investigation resulted in 17 arrests, with an INTERPOL Operational Support Team assisting with analysis of seized data and identification of suspects and criminal networks. South African authorities raided seven locations in Johannesburg linked to a syndicate involved in romance and investment scams targeting retirees in English-speaking countries. Investigators arrested 39 people, seized USD 2.67 million and blocked 257 bank accounts. In Italy, investigators identified an individual connected to a pan-European money laundering network that used shell companies, remittance services and cash withdrawals. One account processed EUR 845,000, or about USD 736,000, through 560 transactions involving 20 financial instruments. Romanian authorities dismantled a criminal group operating an investment scam through a call centre. The group promoted high returns from stocks and cryptocurrencies, with victims' money transferred to electronic wallets controlled by perpetrators. Authorities estimated that EUR 143 million had been stolen and laundered globally. Eleven people were arrested, while cash, cryptocurrency, six real estate properties and luxury watches were seized.

Sextortion and Crime-as-a-Service Emerge

Beyond individual investigations, the operation highlighted emerging threats involving sextortion and Crime-as-a-Service. INTERPOL identified an increase in West African organized crime groups using sextortion to target minors, including victims as young as 14. In these cases, offenders typically contacted minors through social media, established trust and persuaded them to share explicit images or videos. They then threatened to distribute the material to the victim's contacts unless a ransom was paid. Investigators also found that some criminal syndicates were procuring Crime-as-a-Service from external providers, including through the dark web. These services were used to outsource activities such as money laundering and other operational functions. While several cases from Operation Jackal IV remain under investigation, the preliminary results demonstrate the scale and international reach of the networks targeted during the eight-month operation. The participating countries were Austria, Argentina, Australia, Canada, Côte d'Ivoire, France, Germany, Indonesia, Ireland, Italy, Japan, Malaysia, the Netherlands, Nigeria, Portugal, South Africa, Spain, Sweden, Switzerland, the United Arab Emirates, the United Kingdom and the United States.

Recent AI security incidents involving model evaluations have raised questions about how securely frontier AI models are tested before deployment. Cybersecurity-focused AI company Irregular said an investigation into a publicly reported incident found that models in a small number of evaluation runs gained unintended internet access and carried out offensive security actions against real-world targets. Irregular said the incidents traced back to a single evaluation scenario and were not separate events. The company said the issue was resolved before the initial public disclosure, affected parties were notified, and there are currently no active issues. Its broader audit remains ongoing. Irregular said the AI security incidents occurred during AI model evaluations designed to test whether models could autonomously execute multi-stage cyber scenarios under realistic conditions. The evaluations simulate real-world attack patterns and provide models with objectives such as reconnaissance, identifying private keys, gathering information, extracting data and attempting to avoid detection. According to Irregular, controlled internet access can be important to maintain realism because real-world attackers rely on the internet. However, the company found that internet access controls allowed some models to move beyond the intended simulated environment. In the evaluation at the center of the investigation, engineers selected a fictional company name that unknowingly matched a real domain. While models operated inside the simulation in most runs, a small number attempted to access the real domain despite receiving no instruction to do so. Irregular said models subsequently exploited vulnerabilities, extracted credentials and obtained access to a production database. In another instance, a model moved to a website with a similar name and encountered publicly posted credentials. The company said there is no evidence that a customer's systems were breached or that customer data was leaked.

Evaluation Environments Face Monitoring Challenges

Irregular said most of the problems identified during its investigation were connected to internet access controls. The company is introducing additional protocols for evaluation setup and strengthening its approach to containment. The incident also highlighted challenges around model monitoring. Irregular said advanced simulations can generate extremely large volumes of traffic, while legitimate offensive actions performed by models can resemble malicious activity. The company said incidents occurred in fewer than one in 10,000 advanced simulations and often appeared hundreds of turns into an evaluation. Irregular plans to expand manual review of model behavior, improve monitoring capabilities and establish a dedicated internal team focused on security, containment and model control. The company also said evaluation environments need continuous review because fictional names used in scenarios can later overlap with newly created websites or real domains.

Security Experts Question Irregular's Response

The disclosure has drawn criticism from cybersecurity professionals. Zack Korman, chief executive of cybersecurity-focused AI company Embroidery, called the post “such an embarrassing post-mortem” on the OpenAI/Anthropic security incidents and described it as “full of excuses.” Justin Elze, chief technology officer at TrustedSec, questioned why the monitoring challenge had not been addressed earlier, saying the issue appeared closely connected to the purpose of the testing service. Woodward also criticized the disclosure, arguing that the absence of dates, named owners for corrective measures and independently verifiable criteria limited its usefulness to researchers and security professionals. Another cybersecurity commentator, BlackRoomSec, challenged Irregular's assessment of existing monitoring tools, arguing that security teams routinely tune monitoring systems to reduce noise and filter false positives. Irregular said it is continuing its investigation and will share additional findings where relevant. The company also plans to publish an open whitepaper covering pre-deployment evaluations, including proposed best practices for internet access during testing. [caption id="attachment_113686" align="aligncenter" width="555"] Image Source: X[/caption] The discussion adds to wider scrutiny of how cyber evaluations are contained, monitored and disclosed as frontier AI models become increasingly capable. Irregular said the lessons from the incident will be used to develop stronger evaluation environments, monitoring capabilities, containment controls and response procedures.

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.

U.S. authorities have charged two New York residents, including Zhuoying Chen, in connection with an alleged Chinese money laundering network accused of laundering at least $43 million generated through cyber investment fraud schemes. The indictment, unsealed in Brooklyn, alleges the operation ran between 2020 and 2022 and involved an extensive network of shell companies and bank accounts.  According to prosecutors, Zhuoying Chen, 27, of Brooklyn, and Haojie Zhang, 38, of Queens, managed more than a dozen individuals across Brooklyn and Queens. The group allegedly opened 140 bank accounts under approximately 45 shell companies to move proceeds from fraudulent investment scams before transferring the funds to co-conspirators based in China.  Authorities said the investment fraud schemes began with perpetrators contacting victims through messaging platforms and social media. They allegedly built trust over time, persuaded victims to invest in seemingly lucrative opportunities, displayed fake profits to encourage additional investments, and ultimately stole the victims' money. 

Officials Vow Crackdown on Chinese Money Laundering Operations 

Commenting on the Chinese money laundering case, Assistant Attorney General A. Tysen Duva said, "As alleged in the indictment, the defendants laundered fraud proceeds, enabling scammers to continue to victimize Americans and deprive them of their hard-earned money." He added that dismantling Chinese money laundering networks supporting investment fraud is critical to protecting Americans and that the Criminal Division "will relentlessly pursue the financial networks that fuel and profit from these fraud schemes."  U.S. Attorney Joseph Nocella Jr. for the Eastern District of New York described the defendants as "key members of a sophisticated money laundering network" that allegedly routed more than $40 million in victim funds to bank accounts in China. He said the office would continue pursuing individuals involved in investment fraud targeting vulnerable victims.  FBI New York Assistant Director in Charge James C. Barnacle Jr. stated that the operation allegedly laundered more than $40 million from American victims before depositing the funds into Chinese accounts overseas. He said the FBI remains committed to working with federal partners to dismantle such fraud networks.  Acting Executive Associate Director John A. Condon of Homeland Security Investigations said the two Chinese nationals allegedly operated the illicit network for nearly two years, laundering victims' life savings. IRS Criminal Investigation Special Agent in Charge Harry T. Chavis Jr. said the indictment demonstrates that "justice is coming" for fraudsters, while U.S. Postal Inspection Service Inspector in Charge Ketty Larco-Ward noted that investment fraud schemes exploit victims' trust through false promises of returns. 

Investigation and Legal Proceedings Continue 

The conspiracy to commit money laundering charge carries a maximum sentence of 20 years in prison. The investigation is being conducted by FBI New York, HSI New York, IRS Criminal Investigation New York, and the U.S. Postal Inspection Service. The prosecution is being led by Trial Attorneys Claire Galasso, David Ginensky, and Adrienne Rosen, along with Assistant U.S. Attorneys Benjamin Weintraub and David Berman.  The case also forms part of the Homeland Security Task Force initiative established under Executive Order 14159. Officials emphasized that an indictment is only an allegation, and Zhuoying Chen and the co-defendant are presumed innocent unless proven guilty beyond a reasonable doubt in court. 

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.

The Italian Data Protection Authority fine against Poste Italiane and Postepay has reached over €12.5 million, after regulators found unlawful processing of personal data affecting millions of users.

Italy’s Italian Data Protection Authority imposed a €6.6 million penalty on Poste Italiane and €5.8 million on Postepay. The action follows an investigation launched in April 2024 after multiple complaints from users regarding how their data was being handled through mobile applications.

Italian Data Protection Authority Fine Linked to Intrusive App Monitoring

The Italian Data Protection Authority fine centers on how BancoPosta and Postepay apps collected user data. Customers were required to allow monitoring of information stored on their devices, including details about installed and active applications.

According to the companies, this access was necessary to detect malware and prevent fraud in line with payment security requirements. However, the regulator found that the scope of monitoring went too far.

Authorities stated that the data collection methods were not proportionate and resulted in excessive intrusion into users’ private lives. The ruling emphasized that fraud prevention cannot justify blanket access to personal device data.

Multiple Compliance Failures Identified

The investigation behind the Italian Data Protection Authority fine also revealed broader compliance failures. Regulators flagged insufficient transparency in how users were informed about data collection practices.

The companies were also found to have not conducted an adequate Data Protection Impact Assessment. Such assessments are required when processing activities pose high risks to individual privacy.

Further issues included weak security measures, unclear policies on how long data was stored, and irregularities in defining data controller responsibilities. These gaps raised concerns about how user data was governed internally.

As part of the enforcement action, both companies have been ordered to stop the disputed data processing practices if still ongoing. They must also align their data retention policies with regulatory requirements and report compliance to the Authority.

Italian Regulator Steps Up Enforcement

The action reinforces a broader trend of stricter enforcement by the Italian Data Protection Authority across the financial sector. The Italian Data Protection Authority fines Poste Italiane and Postepay case follows another high-profile enforcement action earlier this year involving Intesa Sanpaolo. In March 2026, the regulator imposed a €31.8 million penalty on the bank after uncovering serious lapses in how customer data was protected. The case involved unauthorized access to sensitive information of more than 3,500 customers over a period of more than two years. Investigators found that a single employee had accessed customer records more than 6,600 times without any legitimate business reason. The breach went undetected for months, exposing weaknesses in the bank’s internal monitoring systems.

Insider Risks and Monitoring Gaps under Focus

The Intesa Sanpaolo case highlighted a different but equally critical issue. While Poste Italiane and Postepay were penalized for excessive data collection, the bank was fined for failing to detect misuse of legitimate access. According to the Authority, the bank’s monitoring systems were not designed to identify slow, repeated misuse of access over time. This allowed the unauthorized activity to continue without triggering alerts, even when it involved high-risk individuals such as public figures. Regulators concluded that the controls in place were not aligned with the risks associated with broad internal access to sensitive financial data. The case has since raised concerns about insider threats and the effectiveness of existing detection mechanisms within financial institutions.

Growing Pressure on Financial Services

Together, these cases reflect a tightening regulatory environment in Italy, where financial institutions are being held accountable for both overreach and underperformance in data protection. The Italian Data Protection Authority fines Poste Italiane and Postepay decision highlights the importance of balancing fraud prevention measures with user privacy. Security controls must be proportionate, transparent, and supported by proper risk assessments. At the same time, the Intesa Sanpaolo breach demonstrates that insufficient monitoring can be just as damaging, particularly when insider threats go unnoticed for extended periods. With enforcement actions increasing in scale and frequency, organizations operating in the financial sector are facing mounting pressure to reassess their data governance frameworks. The regulator’s recent decisions make it clear that both excessive data collection and weak oversight can lead to significant financial and reputational consequences.

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.