New Tools, New Errors: Deploying TheHive & Cortex on Kali Linux with Docker

“Every new tool is a lesson in patience, precision, and unexpected problems.”

As a Security Analyst, I’m always on the lookout for open-source tooling that elevates threat detection, incident response, and case management. Recently, I decided to dive into TheHive ,a powerful Security Incident Response Platform (SIRP), alongside its analyst-friendly companion, Cortex.

Like most promising tools in infosec, the install process didn’t go quietly.

This blog captures the raw, unpolished journey of deploying TheHive using Docker on Kali Linux, from pulling the image to hitting cryptic errors, chasing down missing directories, and ultimately documenting what actually works and what doesn’t.

The Plan

Pull Docker images for TheHive and Cortex.
Run containers, map ports, and mount volumes.
Start analyzing incidents like a boss.

Reality:
“Container started.”
Then:

AccessDeniedException: /opt/thp/thehive/db/je.properties

Let’s break it all down, step by painful step.

Step 1: Pulling TheHive Docker Image

docker pull strangebee/thehive:5.0.23
docker run -d --name thehive -p 9000:9000 strangebee/thehive:5.0.23

Step 2: Java Death Logs Begin

org.thp.scalligraph.ScalligraphApplicationImpl$InitialisationFailure: /opt/thp/thehive/db/je.properties
Caused by: java.nio.file.AccessDeniedException

This screamed BerkeleyDB and permission issues.

Step 3: File Doesn’t Exist?

Ran this:

ls -l /opt/thp/thehive/db/je.properties

No such file or directory.

Tried to fix permissions anyway:

sudo chown -R thehive:thehive /opt/thp

sudo chown -R thehive:thehive /opt/thp

Result?

invalid user: thehive:thehive

Naturally. There’s no “thehive” user, we’re in Docker land, not systemd territory.

Step 4: Clean It All Up

At this point, I made a call, let’s delete TheHive and reinstall:

docker ps -a                    # Find container ID
docker rm <container-id>        # Remove it
docker rmi <image-id>           # Remove image

docker rmi <image-id> # Remove image

Only after killing the container was I allowed to delete the image.

Step 5: Docker Compose Templates Galore

Navigated to my Docker templates folder, and guess what?

cd ~/Docker-Templates/docker/

Over 10+ TheHive variations, from thehive4-cortex31-nginx-https to thehive35-cortex3-es7. Overwhelming? A bit. But the community support is real.

Step 6: Cortex. Still Untested, but Pulled

docker pull cortexproject/cortex:latest

Image pulled, ready to test, but I paused deployment until I got TheHive running cleanly.

Lessons Learned

TheHive loves /opt/thp – volume mapping must preserve proper ownership inside Docker.
Don’t chase systemd configs for containers. Look inside the Dockerfiles or use Docker Compose.
BerkeleyDB = permission pain. Consider switching to ScyllaDB or Cassandra templates.
Don’t assume success because a container “starts.” Watch the logs and they tell the real story.

What’s Next?

Use a full Docker Compose setup (like thehive5-minimal) with proper mounted volumes.
Switch to ScyllaDB or Cassandra to avoid BerkeleyDB permission madness.
Integrate Cortex once TheHive runs reliably.
Push all findings to GitHub repo with full logs, Dockerfiles, and templates.

Final Thoughts

Every new tool in cybersecurity brings power and pain. And that’s okay. Debugging teaches you more than smooth installs ever will. If you’re in the SOC world, automating and orchestrating investigations is worth the setup struggles.

Let me know if you’re deploying TheHive/Cortex and hit similar snags. I’d love to collaborate or share working configs.

Until then…
New tools, new errors. Bring them on.

Written by: Manish Rawat
Security Analyst | SOC Automation Enthusiast

Deploying, Breaking, and Documenting Cyber Tools One Error at a Time

🔧 New Tools, New Errors: Deploying TheHive & Cortex on Kali Linux with Docker was originally published in OSINT Team on Medium, where people are continuing the conversation by highlighting and responding to this story.