21, August 2025
by: Mike Boswell
Recently, over dinner, Mrs B started questioning whether we would be able to order Boz Jnrs new school trousers online ready for him to return to school…heaven forbid she might have to go into the town centre and visit a shop! The source of her questions related to a recent cyberattack, caused by an insider threat and a breakdown in password reset process, that had taken a well-known UK retailer offline for weeks.
In many a board room today or scrum team there is developer, architect or director try to prioritise what’s next, and some are question how to balance security vs developing new features. After spending two years working with national cyber security agencies, this has moved to always be top of mind for me. Cloud has become more complex and with Gen AI in the picture, it is becoming even more difficult secure hyperscale cloud from threats. The cloud providers can go so far then you must rely on your teams to move up to the next level by using tooling they or third parties provide.
I have been very privileged to gain some insight into how cyber criminals are grouping and the daily insights that allow these hyper-scalers to tackle different attack vendors. When discussing this with many clients and colleagues, it is difficult to compete with the insights that cloud providers have daily. Why? Team sizes and signals are the reason. They have thousands of people focussed on security daily. They use AI to detect anonymities and patterns as criminals attack infrastructure. You cannot compete with this at scale and most places I’ve work at only have a couple of people focussed in on cyber security. If you do want to compete, then the defacto line I heard was that the whole systems would be disconnected from the internet and air gapped which happens in highly secure environments. However, this does not remove the insider or hosting provider threat if anything it removes the external threat.
So, let us go through what I see as insider, external and cloud provider threats for a simple analytics platform.
Let us take the Microsoft Northwind Traders example company. They have no inhouse cybersecurity staff and have deployed Azure Data Factory to handle ingestion, they have all data stores in a single Azure Data Lake Storage Gen 2 and are using Azure Databricks, with external tables, to process, transform and create their business intelligence layers (aligned to the medallion architecture). In 2022, they deployed via ClickOps, with no network-level firewalls or private endpoints in place and no azure policies controlling what can be deployed in the subscription.
With the architecture explained above, let us look at the insider threats risk themes that come to mind (I am sure there are more!).
| Risk theme | Why it matters in this architecture |
| Over-privileged identities & tokens | Anyone who can obtain a personal-access token, service-principal secret, or SAS token can read from ADLS Gen 2 over its public endpoint and copy data out. No firewall means no IP-level restriction to stop them. |
| “Copy-out” pipelines in ADF | A malicious analyst can author a Data Factory pipeline that points to an external SFTP/HTTP/Blob sink and schedules continual exports. Microsoft’s own Digital Defence Report notes attackers using ADF pipelines for bulk theft (Hall Booth Smith, P.C.) |
| Debug / sample-data features | ADF data preview, Databricks notebook “display()”, and Spark UI download buttons let well-meaning users leak smaller but sensitive row sets via screenshots or CSV downloads. |
| Credential sprawl in notebooks & config files | Shared notebooks often keep storage keys in plain text; with public endpoints, those keys are immediately usable off-site. |
The next question that I often get is who should I be keeping an eye on? The signals are usually there but we chose to ignore them or are so wrapped up in keeping systems alive, we miss all the automation signals which should be setup, and if they are, we are ignoring them as we don’t have it part of our daily checklist routine.
The persona of an insider threat typically revolves around someone who has authorised access to systems, data, and resources within an organisation. While insider threats are diverse and nuanced, personas usually fit into several recognisable patterns.
Their motivation could range from revenge, frustration from perceived mistreatment to dissatisfaction (job loss, demotion, missed promotions, or conflict).
Some of the indicators to look out for could be declining work performance, increasingly negative attitude toward peers or organisation or recent disciplinary actions or conflicts.
Without controls in place, the methods they could use are data theft via USB drive or cloud services, sabotage of analytics pipelines or deletion of data, deliberate unauthorised sharing of sensitive data.
Their motivation could typically have no malicious intent but is driven by ignorance or oversight.
The persona who would fit into this is someone who has poor cybersecurity hygiene (password reuse, sharing credentials), accidental disclosure via misconfigured storage, exposed notebooks or keys or failure to comply with security guidelines or policies.
Without controls in place, the accidental threat comes through unintentional exposure of data via misconfigured Azure Blob/ADLS Gen2 storage. Accidental data sharing through email or public forums. Mishandling of sensitive data by running unauthorised/unsecure scripts or notebooks.
Their motivation could be personal financial gain, intellectual property theft (for future employment, competition, or monetary reward) or desire for recognition or validation elsewhere.
Some of the indicators could be unusual activity, such as sudden large downloads or excessive queries, accessing sensitive data beyond typical responsibilities or frequent off-hours access or unexplained interest in sensitive analytics data.
These personas are typically using admin rights to exfiltrate data through legitimate tooling (Azure Data Factory pipelines, Databricks notebooks) or installing third-party tooling for covert data transfers. They could be cloning or altering existing pipelines to send data externally.
Their motivation could be bribery or coercion from external threat actors or competitors, financial reward for espionage activities.
Some of the key indicators could be sudden unexplained financial improvement or personal stressors, anomalous behaviour and communications or frequent transfers or data exports not matching job role.
For this persona we see sharing credentials or secrets with external collaborators, creating hidden or obfuscated export processes via Databricks/ADF, or coordinating exfiltration through external endpoints.
For a departing employee, they have a motivation to securing a competitive advantage in new employment, with a personal belief in entitlement to intellectual property created during employment.
Some of the indicators you should see in your logs are increased access to analytics reports, models, or intellectual property in final weeks, copying of code, analytical notebooks, or sensitive data into personal repositories.
They use methods such as exfiltration through cloud storage, USB drives, or personal emails, exporting sensitive tables from Databricks or ADLS before departure or cloning proprietary analytical models or code for later use.
There are some common methods across all insider personas such as creation of unauthorised Azure Data Factory pipelines pointing externally. The use of Databricks notebooks to script bulk data downloads or push data to external storage. Alongside exploitation of open outbound network policies (no firewalls or Private Link) or export of SAS tokens or storage keys stored in plaintext.
To effectively mitigate insider and external threats within Azure analytics services, organisations should implement strict least-privilege access controls, ensuring users have only the permissions necessary for their roles, significantly reducing the risk surface. Behavioural analytics tools should be utilised to proactively detect anomalous user activity patterns, enabling early intervention against potential threats. Additionally, using strong network policies with egress controls and outbound allow-listing should be enforced to prevent unauthorised data exfiltration through open network paths. Lastly, continuous monitoring should be established to swiftly detect suspicious Azure Entra ID activity, unusual storage read/write operations, and unexpected cloning or exporting of data pipelines, creating a robust and responsive security posture.
Finally, check your procedures and do fire drills as the UK retailer was infiltrated via a password reset by the help desk. Even the best front doors can be let down by the simplest of procedures not being in place.
This is the common threat that if you mention hackers gaining access that most people will relate to on the street.
For the architecture we mentioned, that Northwind Traders has implemented, we should be considering the following attack vectors.
| Attack vector | How an outsider gets the data |
| Public endpoints with no IP restrictions | ADLS, ADF and Databricks all use HTTPS endpoints which unless locked down could allow give stolen or brute-forced credentials direct object-store access or workspace login. |
| Misconfigured storage buckets | The 2022 “BlueBleed” incident (2.4 TB leaked) shows how a single open Azure Storage container could expose vast customer data when no firewall or private link is used (PurpleSec). |
| Credential-stuffing & token reuse | With endpoints open, password-spray or OAuth token replay directly exposes APIs that can list or copy ADLS data. |
| Supply-chain or CI/CD compromise | If attack code is committed to the repo that deploys ADF pipelines or Databricks jobs, it can silently add “Copy to external” steps. |
| Ransomware operators abusing cloud copy tools | Microsoft has observed groups such as Storm-0501 staging data to the cloud with Rclone before encrypting on-prem assets; open egress from Databricks clusters enables the same tactic (Hall Booth Smith, P.C.) |
| Shared key or SAS phishing | Attackers routinely phish for storage account keys or generate long-lived SAS tokens, with no firewall, those tokens work from anywhere. |
| Side-channel enumeration of ADLS | Public containers can be found via automated crawler lists (e.g., GreyNoise, PunkSpider). |
External attacker personas targeting Azure analytics services often fall into distinct profiles, each with unique motivations, tactics, and indicators of compromise.
Their motivation is direct monetary gain via data ransom/extortion, selling stolen data on dark web marketplaces or exploiting customer PII or financial data.
Some of the indicators of Compromise (IoC) are ransom notes, indicators of rclone or cloud-based exfiltration tools found on Databricks clusters, unusual outbound network connections to cloud providers or unknown domains.
Some of the typical methods to gain access are phishing or credential theft using credential stuffing attacks against Azure AD to access Databricks or ADLS endpoints. Ransomware and Data Extortion using Azure Data Factory or Databricks clusters to export data to attacker-controlled cloud storage prior to encryption. Exploitation of misconfigurations by scanning for open ADLS Gen2 containers and downloading exposed sensitive data.
In the last few years, this is on the rise with a motivation in espionage, IP theft, or strategic advantage (state-sponsored), economic disruption, or targeted data sabotage.
Some of the Indicators of Compromise (IoC) are extremely targeted spear-phishing campaigns aimed at administrators or data engineers, quiet persistence, long-term access, and subtle exfiltration over extended periods, use of sophisticated, hard-to-detect malware or compromised CI/CD pipelines to deploy backdoors.
When looking at the typical methods, they can be a supply chain compromise where they inject malicious code into CI/CD pipelines deploying ADF pipelines or Databricks notebooks. They monitor and exploit Zero-days or Recent Vulnerabilities. Other patterns are stealth data exfiltration using low-volume exports via Databricks notebooks or Azure Data Factory pipelines to obscure destinations.
Whilst we have had activists for a long time, the term hacktivist (Social, environmental, or political activism) applies in the systems sense where someone is ideologically motivated to publicly exposure the data to embarrass or damage corporate reputation.
Indicators of Compromise (IoC) are public release or threat to release sensitive analytics data via paste sites or social media. Defacement or tampering of analytics reports or dashboards in Databricks.
Some of the typical methods are publicly exposed endpoints by scanning and exploiting open storage accounts or publicly accessible Databricks SQL endpoints. A credential stuffing or account takeover to reuse and brute-force attacks against publicly exposed Azure services. A leakage could occur via misconfiguration after discovering and downloading data from misconfigured ADLS containers, then publicising via social media platforms.
These are increasing and are seen as opportunistic data theft for quick profit using compromised resources for further attacks or mining cryptocurrencies.
Some of indicators of compromise are high volume of failed login attempts against Databricks, ADF, or ADLS accounts. Increased bandwidth consumption or resource utilisation without business justification.
Whilst the typical methods to gain access are using automated scanners (e.g., PunkSpider, Shodan) to discover open Azure endpoints (e.g., ADLS Gen2 storage), Large-scale automated attacks to exploit known credential leaks.
The corporate world can be brutal with motivation for theft of intellectual property or analytics insights for competitive advantage. Other motivation can be for obtaining confidential pricing, customer analytics, or business strategies.
Indicators of Compromise (IoC) for corporate espionage could be targeted attacks focused on strategic analytics data (pricing, forecasts, models, customer segmentation). Unauthorised access coinciding with strategic business timelines (product launches, quarterly reports)
The methods could be targeted phishing campaigns aimed specifically at Azure administrators or analytics team members. Directly harvesting information from unprotected ADLS Gen2 storage, Databricks workspaces, or reports published via ADF pipelines. Recruitment of Insiders (Collusion) by paying or otherwise incentivising insiders to extract data via legitimate Azure analytics services (e.g., creating rogue export pipelines).
Organisations should enforce strong identity and multi-factor authentication through Azure AD Conditional Access to ensure only legitimate users can access cloud resources, while deploying private networking and network isolation measures such as Private Link, VNet injection, and outbound firewall controls to keep sensitive analytics traffic off the public internet. Regularly scheduled vulnerability and misconfiguration scans using Cloud Security Posture Management (CSPM) tools help identify gaps before they can be exploited, and comprehensive monitoring and logging leveraging Azure Sentinel, Databricks audit logs, and storage diagnostics provide early warning of anomalous activity. A disciplined patch management process and swift, intelligence-driven security posture adjustments ensure that newly discovered threats are addressed immediately, maintaining a continuously hardened environment.
Finally, check that the cybersecurity procedures you can that involves a human loop, are regularly reviewed.
In the arena of sovereignty these discussions come up often as into what can the cloud provider see and what access they have to systems.
Cloud providers have a lot of controls in place over access from how they build data centres to auditing that is put in place to how access to underlying infrastructure is given. For example, the Microsoft Trust Centre (Microsoft Trust Centre) lists how they handle Security, Privacy, Data location and GDPR.
For Microsoft, complete transparency is maintained through Azure Fundamentals which gives insight to the Azure infrastructure security and using this material is how you make a risk assessment for what you wish to place in cloud.
Looking at two industries such as retail and FSI, we can hypothesize some of the potential leaks.
High‐probability data exfiltration in retail environments can originate from a variety of sources.
Insiders, such as merchandising analysts or marketing vendors, might surreptitiously add an ADF “Copy to XYZ” sink to siphon full product and loyalty tables overnight. Even seemingly benign tools like Databricks notebooks used for promotion modelling, which offer CSV export and display() features, can be misused by staff to screenshot or sensitive data to personal machines.
Externally, misconfigured ADLS containers routinely expose order‐confirmation emails and shipping labels to bucket‐crawling attackers as seen in June 2025 when an open Azure Blob leaked 1.6 million Etsy and TikTok Shop customer records (The Hacker News) while credential‐stuffing campaigns against customer‐facing Power BI and Databricks SQL endpoints could harvest price files ahead of major campaigns (“Black-Friday price exfiltration”).
Ransomware groups such as Storm-0501 further exploit public endpoints with tools like rclone to stage POS data prior to encryption (Microsoft).
The impact on retail is swift and severe with PCI DSS fines, loss of loyalty, competitive leakage of pricing and promotions, and credential‐stuffing fraud against shoppers are immediate fallout, all compounded by the fact that third‐party fulfilment and marketing agencies multiply the pool of insiders who can exfiltrate data as soon as they gain access to a simple HTTPS URL.
High‐probability data exfiltration in financial services and insurance (FSI) environments often begins with insider access. Quantitative analysts or fraud-analytics teams typically hold cluster admin rights, which a rogue employees could abuse by installing tools like rclone to copy data to a personal cloud bucket.
Similarly, Azure Data Factory pipelines built for regulatory reporting can be cloned, redirected to an external “evidence” store, and scheduled to run hourly, continuously siphoning sensitive data.
Even shared Databricks notebooks can become a vector, if they contain embedded service principal secrets, an attacker gains unfettered, off-network read access to trading or underwriting datasets.
Externally, attackers harvest misconfigurations and software flaws at scale. In May 2024, the Bankingly breach exposed 135,000 customer records across seven Latin-American financial institutions when threat actors discovered unsecured Azure Blob Storage buckets (Data leak hits Latin America’s financial institutions, leads point to fintech app | Cybernews).
The fallout from such exfiltration in FSI is severe. Breach notifications under GLBA, DORA, FCA/PRA, and SEC regulations carry heavy fines and scrutiny, and a leak of pre-earnings data can trigger market-manipulation investigations.
Ransomware operators demand the highest double extortion payouts for FSI data for leaked customer ID scans, loan applications, and transaction logs command premium prices on dark markets.
Before you dive into any analytics rollout, take a hard look at your risk appetite:
Build strong data foundations by classifying everything up front know what is sensitive, where it lives, and who should touch it, then design pipelines and access controls around those categories. Make sure your endpoints are locked down. Secure your data from the start, or do not be surprised when the Emergency Call Out phone rings!
So again…. Think…
Oh, and remember the reason I wrote this… it all comes down to making sure Boz Jnr gets school trousers for the new school year!
Have a question or want to make an enquiry?
Contact us
