CN116070211A - 恶意脚本检测方法及装置、存储介质及电子设备 - Google Patents

Abstract

本申请涉及网络安全技术领域，提供一种恶意脚本检测方法及装置、存储介质及电子设备。其中，恶意脚本检测方法包括：判断目标进程是否已经加载脚本引擎模块；若是，则在脚本引擎模块中搜索脚本处理函数；对脚本处理函数执行挂钩操作；在脚本处理函数被调用时，获取脚本处理函数所要处理的脚本，并对脚本进行恶意行为检测。该方法利用挂钩操作来实现恶意脚本的检测，其适用范围较广，有利于实现各种设备的全面保护。再者，该方法由于不依赖于特定操作系统提供的防御机制，所以不容易被攻击者绕开，其对恶意脚本的检测效果较好。另外，由于在跳转到检测流程时，所检测的脚本尚未执行，所以检测不会引发安全性问题。

Description

恶意脚本检测方法及装置、存储介质及电子设备

技术领域

本发明涉及网络安全技术领域，具体而言，涉及一种恶意脚本检测方法及装置、存储介质及电子设备。

背景技术

当今的网络攻击中，攻击者会使用各类脚本(例如，javascript、vbscript等脚本语言编写的脚本)来躲避安全软件的监控与拦截，因此有效检测恶意脚本对于提升网络的安全性尤为重要。

最近开发的部分操作系统中提供了特定的防御机制来协助恶意脚本的检测，例如，较新版本的Windows系统中提供了反恶意软件扫描接口(Antimalware ScanInterface，简称AMSI)，AMSI可将脚本的执行信息提供给安全软件实现脚本恶意行为的检测。然而，这类防御机制存在较大的缺陷：一些较老版本的操作系统中并不存在这样的机制，导致安装老版本系统的设备无法得到有效保护，即该机制严重依赖特定的系统版本，其防御功能严重受限。

发明内容

本申请实施例的目的在于提供一种恶意脚本检测方法及装置、存储介质及电子设备，以改善上述技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种恶意脚本检测方法，包括：判断目标进程是否已经加载脚本引擎模块；其中，加载所述脚本引擎模块的目标进程为脚本的宿主进程；若所述目标进程加载所述脚本引擎模块，则在所述脚本引擎模块中搜索脚本处理函数；对所述脚本处理函数执行挂钩操作；在所述脚本处理函数被所述脚本引擎模块调用时，获取所述脚本处理函数所要处理的脚本，并对所述脚本进行恶意行为检测。

在上述方法中，脚本引擎模块用于执行脚本，若目标进程中加载有脚本引擎模块，则表明目标进程为脚本的宿主进程，即目标进程会利用脚本引擎模块执行脚本，从而若脚本中包含有恶意内容，则目标进程执行脚本后会引发安全问题。脚本引擎模块中包含脚本处理函数，脚本引擎模块需要调用脚本处理函数才能实现脚本的执行。因此，若对脚本处理函数执行挂钩操作，在脚本引擎执行脚本时，一旦发生对脚本处理函数的调用，执行流程就必然跳转到自定义的处理逻辑中：获取脚本处理函数所要处理的脚本，并对其进行恶意行为检测。

上述方法主要是利用挂钩操作来实现恶意脚本的检测，而挂钩操作并不与特定的操作系统版本绑定，是各版本操作系统下都可以执行的一种操作，因此该方法的适用范围较广，有利于实现各种设备的全面保护。再者，基于特定操作系统的防御机制容易被攻击者关闭，从而绕开检测，但上述检测方法由于不依赖于特定操作系统提供的防御机制，所以不容易被攻击者绕开，其对恶意脚本的检测效果较好。另外，由于在执行自定义的处理逻辑时，所检测的脚本尚未执行，所以检测不会引发安全性问题。

在第一方面的一种实现方式中，所述方法还包括：若所述目标进程未加载所述脚本引擎模块，则继续监控所述目标进程是否加载所述脚本引擎模块，并在监控到所述目标进程加载所述脚本引擎模块后，在所述脚本引擎模块中搜索所述脚本处理函数。

目标进程当前未加载脚本引擎模块，但不排除目标进程之后会加载脚本引擎模块，即之后目标进程仍然可能成为宿主进程。在上述实现方式中，通过继续监控目标进程是否加载脚本引擎模块以持续检测恶意脚本，从而能够实现长期的安全防护。

在第一方面的一种实现方式中，所述监控所述目标进程是否加载所述脚本引擎模块，包括：利用预先在操作系统中注册的回调函数监控所述目标进程是否加载所述脚本引擎模块；其中，若所述目标进程加载所述脚本引擎模块，则所述回调函数被所述操作系统调用，否则所述回调函数不被调用。

在上述实现方式中，通过设置回调函数来监控目标进程是否加载所述脚本引擎模块，此种监控方式简单高效。

在第一方面的一种实现方式中，所述脚本处理函数包括脚本编译函数。

在上述实现方式中，脚本编译函数所处理的脚本是干净、完整的脚本，其中的编码、混淆等已经被去除，因此后续基于这样的脚本进行恶意行为检测，其检测结果更准确。

在第一方面的一种实现方式中，所述在所述脚本引擎模块中搜索脚本处理函数，包括：根据所述脚本处理函数的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置；其中，所述脚本处理函数的特征码为所述脚本处理函数中特定的代码片段。

在上述实现方式中，通过脚本处理函数的特征码在脚本引擎模块中搜索脚本处理函数的位置，其搜索逻辑简单，搜索效率较高。

在第一方面的一种实现方式中，所述根据所述脚本处理函数的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置，包括：获取操作系统的版本信息，确定与所述操作系统的版本信息对应的所述脚本处理函数的特征码，并根据所确定的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置；或者，获取所述脚本引擎模块的版本信息，确定与所述脚本引擎模块的版本信息对应的所述脚本处理函数的特征码，并根据所确定的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置。

在脚本引擎模块的版本不同时，脚本处理函数的代码可能存在一定的差别，因此用于搜索脚本处理函数的特征码也可能存在区别。在上述实现方式中，先获取脚本引擎模块的版本信息，确定对应的脚本处理函数的特征码，再进行脚本处理函数的搜索，有利于准确地搜索出脚本处理函数的位置。

进一步的，脚本引擎模块可能是随操作系统一同发布的，因此如果知道了操作系统的版本信息，也就等价于知道了脚本引擎模块的版本信息，所以以上方案中的脚本引擎模块的版本信息也可以替换为操作系统的版本信息。

在第一方面的一种实现方式中，所述对所述脚本进行恶意行为检测，包括：将所述脚本中的指令与指令列表中的预设指令进行匹配，若匹配成功，则执行对应的处理操作；其中，所述预设指令包括恶意指令和/或敏感指令。

在上述实现方式中，通过将脚本中的指令与指令列表中的预设指令匹配的方式，可以快速、准确地检测恶意脚本。并且，指令列表中的预设指令可以由用户自由配置，使用起来非常灵活。

在第一方面的一种实现方式中，所述方法由注入到所述目标进程中的脚本检测模块执行；其中，所述脚本检测模块为DLL模块。

在上述实现方式中，先将脚本检测模块注入到目标进程中，再由脚本检测模块执行脚本检测方法，可以使恶意脚本检测方法实现起来更加容易。例如，对于挂钩操作，如果在目标进程外部执行，其实现会非常复杂。

在第一方面的一种实现方式中，所述脚本检测模块在驱动程序中进行注入。

在上述实现方式中，由于驱动程序权限较高，因此在驱动程序中进行脚本检测模块的注入更加容易，可实现对更多进程的监控。

第二方面，本申请实施例提供一种恶意脚本检测装置，包括：加载判断单元，用于判断目标进程是否加载脚本引擎模块；其中，加载所述脚本引擎模块的目标进程为脚本的宿主进程；函数搜索单元，用于在确定所述目标进程加载所述脚本引擎模块后，在所述脚本引擎模块中搜索脚本处理函数；挂钩单元，用于对所述脚本处理函数执行挂钩操作；检测单元，用于在所述脚本处理函数被所述脚本引擎模块调用时，获取所述脚本处理函数所要处理的脚本，并对所述脚本进行恶意行为检测。

第三方面，本申请实施例提供一种计算机程序产品，包括计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第五方面，本申请实施例提供一种电子设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种恶意脚本检测方法的流程图；

图2为本申请实施例提供的一种恶意脚本检测装置的模块图；

图3为本申请实施例提供的一种电子设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

术语“第一”、“第二”等仅用于将一个实体或者操作与另一个实体或操作区分开来，而不能理解为指示或暗示相对重要性，也不能理解为要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

图1为本申请实施例提供的一种恶意脚本检测方法的流程图。该方法可以、但不限于由图3示出的电子设备执行，关于该电子设备的结构可以参考后文关于图3的阐述。参照图1，恶意脚本检测方法包括：

步骤S110：判断目标进程是否加载脚本引擎模块。

脚本是利用脚本语言(例如，javascript、vbscript语言)编写的程序代码。脚本引擎可以理解为一种执行脚本的工具，这里的“执行”可以理解为包括脚本解析、编译、运行等一系列步骤，不同的脚本语言可以对应不同的脚本引擎。其中，脚本引擎模块可以是指包含脚本引擎的动态链接库(Dynamic Link Library，简称DLL)模块，例如，在Windows操作系统中，DLL模块可实现为后缀为DLL的文件。

操作系统中的进程可以利用脚本引擎模块执行相应语言编写的脚本，这样的进程也称为脚本的宿主进程，宿主进程提供了脚本的执行环境。例如，Windows操作系统自带的两个脚本执行工具wscript.exe和cscript.exe(在运行起来时)就是两个宿主进程，二者均可以执行javascript脚本和vbscript脚本，二者的区别主要在于wscript.exe是窗口版本的程序，而cscript.exe是控制台版本的程序。但应当理解，宿主进程并不限于系统自带的脚本执行工具，其可以是任何要执行脚本的进程。

在步骤S110中，目标进程是指需要监控的进程(例如，监控这些进程是否会运行恶意脚本)，目标进程可以是操作系统中正在运行的全部或部分的进程。

根据上面的阐述，若目标进程要执行脚本，则必然会先加载脚本引擎模块，然后利用脚本引擎模块来执行脚本。因此，步骤S110实际上也是判断目标进程是否为宿主进程的步骤，若目标进程加载有脚本引擎模块，则目标进程是宿主进程，否则不是宿主进程。根据目标进程所要执行的脚本的不同，其加载的脚本引擎模块可以是一个或多个，例如，javascript引擎模块、vbscript引擎模块等。

目标进程当前加载的所有模块的信息是可以获得的，例如，通过某些Windows API就可以获得进程所加载的DLL模块的列表，从而可以进行步骤S110中的判断。

若步骤S110的判断结果表明目标进程加载了脚本引擎模块，则可以执行步骤S120，否则可以执行步骤S150，但S150是可选步骤，将在阐述完步骤S110～S140之后再阐述。

步骤S120：在脚本引擎模块中搜索脚本处理函数。

步骤S130：对脚本处理函数执行挂钩操作。

步骤S120～S130一起阐述，先介绍挂钩操作。挂钩操作是指：对目标函数的调用进行拦截，使得程序的执行流程从目标函数转入到用户自定义的处理逻辑中继续执行，从而可以在目标函数执行之前插入用户自定义的处理逻辑。用户自定义的处理逻辑执行完毕之后，执行流程可以返回目标函数，也可以不再返回目标函数，取决于处理逻辑如何设计。可选的，用户自定义的处理逻辑也可以采用函数的形式实现，称为挂钩函数。

对于本申请的方案而言，上述目标函数就是步骤S120中的脚本处理函数，而用户自定义的处理逻辑就是步骤S140中的脚本检测流程。要实现挂钩操作，先要在脚本引擎模块中搜索到脚本处理函数，然后再对脚本处理函数进行挂钩，即步骤S120和S130的内容。

步骤S120中的搜索脚本处理函数，可以是指搜索脚本处理函数在脚本引擎模块中的位置，步骤S130中根据脚本处理函数的位置对其执行挂钩操作。当然，也不排除在步骤S120中搜索脚本处理函数的标识等其他信息。由于脚本引擎模块已经被加载，所以可以读取到脚本引擎模块的内容，因此从其中搜索脚本处理函数是可行的。

挂钩操作可以不依赖于操作系统提供的功能接口(例如，Windows API)来实现，因此挂钩操作不依赖于特定的操作系统版本，或者说挂钩操作是各版本操作系统下都可以执行的一种操作。

脚本引擎模块中包含多个函数，脚本引擎模块需要调用这些函数才能实现其执行脚本的功能，可以将其中的一个或多个函数确定为脚本处理函数，脚本处理函数会获取所要执行的脚本，并对脚本进行相应的处理。从而，在对脚本处理函数执行挂钩操作后，步骤S140中的脚本检测流程可以先于脚本处理函数获取到所要执行的脚本，并进行自定义的恶意行为检测。

步骤S140：获取脚本处理函数所要处理的脚本，并对脚本进行恶意行为检测。

在目标程序(此时为宿主进程)执行脚本时，会利用脚本引擎模块来执行，而脚本引擎模块要执行脚本，则必然会调用其中的脚本处理函数，由于脚本处理函数已经被挂钩，所以执行流程会转入到脚本检测流程继续执行。

在脚本检测流程中，可以获取脚本处理函数所要处理的脚本，根据预设的逻辑来检测脚本中的恶意行为，以获得检测结果，并且还可以根据检测结果执行相应的操作，例如报警等。脚本检测流程具体要如何对脚本进行恶意行为检测可以根据用户的需求实现，具有极大的自由度，后文还会给出一些可能的实现方式。

简单总结步骤S110～S140中的恶意脚本检测方法，上述方法主要是利用挂钩操作来实现恶意脚本的检测，而挂钩操作并不与特定的操作系统版本绑定，是各版本操作系统下都可以执行的一种操作(这里的操作系统可以但不限于是Windows操作系统)，因此该方法的适用范围较广，有利于实现各种设备的全面保护。再者，基于特定操作系统的防御机制(例如，某些版本的Windows系统中的AMSI机制)容易被攻击者关闭，从而绕开检测，但上述检测方法由于不依赖于特定操作系统提供的防御机制，所以不容易被攻击者绕开，其对恶意脚本的检测效果较好。另外，由于在执行步骤S140中的脚本检测流程时，所检测的脚本尚未执行，所以检测不会引发安全性问题。

继续参照图1，可选的，若步骤S110的判断结果表明目标进程未加载脚本引擎模块，则可以执行步骤S150：继续监控目标进程是否加载脚本引擎模块。

目标进程当前(指执行步骤S110时)未加载脚本引擎模块，但不排除目标进程之后会加载脚本引擎模块。也就是说，即使目标进程当前不是脚本的宿主进程，之后仍然可能成为宿主进程，所以要持续监控目标进程是否加载脚本引擎模块，并在监控到目标进程加载脚本引擎模块后，转至步骤S120继续执行，从而可以持续检测可能执行的恶意脚本，进而能够实现长期的安全防护。

需要指出，针对步骤S150的执行条件“目标进程未加载脚本引擎模块”，可以理解为目标进程未加载任何脚本引擎模块，也可以理解为目标进程未加载特定的某些脚本引擎模块。对于后一种理解，例如，目标进程当前加载了javascript引擎模块，但是未加载vbscript引擎模块，则目标进程后续还是可能加载vbscript引擎模块的，所以此时仍然可以执行步骤S150，监控目标进程对vbscript引擎模块的加载行为。

步骤S150存在多种不同的实现方式：

例如，可以定期查询目标进程所加载的模块列表，并判断其中是否包含有目标引擎模块。

又例如，可以利用预先在操作系统中注册的回调函数来监控目标进程是否加载脚本引擎模块，这里的回调函数可以认为是操作系统提供的一种监控机制，可监控系统中特定行为的发生，先将回调函数注册到操作系统中，在注册完成之后，若目标进程加载脚本引擎模块，则相应的回调函数会被操作系统调用，否则回调函数不会被调用，从而一旦发现回调函数被调用，就可以确定目标进程已经加载脚本引擎模块。

通过设置回调函数实现监控的方式简单高效，并且能够在脚本引擎模块被加载的第一时间就得到通知，从而可以及时检测到可能执行的恶意脚本。可选的，可以在驱动程序中进行回调函数的注册，其中，驱动程序是一类权限较高(例如，ring0级别)的应用程序，从而便于进行回调函数的注册，关于驱动程序，后文在介绍注入时还会提到。

进一步的，若在执行步骤S110时，某个程序还未启动，但后期该程序启动了，并且其对应的进程也属于监控范围，即也属于目标进程。则可以类似于上面对脚本引擎模块的加载行为的监控，对进程的启动行为进行监控，一旦监控到有新的进程启动，则对其执行步骤S110及后续步骤，其监控方法也可以包括注册回调函数等，不再重复阐述。

在一种实现方式中，步骤S120中的脚本处理函数包括脚本编译函数，脚本编译函数用于编译待执行的脚本，编译后的脚本才能够运行。原始的脚本中可能进行了代码混淆、编码等操作，导致直接检测原始脚本中是否存在恶意行为比较困难，但脚本编译函数所处理的脚本是干净、完整的脚本，其中的代码混淆、编码等效果已经被去除，因此后续在步骤S140中基于这样的脚本进行恶意行为检测，其检测结果更准确。

在一种实现方式中，步骤S120可以实现为：根据脚本处理函数的特征码在脚本引擎模块中搜索脚本处理函数的位置，其中，脚本处理函数的特征码为脚本处理函数中特定的代码片段，通过将特征码与脚本引擎模块的内容进行比对即可以定位到脚本处理函数。此种搜索方式逻辑简单，搜索效率较高。注意，由于脚本引擎模块是可执行文件，其内容为机器指令，所以脚本处理函数的特征码也是特定的机器指令而非脚本处理函数的原始代码片段。应当理解，步骤S120还可以采用其他方式实现，例如从脚本引擎模块的符号表中搜索脚本处理函数的位置，等等。

进一步的，在脚本引擎模块的版本不同时，其中脚本处理函数的代码可能存在一定的差别，因此用于搜索脚本处理函数的特征码也可能存在区别，此时，为了准确搜索出脚本处理函数的位置，可以按照以下步骤执行：

首先，获取脚本引擎模块的版本信息，例如，可以直接从脚本引擎模块中读取其版本信息。然后，确定与脚本引擎模块的版本信息对应的脚本处理函数的特征码，例如，脚本引擎模块的版本信息与脚本处理函数的特征码之间的对应关系可以事先确定，从而根据脚本引擎模块的版本信息以及该对应关系就可以查询到对应的脚本处理函数的特征码。最后，根据所确定的脚本处理函数的特征码在脚本引擎模块中搜索脚本处理函数的位置。

在一种替代方案中，考虑到脚本引擎模块可能是随操作系统一同发布的(脚本引擎模块本身就可能是操作系统的一部分)，因此如果知道了操作系统的版本信息，也就等价于知道了脚本引擎模块的版本信息，例如，操作系统版本1.0对应脚本引擎模块版本1.0，操作系统版本2.0对应脚本引擎模块版本2.0等。因此，以上方案中的脚本引擎模块的版本信息也可以替换为操作系统的版本信息，替换后的方案如下：

首先，获取操作系统的版本信息。然后，确定与操作系统的版本信息对应的脚本处理函数的特征码。最后，根据所确定的脚本处理函数的特征码在脚本引擎模块中搜索脚本处理函数的位置。

在一种实现方式中，步骤S140中可以采用如下方式对脚本进行恶意行为检测：将脚本中的指令与指令列表中的预设指令进行匹配，若匹配成功，则执行对应的处理操作。

其中，预设指令包括恶意指令和/或敏感指令，恶意指令和敏感指令都是存在安全风险的指令，但恶意指令的风险级别更高，会产生明显危害，而敏感指令则不会产生明显的危害。在进行指令匹配时，可以是将脚本中的每条指令都拿去和指令列表中的预设指令匹配，也可以是将脚本中的部分指令拿去和指令列表中的预设指令匹配。“对应的处理操作”可以包括：抛出异常、上报服务器、记录日志、输出提示信息等一项或多项操作。对于匹配失败的情况，存在不同的处理方式，可以参考下面的例子。

在上述实现方式中，通过将脚本中的指令与指令列表中的预设指令匹配的方式，可以快速、准确地检测恶意脚本。并且，指令列表中的预设指令可以由用户自由配置，使用起来非常灵活。

以脚本中的任意一条指令X为例，一个符合以上描述的具体检测方案为：先将指令X与黑名单指令列表中的恶意指令进行匹配，若指令X和黑名单指令列表匹配成功，则表明X是恶意指令，可向服务器上报当前脚本，抛出异常(异常中可以包含该指令的信息等内容)并在防御软件中拦截该异常，以及输出提示信息(提示信息中可以包含该指令的信息等内容)。此时，由于抛出了异常，所以脚本处理函数也不会继续执行了，因此当前脚本并未运行，不会造成危害。

若指令X和黑名单指令列表匹配失败，则表明X不是恶意指令，将指令X与敏感指令列表中的敏感指令进行匹配，若指令X和敏感指令列表匹配成功，则表明X是敏感指令，可向服务器上报当前脚本，并输出提示信息(提示信息中可以包含该指令的信息等内容)。若指令X和敏感指令列表匹配失败，则表明X是无风险的指令，可以不执行任何额外的操作。

若脚本中参与匹配的指令不包含恶意指令，则可以允许脚本处理函数继续执行(即步骤S140执行完后返回脚本处理函数)，当前脚本最终也会运行。

可选的，黑名单指令列表和敏感指令列表都可以实现为配置文件，由用户自由配置，从而满足用户灵活多样的脚本检测需求。

需要指出，以上检测方案仅仅是一个示例，步骤S140中的检测逻辑可以根据需求自由设计：例如，也可以只进行黑名单列表的匹配，不进行敏感指令列表的匹配；又例如，也可以将恶意指令和敏感指令都放到一个列表中进行匹配；又例如，不是通过指令匹配，而是通过分析脚本的特征来确定其中是否存在恶意行为，等等。

在一种实现方式中，在执行步骤S110之前，先由某个程序将脚本检测模块(可以是一个DLL模块)注入到目标进程中，再由该脚本检测模块执行上面介绍的脚本检测方法的步骤(包含其各种实现方式)，即脚本检测模块可以实现监测脚本执行、匹配指令列表、上报与拦截恶意脚本、通知驱动程序监控脚本引擎模块的加载(见下面的阐述)等一项或多项功能。

通过注入DLL模块的方式进行恶意脚本检测，可以使恶意脚本检测方法实现起来更加容易。例如，对于挂钩操作，如果在目标进程外部执行，其实现会非常复杂，而在目标进程内部(脚本检测模块已经被注入目标进程，因此属于目标进程内部)实现则比较简单。

进一步的，脚本检测模块可以在驱动程序中进行注入，例如，运行驱动程序后，通过异步过程调用(Asynchronous Procedure Calls，简称APC)来实现脚本检测模块的注入。由于驱动程序权限较高，因此在驱动程序中进行脚本检测模块的注入更加容易，可实现对更多进程的监控。

特别地，前文在介绍回调函数的设置时曾介绍过驱动程序，前文介绍的驱动程序与此处的驱动程序可以是同一个驱动程序。需要指出的是，如果由驱动程序负责注册用于监控脚本引擎模块加载的回调函数(可选的，脚本检测模块可以在判断出目标进程未加载脚本引擎模块时，通知驱动程序注册回调函数)，一旦目标进程加载脚本引擎模块后，操作系统先通知的也是驱动程序，再由驱动程序通知脚本检测模块，然后脚本检测模块才会执行步骤S120，也就是说，对于脚本检测模块来说，前文提到利用预先注册的回调函数监控目标进程是否加载脚本引擎模块，实际上是脚本检测模块等待在驱动程序中进行注册的回调函数发送加载通知消息，若脚本检测模块接收到加载通知消息，则表明目标进程已经加载脚本引擎模块，可以继续执行步骤S120。应当理解，以上介绍的恶意脚本检测方法的各种实现方式，在不产生矛盾的情况下可以自由组合，其组合后的方案均纳入本申请的保护范围。

图2为本申请实施例提供的恶意脚本检测装置200的模块图。参照图2，恶意脚本检测装置200包括：

加载判断单元210，用于判断目标进程是否加载脚本引擎模块；其中，加载所述脚本引擎模块的目标进程为脚本的宿主进程；

函数搜索单元220，用于在确定所述目标进程加载所述脚本引擎模块后，在所述脚本引擎模块中搜索脚本处理函数；

挂钩单元230，用于对所述脚本处理函数执行挂钩操作；

检测单元240，用于在所述脚本处理函数被所述脚本引擎模块调用时，获取所述脚本处理函数所要处理的脚本，并对所述脚本进行恶意行为检测。

其中，上述所述脚本引擎模块可以为包含脚本引擎的DLL模块。

在恶意脚本检测装置200的一种实现方式中，函数搜索单元220还用于：在确定所述目标进程未加载所述脚本引擎模块时，继续监控所述目标进程是否加载所述脚本引擎模块，并在监控到所述目标进程加载所述脚本引擎模块后，在所述脚本引擎模块中搜索所述脚本处理函数。

在恶意脚本检测装置200的一种实现方式中，函数搜索单元220监控所述目标进程是否加载所述脚本引擎模块，包括：利用操作系统中预先注册的回调函数监控所述目标进程是否加载所述脚本引擎模块；其中，若所述目标进程加载所述脚本引擎模块，则所述回调函数被所述操作系统调用，否则所述回调函数不被调用。

在恶意脚本检测装置200的一种实现方式中，所述脚本处理函数包括脚本编译函数。

在恶意脚本检测装置200的一种实现方式中，函数搜索单元220在所述脚本引擎模块中搜索脚本处理函数，包括：根据所述脚本处理函数的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置；其中，所述脚本处理函数的特征码为所述脚本处理函数中特定的代码片段。

在恶意脚本检测装置200的一种实现方式中，函数搜索单元220根据所述脚本处理函数的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置，包括：获取操作系统的版本信息，确定与所述操作系统的版本信息对应的所述脚本处理函数的特征码，并根据所确定的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置；或者，获取所述脚本引擎模块的版本信息，确定与所述脚本引擎模块的版本信息对应的所述脚本处理函数的特征码，并根据所确定的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置。

在恶意脚本检测装置200的一种实现方式中，检测单元240对所述脚本进行恶意行为检测，包括：将所述脚本中的指令与指令列表中的预设指令进行匹配，若匹配成功，则执行对应的处理操作；其中，所述预设指令包括恶意指令和/或敏感指令。

在恶意脚本检测装置200的一种实现方式中，加载判断单元210、函数搜索单元220、挂钩单元230以及检测单元240均利用注入到所述目标进程中的脚本检测模块实现各自的功能；其中，所述脚本检测模块为DLL模块。

在恶意脚本检测装置200的一种实现方式中，所述脚本检测模块在驱动程序中进行注入。

本申请实施例提供的恶意脚本检测装置200，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法实施例中相应内容。

图3为本申请实施例提供的电子设备300的结构图。参照图3，电子设备300包括：处理器310、存储器320以及通信接口330，这些组件通过通信总线340和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，处理器310包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器310可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括神经网络处理器(Neural-network Processing Unit，简称NPU)、图形处理器(Graphics ProcessingUnit，简称GPU)、数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application Specific Integrated Circuits，简称ASIC)、现场可编程门阵列(FieldProgrammable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。并且，在处理器310为多个时，其中的一部分可以是通用处理器，另一部分可以是专用处理器。

存储器320包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除可编程只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。处理器310以及其他可能的组件可对存储器320进行访问，读和/或写其中的数据。

特别地，在存储器320中可以存储一个或多个计算机程序指令，处理器310可以读取并运行这些计算机程序指令，以实现本申请实施例提供的恶意脚本检测方法。

通信接口330包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口330可以包括进行有线和/或无线通信的接口。

可以理解的，图3所示的结构仅为示意，电子设备300还可以包括比图3中所示更多或者更少的组件，或者具有与图3所示不同的结构。图3中所示的各组件可以采用硬件、软件或其组合实现。电子设备300可能是实体设备，例如PC机、笔记本电脑、平板电脑、手机、服务器、嵌入式设备等，也可能是虚拟设备，例如虚拟机、虚拟化容器等。并且，电子设备300也不限于单台设备，也可以是多台设备的组合或者大量设备构成的集群。

本申请实施例还提供一种计算机程序产品，该产品包括计算机程序指令，这些计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的恶意脚本检测方法。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，这些计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的恶意脚本检测方法。例如，计算机可读存储介质可以实现为图3中电子设备300中的存储器320。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种恶意脚本检测方法，其特征在于，包括：

判断目标进程是否加载脚本引擎模块；其中，加载所述脚本引擎模块的目标进程为脚本的宿主进程；

若所述目标进程加载所述脚本引擎模块，则在所述脚本引擎模块中搜索脚本处理函数；

对所述脚本处理函数执行挂钩操作；

在所述脚本处理函数被所述脚本引擎模块调用时，获取所述脚本处理函数所要处理的脚本，并对所述脚本进行恶意行为检测。

2.根据权利要求1所述的恶意脚本检测方法，其特征在于，所述方法还包括：

若所述目标进程未加载所述脚本引擎模块，则继续监控所述目标进程是否加载所述脚本引擎模块，并在监控到所述目标进程加载所述脚本引擎模块后，在所述脚本引擎模块中搜索所述脚本处理函数。

3.根据权利要求2所述的恶意脚本检测方法，其特征在于，所述监控所述目标进程是否加载所述脚本引擎模块，包括：

利用预先在操作系统中注册的回调函数监控所述目标进程是否加载所述脚本引擎模块；其中，若所述目标进程加载所述脚本引擎模块，则所述回调函数被所述操作系统调用，否则所述回调函数不被调用。

4.根据权利要求1所述的恶意脚本检测方法，其特征在于，所述脚本处理函数包括脚本编译函数。

5.根据权利要求1所述的恶意脚本检测方法，其特征在于，所述在所述脚本引擎模块中搜索脚本处理函数，包括：

根据所述脚本处理函数的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置；其中，所述脚本处理函数的特征码为所述脚本处理函数中特定的代码片段。

6.根据权利要求5所述的恶意脚本检测方法，其特征在于，所述根据所述脚本处理函数的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置，包括：

获取操作系统的版本信息，确定与所述操作系统的版本信息对应的所述脚本处理函数的特征码，并根据所确定的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置；或者，

获取所述脚本引擎模块的版本信息，确定与所述脚本引擎模块的版本信息对应的所述脚本处理函数的特征码，并根据所确定的特征码在所述脚本引擎模块中搜索所述脚本处理函数的位置。

7.根据权利要求1所述的恶意脚本检测方法，其特征在于，所述对所述脚本进行恶意行为检测，包括：

将所述脚本中的指令与指令列表中的预设指令进行匹配，若匹配成功，则执行对应的处理操作；其中，所述预设指令包括恶意指令和/或敏感指令。

8.根据权利要求1-7中任一项所述的恶意脚本检测方法，其特征在于，所述方法由注入到所述目标进程中的脚本检测模块执行；其中，所述脚本检测模块为DLL模块。

9.根据权利要求8所述的恶意脚本检测方法，其特征在于，所述脚本检测模块在驱动程序中进行注入。

10.一种恶意脚本检测装置，其特征在于，包括：

加载判断单元，用于判断目标进程是否加载脚本引擎模块；其中，加载所述脚本引擎模块的目标进程为脚本的宿主进程；

函数搜索单元，用于在确定所述目标进程加载所述脚本引擎模块后，在所述脚本引擎模块中搜索脚本处理函数；

挂钩单元，用于对所述脚本处理函数执行挂钩操作；

检测单元，用于在所述脚本处理函数被所述脚本引擎模块调用时，获取所述脚本处理函数所要处理的脚本，并对所述脚本进行恶意行为检测。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行如权利要求1-9中任一项所述的方法。

12.一种电子设备，其特征在于，包括存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行权利要求1-9中任一项所述的方法。

Images