#
This room will serve as an introduction to the world of
intrusion detection systems (IDS)
and cyber evasion techniques
We first need to
Deploy the target machine and create an account
on port 8000
you can get your IP by running ifconfig and looking at an interface like “tun-0” – the one connected to the VPN
Give that IP to the register form and any username
Once we register we will get an access token which we will need
for logging in in the future and now
Before we get started i’ll quickly explain whats going on by summing up Task 2 intro:
IDS Systems usually automatically detect suspicious activities in
a network – IDS will also inform you about it, but won’t try to
prevent it – this is what IPSes are for (intrusion prevention systems).
once an incident is detected, the IDS will generate an alert
and then forward it to your logging or data visualisation platforms like [Graylog] or the [ELK Stack]
- In my experience, for example, i’ve seen ELK stack used very often.
In this tryhackme room we have two examples of IDSes attached to the machine
1.) Suricata = NIDS (network-based) – monitors the network activity
2.) Wazuh = HIDS (host-based) – monitors the host activity
Another note about Wazuh is that its a Host Intrusion Detection System That can be considered as an IDS and an IPS capable of monitoring WebApplication Firewall. Also it is presented by its creator as a SIEM (Which is a security information event management software)
But in this scenario we will be looking at it just as a Host Intrusion detection system.
Anyway Both of these IDSes implement signature detection methodology (signature-based)
This is also the answer to our first question (What IDS detection methodology relies on rule sets):
Its “signature-based detection”
Lets jump to task 3
So NIDS monitor networks for malicious activity by checking packets
for traces of activity associated with:
Malware C&C activity, scanning, exploitation, data exfil and more
Fun fact is
NIDS are more prone to generating false positives than other IDSes,
this is partly due to the amount of traffic that passes through
even a small network
the difficulty of building a rule set that is flexible enough to reliably
detect malicious traffic without detecting safe applications
can be high.
NIDS can be deployed on both sides of the firewall
But mostly, as well as in this scenario which is relevant to us
they are inside the LAN.
For this, demo the IPS mode is disabled so you are free to run
as many attacks as you want. We just want to see how IDS reacts
and how we could bypass it. If IPS was ON we wouldnt be able
to do half the stuff – so for learning purposes its off.
A history of all the alerts generated during this room is
available at http://xxxx:8000/alerts
What widely implemented protocol has an adverse effect on the reliability of NIDS?
HINT: It’s in the corner of your browser and starts with a T
Since the corner specifies HTTPS or HTTP on some sites,
and they mentioned T its then its most likely ssl or tls
- ofcourse since it starts with T its TLS
- If you dont know – simplified explaination is :
TLS is used to encrypt the traffic
Experiment by running tools against the target and viewing the result alerts. Is there any unexpected activity?
Then we can run an
nmap -sV 10.10.38.7 scan
and surricata should pick it up on /alerts
You should be able to see ET SCAN NMAP SCRIPTING ENGINE entries
You can click on any entry to get additional data
After this the challenge is talking about recon and evasion basics in task 4 – ill shorten the text:
To make the scan more legit and less intrusive in the eyes
of an IDS – we can run the scan with script args http.useragent to change the user agent to any other:
nmap -sV –script-args http.useragent=”Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0″ 10.10.38.7
Use a user agent from your browser for example
(When running this SCAN the interface seems to show us a bit different
entries from the previous one which noticed the scanner is NMAP)
Since IDS will still detect everything, and we want to run more complex
scans to do our Recon decently – we need to learn more about evading IDSes
One option is to use the STEALTH SCAN -sS
Usually : the more you evade an IDS the less information you will
be able to retrieve – but we’ll try to get right in the middle
It seems that SURICATA also notices the weird activity that happens
when we run a stealth scan – we still got some opened ports, but
also we noticed SURICATA noticed the activity as severe (3rd level)
It still didnt detect we are using NMAP tho – so thats something.
The room creator also mentions that usually targets that are publicly
exposed have some sort of rate-limiting tools like fail2ban and often
have better security since, if they are popular, they probably faced
some attacks – but he also mentions that your scans will be less
interesting to the IDS analyzer since other attacks may be running
-which are bigger than just recon
What scale is used to measure alert severity in Suricata? (–)
if we look into our alerts we can see its 1-3
How many services is nmap able to fully recognise when the service scan (-sV) is performed?
Since the question specifies “fully recognize” the answer is 3
Moving on to task 5 Creator of the room also mentions nmap isnt the only one that has evasion
options when talking about IDS evasion. There is also NIKTO scanner.
When we run
nikto -p 80,3000 -h 10.10.38.7
we can see SURICATA detects a lot of stuff – this is due to
nikto being more agressive than nmap.
(we can see that there were attempts of exploits (they arent really)
and acessing sensitive directories by nikto – all of that on alerts’s last page)
Lets stop NIKTO and look at an option like this :
nikto -p 3000 -T 1 2 3 -h 10.10.38.7
(since we can see A BUNCH of results now in SURICATA)
This option shows us we can run only certain scans – or to be more
exact for certain vulns – T stands for tuning, and 1 is
Interesting files option – 2 is Misconfiguration and
3 is information disclosure
These can be useful and tweaked however you like them.
- Now lets look into evasion options for nikto
We will provide 2 additional arguments
One for a user agent – we can use the same one as before
and -e for evasion modules 1 and 7
Funnily enough this will not bypass victim’s IDS – suricata can notice
this as suspicious activity. It wont notice perfectly correct whats
going on as it did before – but it will generate a bunch of alerts
Creator of the room also leaves an interesting tip for us:
if you were to somehow gain access to a large enough botnet it may be possible
to simply overwhelm the target IDS or IDS operators by flooding the system with
alerts from many hosts and attack vectors and thus conceal the real attack
This strategy may also simply crash any IDS that’s protecting the service if enough packets
are sent though, most IDS use some form of a limiter
Nikto, should find an interesting path when the first scan is performed, what is it called?
The first path it found: /login
In the meantime while its scanning we can solve the other questioN:
What value is used to toggle denial of service vectors when using scan tuning (-T) in nikto?
Not evasion options – tuning options therefore : 6 (look at -H)
Which flags are used to modify the request spacing in nikto? Use commas to separate the flags in your answer.
as we can see in the table in this writeup, its 6,a and b
Lets see if our scan is done for the first question to confirm /login is the path nikto found – and it didn’t.
Something must have went wrong cause its stuck here already for a long time so im just gonna assume machine needs
a restart. On my first time solving the challenge it worked well and it showed me a directory /login. Let’t continue since
my nikto froze anyway.
Next we move on to OSINT segment, which covers a bit more passive recon
Most forms of OSINT are affectivity undetectable and thus are extremely effective against IDS however,
there are limitations as by its nature, OSINT relies on the target to disclose information
which may not happen
-A good example of this is the Wireguard VPN protocol which will not respond to queries
unless they come from an authenticated source
Information gathering can be then done using:
Shodan (as well as using shodan’s honeypot rating tool – you can see if something is a honeypot there and its a useful thing)
Search engines (and using special tags like filetype:)
Recon-ng
Whois lookups on sites
And more
Obviously, you can also gather info based on the stuff you see like the source code of the website, type of requests and params
and similar
(like if you see wp-content in a url in the source code we might assume victim is running wordpress)
(Or similar stuff)
What version of Grafana is the server running?
go to port 3000, it takes u to /login, look at version.
v8.2.5
What is the ID of the severe CVE that affects this version of Grafana?
Google it, navigate to CVEdetails, CTRL+F ” 8″ – try one of
those 4 cves, CVE-2021-43798 works.
If this server was publicly available, What site might have information on its services already?
Shodan (who else 🙂 )
I should probably make a video on shodan too
How would we search the site “example.com” for pdf files, using advanced Google search tags?
site:example.com filetype:pdf – easy google dorkz
Let’s move on to the next task.
- Introduction to rulesets mentions that
Rulesets of IDSes have to be kept up to date to catch the new exploits
that are floating around the internet. - Developing rules is hard and another problem is the accuracy of the
ones that are developed
In this case, we have identified that one of the target assets is affected by a critical vulnerability
Since its been a while since this vulnerability was found
and exploit developed, we can expect Suricata to detect
the activity. Lets try this out:
Download the exploit and run it.
If we run the exploit we’ll see that it actually works
with /etc/passwd !!!
Then lets see alerts and notice we didnt get detected
weirdly enough this IDS didnt get the most recent updates
or to be more specific ones covering this exploit. If we look at the timestamps of
events we’ll notice it didnt really detect anything – also yes timestamps are different than my time for about 2hrs
because of time zones.
What is the password of the grafana-admin account?
Lets look at the hint first and after some searching on google
“grafana primary config location”
We first found a lot of empty responses but eventually we found this existing one:
python3 exploit.py -u 10.10.28.85 -p 3000 -f /etc/grafana/grafana.ini
so /etc/grafana/grafana.ini
when we access it we have the ###SECURITY####
part and the admin’s login
GraphingTheWorld32
Is it possible to gain direct access to the server now that the
grafana-admin password is known? (yay/nay)
yay -here is why, ssh is mentioned in the hint so lets try logging in:
sudo ssh grafana-admin@IP
and the pass GraphingTheWorld32
And since we have the access the answer is yes
Are any of the attached IDS able to detect the attack if the file
/etc/shadow is requested via the exploit, if so what IDS detected it?
if we request shadow SURICATA actually DETECTS IT
since source is “suricata” that is our answer.
Now let’s move onto the Host based IDS or HIDS
HIDS require agent installs on every host so they are harder to install
than NIDS
They monitor a bunch of stuff including
Application logs, system logs, state of the filesystem
,in the case of windows OS stuff like registry
and a bunch more
This can be hard to manage, but a solution for that is
Ansible – the automated deployment mechanism for this problem
Difference between NIDS and HIDS is mostly in the
type of activity they can detect – HIDS doesnt usually
have access to the log of network traffic, its more
useful for agressive stuff which we’ll show soon.
So as i mentioned Since Suricata is a NIDS, We can conclude Wazuh is a HIDS.
Wazuh should be able to detect that an insecure SSH
connection attempt was made to the server but will not
mention the connection to the HTTP server, unlike Suricata
Wazuh will create thousands of alerts as it will detect each 400
error code created as a result of running the vuln script
as this attack creates entries in the error log which,
is one of the sources that Wazuh reads from if it has been
configured too.
Lets run nmap -sV scan and see the logs
It doesnt seem like it detected anything for SSH from -sV scan, but that’s fine
It happens sometimes, just restart the machine if you want.
And if we run
nmap –script=vuln scan then
wazuh should create a bunch of alerts since
it will notice a lot of 400 error codes
which are written in a log from which Wazuh reads
Lets solve the questions now:
What category does Wazuh place HTTP 400 error codes in?
if we look at our alerts we will see the category is “web”
-refresh the machine if it doesnt show
Play around with some post-exploitation tools and commands and make note of what activity is detected by Wazuh; compare it to the activity that’s detected by Suricata
basically just login and try to privesc with linpeas (python -m http.server 8000 it to the victim)
So download linpeas to your attacker pc, host a python server and wget linpeas to the victim pc using your IP and port you gave
the python server.
After that Chmod it
And then run it
The only thing we are really interested in and it looks really tasty is the Docker vulnerabilities.
If we take the suggested URL for the vulnerability and navigate to it we will see that the site is missing,
dont worry just google it and find the right result (in this case by the same site).
Here we’ll have clear instructions for priviledge escalation under the title Mounted docker socket escape.
So we can run the privesc command but before we do we can see that the original command uses ubuntu:18.04 as an image
We don’t have that so we need to pick one of ours by running “docker images”
Im going to pick the suricata one so just modify the command how it fits.
And BOOM. We just powned the system. We Have root.
Lets look at the alerts. It looks like suricata generated some alerts but they seem to be tied to NMAP which is odd
Privesc was done and none of them reacted – maybe they were supposed to but something just bugged out.
so now lets continue with the challenge
- The challenge then talks about priv esc techniques and recommends getting linpeas, which we did do and it worked
great. I downloaded it to my machine, ran a python server and downloaded it to the victim machine from my machine
as thats always available even if the machine doesnt have outside interent connection. - after running linpeas it was clear docker was the danger. Looking at wazuh the severity was 5.
What tool does linPEAS detect as having a potential escalation vector?
as you remember it was docker
Is an alert triggered by Wazuh when linPEAS is added to the system, if so how severe is it?
It doesnt look like it did generate an alert this time, but last time it worked and it had severe level 5
Next task (the task number 10) talks about privesc method which we already know since we already
did a privesc to root. It shows a small difference in commands we ran but it doesnt matter because ours worked perfectly.
Perform the privilege escalation and grab the flag in /root/
So thats easy since we already have root, just navigate to root directory and cat into root.txt and we have the flag:
{SNEAK_ATTACK_CRITICAL}
Now we can move on to the
ESTABLISHING PERSISTANCE
task.
Let’s move on to making sure we are persistant on this machine.
You could:
- add a public key that we control to the authorized_keys file at
/root/.ssh/. This would allow us to connect to the host via SSH without
needing to run the privilege escalation exploit every time
(generate keypair with ssh-keygen) - Wazuh has two configuration modes, local and centralised in this case,
the HIDS agents are setup locally and the config file can be found at
/var/ossec/etc/ossec.conf . This file lists all of the data sources that
are covered by HIDS in this case - Docker monitoring is available, but not turned on
so we could: install a backdoor into one of the containers that are hosted
by the system. This would be difficult to detect without additional
container monitoring and scanning technology. - Credentials for a docker registry could either be phished or
extracted from /root/.docker/config.json as, this location stores the
credentials used with the docker login command in plaintext - We could modify an existing or new docker-compose setup
Since the challenge wants us to establish a backdoor by abusing docker
we can do this perform the last option they explained :
So to preform the last option append the following to a new docker-compose.yml file (inside /root/.docker/):
Also dont forget to change the IP.
This will create a new docker container using an image that’s
already available on the system, mount the entire host file system
to /mnt/ on the container and spawn a reverse shell with python
So we also have to listen on the port 4242 before we get the shell:
nc -lvp 4242
Then start the new docker compose on the victim machine by:
docker-compose up
And as you can see we have a root shell 🙂
If you get syntax errors its cause you didnt copy it right
If you get the “cant find suitable configuration file” error that means you didnt make a file called
docker-compose.yml OR the text you copied inside it isnt right
So There we go it works great
Ideally i wouldnt even abuse docker, i would just go with an ssh connection to the
root user with /root/.ssh and id run sshkeygen but this is fine too
And in the end of the challenge there is a conclusion that thanks us for playing.
And thats all for today. Hacking this machine was very fun and we learned a lot of stuff about IDS-es and
how they work.
So Thank you so much for watching and have a nice day.
