سرقة جلسات الذكاء الاصطناعي كيف تتحول سجلات Infostealer إلى مفاتيح تتجاوز MFA

لم يعد اختراق حسابات الذكاء الاصطناعي يتطلب دائمًا معرفة كلمة المرور، أو كسر آلية المصادقة متعددة العوامل، أو حتى خداع المستخدم لتسجيل الدخول في صفحة مزيفة. في بعض الحالات، يكفي أن يحصل المهاجم على السر الذي يُمنح بعد نجاح عملية تسجيل الدخول أصلًا.

هذا هو الخطر الذي تكشفه بيانات سرقتها برمجيات من فئة Infostealer: رموز جلسات، مفاتيح API، وهياكل مصادقة قابلة لإعادة الاستخدام قد تمنح المهاجم وصولًا مباشرًا إلى خدمات الذكاء الاصطناعي وكأنه المستخدم الشرعي، دون المرور مجددًا عبر كلمة المرور أو MFA.

النتيجة ليست مجرد استيلاء على حساب. في بيئات المؤسسات، يمكن أن يمتد الأثر إلى استهلاك موارد مدفوعة، الوصول إلى نماذج متقدمة، إساءة استخدام البنية السحابية، كشف معلومات شخصية، وتحويل حسابات الذكاء الاصطناعي نفسها إلى أصل قابل للبيع داخل أسواق الجريمة الإلكترونية.

#عندما تصبح جلسة تسجيل الدخول هي الهدف

برمجيات سرقة المعلومات مثل Lumma Stealer وVidar مصممة لجمع نطاق واسع من البيانات من الأجهزة المصابة، بما في ذلك بيانات الاعتماد، رموز الجلسات، ومفاتيح API.

بعد سرقة هذه البيانات، لا ينتهي دورها عند المهاجم الذي أصاب الجهاز. غالبًا ما تُجمع في ما يعرف باسم Stealer Logs ثم تُباع أو تُتداول في المنتديات والقنوات الإجرامية، بحيث يستطيع مهاجم آخر استخدامها في هجمات لاحقة.

القيمة الأساسية هنا أن بعض الأسرار المسروقة لا تمثل مجرد بيانات تساعد على تسجيل الدخول، بل تمثل إثباتًا قائمًا بالفعل على أن عملية تسجيل الدخول قد نجحت سابقًا.

ولهذا تصبح عناصر مثل:

Session Token

JWT

JWE

API Key

أكثر خطورة في بعض السيناريوهات من كلمة المرور نفسها.

فإذا كان الرمز ما يزال صالحًا ويمكن إعادة استخدامه، يستطيع المهاجم تنفيذ Session Replay والوصول إلى الخدمة دون إعادة المرور بعملية المصادقة التقليدية.

#7 جيجابايت من السجلات تكشف حجم المشكلة

حللت Okta ملفًا بحجم 7 جيجابايت من بيانات Infostealer نُشر على قناة في Telegram بتاريخ 2 أغسطس 2026.

البيانات احتوت على معلومات تعود إلى:

• 5,871 جهازًا مصابًا.
• 162 دولة.
• آلاف رموز المصادقة غير المنتهية المرتبطة بخدمات تقنية وذكاء اصطناعي متعددة.

وشملت الخدمات التي ظهرت في البيانات أسماء مثل Google وMicrosoft وAnthropic وAmazon وGamma وNotion وCharacter.ai وCursor وPoe.com وPika AI.

ومن أصل 44,791 رمزًا فريدًا من نوع JWT، حدد التحليل 555 رمزًا يُرجح ارتباطها بالمصادقة في خدمات الذكاء الاصطناعي.

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

#لماذا قد يتجاوز الرمز المسروق MFA؟

المصادقة متعددة العوامل MFA تحمي مرحلة تسجيل الدخول. لكن المشكلة تبدأ عندما ينجح المستخدم في تسجيل الدخول وتصدر الخدمة رمزًا يمثل الجلسة الموثقة.

إذا سرق المهاجم هذا الرمز وهو لا يزال صالحًا، فقد لا يحتاج إلى:

• اسم المستخدم.
• كلمة المرور.
• رمز التحقق.
• تنفيذ تحدٍ جديد للمصادقة.

بدلًا من ذلك، يعيد استخدام الجلسة نفسها.

بصيغة مبسطة:

User authenticates
        ↓
Service issues a valid session token
        ↓
Infostealer steals the token
        ↓
Attacker replays the token
        ↓
Service may treat the attacker as the authenticated user

لهذا لا تعني قوة كلمة المرور أو وجود MFA أن الحساب محصن من سرقة الجلسة.

المشكلة هنا ليست فشل المصادقة، بل سرقة الدليل الناتج عن المصادقة الناجحة.

#JWT: الرمز الذي قد يتحول إلى جلسة مسروقة

JWT أو JSON Web Token يُستخدم على نطاق واسع لنقل معلومات مرتبطة بالمصادقة أو التفويض.

عندما يكون الرمز صالحًا ولم تنتهِ صلاحيته، قد يتمكن من يسيطر عليه من استخدامه للوصول إلى الحساب أو الخدمة مباشرة وفق طريقة تنفيذ النظام.

وفي البيانات التي حللتها Okta، ظهر ما مجموعه:

44,791 unique JWTs

وكان:

555 JWTs

منها على الأرجح مرتبطًا بخدمات ذكاء اصطناعي.

لكن المشكلة لم تتوقف عند إمكانية إعادة الاستخدام.

وجد التحليل أيضًا أن:

17.7%

من إجمالي رموز JWT احتوت على معلومات تعريف شخصية PII بنص واضح، مثل الاسم أو رقم الهاتف أو عنوان البريد الإلكتروني.

وهذا يخلق طبقة ثانية من المخاطر. فحتى بعد انتهاء صلاحية الرمز، قد تظل البيانات الشخصية المستخرجة منه صالحة للاستخدام في التصيد والهندسة الاجتماعية وربط المستخدم بخدمة بعينها.

#JWE: مشفّر، لكنه ليس بالضرورة غير قابل للاستغلال

رصد التحليل كذلك 2,937 بنية مرتبطة بالمصادقة من نوع JWE أو JSON Web Encryption.

هذا النوع يستخدم لتشفير بيانات JWT بحيث لا يستطيع طرف لا يملك المفتاح المناسب قراءة محتوى الرمز مباشرة.

لكن التشفير لا يعني بالضرورة أن الرمز غير قابل لإعادة الاستخدام.

بحسب التحليل، معظم هذه الرموز تم تعيينها بواسطة OpenAI باستخدام NextAuth.js. وعلى الرغم من أن المهاجم لا يستطيع فك محتوى الرمز وتحليله دون امتلاك مفتاح التشفير، فقد يظل قادرًا على إعادة تقديم الرمز إلى الخدمة كما هو إذا كان ما يزال صالحًا.

وهنا يظهر فرق مهم:

في يوم نشر البيانات، احتوى الملف على 1,843 رمزًا غير منتهي الصلاحية من أنواع JWT وJWE.

وهذا يعني أن جزءًا من البيانات المسروقة لم يكن تاريخيًا فقط، بل كان قابلًا للاستخدام في وقت نشره.

#مفاتيح API تنقل الخطر من الحساب إلى التكلفة والبنية التحتية

لم تقتصر البيانات على رموز الجلسات.

استخدم الباحثون أداة TruffleHog لتحليل السجلات، ووجدوا 24 مفتاح API ما تزال صالحة لأربع خدمات مرتبطة بالذكاء الاصطناعي:

• Google Gemini
• OpenAI
• Groq
• OpenRouter

مفتاح API مسروق قد يسمح للمهاجم باستخدام الخدمة على حساب الضحية، وقد يتحول ذلك إلى استهلاك مالي أو إساءة استخدام للموارد أو استخدام النموذج في أنشطة لا يملك المهاجم بنية تحتية خاصة لتنفيذها.

هذا النمط من الإساءة يُعرف باسم:

LLMjacking

وهو قريب في منطقه من استغلال موارد جهاز أو بيئة ضحية لتعدين العملات المشفرة، مع اختلاف أن المورد المسروق هنا هو الوصول إلى نماذج الذكاء الاصطناعي وقدرة الحوسبة المرتبطة بها.

بدل أن يدفع المهاجم تكلفة الوصول إلى النموذج أو الحوسبة، تنتقل التكلفة إلى مالك الحساب أو المؤسسة.

#من سرقة الحساب إلى سوق متكامل للوصول إلى نماذج AI

مع توسع تبني الذكاء الاصطناعي داخل المؤسسات، توسعت أيضًا قيمة البيانات التي تجمعها برمجيات Infostealer.

أصبحت الأسواق الإجرامية تعرض حزمًا من رموز الجلسات، حسابات جاهزة، وبيئات تصفح مخصصة لإعادة استخدام بيانات المصادقة المسروقة.

وفي إحدى منشورات Telegram التي رصدتها Okta، كان أحد البائعين يعرض وصولًا مخفض السعر إلى Claude وCursor وChatGPT وGemini، إلى جانب دعم على مدار الساعة وضمان استرجاع الأموال.

كما ظهر اسم خدمة أخرى هي Poison Claude تدعي توفير وصول إلى عدة نماذج من Anthropic.

المشهد هنا يشبه سوقًا لخدمات شرعية من حيث التسعير والدعم، لكنه قائم على بيانات وصول مسروقة.

#Anti-Detect Browsers تجعل إعادة الجلسات أكثر عملية

إعادة استخدام الجلسات المسروقة لا تعتمد فقط على امتلاك الرمز.

هناك أدوات وبيئات متخصصة تساعد المهاجم على جعل الجلسة تبدو أقرب إلى جلسة المستخدم الحقيقي.

من أمثلتها:

Anti-Detect Browsers

وأدوات مفتوحة المصدر أو أتمتة مثل:

Camoufox

SeleniumBase

يمكن لهذه الأدوات تحميل بيانات مسروقة من:

sessionStorage

و:

localStorage

كما يمكن ضبطها للعمل عبر بروكسيات مختلفة.

الفائدة للمهاجم هي تقليل احتمالية اصطدام الجلسة بمؤشرات أمنية تقليدية، مثل اختلاف الموقع الجغرافي أو ظهور تنقل مستحيل بين دولتين خلال فترة قصيرة.

أي أن المهاجم لا يحاول فقط امتلاك الجلسة، بل يحاول إعادة بناء السياق الذي يجعل استخدامها أقل إثارة للاشتباه.

#متى تفشل هجمات Session Replay؟

ليست كل جلسة مسروقة قابلة للاستخدام بنجاح.

أحد الضوابط التي قد تمنع إعادة تشغيل الجلسة هو IP Allowlisting.

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

كذلك قدمت Google دعمًا لـ:

Device Bound Session Credentials (DBSC)

في Chrome.

الفكرة الأساسية في DBSC هي ربط بيانات الجلسة تشفيريًا بالجهاز، بحيث لا يكفي نسخ الرمز من جهاز الضحية واستخدامه على جهاز آخر.

هذا النموذج يغيّر طبيعة حماية الجلسة من:

Whoever possesses the token may be able to use it

إلى نموذج أقرب إلى:

The token is useful only when it can be proven to belong to the bound device

وهو فارق جوهري عند مواجهة برمجيات سرقة المتصفحات.

#الحادثة لا تقف عند تطبيقات AI

أشارت Google إلى أنها رصدت زيادة في أعداد البائعين والمشترين المهتمين بحسابات الذكاء الاصطناعي داخل مجتمعات الجريمة الإلكترونية.

الطلب شمل بيانات اعتماد لخدمات مثل Claude وGemini، بالإضافة إلى بيئات تطوير تعتمد على الذكاء الاصطناعي مثل Cursor Pro وDevin.

وفي إحدى حالات الاستجابة للحوادث التي تعامل معها فريق Mandiant، استخدم مهاجم GitHub Personal Access Token (PAT) مكشوفًا للوصول الأولي إلى بيئة سحابية، ثم استغل البيئة لنشر بنية ذكاء اصطناعي غير مصرح بها وتوسيع موارد حوسبة عالية الأداء.

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

#البعد المؤسسي: المشكلة أصبحت جزءًا من Identity وCloud وGRC

من منظور تقني، القضية تتعلق بسرقة رموز ومفاتيح.

لكن من منظور المؤسسات، المسألة أوسع.

حسابات الذكاء الاصطناعي أصبحت جزءًا من سطح الهوية المؤسسية، ومفاتيح API أصبحت جزءًا من مخاطر الأسرار الرقمية، بينما أصبح استهلاك النماذج والحوسبة جزءًا من المخاطر المالية والتشغيلية.

يمكن تلخيص الأثر بهذه الصورة:

بالنسبة لفرق الحوكمة والمخاطر والالتزام، لا يكفي اعتبار منصات الذكاء الاصطناعي مجرد خدمات SaaS إضافية.

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

#ما الذي يتغير في نموذج الحماية؟

الاستنتاج الأهم من هذه البيانات هو أن حماية حسابات الذكاء الاصطناعي لا يمكن أن تعتمد فقط على تقوية تسجيل الدخول.

استخدام Passkeys وتقنيات مقاومة التصيد يجعل سرقة اسم المستخدم وكلمة المرور أكثر صعوبة، لكنه لا يمنع استخدام جلسة سُرقت بعد اكتمال المصادقة.

ولهذا تبرز مجموعة من الضوابط التي أشار إليها التقرير:

• مراقبة إعادة استخدام رموز الجلسات.
• تقييد نطاق مفاتيح API.
• الاعتماد على تدفقات OAuth 2.0 مع رموز قصيرة العمر.
• استخدام IP Allowlisting عندما يناسب بيئة العمل.
• تقنيات ربط الجلسة بالجهاز مثل DBSC.
• تقليل فترة بقاء الرموز صالحة بما يحد من نافذة الاستغلال.

الفكرة ليست أن كل رمز مسروق سيؤدي بالضرورة إلى اختراق، بل أن قيمة الرمز تتغير جذريًا إذا كان قابلًا للنقل بين الأجهزة وقابلًا للاستخدام دون إعادة التحقق من هوية صاحبه.

#الخلاصة

كلما ارتفعت تكلفة الوصول إلى النماذج المتقدمة والحوسبة عالية الأداء، زادت قيمة الحسابات والمفاتيح والجلسات المسروقة داخل الاقتصاد الإجرامي.

وفي هذا السياق، لم تعد برمجيات Infostealer تستهدف كلمات المرور وحدها. هي تجمع مفاتيح API، رموز جلسات، بيانات متصفح، وبيانات اعتماد قد تسمح للمهاجم بتجاوز مرحلة تسجيل الدخول بالكامل.

السؤال الأمني لم يعد فقط:

Can an attacker steal the password?

بل أصبح أيضًا:

What happens if the attacker steals the authenticated session itself?

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