This is a Windows 10 pro workstation used by a group of malware researchers. For their investigations, they run a blog to post their findings and an internal Elasticsearch server. They are currently researching the Naplistener malware and it seems that, unfortunately, the software has infected the machine leaving it exposed to external attacks, this can be leveraged for user foothold. Regarding escalation, reversing a local binary written in Golang allows finding credentials for local administrator.
We have found another subdomain called internal.napper.htb. If we browse it with Firefox, a login web page appears.
Browsing the login site with Burpsuite, we see it uses basic authorization. In this type of authorization the credentials are sent in base64. The next step would be to find valid credentials for this site. In the blog app.napper.htb there are information about how the basic authorization works.
USER
We find the procedure they followed to configure the server, including the default password used.
Trying these credentials example:ExamplePassword in the login page, we are given access to the internal area. Inside the restricted area we find out there is an investigation ongoing on a malware called Naplistener. Doing a search in Internet, we find out 2 good resources to have a basic understanding of this malware.
In summary, it is a malware written in C# which starts an HTTP listener in the infected machines. Once the listener is running, if you send base64 encoded C# payloads to certain endpoint, it will be executed in memory. It is designed to masquerade and evade network-based detection methods, for this same reason, it will only process requests sent to /ews/MsExgHealthCheckd/, in the sdafwe3rwe23 parameter. Any other tries to interact with Naplistener will be responded with a 404 code.
To verify if Naplistener is running in the host, we send a base64 aaa payload to the endpoint and it is responded with OK 200. Therefore, Naplistener is running in the system.
We conclude that if we send a base64-encoded C# reverse shell it will be decoded by Naplistener and executed.
Next step is to download a C# TCP shell from http://www.revshells.com. Bear in mind it cannot be used off-the-self, it needs some modifications.
Namespace must match filename.
It must contain a Run class.
Create a constructor and place the shell code inside, so it is automatically invoked whenever an instance of the class is created.
The main() point of entry will just call the constructor.
We also find a local service running on port 9200, doing some research, we find out this port is owned by Elasticsearch. Place a chisel and forward port 9200 to Kali.
Browsing the site locally with Firefox https://localhost:9200, an Elasticsearch login website appears.
Next step is to decompile the a.exe file with a reversing tool. The file turns out to have been written in Golang.
Conclusions after inspecting the source code:
If you use Ghidra, look for a Golang extension to assist in decompiling process.
The binary reads environmental variables from the .env file.
In the source you can find credentials for elastic user.
The binary updates password for user backup, which is written in a JSON field called blob
Use the elastic user credentials to log into the Elasticsearch site. Query thehttps://localhost:9200/_search endpoint to find the blob parameter, which contains the encoded current password for user backup and the seed used to AES encode it.
Also, bear in mind that password for user backup is updated periodically.
Once the password is obtained, we just need to log in as user backup. There are no open ports 135, 445, 3389, 5985, so Impacket, rdesktop and evil-winrm are discarded. A good alternative could be runascs with a payload generated with msfvenom
