• DevSecOps Guides - Comprehensive DevSecOps documentation
• Secure Code Warrior - Secure coding training platform
• SonarSource Code Challenges - Code security challenges
• TryHackMe DevSecOps Path - Hands-on DevSecOps learning path
• Google Cloud Skills Boost - Cloud security training
• DevSecOps Awesome List - Curated DevSecOps tools and resources
• DevSecOps Vault - DevSecOps knowledge base
• AppSec Engineer - Application security training
• hahwul/DevSecOps - DevSecOps tools collection

A container is an isolated environment for your code. It has no knowledge of your operating system or your files. Containers have everything that your code needs in order to run, down to a base operating system.

What is Container Security?

Container security refers to measures and practices taken to ensure the safety and integrity of containers. It comprises everything from the applications inside the containers to the infrastructure they run on. Base image security and quality are critical to ensure that any derivative images come from a trusted source.

Security Standards

1. CIS Docker Benchmark - Guidelines for securing Docker containers covering runtime, daemon config, image security, networking, and logging
2. NIST SP 800-190 - Container security challenges and best practices
3. Docker Security Best Practices - Practical, Docker-specific guidelines
4. PCI DSS / HIPAA - Compliance standards with specific container guidance
5. OWASP - Application security perspective for containers
6. ISO/IEC 27001 - Broad information security framework applicable to Docker environments

Core Threats

1. Data Breaches - Unauthorized access to sensitive data within containers
2. Insecure Base Images - Outdated or unpatched base images introduce vulnerabilities
3. Untrusted Image Registries - Malicious images from untrusted sources
4. Container Escape Vulnerabilities - Breaking out of the container to access the host
5. Misconfigurations - Excessive privileges or weak security settings
6. Insider Threats - Unauthorized insiders exploiting privileged container environments
7. Third-Party Vulnerabilities - Vulnerable components integrated into containers
8. Container Orchestration - Misconfigurations in Kubernetes and service mesh tools

Types of Security Solutions

Container Monitoring

Tools like Dynatrace, Datadog, Prometheus, Grafana, Elasticsearch and cAdvisor provide performance metrics, real-time log streaming, anomaly detection, and alerting.

Container Scanning

Image scanners identify vulnerabilities, misconfigurations, and security issues within container images and their runtime environments.

Application-Level Scanning

• SCA (Software Composition Analysis) - Scans dependencies for vulnerabilities
• SAST (Static Application Security Testing) - Analyzes source code before compile (white box)
• DAST (Dynamic Application Security Testing) - Tests running applications (black box)
• SBOM (Software Bill of Materials) - Lists all components for supply chain risk assessment

Container Security Architecture

CI/CD Build Environment

Automated tests must ensure images don’t include outdated or insecure components. The CI/CD infrastructure itself must be secured to prevent supply chain attacks.

Container Registries

Central repositories for storing and scanning container images. Treat images as immutable artifacts. This allows quick replacement or rollback of high-risk containers.

Runtime Environments

Implement security policies governing container behavior at runtime. Monitor and manage resources to prevent abuse.

Container Orchestration

Kubernetes is crucial but complex. Misconfigurations can allow attackers to compromise nodes or the entire cluster.

Container Networking Security

Strategies for secure container networking:

1. Network Isolation

• Microsegmentation - Divide network into isolated segments
• Container Network Policies (CNPs) - Granular access rules per container

2. Encryption

• TLS for data in transit
• Encrypt container images at rest

3. Authentication & Authorization

• Mutual TLS (mTLS) between containers
• Role-Based Access Control (RBAC)

4. Monitoring & Logging

• Monitor for suspicious traffic patterns
• Enable logging for all network activity

5. Tools

• Next-generation firewalls for container traffic
• SIEM systems for log analysis
• Service mesh (Istio) for mTLS, encryption, and access control

Security Checklist

Secure the Build Pipeline

• Verify the image source (registry)
• Use official base images
• Lock down access to the image registry
• Scan container image layers for CVEs
• Scan configuration files for security in CI
• Static analysis of code and dependencies
• Tag and prevent vulnerable images from running

Secure the Host

• Lock down the OS (e.g., Container Optimized OS)
• Use seccomp to restrict syscall access
• Use SELinux for container isolation
• Utilize container sandboxing (gVisor, Kata Containers)

Secure Container Runtimes

• Ensure security configs span all runtimes
• Use pod security policies to restrict privileged containers
• Restrict access to runtime daemon/APIs

Secure the Network

• Firewall for internet-exposed services
• Layer 3/4 network policies
• Layer 7 policies via service mesh
• mTLS for workload authentication
• Segregate workloads with host/network isolation
• Log unsuccessful connection attempts

Secure the Orchestrator

• Version control for service definitions (git)
• RBAC for orchestrator API access
• Audit third-party plugins (CNIs, CSIs, CRIs)
• Enable API access audit logs
• Scan Kubernetes manifests in CI
• Encrypt secrets and rotate encryption keys

Secure the Data

• Filesystem encryption for container storage
• Minimal write/execute access
• Scan images for embedded secrets before pushing
• Limit storage-related syscalls
• Log all access attempts to sensitive data

Container Security Tools

Monitoring

Scanning

Dockerfile & Container Testing

Dockerfile Testing (before deployment):

• Linting with Hadolint, Dockle
• Static analysis with Snyk, Anchore

Container Testing (after deployment):

• Unit testing of individual components
• Integration testing between containers
• End-to-end testing for real-world scenarios
• Security testing with Clair, Trivy

Technologies:

• Jenkins (Local installation)
• SonarQube (Dockerized)

We will use a vulnerable web application named Vulnado for testing.

Jenkins Installation

There are different ways to install Jenkins but I chose the easiest way. You can install Jenkins with package managers like apt/snap or follow the official installation guide. Also you can run Jenkins on Docker but this is not preferred.

Docker Installation

We are installing Docker to run SonarQube on Docker:

Configuring Jenkins

After installation you can reach Jenkins’s web interface from browser at localhost:8080 (default):

Getting the initial admin password:

After you logged in, Jenkins asks which plugins to install. I chose suggested plugins:

Create the first admin user:

Configure the Jenkins URL:

And here’s the Jenkins main page:

Creating the Pipeline

Press “New Item”, select Pipeline and give it a name:

In the opened page scroll down to the Pipeline section. This is the editor we are going to use:

Jenkins has a syntax for pipeline scripting. It’s easy to understand and use.

Stage 1: Install the Project

The first part of our pipeline - installing the project from Git:

Stage 2: Build the Project

Second part - building the project (before build: sudo apt-get install maven -y):

After building, your pipeline should look like this:

Setting Up SonarQube

We have installed and built the project in Jenkins. Now let’s start security testing!

Pull the SonarQube image:

Run SonarQube in a container:

Check if it’s working:

Access SonarQube at localhost:9000 with default credentials admin:admin:

Reset your password:

SonarQube Project Setup

Choose “Create a local project”:

Fill the name and key:

Choose “Use global settings”:

Choose Jenkins as analysis method:

Choose GitHub:

Choose Maven - SonarQube gives us a Jenkinsfile but this script needs modification:

Integrating SonarQube with Jenkins

In SonarQube, go to My Account > Security > Generate new token (Global Analysis Token):

In Jenkins Dashboard > Manage Jenkins:

Install the SonarQube Scanner plugin:

Go to Manage Jenkins > Credentials > Add credential:

Select “Secret text” and paste the SonarQube Global Analysis Token:

Manage Jenkins > System > SonarQube installations. Give a name, write the URL, and choose the token:

Final Pipeline

Your pipeline should look like this:

And this is how stages should look:

And this is the SonarQube dashboard with results:

Add the Jenkins repository and install:

sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt-get update
sudo apt-get install jenkins

Access the Web Interface

After installation, Jenkins works on localhost:8080:

You can use cat command or a text editor to see the admin password (directory can change depending on your installation method):

Initial Setup

After you log in and install plugins you can create admin user:

After you fill in the form, you can change port and URL of your Jenkins instance:

And here we successfully installed Jenkins:

Changing the Port

Jenkins starts on port 8080 by default. You can change the port in the web interface but sometimes you need to start Jenkins from a different port. To do this, go to the Jenkins directory /opt/jenkins/ or /snap/jenkins and run:

java -jar jenkins.war --httpPort=<port_number>

$ volatility -f <example.raw> imageinfo

Process Analysis

# List processes
$ volatility -f <example.raw> --profile=<profile> pslist

# Process tree
$ volatility -f <example.raw> --profile=<profile> pstree

# Process scan (includes hidden/terminated)
$ volatility -f <example.raw> --profile=<profile> psscan

# Generate graph visualization
$ volatility -f <example.raw> --profile=<profile> psscan --output=dot --output-file=<filename.dot>

# Dump process
$ volatility -f <example.raw> --profile=<profile> procdump -p <pid> -D <output/>

Command Line Artifacts

# Executed commands
$ volatility -f <example.raw> --profile=<profile> cmdscan

# Console outputs
$ volatility -f <example.raw> --profile=<profile> consoles

# Command line arguments (all processes)
$ volatility -f <example.raw> --profile=<profile> cmdline

# Command line for specific PID
$ volatility -f <example.raw> --profile=<profile> cmdline -p <pid>

System Information

# Environment variables
$ volatility -f <example.raw> --profile=<profile> envars

# NTLM password hashes
$ volatility -f <example.raw> --profile=<profile> hashdump

Network

$ volatility -f <example.raw> --profile=<profile> netscan

DLL & Module Analysis

# List loaded DLLs
$ volatility -f <example.raw> --profile=<profile> dlllist -p <pid>

# Dump specific DLL
$ volatility -f <example.raw> --profile=<profile> dlldump -p <pid> -b <base_address> -D <output_directory>

Registry

$ volatility -f <example.raw> --profile=<profile> dumpregistry -D <output_directory>

File Operations

# Scan for files
$ volatility -f <example.raw> --profile=<profile> filescan | grep <filename>

# Extract file from memory
$ volatility -f <example.raw> --profile=<profile> dumpfiles -Q <dataoffset> -D <output-directory>

Change file extension after extracting based on actual file type.

Memory Analysis

# Extract process memory (change extension to .data)
$ volatility -f <example.raw> --profile=<profile> memdump -p <pid> -D <output>

# List handles
$ volatility -f <example.raw> --profile=<profile> handles -p <pid> -t <type>
# Types: mutant, process, file, key, etc.

# Find injected code / suspicious memory allocations
$ volatility -f <example.raw> --profile=<profile> malfind -p <pid>

# Dump memory region
$ volatility -f <example.raw> --profile=<profile> vaddump -b <base_address> -D <output_directory>

Yara Scanning

$ volatility -f <example.raw> --profile=<profile> yarascan -Y "<yara_rule>"

Browser Artifacts

# Chrome history (requires volatility-plugins)
# Download: https://github.com/superponible/volatility-plugins
$ volatility --plugins=plugins/ -f <example.raw> --profile=<profile> chromehistory > <output_file>

# IE history
$ volatility -f <example.raw> --profile=<profile> iehistory

Alternative: extract browser history file and open it in SQLite.

Quick Reference

We received this memory dump from our client recently. Someone accessed his system when he was not there and he found some rather strange files being accessed. Find those files and they might be useful.

“The names were not readable. They were composed of alphabets and numbers but I wasn’t able to make out what exactly it was.”

Also, he noticed his most loved application that he always used crashed every time he ran it. Was it a virus?

Note-1: This challenge is composed of 3 flags.
Note-2: There was a small mistake when making this challenge. If you find any string which has L4B_3_D0n3!! in it, please change it to L4B_5_D0n3!! and then proceed.
Note-3: You’ll get the stage 2 flag only when you have the stage 1 flag.

Solution

Stage 1: Encrypted File Names

First step let’s get the image info:

In second step I use pslist command for listing processes and I found these suspicious processes for now:

cmdscan and consoles commands didn’t show anything. Then I used pstree command and I can see that some of our suspicious processes TCPSVCS.exe and WerFault.exe were triggered by services.exe.

With cmdline command I found a RAR file, I am going to try to dump this file.

Here I found and dumped the file.

Okey this RAR archive is password protected. I will use envars command.

envars command and some other commands don’t help with the password but I found a file with iehistory command. The name of this file looks like an encrypted string - let’s decode it:

And here! There is a flag: flag{!!_w3LL_d0n3_St4g3-1_0f_L4B_5_D0n3_!!}

The description says that there are 3 flags in this lab and we cannot pass to the 2nd stage without the first flag. If we are lucky this is the first flag:

Stage 2: The RAR Archive

Yes! The first flag is the password for the RAR archive:

There was only an image file in the RAR archive and I find the second flag but description says we have one more flag:

Stage 3: Reverse Engineering

For the last stage I am going to investigate another suspicious process - NOTEPAD.exe.

I found and dumped the suspicious exe and here I dumped 3 files.

file.dat was the file we were looking for. This was actually an .exe file. So I tried to analyze it. I used different PE analysis tools, string scanning tools and Detect-It-Easy but I couldn’t find anything. After these attempts I decided to start reverse engineering. After spending some time in Ghidra and IDA Free I found the flag with IDA Graph View.

The last flag was: bios{M3m_l4B5_OVeR_!}

Key Takeaways

• IE history (iehistory plugin) can reveal interesting file access patterns
• Encrypted/encoded file names are worth decoding - they might contain flags
• Flags from earlier stages can serve as passwords for later stages
• When standard forensics tools fail, reverse engineering (IDA/Ghidra) can reveal hidden strings in executables
• Dumped process memory can contain executable files disguised with different extensions

We received this memory dump from the Intelligence Bureau Department. They say this evidence might hold some secrets of the underworld gangster David Benjamin. This memory dump was taken from one of his workers whom the FBI busted earlier this week. Your job is to go through the memory dump and see if you can figure something out. FBI also says that David communicated with his workers via the internet so that might be a good place to start.

Note: This challenge is composed of 1 flag split into 2 parts.
The flag format for this lab is: inctf{s0me_l33t_Str1ng}

Solution

The description made me very excited. So let’s start!

Browser Investigation

First step let’s get the image info.

Then I listed the processes with pslist command. chrome.exe, firefox.exe and WinRAR.exe are the suspicious ones that we will focus on for now. The description says that the suspect communicates over the internet, so I will analyze more about browser history and network traffic.

But before things about internet - let’s check the RAR files to see what suspect did on WinRAR:

I dumped it and tried to unrar but it was password protected and there was no clue so we will go back to it later. In the description it says “This challenge is composed of 1 flag split into 2 parts.” So I believe that the password of this RAR archive is the first part of the flag.

Chrome and Firefox History

So let’s look what the suspect did on the internet. We can scan network and also dump browser histories.

Okey this is the Google Chrome history but where is Firefox history?

After some searching I found an article about where Firefox history is stored.

Now let’s dump and analyze these browser histories.

You can open browser histories with DB Browser. First I chose Chrome history and there was literally nothing… Just some searches about cars and stuff and download history of WinRAR (from official website).

So let’s check the Firefox history, and there are encoded texts and different mails about a Mega Drive Key.

Okey.. I couldn’t find anything about these encoded texts. I went back to look at Chrome history and I realized I had missed something.

This is the note in the URL:

And this is the document which URL is given in the note. The text in this document is only Lorem Ipsum (Lorem Ipsum is a meaningless block of text used as placeholder in design templates).

But there is a Mega link hidden in this Lorem Ipsum. Now we have a key and a Mega link.

When we go to this link Mega asks us for a key. The text that I thought was encrypted is actually the key to this file. And there is just one file in the link: “flag.png”. But as you can see we can’t open this file as an image.

The RAR Archive

Now let’s go back to the password protected RAR archive. I tried to scan files about “password” but there was no result so I tried to use envars command and there it is.. I can’t believe how easy it is:

This is the file in the password protected RAR archive. This is the second part of our flag:

Fixing the Corrupted PNG

Yes.. we still have a password protected image file and there is no clue. Also there was another big problem. Steghide throws an error about file format:

When I use exiftool I can see the problem but I couldn’t understand what exactly is the issue:

After some googling (like 3 seconds) I understood the problem and I know how to solve it. I am going to change hex data:

Every file format has a hexadecimal text palette called “magic number” in IT. If you change those hexadecimal file signs you will change the format of file. This method is also used by attackers for unauthorized file uploads.

So when we go back to our file there is just a small problem, small enough to be annoying. As you can see there is written “iHDR” - it should be “IHDR”:

There was written 69 (i in ASCII table) - I changed it to 49 (I in ASCII table).

And here it is, the file actually wasn’t password protected - it was just broken:

Final flag: inctf{thi5_cH4LL3Ng3_!s_g0nn4_b3_?_aN_Am4zINg_!_i_gU3Ss???}

Key Takeaways

• Always analyze ALL browser histories (Chrome, Firefox, etc.) - don’t skip any
• Browser history databases can be opened with SQLite/DB Browser
• Lorem Ipsum text can hide embedded links
• PNG files have magic bytes with specific header requirements (IHDR not iHDR)
• A single byte change in hex can corrupt or fix an entire file
• Environment variables remain a goldmine for hidden information

A malicious script encrypted a very secret piece of information I had on my system. Can you recover the information for me please?

Note-1: This challenge is composed of only 1 flag. The flag split into 2 parts.
Note-2: You’ll need the first half of the flag to get the second.
You will need this additional tool: sudo apt install steghide
The flag format for this lab is: inctf{s0me_l33t_Str1ng}

Solution

Part 1: The XOR Script

First step let’s get the image info:

Then check the processes:

I noted the processes I think suspicious:

After I check cmd commands with cmdline:

And here there are 2 suspicious commands:

Let’s try to extract these 2 files - evilscript.py and vip.txt:

This is the evilscript.py - as you can see this code XOR encrypts the vip.txt and encodes it with Base64.

And this is the vip.txt:

After decoding it with CyberChef I got something. Key 3 is in the format of our flag:

Part 2: Steganography

After that, in the CTF challenge it says we will need to use steghide so I am going to search for some images.

First I checked for .png file extension which is a popular image file extension, and I got a lot of files but these files are not what we’re searching for:

Then I checked .jpeg file extension. And here there is a file named “suspision1.jpeg”. I know that this looks fake but don’t forget that this is a CTF:

Then I extracted the file. As you can see this image looks like a random footage but in the challenge description creator said we need to use steghide:

When we try to extract file with steghide we see there is a passphrase. While doing some bruteforce tries, I checked the description again and saw: “Note-2: You’ll need the first half of the flag to get the second.”

The passphrase is the first part of the flag: inctf{0n3_h4lf

We extracted the file, and there it is - the second part of the flag.

Final flag: inctf{0n3_h4lf_1s_n0t_3n0ugh}

Key Takeaways

• Python scripts found in memory can reveal encryption methods used
• CyberChef is great for chaining multiple decode operations (XOR + Base64)
• Steganography tools like steghide can hide data inside JPEG images
• Challenge descriptions contain critical hints - always read them carefully

My system was recently compromised. The Hacker stole a lot of information but he also deleted a very important file of mine. I have no idea on how to recover it. The only evidence we have, at this point of time is this memory dump. Please help me.

Note: This challenge is composed of only 1 flag.
The flag format for this lab is: inctf{s0me_l33t_Str1ng}

Solution

First step let’s get the image info.

Then I checked processes, but I didn’t see any suspicious processes except of StickyNot.exe and dllhost.exe.

After that I use cmdscan command but I didn’t get anything suspicious then I use cmdline command and I get something about “dllhost.exe”.

Then I used consoles command but there was nothing suspicious. After that I tried to get deeper for StickyNot.exe but there was nothing. After some failures I tried to search some files and here - there is a file named Important.txt:

And let’s dump it.. what? Okey - dumpfiles command can’t extract the file:

After some searches about Windows forensics I find something interesting. In NTFS (New Technology File System) there is a table named MFT - Master File Table. MFT contains information about files: where the file is, data in the file, and metadata information. I wish I had known this until today.

And the best part about this: Volatility can export MFT! (This process can take minutes)

The exported txt file was 9.5 MB and 173544 lines… Okey let’s open it in a text editor and try to find something about Important.txt.

And this is what we got about Important.txt - luckily I have some experience in Malware Analysis so I’m a bit used to screens like this. This is just hexdump - you can read it easily or you can decode it.

Finally the flag is:

inctf{1_is_n0t_EQu4l_7o_2bUt_th1s_d0s3nt_m4ke_s3ns3}

Key Takeaways

• When dumpfiles command fails, the file might be in MFT (Master File Table)
• NTFS stores small files directly in the MFT record - these can be recovered even when the file itself is “deleted”
• Volatility’s mftparser plugin exports the entire MFT - grep through it for your target
• Reading hexdump is a useful skill for forensic analysts

Challenge Description

My friend John is an “environmental” activist and a humanitarian. He hated the ideology of Thanos from the Avengers: Infinity War. He sucks at programming. He used too many variables while writing any program. One day, John gave me a memory dump and asked me to find out what he was doing while he took the dump. Can you figure it out for me?

Solution

First get the image info:

Then I use pslist command to list processes and take notes about suspicious processes.

After that I use cmdscan command to search what happened in cmd.exe. And there seen a python file executed with cmd:

To search what was the output I used consoles command, and there is seen an encoded text as output of executed python file. But when I tried to decode it I didn’t get any normal text just random characters.

So I tried to use envars command to scan environment variables. And there is a clue - a “Thanos” variable with “xor and password” value:

After decode the text with the right way in second attempt it gives us a string 1_4m_b3tt3r. Okey this should be something but this is not the flag.

We decoded the text with XOR but we didn’t see any passwords so I use hashdump command to get NTLM hashes:

Then I used hashcat for cracking hash. Also online tools can be very useful for cracking NTLM hashes.

Finally when you combine these two texts the flag is:

flag{you_are_good_but1_4m_b3tt3r}

Key Takeaways

• Environment variables can hold critical clues
• Combining multiple data sources (consoles, envars, hashdump) is essential
• Understanding encoding methods (XOR) matters in CTF challenges