What is a script wrapping tool?
Simple scripting language which can be compiled into an PE type executable.
How do they work?
Administrators can write simple scripts in the known language of the wrapper which perform various administrative tasks. Then, a compiler wraps a standard code base around that script and generates a single Executable file.
What would people use them for? What is their purpose?
They are typically used by administrators who may not be comfortable writing shell scripts. These wrappers perform out of the box tasks and you just need to write just a few lines of script for them to work. By wrapping these simple scripts into a standard executable, administrators don’t have to worry about the environments they execute in as the wrapper makes it standard. Think of the wrapper as a container where you only must ensure your script works with the wrapper and the executable takes care of the rest.
Why are these so dangerous?
You might be asking yourself, why would you consider this to be dangerous? It seems smart to ensure your administrative tasks run properly. You might also think this method saves time because there would be less testing involved before deploying such easy tasks. And you’d be right in thinking these things if you look at it from a linear point of view. These executables would take more time to deploy if your network was properly secured. Not only would new executables need to be approved prior to deployment and execution, but these individual files must be delivered to all your systems. This approval and delivery process would take more time from both a policy and man-hours perspective.
The problem is that these scripts cannot be checked for validation, as a lot of these tasks require privilege escalation and are set up to run automatically. This can cause issues if the file is compromised and replaced by another tool. The second issue is that wrapping tools are quite easy to reverse engineer. There are simple tools out there than can export your entire script from that executable. What that means is that administrators might have a tough time remotely validating their executables are still in-tact, and hackers can easily view exactly what these administrative files are doing. And, because they can decompile your scripts, hackers can easily take your script in its entirety and add to them before recompiling back into a new executable. In such a case, your administrative tasks would appear to be running as they should, but your scripts have now become a backdoor Trojan for hackers to use.
What can I do to fix this problem? What’s the alternative?
Most organizations that have well established security policies typically lock down script executors like PowerShell and WScript because these common tools are being used by attackers to exploit systems. However, there are tools that can launch administrative scripts securely with these security measures in-place.
TYCHON, for instance, can launch PowerShell scripts on a timed basis in a secure manner across your enterprise in seconds. It does not use typical PowerShell executables. Rather, it runs your scripts locally in its agent allowing your existing security policies to stay in place while giving you the flexibility of running administrative tasks.
How can I detect script wrappers on my network?
You should be able to easily identify legitimate scripts on your network because when they are compiled the tool which creates the exe file typically puts items in the file’s meta data. Things like the file description indicate which tool was used to compile the script. However, a decent hacker will strip off these indicators, which means you will need to use a different method.
Fuzzy Hashes is a context triggered piecewise hash which lets administrators determine how different two files are to each other based on string distance calculation. Luckily for security professionals, a script wrapper will put the same exe code around the script every time it is compiled. The only part that changes is the script portion of the executable which is placed in the same spot every time. This means that by using Fuzzy Hash you can easily detect all script wrappers on your network with a high probability of success.
Can you give me an example?
Absolutely. For this exercise we will take a simple administrative task of ensuring auto run is disabled on our systems. To do this, I will use two tools:
- AutoIT V3 – Freeware tool which allows you write basic scripts (AutoIT scripts) and then compile those scripts into an exe file.
- TYCHON – Enterprise EDR tool which allows you to query endpoints in real-time and get you results from those queries in seconds.
Scenario 1: AutoIT V3
First, I need to check and change the registry key which controls this feature:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\NoDriveTypeAutorun
To do this in AutoIT I add a single line to my script:
Run(@ComSpec & ” /c ” & ‘reg add HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\NoDriveTypeAutorun /v NoDriveTypeAutorun /t REG_DWORD /d 0xFF /f’, “”, @SW_HIDE)
After compiling my script above I get the file UpdateAutoRun.exe, which I then copy to a share drive somewhere and start to deploy to my enterprise. Part of that deployment must be updating each system’s auto run keys to ensure this script executes every time the computer starts per user.
This task may take some additional time because now I must inform my organization a new executable is being deployed to the auto run key and that it is a legitimate application. After doing everything needed for our security policy and getting the binaries on everyone’s system, we can now feel somewhat comfortable that auto run will always be disabled. However, after a recon exercise by an attacker, they found this AutoIT script and modified it to push document based files out port 443 to their stolen Amazon S3 bucket. The script is recompiled and overwrites the administrative tool. The new version still modifies the registry key.
Because the malicious version is still performing its normal function to update the registry key, the executable may not raise any alarms. It launches every time users log on and gives the attacker an endless supply of command and control over the systems. And, because this is compiled binary code, it cannot be easily checked for accuracy by opening the script in a text editor.
To give you a look at this file, we will query for the file using TYCHON Rapid Query. From the results of the query you notice the SHA1 Hash of the file has changed, however the fuzzy hash is only slightly different:
File Name: SHA1 Hash
UpdateAutoRun.exe: 400a427cb8b4f57c42b47751ef5bc46b55a8f029
UpdateAutoRun.exe: e20fd2ea5c2e1c39abf9874d45e826b0bd231fd1
File Name: Fuzzy Hash: Match %
UpdateAutoRun.exe: 1536:qbR9OjH9hGUgxTCZq0ccyUuavJbtD62f8yPRGgaqEXom6MsJ7ZOh7:c9OD90UgxTCZq0/ZtLEYRGg7EXomRQZ0: 99%
UpdateAutoRun.exe: 1536:qbR9OjH9hGUgxTCZq0ccyUuavJbtD62f8yPRGgaqEXom6MsJ7ZOhP:c9OD90UgxTCZq0/ZtLEYRGg7EXomRQZs: 99%
Because the Fuzzy Hash change is so slight, we can use IOC’s to detect large changes to this file. We can use TYCHON signatures to alert admins when the executable changes by adding an IOC which detects when the fuzzy hash of your known good version of the executable is modified to less than a 100% match. In the very least, this will protect you in the short term.
However, this is not the ideal solution as, with IOC detection, we are only putting a band-aid over the problem. Security services can be shut down or circumvented, and it’s better to stop using these types of administrative techniques all together. Completely removing these types of executables from your enterprise is the best bet and to use the IOC example above only to detect when an attacker drops an AutoIT script to one of your systems. The answer is to convert these scripts to PowerShell and let TYCHON securely execute them across your enterprise.
Scenario 2: TYCHON
To solve the above scenario for good I will use TYCHON to create the following:
- Create a PowerShell script which changes the value of the AutoRun registry key. This is especially helpful because now that I’m centrally deploying the script, if something needs to change I only need to change it once for it to affect everyone. You can be assured that this PowerShell script will run securely in the TYCHON script environment which is stored in a FIPS-140 compliant repository.
- Create a query and dashboard around the status of AutoRun registry keys and have that report alert administrators when the key changes as this is a clear violation of policy and should never be changed.
- Update my IOC to take action when a new AutoIT script is detected to quarantine the system. I can further enhance this using third party systems like McAfee’s Advanced Threat Detection by uploading the file automatically to the sandbox for instant analysis.
In closing I’d just like to say that programs like AutoIT and other script wrappers can be handy for local day to day activities. However, they should not be used as an enterprise level tool. Luckily, by leveraging tools like TYCHON, I can securely execute these same administrative tasks while simultaneously reporting on the status in real-time and detect new threats that exist in my environment.
Additional Reading:
Information about TYCHON or to schedule a demo: https://tychon.io
Information about AutoIt can be found on their website: https://www.autoitscript.com/site/autoit/
Micheal Mimoso’s write-up on RATs that use AutoIt scripts: https://threatpost.com/autoit-used-in-targeted-attacks-to-move-rats/114406/
Information on Fuzzy Hashes: https://ssdeep-project.github.io/ssdeep/index.html
