If you haven’t seen part 1, it provides an overview of the service as well as the domains and IPs supporting the infrastructure.

Continuing my analysis of the Hangro VPN IPs and service I started querying the IPs directly as well as started taking some first steps towards reversing an older sample of the Hangro VPN client. Using OpenSSL as well as a few other tools provided some additional details on how the VPN functions. This post dives further into how the Hangro client authenticates, as well as some recent sightings of Hangro in the wild.

Handshake Failures

Across the four IPs 175.45.176.21, 175.45.176.22, 188.43.136.115, and 188.43.136.116 they all share a common certificate on port 7443. For the sake of brevity I’ve posted a few snippets throughout the post, the full certificate will be available at the end. Querying these IPs directly resulted in a handshake failure.

# openssl s_client -connect 175.45.176.21:7443 -tls1_2

CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 CN = hangro.net.kp
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = hangro.net.kp
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = hangro.net.kp
verify return:1

40B0FA76:error:0A00007B:SSL routines:tls_process_key_exchange:bad signature:../ssl/statem/statem_clnt.c:2306:

Certificate chain
0 s:CN = hangro.net.kp
i:CN = hrra2024
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384

v:NotBefore: May 27 03:39:46 2024 GMT; NotAfter: May 26 03:39:46 2029 GMT

We can see that the server responds with a certificate CN = hangro.net.kp and is signed by hrra2024 which could be assumed to be an internal CA. In this case, our query fails as OpenSSL doesnt have the full certificate chain and can’t verify the signature.

Reverse Engineering the Hangro Client

To get a better idea of how the VPN client works I started reverse engineering an older sample that I had. This resulted in several interesting findings into how the client authenticates:

• Local certificate retrieval. Before the connection to the Hangro server is initiated the client connects to 127.0.0.1 over a local socket on port 6279 to retrieve a PEM-encoded certificate

	push    offset cp       ; "127.0.0.1"
	call    ds:__imp_inet_addr
	mov     dword ptr [ebp+name.sa_data+2], eax
	push    1877h           ; hostshort
	call    ds:__imp_htons
	mov     word ptr [ebp+name.sa_data], ax

	push offset "-----BEGIN CERTIFICATE-----"
	call sub_4117A0

• Embedded private key. There’s also an embded private key in the client that is decrypted with the password 1234

        mov     ecx, 53h ; 0x53 * 4 bytes = 332 bytes
        mov     esi, offset aBeginEncrypted ; "-----BEGIN ENCRYPTED PRIVATE KEY-----"
        lea     edi, [ebp+Src]
        
        push    offset a1234         ; "1234"
        mov     eax, [ebp+lpMem]
        push    eax                  ; context with the encrypted PEM
        call    sub_424A30           ; decrypts the private key
        add     esp, 4

• Local certificate validation. Before the initial TLS handshake is initiated the client validates the certificate retrieved in step 1 locally and if it doesn’t pass the built-in checks the client will not attempt to connect to the Hangro server.
• GOST cipher references. There are multiple strings referecing GOST algorithms which suggest potential Russian influence. These appear several times where the client intializes and enumerates cipher suites

        "gost94"
        "GOST R 34.10-94"
        "GOST89"

• External authentication libraries. One of the DLLs imported FT_ET99_API.dll has several imported functions that suggest external authentication may be used. In addition there is code that tries to run USBToken.exe

        et_FindToken
        et_OpenToken
        et_Verify
        et_ChangeUserPIN
        et_CloseToken

Additional testing

With some more details on how the client works, the first thing that I tried was installing GOST cipher suites to see if that had any different results when connecting. This just shows that the sever currently doesnt support GOST:

openssl s_client -connect 175.45.176.21:7443 -cipher GOST2001-GOST89-GOST89
CONNECTED(00000003)

4080FA76:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake          failure:../ssl/record/rec_layer_s3.c:1605:SSL alert number 40

no peer certificate available

No client certificate CA names sent

SSL handshake has read 7 bytes and written 255 bytes

Verification: OK

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent

Verify return code: 0 (ok)

Generating a test certificate

Since I had a decrypted private key I attempted to generate a self-signed certificate to see if it would proceed further. In this case the handshake progressed beyond ServerHello but failed during the signature verification which confirmed that the server expects the certificate to be signed by hrra2024

error:0A00007B:SSL routines:tls_process_key_exchange:bad signature

Interestingly when using gnuTLS and digging into it further revealed the following which shows the Hangro server’s certificate was flagged for Client Authentication but is lacking the Server Authentication purpose

looking for key purpose '1.3.6.1.5.5.7.3.1', but have '1.3.6.1.5.5.7.3.2'

Is Hangro still used today?

The sample that I have appears to be a few years older but one thing that Ive been wondering is if Hangro is still in use. Trend Micro wrote a great blog that goes into detail about the link between Russia and the DPRK (thanks for the shout out!)

Several people actually recently wrote in and shared that the Hangro icon has recently appears on the site https://ps.ppokkugi.com

Even more interesting is the source code on the page that notes that the icon is a “service for visitors away from home”

<img src="/imgsrvc?i=hangro" title="조국으로부터 떨어져계시는 방문자들을 위한 봉사" onclick="openPage('오유!관리부에련락하십시오!')">

This seems to provide further support the idea that Hangro is a VPN client used by North Koreans overseas to establish connectivity back to the country.

Interestingly, as of around July 18 2025 the Hangro icon no longer appears on the site.

Going Forward

From this it looks like Hangro uses mTLS to support authentication as part of the VPN service and requires a valid certificate signed by hrra2024. I haven’t been able to find if the cert requested on the client on port 6279 is part of Hangro or a different service that needs to be running.

Based on what has been discovered so far and looking through some of the other files and a few packet captures it looks like Hangro is derived from SoftEther an open source VPN project maintained by the University of Tsukuba. The included driver that is installed matches with SoftEther and the traffic seems to be similar to the Ethernet over SSL option in SoftEther.

There’s also additional applications like a chat and mail program that are installed as well that could have some interesting information.

There’s still more to explore regarding Hangro’s capabilities. A third part is definitely going to be required to go over some of the functions in Hangro that may provide some additional clues as to what a user is able to access once authenticated. If anyone has any up to date samples that they can share please reach out. And of course if you’re a security company or a three letter agency feel free to reach out as well contact@dprkinternetwatch.com