Yesterday various tools, documentation and intel was dropped on Telegram. Another quick analysis can be found on https://misterch0c.blogspot.com/2019/04/apt34-oilrig-leak.html the blog describes Poisonfrog and the HighShell and HyperShell webshells. This blog looks at another webshell (“base.aspx.txt”) that’s included in the dump. It caught my attention because it uses encryption and the in-memory invocation of C# code to hide the traffic and code execution from defenders.
Subverting detection
The reason this shell is interesting is that it uses encryption in order to perform communication between the panel and the attacker. Encrypted binary blobs are exchanged they can contain C# code that is eventually executed or the output of the C# code. The injected code can be anything and as long as it does not directly execute system commands it might be tricky to detect. A possible venue might be observing the dll’s loaded by “w3wp.exe”. The moment they use a PowerShell-less PowerShell trick its possible the “System.Management.Automation.Dll”, “System.Management.Automation.ni.Dll” or “System.Reflection.Dll” DLLs are observed. This is guesswork and has to be verified in a test setup.
Encryption & signing
The binary blob thats being passed is not just encrypted but also cryptographically signed with RSA. The attacker has a private key thats used to verify the integrity and identity. Next to this the attacker has a separate GUID that points to a file on the attacked system containing the symmetric key for decrypting the payload. The process is like the following:
Attacker sends: EncryptedSource, signature for the EncryptedSource, EncryptedParameters for execution and a signature for the key (ks). The attacker cookie contains A GUID which is the filename of the symmetric key. WebShell creates an RSACryptoServiceProvider using the public modulus and exponent. WebShell uses the GUID to load the symmetric key (used for decryption of the payload.) The signature of the EncryptedSource is verified using the RSACryptoServiceProvider The signature (ks) of the symmetric key is verified using the RSACryptoServiceProvider EncryptedSource and the EncryptedParameters are decrypted using the symmetric key The DecryptedSource is compiled in memory The compiled object is invoked using the DecryptedParameters The output is then encrypted using a newly generated symmetric key The newly generated symmetric key overwrites the previously stored symmetric key (of which we know the GUID filename) The newly generated symmetric key is encrypted using the RSA public key The symmetrically encrypted output and asymmetrically encrypted key are sent back to the attacker
Usage
It’s unclear if the dumped list of webshells actually us the webshell described in this blog. Seeing as some webshell documentation contains public and private keys its a really possibility this is the webshell of choice.
Another interesting fact about the webshells is that most of them are located inside of “/owa/auth/”. It’s interesting to see if the APT34 group possesses a 0day for Exchange or rather it just likes to hide their webshells inside this folder. Another document was found that describes the exact location on the Windows file system (“C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\”) lending credence to the idea that they like hiding there.
As mentioned before there’s a real chance we messed up with the specifics of the cryptography usage (please contact me for any corrections). Still it’s pretty cool to see a WebShell that deviates from the boring “system($_GET[‘a’]);” standard.
Thanks to @LeandroNVelasco for helping me figure out the execution/encryption flow.