TT Lab
Get started
Learn Learning paths Courses

Air-Gapped Sites — Defence and Government

Investigate in an Air-Gapped Network and Prepare an Export Summary

Continue in TT Lab

Goal

In a Pod with no internet and no package installation, find the cause of an outage, turn the result into a form that can be taken out of the network, and write up to the export request form.

Why it matters

This Pod does not imitate an air-gapped network; it really is one. curl cannot reach outside and pip install fails. So what you learn here is not a trick but an order — first make a list of what you have, pin down the fact that something is missing with an exit code, and narrow the cause by placing two different records on a time axis. And what goes outside is made not by deleting from the original but by picking items from an empty file. If you make it by deleting, one is certain to remain, and the remaining one is invisible no matter how many times you reread.

Steps

  1. With python3, create /root/airgap/app.log (600 lines) and /root/airgap/change.log (4 lines). Use the generation script with its fixed seed as is.
  2. Actually run curl and pip3 install to check the exit codes, then count at least 8 usable tools and write them in /root/airgap/offline.txt.
  3. In /root/airgap/triage.txt, write the total line count, the ERROR line count, the first error time, the most frequent err code, and the number of errors before the configuration change time (17:42).
  4. In /root/airgap/cause.txt, write the identifier, item, old value, and new value of the change just before the incident, the gap in minutes between the change and the first error, and the evidence copied from the error lines.
  5. In /root/airgap/sensitive.txt, write the number of unique accounts, employee IDs, hostnames, internal IPs, contacts, and worker identifiers.
  6. In /root/airgap/release/summary.txt, write the export summary. Make it 8 to 40 lines, containing only the facts needed for judgment.
  7. In /root/airgap/forbidden.txt, build the list of forbidden tokens extracted from the original, and write the result of checking the summary against it in /root/airgap/release/selfcheck.txt.
  8. In /root/airgap/release/request.md, write a six-section export request form, and attach integrity with /root/airgap/release/summary.sha256.

Notes

Create the investigation target inside the network

With python3, create /root/airgap/app.log (600 lines) and /root/airgap/change.log (4 lines). Use the generation script with its fixed seed as is.

There is no sample to fetch from outside, so create it yourself with python3. The random seed has to be fixed so that everyone sees the same incident and can check one another's judgments against it.

Pin down the air-gapped network with evidence

Actually run curl and pip3 install to check the exit codes, then count at least 8 usable tools and write them in /root/airgap/offline.txt.

Run curl and pip once each for real and write down the exit codes. For the tool list, write only what actually exists according to command -v — a list that names tools that are not there misleads the next person.

Determine the incident window

In /root/airgap/triage.txt, write the total line count, the ERROR line count, the first error time, the most frequent err code, and the number of errors before the configuration change time (17:42).

Count the total line count, the ERROR line count, the first error time, the most frequent err code, and the number of errors in the period before the configuration change time (17:42). The last number decides whether you can point to the change as the cause.

Link the two logs by time and point to the cause

In /root/airgap/cause.txt, write the identifier, item, old value, and new value of the change just before the incident, the gap in minutes between the change and the first error, and the evidence copied from the error lines.

Find the change just before the incident in change.log, and calculate in minutes the gap between its time and the first error time. The evidence comes not from guesswork but from the values the error lines themselves tell you.

Count the export review targets by category

In /root/airgap/sensitive.txt, write the number of unique accounts, employee IDs, hostnames, internal IPs, contacts, and worker identifiers.

It is the number of unique values, not the number of occurrences. And the review target is not just app.log — one category is hidden in change.log too.

Create the export summary

In /root/airgap/release/summary.txt, write the export summary. Make it 8 to 40 lines, containing only the facts needed for judgment.

Do not open the original and delete from it. Start from an empty file and copy over only the facts needed for judgment, and whatever you did not copy was never there in the first place. If it goes over 40 lines, it is not a summary.

Self-check against the forbidden token list

In /root/airgap/forbidden.txt, build the list of forbidden tokens extracted from the original, and write the result of checking the summary against it in /root/airgap/release/selfcheck.txt.

Extract the six categories from both app.log and change.log and collect them with sort -u. Do the check with grep's -F (fixed strings) and -f (list file). And do not leave this list in the export directory.

Write the export request form and attach integrity

In /root/airgap/release/request.md, write a six-section export request form, and attach integrity with /root/airgap/release/summary.sha256.

You need six sections. In the integrity section, write the SHA-256 of the summary and keep the same value in a hash file as well. If you changed the summary by even one character, you have to recompute both.