In late August 2026, a self-described hacking group put Morocco back in the international data-leak headlines. A Morocco data leak claim by a group calling itself “Jabaroot” alleged that personal records on roughly 70,000 people described as police (DGSN) and territorial surveillance (DGST) personnel had been exposed. Within days the agencies issued a formal, categorical denial, and independent Moroccan journalists began finding holes in the claim itself.
For Moroccan businesses, the headline is not the point. The pattern underneath it is. An organization’s name can end up at the center of a leak claim without a single one of its own systems being compromised, because the real exposure often sits with a vendor, insurer, or service provider that holds the same people’s data.
This article covers what is confirmed about the Morocco data leak claim, then gives you the framework to verify any leak claim, trace its likely origin, and respond in the first 48 hours.
Morocco Data Leak: What the Jabaroot Claim Actually Says
On 24 August 2026, a group calling itself “Jabaroot” published files on Telegram claiming to expose personal data belonging to roughly 70,000 people it described as officers of Morocco’s national police (DGSN) and the territorial surveillance directorate (DGST). The files reportedly included names, dates of birth, national ID numbers, personnel numbers, recruitment dates and, for some records, ranks and banking details.
According to its own messaging, the group presents itself as pro-Algerian and frames the release as a response to the Ceuta migration events of late July 2026. These are the attackers’ own claims about their identity and motive, not independently verified facts.
Three days later, on 27 August 2026, the DGSN-DGST pole issued a formal communique categorically denying any intrusion into its information systems or secure databases, stating that those systems meet the “strictest cybersecurity standards” and are “disconnected from networks open to the internet.”
Authorities state that the circulating data came from old records originating with insurance companies and health or social-coverage organizations rather than the agencies’ own systems, and pointed to specific evidence of staleness: recruitment dates that stop around 2020, the presence of deceased individuals, ranks and uniform descriptions that “do not exist” in Morocco, incorrect photos, and grammatical errors. An investigation has been opened under the supervision of the public prosecutor.
Independent reporting supports parts of that account without confirming all of it. Jeune Afrique and Le Courrier de l’Atlas separately identified Abdelhak Khiame, a former director of the BCIJ who died in 2022, among the records, a finding made by journalists rather than only asserted by the agencies. Medias24 published its own analysis on 25 August concluding that the claimed “list of 70,000 spies” largely fizzled once examined closely.
None of this proves the entire dataset is fabricated, and no independent forensic confirmation of its source is publicly available, but the evidence points to a stale, padded file rather than a fresh breach.
This is not Jabaroot’s first claim against a Moroccan target: the group was linked to an earlier incident recapped in SecureWeb’s CNSS data breach report.
Why a Morocco Data Leak Can Happen Without Your Systems Being Breached
The DGSN-DGST case is a clean illustration of something every Moroccan organization needs to understand: a firm denial of intrusion into your own systems and a real leak of your people’s personal data are not contradictory. Both can be true at the same time.
Here is the mechanism. Your organization is rarely the only place your employees’ data lives. Over a career, an employee’s name, ID number and other details pass through a health insurer, a payroll processor, a benefits administrator, a recruitment agency, and whatever SaaS platform your HR team uses.
Each holds a copy of data your own systems also hold, and each is a separate target with its own security posture, one you do not control and often do not audit. When one of them is breached or simply lets an old export circulate, the leaked data describes your people, so your name ends up attached to the story even though the incident never touched your network.
That is precisely the pattern authorities describe in this case: DGSN and DGST deny any intrusion into their own systems while stating that the underlying records trace back to insurance and health or social-coverage bodies. Whether that account is fully accurate cannot be independently confirmed from the outside, but it describes a genuine and common failure mode, not an unusual excuse.
The practical lesson for any Moroccan organization facing a leak claim: do not treat “we checked our servers and found nothing” as the end of your investigation, and do not treat a dramatic leak claim as automatically true either.
How to Tell a Fresh Breach From a Recycled or Padded Dataset
Not every file published with a shocking headline is a fresh breach. Attackers, and opportunists repackaging old material, have an incentive to make a claim look as current and as large as possible, because size and freshness generate attention. Reading the data itself is the core skill behind data breach verification. Five signals are worth checking every time:
- A hard ceiling on recent dates. If every “recent” hire or activity date in a supposedly current database stops at the same year, 2020 in this case, the underlying export was most likely taken around then rather than last week. An organization that hires continuously would show dates running up close to the leak date, not a wall years in the past. That ceiling works like a shipping date stamped on a box: it tells you when the data left the building, not what it reflects today.
- Duplicate or deceased identities. A record for someone known to have died, as journalists independently identified in this case, is one of the clearest signs a dataset is not being kept current. A properly maintained personnel system reflects the current workforce; a record that keeps a deceased person “active” tells you the file was copied at some point in the past and never updated since.
- Ranks, titles, or formatting that do not match reality. When a leak stitches together fields from more than one source, it can end up with a rank or uniform description that does not exist in the institution it claims to represent. That mismatch suggests the record was not pulled from that organization’s HR system at all, but sourced elsewhere and relabeled to fit the story.
- Mismatched metadata. Incorrect photos and grammatical errors are the signature of a claim assembled quickly for headline impact. A genuine breach of a well-run system usually preserves internal consistency, because the data was taken as one coherent extract.
- Claims that cannot be independently verified. Where the true origin of the data cannot be confirmed by anyone outside the group making the claim or the organization denying it, treat the claim as unresolved. Do not dismiss it outright, and do not accept it at face value.
Several of the agencies’ own points map directly onto these signals: the 2020 ceiling, a deceased former official, non-existent ranks, and formatting errors. That combination is why outlets like Medias24 reached a skeptical conclusion, not because a denial was issued, but because the data itself showed the marks of an old, recycled file.
The Supply Chain: The Most Likely Source of a Morocco Data Leak
If a leak claim about your organization turns out to include real personal data, the supply chain rather than your own core systems is statistically the most likely place it came from. That is true for any Moroccan business, not only security agencies.
Consider how many parties legitimately hold a copy of one employee’s personal data: a health or life insurer, a national social-coverage body, a payroll or HR vendor, a benefits administrator, a recruitment agency, an IT contractor with administrative access. Each is a separate organization with its own security budget and its own patching history.
You cannot secure what you do not control, and most businesses have never mapped who holds copies of their people’s data outside their own walls.
The math favors the vendor: if ten of them each hold a piece of your employee data, and each carries even a small annual chance of an incident, the odds that at least one is compromised in a given year are far higher than the odds for your own, better-resourced systems.
Once data leaks, regardless of where it originated, it rarely stays in one place. Files posted to a channel like Telegram typically also make their way to dark web marketplaces and forums, where they can be resold, repackaged, and recirculated months or years later under a new claim, as SecureWeb has covered in how leaked data circulates and is monetized on the dark web.
Some of that circulation is opportunistic; some is used deliberately to pressure or extort the organization whose name is attached to the data, a pattern explored in SecureWeb’s guide to how cyber extortion works.
The practical takeaway: map every third party that holds personal data on your employees or customers, and require each to demonstrate baseline security practices as an ongoing requirement, not a one-time procurement checkbox.
Your First 48 Hours When Your Company’s Name Appears in a Leak Claim
When your organization’s name surfaces in a leak claim, the first two days set the tone for everything that follows. A rushed denial and a rushed admission can both cause damage that outlasts the original claim. Use this sequence:
- Verify before you panic or deny. Have your security team, not untrained staff, review a sample of the claimed data through controlled channels and check it against the five staleness signals above. Never visit or interact with a leak channel directly, and never attempt to download the full dataset.
- Determine likely scope and origin. Is the data genuinely yours, does it trace to a vendor in your supply chain, or does it show clear signs of padding? This shapes everything that follows, including who else needs to be involved.
- Notify affected parties and the relevant regulator once you have a credible read on scope. Morocco’s Law 09-08 on the protection of personal data sets out notification obligations for organizations handling personal data; SecureWeb’s overview of Moroccan cybersecurity laws and notification obligations walks through what applies and when. Honest, updated communication is safer than silence.
- Coordinate one internal message. Agree on a single, factual account that every spokesperson and manager repeats, so the organization is not publicly contradicting itself while the investigation continues.
- Engage a forensic partner. An experienced incident response team can confirm origin and scope with evidence, helping you avoid both failure modes: over-claiming that nothing happened before the investigation is complete, and staying silent while evidence keeps circulating.
A Morocco data leak claim can be entirely wrong about your organization’s own systems and still be worth taking seriously, because the risk to your people’s data rarely starts and ends inside your own network.
Frequently Asked Questions
Was DGSN or DGST actually hacked in this Morocco data leak?
DGSN and DGST issued a formal communique on 27 August 2026 categorically denying any intrusion, stating those systems are not connected to the open internet. Authorities state the circulating data originates from old insurance and health or social-coverage records rather than their own databases. Independent Moroccan reporting, including Medias24’s fact-check, found the claim did not hold up under scrutiny.
What did the Jabaroot Morocco data leak claim include?
Files published on Telegram on 24 August 2026 claimed to contain data on roughly 70,000 people described as DGSN and DGST personnel: names, dates of birth, national ID numbers, personnel numbers, recruitment dates, and for some records ranks and banking details.
How can I check if my data was leaked in the Jabaroot Morocco data leak?
SecureWeb does not link to or reproduce leaked datasets, and individuals should not seek out the Telegram files directly. If you believe your information may be affected, monitor official DGSN and DGST statements and consider a professional dark web monitoring service, which can flag your details without you needing to search leak channels yourself.
What should a Moroccan business do if its name appears in a data leak claim?
Verify the data before reacting, determine likely scope and origin including your vendor chain, notify affected parties and regulators as required under Law 09-08, issue one coordinated message, and engage a forensic partner to confirm the findings.
Sources
- Le Desk, 27 Aug 2026: Fuite Jabaroot : la DGSN et la DGST démentent tout piratage de leurs systèmes
- La Vie Eco, 27 Aug 2026: Fuite de données : la DGSN-DGST dément toute intrusion
- Barlamane FR, 27-28 Aug 2026: La fuite de données sur des agents de sécurité marocains mêle fichiers anciens et renseignements administratifs
- Le Courrier de l’Atlas: Jabaroot, fausse liste de 70 000 agents marocains
- Jeune Afrique: Maroc : ce que l’on sait de la dernière fuite sécuritaire de Jabaroot
- Medias24, 25 Aug 2026: Une fuite attribuée à Jabaroot “fait pschiitt”
- Maroc Hebdo: Fuite Jabaroot : le pôle DGSN-DGST dément toute intrusion
- Yabiladi: Maroc : DGSN-DGST dément piratage
