W świecie threat huntingu często szukamy skomplikowanych wzorców, korelacji i anomalii. Tymczasem czasami najwięcej mówi… pojedynczy nagłówek wiadomości.

Autor: 5 min czytania

InternetMessageId to jeden z tych elementów, który zwykle jest ignorowany. A szkoda, bo w odpowiednim kontekście potrafi połączyć całą kampanię phishingową w jeden spójny obraz.

Coś więcej niż identyfikator wiadomości

Na pierwszy rzut oka InternetMessageId wygląda jak techniczny detal. Ciąg znaków generowany przy wysyłce maila, mający zapewnić jego unikalność. Problem w tym, że unikalność ta w praktyce bywa względna.

Nierzadko w kampaniach phishingowych i malware’owych ten sam lub bardzo podobny identyfikator pojawia się w wielu wiadomościach. Czasami wynika to z błędów w implementacji narzędzi używanych przez atakujących, a czasami z ich świadomych decyzji.

Dla analityka przyczyna nie ma jednak większego znaczenia. Liczy się efekt – możliwość powiązania wielu zdarzeń, które na pierwszy rzut oka wyglądają na niezależne.

Poniżej przedstawiona jest struktura pola InternetMessageId:

Jeden artefakt, wiele powiązań

Najciekawsze zaczyna się w momencie, gdy InternetMessageId trafia do zapytań w systemach telemetrycznych, takich jak Microsoft 365 Defender.

Zamiast analizować pojedynczą wiadomość, można nagle zobaczyć cały zestaw maili, które:

  • zostały wysłane w podobnym czasie,
  • mają wspólne cechy,
  • trafiają do różnych użytkowników.

To zmienia perspektywę. Incydent przestaje być pojedynczym alertem, a zaczyna wyglądać jak kampania.

I właśnie tutaj wchodzi threat hunting w swojej najczystszej formie – łączenie punktów, które wcześniej były rozproszone.

KQL jako narzędzie korelacji

W środowiskach Microsoft 365 Defender najprostszy scenariusz zaczyna się od wyszukania wszystkich wiadomości z tym samym InternetMessageId:

EmailEvents
| where InternetMessageId == "<ID_PODEJRZANEGO_MAILA>"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction
| order by Timestamp desc

Już to podstawowe zapytanie często daje obraz skali problemu. Dzięki niemu widzimy, kto jeszcze dostał daną wiadomość i co się z nią stało.

Jeśli chcemy pójść krok dalej, można spróbować znaleźć podobne wiadomości – na przykład bazując na fragmencie identyfikatora lub czasie wysyłki:

EmailEvents
| where Timestamp between (datetime(2026-04-01) .. datetime(2026-04-03))
| where InternetMessageId contains "@"
| summarize count() by InternetMessageId, SenderFromAddress
| order by count_ desc

Takie wyszukiwanie pozwala wyłapać grupy wiadomości, które mogą należeć do tej samej kampanii, nawet jeśli identyfikatory nie są identyczne.

Dlaczego to dobre podejście

InternetMessageIdma jedną ogromną zaletę – jest trudny do „rozmycia” w danych. Adresy IP mogą się zmieniać, domeny mogą być rotowane, a payloady mogą wyglądać inaczej w każdej próbce. Ale identyfikator wiadomości często pozostaje powtarzalny, szczególnie jeśli kampania jest prowadzona automatycznie. Czyni go to idealnym punktem zaczepienia. Stabilnym elementem w środowisku, które z natury jest zmienne i dynamiczne.

Choć najczęściej kojarzy się to z phishingiem, ten sam mechanizm działa również w innych scenariuszach.

Kampanie malware, dystrybucja loaderów czy nawet bardziej zaawansowane operacje APT – wszędzie tam, gdzie e-mail jest wektorem wejścia, InternetMessageId może pomóc w korelacji zdarzeń. To szczególnie przydatne w sytuacjach, gdy inne artefakty są już częściowo „spalone” albo trudne do wykorzystania.

Gdzie jest haczyk?

Oczywiście nie jest to magiczne rozwiązanie. Nie każda kampania będzie miała powtarzalne identyfikatory, a niektóre narzędzia używane przez atakujących generują je w sposób bardziej losowy. Dlatego InternetMessageIdnie zastępuje innych metod – raczej je uzupełnia.

Jego siła polega na tym, że może bardzo szybko potwierdzić lub obalić hipotezę. Jeśli kilka podejrzanych maili ma wspólny identyfikator, mamy mocny sygnał, że coś je łączy.

Podsumowanie

Threat hunting nie zawsze wymaga skomplikowanych technik. Czasami wystarczy dobrze wykorzystać coś, co już mamy w danych.

InternetMessageId jest dokładnie takim przykładem. Niby drobny szczegół, a w praktyce może pomóc odkryć całą kampanię, która inaczej pozostałaby rozproszona w logach. I właśnie dlatego warto czasem spojrzeć na te „mało istotne” pola trochę uważniej. Bo to często one składają się na pełny obraz incydentu.