The 24th of January, AMOSSYS and Malizen organised a blue team CTF, for the SupSec seminar. In this blog, we explain how to solve the challenge.
Context
The startup MonkeyMoney is trying to go big on the NFT market with the implementation of a marketplace to sale and exchange NFTs, and a disruptive approach through the use post-quantum cryptography to secure NFT tokens. Wishing to move fast in the highly competitive NFT ecosystem, MonkeyMoney had to make compromises in terms of security when building its information system. Moreover, the aggressive marketing approach employed by MonkeyMoney has resulted in strong oppositions from the NFT community, and has aroused the curiosity of some groups of attackers...
On the day of the attack
On January 19th 2023, around 3:00 pm, the information system of the startup MonkeyMoney stopped working altogether. The employees were no longer able to log on to their workstations. The cause seemed to be that the domain controller was not responding. An administrator logged in locally to the Active Directory server, and found this message on the screen:
The investigation
The participants were given the role of an analyst within the incident response team of the CERTIFLEX company, called to help on this breach. The startup MonkeyMoney was able to extract the different logs of the information system during the presumed period of the attack. These logs were provided to the participants for analysis, in order to investigate and understand the attacker's path.
To help them in this mission, the MonkeyMoney company gives the following network topology diagram of their information system to CERTIFLEX:
Additionally, the logs were available in different forms:
as raw syslog files
through Kibana (Elastic)
through Malizen Investigation Platform
If you want to know more about the investigation through the raw syslog files and Kibana, look at this blog post from Amossys:
Dataset generation
The key tool for the preparation of the challenge is the Cyber Range, developed by AMOSSYS. The Cyber Range is the technology underlying the M&NTIS Platform. It allows simulating an entire corporate network, launching attack scenarios, emulating user actions, etc., all while collecting traces, mainly under the form of network captures (PCAPs) or system logs.
General information before starting the challenge
First of all, we have to take into account the fact that we try to observe attacks through logs, which are often heterogeneous and only gather fragments of information. Attacks are more or less well captured by logs, making them more or less noisy and therefore more or less difficult to detect. Sometimes it's just hard to understand. Even if ChatGPT is great, not all computers speak human very well yet ...
How did our PhD student solve the challenge using Malizen?
He started from the statement data that was provided ... We know that there is an IDS in place, so if there was an attack, there is a chance that the system detected something. So we start there.
A few cards (event.severity to look at the alerts from the IDS, and source.ip and destination.ip to identify the victim and the attacker), a few filters on the severity (by clicking on the value “1.0” on the first card) of the events and in no time, we discover the name of a CVE. This one corresponds to an attack procedure using the **log4j** vulnerability, which is well known to the general public by now.
We then know that the web server of the MonkeyMoney company was infected through this, but what to do from there? Like in a zombie movie, we look at who patient 0 (in our case, the web server on 192.168.101.3) has been in contact with and look for traces of infection there. We then find some suspicious uses of powershell. Then quickly a file called **payload.ps1** sent on the webserver by an external machine. We found our attacker!
Now let's find out who else this attacker is communicating with on our network (by creating a filter with “source.ip = 91.218.114.3”) ? Well, in particular with the Active Directory, the company's centralised identification and authentication service... This is very suspicious! It also talks with a client located in a place of the network which should not be directly accessible. One wonders if he got his access to the AD from there.
When creating the cards recommended by Malizen’s co-pilot, we quickly realise that more noisy resource discovery attacks have been made. The attacker retrieves information such as the open ports of the machines, the system configurations, the installed applications, the users... And all this information is returned by encoded powershell commands. Our attacker left some traces ; they always do!
On the client machine several downloaded files inform us that the attacker's next goals are to establish persistence on the network and to compromise the database administrator's account. With the information discovered beforehand, a classic use of the **zerologon** exploit, offers our attacker access to the Active Directory. He instantly abuses his newly acquired powers.
For his final attack, and now that he has full powers, the attacker spreads the **ransomware.exe** file to all machines and bam, that's the end. The interesting thing is that there is no complicated code in the dark, nor hours of work upstream, these are exploits that can be found freely on the net. All it took was a vulnerable architecture and anyone with minimal cybersecurity knowledge could have done it.
Conclusion
With Malizen, our PhD student was able to quickly find the steps of the attackers. And during the 2 sessions of the SUPSEC challenge, the students were also able to find and explain the attack scenario ! Out of 32 participants and the global top10, 7 were using Malizen compared to the others that used Kibana.
Stay tuned, the dataset will soon be online on our community version.
