Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
Malware Analysis
PyPI Malware Creators are starting to Employ Anti-Debug techniques
Message
<blockquote data-quote="upnorth" data-source="post: 1018043" data-attributes="member: 38832"><p>Quote: " Most PyPI malware today tries to avoid static detection using various techniques: starting from primitive variable mangling to sophisticated code flattening and steganography techniques. Use of these techniques makes the package extremely suspicious, but it does prevent novice researchers from understanding the exact operation of the malware using static analysis tools. However - <strong><u>any dynamic analysis tool, such as a malware sandbox, quickly removes the malware’s static protection layers and reveals the underlying logic</u></strong>.</p><p></p><p>Recently, it seems that attackers have stepped up a notch – we’ve recently detected and disclosed the <strong>cookiezlog</strong> package which seemed to employ <strong>Anti-debugging code</strong> (designed to thwart dynamic analysis tools) in addition to regular obfuscation tools and techniques. <strong>This is the first time our research team (or any publication) have spotted these kinds of defenses in PyPI malware. </strong>In this post, we will give an overview of the techniques used in this Python malware and how to unpack similar malware. </p><p></p><p>Similar to most malicious packages, the <strong>cookiezlog</strong> package runs immediately upon installation. This is achieved via “develop” and “install” triggers in setup.py –</p><p>[CODE]class PostDevelopCommand(develop):</p><p> def run(self):</p><p> execute()</p><p> install.run(self)</p><p> </p><p> </p><p>class PostInstallCommand(install):</p><p> def run(self):</p><p> execute()</p><p> install.run(self)</p><p> </p><p>...</p><p> </p><p>setup(</p><p> name='cookiezlog',</p><p> version='0.0.1',</p><p> description='Extra Package for Roblox grabbing',</p><p> ...</p><p> cmdclass={</p><p> 'develop': PostDevelopCommand,</p><p> 'install': PostInstallCommand,</p><p> },</p><p>)[/CODE]</p><p>The first and simplest layer of protection is zlib-encoded code, which is executed immediately after the package is installed. The decoded payload downloads a file from a hardcoded URL and executes it on the victim’s machine. The executable is a Windows PE file. Looking at the strings in the executable, we can see that it’s not actual native code but rather a Python script packed into the PE format. It can be quickly unpacked with the open-source tool <a href="https://github.com/extremecoders-re/pyinstxtractor" target="_blank">PyInstaller Extractor</a>. The extracted code contains a lot of files, primarily third-party libraries. The most interesting extracted file is <strong>main.pyc</strong>, which contains the malware code as Python bytecode.</p><p></p><p>Normally, we would be able to decompile the bytecode in <strong>main.pyc</strong> to Python source code, using tools such as <a href="https://pypi.org/project/uncompyle6/" target="_blank">uncompyle6</a>. However, in this case, another run of strings on <strong>main.pyc</strong> shows that the binary has been obfuscated with <a href="https://github.com/dashingsoft/pyarmor" target="_blank">PyArmor</a>. PyArmor is a commercial packer and obfuscator, which applies obfuscation techniques to the original code, encrypts it and protects it from analysis. Fortunately for the researchers, PyArmor keeps much of the information that’s necessary for introspection. Knowing this, we can try to restore the names of the functions and constants used in the original code. Although PyArmor does not have any publicly-available unpacker, it can be fully unpacked with some manual effort. In this case, we chose to perform a quick unpacking shortcut (by using library injection) since we were mostly interested in the original symbols and strings. "</p><p></p><p>Quote: " We created our own file named psutil.py in the same directory as the protected file (main.pyc) with the following code. The snippet uses the <strong>inspect</strong> module, which allows to get a runtime information about the code being executed: it iterates over execution frames and extracts the names of the code blocks and referenced constants. After running our snippet, it returned a list of strings that allowed us to discern the capabilities and origin of the malicious code. The most interesting strings were the URL of an injection module, pointing to the possible attacker’s repository, and references to anti-VM functionalities in the code. </p><p></p><p>The Syntheticc GitHub profile mentioned in the strings was still available at the time of writing. The profile’s repositories contain a bunch of open-source hacking tools. Among others there was a repository called “Advanced Anti Debug”, containing methods that could be used to prevent analysis of the malware. We can split the dynamic methods the malware used into two categories: Anti-Debug and Anti-VM. The Anti-Debug checks look for suspicious system activity related to any debuggers or disassemblers and includes the following functions: <strong>check_processes</strong> looks whether debugger process runs on the system – comparing the active process list to the list of over 50 known tools, including - </p><ul> <li data-xf-list-type="ul">“idau64.exe” (IDA Pro Disassembler)</li> <li data-xf-list-type="ul">“x64dbg.exe” (x64dbg Debugger)</li> <li data-xf-list-type="ul">“Windbg.exe” (WinDbg Debugger)</li> <li data-xf-list-type="ul">“Devenv.exe” (Visual Studio IDE)</li> <li data-xf-list-type="ul">“Processhacker.exe” (Process Hacker)</li> </ul><p>[CODE]PROCNAMES = [</p><p> "ProcessHacker.exe",</p><p> "httpdebuggerui.exe",</p><p> "wireshark.exe",</p><p> "fiddler.exe",</p><p> "regedit.exe",</p><p>...</p><p>]</p><p> </p><p>for proc in psutil.process_iter():</p><p> if proc.name() in PROCNAMES:</p><p> proc.kill()</p><p>[/CODE]</p><p><strong>check_research_tools</strong> has almost the same functionality, comparing substrings of process names to a humble list of five traffic analysis tools:</p><ul> <li data-xf-list-type="ul">“wireshark” (Wireshark network protocol analyzer)</li> <li data-xf-list-type="ul">“fiddler” (Fiddler proxy)</li> <li data-xf-list-type="ul">“http” (HTTP Debugger and possibly more tools)</li> <li data-xf-list-type="ul">“traffic” (generic term)</li> <li data-xf-list-type="ul">“packet” (generic term)</li> </ul><p>If any of these processes are found to be running, the Anti-Debug code tries to kill the process via psutil.Process.kill – not a very subtle approach. Malware that is more stealth-conscious would just stop running without any indication, instead of interacting with external processes. The other anti-debug techniques try to make sure the malware is not running inside a virtual machine. "</p><p></p><p>Quote: " <strong>All of the checks mentioned above are relatively simple, but with the respectable protection against static analysis the malware already employed, it offers adequate protection against novice researchers – especially ones who only use automated analysis tools which wouldn’t be able to breach the defenses of this specific malware</strong>. The payload is disappointingly simple compared to the amount of defenses used by the malware, but it is still harmful. The payload is a password grabber, which gathers “autocomplete” passwords saved in the data caches of popular browsers and sends them to the C2 server (in this case a Discord hook. From the strings extracted from the malware we can deduce that in addition to the “industry standard” Discord token leaker functionality, the payload also hunts for passwords of several <strong>financial services</strong> as can be seen by strings used by the <strong>send_info</strong> function. </p><p>[CODE]Name: send_info</p><p>Filename:</p><p>Argument count: 0</p><p>...</p><p>Constants:</p><p>0: None</p><p>1: 'USERPROFILE'</p><p>...</p><p>5: 'coinbase'</p><p>...</p><p>7: 'binance'</p><p>...</p><p>9: 'paypal'</p><p>...[/CODE]</p><p></p><p><strong><span style="font-size: 15px">Summary</span></strong></p><p></p><p>Just a couple of years ago, the only tools that PyPI malware authors used were simple payload encoders. Today we see that malware that’s uploaded to OSS repositories is becoming more complex, has a few levels of static and dynamic protection and utilize combinations of commercial and homebrew tools. This is similar to their “colleagues” in the world of native malware and as such we are expecting OSS-repo malware to continue to evolve, perhaps with advanced techniques such as custom polymorphic encoding and deeper anti-debug methods. "</p><p></p><p>Full source:</p><p>[URL unfurl="true"]https://jfrog.com/blog/pypi-malware-creators-are-starting-to-employ-anti-debug-techniques/[/URL]</p></blockquote><p></p>
[QUOTE="upnorth, post: 1018043, member: 38832"] Quote: " Most PyPI malware today tries to avoid static detection using various techniques: starting from primitive variable mangling to sophisticated code flattening and steganography techniques. Use of these techniques makes the package extremely suspicious, but it does prevent novice researchers from understanding the exact operation of the malware using static analysis tools. However - [B][U]any dynamic analysis tool, such as a malware sandbox, quickly removes the malware’s static protection layers and reveals the underlying logic[/U][/B]. Recently, it seems that attackers have stepped up a notch – we’ve recently detected and disclosed the [B]cookiezlog[/B] package which seemed to employ [B]Anti-debugging code[/B] (designed to thwart dynamic analysis tools) in addition to regular obfuscation tools and techniques. [B]This is the first time our research team (or any publication) have spotted these kinds of defenses in PyPI malware. [/B]In this post, we will give an overview of the techniques used in this Python malware and how to unpack similar malware. Similar to most malicious packages, the [B]cookiezlog[/B] package runs immediately upon installation. This is achieved via “develop” and “install” triggers in setup.py – [CODE]class PostDevelopCommand(develop): def run(self): execute() install.run(self) class PostInstallCommand(install): def run(self): execute() install.run(self) ... setup( name='cookiezlog', version='0.0.1', description='Extra Package for Roblox grabbing', ... cmdclass={ 'develop': PostDevelopCommand, 'install': PostInstallCommand, }, )[/CODE] The first and simplest layer of protection is zlib-encoded code, which is executed immediately after the package is installed. The decoded payload downloads a file from a hardcoded URL and executes it on the victim’s machine. The executable is a Windows PE file. Looking at the strings in the executable, we can see that it’s not actual native code but rather a Python script packed into the PE format. It can be quickly unpacked with the open-source tool [URL='https://github.com/extremecoders-re/pyinstxtractor']PyInstaller Extractor[/URL]. The extracted code contains a lot of files, primarily third-party libraries. The most interesting extracted file is [B]main.pyc[/B], which contains the malware code as Python bytecode. Normally, we would be able to decompile the bytecode in [B]main.pyc[/B] to Python source code, using tools such as [URL='https://pypi.org/project/uncompyle6/']uncompyle6[/URL]. However, in this case, another run of strings on [B]main.pyc[/B] shows that the binary has been obfuscated with [URL='https://github.com/dashingsoft/pyarmor']PyArmor[/URL]. PyArmor is a commercial packer and obfuscator, which applies obfuscation techniques to the original code, encrypts it and protects it from analysis. Fortunately for the researchers, PyArmor keeps much of the information that’s necessary for introspection. Knowing this, we can try to restore the names of the functions and constants used in the original code. Although PyArmor does not have any publicly-available unpacker, it can be fully unpacked with some manual effort. In this case, we chose to perform a quick unpacking shortcut (by using library injection) since we were mostly interested in the original symbols and strings. " Quote: " We created our own file named psutil.py in the same directory as the protected file (main.pyc) with the following code. The snippet uses the [B]inspect[/B] module, which allows to get a runtime information about the code being executed: it iterates over execution frames and extracts the names of the code blocks and referenced constants. After running our snippet, it returned a list of strings that allowed us to discern the capabilities and origin of the malicious code. The most interesting strings were the URL of an injection module, pointing to the possible attacker’s repository, and references to anti-VM functionalities in the code. The Syntheticc GitHub profile mentioned in the strings was still available at the time of writing. The profile’s repositories contain a bunch of open-source hacking tools. Among others there was a repository called “Advanced Anti Debug”, containing methods that could be used to prevent analysis of the malware. We can split the dynamic methods the malware used into two categories: Anti-Debug and Anti-VM. The Anti-Debug checks look for suspicious system activity related to any debuggers or disassemblers and includes the following functions: [B]check_processes[/B] looks whether debugger process runs on the system – comparing the active process list to the list of over 50 known tools, including - [LIST] [*]“idau64.exe” (IDA Pro Disassembler) [*]“x64dbg.exe” (x64dbg Debugger) [*]“Windbg.exe” (WinDbg Debugger) [*]“Devenv.exe” (Visual Studio IDE) [*]“Processhacker.exe” (Process Hacker) [/LIST] [CODE]PROCNAMES = [ "ProcessHacker.exe", "httpdebuggerui.exe", "wireshark.exe", "fiddler.exe", "regedit.exe", ... ] for proc in psutil.process_iter(): if proc.name() in PROCNAMES: proc.kill() [/CODE] [B]check_research_tools[/B] has almost the same functionality, comparing substrings of process names to a humble list of five traffic analysis tools: [LIST] [*]“wireshark” (Wireshark network protocol analyzer) [*]“fiddler” (Fiddler proxy) [*]“http” (HTTP Debugger and possibly more tools) [*]“traffic” (generic term) [*]“packet” (generic term) [/LIST] If any of these processes are found to be running, the Anti-Debug code tries to kill the process via psutil.Process.kill – not a very subtle approach. Malware that is more stealth-conscious would just stop running without any indication, instead of interacting with external processes. The other anti-debug techniques try to make sure the malware is not running inside a virtual machine. " Quote: " [B]All of the checks mentioned above are relatively simple, but with the respectable protection against static analysis the malware already employed, it offers adequate protection against novice researchers – especially ones who only use automated analysis tools which wouldn’t be able to breach the defenses of this specific malware[/B]. The payload is disappointingly simple compared to the amount of defenses used by the malware, but it is still harmful. The payload is a password grabber, which gathers “autocomplete” passwords saved in the data caches of popular browsers and sends them to the C2 server (in this case a Discord hook. From the strings extracted from the malware we can deduce that in addition to the “industry standard” Discord token leaker functionality, the payload also hunts for passwords of several [B]financial services[/B] as can be seen by strings used by the [B]send_info[/B] function. [CODE]Name: send_info Filename: Argument count: 0 ... Constants: 0: None 1: 'USERPROFILE' ... 5: 'coinbase' ... 7: 'binance' ... 9: 'paypal' ...[/CODE] [B][SIZE=4]Summary[/SIZE][/B] Just a couple of years ago, the only tools that PyPI malware authors used were simple payload encoders. Today we see that malware that’s uploaded to OSS repositories is becoming more complex, has a few levels of static and dynamic protection and utilize combinations of commercial and homebrew tools. This is similar to their “colleagues” in the world of native malware and as such we are expecting OSS-repo malware to continue to evolve, perhaps with advanced techniques such as custom polymorphic encoding and deeper anti-debug methods. " Full source: [URL unfurl="true"]https://jfrog.com/blog/pypi-malware-creators-are-starting-to-employ-anti-debug-techniques/[/URL] [/QUOTE]
Insert quotes…
Verification
Post reply
Top
