GitHub
Page cover

Week 7. Napper

TL;DR

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.

KEYWORDS

Naplistener, C#, Elasticsearch, reversing, Golang, AES.

REFERENCES

https://www.sslchecker.com/certdecoder

https://www.elastic.co/security-labs/naplistener-more-bad-dreams-from-the-developers-of-siestagraph

https://thehackernews.com/2023/03/new-naplistener-malware-used-by-ref2924.html

https://github.com/mooncat-greenpy/Ghidra_GolangAnalyzerExtension

https://gist.github.com/fracasula/38aa1a4e7481f9cedfa78a0cdd5f1865

ENUMERATION

Port scan.

> nmap $target -p- -T4 -Pn --open --reason
Starting Nmap 7.93 ( https://nmap.org ) at 2023-11-12 04:32 EST
Nmap scan report for 10.129.160.140
Host is up, received user-set (0.098s latency).
Not shown: 65532 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE   REASON
80/tcp   open  http      syn-ack
443/tcp  open  https     syn-ack
7680/tcp open  pando-pub syn-ack
 
Nmap done: 1 IP address (1 host up) scanned in 118.89 seconds

Enumerate the open ports.

Inspect the certificate with https://www.sslchecker.com/certdecoder

Take note of the subdomain app.napper.htb. We can enumerate further subdomains with ffuf

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.

https://www.elastic.co/security-labs/naplistener-more-bad-dreams-from-the-developers-of-siestagraph

https://thehackernews.com/2023/03/new-naplistener-malware-used-by-ref2924.html

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.

  1. Namespace must match filename.

  2. It must contain a Run class.

  3. Create a constructor and place the shell code inside, so it is automatically invoked whenever an instance of the class is created.

  4. The main() point of entry will just call the constructor.

An example of the payload could be the following:

Compile with mcs, remember the filename must match the namespace.

Encode base64 the resulting binary.

Send the payload with Burpsuite, don't forget to URL-encode to avoid problematic characters.

A reverse shell for user ruben is received.

SYSTEM

Enumerate the system.

Enumerating with winpeas.exe, a binary is discovered in a folder for which we have write access.

In this folder there is also an .env file containing credentials.

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:

  1. If you use Ghidra, look for a Golang extension to assist in decompiling process.

  2. The binary reads environmental variables from the .env file.

  3. In the source you can find credentials for elastic user.

  4. 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.

Once both parameters are retrieved, we can decode the backup user password. For this, it is needed to create our own go script, one good starting point can be found here: https://gist.github.com/fracasula/38aa1a4e7481f9cedfa78a0cdd5f1865

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

Start a listener on port 9000 and use runascs to run the shell.exe payload as backup user.

You are root.

PreviousWeek 6. CodifyNextWeek 8. Hospital

Last updated