Вхід через VPN, а потім шифрувальник: що підтверджують докази
Вхід о 02:14 і зашифровані файли о 03:02 — це послідовність, варта розслідування, а не точка входу. Тримайте окремо докази автентифікації, сеансу та хоста.
Усе нижче спирається на гіпотетичний запис, зібраний, щоб показати форму, а не описати реальний випадок. Він читається як ланцюг: автентифікація на шлюзі о 02:14, сеанс робочого столу о 02:19, зміна привілейованого облікового запису о 02:41 і зашифровані файли, знайдені о 03:02. Перший рядок виглядає як відповідь, і звіт часто пишеться так, ніби це вона і є. Вхід — це подія, яку зафіксував шлюз, а не висновок про те, як хтось потрапив усередину, і саме ця різниця визначає, що ви робитимете далі.
Симптом: вхід, що виглядає як відповідь
Записи автентифікації — найлегші для отримання докази й найлегші для перебільшення. Вони показують, що служба прийняла облікові дані в певний час, з певної адреси, для певного облікового запису. Вони не показують, хто керував цими даними, чи використовувався шлюз і чи пристрій власника облікового запису вже був скомпрометований.
Три пояснення підходять до одного рядка входу. Хтось використав украдений пароль, і шлюз зробив рівно те, для чого він створений. Раніше скомпрометований ноутбук просто увійшов як зазвичай. Непов’язана відкрита служба дала справжній вхід, а сеанс VPN — це пізніша, окрема дія того самого суб’єкта.
Кожне пояснення передбачає різні докази в іншому місці середовища, тому розслідування має шукати саме ці передбачення, а не підтвердження першого слушного. Украдений пароль передбачає незвичайну географію або час автентифікації. Скомпрометований ноутбук передбачає артефакти хоста до входу. Непов’язана точка входу передбачає активність, яка взагалі не стосується шлюзу.
Тримайте події окремо, перш ніж розповідати про них
Запишіть події окремо, доки не існує жодної оповіді, бо оповідь запрошує вибудувати хронологію навколо підозрюваного. Кожен рядок має казати, що встановлює цей запис, і окремо, чого він сам установити не може. У мить, коли два рядки зливаються в одне речення, інтерпретація вже перемогла.
Зверніть увагу, що остання подія стосується виявлення, а не нападника. Час виявлення і час компрометації зазвичай розділяють години або тижні, і звіт, який їх прирівнює, введе в оману кожного читача, який прийде після вас.
Записуйте, звідки взялася кожна мітка часу, а не лише що вона каже. Час отримання збирачем, час події та час виявлення — три різні числа, і тихе зведення їх в один стовпець — це те, як хронологія набуває форми, якої докази ніколи не мали.
З’єднуйте записи лише там, де збігаються ідентифікатори
Об’єднання записів — це гіпотеза, а не крок форматування. Ім’я облікового запису, призначена адреса VPN, цільовий хост і ідентифікатор сеансу мають збігтися, перш ніж два рядки стануть однією історією. Спільної публічної адреси недостатньо, бо вона спільна за задумом.
| Record source | Join key that must match | What breaks when the key is missing |
|---|---|---|
| File-share or backup record | file path and modification time | impact cannot be ordered against any session |
| Host process record, EDR or audit log | host name and process start time | the process cannot be placed inside a session |
| Session broker or remote-desktop log | session identifier and target host | the session cannot be traced back to a gateway login |
| Gateway authentication log | account name and assigned VPN address | the session cannot be followed past the gateway |
Читайте таблицю знизу вгору, коли простежуєте вхід, і згори вниз, коли визначаєте масштаб впливу, бо два питання потребують протилежних напрямків. Там, де ідентифікатори справді збігаються, скажіть це й посилайтеся на обидва записи. Там, де не збігаються, залиште прогалину видимою, а не закривайте її припущенням.
Тут також вводить в оману знайоме ім’я користувача. Той самий обліковий запис уранці може використовувати законний власник, а вночі хтось інший, і саме ім’я облікового запису не може їх розрізнити. Припишіть обліковий запис, потім окремо припишіть особу, і лише коли щось це підтверджує. Більшість хронологій, що розсипаються під час перегляду, зробили саме цей крок надто швидко.
Відсутні журнали — це прогалина, а не негативний доказ
Відсутність подій із невдалими паролями не доводить, що успішний вхід був законним. Чинні украдені облікові дані дають успішний запис автентифікації і жодних збоїв, і саме це робить крадіжку облікових даних привабливою.
Так само порт, закритий сьогодні, каже щось про сьогодні. Він не каже нічого про те, чи була та служба відкрита тоді, чи була вразлива тоді або чи несла вона атаку. Історична конфігурація та докази служби — єдиний спосіб закрити цю прогалину.
Зазначте прогалину явно у звіті. «У нас немає записів за цей інтервал» — це речення, яке можна захистити; «нічого іншого не сталося» — ні, і це вам пригадають. Прогалини мають і власників: назвіть систему, яка мала створити запис, і чому вона цього не зробила. Цей рядок перетворює упущення на пункт виправлення.
Пишіть висновки на тому рівні, який підтверджують докази
Координуйте збереження, локалізацію та відновлення через власника інциденту, а не в обхід нього. Технічне керівництво CISA наголошує на зборі відповідних артефактів і журналів до того, як відновлення змінить те, що ще доступне, і цей порядок важливіший за будь-який окремий інструмент.
Повторний запуск імовірного експлойта на робочому обладнанні, щоб закрити прогалину, не вартий доданого ризику. Тест, який показує, що атака могла спрацювати, не є доказом, що вона спрацювала, і різниця між цими двома твердженнями — уся дисципліна вправи.
Завершіть чотирма списками: що спостерігалося, які зв’язки підтверджують записи, що залишається гіпотезою і які записи недоступні. «Під час інциденту використовувався обліковий запис VPN» належить до другого списку, коли записи це підтверджують. «VPN спричинив шифрувальник» не належить нікуди, доки щось не встановить причинність.