Hacking the Cloud: a volunteer-run cloud attack encyclopedia built on MkDocs

What hackingthe.cloud actually is, and who it is written for

The README calls the project "an encyclopedia of the attacks/tactics/techniques that offensive security professionals can use on their next cloud exploitation adventure." That sentence describes the format accurately. There is no scanner, no agent, no library to import. The repository holds prose: content/ for the pages, layouts/ and overrides/ for the site chrome, and MkDocs configuration files that turn the Markdown into a website. The stated audience is offensive security professionals, but the README is explicit that defensive knowledge is welcome too, on the reasoning that the goal is to make cloud environments safer. In practice that means a detection engineer reading a technique page to work out what telemetry the technique leaves behind is as much the target reader as a penetration tester. The topics list on the repository covers AWS, Azure, GCP, Docker, Terraform and Kubernetes, and the README says content from any major cloud provider is accepted. The scope is deliberately wider than the name suggests.

The build path: MkDocs Material, four pip installs, one container

The whole publishing pipeline is visible in the Dockerfile. It starts from the squidfunk/mkdocs-material image and layers four plugins on top: mkdocs-awesome-pages-plugin, mkdocs-redirects, mkdocs-rss-plugin and mkdocs-glightbox. Each one maps to a visible feature. awesome-pages lets the navigation be defined in the content tree rather than hand-listed in mkdocs.yml, which matters when volunteers add pages without touching the config. redirects preserves old URLs when a page moves, and a community-edited wiki moves pages often. The RSS plugin produces a feed, so new technique write-ups can be followed without checking the site. glightbox handles image lightboxing, which the README's note about "adding a screenshot" implies is a normal contribution. Two MkDocs configs exist: mkdocs.yml for local work and mkdocs.deploy.yml for the deployed build, with a GitHub Actions workflow named deploy v2 handling publication. The site is static output. Nothing in this repository executes against a cloud account, which is worth stating plainly because the name invites the opposite assumption.

Running the site locally with the dev.Dockerfile

The repository carries both a Dockerfile for the published image and a dev.Dockerfile for local work, and the README points contributors at CONTRIBUTING.md for the details. The published image is the base for the deploy path:

FROM squidfunk/mkdocs-material
RUN pip install mkdocs-awesome-pages-plugin
RUN pip install mkdocs-redirects
RUN pip install mkdocs-rss-plugin
RUN pip install mkdocs-glightbox

Building that image gives you the same plugin set the live site uses, so a page that renders locally renders in production. If you would rather not build anything, the upstream squidfunk/mkdocs-material image already serves Markdown, and the four plugins are the only additions this project makes. What you should see after starting the server is the MkDocs Material theme with the Hacking the Cloud wordmark from content/images/branding/hacking-the-cloud-wordmark.jpg, and a navigation tree generated from the content directory rather than from a hand-maintained list. The CONTRIBUTING.md file is the authority on the exact serve command and on where new pages belong; the README does not repeat it.

Contributing a technique page, and the credit rule

Contribution is a pull request against the main branch. The README is unusually relaxed about form: "Don't worry about submitting content in the wrong format or what section it should be a part of, we can always make improvements later." That lowers the barrier for a first-time contributor, and it also means the repository accepts pages that later get restructured. There is one firm editorial requirement, and it is the interesting one: credit the researcher who discovered the technique and link to their site or talk. For an encyclopedia assembled from conference talks and blog posts, that rule is what separates it from a scraped link dump. The README also invites edits to existing pages, not just new ones, and lists grammar fixes and screenshots as welcome. Practically, a contribution is a Markdown file under content/ plus whatever images it needs. The plugin set means you do not have to register the page in a navigation file; awesome-pages picks it up from the directory structure. The deploy workflow runs on merge, so the review step is the only gate between your page and the live site.

Where the coverage is thin, and what that means for a reader

The roadmap section is candid: "Currently the site has some material on AWS, and very little for Azure or GCP." That is the project describing its own gap, and it lines up with the topics list, where AWS and aws-hacking appear alongside the broader cloud-security tags. For anyone evaluating the site as a reference, the consequence is concrete. If your environment is AWS, there is a body of technique pages to work through. If you are assessing an Azure or GCP estate, you will find the index sparse and will end up back at vendor documentation and individual researcher blogs. The README frames this as an invitation rather than a defect, and it is a fair framing for a volunteer project, but a reader deciding where to spend an afternoon should know which shelf is stocked. The second limitation follows from the first: because content is volunteer-written and reviewed by pull request, depth per page varies, and the README's own instruction not to worry about format means the editorial standard is applied after submission rather than before.

How it differs from a vendor knowledge base or a lab platform

The obvious alternative for cloud attack knowledge is the cloud providers' own security documentation and their public post-mortems. Those are authoritative about what a service does and what the provider considers a misconfiguration, but they are written from the defender's side of the boundary and are not organised around attack chains. Hacking the Cloud is organised the other way: the unit is a technique, and the reader is assumed to be the person executing it or detecting it. A second alternative is a hands-on lab platform, where you rent a deliberately vulnerable cloud account and practise. That is a different product entirely. Labs give you an environment and a scoring path; this repository gives you reading material and a place to publish, with no environment attached. The trade-off is straightforward. You get breadth of technique description across providers and a low-friction path to adding your own, and you give up any guarantee of completeness, any hands-on validation, and any vendor's authority on what is actually supported behaviour.

Maintenance, licensing and what to check before you rely on it

The repository is not archived, and the last push was on 2026-09-22, days before this writing, so the project is receiving changes. Releases are tagged on a v2.4.x line, with v2.4.19 on 2026-05-05, v2.4.18 on 2026-03-17 and v2.4.17 on 2026-01-05, roughly a release every six to ten weeks. Upgrading is not something you do to a deployment, because you are not deploying anything: you either read the live site or run the MkDocs container, and the upgrade cost is the cost of rebuilding that image when the plugin set changes. The Dockerfile pins no plugin versions, so a rebuild can pull newer plugin releases than the last build did. That is the one operational detail worth knowing. On licensing, the repository's licence is reported as NOASSERTION, which means the LICENSE file was not recognised as a standard template. The README grants no additional terms, and the contributing guidelines do not discuss licensing of submitted content. If you intend to reuse pages, check the LICENSE file directly rather than assuming a permissive default, and if you are contributing, establish who holds the rights to your text before you submit it.

Editorial conclusion

Adopt it as a reading list and a place to publish if you work in cloud offensive security or detection engineering, and check the AWS pages first because that is where the material is thickest. Do not adopt it if you need complete Azure or GCP coverage, or if you want a tool that runs against an account: the repository ships a documentation site and a Dockerfile, nothing that touches a cloud API. Before contributing, read CONTRIBUTING.md and confirm whether the NOASSERTION licence label matches the terms you need, since the LICENSE file is not the standard MIT text.

Frequently asked questions

Official sources

1. Hacking-the-Cloud/hackingthe.cloud on GitHub
2. Issues
3. Project website
4. README
5. Releases