Figyelem!!! Az Nt Authority\system egy féreg!!! Le a felhasználói szinttel: emelje meg az NT AUTHORITYSYSTEM jogosultságait a Windows bármely verziójában Mi a helyzet a többi helyi fiókkal

Elég egy programot "Futtatni rendszergazdaként", hogy a Feladatkezelőben lássa, hogy a felhasználója önmaga, és nem adminisztrátor, és ez a csoda csak a hozzáférési token módosításával érhető el, nem pedig a SID cseréjével.

Másodszor, az NT-AUTHORITY és a SYSTEM nem fiókok és nem csoportok, annak ellenére, hogy számos más forrás (még a Microsofton belül is) azt állítja. Az SID-nek általában van egy neve, amely szükség esetén megjelenik. A felhasználói fiók a saját SID-jét fő SID-ként adja hozzá a hozzáférési tokenhez, amely meghatározza a különböző segédprogramok által megjelenített nevet is. A hozzáférési jogkivonat azonban tartalmazhat további SID-ket, például az összes csoporthoz, amelyhez az adott felhasználói fiók tartozik. Az engedélyek ellenőrzésekor a Windows minden olyan SID-t keres a hozzáférési tokenben, amely rendelkezik ezzel az engedéllyel.

Néhány jól ismert Windows SID-nek a Windows által jelentett neve lesz, bár valójában nem tartoznak egyetlen fiókhoz sem.

A LocalSystem-fiók egy előre meghatározott helyi fiók, amelyet a szolgáltatásvezérlés-kezelő használ. [...] A tokenje tartalmazza az NT AUTHORITY\SYSTEM és a BUILTIN\Administrators SID-t; ezeket a számlákat hozzáférhetnek a legtöbb rendszerobjektumhoz.

Már a fenti szövegben is látható az a zűrzavar, amely még a Microsoft dokumentációjában is uralkodik a rendszer SID-k tekintetében, amelyek nem pontosan fiókok vagy csoportok - amelyek csak engedélyek halmaza. Ez a zavar tovább terjed más segédprogramokra és cikkekre, ezért minden visszaküldött információt alaposan meg kell vizsgálni.

A Microsoft jól ismert biztonsági azonosítói a Windows operációs rendszerekben című cikke az összes rendszer-SID-t részletezi, amelyek közül néhányat alább felsorolok:

Következtetés: Az NT-AUTHORITY\SYSTEM egy biztonsági azonosító neve, amely sem nem csoport, sem nem fiók. A Feladatkezelőben RENDSZER néven jelenik meg, ha egy program fő SID-je. Leginkább "pszeudofióknak" nevezném.

A lapszám megjelenése előtt néhány nappal a Metasploit megvásárolta
friss modult, amiről egyszerűen nem tudtunk nem mesélni. Köszönet
új getsystem parancs, egy kompromittált rendszeren lehetségessé vált a go
Felhasználói szintről ring0-ra, NT AUTHORITY\SYSTEM megszerzésével! És ez bármelyikben benne van
Windows verziók.

2010. január 19-én nyilvánossá vált egy 0 napos biztonsági rés, amely lehetővé teszi
jogosultság kiterjesztése a Windows bármely verzióján az NT 3.1-től
1993-ban, és az újszerű "héttel" végződve. Az exploit-db.com oldalon Tavis hacker
Ormandy közzétette a KiTrap0d sploit forrását és a lefordított változatot is
bináris használatra kész. Bárki kipróbálhatja az eredeti szloitot
hajlandó. Ehhez csak ki kell bontania a vdmexploit.dll és a vdmallowed.exe fájlt az archívumból,
vigye át valamilyen módon az áldozat gépére, és futtassa ott az exe fájlt. V
eredmény, függetlenül attól, hogy melyik felhasználói fiókot
indításkor megjelenik egy konzol rendszer felhasználói jogosultságokkal, azaz NT
HATÓSÁG\RENDSZER. Az ellenőrzés kedvéért futtathat egy sploitot a gépen,
korábban normál felhasználóval bejelentkezve a rendszerbe. Indítás után
A sploit egy új cmd.exe ablakot nyit meg maximális jogosultságokkal.

Mit ad? Képzeljünk el egy olyan helyzetet, amikor egy törés áttör valamilyen alkalmazáson és
parancsértelmezőt kap a távoli számítógépen. Legyen az internetre kiosztva
Explorer - ebben az esetben a hacker jogosultságokkal fér hozzá a rendszerhez
az a felhasználó, akinek a fiókja alatt a böngésző elindult. Nem vitatkozom, nagyon
gyakran ez egy rendszergazdai jogokkal rendelkező fiók lesz (a felhasználó a hibás), de
ha nem? Itt használhatja a KiTrap0d-t a jogosultságok növelésére
az NT AUTHORITY\SYSTEM-nek! Sőt, még azok a felhasználók is, akik a csoport tagjai
rendszergazda nem tud hozzáférni a rendszer egyes részeihez, például a számára
felhasználói jelszavak hash-einek olvasása (erről lentebb). És NT rendszerfiók -
talán! Mindezzel együtt a cikk megjelenése idején egyetlen folt sem től
A Microsoft nem adott ki javítást a biztonsági réshez.

Operációs rendszer átvétele

Az eredeti felosztást nem mutatjuk be gyakorlatban, mert 25
Januárban egy új szkript került a Metasploitba, aminek köszönhetően használhatod
A KiTrap0d még kényelmesebbé vált. A modul adatbázisaiba eredetileg bekerült változat az volt
instabil és nem mindig működött, de még fél nap sem telt el, mint az összes hiba
Eltüntetett. Most a modul letöltődik az összes többi frissítéssel együtt,
így a telepítéshez válassza ki a „Metasploit frissítés” menüpontot.
Most, hogy hozzáfér a távoli rendszerhez, beírhatja a „run kitrap0d” parancsot, és gépelhet
működésbe olvad. "De mivel egy ilyen pia elment, erre az esetre rá fogunk jönni
különleges parancsot" gondolták a Metasploit fejlesztői. Ennek eredményeként
olyan csodálatos "jogosultságok emelése" parancsnak bizonyult, amely a következőn keresztül érhető el
mérőmérő bővítmény - nagyon szeretjük :).

Tehát hozzáférésünk van egy távoli rendszerhez (szemléltető példa
A kiaknázást az "Aurora művelet" című cikk tartalmazza, és a konzolban vagyunk
metasploit. Lássuk, hogyan állunk a jogokkal:

meterpreter > getuid

Igen, normál felhasználó. Talán még a csoporthoz is tartozik
rendszergazdák, de minket ez nem érdekel. Csatlakoztatjuk azt a modult, amelyben megvalósul
a számunkra érdekes getsystem parancsot, és a on megjelenítésével ellenőrizzük, hogy betöltődött-e
képernyő súgó:

mérőmérő > priv
Bővítmény betöltése priv...sikeres.
meterpreter > getsystem -h
Használata: getsystem
Próbálja meg a helyi rendszer kiváltságait emelni.
OPCIÓK:

H Help Banner.
-t Az alkalmazandó technika. (Alapértelmezett "0").
0: Minden technika elérhető
1.: Szolgáltatás – Named Pipe megszemélyesítés (memóriában/adminisztrátor)
2: Szolgáltatás – Névvel megszemélyesített cső (Droppper/Admin)
3: Szolgáltatás – Token sokszorosítás (memóriában/adminisztrátor)
4: Exploit - KiTrap0D (memóriában/felhasználó)

Amint láthatja, a KiTrap0D sploit a parancs funkcióinak csak egy részét valósítja meg.
Ha sikerült megragadnia egy shell-t egy olyan felhasználóval, aki már rendelkezik jogokkal
rendszergazda, használhatja
három másik technika (a -t kapcsoló segítségével kiválaszthatja a szükségeset). Így vagy úgy, pontosítás nélkül
egyáltalán nincs paraméter, azt mondjuk a metasploitnak, hogy használhatja
bármelyik megközelítés. Beleértve a KiTrap0D-t is, amely szintre emeli kiváltságainkat
A „rendszer”, függetlenül attól, hogy milyen jogaink vannak most.

meterpreter > getsystem
...rendszert kapott (a 4. technikán keresztül).

Igen, kaptunk egy üzenetet a privilégiumok sikeres eszkalációjáról és a támadásról
a KiTrap0D-t használták – úgy tűnik, ennek van elsőbbsége. Tényleg
bemászott a rendszerbe? Nézzük meg aktuális UID-ünket (felhasználói azonosítónkat):

meterpreter > getuid

Van! Csak egy parancs a metasploit konzolon és NT AUTHORITY\SYSTEM jogok
minket a zsebében. Továbbá általánosságban elmondható, hogy minden lehetséges. Hadd emlékeztesselek arra, hogy egyetlen
a magazin megjelenése idején nem volt javítás a Microsofttól.

Jelszavak kiírása

Mivel rendelkezik hozzáféréssel a rendelkezésre álló rendszerfiókhoz, ebből ki kell bontania
valami hasznosat. A Metasploit arzenáljában van egy csodálatos hashdump parancs -
a híres pwdump segédprogram fejlettebb verziója. Ráadásul az utolsóban
A metasploit verziója tartalmazza a használó szkript átdolgozott verzióját
a LANMAN/NTLM kivonat kibontásának modernizált elve, és még nem észlelték
antivírusok. De nem ez a lényeg. Fontos, hogy a hashdump parancs végrehajtásához
NT AUTHORITY\SYSTEM jogosultságok szükségesek. Ellenkező esetben a program hibát jelez
"[-] priv_passwd_get_sam_hashes: A művelet sikertelen: 87". Ez azért történik, mert
hogy a felhasználói jelszavak LANMAN/NTLM-kivonatait speciális nyilvántartási ágakban tárolják
A HKEY_LOCAL_MACHINE\SAM és a HKEY_LOCAL_MACHINE\SECURITY még csak nem is elérhető
rendszergazdák. Csak rendszerfiók jogosultságokkal olvashatók.
Általánosságban elmondható, hogy ehhez használja a sploit, majd a hashdump parancsot
a kivonat kibontása a rendszerleíró adatbázisból helyben egyáltalán nem szükséges. De ha ilyen
van rá lehetőség, miért ne?

meterpreter > getuid
Szerver felhasználónév: NT AUTHORITY\SYSTEM

meterpreter > hashdump futtatása
[*] A rendszerindító kulcs beszerzése...
[*] A hboot kulcs kiszámítása a SYSKEY 3ed7 használatával[...]
[*] A felhasználói lista és a kulcsok lekérése...
[*] Felhasználói kulcsok visszafejtése...
[*] Jelszókivonatok kiíratása...

Rendszergazda:500:aad3b435b51404eeaad3b435b51404ee:...
Vendég:501:aad3b435b51404eeaad3b435b51404ee:...
HelpAssistant:1000:ce909bd50f46021bf4aa40680422f646:...

Hashes kapott. Maradhat például, hogy megetetjük őket valamelyik brutális erővel,
l0phtcrack .

Hogyan lehet visszaadni a jogosultságokat?

Vicces helyzet történt, amikor megpróbáltam visszaadni a normálisak jogait
felhasználó vissza. A rev2self parancs, amit találtam, nem működött, és még mindig
Maradt az "NT AUTHORITY\SYSTEM": láthatóan hárommal való együttműködésre tervezték
a getsystemben megvalósított egyéb megközelítések. Kiderült, hogy visszatér
privilégiumok, szükséges "ellopni" a folyamat tokent, futó témák felhasználó,
amire szükségünk van. Ezért az összes folyamatot megjelenítjük a ps paranccsal, és kiválasztunk közülük
alkalmas:

mérőmérő > ps
Folyamatlista
============
PID név Arch felhasználói elérési út
--- ---- ---- ---- ----
0
4 System x86 NT AUTHORITY\SYSTEM
370 smss.exe x86 NT AUTHORITY\SYSTEM\SystemRoot\System32\smss.exe
...
1558 explorer.exe x86 WINXPSP3\user C:\WINDOWS\Explorer.EXE
...

Amint látjuk, az explorer.exe csak a szokásos felhasználó alatt indul el
fiók és PID=1560. Most tulajdonképpen "ellophatja a tokent" a használatával
steal_token parancs. A PID egyetlen paraméterként kerül átadásra.
kívánt folyamat:

meterpreter > steal_token 1558
Ellopott token a következő felhasználónévvel: WINXPSP3\user
meterpreter > getuid
Szerver felhasználónév: WINXPSP3\user

A "Szerver felhasználónév" mező alapján a művelet sikeres volt.

Hogyan működik?

Végül érdemes beszélni a megjelenéshez vezető sérülékenység természetéről
sploita. A biztonság megsértése a rendszerkezelő hibája miatt következik be.
#GP megszakít (amit úgy hívnak, hogy nt!KiTrap). Ő miatta kerneljogokkal
tetszőleges kód futtatható. Ez azért történik, mert a rendszer
32 bites x86 platformon bizonyos BIOS-hívásokat hibásan ellenőriz
egy 16 bites alkalmazás fut. A sérülékenység kihasználása érdekében a feltörés létrehozza
16 bites alkalmazás (%windir%\twunk_16.exe), manipulál néhányat
rendszer strukturálja és elindítja az NtVdmControl() függvényt
Windows Virtual DOS Machine (más néven NTVDM alrendszer), amely a korábbiak eredményeként
manipulációk hatására a #GP csapdakezelő meghívódik és
szétválást vált ki. Ez egyébként az egyetlen korlátot jelenti
Egy sploit, amely csak 32 bites rendszereken működik. 64 bites verzióban
operációs rendszerek egyszerűen nem rendelkeznek emulátorral a 16 bites alkalmazások futtatásához.

Miért kerültek nyilvánosan hozzáférhető információk a kész sploittal? Az elérhetőségről
sérülékenység – tájékoztatta a Microsoftot a spoit szerzője tavaly év elején és
sőt megerősítést is kapott, hogy jelentését megfontolásra elfogadták. Csak woz
és most ott. Egy évig nem volt hivatalos javítás a cégtől, és a szerző döntött
tegye közzé az információkat nyilvánosan, remélve, hogy a dolgok gyorsabban mennek majd. Lássuk,
kiadják a patch-et, mire a magazin eladásra kerül :)?

Hogyan védheti meg magát a rontástól

Mivel még nincs teljes körű frissítés a sérülékenység feloldására,
megkerülő megoldásokat kell alkalmaznia. A legmegbízhatóbb lehetőség
tiltsa le az MSDOS és a WOWEXEC alrendszereket, ami azonnal megfosztja a sploittól
funkcionalitás, mert többé nem fogja tudni meghívni az NtVdmControl() függvényt
az NTVDM rendszer elindításához. A Windows régebbi verzióiban ez a következőn keresztül valósul meg
rendszerleíró adatbázis, amelyben megtalálható a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW ág
és adjunk hozzá valamilyen karaktert a nevéhez. Modern operációs rendszerhez
korlátoznia kell a 16 bites alkalmazások indítását
csoportszabályzat. Ehhez hívja a GPEDIT.MSC-t, majd lépjen a szakaszra
„Felhasználói konfiguráció/Felügyeleti sablonok/Windows-összetevők/Kompatibilitás
alkalmazások”, és aktiválja a „16 bites hozzáférés tiltása” opciót
alkalmazások".

www

A sérülékenység leírása a kiterjesztés szerzőjétől:

http://archives.neohapsis.com/archives/fulldisclosure/2010-01/0346.html

Megoldás a probléma megoldására a Microsofttól:

http://support.microsoft.com/kb/979682

FIGYELEM

Az információk oktatási célokat szolgálnak. Használata benne
törvénytelen célok büntetőjogi felelősséget vonhatnak maguk után.

Az egyik projekt részeként egy olyan alkalmazást kellett konfigurálnom, amelynek teljesítenie kellett biztonsági mentés adatbázisok egy távoli MS SQL szerveren egy másik kiszolgálón lévő fájltároláshoz. A távoli tároló eléréséhez egy fiókot használnak, amely alatt az MS SQL fut. Esetünkben az MS SQL helyi fiók alatt futott Hálózati szolgáltatás(NT AUTHORITY\NetworkService). Természetesen ez a helyi fiókot a távoli labdán nincs tekintély. Vége volt az MS SQL-nek, hogy tartományi fiók (vagy) alatt működjön, de konfigurálható távoli hozzáférés a megosztásra és az NT AUTHORITY\NetworkService alatt.

Hogyan engedélyezhető a hozzáférés más számítógépekhez a NetworkService fiók alatt

Ha több számítógéphez kell hozzáférést biztosítania, akkor a legegyszerűbb, ha összevonja őket egy csoportba, és már megadja a hozzáférést a csoportnak. Hozzon létre egy új csoportot az AD-ben, és adja hozzá az összes hozzáférni kívánt számítógépfiókot hálózati erőforrás hálózati szolgáltatási jogokkal. A mappa tulajdonságainál adja meg a szükséges engedélyeket a csoportnak.

Mi a helyzet a többi helyi fiókkal?

Amikor hozzáférést biztosít egy erőforráshoz egy számítógépes fiókon keresztül, az összes többi helyi fiók számára is biztosított hozzáférést? Nem – a hozzáférés csak fiókok számára lesz lehetséges Rendszerés Hálózati szolgáltatás. Minden olyan helyi fióknak, amelynek hozzáférést kell biztosítani egy hálózati megosztáshoz, egyenként kell hozzáférést biztosítani.

Beépített SQL Server 2005 bejelentkezés, BEÉPÍTETT\Adminisztrátorok, , NT AUTHORITY\SYSTEM, sa

Közvetlenül az SQL Server 2005 tárolóba történő telepítése után Bejelentkezések van egy sor bejelentkezés, amely automatikusan jön létre. Valószínűleg nem fogja használni őket a felhasználók összekapcsolására. Vannak azonban olyan helyzetek, amikor jól jöhet a beépített bejelentkezési adatok ismerete (például ha a rendszergazdai bejelentkezést véletlenül blokkolják).

q BEÉPÍTETT\Adminisztrátorok (vagy BEÉPÍTETT\Adminisztrátorok, nyelvtől függően operációs rendszer) - ehhez a Windows-csoporthoz a bejelentkezés automatikusan jogosultságot kap rendszergazda SQL szerver. Kérjük, vegye figyelembe, hogy ha a számítógép egy tartományhoz tartozik, ez a csoport automatikusan tartalmazza a csoportot tartományAdminok(Domain Admins), és így a Domain Admins alapértelmezés szerint rendelkezik teljes joggal SQL Serveren. Ha ez a helyzet nem kívánatos, akkor ez a bejelentkezés törölhető. De még ebben az esetben sem lesz nehéz a domain rendszergazdái számára hozzáférni az SQL Server adataihoz.

q Szerver név 2005MSFTEUser$ Szerver név$példány_neve , Szerver név 2005MSSQLUser$ Szerver név$példány_neve ,Szerver név 2005SQLAgentUser$ Szerver név$példány_neve - Ez a három bejelentkezés a Windows csoportokhoz a megfelelő szolgáltatások SQL Server 2005-höz való csatlakoztatására szolgál. SQL Server 2005 szinten nem kell velük semmilyen műveletet végrehajtani, mivel minden szükséges jogosultság már adott. Ritka esetekben előfordulhat, hogy Windows szinten hozzá kell adnia ezekhez a csoportokhoz azokat a fiókokat, amelyek alatt az SQL Server szolgáltatások futnak.

q NT HATÓSÁG\HÁLÓZATI SZOLGÁLTATÁS - Az ASP .NET-alkalmazások ezzel a fiókkal futnak a Windows Server 2003 rendszerben, beleértve a Reporting Services szolgáltatást is (Windows 2000 esetén a fiókot használják erre a célra). ASPNET). Ezzel a Windows-bejelentkezéssel csatlakozhat az SQL Server Reporting Services szolgáltatáshoz. Automatikusan megkapja a szükséges jogokat az adatbázishoz mőszirózsa, msdbés a Reporting Services által használt adatbázisok.

q NT AUTHORITY\SYSTEM az operációs rendszer helyi rendszerfiókja. Ez a bejelentkezés olyan helyzetekben jelenik meg, amikor az SQL Server szolgáltatást úgy konfigurálta, hogy a telepítés során a helyi rendszerfiók alatt fusson. Elmondhatjuk, hogy ezzel a bejelentkezéssel az SQL Server eléri önmagát. Természetesen ehhez a bejelentkezéshez az SQL Server rendszergazdájának jogai vannak.

q sa (tól től RendszerAdminisztrátor) az egyetlen SQL Server típusú bejelentkezés, amely alapértelmezés szerint jön létre. Rendelkezik az SQL Server rendszergazda jogaival, ezeket a jogokat nem lehet tőle elvenni. Ezt a felhasználónevet sem törölheti. De átnevezhető vagy letiltható. Ha az SQL Server 2005 csak Windows-hitelesítés használatára van beállítva, akkor ez a bejelentkezés nem használható a kiszolgálóhoz való csatlakozáshoz.

NT HATÓSÁGI/RENDSZERHIBA,
XP bejegyzés - hogyan lehet eltávolítani a vírust

Ha van orosz verziója, akkor a letöltés előtt feltétlenül változtassa meg a nyelvet.

Egy kicsit magáról a vírusról:

Tegnap este, körülbelül 23 óra után moszkvai idő szerint, sok fórumon megjelentek a Windows 2000 és a Windows XP furcsa viselkedéséről szóló üzenetek a hálózat elérésekor: a rendszer üzenetet adott ki az RPC szolgáltatás hibájáról és az újraindítás szükségességéről. Az újraindítás után maximum pár perc múlva megismétlődött az üzenet, és nem volt vége.

A vizsgálat kimutatta, hogy az új hálózati féreg, a w32.Blaster.worm ma kezdődött járvány a hibás, amely a Windows összes operációs rendszerében megtalálható RPC DCOM szolgáltatás július 16-án talált sebezhetőségét használja ki. 2000, Windows XP és Windows 2003 családok. Ez a biztonsági rés egy puffertúlcsordulás, amelyet a megtámadott számítógép 135-ös, 139-es vagy 445-ös portjára érkező, megfelelően összeállított TCP/IP-csomag hív meg. Lehetővé teszi legalább a DoS támadást (a DoS jelentése "szolgáltatásmegtagadás", vagy "szolgáltatásmegtagadás", ebben az esetben - a megtámadott számítógép újraindul), és legfeljebb - bármilyen kódot végrehajthat a megtámadott számítógép memóriájában.

Az első dolog, ami már a féreg megjelenése előtt felkeltette a hálózati közvélemény aggodalmát, egy nagyon könnyen használható exploit jelenléte volt (sebezhetőség kihasználására szolgáló program), ami általában olyan helyzethez vezet, hogy ezt a programot bárki használhatja. és kezdje el nem békés célokra használni. De virágok voltak...

Az új féreg terjedésekor a 135-ös portot támadja meg, és ha sikeres, elindítja a TFTP.exe programot, amely letölti a futtatható fájlját a megtámadott számítógépre. Ebben az esetben a felhasználó üzenetet kap az RPC szolgáltatás leállításáról, majd újraindításáról. Az újraindítás után a féreg automatikusan elindul, és elkezdi keresni a számítógépről elérhető hálózatokat a nyitott 135-ös porttal rendelkező számítógépek után. Ha ilyeneket találnak, a féreg támadást hajt végre, és minden megismétlődik az elejétől. Sőt, a terjesztés pillanatnyi üteméből ítélve a féreg hamarosan az élre kerül a vírusirtó cégek listáján.

Három módja van a féreg elleni védekezésnek.

Először is, a Microsoft Bulletin hivatkozásokat ad a Windows összes sérülékeny verziójához tartozó javításokhoz, amelyek bezárják az RPC lyukat (ezek a javítások még július 16-án jelentek meg, így azoknak, akik rendszeresen frissítik a rendszert, nem kell aggódniuk).

Másodszor, ha a 135-ös portot tűzfal zárja le, a féreg nem tud behatolni a számítógépbe.

Harmadszor, a DCOM letiltása végső megoldásként segít (ezt az eljárást részletesen leírja a Microsoft közleménye). Ezért, ha még nem támadta meg egy féreg, erősen ajánlott a lehető leghamarabb letölteni egy javítást az operációs rendszeréhez a Microsoft szerverről (például Windows szolgáltatások Frissítés), vagy konfigurálja a 135-ös, 139-es és 445-ös port blokkolását a tűzfalban.

Ha a számítógép már fertőzött (és az RPC hibaüzenet megjelenése egyértelműen azt jelenti, hogy fertőzött), akkor ki kell kapcsolnia a DCOM-ot (ellenkező esetben minden további támadás újraindítást okoz), majd töltse le és telepítse a javítást.

A féreg megsemmisítéséhez el kell távolítania a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr rendszerleíró kulcsból
entVersion\Futtassa a "windows auto update"="msblast.exe" bejegyzést, majd keresse meg és törölje az msblast.exe fájlt – ez a féreg törzse. A féregeltávolítási eljárásról a Symantec webhelyén olvashat bővebben.

Jelenleg nem minden víruskereső észleli a férget - csak a frissítések megjelenése után lehet védelmet remélni.
Beküldte: AHTOH, 2003-08-17, 23:29:

VESZÉLYES FÉREG! Nt Hatóság/Rendszerhiba

__________________
Jót teszek, jót teszek...