如何利用LockCrypt勒索軟體自身弱點恢復加密數據

新聞 04-10

從今年年初開始，我們就意識到2018將變成加密貨幣挖礦軟體元年：它們的風頭如此之盛，壓倒性地蓋過了所有其他惡意軟體。然而，勒索軟體並沒有立即在這個領域繳械投降，相反，每隔幾個月就會有新的變體出現在某個角落，儘管在這裡看起來有點單薄。

目前，最受歡迎的勒索軟體非GandCrab莫屬。不過，自2017年6月以來，原先默默無聞的LockCrypt勒索軟體系列迅速蔓延開來。不過，由於它是通過RDP暴力攻擊進行傳播的，而這必須以手動方式進行，所以，尚未造成巨大的威脅。正因為如此，至今未見針對該軟體的深入分析報告。

但是，近期接觸到了一些LockCrypt的受害者之後，我們決定仔細研究一下該惡意軟體。在此過程中，我們發現了一些有趣的事情，那就是勒索軟體作者完全無視流行的建議，而是一意孤行地實現了自己的加密代碼。不難猜到，他在代碼中引入了某些弱點，導致在某些情況下可利用它們來恢復加密的數據。

分析的樣本

99a3d049f11474fac6844447ac2da430

行為分析

在許可權方面，該惡意軟體必須以管理員身份才能正常運行。此外，由於該勒索軟體需要以手動方式進行部署，因此，該軟體沒有使用任何用以提升許可權的技巧或漏洞利用代碼。

運行後，該軟體將刪除原始代碼，並將其自身投放到C： Windows下名稱為wwvcm.exe的文件中：

同時，它還會通過註冊表項來實現持久性：

這個勒索軟體會對自己能訪問的所有文件進行加密。在此過程中，它會枚舉並嘗試終止所有正在運行的應用程序，以便避免它們妨礙訪問受攻擊的文件。需要注意的是，可執行文件也會受到攻擊。

該軟體會對加密文件的名稱進行混淆處理：首先加密，然後轉換為base64。同時，還會為文件名稱添加隨機ID，加密後的文件擴展名為「1btc」。

另外，該惡意軟體的勒索信是作為TXT文件來進行投遞的：

這些信息將在完成加密工作後彈出。

通過考察加密文件的內容，我們發現其熵非常之高，下面展示了原文件加密前後對應的BMP文件的樣子：

我們對圖像的初步判斷是，這個勒索軟體的作者在這裡沒有使用常見的XOR操作。根據我們的推測，這裡好像使用了流密碼來加密文件（或CBC模式下的其他加密演算法）。通過查看代碼，我們將會對它有進一步的了解。

通過檢測註冊表項的變化情況，我們找到了該勒索軟體留下的其他數據，例如受害者的唯一ID：

網路通信

該惡意軟體能夠在沒有Internet連接的情況下進行加密。但是，當在接入互聯網的機器上運行該惡意軟體的時候，它會向其CnC發送信號。其中，CnC IP為46.32.17.222

（位於伊朗）。

下面展示的是通信數據的一部分：

這個勒索軟體會發送與受攻擊機器有關的base64編碼數據，例如隨機ID、用戶名、操作系統以及部署惡意軟體的路徑等：

WThSQVNVNDczUjZUMzVjNycsJ1dpbmRvd3MgNyBQcm9mZXNzaW9uYWx8dGVzdGVyfEM6XFVzZXJzXHRlc3RlclxEZXNrdG9wXGxvY2tjcnlwdC5leGU=

解碼後的內容：

Y8RASU473R6T35c7","Windows 7 Professional|tester|C:Users esterDesktoplockcrypt.exe

然後，伺服器會返回一組位元組數據，它們看起來像一些隨機或加密的數據。將來通過查看該軟體的內部代碼，就能弄清楚這些數據的作用。

深入分析勒索軟體代碼

對於這個惡意軟體樣本來說，它既沒有加殼，也沒有進行混淆處理。換句話說，我們可以直接看到代碼的真面目。

在剛開始時，該勒索軟體會檢查自己所在的文件夾，並試圖在Windows文件夾中創建一個副本，然後將自己重新部署到這個文件夾中。

然後，它會枚舉所有正在運行的進程，並嘗試終止其線程。

接著，它會讀取註冊表以檢查自己是否已部署過了。如果找到某些對應的註冊表項的話，它就會阻止重複感染——該惡意軟體會將機器識別為已感染過了。否則，它會繼續進行相應的部署工作。

加密過程

該惡意軟體的感染過程是從與CnC進行通信開始的。

通過考察這個函數，我們就會發現，原來在行為分析過程中看到的那些位元組，實際上扮演的是一個神秘的緩衝區的角色。下載的緩衝區會通過CRC32校驗和進行驗證。然後，它為進一步使用加密程序設置了一個全局變數。

現在來看，這個緩衝區貌似是一個用於加密處理的密碼本。該軟體的作者看上去好像要實現類似於一次性密碼本的加密功能。但是，鑒於這裡重複使用了該緩衝區，因此，他實現的演算法更容易受到明文攻擊。

有時候，如果無法從互聯網上下該載緩衝區的話，那麼還可以通過一個簡單的偽隨機數生成演算法來生成相應的位元組內容：

需要提示的是，該作者沒有仔細挑選性能最佳的隨機數生成器：使用的是GetTickCount函數，而不是更加符合加密要求的隨機數生成函數。

通過考察加密常式，我們可以看到，該文件是通過一個非常簡單的函數進行編碼的：

這裡的編碼演算法分兩輪完成文件的加密處理，相應代碼將在下面分別加以介紹。

第一輪編碼

本輪操作的操作非常簡單，它只用到了異或運算，不過它還引入了一個可以防止恢復原始密鑰的小技巧。雖然來自輸入的DWORD會與來自密鑰的DWORD進行異或運算，但需要注意的是，這裡的輸入還會受到前一個輸出的影響。在每一步中，輸入DWORD的前半部分都來自前一個輸出，而只有後半部分才是新引入的，這使得其成為一個簡單的流密碼演算法。

第二輪編碼

這一輪的處理看起來要更加複雜——在這裡不僅使用了XOR操作，還使用了ROL操作和逐位交換操作。但是，這裡沒有像第一輪那樣對輸入進行相應的處理，所以這些操作很容易被反轉。

經過這兩輪的簡單處理，在2,500個位元組長的「pad」緩衝區的共同作用下，我們就能夠得到具有相當高的熵的輸出了。

文件名稱的混淆處理

對於這些文件的名稱，首先會與緩衝區進行異或運算，然後進行base64編碼處理。XOR密鑰的偏移量為從緩衝區開始偏移1111個字元。

負責對文件名進行混淆處理的代碼為：