Speciális keresési lekérdezési ajánlott eljárások

  • Cikk

Megjegyzés:

Szeretne Microsoft Defender XDR-t használni? További információ arról, hogy hogyan értékelheti ki és próbálhatja ki a Microsoft Defender XDR-t.

Érintett szolgáltatás:

  • Microsoft Defender XDR

Ezeket a javaslatokat alkalmazva gyorsabban kaphat eredményeket, és elkerülheti az időtúllépéseket összetett lekérdezések futtatásakor. A lekérdezési teljesítmény javítására vonatkozó további útmutatásért olvassa el a Kusto-lekérdezések ajánlott eljárásait.

A CPU-erőforráskvóták ismertetése

A méretétől függően minden bérlő rendelkezik hozzáféréssel a speciális veszélyforrás-keresési lekérdezések futtatásához lefoglalt CPU-erőforrások meghatározott mennyiségéhez. A különböző használati paraméterekkel kapcsolatos részletes információkért olvassa el a speciális veszélyforrás-keresési kvótákról és használati paraméterekről szóló cikket.

A lekérdezés futtatása után láthatja a végrehajtási időt és az erőforrás-használatot (Alacsony, Közepes, Magas). A Magas érték azt jelzi, hogy a lekérdezés több erőforrást használt a futtatáshoz, és javítható az eredmények hatékonyabb visszaadása érdekében.

A lekérdezés részletei a Microsoft Defender portál **Eredmények** lapján

Azoknak az ügyfeleknek, akik rendszeresen futtatnak több lekérdezést, nyomon kell követnie a használatot, és alkalmazniuk kell a cikkben található optimalizálási útmutatót a kvóták vagy használati paraméterek túllépése miatti fennakadások minimalizálása érdekében.

Tekintse meg a KQL-lekérdezések optimalizálását bemutató cikket, amely a lekérdezések fejlesztésének néhány leggyakoribb módját ismerteti.

Általános optimalizálási tippek

  • Új lekérdezések méretezése – Ha azt gyanítja, hogy egy lekérdezés nagy eredményhalmazt ad vissza, először mérje fel a számláló operátorral. Használjon korlátot vagy szinonimát take a nagy eredményhalmazok elkerüléséhez.

  • Szűrők korai alkalmazása – Időszűrők és egyéb szűrők alkalmazásával csökkentheti az adatkészletet, különösen az átalakítási és elemzési függvények használata előtt, például sztring(), replace(), trim(), toupper(), vagy parse_json(). Az alábbi példában a extractjson() elemzési függvényt akkor használja a rendszer, ha a szűrési operátorok csökkentették a rekordok számát.

    DeviceEvents
| where Timestamp > ago(1d)
| where ActionType == "UsbDriveMount"
| where DeviceName == "user-desktop.domain.com"
| extend DriveLetter = extractjson("$.DriveLetter", AdditionalFields)

  • A has beats tartalmaz – Ha el szeretné kerülni a szavakon belüli sztringrészek szükségtelen keresését, használja a operátort a hascontainshelyett. A sztringoperátorok ismertetése

  • Keresés adott oszlopokban – Egy adott oszlopban kell keresnie ahelyett, hogy teljes szöveges kereséseket futtat az összes oszlopban. Ne használja az parancsot * az összes oszlop ellenőrzéséhez.

  • Kis- és nagybetűk megkülönböztetése a sebesség szempontjából – A kis- és nagybetűket megkülönböztető keresések pontosabbak és általában hatékonyabbak. A kis- és nagybetűket megkülönböztető sztringoperátorok, például has_cs a és contains_csa neve általában a kifejezéssel végződik _cs. A kis- és nagybetűket megkülönböztető egyenlőség operátort == is használhatja a =~helyett.

  • Elemzés, ne nyerje ki – Amikor csak lehetséges, használja az elemzési operátort vagy egy elemzési függvényt, például parse_json(). Kerülje a sztringoperátort matches regex vagy a extract() függvényt, amelyek mindegyike reguláris kifejezést használ. Tartsa fenn a reguláris kifejezés használatát összetettebb forgatókönyvek esetén. További információ a függvények elemzéséről

  • Táblák szűrése nem kifejezések – Ne szűrjön számított oszlopra, ha táblázatoszlopra szűrhet.

  • Nincs három karakteres kifejezés – Ne hasonlítsa össze vagy szűrjön három vagy kevesebb karaktert tartalmazó kifejezések használatával. Ezek a kifejezések nincsenek indexelve, és az egyezésük több erőforrást igényel.

  • Szelektív kivetítés – Az eredmények érthetőbbé tétele úgy, hogy csak a szükséges oszlopokat vetít ki. Az egyes oszlopok kivetítése az összekapcsolási vagy hasonló műveletek futtatása előtt szintén segít a teljesítmény javításában.

Az join operátor optimalizálása

Az illesztési operátor két tábla sorait egyesíti a megadott oszlopok értékeinek egyeztetésével. Ezekkel a tippekkel optimalizálhatja az operátort használó lekérdezéseket.

  • Kisebb tábla balra – Az join operátor az illesztésutasítás bal oldalán lévő táblában lévő rekordokat a jobb oldali rekordokhoz hasonlítja. Ha a kisebb táblát a bal oldalon használja, kevesebb rekordot kell egyeztetni, ami felgyorsítja a lekérdezést.

    Az alábbi táblázatban a bal oldali táblázatot DeviceLogonEvents úgy csökkentjük, hogy csak három adott eszközt fedjen le, mielőtt fiókazonosítók alapján IdentityLogonEvents csatlakozna hozzá.

    DeviceLogonEvents
| where DeviceName in ("device-1.domain.com", "device-2.domain.com", "device-3.domain.com")
| where ActionType == "LogonFailed"
| join
    (IdentityLogonEvents
    | where ActionType == "LogonFailed"
    | where Protocol == "Kerberos")
on AccountSid

  • Használja az inner-join ízt – Az alapértelmezett illesztési íz vagy az innerunique-join deduplikálja a bal oldali táblázat sorait az illesztési kulccsal, mielőtt visszaadna egy sort minden egyezéshez a jobb oldali táblázathoz. Ha a bal oldali tábla több olyan sort tartalmaz, amelynek értéke megegyezik a join kulcséval, a rendszer deduplikálja ezeket a sorokat, hogy minden egyes egyedi értékhez egyetlen véletlenszerű sort hagyjon.

    Ez az alapértelmezett viselkedés fontos információkat hagyhat ki a bal oldali táblából, amelyek hasznos betekintést nyújtanak. Az alábbi lekérdezés például csak egy adott mellékletet tartalmazó e-mailt jelenít meg, még akkor is, ha ugyanazt a mellékletet több e-mail-üzenettel küldte el:

    EmailAttachmentInfo
| where Timestamp > ago(1h)
| where Subject == "Document Attachment" and FileName == "Document.pdf"
| join (DeviceFileEvents | where Timestamp > ago(1h)) on SHA256

    Ennek a korlátozásnak a megoldásához a inner-join ízt alkalmazzuk úgy, hogy a kind=inner bal oldali táblázat összes sorát egyező értékekkel jeleníti meg a jobb oldalon:

    EmailAttachmentInfo
| where Timestamp > ago(1h)
| where Subject == "Document Attachment" and FileName == "Document.pdf"
| join kind=inner (DeviceFileEvents | where Timestamp > ago(1h)) on SHA256

  • Rekordok összekapcsolása egy időablakból – A biztonsági események vizsgálatakor az elemzők az ugyanabban az időszakban előforduló kapcsolódó eseményeket keresik. Ugyanez a megközelítés akkor is előnyös, ha join csökkenti az ellenőrizendő rekordok számát.

    Az alábbi lekérdezés a rosszindulatú fájl fogadásától számított 30 percen belül ellenőrzi a bejelentkezési eseményeket:

    EmailEvents
| where Timestamp > ago(7d)
| where ThreatTypes has "Malware"
| project EmailReceivedTime = Timestamp, Subject, SenderFromAddress, AccountName = tostring(split(RecipientEmailAddress, "@")[0])
| join (
DeviceLogonEvents
| where Timestamp > ago(7d)
| project LogonTime = Timestamp, AccountName, DeviceName
) on AccountName
| where (LogonTime - EmailReceivedTime) between (0min .. 30min)

  • Időszűrők alkalmazása mindkét oldalon – Még ha nem is vizsgál egy adott időablakot, az időszűrők alkalmazása a bal és a jobb oldali táblákon is csökkentheti a rekordok számát az ellenőrzéshez és a teljesítmény javításához join . Az alábbi lekérdezés mindkét táblára vonatkozik Timestamp > ago(1h) , így csak az elmúlt óra rekordjait kapcsolja össze:

    EmailAttachmentInfo
| where Timestamp > ago(1h)
| where Subject == "Document Attachment" and FileName == "Document.pdf"
| join kind=inner (DeviceFileEvents | where Timestamp > ago(1h)) on SHA256

  • Teljesítménymutatók használata – Az operátorral kapcsolatos join tippek használatával utasíthatja a háttérrendszert a terhelés elosztására az erőforrás-igényes műveletek futtatásakor. További információ a csatlakozással kapcsolatos tippekről

    Az elosztási tipp például segít javítani a lekérdezési teljesítményt, ha a táblákat nagy számosságú kulccsal – sok egyedi értékkel rendelkező kulccsal – illeszti össze, például az AccountObjectId alábbi lekérdezésben:

    IdentityInfo
| where JobTitle == "CONSULTANT"
| join hint.shufflekey = AccountObjectId
(IdentityDirectoryEvents
    | where Application == "Active Directory"
    | where ActionType == "Private data retrieval")
on AccountObjectId

    A szórási tipp segít, ha a bal oldali táblázat kicsi (legfeljebb 100 000 rekord), és a jobb oldali táblázat rendkívül nagy. Az alábbi lekérdezés például olyan e-maileket próbál összekapcsolni, amelyek a táblában EmailUrlInfo hivatkozásokat tartalmazó összes üzenettel rendelkeznek:

    EmailEvents
| where Subject in ("Warning: Update your credentials now", "Action required: Update your credentials now")
| join hint.strategy = broadcast EmailUrlInfo on NetworkMessageId

Az summarize operátor optimalizálása

Az összegző operátor összesíti egy tábla tartalmát. Ezekkel a tippekkel optimalizálhatja az operátort használó lekérdezéseket.

  • Eltérő értékek keresése – A használatával summarize általában olyan egyedi értékeket kereshet, amelyek ismétlődőek lehetnek. Szükségtelen lehet olyan oszlopok összesítésére használni, amelyek nem rendelkeznek ismétlődő értékekkel.

    Bár egyetlen e-mail több esemény részét is képezheti, az alábbi példa nem hatékony, summarize mert az egyes e-mailek hálózati üzenetazonosítója mindig egyedi feladói címmel rendelkezik.

    EmailEvents
| where Timestamp > ago(1h)
| summarize by NetworkMessageId, SenderFromAddress

    Az summarize operátor könnyen lecserélhető a-ra project, ami potenciálisan ugyanazokat az eredményeket eredményezi, miközben kevesebb erőforrást használ fel:

    EmailEvents
| where Timestamp > ago(1h)
| project NetworkMessageId, SenderFromAddress

    Az alábbi példa a hatékonyabb használatát szemlélteti summarize , mivel egy feladói címnek több különböző példánya is lehet, amelyek ugyanarra a címzett címre küldenek e-mailt. Az ilyen kombinációk kevésbé eltérőek, és valószínűleg duplikáltak.

    EmailEvents
| where Timestamp > ago(1h)
| summarize by SenderFromAddress, RecipientEmailAddress

  • A lekérdezés elosztása – Bár summarize az ismétlődő értékeket tartalmazó oszlopokban a legjobban használják, ugyanezek az oszlopok nagy számossággal vagy nagy számú egyedi értékkel is rendelkezhetnek. Az join operátorhoz hasonlóan a elosztási tippetsummarize is alkalmazhatja a feldolgozási terhelés elosztásához, és növelheti a teljesítményt, ha nagy számosságú oszlopokon dolgozik.

    Az alábbi lekérdezés a különböző címzettek e-mail-címeinek megszámlálására szolgál summarize , amelyek nagy szervezetekben több százezer példányban futtathatók. A teljesítmény javítása érdekében a következőt hint.shufflekeytartalmazza:

    EmailEvents
| where Timestamp > ago(1h)
| summarize hint.shufflekey = RecipientEmailAddress count() by Subject, RecipientEmailAddress

Lekérdezési forgatókönyvek

Egyedi folyamatok azonosítása folyamatazonosítókkal

A folyamatazonosítókat (PID-ket) a Windows újra felhasználja, és újra felhasználja az új folyamatokhoz. Önmagukban nem szolgálhatnak egyedi azonosítóként adott folyamatokhoz.

Egy adott gépen lévő folyamat egyedi azonosítójának lekéréséhez használja a folyamatazonosítót a folyamat létrehozási idejével együtt. Folyamatok adatainak összekapcsolásakor vagy összesítésekor adja meg a gépazonosító (vagy DeviceIdDeviceName) oszlopait, a folyamatazonosítót (ProcessId vagy InitiatingProcessId) és a folyamat létrehozási idejét (ProcessCreationTime vagy InitiatingProcessCreationTime)

Az alábbi példalekérdezés megkeresi azokat a folyamatokat, amelyek több mint 10 IP-címet érnek el a 445-ös (SMB) porton keresztül, esetleg fájlmegosztásokat keresnek.

Példa lekérdezésre:

DeviceNetworkEvents
| where RemotePort == 445 and Timestamp > ago(12h) and InitiatingProcessId !in (0, 4)
| summarize RemoteIPCount=dcount(RemoteIP) by DeviceName, InitiatingProcessId, InitiatingProcessCreationTime, InitiatingProcessFileName
| where RemoteIPCount > 10

A lekérdezés úgy összegzi a InitiatingProcessId és InitiatingProcessCreationTime a függvényt, hogy egyetlen folyamatot tekintsen meg anélkül, hogy több folyamatot is ugyanazzal a folyamatazonosítóval kevert volna össze.

Lekérdezési parancssorok

A feladatok végrehajtásához számos módon lehet parancssort létrehozni. Egy támadó például hivatkozhat egy képfájlra elérési út nélkül, fájlkiterjesztés nélkül, környezeti változók vagy idézőjelek használatával. A támadó módosíthatja a paraméterek sorrendjét, vagy több idézőjelet és szóközt is hozzáadhat.

Ha tartósabb lekérdezéseket szeretne létrehozni a parancssorok körül, alkalmazza az alábbi eljárásokat:

  • Azonosítsa az ismert folyamatokat (például net.exe vagy psexec.exe) úgy, hogy a fájlnévmezőkben megfelelteti azokat ahelyett, hogy magára a parancssorra szűrne.
  • Parancssori szakaszok elemzése a parse_command_line() függvénnyel
  • Parancssori argumentumok lekérdezésekor ne keressen pontos egyezést több egymáshoz nem kapcsolódó argumentumhoz egy bizonyos sorrendben. Ehelyett használjon reguláris kifejezéseket, vagy használjon több különálló tartalmaz operátort.
  • A kis- és nagybetűket nem megkülönböztető egyezések használata. Például a , a és contains a helyett használja =~a , ina és contains_csa ==parancsot. in~
  • A parancssori eltömítési technikák mérséklése érdekében fontolja meg az idézőjelek eltávolítását, a vesszők szóközökre cserélését, valamint több egymást követő szóköz egyetlen szóközzel történő cseréjét. Vannak összetettebb rejtjelkészítési technikák, amelyek más megközelítéseket igényelnek, de ezek a finomhangolások segíthetnek a gyakoriak kezelésében.

Az alábbi példák különböző módszereket mutatnak be az "MpsSvc" tűzfalszolgáltatás leállításáhoznet.exe fájlra irányuló lekérdezés létrehozására:

// Non-durable query - do not use
DeviceProcessEvents
| where ProcessCommandLine == "net stop MpsSvc"
| limit 10

// Better query - filters on file name, does case-insensitive matches
DeviceProcessEvents
| where Timestamp > ago(7d) and FileName in~ ("net.exe", "net1.exe") and ProcessCommandLine contains "stop" and ProcessCommandLine contains "MpsSvc"

// Best query also ignores quotes
DeviceProcessEvents
| where Timestamp > ago(7d) and FileName in~ ("net.exe", "net1.exe")
| extend CanonicalCommandLine=replace("\"", "", ProcessCommandLine)
| where CanonicalCommandLine contains "stop" and CanonicalCommandLine contains "MpsSvc"

Adatok betöltése külső forrásokból

Ha hosszú listákat vagy nagy táblákat szeretne beépíteni a lekérdezésbe, használja az externaldata operátort egy adott URI-ból származó adatok betöltéséhez. Txt, CSV, JSON vagy más formátumú fájlokból is lekérhet adatokat. Az alábbi példa bemutatja, hogyan használhatja a MalwareBazaar (abuse.ch) által biztosított kártevő-SHA-256 kivonatok széles listáját az e-mailek mellékleteinek ellenőrzéséhez:

let abuse_sha256 = (externaldata(sha256_hash: string)
[@"https://bazaar.abuse.ch/export/txt/sha256/recent/"]
with (format="txt"))
| where sha256_hash !startswith "#"
| project sha256_hash;
abuse_sha256
| join (EmailAttachmentInfo
| where Timestamp > ago(1d)
) on $left.sha256_hash == $right.SHA256
| project Timestamp,SenderFromAddress,RecipientEmailAddress,FileName,FileType,
SHA256,ThreatTypes,DetectionMethods

Sztringek elemzése

Különböző függvények használhatók az elemzést vagy átalakítást igénylő sztringek hatékony kezelésére.

Karakterlánc Funkció Használati példa
Parancssorok parse_command_line() Bontsa ki a parancsot és az összes argumentumot.
Görbék parse_path() Bontsa ki egy fájl vagy mappa elérési útjának szakaszait.
Verziószámok parse_version() Egy legfeljebb négy szakaszból és szakaszonként legfeljebb nyolc karakterből álló verziószám dekonstruálható. Az elemzett adatok segítségével hasonlítsa össze a verzió korát.
IPv4-címek parse_ipv4() IPv4-cím átalakítása hosszú egész számmá. Az IPv4-címek konvertálása nélküli összehasonlításához használja a ipv4_compare() parancsot.
IPv6-címek parse_ipv6() Konvertáljon egy IPv4- vagy IPv6-címet a canonical IPv6 jelöléssé. Az IPv6-címek összehasonlításához használja a ipv6_compare()-t.

Az összes támogatott elemzési függvényről további információt a Kusto-sztringfüggvényekről szóló témakörben olvashat.

Megjegyzés:

Előfordulhat, hogy a cikkben szereplő táblák némelyike nem érhető el Végponthoz készült Microsoft Defender. Kapcsolja be a Microsoft Defender XDR, hogy több adatforrással keressen fenyegetéseket. A speciális veszélyforrás-keresési munkafolyamatokat Végponthoz készült Microsoft Defender-ról Microsoft Defender XDR-ra helyezheti át a speciális veszélyforrás-keresési lekérdezések áttelepítése Végponthoz készült Microsoft Defender.

Tipp

Szeretne többet megtudni? Lépjen kapcsolatba a Microsoft biztonsági közösségével a technikai közösségünkben: Microsoft Defender XDR Tech Community.