This isn’t a “containers vs VMs” theory post. It’s the practical checklist I actually reach for when a container is in scope.

The core problem: ephemeral by design

Containers are meant to be disposable. That’s the whole point of the model — and it’s exactly what works against you during an investigation:

• The writable layer disappears with the container. Anything the process wrote at runtime lives in a thin, container-specific overlay layer on top of the read-only image. docker rm (or a scheduler rescheduling the pod) takes that layer with it.
• There’s often no persistent host artifact. Unlike a compromised VM, there’s frequently nothing left on the node once the container’s gone — no separate disk, no easy “mount the image and look around.”
• Short-lived by default. Build pipelines, serverless-style workloads, and auto-scaling groups routinely spin containers up and down in minutes. If your detection has any lag at all, the container that triggered it may not exist by the time you respond.

The practical upshot: for containers, acquisition speed matters more than it does almost anywhere else in DFIR. Decide your capture plan before you have an incident, not while you’re staring at a container that might vanish in the next scheduler cycle.

Live acquisition: what to pull, and in what order

If the container is still running, prioritize the things that die first.

1. Process and network state (most volatile)

docker top <container_id>
docker exec <container_id> ps auxf
docker inspect <container_id> --format '{{json .State}}'

docker inspect also gives you the container’s network namespace, mounted volumes, environment variables, and the exact image digest it was started from — all of which you want in your case notes regardless of what else you collect.

2. The writable layer and filesystem diff

docker diff shows you every file added, changed, or deleted relative to the base image — often the fastest way to spot a dropped webshell or modified binary without diffing the whole filesystem by hand:

docker diff <container_id>

For a full copy of the container’s filesystem as it currently stands:

docker export <container_id> -o container_fs.tar

Note that export flattens the container to a single filesystem snapshot — you lose the layer history in the process. If layer-by-layer provenance matters (e.g., you need to prove which layer introduced a file), work from docker save on the image instead, or go straight to the host-level storage driver.

3. Logs

docker logs <container_id> --timestamps > container_logs.txt

Don’t stop at docker logs — check where the logging driver is actually writing on the host (json-file under /var/lib/docker/containers/<id>/, or wherever your driver of choice sends it). If centralized logging (Fluentd, an ELK/EFK stack, CloudWatch) is in place, pull from there too; container-local logs can be truncated, rotated, or lost along with the container itself.

4. Memory

Containers share the host kernel, so there’s no separate “container memory” to acquire the way you’d image a VM’s RAM. What you can do is target the container’s specific process(es) on the host:

# find the host PID for a process inside the container
docker inspect <container_id> --format '{{.State.Pid}}'

From there, standard Linux memory forensics against that PID (or the whole host, if you have the budget for it) applies.

Acquisition after the container is already gone

This is the case that actually hurts. A few things still might save the investigation:

• The image is not the container. If the image is still in the local registry or cache, docker save gets you the base filesystem and layer history — useful for understanding what the container looked like before runtime changes, but it won’t show you anything the attacker did at runtime.
• Volumes often outlive the container. Any named volume or bind mount the container used typically persists after docker rm. Check docker volume ls and don’t assume everything walked out the door with the container.
• The host itself is still an artifact. Container runtime logs (dockerd/containerd logs), the overlay2 storage driver’s on-disk layers under /var/lib/docker/overlay2/, and host-level EDR/auditd telemetry frequently retain evidence of what happened even after the container object is deleted.
• Orchestrator-level history. In Kubernetes, check for previous pod events (kubectl get events), and if a pod was OOMKilled or evicted rather than deliberately removed, kubectl logs --previous can recover the last container instance’s logs even after a restart.

What to fix before the next incident

The single highest-leverage change, if you can make it stick: ship logs and runtime telemetry off-host, continuously, before anything happens. Everything above is a “try to recover evidence that might already be gone” exercise. A runtime security tool watching syscalls (Falco is the common open-source choice) or simply making sure container logs land somewhere durable turns most of this from forensic recovery into a straightforward log query.

Beyond that: know your acquisition commands cold, and decide in advance whether a suspicious container gets paused (docker pause, which freezes it without killing it — often the best first move if you’re not sure yet) versus killed. Once it’s gone, you’re working with whatever you had the foresight to ship elsewhere.

Short introduction

Application containerization is not young concept but tools and new capabilities around this topic are still fresh and worth to track. In this article I would like to describe some concepts around containerized ASP .NET Core applications, Docker, Azure Container Registry and Azure Kubernetes Service. I hope that this content will help not only .NET Developers but also everyone who would like to understand the whole concept of containers.

To Be Continued…

Short introduction

Before we start with Microsoft Azure DevOps service lets explain what DevOps is. “DevOps is the union of people, process, and products to enable continuous delivery of value to your end users.” As you can see this is not one specific thing. Azure DevOps is a solution created to support this “union”. It provides tools to manage team work collected in the backlog, it provides GIT repositories to store the code, it provides automatic builds and releases once there is new feature commited. In this article I would like to present how to use Azure DevOps to provide continuous integration and delivery for ASP .NET Core Web Apps. If you want to read more about Azure DevOps visit official website.

Project structure and setup

Creating account in the Azure DevOps is free. You can create one using this link. Once you sign in you should see main panel where you can manage your organization settings and projects. Lets start from creating new project. Click “Create project” button. Provide the name for the project and short description. Below select GIT version control and Agile work items process. Click “Create project” button:

Once project is created you should see navigation panel:

Repository setup

In this section we will commit project’s code to the GIT repository in the Azure DevOps. For this article I used already created, open source project called “eShopOnWeb”. Download its code from GitHub here.

Open “Repos” tab and select “Branches”. In the right top corner click “New branch” button. Create two more branches so in total there will be three of them: master, stage and dev:

Once you have branches ready there is one more thing to do - set “dev” branch as default one. Click “Project setting” on the bottom and go to the “Repositories” tab. Click on the “dev” branch and select three dots on the right - select “Set as default branch”. Once we have branches ready it is time to commit the code to the “dev” branch. Download code from GitHub first. Then it is time to map our GIT repository. Open “Repos” tab and click “Clone” button. Generate GIT credentials here. I am not sue which tool you prefer to use so lets omit the part with commits, and for me I prefer dealing with git command line since it’s a way faster than the other method - the only thing here is that source code from GitHub should be committed to the Azure DevOps GIT repository.

Once you commit the code it should appear in the AzureDevOps portal:

There is great feature for branches called “Branch policy”. We can set few different policies for the branch - for instance you cannot complete pull request if you did not set tasks related with it or you cannot complete pull request if the code from your branch cannot be built. Below I presented how to setup policy for “dev” branch. In the “Branches” section click three dots next to “dev” branch and select “Branch policies”:

Select “Require a minimum number of reviewers”. If you enable this policy you will not be able to merge changes before two specified reviewers will do the code review of your proposed changes:

This will also enforce the use of pull requests when updating the branch.

Board setup

With Azure DevOps boards you can plan the team work and create backlog for your product. You can create tasks, issues, bugs, user stories and features:

If you want to read more about backlog configuration with Azure DevOps please refer to this documentation.

For now we will create one user story and one task inside it. User story and task will be related with updating ReadMe file:

Of course you can add as many stories as you need for the project.

Build pipeline setup

In this section we will setup build pipeline for our web app project. We want to build the code each time when there is an update on the source code from “dev” branch. To configure automatic build open “Pipelines” tab and open “Pipelines” section:

Click “Create pipeline” button and then select “Use the classic editor to create a pipeline without YAML.”

There are few steps:

1. Location-we have to indicate where the code is located - in our case this will be “Azure Repos GIT”:
   

2. In this step we can select template for our build - this is very convenient because we do not have to define everything from scratch. Select “ASP .NET Core” template:
   

3. There will be pre-configured steps displayed. We want to build our code each time new merge is done. To do this select “Enable continuous integration” in the “Triggers” section:
   

4. Lets change build definition name to “eShopOnAzureDevOps-ASP.NET Core-CI-DEV”-just click on the text on top.

5. Click “Save & queue” button. Select “Azure Pipelines” as build agent. New build should be scheduled:
   

6. Once build if finished we can check the result:
   

We can move forward to the next section.

Release pipeline setup

NOTE: I scaled down Azure service plan to the free tier to stop billing so all deployment slots has been removed and I may do clean up all resources after a while so some links below will not work properly.

We will host our application using Microsoft Azure Web App service. In this section I would like to present how to use Azure Web App deployment slots so you can deploy two (or more) versions of the application so its available under different URL addresses. You can read more about deployment slots here. As a result of below setup we will configure two different release pipelines: one for demo and one for production.

Create web application in Azure portal

Login to the Azure portal and create new Web App service inside new resource group:

Please remember to select S1 App Service Plan because it provides deployment slots feature. Once Web App is created open it and go to the “Deployment slots” tab:

Click “Add Slot” button and add new slot called “demo”. Copy configuration from production slot:

Once deployment slot is created click it. Note that there is new URL created:

https://eshoponazuredevops-demo.azurewebsites.net

Production app URL looks like below:

https://eshoponazuredevops.azurewebsites.net

Now we can connect Azure DevOps with Azure subscription to configure release pipeline.

Setup connection between Azure and Azure DevOps

Click “Project settings” on the bottom of AzureDevOps page. Go to “Service connections” under “Pipeline” section. Click “Create service connection” and select “Azure Resource Manager” and then select “Service principal (automatic)”:

Select Azure subscription, resource group and type connection name. Then click “Save”:

Connection should be visible on the list. Now we can configure release pipeline.

Configure release pipeline

Open “Releases” tab in the “Pipelines” section:

Click “New pipeline” button. On the right side please find and select “Azure App Service deployment with slot”:

Type “Demo” in the “stage name” field and click “X” icon to close the tab:

Now change the name of the release to: “Demo release pipeline” and after that click “Add an artifact”:

Select project and then set “default version” to “latest”. “Source alias” should be set to “_eShopOnAzureDevOps-ASP.NET Core-CI-DEV” - our build definition we created earlier in the article:

Once you click “Add” button you should see configured artifact for our release pipeline definition:

Now we have to integrate our release pipeline with the Azure Web App created earlier in the article. Click “1 job, 2 tasks” under “Demo”stage. In this step you have to provide name of the Azure subscription, App type, Azure service name, Resource group and Slot (in this case “demo”):

For now we can remove next step called “Slot swap”. Click remove in the right top corner to remove this step from the release pipeline. Only deploy to slot should remain:

Click “Save” and then “OK” buttons. Our final pipeline looks like presented below:

One more thing - we need to enable trigger for this release pipeline each time there is new build. Click lightning icon in the “Artifacts” and enable below trigger. Then click “Save” and “OK” buttons:

Test release pipeline for demo slot

Now we can try to test whether we configure everything properly. Try to commit some changes to the dev branch and see if build was scheduled and if release was completed successfully. If everything went ok you should access web app under demo URL address:

https://eshoponazuredevops-demo.azurewebsites.net

Please note that under production URL https://eshoponazuredevops.azurewebsites.net there is no app available:

Configure slot swap in the release definition

Once demo environment is ready we can use “slot swap”. This step in release pipeline enables moving application from the “demo” slot to the production slot.

Click “Add” button under “Demo” stage:

Again search for “Azure App Service deployment with slot” template and type “Production” as stage name. Click “X” button in the right corner. Now our pipeline look like below:

Now click “1 job, 2 tasks” on the Production stage. This time remove “Deploy Azure App Service to Slot” and in the “Manage Azure App Service - Slot Swap”. Again select Azure subscription, app service name, resource group and slot:

Click “Save” and then “OK” button. Now we want to have approval before demo app is moved to production. It means that someone has to confirm this slot swap. We have to set pre-deployment conditions. Click lightning icon on the Production stage and then set “Pre-deployment approvals” to enabled:

Then set one of the approvers - person (or people) who will accept deployment to Production stage:

Click “Save” and then “OK” button. Now try to commit some changes to the source code of the web app. Before there is slot swap to Production you will have to wait for approval. Approves should receive e-mails with the information that new build is ready and swap to Production can be proceeded:

Once swap is approved in the portal information about deployment is displayed:

Now lets try to open production URL: https://eshoponazuredevops.azurewebsites.net

Summary

Microsoft Azure DevOps provides tools to manage team work collected in the backlog, it provides GIT repositories to store the code, it provides automatic builds and releases. It help developers and DevOps engineers with setting up the whole Development and Operations related stuff. It is available for free and its worth to mention that it supports not only Microsoft technologies (like ASP .NET Core web applications mentioned in this article). You can read more about Azure DevOps on the official website.

Welcome to the launch of the new YMTech blog website and my first blog post! My name is Yousef Majeed and this is my personal blog or better my personal knowledge base where I am writing down my thoughts all around technology.

Although the main part of this blog activities was to share knowledge and passion about Microsoft Azure, DevOps and ASP.NET but now I think it may extend to anything related to technology as well.

If you like any of my posts, please share them with others. Also, let me know if there are any topics you’d like me to write about. I’ll try to incorporate a few of your suggestions into future posts.

Thanks for stopping by.