# HideMeBr/SambaTu: a Brazilian password list for cracking and audit work

> SambaTu is a wordlist of Brazilian passwords drawn from breaches and infostealer logs, distributed as a single text file under the MIT Licence. It is a data set, not a tool, and its value depends entirely on how you feed it to Hashcat or John the Ripper.

**HideMeBr/SambaTu** — Versão Brasileira da famosa RockYou. Nesta lista de senhas existem senhas 100% brasileiras que estavam em vazamentos, logs de infostealer, etc.

- Repository: https://github.com/HideMeBr/SambaTu
- Stars: 483 · Forks: 96
- Language: Unknown
- License: not declared
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/hidemebr-sambatu

## What SambaTu actually is, and who it is written for

SambaTu is a password list. The README describes it as a curated collection of Brazilian passwords extracted from data breaches, infostealer logs and other open sources, intended for security professionals and researchers working on penetration testing, security audits and academic study. There is no executable, no library and no service. The repository holds a README and a single top-level text file, so the deliverable is the wordlist itself.

The problem it addresses is a real gap in generic cracking dictionaries. Large public wordlists are dominated by English-language patterns, keyboard walks and names that show up in North American and European breaches. Brazilian users generate different material: local names, football references, Portuguese words, and number suffixes tied to local date formats. A tester running an engagement against a Brazilian organisation who only has an English-oriented list is leaving candidate passwords untested. SambaTu is an attempt to fill that locale gap with entries the author says came from real Brazilian exposure.

The audience is narrow and technical. This is for someone who already understands what a wordlist is used for, already has a cracking rig or a GPU box, and is working inside a scope document that permits it. It is not a general-purpose security product and the README does not present it as one.

## How the wordlist is meant to be used: Hashcat and John the Ripper

The mechanism is dictionary attack. A cracking tool takes a file of hashes, reads the wordlist line by line, applies the hash function to each candidate, and compares the result against the stored digest. SambaTu supplies the candidate side of that equation. Nothing in the repository transforms the data; the file is consumed directly by the tool.

The README names two tools explicitly: John the Ripper and Hashcat. The Hashcat example uses attack mode 0, which is straight dictionary mode, and hash type 1000, which is NTLM. That choice tells you something about the intended scenario: NTLM hashes are what you encounter in Windows domain environments, so the author is thinking about internal network audits rather than web application logins. If your target is a bcrypt dump or a SHA-256 set, you change the mode number, not the wordlist.

One detail worth flagging. The Portuguese section of the README points Hashcat at `SambaTu/SambaTu.txt`, while the English section points at `SambaTu/senhas.txt`. The repository's top-level entries list only `SambaTu.txt`. Anyone following the English instructions verbatim will get a file-not-found error. Check what is actually in your clone before running anything.

## Cloning SambaTu and running a first dictionary attack

Installation is a clone. There is no package, no build step and no dependency to resolve. The README gives these two commands, and the comment notes that the list will be in the main directory once the clone finishes.

```bash
# clone the repository and enter it
git clone https://github.com/HideMeBr/SambaTu.git
cd SambaTu
# the password list will be available in the main directory
```

After that, list the directory contents. You should see the README alongside the wordlist file. Confirm the filename before you build any command around it, given the discrepancy noted above.

The README's own usage example is a straight dictionary attack against an NTLM hash file. Run it from the parent directory of the clone so the relative path resolves.

```bash
# -a 0 is straight dictionary mode, -m 1000 is NTLM
hashcat -a 0 -m 1000 arquivo_de_hashes.txt SambaTu/SambaTu.txt
```

What you should see is Hashcat loading the wordlist, reporting the number of entries, and then either recovering hashes or exhausting the list. If Hashcat exits immediately with a file error, the path or the filename is wrong, not the wordlist. Swap `-m 1000` for the mode that matches your hash type; the README does not enumerate modes because that is Hashcat's documentation, not this project's.

## The provenance problem, and when SambaTu is the wrong tool

The README says the passwords come from data breaches, infostealer logs and other open sources. It does not say which breaches, how many entries the list contains, when each source was collected, or how duplicates and low-quality entries were filtered. The repository has no changelog, no release history and no data dictionary. That is a genuine limitation, not a minor documentation gap.

For an academic study, provenance is the whole argument. If you cannot state where your corpus came from and how it was assembled, reviewers will treat your frequency analysis as unreproducible. SambaTu gives you a file and a one-paragraph description. That is enough for a penetration test where the list is one of several dictionaries you throw at a hash set, and not enough for a paper that makes claims about Brazilian password composition.

There is a second case where this is the wrong tool. If your target population is not Brazilian, the locale advantage disappears and you are better served by a general-purpose list with broader coverage. The README makes no claim to compete on size against the large international wordlists, and the repository layout suggests the file is modest. Treat SambaTu as a supplement to your existing dictionaries, not a replacement.

Finally, the legal and ethical boundary. The README scopes the project to penetration testing and academic research, but holding breach-derived credentials is regulated in many jurisdictions regardless of intent. If you do not have written authorisation for the systems you are testing, or a data handling policy that covers this material, the tool is not the problem. Your process is.

## SambaTu versus compiling your own locale wordlist

The obvious alternative is not another named product. It is building the list yourself from Brazilian public sources: scraped name registries, Portuguese dictionary dumps, football club rosters, common date formats, and the standard mangling rules that generate the `nome + ano` pattern so common in Brazilian credentials. That approach gives you full control over provenance, size and licensing, and you can version it in your own repository.

The difference in approach is one of effort against traceability. SambaTu hands you a curated file today, with no assembly work and no source-attribution burden, under the MIT Licence. A self-compiled list costs you days of collection and cleaning, but you can document every source and defend the methodology in a review. If your work needs an auditable chain of custody, the DIY route is the one that survives scrutiny.

A middle path is to use SambaTu as one input among several and run Hashcat rules on top of it. Rules expand each dictionary entry into many candidates, which multiplies the effective coverage without you curating anything. That is a Hashcat feature, not a SambaTu one, and the README does not mention rules at all, so treat it as your own addition to the workflow.

## Licence, maintenance and the cost of keeping up

The README states that the project is licensed under the MIT Licence. That is permissive: you can use, modify and redistribute the list, including commercially, provided the licence and copyright notice travel with it. What MIT does not do is resolve the underlying question of the data. A permissive licence on a compilation does not automatically grant you rights over the breach-derived content inside it, and the README offers no statement about consent, anonymisation or source permissions. If you plan to redistribute the list or ship it inside a product, that is a question for your own legal review, not something the repository answers.

The repository is not archived, and the last push was on 2026-08-15. That is recent enough that the project is not abandoned, but there are no releases in the repository and no version tags, so there is no upgrade path in the conventional sense. You get whatever the default branch holds at clone time. If the author adds entries later, you re-clone or pull, and your previous test results are no longer reproducible against the same file unless you pinned a commit hash.

That is the real maintenance cost. Pin the commit you used in any report, because the wordlist is mutable and unversioned. A test run last month and a test run today may not be the same test.

## Conclusion

Adopt SambaTu if you run authorised password audits against Brazilian user bases or need a locale-specific wordlist for academic work, and you already have Hashcat or John the Ripper in place. Skip it if you need a maintained, versioned data set with documented provenance, or if you are not cleared to handle breach-derived credential material. Before using it, check the actual filename in the repository root and confirm the licence file is present alongside the README, because the English and Portuguese usage examples do not agree on the name.

## FAQ

### What does the name SambaTu mean?

The README does not explain the name. It only describes the project as a Brazilian password list, and the repository is published under the HideMeBr organisation. No origin for the word is given.

### Is SambaTu the same as RockYou?

No. The repository description calls it the Brazilian version of RockYou, which describes its role as a locale-specific wordlist rather than a copy of that list. The README states the entries come from Brazilian data breaches and infostealer logs.

### How do I install SambaTu and use it with Hashcat?

Clone the repository with git, then run Hashcat in straight dictionary mode against your hash file, pointing the last argument at the wordlist. The Portuguese README uses SambaTu/SambaTu.txt while the English section uses SambaTu/senhas.txt, so verify the actual filename in your clone first.

### What licence does SambaTu use?

The README states the project is licensed under the MIT Licence. There is no separate licence file in the repository and no statement about the rights attached to the underlying breach data.

## Sources

- [HideMeBr/SambaTu on GitHub](https://github.com/HideMeBr/SambaTu)
- [Issues](https://github.com/HideMeBr/SambaTu/issues)
- [README](https://github.com/HideMeBr/SambaTu/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hidemebr-sambatu