[Active Directory] Vreemd account in de directory

[Trommelrem]

Bij een kennis kwam ik een vreemd account tegen. De naam van het account is een typische virusnaam: het lijkt op "vdfsv58934vjkfd." Dit is niet de echte naam, maar voor het gemak noem ik het account even zo. Deze account is lid van de built-in group Administrators.

Als ik in de built-in account Administrators op "vdfsv58934vjkfd" dubbelklik, dan krijg ik de melding "The following ADDS error occurred: Directory object not found." Dat is logisch, want de OU waar de account in staat bestaat niet. De account zou in domain.local\Admins moeten staan. Echter domain.local\Admins is een object en geen OU (waarvan alleen vdfsv58934vjkfd full control heeft, en niemand anders rechten heeft). Iemand heeft dus in die OU dat account aangemaakt en op een of andere manier de OU weten om te bouwen naar een object zodat de account onvindbaar is. Precies zoals je in een FAT16 filesystem kon doen: Je kon een directory ombouwen naar een bestand door een kenmerk aan te passen, want feitelijk was een directory ook een bestand. De inhoud van de directory was er dan nog, maar je kon de directory niet meer benaderen. De files stonden dan nog wel op de diskette. Dat is ook hier gedaan vermoed ik.

De account is gemaakt ergens in 2003 en de lastlogon is null (of is niet uit te lezen). Met de zoekfunctie vind je de account niet. Logisch, want de account staat niet in een OU.

Ik vind het een heel interessant probleem en ik vermoed dus dat iemand ooit een backdoor heeft gemaakt (oude beheerder?). Ik beheer de server niet, dus ik mag er niets aan veranderen. Ik heb de kennis wel kunnen overhalen om de auditing van logons in te schakelen zodat als het account zou worden gebruikt, dat we dat dan konden zien.

Men is nu bezig met de procedure om mij tijdelijk beheerrechten te geven zodat ik hiernaar onderzoek kan gaan doen. Echter ik doe het in mijn vrije tijd en ik verdien er dus niets aan, dus ik wil er niet al te veel tijd aan besteden. Toch vind ik het wel erg interessant en wil ik er graag even naar kijken.

Wat denken jullie? Is dit een backdoor? Ik kan mij niet voorstellen dat iemand "per ongeluk" de account heeft gemaakt of dat een applicatie een vreemd account voor een service heeft aangemaakt en vervolgens de OU ombouwt naar een object. Welk kenmerk in ADSI zou ik kunnen omzetten om het object terug te bouwen naar een OU?

[Hero of Time]

Is het object niet gewoon een container? Neem ownership van de container, zet de rechten weer goed zoals die op de andere containers staat en reset het wachtwoord van het account, of schakel 't uit. Wijzigen is iig beter, met audit logging, want dan zie je iig pogingen (die mislukken, dus eventuele acties zijn niet meer mogelijk). Zorg ook dat de oorspronkelijke beheerder(s) de wachtwoorden direct wijzigen. Wie weet wat er nog meer aan backdoors in zitten, als het ook echt een probleem is.

[Trommelrem]

Nope. Het is geen container. Het is echt een object die zich ook gedraagt als object.
Iemand of iets moet het bewust hebben omgebouwd terwijl de inhoud er nog in zat.
Ik heb nog geen beheerrechten, dus ik kan nog iets veranderen.

Het account disablen heeft denk ik niet zo veel zin meer. Als het account al sinds 2003 bestaat dan zal een paar dagen extra open laten staan al iets minder erg zijn want de grootste schade zal dan al zijn aangericht. Dan wil ik liever monitoren wat er met dat account gebeurt en dat als bewijsmateriaal aanleveren. Althans, dat is wat ik zal voorstellen, maar het hangt af van wat de organisatie zelf wilt. Zou je dat ook adviseren?

[Hero of Time]

Dat is geen gek idee eigenlijk. Had ik nog niet aan gedacht.

[Brahiewahiewa]

D'r kan in 11 jaar natuurlijk een hoop gebeuren.
Bijvoorbeeld iemand die met ADSIedit heeft zitten spelen, perongeluk rechtsklik heeft gedaan en toen op allerlei knoppen heeft zitten drukken om uit het "create new object" dialoogje te komen (ik verbaas me nergens meer over)

OTOH, als het daadwerkelijk iets met malware te maken heeft, is die aanmaakdatum natuurlijk ook niet betrouwbaar; althans als ik malware zou schrijven, zou'k ook de suggestie willen wekken dat het er al meer dan tien jaar inzit. Heb je overigens enig idee hoe oud de AD in kwestie is?

En ik zou de account gewoon weghalen; veilig welteverstaan. Dus eerst even een export doen zodat je 'm in geval van nood nog terug kunt zetten

[T0ny]

Het zou evt ook een automatisch aangemaakt service account kunnen zijn van een of ander software pakket.
Desnoods even kijken naar de creation date en dat vergelijken met geïnstalleerde software oid.