امنیت

بررسی کاربران Administrator مخفی در ویندوز

بررسی کاربران Administrator مخفی در ویندوز

مقدمه

حساب‌های دارای دسترسی Administrator یکی از مهم‌ترین نقاط امنیتی در Windows Server هستند.

اگر مهاجم بتواند روی یک سرور دسترسی Administrator به دست آورد، یکی از روش‌های حفظ دسترسی می‌تواند ایجاد یک User جدید یا اضافه کردن یک Account موجود به گروه Administrators باشد.

این Account الزاماً نام مشکوکی مانند hacker ندارد و ممکن است با نام‌هایی شبیه حساب‌های عادی یا سیستمی ایجاد شود:

Support
BackupAdmin
ServiceAdmin
SQLAdmin
HelpDesk
UpdateService
SysAdmin

حتی ممکن است Account در صفحه Sign-in نمایش داده نشود، اما همچنان روی سیستم وجود داشته و دارای دسترسی مدیریتی باشد.

به همین دلیل برای بررسی Administratorهای یک Windows Server نباید فقط به صفحه Login نگاه کنیم.

در این مقاله با استفاده از PowerShell، CMD، Computer Management و Windows Security Logs کاربران Local، اعضای گروه Administrators، حساب Built-in Administrator، Sessionهای فعال و تغییرات مشکوک مربوط به Userها را بررسی می‌کنیم.

این مقاله عمدتاً برای Windows Serverهای Standalone و Member Server نوشته شده است. در Domain Controllerها مدیریت Accountها متفاوت است و باید کاربران و Groupهای Active Directory نیز بررسی شوند.

منظور از Administrator مخفی چیست؟

عبارت:

Hidden Administrator

یک نوع رسمی Account در Windows نیست.

معمولاً منظور یکی از این حالت‌ها است:

User موجود روی سیستم
+
عضویت در Administrators
+
ناشناخته بودن برای مدیر سرور

یا:

User فعال
+
مخفی بودن از Sign-in Screen

یا:

Domain User / Group
+
عضویت در Local Administrators
+
عدم وجود در مستندات سازمان

بنابراین هدف اصلی ما پیدا کردن Administratorهای ناشناخته یا غیرمنتظره است.

اولین مرحله: مشاهده تمام Local Userها

PowerShell را با:

Run as Administrator

اجرا کنید.

سپس:

Get-LocalUser

را وارد کنید.

Get-LocalUser تمام Local Accountهای سیستم، شامل Accountهای Built-in و Userهای ایجادشده را نمایش می‌دهد.

نمونه:

Name                Enabled    Description
----                -------    -----------
Administrator       False
DefaultAccount      False
Guest               False
WDAGUtilityAccount  False
SupportAdmin        True
BackupUser          True

اکنون باید مشخص شود Userهایی مانند:

SupportAdmin
BackupUser

واقعاً باید روی Server وجود داشته باشند یا خیر.

نمایش اطلاعات بیشتر کاربران

برای مشاهده جزئیات:

Get-LocalUser | Format-List *

اما خروجی آن نسبتاً طولانی است.

برای Security Audit می‌توانیم فقط اطلاعات مهم را نمایش دهیم:

Get-LocalUser |
Select-Object Name,Enabled,LastLogon,PasswordLastSet,SID,Description

برای هر User موارد زیر را بررسی کنید:

Name
Enabled
LastLogon
PasswordLastSet
SID
Description

فقط Userهای فعال را نمایش دهیم

برای مشاهده Accountهایی که در حال حاضر Enabled هستند:

Get-LocalUser |
Where-Object {$_.Enabled -eq $true}

در Server Production معمولاً باید بتوانید دلیل وجود تمام Accountهای فعال را توضیح دهید.

اگر Account فعالی مشاهده کردید که Owner یا کاربرد آن مشخص نیست، باید بررسی شود.

مشاهده Userها با CMD

اگر Get-LocalUser در دسترس نبود، روش قدیمی‌تر CMD نیز قابل استفاده است:

net user

نمونه:

Administrator
BackupAdmin
DefaultAccount
Guest
Support

برای مشاهده اطلاعات یک Account:

net user BackupAdmin

اطلاعاتی مانند:

Account active
Password last set
Last logon
Local Group Memberships

نمایش داده می‌شوند.

مهم‌ترین مرحله: چه کسانی Administrator هستند؟

داشتن Local User لزوماً خطرناک نیست.

مهم‌تر این است که ببینیم چه User یا Groupهایی عضو گروه:

Administrators

هستند.

اجرا کنید:

Get-LocalGroupMember -Group "Administrators"

این Cmdlet به‌طور مستقیم اعضای Local Group موردنظر را نمایش می‌دهد.

نمونه:

ObjectClass   Name                      PrincipalSource
-----------   ----                      ---------------
User          SERVER01\Administrator    Local
User          SERVER01\SupportAdmin     Local
Group         DOMAIN\Domain Admins      ActiveDirectory
User          DOMAIN\Kian               ActiveDirectory

چه چیزهایی را در Administrators بررسی کنیم؟

هر مورد موجود در این لیست باید دلیل مشخصی داشته باشد.

به‌خصوص:

  • Local User ناشناس
  • Account قدیمی
  • Test User
  • Service Account
  • Domain User غیرمنتظره
  • Domain Group ناشناس
  • Account مربوط به کارمند سابق

باید بررسی شوند.

گروه Administrators یکی از High-value Groupهای سیستم است و تغییر Membership آن اهمیت امنیتی زیادی دارد. Microsoft نیز مانیتور کردن تغییر اعضای گروه‌های حساسی مانند Administrators را توصیه می‌کند.

مشاهده Administrators با CMD

روش ساده‌تر:

net localgroup administrators

نمونه:

Alias name     administrators

Members
---------------------------------------------------
Administrator
SupportAdmin
DOMAIN\Domain Admins
DOMAIN\ServerAdmins

اگر نامی را نمی‌شناسید، صرفاً آن را حذف نکنید؛ ابتدا مشخص کنید متعلق به چه سرویس یا تیمی است.

تفاوت Local Administrator و Domain Administrator

در Server عضو Domain ممکن است گروه Local Administrators شامل موارد زیر باشد:

SERVER01\Administrator
DOMAIN\Domain Admins
DOMAIN\ServerAdmins
DOMAIN\UserName

مورد اول Local Account است.

مواردی که با:

DOMAIN\

شروع می‌شوند از Active Directory آمده‌اند.

بنابراین ممکن است هیچ Local User مشکوکی وجود نداشته باشد اما یک Domain Account غیرمجاز دارای Local Administrator Access باشد.

مشاهده Source هر Administrator

با PowerShell:

Get-LocalGroupMember Administrators |
Select-Object Name,ObjectClass,PrincipalSource

خروجی می‌تواند مشخص کند Principal از کجا آمده است:

Local
ActiveDirectory
MicrosoftEntra

بنابراین فقط Username را بررسی نکنید؛ منبع Account نیز اهمیت دارد.

پیدا کردن Built-in Administrator

Windows دارای یک Built-in Administrator Account است.

برای مشاهده:

Get-LocalUser -Name Administrator

اما یک مشکل وجود دارد:

Administrator می‌تواند Rename شده باشد.

در این حالت جستجو براساس اسم کافی نیست.

شناسایی Administrator حتی بعد از Rename

Built-in Administrator معمولاً با RID:

500

قابل شناسایی است.

SID آن معمولاً به شکل زیر پایان می‌یابد:

-500

مثلاً:

S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-500

Microsoft نیز در مستندات Get-LocalUser حساب داخلی Administrator را با SID انتهایی -500 نشان می‌دهد.

برای پیدا کردن آن:

Get-LocalUser |
Where-Object {
    $_.SID.Value -match '-500$'
}

حتی اگر Administrator Rename شده باشد، از این طریق قابل شناسایی است.

وضعیت Built-in Administrator را بررسی کنیم

اجرا کنید:

Get-LocalUser |
Where-Object {$_.SID.Value -match '-500$'} |
Select-Object Name,Enabled,SID,LastLogon

مثلاً:

Name        Enabled   SID                  LastLogon
----        -------   ---                  ---------
SrvAdmin    False     S-1-5-21-...-500

اگر طبق Policy سازمان این Account باید Disabled باشد ولی مشاهده کردید:

Enabled = True

باید علت آن بررسی شود.

آیا Disable بودن یعنی Account بی‌خطر است؟

خیر.

Account غیرفعال در حال حاضر نمی‌تواند Login معمولی انجام دهد، اما وجود یک User ناشناس همچنان باید بررسی شود.

برای نمایش Disabled Accountها:

Get-LocalUser |
Where-Object {$_.Enabled -eq $false}

ممکن است یک Account در زمان نفوذ ایجاد و سپس Disable شده باشد تا بعداً دوباره فعال شود.

بررسی Accountهایی که در Login Screen دیده نمی‌شوند

یکی از اشتباهات متداول این است که تصور کنیم Userهایی که در صفحه Sign-in مشاهده نمی‌شوند، روی سیستم وجود ندارند.

Source of Truth برای Local Accountها ابزارهایی مانند:

Get-LocalUser

و:

net user

هستند.

نه صفحه Login.

بنابراین اولین اصل این است:

Login Screen ≠ Full User Inventory

بررسی Registry مربوط به Userهای مخفی

در بعضی سیستم‌ها ممکن است Registry زیر برای کنترل نمایش Accountها در صفحه Sign-in وجود داشته باشد:

HKEY_LOCAL_MACHINE
\SOFTWARE
\Microsoft
\Windows NT
\CurrentVersion
\Winlogon
\SpecialAccounts
\UserList

برای بررسی Read-only آن:

$Path = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList"

if (Test-Path $Path) {
    Get-ItemProperty $Path
}

اگر Username ناشناخته‌ای در این قسمت مشاهده شود، همان Account را با:

Get-LocalUser

و:

Get-LocalGroupMember Administrators

بررسی کنید.

مخفی شدن از رابط Sign-in به معنی Disable شدن Account نیست.

بررسی SID تمام کاربران

برای مشاهده SIDها:

Get-LocalUser |
Select-Object Name,Enabled,SID

SID اهمیت زیادی دارد زیرا Username می‌تواند Rename شود.

برای مثال:

Name          SID
----          ---
Administrator S-1-5-21-...-500
Guest         S-1-5-21-...-501
SupportAdmin  S-1-5-21-...-1005

در Incident Response بهتر است علاوه بر Username، SID نیز ثبت شود.

بررسی کاربران از طریق Computer Management

روش گرافیکی نیز وجود دارد.

اجرا کنید:

compmgmt.msc

سپس:

Computer Management
       |
       └── Local Users and Groups
              |
              ├── Users
              └── Groups

ابتدا:

Users

را بررسی کنید.

سپس وارد:

Groups

شوید و:

Administrators

را باز کنید.

تمام Members باید مشخص و مستند باشند.

استفاده از lusrmgr.msc

روی نسخه‌های Windows Server که Local Users and Groups را ارائه می‌کنند:

lusrmgr.msc

را اجرا کنید.

در:

Users

تمام Local Userها و در:

Groups → Administrators

تمام Administratorها را مشاهده خواهید کرد.

از کجا بفهمیم چه زمانی User ساخته شده است؟

Windows Security Log در این قسمت بسیار مهم است.

یکی از Event IDهای مهم:

4720

است.

این Event مربوط به:

A user account was created

است. Microsoft آن را یکی از Eventهای Audit User Account Management معرفی می‌کند.

برای جستجو:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4720
}

مشاهده آخرین Userهای ایجادشده

برای آخرین 20 Event:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4720
} -MaxEvents 20 |
Select-Object TimeCreated,Id,Message

داخل Message معمولاً می‌توان اطلاعات مربوط به:

  • Account ایجادشده
  • SID
  • Account ایجادکننده
  • Domain

را بررسی کرد.

چه Eventهای دیگری برای User Management مهم هستند؟

در Audit User Account Management، Eventهای مهم شامل موارد زیر هستند:

4720 = User created
4722 = User enabled
4725 = User disabled
4726 = User deleted
4738 = User changed

بنابراین اگر Account مشکوکی پیدا کردید، فقط 4720 را بررسی نکنید.

ممکن است Account قبلاً ساخته شده باشد اما اخیراً:

Enable
Rename
Modify

شده باشد.

بررسی Event ID 4732

یکی از مهم‌ترین Eventها:

4732

است.

این Event زمانی ثبت می‌شود که Member جدیدی به یک Security-enabled Local Group اضافه شود.

برای بررسی:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4732
} -MaxEvents 50 |
Select-Object TimeCreated,Message

اگر Group موردنظر:

Administrators

باشد، این Event اهمیت بالایی دارد.

چرا Event 4732 مهم‌تر از وجود User است؟

ممکن است یک User عادی سال‌ها روی Server وجود داشته باشد.

اما مهاجم امروز همان Account را به Administrators اضافه کرده باشد.

در این حالت:

User Creation

جدید نیست.

اما:

Privilege Change

جدید است.

بنابراین Timeline صحیح باید هر دو را بررسی کند:

4720
+
4732

بررسی Loginهای Account مشکوک

اگر Username مشکوکی پیدا کردید، باید بررسی کنید آیا استفاده شده است.

Event ID:

4624

نشان‌دهنده Successful Logon است و روی سیستمی ثبت می‌شود که Logon Session روی آن ایجاد شده است.

برای مشاهده:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4624
} -MaxEvents 200

جستجو برای یک Username خاص

برای مثال:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4624
} |
Where-Object {
    $_.Message -match "SupportAdmin"
}

اکنون می‌توان زمان‌های Login مربوط به Account را بررسی کرد.

Logon Type را بررسی کنیم

داخل Event 4624 یکی از اطلاعات مهم:

Logon Type

است.

نوع Logon می‌تواند مشخص کند Session از چه نوعی بوده است.

برای مثال:

Interactive
Network
Batch
Service
RemoteInteractive

Microsoft توصیه می‌کند Logon مربوط به Accountهای باارزش و Accountهایی که نباید استفاده شوند، مانیتور شود.

بررسی Sessionهای RDP فعلی

برای مشاهده Userهایی که در حال حاضر Session دارند:

quser

یا:

query user

نمونه:

USERNAME        SESSIONNAME     ID    STATE
Administrator   rdp-tcp#12      2     Active
SupportAdmin    rdp-tcp#15      3     Disc

حتی Session با وضعیت:

Disc

نیز باید بررسی شود.

مشاهده تمام Sessionها

همچنین:

qwinsta

را اجرا کنید.

این ابزار وضعیت Sessionهای Remote Desktop Services را نمایش می‌دهد.

برای Historical Investigation اما همچنان باید Security Event Log بررسی شود.

بررسی Serviceهایی که با User اجرا می‌شوند

گاهی یک Account به ظاهر ناشناس در واقع Service Account است.

برای مشاهده Serviceها و Account مربوط به آنها:

Get-CimInstance Win32_Service |
Select-Object Name,StartName,State,PathName

به ستون:

StartName

توجه کنید.

مثلاً:

.\BackupAdmin
DOMAIN\ServiceSQL
LocalSystem
NT AUTHORITY\NetworkService

اگر Account مشکوک Service اجرا می‌کند، قبل از Disable کردن آن باید Dependency بررسی شود.

بررسی Scheduled Taskها

Account ممکن است برای اجرای Scheduled Task استفاده شود.

اجرا کنید:

Get-ScheduledTask

برای جستجوی User مشخص:

Get-ScheduledTask |
Where-Object {
    $_.Principal.UserId -match "SupportAdmin"
}

اگر Account ناشناخته هم Administrator باشد و هم Scheduled Task اجرا کند، موضوع اهمیت بیشتری پیدا می‌کند.

بررسی Profileهای کاربران

وجود Profile می‌تواند سرنخ دیگری باشد.

اجرا کنید:

Get-CimInstance Win32_UserProfile |
Select-Object LocalPath,SID,Loaded,LastUseTime

نمونه:

C:\Users\Administrator
C:\Users\SupportAdmin
C:\Users\BackupUser

اگر Profile مربوط به User حذف‌شده یا ناشناس پیدا کردید، SID و LastUseTime را بررسی کنید.

بررسی C:\Users

روش ساده‌تر:

Get-ChildItem C:\Users

سپس نتیجه را با:

Get-LocalUser

مقایسه کنید.

وجود یک Profile به‌تنهایی اثبات نمی‌کند Account هنوز فعال است، اما برای Timeline مفید است.

بررسی Auto Logon

در Server Production بهتر است Auto Logon دلیل مشخصی داشته باشد.

برای بررسی تنظیمات Winlogon:

Get-ItemProperty `
"HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" |
Select-Object AutoAdminLogon,DefaultUserName,DefaultDomainName

اگر:

AutoAdminLogon = 1

است، باید مشخص شود چرا Server به شکل خودکار Login می‌کند و با چه Accountی.

بررسی Audit Policy

اگر Eventهایی مانند:

4720
4732
4624

وجود ندارند، ممکن است Audit Policy مناسب فعال نبوده باشد.

برای مشاهده:

auditpol /get /category:*

بخش‌های مهم عبارت‌اند از:

Account Management
Logon/Logoff
Account Logon

Microsoft، Advanced Audit Policy مربوط به Account Management را برای ردیابی ایجاد، تغییر، Enable، Disable و حذف Userها ضروری می‌داند.

یک Workflow عملی برای Audit Administratorها

برای بررسی سریع یک Server، مراحل زیر را اجرا کنید.

مرحله اول: تمام Local Userها

Get-LocalUser |
Select Name,Enabled,LastLogon,PasswordLastSet,SID

مرحله دوم: Administratorها

Get-LocalGroupMember Administrators |
Select Name,ObjectClass,PrincipalSource

مرحله سوم: Built-in Administrator

Get-LocalUser |
Where-Object {$_.SID.Value -match '-500$'}

مرحله چهارم: بررسی Login UI Registry

$Path = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList"

if (Test-Path $Path) {
    Get-ItemProperty $Path
}

مرحله پنجم: User Creation

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4720
} -MaxEvents 50

مرحله ششم: Local Group Changes

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4732
} -MaxEvents 50

مرحله هفتم: Sessionهای فعلی

quser

مرحله هشتم: Serviceها

Get-CimInstance Win32_Service |
Select Name,StartName,State

مرحله نهم: Scheduled Taskها

Get-ScheduledTask |
Select TaskName,TaskPath,@{N='RunAs';E={$_.Principal.UserId}}

یک دستور PowerShell برای Audit اولیه

می‌توان اطلاعات اصلی را پشت سر هم نمایش داد:

Write-Host "`n=== LOCAL USERS ==="
Get-LocalUser |
Select Name,Enabled,LastLogon,SID

Write-Host "`n=== LOCAL ADMINISTRATORS ==="
Get-LocalGroupMember Administrators |
Select Name,ObjectClass,PrincipalSource

Write-Host "`n=== BUILT-IN ADMINISTRATOR ==="
Get-LocalUser |
Where-Object {$_.SID.Value -match '-500$'} |
Select Name,Enabled,LastLogon,SID

این اسکریپت هیچ تغییری روی Server ایجاد نمی‌کند و برای بررسی اولیه مناسب است.

چه Accountهایی مشکوک‌تر هستند؟

موارد زیر نیازمند بررسی بیشتری هستند:

  • Administrator ناشناخته
  • User تازه ایجادشده
  • User با نام شبیه Account سیستمی
  • Local Admin بدون Owner مشخص
  • Domain User ناشناس داخل Administrators
  • Account مربوط به کارمند سابق
  • Account فعال با LastLogon غیرمنتظره
  • Account Disabled ناشناخته
  • Built-in Administrator که بدون دلیل Enable شده
  • Account مورد استفاده در Scheduled Task ناشناس
  • Account مورد استفاده توسط Service غیرمعمول

آیا User با نام عجیب حتماً مخرب است؟

خیر.

ممکن است نرم‌افزار یا تیم IT Account خاصی ساخته باشد.

برای مثال:

BackupAdmin
MonitoringUser
ServiceDeploy

می‌توانند کاملاً قانونی باشند.

سؤال اصلی این است:

آیا برای این Account یک Owner، Purpose و Documentation مشخص وجود دارد؟

Account ناشناخته مهم‌تر از Account با نام عجیب است.

Administratorهای مجاز را Baseline کنید

بهتر است برای هر Server فهرست Administratorهای مجاز مشخص باشد.

برای مثال:

SERVER01\Administrator
DOMAIN\Domain Admins
DOMAIN\ServerOps

می‌توانید وضعیت فعلی را Export کنید:

Get-LocalGroupMember Administrators |
Select Name,ObjectClass,PrincipalSource |
Export-Csv C:\AdminBaseline.csv -NoTypeInformation

در بررسی‌های بعدی تغییرات بسیار سریع‌تر مشخص می‌شوند.

Windows LAPS چیست؟

برای مدیریت امن Local Administrator Password بهتر است از Windows LAPS استفاده شود.

Windows LAPS می‌تواند Password مربوط به Local Administrator را به‌صورت دوره‌ای مدیریت و Rotate کند و آن را در Active Directory یا Microsoft Entra ID پشتیبان‌گیری کند.

این روش خطر استفاده از یک Password مشترک روی چند Server را کاهش می‌دهد.

Windows LAPS روی Windows Server 2019، 2022 و 2025 پشتیبانی می‌شود.

Account مشکوک پیدا کردیم؛ چه کنیم؟

Account را فوراً حذف نکنید.

ابتدا Evidence جمع‌آوری کنید.

برای مثال:

Get-LocalUser -Name "SupportAdmin" |
Format-List *

بررسی Administrator Membership:

Get-LocalGroupMember Administrators |
Where-Object {
    $_.Name -match "SupportAdmin"
}

سپس Eventهای:

4720
4722
4732
4624

را بررسی کنید.

Disable کردن Account مشکوک

اگر بعد از بررسی مشخص شد Account نباید فعال باشد و Incident Response Policy اجازه می‌دهد:

Disable-LocalUser -Name "SupportAdmin"

Disable کردن معمولاً برای Containment اولیه قابل کنترل‌تر از حذف فوری Account است.

قبل از انجام این کار مطمئن شوید Account متعلق به Service حیاتی نیست.

حذف Administrator Access

اگر خود User قانونی است اما Administrator Membership نباید وجود داشته باشد:

Remove-LocalGroupMember `
-Group "Administrators" `
-Member "SupportAdmin"

باز هم Dependencyها باید قبل از تغییر بررسی شوند.

حذف User

اگر Investigation تأیید کرد Account غیرمجاز است:

Remove-LocalUser -Name "SupportAdmin"

اما در Incident امنیتی بهتر است این مرحله بعد از حفظ Evidence انجام شود.

بعد از پیدا کردن Administrator غیرمجاز چه کنیم؟

صرف حذف Account کافی نیست.

باید مشخص شود:

  • چه کسی User را ساخته است؟
  • چگونه دسترسی Administrator به دست آمده؟
  • Account چه زمانی ایجاد شده؟
  • چه زمانی به Administrators اضافه شده؟
  • از چه زمانی Login داشته است؟
  • آیا RDP استفاده کرده؟
  • Service ساخته است؟
  • Scheduled Task ایجاد کرده است؟
  • Account دیگری ایجاد کرده است؟
  • Credentialهای دیگری در معرض خطر هستند؟

هدف نهایی پیدا کردن:

Root Cause

است.

اشتباهات رایج

برخی اشتباهات رایج هنگام بررسی Administratorها عبارت‌اند از:

  • بررسی فقط صفحه Login
  • بررسی نکردن گروه Administrators
  • جستجو فقط برای Account با نام Administrator
  • نادیده گرفتن RID 500
  • بررسی نکردن Domain User و Group
  • حذف فوری Account قبل از بررسی Logها
  • نادیده گرفتن Disabled Userها
  • بررسی نکردن Scheduled Taskها
  • بررسی نکردن Service Accountها
  • توجه نکردن به Event ID 4720
  • نادیده گرفتن Event ID 4732
  • بررسی نکردن Successful Logonها
  • نداشتن Baseline از Administratorهای مجاز

بهترین روش‌ها

برای مدیریت امن Administrator Accountها:

  • Administrators Group را دوره‌ای Audit کنید.
  • Local Userهای غیرضروری را Disable یا حذف کنید.
  • Least Privilege را رعایت کنید.
  • تغییر Membership گروه Administrators را مانیتور کنید.
  • Eventهای User Management را به SIEM ارسال کنید.
  • Built-in Administrator را طبق Policy سازمان مدیریت کنید.
  • از Windows LAPS استفاده کنید.
  • Password مشترک Local Administrator روی چند Server استفاده نکنید.
  • Accountهای Service را مستندسازی کنید.
  • Domain Groupهای دارای Local Admin Access را محدود کنید.
  • Administrator Baseline داشته باشید.
  • Accountهای قدیمی را به‌صورت دوره‌ای Review کنید.

چک‌لیست

برای بررسی Administratorهای مخفی یا ناشناخته موارد زیر را کنترل کنید:

  • تمام Local Userها بررسی شده‌اند.
  • Userهای Enabled مشخص شده‌اند.
  • Disabled Accountها بررسی شده‌اند.
  • تمام Local Administratorها استخراج شده‌اند.
  • Domain Userهای داخل Administrators بررسی شده‌اند.
  • Domain Groupهای Administrators بررسی شده‌اند.
  • Built-in Administrator با RID 500 پیدا شده است.
  • وضعیت Enabled بودن Built-in Administrator بررسی شده است.
  • Registry مربوط به Userهای مخفی بررسی شده است.
  • Event ID 4720 بررسی شده است.
  • Event ID 4722 بررسی شده است.
  • Event ID 4732 بررسی شده است.
  • Event ID 4624 برای Accountهای مشکوک بررسی شده است.
  • RDP Sessionهای فعلی بررسی شده‌اند.
  • Service Accountها بررسی شده‌اند.
  • Scheduled Taskها بررسی شده‌اند.
  • User Profileها بررسی شده‌اند.
  • Audit Policy بررسی شده است.
  • Administratorهای مجاز مستندسازی شده‌اند.
  • Windows LAPS در صورت امکان پیاده‌سازی شده است.

مطالعات بیشتر

برای مطالعه بیشتر می‌توانید از مستندات رسمی Microsoft استفاده کنید:

جمع‌بندی

برای پیدا کردن Administratorهای مخفی یا ناشناخته در Windows Server نباید فقط صفحه Login را بررسی کنیم.

اولین مرحله مشاهده تمام Local Userها است:

Get-LocalUser

سپس باید مشخص کنیم چه User یا Groupهایی واقعاً Administrative Access دارند:

Get-LocalGroupMember Administrators

در Serverهای Domain Joined توجه به:

Domain User
Domain Group

نیز اهمیت دارد، زیرا Administrator Access الزاماً از طریق یک Local Account ایجاد نمی‌شود.

Built-in Administrator را نیز بهتر است براساس RID:

500

شناسایی کنیم تا Rename شدن Username باعث مخفی ماندن آن نشود:

Get-LocalUser |
Where-Object {$_.SID.Value -match '-500$'}

بعد از پیدا کردن Account غیرمنتظره، Security Event Log باید بررسی شود. Event:

4720

می‌تواند ایجاد User را نشان دهد و Event:

4732

برای بررسی اضافه شدن Member به Local Security Group اهمیت دارد.

Event:

4624

نیز کمک می‌کند مشخص شود Account موردنظر چه زمانی واقعاً Login کرده است.

در نهایت معیار اصلی این نیست که Username عجیب باشد یا Account در Login Screen دیده نشود. هر Account دارای Administrator Access باید Owner، Purpose و دلیل مشخصی برای وجود روی Server داشته باشد.

اگر Administratorی پیدا شود که هیچ تیم یا شخصی مسئولیت آن را قبول نمی‌کند، همان Account باید به‌عنوان یک مورد امنیتی بررسی شود.

برای مدیریت بلندمدت نیز بهتر است Administratorهای مجاز Baseline شوند، تغییر Membership گروه Administrators مانیتور شود و Password حساب‌های Local Administrator با Windows LAPS مدیریت شود.

کیان پور

نظرات خود را بنویسید...

اشتراک گذاری این مقاله

بررسی کاربران Administrator مخفی در ویندوز

کپی کردن لینک

سلام