روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛  به عنوان اعضای تیم واکنش اضطراری جهانی  (GERT)، ما روزانه با ردپاهای فارنزیکی کار می‌کنیم تا تحقیقات را پیش ببریم. یکی از باارزش‌ترینِ این ردپاها UserAssist است که اطلاعات مفیدی درباره اجرای برنامه‌ها دارد و به ما در شناسایی و ردیابی فعالیت‌های مهاجمان و کشف نمونه‌های بدافزار کمک می‌کند. با این حال، UserAssist  تاکنون به طور گسترده بررسی نشده و این باعث شده دانش ما درباره تفسیر داده‌ها، شرایط ثبت و عوامل فعال‌کننده آن ناقص باشد.

این مقاله تحلیل عمیقی از ردپای UserAssist ارائه می‌دهد و ابهامات مربوط به نحوه نمایش داده‌های آن را روشن می‌کند. همچنین به بررسی روند ایجاد و به‌روزرسانی ردپا، ساختار مقدار UEME_CTLSESSION و نقش آن در ثبت داده‌های UserAssist می‌پردازد و در نهایت ساختار داده‌ای جدیدی از UserAssist را معرفی می‌کند. با ما همراه باشید.

خلاصه‌ای از آرتیفکت[1]  UserAssist

در جامعه فارنزیک[2]، UserAssist  یکی از آرتیفکت‌های شناخته‌شده ویندوز است که برای ثبت اجرای برنامه‌های گرافیکی (GUI) استفاده می‌شود. این آرتیفکت داده‌های مختلفی درباره هر برنامه گرافیکی که روی سیستم اجرا شده، ذخیره می‌کند:

•          نام برنامه: مسیر کامل برنامه
•          تعداد اجرا: تعداد دفعاتی که برنامه اجرا شده
•          تعداد تمرکز: تعداد دفعاتی که برنامه در حالت فعال و در کانون توجه قرار گرفته، چه با سوئیچ کردن از برنامه‌های دیگر یا به هر شکل دیگر
•          مدت زمان تمرکز: مجموع زمانی که برنامه در حالت فعال بوده
•          آخرین زمان اجرا: تاریخ و زمان آخرین اجرای برنامه

آرتیفکت UserAssist در رجیستری، زیر کلید اصلی یا هایو NTUSER.DAT در مسیر
Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\ قرار دارد. این کلید شامل زیرکلیدهایی با نام‌های GUID است که دو زیرکلید اصلی و مهم در میان آن‌ها وجود دارد:

• {CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}: registers executed EXE files.
• {F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}: registers executed LNK files.

 

هر زیرکلید، زیرکلیدی به نام "Count" دارد که شامل مقادیری است که برنامه‌های اجرا شده را نشان می‌دهد. نام این مقادیر، مسیر برنامه‌ها هستند که با استفاده از رمزگذاری ROT-13 کد شده‌اند. این مقادیر داده‌های دودویی ساختاریافته‌ای را در خود دارند که شامل تعداد اجرا، تعداد تمرکز، مدت زمان تمرکز و آخرین زمان اجرای برنامه مربوطه است. این ساختار به خوبی شناخته شده و نمایانگر شیء CUACount است. بایت‌های بین مدت زمان تمرکز و آخرین زمان اجرا تاکنون به صورت عمومی شرح داده یا تحلیل نشده‌اند، اما ما موفق شدیم ماهیت آن‌ها را مشخص کنیم که در ادامه مقاله به آن می‌پردازیم. چهار بایت آخر ناشناخته‌اند و در تمام داده‌هایی که بررسی کردیم مقدار صفر داشتند.

ناسازگاری داده‌ها

در طول تحقیقات متعدد، مشخص شد داده‌های UserAssist ناسازگار هستند. برخی مقادیر شامل همه پارامترهای ذکر شده می‌شدند، در حالی که برخی دیگر تنها شامل تعداد اجرا و آخرین زمان اجرا شدند. در کل، پنج ترکیب مختلف از ناسازگاری داده‌های UserAssist مشاهده کردیم.

تحلیل روند کاری

بررسی عمیق توابع  Shell32

برای درک دلایل این ناسازگاری باید به مؤلفه‌ای که مسئول ثبت و به‌روزرسانی داده‌های UserAssist است، نگاه کنیم. تحلیل ما نشان داد که این مؤلفه فایل shell32.dll و به‌خصوص تابعی به نام FireEvent است که متعلق به کلاس CUserAssist می‌باشد. آرگومان‌های تابع FireEvent به شرح زیر است:

•          آرگومان ۱: GUID که زیرکلیدی از کلید رجیستری UserAssist است و داده‌های ثبت شده را در خود دارد. این آرگومان اغلب مقدار {CEBFF5CD-ACE2-4F4F-9178-9926F41749EA} را می‌گیرد چون برنامه‌های اجرا شده معمولاً فایل‌های EXE هستند.
•          آرگومان ۲: مقدار شمارنده عددی که تعیین می‌کند کدام شمارنده‌ها و داده‌ها باید به‌روزرسانی شوند.
  مقدار ۰: به‌روزرسانی تعداد اجرا و آخرین زمان اجرا

مقدار ۱: به‌روزرسانی تعداد تمرکز

مقدار ۲: به‌روزرسانی مدت زمان تمرکز

مقدار ۳: نامشخص

مقدار ۴: نامشخص (احتمالاً برای حذف ورودی استفاده می‌شود)

•          آرگومان ۳: مسیر کامل فایل اجرایی که اجرا، متمرکز یا بسته شده است.
•          آرگومان ۴: مدت زمان تمرکز روی فایل اجرایی برحسب میلی‌ثانیه. این مقدار فقط وقتی آرگومان ۲ برابر ۲ باشد، مقدار دارد؛ در غیر این صورت صفر است.

علاوه بر این، تابع FireEvent به دو تابع دیگر از shell32.dll یعنی s_Read و s_Write وابسته است. این توابع مسئول خواندن و نوشتن داده‌های باینری UserAssist از رجیستری و به رجیستری هستند، هر زمان که برنامه‌ای خاص به‌روزرسانی می‌شود.

تابع s_Read داده‌های باینری UserAssist را از رجیستری به حافظه می‌خواند، در حالی که تابع s_Write داده‌های باینری UserAssist را از حافظه به رجیستری می‌نویسد. هر دو تابع آرگومان‌های یکسانی دارند که عبارتند از:

•          آرگومان ۱: اشاره‌گر به بافر حافظه (ساختار CUACount)که داده‌های باینری UserAssist را دریافت یا در خود دارد.
•          آرگومان ۲: اندازه داده‌های باینری UserAssist به بایت که باید از رجیستری خوانده یا به آن نوشته شود.
•          آرگومان ۳: ساختار مستندسازی نشده‌ای که شامل دو اشاره‌گر است:

o        اشاره‌گر نمونه CUADBLog در آفست 0x0

o        مسیر کامل فایل اجرایی به صورت متن ساده که داده‌های باینری مرتبط با آن باید از رجیستری خوانده یا به رجیستری نوشته شود.

زمانی که برنامه‌ای برای اولین بار اجرا می‌شود و ورودی مربوط به آن در رکوردهای UserAssist وجود ندارد، تابع s_Read مقدار UEME_CTLCUACount:ctor را می‌خواند که به عنوان قالب ساختار داده باینری UserAssist (CUACount) عمل می‌کند. این مقدار را بعداً در مقاله توضیح خواهیم داد.

شایان ذکر است که توابع s_Read و s_Write همچنین مسئول رمزگذاری نام مقادیر با استفاده از رمز ROT-13 نیز هستند.

روند به‌روزرسانی داده‌هایUserAssist

هر تعاملی با برنامه‌ای که رابط گرافیکی (GUI) دارد، یک رویداد محرک است که منجر به فراخوانی تابع CUserAssist::FireEvent  می‌شود. چهار نوع رویداد محرک وجود دارد:

•          اجرای برنامه
•          فعال شدن برنامه (قرار گرفتن در کانون توجه)
•          غیرفعال شدن برنامه (خارج شدن از کانون توجه)
•          بسته شدن برنامه

رویداد محرک، روند اجرای تابع CUserAssist::FireEvent را تعیین می‌کند. این روند بر اساس مقدار شمارشی است که به عنوان آرگومان دوم به FireEvent ارسال می‌شود و مشخص می‌کند کدام شمارنده‌ها و داده‌ها باید در داده‌های باینری UserAssist به‌روزرسانی شوند. تابع CUserAssist::FireEvent ابتدا تابع CUADBLog::s_Read را برای خواندن داده‌های باینری از رجیستری به حافظه فراخوانی می‌کند. سپس شمارنده‌ها و داده‌های مربوطه را به‌روزرسانی کرده و در نهایت با فراخوانی CUADBLog::s_Write داده‌ها را دوباره به رجیستری می‌نویسد. توابعی که تابع FireEvent را فراخوانی می‌کنند بسته به نوع رویداد محرک ناشی از تعامل با برنامه متفاوت است. جدول زیر، پشته فراخوانی هر رویداد محرک را همراه با ماژول‌های توابع نشان می‌دهد.

بررسی ناسازگاری‌ها

همانطور که پیش‌تر گفته شد، پنج ترکیب مختلف از داده‌های UserAssist مشاهده کردیم. تحلیل دقیق ما نشان می‌دهد این ناسازگاری‌ها ناشی از تعاملات مختلف با برنامه و توابع متفاوتی است که تابع FireEvent را فراخوانی می‌کنند. اکنون به بررسی دقیق‌تر رویدادهای محرکی می‌پردازیم که باعث این ناسازگاری‌ها می‌شوند.

همه داده‌ها

اولین ترکیب شامل ثبت چهار پارامتر در رکورد UserAssist است: تعداد اجرا، تعداد تمرکز، مدت زمان تمرکز و آخرین زمان اجرا. در این حالت، برنامه معمولاً روند اجرای عادی را طی می‌کند، دارای رابط گرافیکی است و با دوبار کلیک در Windows Explorer  اجرا می‌شود.

•          هنگام اجرای برنامه، تابع FireEvent برای به‌روزرسانی تعداد اجرا و آخرین زمان اجرا فراخوانی می‌شود.
•          هنگام فعال شدن برنامه، FireEvent  برای به‌روزرسانی تعداد تمرکز فراخوانی می‌شود.
•          هنگام غیرفعال شدن یا بسته شدن برنامه، FireEvent برای به‌روزرسانی مدت زمان تمرکز فراخوانی می‌شود.

تعداد اجرا و آخرین زمان اجرا

   دومین ترکیب زمانی رخ می‌دهد که رکورد تنها شامل تعداد اجرا و آخرین زمان اجرا باشد. در این حالت، برنامه با دوبار کلیک    در Windows Explorer اجرا شده، اما رابط گرافیکی نمایش داده شده متعلق به برنامه دیگری است. نمونه‌هایی از این حالت شامل اجرای برنامه‌ای از طریق شورتکات LNK یا استفاده از نصب‌کننده‌ای است که برنامه گرافیکی دیگری را اجرا کرده و تمرکز را به آن منتقل می‌کند. در آزمایش ما، یک نسخه از calc.exe با دوبار کلیک در Windows Explorer اجرا شد، اما برنامه گرافیکی ظاهر شده، اپلیکیشن UWP ماشین‌حساب به نام Microsoft.WindowsCalculator_8wekyb3d8bbwe!App  بود.

رکوردی از نسخه دسکتاپ calc.exe در UserAssist وجود داشت که تنها شامل تعداد اجرا و آخرین زمان اجرا می‌شد، در حالی که تعداد تمرکز و مدت زمان تمرکز زیر ورودی UserAssist مربوط به ماشین‌حساب UWP ثبت شده بود.

تعداد تمرکز و مدت زمان تمرکز

سومین ترکیب شامل رکوردی می‌شود که فقط تعداد تمرکز و مدت زمان تمرکز را دارد. در این حالت، برنامه دارای رابط گرافیکی است اما به روش‌هایی غیر از دوبار کلیک در Windows Explorer اجرا شده است، مثلاً از طریق خط فرمان. در آزمایش ما، نسخه‌ای از Process Explorer در مجموعه Sysinternals از طریق cmd اجرا شد و در UserAssist تنها تعداد تمرکز و مدت زمان تمرکز آن ثبت شد.

تعداد اجرا، آخرین زمان اجرا و مدت زمان تمرکز

چهارمین ترکیب زمانی رخ می‌دهد که رکورد شامل تعداد اجرا، آخرین زمان اجرا و مدت زمان تمرکز باشد. این حالت فقط برای برنامه‌های خط فرمان (CLI) صدق می‌کند که با دوبار کلیک اجرا شده و بلافاصله بسته می‌شوند. اجرای دوبار کلیک باعث ثبت تعداد اجرا و آخرین زمان اجرا می‌شود. سپس رویداد بسته شدن برنامه تابع FireEvent را برای به‌روزرسانی مدت زمان تمرکز فراخوانی می‌کند که توسط تابع لامبدا (5b4995a8d0f55408566e10b459ba2cbe) فعال می‌شود.

در آزمایش ما، نسخه‌ای از whoami.exe با دوبار کلیک اجرا شد که برای لحظه‌ای کوتاه کنسول GUI را باز کرد و سپس بسته شد.

فقط مدت زمان تمرکز

پنجمین ترکیب رکوردی است که تنها دو مدت زمان تمرکز را دربرمی‌گیرد. این حالت فقط برای برنامه‌های خط فرمان که به روش‌هایی غیر از دوبار کلیک اجرا شده‌اند صدق می‌کند؛ برنامه‌هایی که کنسول GUI را برای لحظه‌ای کوتاه باز می‌کنند و بلافاصله بسته می‌شوند. در آزمایش ما، نسخه‌ای از whoami.exe با استفاده از PsExec اجرا شد، نه cmd. PsExec برنامه whoami را به عنوان فرزند خود اجرا کرد و باعث ایجاد فرآیند conhost.exe برای whoami شد. برای ثبت شدن برنامه CLI در UserAssist  در این حالت، این شرایط باید برقرار باشد.

CUASession و UEME_CTLSESSION
حالا که ناسازگاری داده‌های UserAssist را بررسی کردیم، بخش دوم این تحقیق به جنبه‌ای دیگر ازUserAssist می‌پردازد: کلاس CUASession و مقدار UEME_CTLSESSION.  پایگاه داده UserAssist شامل نام مقادیر برای هر برنامه اجرا شده است، اما یک مقدار ناشناخته به نام UEME_CTLSESSION وجود دارد. برخلاف داده‌های باینری که برای هر برنامه ثبت می‌شود، این مقدار داده‌های باینری بزرگ‌تری دارد: ۱۶۱۲ بایت، در حالی که اندازه معمول مقادیر برنامه‌های اجرا شده ۷۲ بایت است.

CUASession  کلاسی در داخل shell32.dll است که مسئول نگهداری آمار کل جلسه ثبت UserAssist برای همه برنامه‌هاست. در زمینه CUASession و UEME_CTLSESSION، به جای اصطلاحات تعداد اجرا، تعداد تمرکز و مدت زمان تمرکز، از واژه‌های راه‌اندازی، تعویض‌هایا سوئیچ‌هاو زمان کاربری  برای پارامترهای همه برنامه‌های اجرا شده در یک جلسه ثبت به جای داده‌های یک برنامه استفاده می‌کنیم.

مقدار UEME_CTLSESSION ساختار داده خاصی دارد که شامل موارد زیر است:

آفست 0x0: آمار کلی عمومی (۱۶ بایت)

        0x0:شناسه جلسه ثبت (۴ بایت)

        0x4:مجموع راه‌اندازی‌ها (۴ بایت)

        0x8:مجموع تعویض‌ها (۴ بایت)

        0xC:مجموع زمان کاربری بر حسب میلی‌ثانیه (۴ بایت)

آفست 0x10 سه ورودی NMax  (۱۵۹۶بایت)

        0x10: ورودی اول NMax ۵۳۲بایت

        0x224:  ورودی دوم NMax ۵۳۲بایت

        0x438:  ورودی سوم NMax ۵۳۲بایت

هر بار که تابع FireEvent برای به‌روزرسانی داده‌های برنامه فراخوانی می‌شود، CUASession ویژگی‌های خود را به‌روزرسانی کرده و آنها را در UEME_CTLSESSION ذخیره می‌کند.

•          زمانی که FireEvent برای به‌روزرسانی تعداد اجراهای برنامه فراخوانی می‌شود، CUASession مقدار Total Launches را در UEME_CTLSESSION افزایش می‌دهد.
•          زمانی که FireEvent برای به‌روزرسانی تعداد تمرکز برنامه فراخوانی می‌شود، CUASession مقدار Total Switches را افزایش می‌دهد.
•          زمانی که FireEvent برای به‌روزرسانی مدت زمان تمرکز برنامه فراخوانی می‌شود، CUASession مقدار Total User Time را به‌روزرسانی می‌کند.

ورودی‌های NMax
ورودی NMax بخشی از داده‌های UserAssist برای برنامه خاصی است که شامل تعداد اجرا، تعداد تمرکز، مدت زمان تمرکز و مسیر کامل برنامه می‌شود. ورودی‌های NMax بخشی از مقدار UEME_CTLSESSION هستند. هر ورودی NMax ساختار داده زیر را دارد:

•          آفست 0x0: تعداد اجراهای برنامه (۴ بایت)
•          آفست 0x4 : تعداد تمرکز برنامه (۴ بایت)
•          آفست 0x8  : مدت زمان تمرکز برنامه به میلی‌ثانیه (۴ بایت)
•          آفست 0xc: نام/مسیر کامل برنامه به صورت Unicode  (۵۲۰بایت، برابر با حداکثر طول مسیر ویندوز ضرب در دو)
•          ورودی‌های NMax برنامه‌هایی را پیگیری می‌کنند که بیشترین اجرا، تعویض و استفاده را دارند. هر بار که تابع FireEvent  برای به‌روزرسانی برنامه فراخوانی می‌شود، تابع CUADBLog::_CheckUpdateNMax نیز برای بررسی و به‌روزرسانی ورودی‌های NMax فراخوانی می‌شود.
•          ورودی اول NMax داده‌های برنامه‌ای را ذخیره می‌کند که بیشترین تعداد اجرا را دارد. اگر دو برنامه(برنامه‌ای که قبلاً در ورودی NMax ذخیره شده و برنامه‌ای که باعث فراخوانی FireEvent شده)تعداد اجرای برابر داشته باشند، ورودی بر اساس مقدار بالاتر N به‌روزرسانی می‌شود. مقدار N با فرمول زیر محاسبه می‌شود:
•          ارزش N= شمارش اجرای برنامه* (کل زمان کاربری / کل راه‌اندازی‌ها) + مدت زمان تمرکز برنامه + تعداد تمرکز برنامه * (کل زمان کاربری / کل تعویض‌ها)
•          ورودی دوم NMax داده‌های برنامه‌ای را ذخیره می‌کند که بیشترین تعویض را بر اساس تعداد تمرکز دارد. اگر دو برنامه تعداد تمرکز برابر داشته باشند، ورودی بر اساس مقدار بالاتر N به‌روزرسانی می‌شود.
•          ورودی سوم NMax داده‌های برنامه‌ای را ذخیره می‌کند که بیشترین استفاده را داشته باشد، بر اساس بالاترین مقدار N.

ریست شدن  UserAssist

مقدار UEME_CTLSESSION حتی پس از خروج از سیستم یا راه‌اندازی مجدد باقی می‌ماند. اما وقتی مجموع زمان کاربری کل برنامه‌های اجرا شده توسط کاربر فعلی به آستانه دو روز برسد، یعنی وقتی مجموع مدت زمان تمرکز به دو روز برابر شود، جلسه ثبت پایان می‌یابد و تقریباً تمام داده‌های UserAssist، از جمله مقدار UEME_CTLSESSION، ریست می‌شوند. مقدار UEME_CTLSESSION به همراه تقریباً تمام داده‌هایش مانند مجموع راه‌اندازی‌ها، مجموع تعویض‌ها، مجموع زمان کاربری و ورودی‌های NMax ریست می‌شود. با این حال، شناسه جلسهافزایش می‌یابد و یک جلسه ثبت جدید آغاز می‌شود.

شناسه جلسه جدید که افزایش یافته، در آفست 00 x  داده‌های UserAssist هر برنامه کپی می‌شود. علاوه بر مقدار UEME_CTLSESSION، سایر داده‌های UserAssist برای هر برنامه نیز ریست می‌شوند، از جمله تعداد اجرا، تعداد تمرکز، مدت زمان تمرکز و چهار بایت آخر که هنوز ناشناخته بوده و همیشه مقدار صفر دارند. تنها پارامتری که ریست نمی‌شود، آخرین زمان اجرا است. با این حال، همه این داده‌ها قبل از ریست به صورت درصد استفاده ذخیره می‌شوند.

درصد استفاده و شمارنده‌ها
ما داده‌های UserAssist برنامه‌های مختلف را برای شناسایی بایت‌های ناشناخته بین بخش‌های مدت زمان تمرکز و آخرین زمان اجرا بررسی کردیم. متوجه شدیم این بایت‌ها نشان‌دهنده فهرستی از درصد استفاده برنامه نسبت به برنامه‌ای است که در آن جلسه بیشترین استفاده را داشته، به همراه شمارنده بازنویسی (اندیس آخرین درصد استفاده نوشته شده در فهرست) برای ۱۰ جلسه آخر.

ارزش فارنزیکی

مقادیر r0 منبع ارزشمندی از اطلاعات درباره استفاده کاربر خاص از برنامه‌ها و نرم‌افزارها هستند. این مقادیر اطلاعات مفیدی برای تحقیقات حادثه فراهم می‌کنند، مانند موارد زیر:

• برنامه‌هایی که در فهرست r0 تعداد زیادی مقدار ۱ دارند، بیشترین میزان استفاده را توسط کاربر داشته‌اند.
• برنامه‌هایی که در فهرست r0 تعداد زیادی مقدار ۰ دارند، کم‌استفاده‌ترین یا رها شده توسط کاربر هستند که این موضوع می‌تواند در شکار تهدیدها و کشف بدافزارها یا نرم‌افزارهای مشروع مورد استفاده مهاجمان کمک کند.
• برنامه‌هایی که در فهرست r0 تعداد زیادی مقدار -۱ دارند، برنامه‌های نسبتاً جدیدی هستند که داده‌هایشان تا دو روز پس از جلسه تعاملی کاربر ریست نشده است.

قالب داده UserAssist

همانطور که گفته شد، وقتی برنامه برای اولین بار اجرا می‌شود و هنوز رکورد UserAssist خاص خود را ندارد (شیء CUACount)، یک ورودی جدید با مقدار UEME_CTLCUACount:ctor ایجاد می‌شود. این مقدار به عنوان قالبی برای داده باینری UserAssist برنامه با مقادیر زیر عمل می‌کند:

• شناسه جلسه لاگ کردن= -1 (0xff ff ff ff). با این حال اینمقدار از جلسه فعلی UEME_CTLSESSION به ورودی UserAssist کپی می‌شود.
• تعداد اجرا = ۰
• تعداد تمرکز = ۰
• مدت زمان تمرکز = ۰
• فهرست درصد استفاده (0-9 ) = -1 (x bf8000000 ) چون این مقادیر از نوع عدد اعشاری هستند.
• اندیس درصد استفاده (شمارنده) = -1 (xff ff ff ff0)
• آخرین زمان اجرا = ۰
• چهار بایت آخر = ۰

پارسر[3] جدید

بر اساس یافته‌های این تحقیق، ما یک پارسر جدید ساخته‌ایم که بر پایه یک پارسر متن‌باز توسعه یافته است. ابزار جدید ما همه مقادیر UEME_CTLSESSION را به فرمت JSON استخراج و ذخیره می‌کند. همچنین داده‌های UserAssist را با ساختار جدید مقادیر r0 تجزیه کرده و به صورت فایل CSV ذخیره می‌کند.

نتیجه‌گیری
ما به‌طور دقیق آرتیفکت UserAssist و ساختار داده‌های آن را بررسی کردیم. تحلیل جامع ما به شناسایی ناسازگاری‌های داده‌ای کمک کرد. تابع FireEvent در shell32.dll مسئول اصلی به‌روزرسانی داده‌های UserAssist است. تعاملات مختلف با برنامه‌ها باعث فراخوانی این تابع می‌شوند که عامل اصلی ناسازگاری‌ها در داده‌های UserAssist است. همچنین مقدار UEME_CTLSESSION را بررسی کردیم. این مقدار مسئول هماهنگی جلسه ثبت UserAssist است که پس از رسیدن زمان تمرکز جمعی همه برنامه‌ها به دو روز منقضی می‌شود. تحقیقات بیشتر در UEME_CTLSESSION هدف مقادیر باینری ناشناخته UserAssist را آشکار کرد؛ این مقادیر در واقع فهرست درصد استفاده برنامه‌ها و شمارنده بازنویسی مقادیر هستند. آرتیفکت UserAssist ابزاری ارزشمند برای فعالیت‌های واکنش به رخداد است و تحقیق ما می‌تواند به بهره‌برداری بهتر از داده‌های آن کمک کند.

 

[1]آرتیفکت (Artifact) در زمینه علوم فارنزیک دیجیتال یعنی هر نوع داده، فایل، یا اطلاعاتی که در سیستم‌های کامپیوتری یا دستگاه‌های دیجیتال به جا مانده و می‌تواند به عنوان مدرک در تحقیقات یا بررسی‌های امنیتی استفاده شود.

[2]جامعه فارنزیک به گروه یا جمعی از کارشناسان و متخصصان گفته می‌شود که در زمینه علوم قضایی دیجیتال (Digital Forensics) فعالیت می‌کنند. این افراد به بررسی، تحلیل و جمع‌آوری شواهد دیجیتال از دستگاه‌ها و سیستم‌های کامپیوتری می‌پردازند تا در تحقیقات قضایی، امنیتی یا جنایی به کار گرفته شوند..

[3]در برنامه‌نویسی به برنامه یا قطعه‌ کدی گفته می‌شود که یک متن یا دادهٔ ورودی را می‌گیرد و طبق یک ساختار مشخص (مثل دستور زبان یا فرمت فایل) آن را تجزیه و تحلیل می‌کند تا بخش‌های مختلف آن‌ را بفهمد و قابل‌ استفاده کند.

 

 کسپرسکی آنلاین (ایدکو)

کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.