Урок 2. Как отличить догадку от доказанного факта

В первом уроке мы научились понимать, какой ответ требует задача. Теперь разберём вторую причину дорогих ошибок: ученик находит подозрительную строку и сразу превращает её в вывод.

Запрос к /admin/export не доказывает успешную выгрузку. Строка sudo -n /bin/sh не доказывает получение root. Имя Stealer.class не доказывает вредоносность класса. Это наблюдения — полезные, иногда очень сильные, но всё ещё не выводы.

Пять простых шагов рассуждения

Чтобы не перескакивать от подозрительной строки сразу к ответу, раскладывайте решение на пять шагов.

Источник — файл, в котором мы ищем следы: таблица CSV, журнал, архив, запись трафика или дамп памяти. Специалисты часто называют такой файл артефактом.

Наблюдение — то, что непосредственно видно в источнике. Например: «в запросе R-204 указан путь /api/read?file=secret.txt».

Гипотеза — возможное объяснение наблюдения: «запрос мог привести к чтению secret.txt».

Проверка — действие, которое различает гипотезы: найти связанное событие процесса или журнала доступа к файлам по ID запроса либо сессии.

Доказательство — запись, которая прямо поддерживает или опровергает догадку: FA-208 action=read result=success path=/srv/secret.txt.

Вывод — короткий ответ на вопрос: «да, файл был успешно прочитан».

Пропуск среднего шага — главный источник ложных ответов.

Попытка и эффект на демонстрационном наборе

Имена R-204, FA-208 и названия файлов в следующих примерах принадлежат маленькому демонстрационному набору. В самостоятельном l2_evidence.zip другие имена и идентификаторы: метод нужно повторить, а не перенести ответ.

Рассмотрим цепочку:

web_requests.csv
R-204,10:14:02,198.51.100.19,GET,/api/read?file=secret.txt,200

process_events.csv
P-205,10:14:02,web,R-204,/usr/bin/cat /srv/secret.txt,success

object_access.csv
FA-208,10:14:03,web,read,/srv/secret.txt,success

Код 200 показывает, что web-сервер ответил без ошибки, но не доказывает чтение файла. Вторая строка связывает запрос с командой. Третья строка прямо фиксирует успешное чтение конкретного пути. Поэтому для вопроса «был ли прочитан файл?» третья строка — самое сильное доказательство.

Теперь другая строка:

R-199,10:11:40,198.51.100.88,GET,/api/read?file=/etc/shadow,500

Она выглядит опаснее, но рядом нет ни события процесса, ни записи о чтении файла. Корректный вывод — не «файл прочитан» и не «файл не прочитан». По выданным данным результат установить нельзя.

Когда данных недостаточно

Иногда олимпиадный вопрос допускает ответ о недостаточности данных, иногда требует выбрать yes/no. В обоих случаях нужно оценить покрытие источников.

Если журнал содержит только входящие запросы, нельзя уверенно утверждать, что произошло внутри системы. Отсутствие записи может быть доказательством только тогда, когда мы уверены, что журнал работал, охватывает нужное время и обязан был зафиксировать событие.

Отрицательный вывод допустим, только если выполнены следующие условия:

• должен ли нужный эффект вообще появляться в этом источнике;
• нет ли разрыва или очистки журнала;
• совпадают ли часовой пояс и нужный промежуток времени;
• есть ли фильтрация по пользователю, хосту или типу события;
• может ли действие выполниться другим механизмом.

«Не найдено» превращается в «не произошло» только тогда, когда источник действительно полон.

Альтернативные гипотезы

Пусть в журнале процессов есть:

/usr/bin/curl -fsS http://203.0.113.9/health

Гипотеза A: атакующий проверял управляющий сервер.

Гипотеза B: штатная проверка работоспособности обращалась к тестовому адресу.

Что различит их дешевле всего?

• родительский процесс;
• пользователь;
• расписание запуска;
• список разрешённых адресов;
• соседние события процессов, файлов и сети.

Поиск слова curl уже выполнен и больше не помогает. Хорошая следующая проверка должна дать разные ожидаемые результаты для A и B.

Прямые и косвенные признаки

Прямое доказательство отвечает ровно на поставленный вопрос. Запись action=read,result=success прямо подтверждает чтение файла. Команда cat /srv/secret.txt — сильный, но косвенный признак: команда могла завершиться ошибкой, а доступ мог быть запрещён.

Косвенные признаки не бесполезны. Иногда прямой записи нет, и вывод строится из нескольких независимых следов. В этом случае нужно честно объяснить цепочку и не выдавать предположение за доказанный факт.

Записывайте, где найден ответ

Ответ должен быть воспроизводимым. Фраза «нашёл через grep» описывает инструмент, а не место доказательства.

Хорошие записи:

object_access.csv:FA-208
process_events.csv:P-205
auth.log:2026-01-17T10:13:51Z/session=S-44
archive.zip:reports/shift.csv
fragment.raw:offset=768

Номер строки допустим для неизменяемого текстового файла, но идентификатор события обычно надёжнее: разные программы могут считать строки по-разному.

Короткая заметка к ответу

Для сложной части задачи достаточно пяти строк:

Вопрос: успешное чтение после R-204?
Наблюдение: R-204 просит secret.txt.
Проверка: связанные process и file-audit события.
Доказательство: object_access.csv:FA-208, result=success.
Вывод: yes.

Такая запись сохраняет связь между выводом и исходной строкой журнала. При повторной проверке не придётся заново восстанавливать причину ответа.

Разбор: два похожих запроса

В демонстрационном наборе есть R-199 и R-204. Оба обращаются к чувствительным путям. У первого status 500 и нет продолжения. Второй связан с process P-205 и file event FA-208. Эти значения показывают ход рассуждения, но не являются ответами C4–C6.

Если вопрос звучит «какой запрос привёл к успешному чтению?», правильная стратегия:

1. не выбирать по «страшности» path;
2. найти оба запроса в web-журнале;
3. проверить связь по номеру запроса;
4. найти источник, прямо фиксирующий результат;
5. вернуть ID запроса или yes/no в требуемом формате.

Эта логика работает и в других темах. Попытка входа не равна успешной сессии; запуск опасной команды не равен получению прав администратора; отправка пакета не равна получению ответа.

Реальная задача ВСОШ

«Сетевые движения» · заключительный этап 2024–2025 · 9 класс
Формат: запись сетевого трафика и отчёт; отдельно проверялись IP атакующего, флаг и доказательная цепочка атаки.
Проверяемый навык: отличить запрос от успешного эффекта и связать вывод с пакетом либо TCP-потоком.
Открыть исходное условие и авторское решение

172.28.0.4

dnNvc2h7czNjcjN0X2QwY3N9

vsosh{s3cr3t_d0cs}

Вывод: выполнена OS command injection.
Источник: final_9_class.pcap, TCP stream 2, POST /find_file.
Наблюдение: в теле запроса есть shell-метасимволы, bash -c и /dev/tcp/172.28.0.4/1234.
Подтверждение эффекта: TCP stream 3 содержит интерактивный shell; whoami → root.
Следствие: через тот же поток прочитан secrets.txt, его Base64 декодирован до флага.

Практика урока

В l2_evidence.zip находятся три коротких учебных журнала. Запрос, процесс и доступ к файлу связаны номерами и временем — так же, как в реальном расследовании.

• C4 просит определить, было ли действие успешным.
• C5 требует указать файл и номер подтверждающего события.
• C6 проверяет границу уверенного вывода: сначала нужно самостоятельно установить, достаточно ли выданных источников для yes или no.

У анализа здесь три нормальных результата: событие подтверждено, событие опровергнуто или выданных данных недостаточно. Последний вариант не является неудачей решения. Ошибка возникает, когда нехватку данных маскируют уверенным yes или no.

В C4–C6 одна и та же внешне подозрительная активность приводит к разным выводам именно из-за различий в подтверждающих журналах.