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
Software
Security Apps
Kaspersky
Loncom packer: from backdoors to Cobalt Strike
Message
<blockquote data-quote="Bot" data-source="post: 870550" data-attributes="member: 52014"><p><img src="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/02094116/abstract-bomb-scull-sad-cross-scull-990x400.jpg" alt="" class="fr-fic fr-dii fr-draggable " style="" /></p><p></p><p>The <a href="https://securelist.com/mokes-and-buerak-distributed-under-the-guise-of-security-certificates/96324/" target="_blank">previous story</a> described an unusual way of distributing malware under disguise of an update for an expired security certificate. After the story went out, we conducted a detailed analysis of the samples we had obtained, with some interesting findings. All of the malware we examined from the campaign was packed with the same packer, which we named Trojan-Dropper.NSIS.Loncom. The malware uses legitimate NSIS software for packing and loading shellcode, and Microsoft Crypto API for decrypting the final payload. Just as the earlier find, this one was not without its surprises, as one of the packaged samples contained software used by APT groups.</p><p></p><p><span style="font-size: 18px"><strong>Primary analysis</strong></span></p><p></p><p></p><p>Loncom utilizes NSIS for running shellcode contained in a file with a name that consists of numbers. In our example, the file is named 485101134:</p><p><a href="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31112816/loncom_packer_01.png" target="_blank"><img src="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31112816/loncom_packer_01.png" alt="" class="fr-fic fr-dii fr-draggable " style="" /></a></p><p><em>Overview of the NSIS archive contents</em></p><p></p><p></p><p>Once the shellcode is unpacked to the hard disk and loaded into the memory, an NSIS script calculates the starting position and proceeds to the next stage.</p><p></p><p><span style="font-size: 18px"><strong>What the shellcode does</strong></span></p><p></p><p></p><p>Before proceeding to decrypt the payload, the shellcode starts decrypting itself piece by piece, using the following algorithm:</p><p></p><ul> <li data-xf-list-type="ul">Find position for next 0xDEADBEEF dword.</li> <li data-xf-list-type="ul">Read dword: size of data to decrypt.</li> <li data-xf-list-type="ul">Read dword: first part of key.</li> <li data-xf-list-type="ul">Read dword: second part of key.</li> <li data-xf-list-type="ul">Find suitable key: check the numbers consequently, starting at 0, while xor(i, second part of key) != first part of key. This part is needed to hold up execution and prevent AV detection. After simplification, key = i = xor(first part, second part).</li> <li data-xf-list-type="ul">Decrypt next part of shellcode (xor), move on to it.</li> </ul><p><a href="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111057/loncom_packer_02.png" target="_blank"><img src="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111057/loncom_packer_02.png" alt="" class="fr-fic fr-dii fr-draggable " style="" /></a></p><p><em>Decrypting the next part of the shellcode</em></p><p></p><p></p><p>Here’s the code that performs the algorithm described above:</p><p></p><p><a href="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111113/loncom_packer_03.png" target="_blank"><img src="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111113/loncom_packer_03.png" alt="" class="fr-fic fr-dii fr-draggable " style="" /></a> </p><p>After several such iterations of block decryption, the shellcode switches to active steps, loading libraries and retrieving the addresses of required functions with the help of the APIHashing technique. This helps avoid stating the names of requested functions directly, providing their hashes instead. When searching for functions by hash, a hash will be calculated for each element from the library export table until it matches the target.</p><p></p><p>Then, Loncom decrypts the payload contained in the same file as the shellcode and proceeds to run it. The payload is encrypted with an AES-256 block cipher. The decryption key is stated in the code, and the payload offset and size are passed from the NSIS script.</p><p></p><p><a href="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111120/loncom_packer_04.png" target="_blank"><img src="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111120/loncom_packer_04.png" alt="" class="fr-fic fr-dii fr-draggable " style="" /></a></p><p><em>The main part of the shellcode: decrypting the payload</em></p><p></p><p><span style="font-size: 18px"><strong>Unpacking</strong></span></p><p></p><p></p><p>For automated Loncom unpacking, we need to find out how data is stored in the packed NSIS installers, obtain the payload offset and size from the NSIS script, and pull the key from the shellcode.</p><p></p><p><span style="font-size: 15px"><strong>Unpacking the NSIS</strong></span></p><p></p><p></p><p>After a brief analysis, we managed to find that the NSIS installers have the following structure:</p><p></p><ul> <li data-xf-list-type="ul">an MZPE NSIS interpreter containing in its overlay the data to be processed: the flag, the signatures, the size of the unpacked header, and the total size of the data, and then the containers, i.e. the compressed data itself.</li> <li data-xf-list-type="ul">Containers in the following format: dword (data size):zlib_deflate(data). The 0th container has the header, the first container has our file with the shellcode and the payload, and the second one has the DLL with the NSIS plugin.</li> <li data-xf-list-type="ul">The header contains a table of operation codes for the NSIS interpreter, a string table and a language table.</li> </ul><p></p><p>As we have obtained the encrypted file, now all we need is to find the payload offset and size, and proceed to decrypting the payload and the shellcode.</p><p></p><p><a href="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111141/loncom_packer_05.png" target="_blank"><img src="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111141/loncom_packer_05.png" alt="" class="fr-fic fr-dii fr-draggable " style="" /></a></p><p><em>NSIS data structure</em></p><p></p><p></p><p>As all arguments in the NSIS operation codes when using plugins are passed as strings, we need to retrieve from the header string table all strings that look like numbers within the logical limits: from 0 to (file size – shellcode size).</p><p>NSIS unpacking code:</p><p></p><p><a href="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111151/loncom_packer_06.png" target="_blank"><img src="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111151/loncom_packer_06.png" alt="" class="fr-fic fr-dii fr-draggable " style="" /></a> </p><p>To simplify determining the payload offset and size, we can recall the structure of the file with the shellcode: encrypted blocks are decrypted from the smallest address to the largest, top to bottom, and the payload is located above the shellcode. Thus, we can determine the position of the 0xDEADBEEF byte and consider it the end of the encrypted data (aligning as required, because AES is a block cipher).</p><p></p><p><span style="font-size: 15px"><strong>Decrypting the shellcode</strong></span></p><p></p><p></p><p>To decrypt the payload, we need to:</p><p></p><ul> <li data-xf-list-type="ul">decrypt the shellcode blocks;</li> <li data-xf-list-type="ul">determine where the AES key is;</li> <li data-xf-list-type="ul">retrieve the key;</li> <li data-xf-list-type="ul">try to decrypt the payload for offsets received from the NSIS;</li> <li data-xf-list-type="ul">stop after obtaining the first two bytes = ‘MZ’.</li> </ul><p></p><p>Step one can be performed by slightly modifying the code that performs the decryption algorithm in IDA Pro. The key can be determined with the help of a simple regular expression: ‘\xC7\x45.(….)\xC7\x45.(….)\xC7\x45.(….)\xC7\x45.(….)\xE8’ — “mov dword ptr” 4 times, then “call” (pseudocode in the main part of the shellcode).</p><p>The other steps do not require a detailed explanation. We will now describe the actual malware that was packed with Loncom.</p><p></p><p><span style="font-size: 18px"><strong>What’s inside</strong></span></p><p></p><p></p><p>Besides Mokes and Buerak, which we mentioned in the previous article, we noticed packed specimens of Backdoor.Win32.DarkVNC and Trojan-Ransom.Win32.Sodin families, also known as REvil and Sodinokibi. The first is a type of backdoor used for controlling an infected machine via the VNC protocol. The second is a <a href="https://securelist.com/sodin-ransomware/91473/" target="_blank">ransomware that encrypts the victim’s information</a> and threatens to publish it.</p><p>However, the most exciting find was the Cobalt Strike utility, used both by legal pentesters and by various APT groups. The command center of the sample that contained Cobalt Strike had previously been seen distributing CactusTorch, a utility for running shellcode present in Cobalt Strike modules, and the same Cobalt Strike packed with a different packer.</p><p></p><p>We continue monitoring Trojan-Dropper.NSIS.Loncom and hope to share new findings soon.</p><p></p><p><span style="font-size: 18px"><strong>IOC</strong></span></p><p></p><p></p><p><a href="https://opentip.kaspersky.com/BB00BA9726F922E07CF243D3CCFC2B6E/" target="_blank">BB00BA9726F922E07CF243D3CCFC2B6E</a> (Backdoor.Win32.DarkVNC)</p><p><a href="https://opentip.kaspersky.com/EBE191BF77044961684DF51B88CA8D05/" target="_blank">EBE191BF77044961684DF51B88CA8D05</a> (Backdoor.Win32.DarkVNC)</p><p><a href="https://opentip.kaspersky.com/4B4C98AC8F04680F7C529956CFE8519B/" target="_blank">4B4C98AC8F04680F7C529956CFE8519B</a> (Trojan-Ransom.Win32.Sodin)</p><p><a href="https://opentip.kaspersky.com/AEF8FBB5C64734093E78EB13E6FA7849/" target="_blank">AEF8FBB5C64734093E78EB13E6FA7849</a> (Cobalt Strike)</p><p></p><p><a href="https://securelist.com/loncom-packer-from-backdoors-to-cobalt-strike/96465/" target="_blank">Source</a></p></blockquote><p></p>
[QUOTE="Bot, post: 870550, member: 52014"] [IMG]https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/02094116/abstract-bomb-scull-sad-cross-scull-990x400.jpg[/IMG] The [URL='https://securelist.com/mokes-and-buerak-distributed-under-the-guise-of-security-certificates/96324/']previous story[/URL] described an unusual way of distributing malware under disguise of an update for an expired security certificate. After the story went out, we conducted a detailed analysis of the samples we had obtained, with some interesting findings. All of the malware we examined from the campaign was packed with the same packer, which we named Trojan-Dropper.NSIS.Loncom. The malware uses legitimate NSIS software for packing and loading shellcode, and Microsoft Crypto API for decrypting the final payload. Just as the earlier find, this one was not without its surprises, as one of the packaged samples contained software used by APT groups. [SIZE=5][B]Primary analysis[/B][/SIZE] Loncom utilizes NSIS for running shellcode contained in a file with a name that consists of numbers. In our example, the file is named 485101134: [URL='https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31112816/loncom_packer_01.png'][IMG]https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31112816/loncom_packer_01.png[/IMG][/URL] [I]Overview of the NSIS archive contents[/I] Once the shellcode is unpacked to the hard disk and loaded into the memory, an NSIS script calculates the starting position and proceeds to the next stage. [SIZE=5][B]What the shellcode does[/B][/SIZE] Before proceeding to decrypt the payload, the shellcode starts decrypting itself piece by piece, using the following algorithm: [LIST] [*]Find position for next 0xDEADBEEF dword. [*]Read dword: size of data to decrypt. [*]Read dword: first part of key. [*]Read dword: second part of key. [*]Find suitable key: check the numbers consequently, starting at 0, while xor(i, second part of key) != first part of key. This part is needed to hold up execution and prevent AV detection. After simplification, key = i = xor(first part, second part). [*]Decrypt next part of shellcode (xor), move on to it. [/LIST] [URL='https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111057/loncom_packer_02.png'][IMG]https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111057/loncom_packer_02.png[/IMG][/URL] [I]Decrypting the next part of the shellcode[/I] Here’s the code that performs the algorithm described above: [URL='https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111113/loncom_packer_03.png'][IMG]https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111113/loncom_packer_03.png[/IMG][/URL] After several such iterations of block decryption, the shellcode switches to active steps, loading libraries and retrieving the addresses of required functions with the help of the APIHashing technique. This helps avoid stating the names of requested functions directly, providing their hashes instead. When searching for functions by hash, a hash will be calculated for each element from the library export table until it matches the target. Then, Loncom decrypts the payload contained in the same file as the shellcode and proceeds to run it. The payload is encrypted with an AES-256 block cipher. The decryption key is stated in the code, and the payload offset and size are passed from the NSIS script. [URL='https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111120/loncom_packer_04.png'][IMG]https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111120/loncom_packer_04.png[/IMG][/URL] [I]The main part of the shellcode: decrypting the payload[/I] [SIZE=5][B]Unpacking[/B][/SIZE] For automated Loncom unpacking, we need to find out how data is stored in the packed NSIS installers, obtain the payload offset and size from the NSIS script, and pull the key from the shellcode. [SIZE=4][B]Unpacking the NSIS[/B][/SIZE] After a brief analysis, we managed to find that the NSIS installers have the following structure: [LIST] [*]an MZPE NSIS interpreter containing in its overlay the data to be processed: the flag, the signatures, the size of the unpacked header, and the total size of the data, and then the containers, i.e. the compressed data itself. [*]Containers in the following format: dword (data size):zlib_deflate(data). The 0th container has the header, the first container has our file with the shellcode and the payload, and the second one has the DLL with the NSIS plugin. [*]The header contains a table of operation codes for the NSIS interpreter, a string table and a language table. [/LIST] As we have obtained the encrypted file, now all we need is to find the payload offset and size, and proceed to decrypting the payload and the shellcode. [URL='https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111141/loncom_packer_05.png'][IMG]https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111141/loncom_packer_05.png[/IMG][/URL] [I]NSIS data structure[/I] As all arguments in the NSIS operation codes when using plugins are passed as strings, we need to retrieve from the header string table all strings that look like numbers within the logical limits: from 0 to (file size – shellcode size). NSIS unpacking code: [URL='https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111151/loncom_packer_06.png'][IMG]https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/03/31111151/loncom_packer_06.png[/IMG][/URL] To simplify determining the payload offset and size, we can recall the structure of the file with the shellcode: encrypted blocks are decrypted from the smallest address to the largest, top to bottom, and the payload is located above the shellcode. Thus, we can determine the position of the 0xDEADBEEF byte and consider it the end of the encrypted data (aligning as required, because AES is a block cipher). [SIZE=4][B]Decrypting the shellcode[/B][/SIZE] To decrypt the payload, we need to: [LIST] [*]decrypt the shellcode blocks; [*]determine where the AES key is; [*]retrieve the key; [*]try to decrypt the payload for offsets received from the NSIS; [*]stop after obtaining the first two bytes = ‘MZ’. [/LIST] Step one can be performed by slightly modifying the code that performs the decryption algorithm in IDA Pro. The key can be determined with the help of a simple regular expression: ‘\xC7\x45.(….)\xC7\x45.(….)\xC7\x45.(….)\xC7\x45.(….)\xE8’ — “mov dword ptr” 4 times, then “call” (pseudocode in the main part of the shellcode). The other steps do not require a detailed explanation. We will now describe the actual malware that was packed with Loncom. [SIZE=5][B]What’s inside[/B][/SIZE] Besides Mokes and Buerak, which we mentioned in the previous article, we noticed packed specimens of Backdoor.Win32.DarkVNC and Trojan-Ransom.Win32.Sodin families, also known as REvil and Sodinokibi. The first is a type of backdoor used for controlling an infected machine via the VNC protocol. The second is a [URL='https://securelist.com/sodin-ransomware/91473/']ransomware that encrypts the victim’s information[/URL] and threatens to publish it. However, the most exciting find was the Cobalt Strike utility, used both by legal pentesters and by various APT groups. The command center of the sample that contained Cobalt Strike had previously been seen distributing CactusTorch, a utility for running shellcode present in Cobalt Strike modules, and the same Cobalt Strike packed with a different packer. We continue monitoring Trojan-Dropper.NSIS.Loncom and hope to share new findings soon. [SIZE=5][B]IOC[/B][/SIZE] [URL='https://opentip.kaspersky.com/BB00BA9726F922E07CF243D3CCFC2B6E/']BB00BA9726F922E07CF243D3CCFC2B6E[/URL] (Backdoor.Win32.DarkVNC) [URL='https://opentip.kaspersky.com/EBE191BF77044961684DF51B88CA8D05/']EBE191BF77044961684DF51B88CA8D05[/URL] (Backdoor.Win32.DarkVNC) [URL='https://opentip.kaspersky.com/4B4C98AC8F04680F7C529956CFE8519B/']4B4C98AC8F04680F7C529956CFE8519B[/URL] (Trojan-Ransom.Win32.Sodin) [URL='https://opentip.kaspersky.com/AEF8FBB5C64734093E78EB13E6FA7849/']AEF8FBB5C64734093E78EB13E6FA7849[/URL] (Cobalt Strike) [url="https://securelist.com/loncom-packer-from-backdoors-to-cobalt-strike/96465/"]Source[/url] [/QUOTE]
Insert quotes…
Verification
Post reply
Top
