A Microsoft DART ransomware megközelítése és ajánlott eljárásai

Az ember által működtetett zsarolóprogramok nem rosszindulatú szoftverproblémák - ez egy emberi bűnözői probléma. Az áruproblémák kezelésére használt megoldások nem elegendőek egy olyan fenyegetés megelőzéséhez, amely jobban hasonlít egy nemzetállami fenyegetési szereplőre, aki:

  • Fájlok titkosítása előtt letiltja vagy eltávolítja a víruskereső szoftvert
  • Letiltja a biztonsági szolgáltatásokat és a naplózást az észlelés elkerülése érdekében
  • A váltságdíj-igény elküldése előtt megkeresi és megrongálja vagy törli a biztonsági másolatokat

Ezeket a műveleteket gyakran olyan jogszerű programokkal hajtják végre, amelyek rendszergazdai célokból már rendelkezhetnek a környezetében. A bűnözők kezében ezeket az eszközöket rosszindulatúan használják a támadások végrehajtására.

A zsarolóprogramok növekvő fenyegetésére való reagáláshoz a modern vállalati konfiguráció, a naprakész biztonsági termékek és a betanított biztonsági személyzet ébersége szükséges, hogy észleljék és reagáljanak a fenyegetésekre az adatok elvesztése előtt.

A Microsoft észlelési és válaszcsapata (DART) válaszol a biztonsági résekre, hogy segítsen az ügyfeleknek a kiberbűnözővé válásban. A DART helyszíni reaktív incidenskezelést és távoli proaktív vizsgálatokat biztosít. A DART a Microsoft stratégiai partnerségeit használja a világ biztonsági szervezeteivel és belső Microsoft-termékcsoportokkal a lehető legteljesebb és legáttekintőbb vizsgálat érdekében.

Ez a cikk azt ismerteti, hogyan kezeli a DART a Microsoft-ügyfelek zsarolóprogram-támadásait, hogy megfontolhassa a megközelítés elemeinek és az ajánlott eljárásoknak a saját biztonsági műveletek forgatókönyvére való alkalmazását.

A részletekért tekintse meg az alábbi szakaszokat:

Feljegyzés

Ez a cikk tartalma az A útmutatóból származik az emberi üzemeltetésű ransomware elleni küzdelemhez: 1 . rész és A útmutató az emberi üzemeltetésű zsarolóprogramok elleni küzdelemhez: 2 . rész A Microsoft Security csapat blogbejegyzései.

Hogyan használja a DART a Microsoft biztonsági szolgáltatásait?

A DART nagymértékben támaszkodik az összes vizsgálat adataira, és olyan Microsoft biztonsági szolgáltatások meglévő üzembe helyezését használja, mint a Office 365-höz készült Microsoft Defender, a Végponthoz készült Microsoft Defender, a Microsoft Defender for Identity és a Felhőhöz készült Microsoft Defender Alkalmazások.

Végponthoz készült Defender

A Defender for Endpoint a Microsoft vállalati végpontbiztonsági platformja, amelynek célja, hogy segítse a vállalati hálózati biztonsági elemzőket a speciális fenyegetések megelőzésében, észlelésében, kivizsgálásában és elhárításában. A Defender for Endpoint fejlett viselkedéselemzéssel és gépi tanulással képes támadásokat észlelni. Az elemzők a Defender for Endpointt használhatják a támadó viselkedéselemzéséhez.

Íme egy példa egy riasztásra a Végponthoz készült Microsoft Defender egy pass-the-ticket támadáshoz.

Example of an alert in Microsoft Defender for Endpoint for a pass-the-ticket attack

Az elemzők speciális keresési lekérdezéseket is végrehajthatnak a biztonsági kockázatjelzők (IOC-k) kimutatásához, illetve ismert viselkedés kereséséhez, ha azonosítják a veszélyforrás-szereplők csoportját.

Íme egy példa arra, hogyan használhatók speciális keresési lekérdezések az ismert támadói viselkedés megkeresésére.

An example of an advanced hunting query.

A Defender for Endpoint szolgáltatásban valós idejű szakértői szintű monitorozási és elemzési szolgáltatáshoz férhet hozzá Microsoft Veszélyforrás-szakértők a folyamatban lévő gyanús szereplői tevékenységhez. Igény szerinti szakértőkkel is együttműködhet a riasztásokkal és incidensekkel kapcsolatos további elemzések érdekében.

Íme egy példa arra, hogyan jeleníti meg a Defender for Endpoint a részletes ransomware-tevékenységeket.

Example of how Defender for Endpoint shows detailed ransomware activity.

Defender for Identity

A Defender for Identity használatával kivizsgálhatja az ismert feltört fiókokat, és potenciálisan feltört fiókokat kereshet a szervezetében. A Defender for Identity riasztásokat küld az ismert rosszindulatú tevékenységekről, amelyeket a szereplők gyakran használnak, például DCSync-támadásokat, távoli kódvégrehajtási kísérleteket és kivonatoló támadásokat. A Defender for Identity lehetővé teszi a gyanús tevékenységek és fiókok azonosítását a nyomozás szűkítéséhez.

Íme egy példa arra, hogy a Defender for Identity hogyan küld riasztásokat a ransomware-támadásokkal kapcsolatos ismert rosszindulatú tevékenységekről.

An example of how Defender for Identity sends alerts for ransomware attacks

Defender for Cloud Apps

Felhőhöz készült Defender Alkalmazások (korábbi nevén Microsoft Felhőappbiztonság) lehetővé teszik az elemzők számára, hogy észleljék a felhőalkalmazások szokatlan viselkedését a zsarolóprogramok, a feltört felhasználók vagy a gazember alkalmazások azonosítása érdekében. Felhőhöz készült Defender Az alkalmazások a Microsoft felhőelérési biztonsági közvetítőjének (CASB) megoldása, amely lehetővé teszi a felhőszolgáltatások és a felhőszolgáltatásokban a felhasználók általi adathozzáférés monitorozását.

Íme egy példa a Felhőhöz készült Defender-alkalmazások irányítópultjára, amely lehetővé teszi az elemzésnek a felhőalkalmazások szokatlan viselkedésének észlelését.

an example of the Defender for Cloud Apps dashboard.

Microsoft Biztonsági pontszám

A Microsoft Defender XDR-szolgáltatások készlete élő szervizelési javaslatokat nyújt a támadási felület csökkentésére. A Microsoft Biztonságos pontszám egy szervezet biztonsági helyzetének mérése, amely nagyobb számban jelzi, hogy több fejlesztési művelet történt. A Biztonságos pontszám dokumentációjában további információt talál arról, hogy a szervezet hogyan használhatja ezt a funkciót a környezetükön alapuló szervizelési műveletek rangsorolására.

A DART megközelítése a ransomware incidensvizsgálatok elvégzéséhez

Minden erőfeszítést meg kell tennie annak meghatározásához, hogy a támadó hogyan fért hozzá az eszközeihez, hogy a biztonsági rések orvosolhatók legyenek. Ellenkező esetben nagyon valószínű, hogy a jövőben is ugyanez a típusú támadás történik. Bizonyos esetekben a fenyegetést okozó szereplő lépéseket tesz a nyomok eltüntetésére és a bizonyítékok megsemmisítésére, így lehetséges, hogy az események teljes láncolata nem feltétlenül egyértelmű.

A DART ransomware-vizsgálatok három fő lépése:

Lépés Cél Első kérdések
1. A jelenlegi helyzet értékelése A hatókör ismertetése Mi volt az első tudomásod a zsarolóprogram-támadásról?

Mikor/mikor értesült először az incidensről?

Milyen naplók érhetők el, és van-e arra utaló jel, hogy a szereplő jelenleg hozzáfér a rendszerekhez?
2. Az érintett üzletági (LOB) alkalmazások azonosítása Rendszerek visszaállítása online állapotba Az alkalmazásnak szüksége van identitásra?

Elérhetők az alkalmazás, a konfiguráció és az adatok biztonsági másolatai?

A biztonsági másolatok tartalmát és integritását rendszeresen ellenőrzik visszaállítási gyakorlattal?
3. A biztonsági rések helyreállításának (CR) folyamatának meghatározása Támadóvezérlés eltávolítása a környezetből n/a

1. lépés: A jelenlegi helyzet értékelése

A jelenlegi helyzet értékelése kritikus fontosságú az incidens hatókörének megértéséhez, valamint a legjobb személyek kiválasztásához, akik segítséget nyújtanak, valamint a vizsgálati és szervizelési feladatok megtervezése és hatóköre. Az alábbi kezdeti kérdések megválaszolása kulcsfontosságú a helyzet meghatározásában.

Mi volt az első tudomásod a ransomware támadásról?

Ha az informatikai személyzet azonosította a kezdeti fenyegetést (például a biztonsági másolatok törlésének bejelentését, a víruskereső riasztásokat, a végponti észlelés és reagálás (Végponti észlelés és reagálás) riasztásokat vagy a gyanús rendszermódosításokat, gyakran gyors, határozott intézkedéseket lehet tenni a támadás megelőzésére, általában az összes bejövő és kimenő internetes kommunikáció letiltásával. Ez a fenyegetés átmenetileg hatással lehet az üzleti műveletekre, de ez általában sokkal kevésbé lenne hatásosabb, mint egy zsarolóprogramot üzembe helyező támadó.

Ha egy felhasználói hívás az informatikai ügyfélszolgálathoz azonosította a fenyegetést, elegendő előzetes figyelmeztetést kaphat a támadás hatásainak megelőzéséhez vagy minimalizálásához szükséges védelmi intézkedések meghozásához. Ha egy külső entitás, például a bűnüldözés vagy egy pénzügyi intézmény azonosította a fenyegetést, valószínű, hogy a kár már megtörtént, és a környezetben olyan bizonyítékokat fog látni, amelyek szerint a fenyegetés szereplője rendszergazdai ellenőrzést végez a hálózat felett. Ez a bizonyíték a zsarolóprogramok jegyzeteitől, a zárolt képernyőktől vagy a váltságdíj-igényektől is terjedhet.

Mikor és mikor értesült először az incidensről?

A kezdeti tevékenység dátumának és időpontjának meghatározása azért fontos, mert segít szűkíteni a kezdeti osztályozás hatókörét, hogy a támadó gyorsan nyerjen. További kérdések lehetnek a következők:

  • Milyen frissítések tűntek el ezen a napon? Fontos tisztában lenni azzal, hogy milyen biztonsági réseket kihasználhatott a támadó.
  • Milyen fiókokat használtak ezen a napon?
  • Milyen új fiókokat hoztak létre azóta?

Milyen naplók érhetők el, és van-e arra utaló jel, hogy a szereplő jelenleg hozzáfér a rendszerekhez?

A naplók – például a víruskereső, a Végponti észlelés és reagálás és a virtuális magánhálózat (VPN) – a feltételezett kompromisszumra utalnak. Az utánkövetési kérdések a következők lehetnek:

  • A naplók egy biztonsági információ- és eseménykezelési (SIEM) megoldásban vannak összesítve , például a Microsoft Sentinel, a Splunk, az ArcSight és mások és az aktuálisak? Mi az adatok megőrzési ideje?
  • Vannak gyanúsan feltört rendszerek, amelyek szokatlan tevékenységet tapasztalnak?
  • Vannak gyanúsan feltört fiókok, amelyeket úgy tűnik, hogy a támadó aktívan használ?
  • Van-e bizonyíték az aktív parancsokra és vezérlőkre (C2s) Végponti észlelés és reagálás, tűzfal, VPN, webproxy és egyéb naplókban?

A jelenlegi helyzet felmérésének részeként szükség lehet egy Active Directory tartományi szolgáltatások (AD DS) tartományvezérlőre, amely nem sérült, vagy egy tartományvezérlő legutóbbi biztonsági másolatára, vagy egy friss tartományvezérlőre, amely karbantartás vagy frissítés céljából offline állapotba került. Azt is megállapíthatja, hogy szükség volt-e többtényezős hitelesítésre (MFA) a vállalat minden tagja számára, és hogy használták-e a Microsoft Entra-azonosítót.

2. lépés: Az incidens miatt nem elérhető LOB-alkalmazások azonosítása

Ez a lépés kritikus fontosságú a rendszerek online állapotba helyezésének leggyorsabb módja, a szükséges bizonyítékok beszerzése során.

Az alkalmazásnak szüksége van identitásra?

  • Hogyan történik a hitelesítés?
  • Hogyan tárolják és kezelik a hitelesítő adatokat, például a tanúsítványokat vagy titkos kulcsokat?

Elérhetők az alkalmazás, a konfiguráció és az adatok tesztelt biztonsági másolatai?

  • A biztonsági másolatok tartalmát és integritását rendszeresen ellenőrzik visszaállítási gyakorlattal? Ez az ellenőrzés különösen fontos a konfigurációkezelési módosítások vagy a verziófrissítések után.

3. lépés: A sérült helyreállítási folyamat meghatározása

Erre a lépésre akkor lehet szükség, ha megállapította, hogy a vezérlősík, amely általában az AD DS, sérült.

A vizsgálatnak mindig olyan kimenetet kell biztosítania, amely közvetlenül a CR-folyamatba kerül. A CR az a folyamat, amely eltávolítja a támadók irányítását a környezetből, és taktikailag növeli a biztonsági helyzet egy meghatározott időszakon belül. A CR biztonsági incidens után történik. Ha többet szeretne megtudni a CR-ről, olvassa el a Microsoft Compromise Recovery Security Practice csapatÁNAK CRSP-jét : Az ügyfelek mellett a kibertámadások elleni vészhelyzeti csapat blogbejegyzését.

Miután összegyűjtötte az 1. és a 2. lépésben szereplő kérdésekre adott válaszokat, létrehozhat egy feladatlistát, és hozzárendelheti a tulajdonosokat. A sikeres incidensválasz-előjegyzés kulcsfontosságú tényezője az egyes munkaelemek részletes dokumentációja (például a tulajdonos, az állapot, az eredmények, a dátum és az idő), így a megállapítások összeállítása az előjegyzés végén egyszerű folyamat.

DART-javaslatok és ajánlott eljárások

Az alábbiakban a DART javaslatait és ajánlott eljárásait találja az elszigetelési és az incidens utáni tevékenységekhez.

Elszigetelés

Az elszigetelés csak akkor történhet meg, ha meghatározza, hogy mit kell tartalmaznia. Zsarolóprogramok esetén a támadó célja olyan hitelesítő adatok beszerzése, amelyek lehetővé teszik a magas rendelkezésre állású kiszolgálók rendszergazdai ellenőrzését, majd a zsarolóprogram üzembe helyezését. Bizonyos esetekben a fenyegetéselktor azonosítja a bizalmas adatokat, és kiszűri őket egy általuk kezelt helyre.

A taktikai helyreállítás egyedi a szervezet környezete, iparága, valamint informatikai szakértelme és tapasztalata szempontjából. Az alábbi lépések ajánlottak a szervezet rövid távú és taktikai elszigetelési lépéseihez. A hosszú távú útmutatással kapcsolatos további információkért tekintse meg a kiemelt hozzáférés biztosítását ismertető témakört. A zsarolóprogramok és zsarolás átfogó áttekintéséért és a szervezet előkészítésének és védelmének módjáért tekintse meg az ember által üzemeltetett zsarolóprogramokat.

Az új fenyegetésvektorok felderítése során a következő elszigetelési lépések egyidejűleg elvégezhetők.

1. lépés: A helyzet hatókörének értékelése

  • Mely felhasználói fiókok lettek feltörve?
  • Mely eszközök érintettek?
  • Mely alkalmazásokat érinti?

2. lépés: Meglévő rendszerek megőrzése

  • Tiltsa le az összes kiemelt felhasználói fiókot, kivéve, ha a rendszergazdák kis számú fiókot használnak az AD DS-infrastruktúra integritásának visszaállításához. Ha úgy véli, hogy egy felhasználói fiók biztonsága sérült, azonnal tiltsa le.
  • Elkülönítheti a feltört rendszereket a hálózatról, de ne állítsa le őket.
  • A két tartomány legalább egy ismert jó tartományvezérlője elkülönítése még jobb. Válassza le őket a hálózatról, vagy állítsa le teljesen. A cél az, hogy megállítsuk a zsarolóprogramok kritikus rendszer-identitásra való terjedését a legkiszolgáltatottabbak között. Ha az összes tartományvezérlő virtuális, győződjön meg arról, hogy a virtualizálási platform rendszere és adatmeghajtói offline külső adathordozóra vannak biztonsági másolatot készítve, amely nem csatlakozik a hálózathoz, amennyiben maga a virtualizálási platform sérül.
  • Elkülönítheti a kritikus fontosságú, jól ismert alkalmazáskiszolgálók, például az SAP, a konfigurációkezelési adatbázis (CMDB), a számlázás és a könyvelési rendszerek elkülönítését.

Ez a két lépés egyidejűleg elvégezhető új fenyegetésvektorok felfedezésekor. Tiltsa le ezeket a fenyegetésvektorokat, majd próbáljon meg megtalálni egy ismert, jó rendszert, amely elkülöníti a hálózatot.

Egyéb taktikai elszigetelési műveletek a következők lehetnek:

  • Állítsa alaphelyzetbe a krbtgt-jelszót, kétszer gyors egymás után. Fontolja meg egy szkriptelt, megismételhető folyamat használatát. Ez a szkript lehetővé teszi a krbtgt-fiók jelszavának és a kapcsolódó kulcsok visszaállítását, miközben minimalizálja a kerberosi hitelesítési problémák előfordulásának valószínűségét. A lehetséges problémák minimalizálása érdekében a krbtgt élettartama az első jelszó-visszaállítás előtt egy vagy több alkalommal csökkenthető, így a két alaphelyzetbe állítás gyorsan elvégezhető. Vegye figyelembe, hogy a környezetben tartani kívánt tartományvezérlőknek online állapotban kell lenniük.

  • Helyezzen üzembe egy csoportházirendet a teljes tartományon, amely megakadályozza a kiemelt bejelentkezést (tartományi Rendszergazda) a tartományvezérlők és a csak kiemelt rendszergazdai jogosultságú munkaállomások (ha vannak) számára.

  • Telepítse az operációs rendszerek és alkalmazások hiányzó biztonsági frissítéseit. Minden hiányzó frissítés egy potenciális fenyegetésvektor, amelyet a támadók gyorsan azonosíthatnak és kihasználhatnak. Végponthoz készült Microsoft DefenderA veszélyforrások és sebezhetőségek kezelése egyszerű módot kínál a hiányzó frissítések pontos megtekintésére, valamint a hiányzó frissítések lehetséges hatásainak megtekintésére.

  • Ellenőrizze, hogy minden külső alkalmazás, beleértve a VPN-hozzáférést is, többtényezős hitelesítéssel van-e védve, lehetőleg biztonságos eszközön futó hitelesítési alkalmazás használatával.

  • Ha az eszközök nem használják a Defender for Endpointet elsődleges víruskereső szoftverként, futtasson teljes vizsgálatot Microsoft Biztonsági ellenőrzőeszköz izolált, jól ismert rendszereken, mielőtt újra csatlakoztatja őket a hálózathoz.

  • Az örökölt operációs rendszerek esetében frissítsen egy támogatott operációs rendszerre, vagy szerelje le ezeket az eszközöket. Ha ezek a lehetőségek nem érhetők el, minden lehetséges intézkedést meg kell tenniük az eszközök elkülönítésére, beleértve a hálózati/VLAN-elkülönítést, az Internet Protocol biztonsági (IPsec) szabályait és a bejelentkezési korlátozásokat, hogy csak a felhasználók/eszközök férhessenek hozzá az alkalmazásokhoz az üzletmenet folytonosságának biztosítása érdekében.

A legkockázatosabb konfigurációk a kritikus fontosságú rendszerek olyan régi operációs rendszereken való futtatásából állnak, mint a Windows NT 4.0 és az alkalmazások, mind örökölt hardveren. Nem csak ezek az operációs rendszerek és alkalmazások nem biztonságosak és sebezhetők, ha a hardver meghibásodik, a biztonsági másolatok általában nem állíthatók vissza a modern hardveren. Ha a régi hardverek cseréje nem érhető el, ezek az alkalmazások nem fognak működni. Fontolja meg ezeknek az alkalmazásoknak a konvertálását az aktuális operációs rendszereken és hardvereken való futtatásra.

Incidens utáni tevékenységek

A DART az alábbi biztonsági javaslatokat és ajánlott eljárásokat javasolja az egyes incidensek után.

  • Győződjön meg arról, hogy az ajánlott eljárások az e-mail- és együttműködési megoldásokhoz szükségesek, hogy a támadók nehezebben használják fel őket, miközben lehetővé teszik a belső felhasználók számára, hogy könnyen és biztonságosan hozzáférjenek a külső tartalmakhoz.

  • Kövesse Teljes felügyelet belső szervezeti erőforrások távelérési megoldásainak biztonsági ajánlott eljárásait.

  • A kritikus hatással rendelkező rendszergazdáktól kezdve kövesse a fiókbiztonsággal kapcsolatos ajánlott eljárásokat, beleértve a jelszó nélküli hitelesítést vagy az MFA-t.

  • Átfogó stratégia implementálása a kiemelt hozzáférés veszélyeztetésének kockázatának csökkentésére.

  • Adatvédelmet valósíthat meg a zsarolóprogram-technikák blokkolásához, valamint a támadások gyors és megbízható helyreállításának megerősítéséhez.

  • Tekintse át a kritikus rendszereket. Ellenőrizze, hogy van-e védelem és biztonsági mentés a szándékos támadók törlése vagy titkosítása ellen. Fontos, hogy rendszeresen tesztelje és ellenőrizze ezeket a biztonsági másolatokat.

  • Gondoskodjon a végpontok, e-mailek és identitások gyakori támadásainak gyors észleléséről és elhárításáról.

  • Aktívan felfedezheti és folyamatosan javíthatja környezete biztonsági állapotát.

  • Frissítse a szervezeti folyamatokat a jelentős ransomware-események kezeléséhez, és egyszerűsítse a kiszervezést a súrlódás elkerülése érdekében.

PAM

A PAM (korábbi nevén rétegzett felügyeleti modell) használata javítja a Microsoft Entra ID biztonsági helyzetét, amely a következőket foglalja magában:

  • Rendszergazdai fiókok lebontása egy "megtervezett" környezetben– minden szinten egy-egy fiók, általában négy:

  • Vezérlősík (korábbi nevén 0. szint): tartományvezérlők és egyéb kulcsfontosságú identitásszolgáltatások Rendszergazda, például Active Directory összevonási szolgáltatások (AD FS) (ADFS) vagy Microsoft Entra Csatlakozás, amely magában foglalja azokat a kiszolgálóalkalmazásokat is, amelyek rendszergazdai engedélyeket igényelnek az AD DS-hez, például az Exchange Serverhez.

  • A következő két gép korábban az 1. réteg volt:

    • Felügyeleti sík: Eszközkezelés, monitorozás és biztonság.

    • Data/Workload Plane: Alkalmazások és alkalmazáskiszolgálók.

  • A következő két gép korábban 2. réteg volt:

    • Felhasználói hozzáférés: Hozzáférési jogosultságok a felhasználók (például fiókok) számára.

    • Alkalmazáshozzáférés: Hozzáférési jogosultságok alkalmazásokhoz.

  • Ezen síkok mindegyikéhez külön felügyeleti munkaállomás tartozik , és csak abban a síkban lévő rendszerekhez fér hozzá. A más síkokról származó egyéb fiókok hozzáférése a többi sík munkaállomásaihoz és kiszolgálóihoz az adott gépekhez beállított felhasználói jogosultsági hozzárendelések révén megtagadva.

A PAM nettó eredménye a következő:

  • A feltört felhasználói fiókok csak ahhoz a síkhoz férnek hozzá, amelyhez tartoznak.

  • A bizalmasabb felhasználói fiókok nem fognak alacsonyabb biztonsági szinttel rendelkező munkaállomásokra és kiszolgálókra bejelentkezni, ezáltal csökkentve az oldalirányú mozgást.

KÖR

A Microsoft Windows és az AD DS alapértelmezés szerint nem rendelkezik központi felügyelettel a munkaállomásokon és tagkiszolgálókon található helyi rendszergazdai fiókokról. Ez olyan gyakori jelszót eredményezhet, amely az összes helyi fiókhoz, vagy legalábbis gépcsoportokhoz van adva. Ez a helyzet lehetővé teszi, hogy a támadók feltörjenek egy helyi rendszergazdai fiókot, majd ezzel a fiókkal férhessenek hozzá a szervezet más munkaállomásaihoz vagy kiszolgálóihoz.

A Microsoft LAPS szolgáltatása ezt a csoportházirend ügyféloldali bővítményével enyhíti, amely rendszeres időközönként módosítja a helyi rendszergazdai jelszót a munkaállomásokon és a kiszolgálókon a szabályzatkészletnek megfelelően. Ezek a jelszavak különbözőek, és attribútumként vannak tárolva az AD DS számítógép-objektumban. Ez az attribútum lekérhető egy egyszerű ügyfélalkalmazásból az attribútumhoz rendelt engedélyektől függően.

A LAPS megköveteli, hogy az AD DS-sémát ki kell terjeszteni, hogy lehetővé tegye a további attribútumot, a LAPS csoportházirend-sablonokat, valamint egy kis ügyféloldali bővítményt kell telepíteni minden munkaállomásra és tagkiszolgálóra az ügyféloldali funkciók biztosításához.

A LAPS-t a Microsoft letöltőközpontból szerezheti be.

További ransomware-erőforrások

A Microsoft legfontosabb információi:

Microsoft 365:

Microsoft Defender XDR:

Microsoft Azure:

Felhőhöz készült Microsoft Defender alkalmazások:

A Microsoft Security csapatának blogbejegyzései: