Informed by T1G

I was enjoying my morning when I was prompted by T1G (alias) regarding a self-proclaimed Korean hacking group that managed to hack a "Security Researcher" in February. While I was not overly interested, I was curious about what had happened.

How it started

It seems the "Security Researcher" had been talking with a scammer named Jiffy and after identifying the individual was a scammer he decided to perform some intelligence by "IP Logging" Jiffy, while this was not a particularly professional move it had invoked fear into Jiffy as a result, Jiffy contacted some "self-proclaimed Korean hackers" which go by the alias PRG short for Pyongyang Research Group and informed them of the IP Log which took place by the researcher.

Phase one: Initial compromise of redacted[.]com

It seems Jiffy had informed the hackers of the researcher's website and the "Korean" group had decided to conduct a fairly long plan to successfully pwn the researcher. The alleged reasoning? PRG wanted an apology from the researcher to Jiffy. PRG knew they'd have to act if they wanted that and within the next moments, it seemed redacted[.]com was breached by PRG, however, the researcher had no idea how and this is exactly what PRG wanted. They wanted their prey to be discombobulated this leaves the research questioning how. It became a point of desperation, and mistakes are made in the process. The researcher for whatever reason did not imply the logic to review system-level logs and the web server logs to see how PRG gained access. Instead, the researcher openly admitted there were too many shells and he can't find "them" referencing PRG. Not knowing how the attackers gained access would bite the researcher, but, how?

Phase two: Fake IRC Chat Logs

Well, before we continue, they hacked redacted[.]com why did they not request an apology from the researcher? Well, you see, PRG must've hacked the site to prove a point and to invoke fear, not to get the apology. The website was not relevant enough to get the apology and PRG knew that, I believe the overall goal must have been to compromise the researcher's personal computer where personal data and other important information may've been at risk.

Now we have an idea of why there may've been a second phase, let's move on. The researcher was contacted by an unknown handle to imply that redacted[.]com was indexing a .weechat folder that contained IRC chat logs from PRG. While this is suspicious and most likely an affiliate of PRG attempting to bait him into viewing the folder, the researcher did not interpret this and instead checked the .weechat folder. Within that folder were IRC Chat Logs. The researcher downloaded the chat logs and was greeted with a discussion in Korean

The researcher must've translated the chat logs into English. While a lot of it was them talking about hacking a fairly large site that provides a putty download, at this time we have not identified if it was compromised or not. However, some of the chat logs below imply it was. (Translated to English)

Though you see, the period during the messages being sent seems as if it was copied and pasted so, take this with a pinch of salt and also take the fact of them being "Korean" as a pinch of salt rather than a fact, it may just be an OpSec or clout chasing thing. One strange thing is PRG linked a valid XSS on the domain of the subject which may have been a social engineering tactic to gain the researcher's trust and for him to view them as elite.

At the end of the logs, PRG mentioned the exploit was ready. They left some SSH credentials, logically thinking, this is all bait. Any researcher would want such an awesome exploit, right!!?? Exactly. And, sadly. The researcher SSH'd in moving us onto phase three.

Phase three: Fake 0-Day within a HoneyPot

After the researcher identified the SSH server, he directly SSH'd into the box. What was he greeted with

We can see there was an exploit.py and Litespeed the researcher thought the exploit.py was a 0-Day exploit for LiteSpeed which he believed was how his site was breached (that's what PRG claimed). The researcher downloaded the exploit.py and seemed to believe it shown here:

One guy ran it on a Parrot OS

Despite the failure, the researcher must've believed it as he couldn't boot into his VM so he resulted in running it on his VPS. Now, before we view the outcome, let's review the script.

Analysing exploit.py

Snippet of the code. The code seems to define a function called shellcode_construct() which constructs shellcode, which is essentially a sequence of bytes that can be executed as machine code. The shellcode seems to be constructed by manipulating certain ASCII characters, which are then converted to their corresponding hexadecimal representation.

The code also defines a function called command() which appears to execute a given command. The function takes a command string as input and returns True if the program should continue or False if it should exit. It seems to handle the cd command, which changes the current working directory, and any other command by printing the command to the console.

The code also defines a function called temp() which seems to take several arguments, including a protocol (http or https), a server address, an endpoint, and a padding length. It appears to define two internal functions called GET_request_execute() and POST_request_execute() which seem to execute GET and POST requests, respectively. However, these functions do not seem to be fully implemented and currently only return None.

Interestingly, the smash(content) function in the code is just a built-in eval function. The eval function takes a string as an argument, and it interprets the string as a Python expression and returns the result. In this case, smash(content) takes the content string, which is essentially the shellcode constructed by the shellcode_construct() function, and evaluates it as a Python expression. This is done to execute the shellcode.

Well, someone who didn't pay attention to the shell code and get the entire constructed shell code may fall victim to this. It's always good to be cauctious and check everything before running it, especially if it's off a random VPS server called exploit.py

Now, let's call the shellcode_construct() function and find out what the shellcode does.

We can see that we ran it and it outputted the shell code.

hmpq://<IP/VPS>

It seems the shell code generates this hmpq:// protocol that goes to an IP or VPS? Well, that's strange. I have never seen hmpq:// and that's because it's a non-existent protocol URI. Going through the source code, we can see the following.

This code replaces the letters "m", "p" and "q" in the string target_url with the letters "t" and "p" in a specific order. We now have http as it removed mq and included tp, neat little trick. They're making it seem as if they're exploiting a custom URI or something within Litespeed? Not sure, another useless social engineering factor.

Phase three: Final Pwnage

Well, after he ran it, the VPS got completely compromised and PRG managed to root the box. The researcher lost this fight to PRG. However, this was a very interesting attack. But one question remains. If they didn't have a 0-Day in Litespeed, how did they pwn him in the first place? Conclusion: A vulnerable file upload on redacted[.]com, the domain is down but we can validate it did have such functionality via the Wayback machine.

Finishing up

Enumerating the VPS, it's clear it's a honeypot. The real SSH port is 1338, and upon visiting the web server we can see this: "당신이 신뢰하는 대통령과 그의 최고 지도자 손자를 따르십시오!" which translates to Follow the President you trust and his top leader grandson! We also saw this /e endpoint which seemed to have just shown random code

Escaping the Honeypot was not possible, we were unable to use any mounting commands and many other helpful commands or just general harmless Linux commands such as "whoami". Weirdly, wget and curl were not an option either which most Honeypots would allow as bots/attackers will usually drop their bins via wget or curl. This just proves it was used to lure the researcher in and well, it worked. He fell for it, lol.

Besides that, we could not find much else. T1G believes he may have some intelligence on who's behind this (personally, not just handles) and we do have a list of the hacker's handles but I will redact those for now.

Overall, this was extremely interesting. It seems PRG was very desperate to successfully pwn him, we also checked the Wayback machine and can confirm there was a defacement of the researcher's site. It had stated: 당신이 신뢰하는 대통령과 그의 최고 지도자 손자를 따르십시오! 빌어먹을 영국의 적 which translates to "Follow the president you trust and his supreme leader grandson! British Enemies" seems that the "researcher" was British most likely.

PRG pwned the researcher more than once thus it's a win for them.

Credits to: S1G, T1G and Zen for researching, reversing and identifying what happened.

Zen's Twitter: twitter.com/zenaker