Final Reflection

These past 4 weeks, I undertook the Summer Studio, Cyber Security an Offensive Mindset. The Studio method was proposed a means too incorporate intensive self-learning, collaboration and research to reach the 5 learning outcomes as indicated below. This studio focused on developing the ‘offensive’ from the security perspective. It introduced students to the ins and outs of the security world especially its lack in modern systems which was exemplified by the inclusion of industry professionals from well renowned firms. These professionals shared valuable experience and knowledge on a variety of topics, which allowed students to broaden their horizons.

I decided to take the subject as I believed it was a means to at least achieve a core foundation in the security industry. Previously I’ve attended several seminars hosted by the Cyber Security Society which were a useful introduction, however at that stage, my understanding wasn’t entirely set in stone. Luckily, having a background in networking helped a lot in enumeration as I was able to understand basic addressing and protocols. At the beginning of the Studio, we had to come up with a list of objectives that we wanted to achieve by the end of the studio. These objectives were to ensure the work we put in would evolve into something that could be taken away, whether you passed or not. Mine were the followng:

  • Clearer job path
  • Portfolio for future employment
  • In depth technical knowledge
  • Improved research skills
  • Insight from the CSEC members
  • Enhanced time management

SLO 1 - Engage with stakeholders to identify a problem

Throughout the studio, we have had the opportunity for industry professionals to give a talk on particular topics. The topic is aimed at identifying a particulat issue in cyber security whether it be technical or human-oriented. The following is a list of the professionals that graced us with their presence:

  • Week 1: Rob Mitchell - Gitlab
  • Week 2: Luke Fuehrer - UTS CSEC - Security Consultant
  • Week 3: Deloitte Cyber Security Team
  • Week 4: Ruben Thijssen - Symantec

Rob stressed the notion of social engineering. Essentially, humans are the weakest link to a firms infrastructure. This is due to the fact that as emotional beings, we tend to fall quite easily for phishing attacks, which involves impersonating another entity in order to maliciously capture the details of the victim. An example he gave us was the ILOVEYOU email.

Luke gave the studio a lecture on the XSS vulnerabilites in web application security. He gave some background to such applications as well as explaining what XSS is and how it works. We had to research an XSS attack and common mitigation strategies. However, a common theme was the confusion between them and so he provided us with a neat diagram as displayed below:

The Deloitte team offered an interactive aspect to their talk by inviting us to break a box that they have developed themselves known as Piper. At that time, I wasn’t able to complete it as I wasn’t comfortable with my skill level. Apart from that, they covered several vulnerabilities including social engineering, XSS, database vulnerabilities alongside a Red Teaming engagement.

Ruben’s talk focussed on reverse engineering using a tool called Binary Ninja. He didn’t give a lecture per se but directed us to a website that hosted several challenges with increasing difficulty. These challenges would reveal certain software vulnerabilites to reveal the flag. Below are my notes from the talk:

SLO 2 - Apply design thinking to respond to a defined or newly identified problem

Creative thinking is not only important in traversing a system but also demonstrating how you got into that system in the first place as well as the theory behind cyber security attack vectors. Throughout the studio we had to make several presentations. This was to improve our ability to educate our audience in a professional and creative manner and respond to an identified problem. They also ensure that our communication skills were up to scratch by the time the Final Expo came around. The presentations that we gave was on the OWASP top 10, John the Ripper as well as the final at the expo.

This problem was in the form of a statement that we indiviudally articulated at the beginning of the studio. My initial draft of the statement wasn’t taken very well as it was too broad and not defined properly. In response to the feedback I adjusted it to “How can we educate security staff in a corporate environment?”. The design thinking undergone to satisfy this SLO is used to respond to this statement.

Unlike other studio’s where the portfolio was maintained in a document format, we developed our own statically generated websites where we would maintain blog posts of weekly sprints. This blog was a creative means of noting everything we did including how we were solving our problem statement as the weeks progressed.

SLO 3 - Apply technical skills to develop, model and/or evaluate design

Coming into the studio, my techincal skill was very little to almost nothing, especially in comparison to the guys from the Cyber Security Society. The way in which the studio went about teaching us was to simply guide us in the right direction to undergo our own research in vulnerabilities and exploiting them in order to build the foundation of breaking into vulnerable machines. Since I wasn’t the only one in that position, we were first introduced to the basics via OvertheWire, a beginners platform for learning a gamified version of hacking. By week 3, we were tasked with reaching Bandit 30 and Natas 15, substantial enough to continue to further research. Below are some of my handwritten notes:

The conecept of breaking into boxes wasn’t brought about until Darshil’s demo of Pentester 1, a boot2root machine hosted on Vulnhub. That demo essentially secured the foundational mindset to the tools and avenues to take to traverse the box. From there, I continued to research walkthroughs of other Vulnhub boxes such as Matrix and Necromancer. From there, I pivoted to Hack the Box walkthroughs most notably by the Youtuber known as Ippsec. The boxes I looked at were Blocky and Popcorn, which were basic enough so that I could understand the methodology. The OWASP Juice Box was an extra vulnerable machine that was given to play around with to test where we were at with our knowledge.

SLO 4 - Demonstrate effective collaboration and communication skills

As a security professional, technical knowledge is only one side of the coin. The skill to communicate the impact of security issues on a business level is highly sought after. This was highlighted with great importance in the Studio through formal, high level writeups that mirror that seen in security certifications such as the OSCP. This industry skill is further highlighted in the Engineers Australia Competency Standard where a key skill of competent engineers is highly developed communication.

Another method of collaboration was the use of Microsoft Teams . This tool was introduced at the beginning of the Studio in order to connect that the entire class in a chatroom. It also allowed the creation of individual teams. Each team can take advantage of the planner which can be used to organise tasks and completion times.

One of the core components of the Studio was the Scrum and Free-for-all sessions. During these sessions we would communicate with different members of the class and ask each other about the work we’ve undertaken since the previous session as well as any challenges that faced, how we overcame them and what to expect in the future. This was a valuable means of collaboration as it allowed the perspectives of others to be shared. Many students I felt at some point would’ve experienced some degree of imposter syndrome, where they feel that their skill is far inferior to that of their peers. These sessions would’ve helped to calm the nerves and reinforce the notion that the majority started from nothing, as seen at the very start.

SLO 5 - Conduct critical self and peer review and performance evaluation

Self review is a core concept of this Summer Studio as it emphasises the progress made throughout. After each week, we are required to give an evaluation of our own performance, good or bad and give pointers on any possible imrovements. We also benefit from the the weekly feedback given to us by our tutors. Each week, they will post the result of the previous week’s submission followed by some feedback to help improve the submission for next week, below is an example of my feedback from sprint 3:

Similarly, we engaged in Scrum and Free-for-all sessions for peer review. This way we are able to compare the the progress of other students and from their be able to reevaluate our own. I feel these sessions really helped in doing so.


In essence the Summer Studio has been an absolute roller coaster for me. However, possibly the some of the best time I’ve enjoyed at UTS thusfar. It meant striving towards the goals I had initially set for myself:

  • Clearer job path
  • Portfolio for future employment
  • In depth technical knowledge
  • Improved research skills
  • Insight from the CSEC members
  • Enhanced time management

Whilst these weren’t necessarily polished by the end of the Studio, they definitely saw improvement.

The lack of knowledge in security at the start had be doubtful that such a path would interest me in the future. A further developed foundation has meant that I can comfortably perform basic enumeration and exploitation of a vulnerable system. This new found knowledge has given me the confidence and the courage to explore further opportunity for self-learning as well as heading into Cyber Security roles that require such knowledge as a basis for the application process.

The website that I had developed of the course of the Studio as quoted by Larry a “resume on steroids”. It is most definitely the most valuable asset to be pulled away from the studio.

Time management was a major issue for me during the Studio, unfortunately it hasn’t improved all that much. I strive my best to do as much work in little time in order to maximise efficiency where I can. The intense nature helped with that and enforced good organisation to stay on top of a hectic workload in such a short period of time.

Reflective Statement

The learning journey undergone over the Summer Studio has been second to none. As a group, we have had the profound opportunity to meet industry professionals that shared their insights to look at differing vulnerabilitie in Cyber Security. We have applied design thinking through the use of creative presentations and blog entries in order to solve our own problem statement, “How can educate security staff in a corporate environment”. This was highlighted by covering topics such as the OWASP top 10 and tools such as John the Ripper. We have applied diligent self-learning alongside demonstrations to development the technical knowldge to begin rooting our first vulnerable machines. Collaboration and communication were incorporated via scrum and free-for-all sessions to share the learning journeys with others as the weeks progressed to help reevaluate our own methods of study. Finally, self and peer review through the weekly scrums/free-for-alls as well as the feedback from the sprints allowed each of us to reevaluate our own progress and improve on our learning journeys in developing a true “offensive mindset”.

Sprint 1

Hi, my name is Harry Louskos and I’m currently taking 41151 Summer Studio - Cybersecurity: An Offensive Mindset. I’m enrolled in the BSCiT course as a final year majoring in Internetworking and Applications submajoring in Network Security. Whilst my interests are not entirely within computers, I do find myself leaning towards the networking field as provides a means of developing a physical and software-based system that, when they break are quite enjoyable to fix. In terms of security, wireless and web app hacking seem to draw my attention the most as whilst it creates an outlet to challenge my problem solving and creativity, they are also the some the most enjoyable to break.

My motivation for the studio revolves around the fact that I simply do not know nearly where in security I want be. I also feel that my knowledge is nowhere near as complex as anyone else’s especially the members in the CSEC Society that show immense aptitude in the field. By completing the studio, I’m hoping that my path towards the workforce becomes clearer and that my knowledge expands well above my current stage.

What do I want out of this studio?

  • Clearer job path
  • Portfolio for future employment
  • In depth technical knowledge
  • Improved research skills
  • Insight from the CSEC members
  • Enhanced time management

SLO 1 - Engage with stakeholders to identify the problem

The studio was lucky enough to get a presentation by a security specialist from GitLab. Essentially the key takeout was that social engineering seems to be the key factor is security weakness. This is due, based on my observation through the exploitation of human emotion. An example of this was the ILOVEYOU email. As a victim reads the message, a spike in the dopamine hormone would result in the person feeling good and would make them pursue the matter further. Thus, they will click the obfuscated file and launch the worm into their machine .

SLO 2 - Apply design thinking to respond to a defined or newly developed problem

Our group chose to research the OWASP Top 10. These are essentially, the most sought after attacks in enterprise. Number 1 on the list was injection, this would mainly entail SQL injection. Thus in terms of design thinking, a solid validation software would need to be installed to ensure the data that is being fed to the data field is not fuzz and will not cause spit out data that an unauthorised user should not see

SLO 3 - Apply technical skills to develop, model, and/or evaluate design

The group was able to demonstrate the importance of OWASP Top 10 through a powerpoint presentation. This is a list of the most utilised and thus malicious attacks in the past year or so. They are used as a guideline for vulnerability identification and can assist in enterprise to evaluate their own security risk.

This skill was demonstrated in the studio through a CTF run by OWASP themselves called Juice Box. This CTF is deliberately vulnerable web application that allows players to leverage different exploits varying in complexity.

SLO 4 - Demonstrate effective collaboration and communication skills

Since I had to continually communicate with tutors and other group members, I found myself reaching out with others for assistance. This was escpecially needed for the static website, which currently has not been set up due to some unsolved errors. Fortunately, I had Darshil, Max and Andre to help me out hosting setting up the page, which I found very difficult as it was very new to me, since most my expertise is elsewhere.

SLO 5 - Conduct critical self and peer review and performance evaluation

The feedback from Larry indicated that I was on track with the SLO’s and on course to complete the studio. He did however mention that I did display excessive hand and feet movement when I spoke during the presentation, which is definitely something to improve on. Another aspect would be to not leave a submission until the last 30 minutes.

As a group in general, we have to work on getting to the point. This lack of comprehension resulted in the presentation going too far overtime, however we were lucky enough to be let off with a warning and was told that we would be stopped at 6 minutes sharp should we do another presentation.

Sprint 2

Ethical hacking on stakeholders

Ethical hacking is the means of penetrating into the network of an organisation for the purpose of exploiting vulnerabilities under the legal consent of the hiring organisation. This in essence provides the organisation with the peace of mind that their network will be less open to outside attackers that would exploit these same vulnerabilities for their own benefit as well as the embarrassment of the victim

The purpose of ethical hacking is to ensure that the assets and data that belong to stakeholders remain secure and out of reach of the prying eyes of the public

Hacking ‘ethically’ requires these so called hackers to act under a code that protects the organisation from any harm

In a simple example, the code would read like this:

  • Understand the characteristics of the of the company
  • Determine the sensitivity and confidentiality of the information
  • Communicate, be transparent
  • Do not violate set limits
  • Do not disclose information to third parties

Hence such a code provides peace of mind to the stakeholders themselves that any portion of the company they own or data that the company posesses, such as investments for Superannuation and banking to health records are protected by law.


Bug Bounties on stakeholders

Bug bounty allow security teams to earn a sum of money for a bug that is found in an organisation’s website. This bounty encourages persistance and hard work in the search, futureproofing the company from future attacks. Such a program can be an issue as bugs may be disclosed to the public on purpose, exposing data and other sensitive information unbenownst to the componay and likewise to their stakeholders.

A bug bounty program will have a scope in place

A scope states the type of the bugs to be found and where the hacker can poke and probe. It will also include a respobsible disclosure statement as well as the reward for finding certain bugs. The responsible disclosure affects both the finders and security teams alike and prevents either party from misconduct such as giving away sensitive information or not acting to improve security when a bug has been found


Test Web Apps under RDP

Web app hacking requires a plethora of knowldge with regards to how the web works, its protocols, the OSI model and the respective tools that are used to break in. Under a responsible disclosure program, the exloits that are unveiled and broken using such tools must not be distributed openly to the public so as to make the information a vector of attack in the future

Research Task - XSS

The studio was given a lecture by CSEC member Luke Fuehrer. During the lecture he covered the history of web applications throughout the development of the internet. This was alongside the need to provide improved security to such applications as the amount of data that organisations were handling was expanding over time. The security vulnerability that he covered was Cross-site scripting, or XSS for short. This is essentially the exploitation of the javascript that runs in the background of a web application for malicious means on both server-side and client-side operations. He explained the 3 main types of XSS attacks and how they work. One of the take home messages that he wished to implant into his audience was that once you know how to mitigate the attack, as a student you now know the methods with which you can use the execute the attack without detection. It was also mentioned that it’s not what you do, but how you do it. It is simply a fallacy to try and know everything, however once you seen a common pattern, you are reminded of a previous exploit from a past learning experience.

We were tasked to research an XSS attack and find a common solution to that type of attack. I managed to find am attack that involved ebay from 2017. This involved redirecting the user to a spoofed site. An attacker would use a PHP script to steal the credentials of the user. These credentials would then be sold off for a cost.

The atack would execute as follows:
1) User would click on listing which redirected the user to a page that hosted malicious Javascript injected by the atacker
This script executes as the page is loaded so it is practically unseen by the user, whom is redirected again to a spoofed login form.
2) When the user inputs their credentials, they are transmitted to a PHP script. Once received, the user is redirected to a genuine eBay page, stating the listing has been removed. Unbenownst to the user, these credentials have been stolen

Unfortunately, based on the several sites I searched through, there doesn’t seem to be any exact figures as to how many accounts were compromised as a result of the vulnerability.

Prevention & Mitigation

Reflected XSS can be avoided in a relatively simple manner:

  • Vigilance
  • Web Application Firewalls - block abnormal requests
  • Escaping user input - ensuring data is secured before rendered to end user
  • Validating Input (Whitelist and Blacklist) - ensure site is rendering correct data and preventing malicious data from harming the application
  • Sanitising data - removing unwanted characters such as utilising filters such as helmet


Problem Statement

Company XYZ is currently hosting multiple web apps to run different customer portals. However, a lack of security knowledge means the compny is unable to properly train their staff on the dangers of and threats that surround the web.

To improve our web hacking skills, were given an array of deliberately vulnerable web apps. Of these I chose to explore Web for Pentester and Natas. In the past, I’ve gone through Bandit, another wargame hosted by Overthewire, the same site that hosts Natas. I figured that my prior experience would help to solve Natas, I seemed to bit off more than I can chew.

Initially going through Natas for the first time, I reached a level that required the use of an HTTP proxy, most notably Burp Suite, which in itself was one the many tools mentioned in Luke’s talk. In essence, any level afterwards I had trouble in seeing where to go or what to do. To solve this, I spent time looking at writeups. These are the solutions that have been posted by other users during that attempt to solve the challenges. These helped a lot as it allowed me to put myself in their mindset, empathising the methodolgy. As Luke stated, “it’s not what you do, it’s how you do it”, in that there are multiple ways to traverse the web app.

Natas 4 seemed interesting to a hacking rookie such as myself:
1) I was presented with a page that says “Access dissallowed”


2) Looking at it I had no idea where to go or what to look for
3) A quick search for the writeup, I discovered it required the use of a http proxy, in this case Burp Suite to capture the request in the middle of transmission

request capture

4) The challenge required that the packet be captured and the URL to be modified to allow the user to appear as if they were accessing the page from


It was interesting to see how simple it is to execute such as attack

Since I felt I didn’t have a clue about the later levels, I continued reading the writeups of the later levels, reading further about the differing attack vectors that are required to be exploited. PHP seems to be heavily used as a vulnerable scripting language in these challenges. To my knowledge, real life filters such as helmet do exist to protect against open gaps in such code.

Whilst limited in scale, these challenges outline the basic yet dangerous vulnerabilties that exist in industry that can be used as a form of education to mitigate such attacks. As they are mostly attacker-oriented, the opposite approach would need to be taken into account, that is understanding defensive methods/software that are designed to protect against the vectors that are put on display.

This research ties to SLO 2: Apply design thinking to respond to a defines or newly identifies problem.

Friday Free-for-all

Speaking to Riley, i gained a valuable insight into his progression into the subject. At current, he had solved a HTB challenge that seemed far beyond what I have taught a rookie such as myself, despite him admitting being ‘very new’ to the process. The challenge for him seemed to be time since he mentioned it took him around 2 hours to research prior to approximately 3-4 to execute the attack, which for one challenge, is a pretty long time. In analysis, there were definitely some useful skills that he would’ve picked up in the process including changing permissions, privilege escalation and some scripting. This collaboration link to SLO 4 and 5 because …


This week was a challenge in trying to get the website up on time. I attempted many a time with hugo and github pages to no avail. I then attempted jekyll, once again, no success. I was able to get the site running locally, however once loaded to the custom domain, it was unable to load. In my time of need I contacted Darshil whom recommended running hexo on netlify. Luckily he was kind enough to help me with the setup. With a few DNS tweaks, the site was up and running.

Domain Information

Netlify is brilliant as everything is run though github.


Once changes to files are committed, netlify automatically updates the changes and pushes them to the site. Initially, I thought that posts needed to be made via the cli using a specific command, however netlify allows the direct creation of markdown files so that assuming everything is saved in the correct folder, the pages render automatically.

Site Details

In terms of issues that I had with the site, the main one was actually trying to figure out how to get images to render on the page. Below is a before and after of the site to demonstrate how netlify updates the page after committing the markdown file on github:

Before Committing

The markdown file before committing

After Committing

The main solution that seemed to roam the net was trying to get the asset folder to update upon post creation. This could be done through one of the parameters in the config file. Since this wasn’t the case, I managed my own solution to the problem. All that had to be done was a new folder had to created in the source directory to store images, even that wasn’t straight forward either. The process is as follows:
1)Create file
2) Within name textbox, add name of folder followed by forward slash
3) Within the new box, add a file name

This file be subsequently empty, so it could be deleted later on:

4) Insert file, click and drag photo
5) Commit changes

Images can than be referenced in the markdown file as follows:

![<comment>](<path to image>)

Image Folder

One of the current unsolved issues I do have though are that the posts don’t seem to update independent to one another, and thus yield the same timestamp on them. As a bonus, I am still yet to figure out how to add new links on the splash page that would allow to separate different topics.

Running Site



Half way into the studio and time management seems to be the toughest challenge thus far. It’s one of the most common things that wil come up in the scrum/free-for-alls from not only me but also many others. I feel it’s an issue with planning ahead as well as juggling between committments and just struggling to staying on task. Darsh has mentioned Google Keep, however, I haven’t incorporated into my repertoire since I tend to find handwritten notes the best method of notetaking.

Sprint 3

Free-for-all 1 - Monday

Speaking to David and Frank, they seemed to have a solid grounding in the subject. David spoke about traversing the web app that the class was invited to break. There were three main findings as part of his talk:
1) The Rest API is quite open and so through particular links he was able to find a list of user data UNENCRYPTED
2) the source code on the login page shows the user unencrypted
3) invalidating a cookie on the login page reveals the server version. David was able to cross check the common vulnerabilities on Common Vulnerabilites and Exposures (CVE) for that particular version. Frank is working through Natas. This is probably best as it is expected that we reach bandit 30 and natas 15 by the end of today.

Monday Demo

Darshil was able to generously donate his time to demonstrate the basic process of breaking into a vulnerable machine. He used Pentesting 1, a machine downloadble from vulnhub. Below are my notes on what he did, specific quotations from him and anyone else that made a contribution to the demo.

“You cant hack what you cant see” - Darsh
“enumerate, enumerate, enumaerate” - drsh
There are many tools to breaj the machine
vuln will give you an ova, import to virtual box
setup NAT network

Attacker -
Box -

Assuming we are in the network and cant get past login
From attackers machine:
NMAP - ip addr
find ip

Enumerate subnet and find ip of victim:
nmap -sP (ping scan)

ping ip to validate

to enumerate:
netdiscover - needs device and range

netdiscover -i eth0 -r

to find open ports:
nmap - not always recommended as the default script may be too noisy or not always work

nmap -sv - enumerates all the versions, e.g. which version of ftp

searchsploit proftpd 1.3.3 - shows expoits for given protocol version, in this case proftpd 1.3.3
Drsh then when to and searched for proftpd1.3.3c
what was revealed was metaploit (backdoor) and RCE (compromised source backdoor)
created new directory to load directory
cd Documents/

used wget to load exploits

msfconsole (metasploit framework console)
Drsh doesnt recommend to use metasploit to start out - ITS TOO EASY - Jason
By googling the exploit, drsh was able to find - aldeid - wiki page
GOAL:reverse tunnel to execute commands as root

to check if root:


Breaking http:
typed in ip to browser
searchsploit httpd 2.4.18

try curl:
shows cource of webpage

Directory enumeration to see invisible directories
in this case /usr/share/wordlists/dirb/common.txt

had to mod host.conf vtsec
type in vtcsec

From the dirb we discovered its a wordpress page - notoriously vulnerable
wpscan is designed to specifically scan wordpress

Discovered user is admin admin

Drsh went for a reverse shell
found a cheat sheet through pentestmonkey

nc -nlvp 1234
-l listener
-p port number
The listener must be up first before the script can be executed

change 404 page to includea PHP reverse shell
since we’re admin, the 404 page can be changed tthrough the webpage
point ip to machine
also point to transmit tp port 1234
The server needs to poin to the attacker
why is ther server trying to connect to the attacker?

The reverse shell is trying to create a connection without having a direct way in

upgrade shell -
not necessary but prettier

to check if possible to escalate to root
look at psswd and shadow
use hashcat or John the Ripper to brute force

tmux - terminal splitter

Free-for-all 2

We had no free-for-all on the wednesday due to the fact that the time was taken up by the team from Deloitte (see below for info)

Free-for-all 3

On the Friday, I had the opportunity to talk to Corey, Cameron, and Brendan. Cameron attemped Kioptrix and utilised the Openfuck exploit to gain root as well as going through Pwnlab. Corey attempted legacy, a hack-the-box challenge and managed to use one exploit to gain root. He also attempted Bake, a machine based on directory traversal. Brendan went through hack-the-box, looked at the resources that were posted on the studio website as well as pwnlab. A definite challenge for all of them was getting the vm’s to work.

Deliverable 1 - John the Ripper

John the Ripper is a free password cracker.

It is used to used to execute 3 basic password attacks:

  • Brute force: goes through every possible combination to find the solution
  • Dictionary: a list of passwords. The tool will cross check the list with a possible match
  • Rainbow: a rainbow table is a list of pre-computed hashes. Similar to a dictionary attack, the tool cross-checks with this list.

John requires that the file to crack is needed in a particular format. In a linux system, it is common to break the /etc/passwdd and /etc/shadow files where drsh ended on Monday’s demo. We need to use the unshadow utility to convert the files into a text file:

/usr/sbin/unshadow /etc/passwd /etc//shadow > ~/passwordstocrack.txt

to perform the crack:

/usr/sbin/john --wordlist=/usr/share/wordlists/rockyou.txt ~/passwordstocrack.txt

The above example was used directly from one of a website but I will do my best to explain the syntax.
/usr/sbin/john - initiates JtR
–wordlist= - tells JtR to use a dictionary. In this case, the rockyou.txt file was used which is a list of common compromised passwords from the web.
~/passwordstocrack.txt - the file containing of passwords for us to crack


Openwall, 2019, John the Ripper’s Cracking Modes, viewed 18 February 2019,

Openwall, 2019, John the Ripper password cracker, viewed 18 February 2019,

Openwall, 2019, John the Ripper usage examples, viewed 18 Februrary 2019,

Pentestmonkey, 2019, John the Ripper Hash Formats, viewed 18 February 2019,

Oudy, H, 2017, What is John the Ripper?, viewed 28 February 2019,

Bytes over Bombs, 2019, Cracking everyhting with John the Ripper, viewed 18 February,

Wikipedia, 2018, John the Ripper, viewed 18 February 2019,

Wednesday Industry

On Wednesday, the security team from Deloitte presented to the studio. Below is my personal notes but in summary, they introduced the concept of pentesting, outlined what they do including red teaming as well as the tools and techniques they employ. They also gave us a cool to box to break. This talk satisfied SLO 1 as it provided further insight into system vulnerabbilies and how to exploit them. This was demonstrated through an open hacking session where the studio was given the oppurtunity to break into their box with feedback from the team on progression.

If both vms are on NAT, they should be able to interact

What is Pentesting?
Think like criminals
advide clients on how to imporve security
art & science

what do we do?
talk about what to test
reporting - findings and solutions

Physical - locks, cctv, elevators
Human - social engineering, ‘forgotten link’
Cyber -

Infrastructure - internal network, wifi, windows auth systems
Web Apps
Mobile Apps
Physical and social engineering
Red teaming
Citrix/Kiosk breakout

Find apache cred folder through text box
using xss to root
using expliot-db

Database weaknesses
1) Create account
2) add it to admin group

Demonstrated a social engineering ploy executed on a company. They told them that ip’s from Russia and Turkey were attacking them. Proxy auth was used to snatch the employees creds. On their end, they saw ip 1:: and the employee creds in plaintext.
They also mentioned hacking kiosks through navigating to a sight using a webpage that allows file uploads. Through this, a malicious shell can be injected through an open usb port and crack passwords

Red Teaming
breaking into a building

Pentesting vs Red teaming
Specific Realistic
Limited Scope Relevent
Narrow focus Readiness

Proxmark3 Card Resder
Low freq antenana

Powershell empire

power bank

ifconfig - find ip of machine
-T4 specifies speed
netdiscover - find alike hosts
nmaps -sSV -n -T4 -p 4949
make sure to specify protocol and port
sslscan ip:port
tls not running properly
nmap –script=ssl-heartbleed -p 4949 -T4

msfdb run - run metasploit
search heartbleed
>set RHOSTs target ip
>run - will scan by defualt
set action DUMP
creds dumped

Friday Deliverable

This was essentially my first big dive in attempting boxes. The skill of enumeration was my first wall and I was dedicated to break it simply by getting into walkthroughs and writeups.

I discovered ippsec, a youtuber whom does walkthroughs for retired hack the box machines. After watching a few, I realised that the enumeration is essentially the same in terms of the tools used things to look for.

I took a shot at raven2 to start off. The inital thought was to read through the walkthrough for raven1 and use that as a guide. However, I decided I’d use the skills that drsh displayed in his demo earlier in the week, as well as the methods from the deloitte team.

In going through raven2, i quickly discovered that the network settings for virtualbox weren’t set up properly as the services that appeared as part of the nmap scan didn’t seem right. So once the settings were fixed, the scan yielded a cheeky http at port 80.

By instinct i accessed the webpage and navigated my way through for a textbox or something sinister.

One of the links was a blog, which directed me to a wordpress page. At this point I remembered that drsh used wpscan in his demo. In attempting to run:

wpscan --url --wp-content-dir wp-content

the didn’t quite yield anything interesting

A quick scan of the raven2 walkthrough revealed that I WAS NOT EVEN CLOSE

I had hit a barrier by choosing one of the services that I didn’t quite understand how to attack but just went for it anyway:

The webpage indicated that only POST requests were accepted. Me thinking this was going to lead to somewhere, I launched burp and intercepted the request. I stumbled upon a site that boasted loading the response with this:


In the end, this got me nowhere

Rizwan, B, 2018, Wordpress xmlrpc.php -common vulnerabilites & how to exploit them, viewed 21 February 2019,


I “skimmed” through the walkthrough for clues as to where the flags may be because i was losing patience.
Turns out one of them was right under my nose. One of the results of the wpscan pointed to a directory with a few interesting directories. In the end, you get to a file called flag3.png, which sure enough, is actually the flag, WOO HOO!!

Performed a nikto scan, saw a raven.local. Similar to what drsh did in his demo, I added raven.local in /etc/hosts and pointed it the target ip.

Nikto is a perl-based recon tool used to detect web server vulnerabilities such as misconfigurations and outdated versions. It is by no means safe to use under an IDS as it is quite noisy. It does also return false positives as it doesn’t execute the vulnerablities but rather checks to see if the server responds to known vulnerable URL’s

Occupytheweb, 2019, ow to Find Vulnerabilities for Any Website Using Nikto, viewed 21 Febrary 2019,
Sectools, n.d, Nikto, viewed 21 February 2019,

A dirb scan reveals the possible directories. I discovered that /vendor/ yields further progress.

One of the sub-directories had a timestamp that was noticable different to the others. Clicking on it, gives me the first flag.

At this point, I realised that moving forward meant researching more about privelage escalation.


As recommended by Darshil, I continued to research several walkthroughs primarily from different vulnhub machines and retired Hack-the-Box attempts from Ippsec. The vulnhub machines showed potential as the steps taken were somewhat easy to understand. The HTB challenges on the other hand, in my opinion anyway were a massive jump and so I deterred from those and leaned towards boot2root.

Matrix 1

Matrix was a cool box as it introduced me to focusing on bruteforcing and shell breaking if you will. I chose to document this box in particular as it was the simplest to understand compared to the others I looked at (Moonraker and Bulldog). Below are my handwritten notes of how I articulated the box being broken.

Colon, N, 2018, Matrix 1: A Vulnhub VM Walkthrough, viewed 24 Febraruy 2019,

Final word

Unfortunately my time management is still something to be desired. For some reason I find myself getting to this trans where I have no idea as to what I’m doing simply because I have so sense of urgency or organisation. The best example was working towards this weeks presentation. It took me ages to figure out how to simply organsise the damn thing and it still didn’t come out to standard and I’m hoping its enough to pass. In closing, I just have to read more and more, keep my eyes on the prize and don’t mess it up., or try my best not to at least.

Sprint 4

Reverse Engineering Guest Speaker

We were fortunate enough to have Ruben from Symantec to give us a workshop on reverse engineering with binary ninja. He directed us to a website that had several challenges that we could attempt, each with increasing difficulty and thus complexity. The hardest part abou these challenges was definitely having no knowledge of reverse engineering whatsoever, so naturally, I had no idea as to what I was looking for. To make matters worse, Binary Ninja wasn’t working on my mac due to the limited amount of RAM I have installed so I had to pair up with Pags, one of my colleagues to complete the challenge.

It was very interesting to say the least, especially with how binary ninja worked to display what the cpu instructions looked like. The complexity of how low level information is traversed through the system is something that every tech student should know and understand. It’s by far the means to reverse engineering (pun intended) the knowledge that is taught in the subject (at a high level) to gain a deeper understand of how a machine works. Essentially what I mean by that is, a student is taught what functions, methods and libraries are, however are practically oblivious to how the code is looked at in the background. I think you get the gist.

Ruben also mentioned malware analysis in his talk, which definitely struck my attention.

Hack the Box

Being new to Hack the Box, I was expecting to just create an account, get the invite code and away I go…boy was I wrong.

The /invite/ page is actually a vulnerable login form that needs to be exploited in order to reveal the flag. I was able to get the help of Jason and Rowan to guide me in the right direction. It went something like this:

1) Me trying XSS and SQLi and immediately getting blocked

2) Jason redirected me to the invite page’s source code. In the console tab, there was an image of a skll that seemed interesting. There was also a js method that I found that allowed you to generate the invite code. At this stage, I had to google how to call functions in javascript since my programming knowledge is very limited. I discovered that the console allows the calling of these methods on the browser. Once I called the function, I was given a base64, which is where i used cyberchef to decode:

3) The message read that I needed to a POST request to that given url. So I used postman to do so. Once again, I was given yet another base64:

3) Once the code was inputted into the invite field…

…and there you have it

I was able to get root on Curling, however since it is currently an active box, writeup is to be announced!!

Final Expo

On the last Friday, all the Summer Studio students banded together to put on an expo to showcase their work over the 4 weeks. From 12pm to 1pm, we had a pizza lunch before speeches from the head organisers as well as the subject leaders. The expo was located all over Building 11, with each studio having their own room to display their work.

Our setup wasn’t as organised as I’d wish, however we managed to impress where we could. Unfortunately, I didn’t get the opportunity to present, however I was able to go to a different studio (Neural Networks) to see the progress of other students and of their stuff is cool to say the least. One team was developed an algorithm to identify the percentage of a certain cat you are. Another group developed a scanner to calculate the amount of white blood cells in your bloodstream.

To finish up, it was awesome to see what the other studios have done and I’m escpecially proud of everyone in our studio.