Almost daily, I see someone making a crack at PHP, implying that apps written in PHP are somehow less secure than other languages.

Here’s the thing: they’re not.

Where does the idea stem from?

I have a few theories about why people think PHP is less secure than other languages. I’m going to address all of them.

People’s perception of PHP is outdated by 15+ years

Back in the early days of PHP, it was one of the few options for web-based languages, and probably the best. This was also an age where security was more of an afterthought, so vulnerabilities were everywhere. This wasn’t specific to PHP; rather, it was a general lack of awareness regarding security in that era.

Many older security professionals began their careers by finding vulnerabilities in websites during the 90s and early 00s, back when PHP powered pretty much everything. Now when they see PHP it just feels vulnerable because they’re equating PHP with the vulnerability of 15+ year old web applications.

You see, PHP has stood the test of time, and it still powers most of the internet today. You can’t say the same about ASP, JSP, ColdFusion or Perl, which were the other popular web languages that were available 20 years ago. We have to give a shoutout to ASP though, which has been modernised with C#, .NET, ASP.NET.

You don’t notice it’s PHP unless you see a .php extension

In the early days of web applications we would split PHP code into different files and access those files directly. For example if you wanted to visit the “about” page of a website, it would probably be located at /about.php. The user would navigate to example.com/about.php, which would execute the about.php file on the server-side and return the result.

Modern applications are much more likely to use application-level routing to forward requests to the right section of code within their application. When we use routing in this way, there is no need to have .php extensions visible in the URL, so we omit them.

The vast majority of modern PHP applications don’t show .php extensions in the URL. For this reason, you’re unlikely to notice that an application runs on PHP unless it’s a really old application. In this case, once again, the application is more likely to be vulnerable because it’s old, not because it uses PHP. The same goes for a .asp extension, for example.

Examples of vulnerable code are often written in PHP

If you’ve ever done any appsec training, there’s a very good chance that you’ve seen PHP being used to demonstrate vulnerable code. For example, how many times have you seen this XSS demo?

<?php echo "Hello " . $_GET['name'] . "!"; ?>

The truth is, PHP is often chosen as a language to demonstrate vulnerabilities simply because PHP was the language where most of these vulnerabilities were first discovered – not because PHP is somehow more vulnerable, but because PHP was one of the few server-side web languages that existed back then.

Just by training security professionals with vulnerable code snippets in PHP, we have inadvertently trained them to feel that PHP is somehow less secure.

People compare raw PHP with full web frameworks

For some reason, when people argue that PHP is less secure, they often compare raw PHP with a web framework in another language, rather than comparing the two raw languages against each other (e.g. PHP vs. JS). For example, I have seen people comparing raw PHP with Next.js.

This makes absolutely no sense.

In fact, the closest equivalent to Next.js in the PHP world is probably Laravel, and anyone who has used Laravel knows that it is amazing, modern and just as secure as any other popular framework in any language.

PHP is very easy for beginners

Creating a web application with PHP can be as easy as writing a PHP file  in notepad.exe and uploading it to a web server. There’s very little prerequisite knowledge required. This is very encouraging for beginner coders, but beginner coders are the ones most likely to write insecure code! As a result, there’s a lot of bad PHP code out there.

I also think that many developers who are experienced today probably started their web development journey with PHP. The code that they wrote when they started was likely filled with vulnerabilities because they weren’t experienced developers yet. Rather than blame their own inexperience, they blame the language they used. “A poor worker blames his tools”, as they say.

Is this PHP’s fault? No! In fact, I’d say that being beginner-friendly is probably a net positive. Important production code is rarely written by beginners.

People don’t know about Laravel

It still blows me away how many cybersecurity folks have never heard of Laravel. Or any PHP frameworks for that matter. They hear “PHP” and assume that people are just writing raw PHP.

I consider Laravel to be one of the most robust, modern, developer-friendly frameworks out there today. It even has a healthy ecosystem of pre-made starter kits, testing suites, managed hosting solutions, local dev environments, admin dashboards, auth flows, debugging interfaces and much more.

Modern frameworks like Laravel attempt to shield developers from writing vulnerable code by using secure defaults. For example, the Blade templating engine in PHP will HTML encode variable output by default, thwarting XSS vulnerabilities unless the developer explicitly disables it.

People are ignorant/uninformed

More than anything, when I hear someone imply in 2023 that PHP is somehow more insecure than other languages, it tells me that they are simply ignorant or uninformed. They’re parroting an inaccurate opinion that has somehow stuck around for decades.

If you’re still sure that PHP is an “inherently insecure” language, then I’d encourage you to try finding 0days in some long-standing popular PHP apps like WordPress or phpBB. Good luck!

There are a bunch of different terms here, all with slightly different meanings:

• Remote Code Execution
• Remote Command Execution
• Code Injection
• Command Injection
• RCE

These subtle differences have caused confusion enough times in my life now for me to write a blog post about it, clearly defining the differences.

Command Injection is a type of vulnerability that allows an attacker to inject operating system commands directly into an application and have them execute (the type of commands that one would enter into a Bash or Powershell terminal).

Code Injection is a type of vulnerability that allows an attacker to inject server-side code directly into an application and have it execute. For example, injecting PHP, Python or server-side JavaScript into eval().

Remote Code Execution is the impact of a vulnerability that allows an attacker to execute code remotely, but it is not the actual vulnerability itself. The vulnerability does not necessarily need to be a Code Injection vulnerability, it could be something else, such as an arbitrary file upload that allows an attacker to upload a web shell.

Remote Command Execution is the impact of a vulnerability that allows an attacker to execute commands remotely, but it is not the vulnerability itself. Again, the vulnerability does not necessarily need to be a Command Injection vulnerability, it could be any vulnerability that results in an attacker being able to execute commands.

It should be noted that typically, if a vulnerability allows remote code execution, then it will also allow remote command execution, and vice versa.

RCE is a generic term that can refer to either Remote Code Execution OR Remote Command Execution. In other words, RCE is the impact of a vulnerability that allows an attacker to execute code and/or commands remotely.

TL;DR: Injection is a type of vulnerability, execution is a type of impact. Command is a shell command, while code is some type of server-side code other than shell commands, such as PHP. RCE is used interchangeably to mean remote (code|command) execution.

Attack surface monitoring has become increasingly important and popular in recent years as the internet footprint of organizations has increased. Hackers are utilizing advanced recon methods for discovering and monitoring internet-facing assets of an organisation. As changes occur in the attack surface, it is beneficial for hackers to be notified so that they can immediately check if these changes may have introduced security issues. Of course, this makes it equally important for organisations to monitor their own attack surface, so that they have at least the same visibility as their attackers.

Today there are a lot of tools available to help automate the process of monitoring an attack surface. Many of them are extremely expensive, and designed to be used in an enterprise setting. Thankfully for individual users, OSINT hobbyists and bug bounty hunters, there are some great free, open source alternatives too. Today I’ll be diving into one of them, SpiderFoot.

The open source version of SpiderFoot is pretty amazing, and totally free. It’s been worked on for almost a decade now making it very stable and feature rich. If you want a full range of attack surface monitoring capabilities, you’d need to use SpiderFoot HX, the premium paid offering that’s cloud-hosted. If you don’t want to do this stuff from the cloud, or are operating on a tight budget, I’m going to cover some simple things you can do using the open source version plus some other tools and scripts to get some basic attack surface monitoring capabilities. This will enable you to:

• Be notified when new hosts appear in certificate transparency, SHODAN and other places that SpiderFoot hooks into to identify new hosts
• Capture screenshots of new hosts as they are identified
• The rest is up to your imagination – if SpiderFoot detects it, you can get alerted about it

First of all, let’s choose the SpiderFoot HX features we need to mimic to get this functionality. Out of the main SpiderFoot HX features beyond the open source version, those highlighted in bold  look like good candidates because they offer a lot of value and also seem achievable:

• Hosted, pre-installed and pre-configured
• Better performance (5x-10x)
• Team collaboration
• Multiple targets per scan
• Monitoring with change detection and notifications
• Correlations
• Investigations through a graph-based UI
• Customer Support
• Built-in TOR integration
• Feed data to Splunk, ElasticSearch and REST endpoints
• API
• Screenshotting

API

Perhaps surprisingly, this one is very easy to implement. The open source SpiderFoot uses SQLite3 as the backend database. If you have run a scan, you can view the raw results in the database easily by simply opening the spiderfoot.db file in the root directory of the SpiderFoot installation.

There is an excellent open source project called Datasette which ingests any SQLite file and turns it into a browsable web interface, along with a full JSON API. It also has some other handy features like the ability to run raw SQL queries and export data in CSV format. A word of warning, Datasette does not have any authentication and it allows anyone who visits the page the ability to run arbitrary SQL commands and view all of your data, so be sure not to expose this beyond localhost!

In order to set this up we can simply install Datasette with pip (requires Python3.6 or higher):

pip install datasette

If you’re using a Mac, you may also use Homebrew:

brew install datasette

Then we can start datasette with the following command. You may need to change the location of the database, depending on where it’s stored on your system.

datasette serve ./spiderfoot.db

You should see something similar to the following:

Navigating to http://127.0.0.1:8001 will reveal the Datasette web interface:

The scan results are stored in the table called “tbl_scan_results”, navigating to this table will show the data in a table within the web UI.

You may notice a “json” link indicated by the red arrow in the screenshot above. Clicking this will take you to the JSON endpoint for that table.

To filter the data, you can use HTTP GET parameters. For example, to only view results from the SpiderFoot sfp_whois module, we can navigate to the following URL. Note the &module=sfp_whois at the end.

http://127.0.0.1:8001/spiderfoot/tbl_scan_results.json?_labels=on&module=sfp_whois

That’s it! In a few minutes we have set up a full JSON API containing all of our SpiderFoot data.

Screenshotting

There are many different open source command-line utilities for screenshotting HTTP responses of hosts but my favourite is probably Aquatone by michenriksen.

First, we need a list of hosts to screenshot. Luckily we have set up our own API, so this is trivial with the following command:

curl -s "http://127.0.0.1:8001/spiderfoot/tbl_scan_results.json?_sort=rowid&type__exact=INTERNET_NAME" | jq ".rows[][9]"

The curl command queries the API and returns the JSON response, then jq is used to extract just the hostnames. The output should look something like this:

You might notice that there are duplicates, let’s remove those and the double quotes with sort and sed.

The final command to extract all raw, unique hostnames from SpiderFoot looks like this:

curl -s "http://127.0.0.1:8001/spiderfoot/tbl_scan_results.json?_sort=rowid&type__exact=INTERNET_NAME" | jq ".rows[][9]" | sort -u | sed "s/\"//g"

And the output:

Just for convenience, I’m going to save it into a bash file for easy execution later, to achieve this I just copied the command into gethosts.sh and added execution permissions.

Now head over to the Aquatone releases page to grab the latest version for your operating system, download and unzip it. Inside you will find a binary file. 

The screenshot functionality utilises headless Chromium or Chrome. The Aquatone docs say that Chrome is sometimes unstable, so they recommend installing Chromium, which you can find here.

Once it’s installed, all we need to do is pipe the output of gethosts.sh into aquatone like this:

~/gethosts.sh | aquatone

I’d recommend doing this in an empty directory, because it will create a bunch of files and folders.

The output should look similar to the following:

When aquatone finishes, it will have created a number of files in your current directory, as shown below.

If you take a look in the screenshots directory, you can view the raw screenshots:

Alternatively, you can open the aquatone_report.html file to see a nice UI overview of the scanned hosts including screenshots (grouped by similarity), raw responses and HTTP headers. See below for a sneak peek.

Monitoring With Change Detection and Notifications

As is, the open source version of SpiderFoot provides single scans, but no means of continuously monitoring a target by scanning at regular intervals. This is something only offered by SpiderFoot HX. Ideally, if we’re hacking a target or defending our own organisation, we would want scans to be performed at least once per day, and any changes should be sent to us as a notification.

SpiderFoot is quite a comprehensive application that pulls many different data types. Alerting on all of these data types may lead to a lot of notifications, so for the purpose of this blog post we are just going to monitor for newly discovered subdomain names. This would be very useful to a bug bounty hunter for monitoring a large scope, or to a security team monitoring their own systems. Note that you could use any data gathered by SpiderFoot with similar methods. 

Setting Up Continuous Scanning Using Cronjobs

First let’s set up regular scans by utilising a cronjob! To start, simply run:

crontab -e

This will open up the file which will contain all of your cronjobs in vim. If you know how to use vim, simply enter the following line, then save and quit. You will need to edit the location of sf.py based on your setup, and also change “yourtarget.com” to whatever your scan target will be.

0 2 * * * ~/tools/spiderfoot/sf.py -s yourtarget.com

 If you aren’t sure how to use vim, follow these instructions very carefully.

• Once you have run crontab -e, press i to enter insert mode
• Type the following, changing the sf.py location and target to suit your setup/needs: 

0 2 * * * ~/tools/spiderfoot/sf.py -s yourtarget.com

• Press the escape key
• Type :wq
• Press enter

The “0 2 * * *” tells cron to run the command every day at 2am. To better understand how cron scheduling works or create your own, check out crontab.guru.

That’s it! Now that you’ve edited your crontab, the scan will run every day at 2am.

Change Detection

As I stated earlier, for the scope of this blog, we’re only interested in sending notifications for new subdomains, so we can reuse the gethosts.sh script that we created earlier.

Firstly, let’s create another bash script to append new hosts to a file. Save this script to a file called appendhosts.sh:

touch ~/hosts.txt
for line in `~/gethosts.sh`; do grep -qxF $line ~/hosts.txt || echo $line >> ~/hosts.txt; done

Be sure to give it execute permissions with chmod +x ~/appendhosts.sh

Next, run crontab -e and add this new line to make the script run every hour.

0 * * * * ~/appendhosts.sh

Now, any time a new subdomain is discovered, it will be added to the end of the ~/hosts.txt file. Just one step left, setting up notifications!

Setting up Notifications

The last step is setting up notifications for the changes we detected in the previous step. Again, we can do this with some bash magic and a cronjob. I’m going to be using a Discord webhook for the notifications. Essentially, we can send a message using curl to our own Discord webhook, and it will send through as a Discord message.

To set up your Discord webhook URL, follow the instructions here. Save the webhook URL for later.

Now copy the following script into ~/sendnotification.sh and edit the example webhook to be your own.

tail -n 5 -f ~/hosts.txt | grep --line-buffered '.*' | while read line;

do

   curl -H "Content-Type: application/json" -d "{\"username\": \"SpiderFoot\", \"content\": \"$line\"}" "https://discord.com/api/webhooks/1234567890/ABCDEFG1234567";

done

This script will continuously monitor ~/hosts.txt for changes. Whenever a new subdomain is appended, it will send that subdomain as a Discord message. Once again, be sure to make the script executable with:

chmod +x ~/sendnotification.sh

As this script will need to run continuously, it may be best to run it within tmux or screen on a VPS so that if your SSH connection drops, it will continue to work.

Here’s a screenshot of the outcome:

Conclusion

The point of this article is to show that even the free version of SpiderFoot is an extremely powerful tool and can be easily extended to provide some basic attack surface monitoring capabilities. By implementing some simple scripts around it, a few of the key features of SpiderFoot HX can be mimicked free of charge. This might be ideal for individual users, bug bounty hunters and OSINT hobbyists.

If you do OSINT a lot or you’re using this as an organisation, you may be better off paying for SpiderFoot HX for the additional speed, support, hosting, multiple targets, correlations, etc.

Happy OSINTing!

The whole JBS Meatworks ransomware attack caused some inner conflict for me.

Firstly I’m an ethical hacker and I don’t believe that ransomware attacks are ethical. I’ve spent a lot of my time defending organisations against these types of attacks. Secondly I’m a vegan who is against slaughtering animals for human consumption.

What happens when ransomware halts animals from being killed for human consumption? How do I feel about that? ¯\_(ツ)_/¯

I won’t lie, my initial gut reaction to the news of the JBS Meatworks ransomware attack was joy. It warms my heart that the power of hacking can yield an individual the ability to cause significant positive change in the world, especially disrupting an operation that slaughters tens of thousands of animals every single day.

Reading further, I wasn’t so happy about it. Legality aside, this was not an ethical attack. It was clearly financially motivated, many of the employees of JBS Meatworks did not get paid on time, there were probably casual staff who lost income and the animal slaughter will probably continue in a week or so anyway.

This got me thinking though… what if the attack’s sole purpose was to halt the slaughter of animals, not to make money? Would I consider that to be ethical? Or to abstract it further, and eliminate my own personal beliefs:

Is it ethical to utilise illegal hacking techniques to disrupt the operations of an organisation that profits primarily from something which is unethical?

It’s a tough question, right? Firstly the word “ethical” is purely subjective. Secondly, there are varying degrees of ethicalness. So while this question is good to think about, there is no definitive answer.

What really matters is people’s opinions on these topics, because those beliefs are what end up being translated into actions in the real world. So how do we measure people’s opinions?

Getting some answers

If you want to gather opinions, Twitter polls are a terrible idea. But that’s exactly where I turned. I love Twitter polls, but they’re not exactly the epitome of scholarly research. Most of the Twitter polls I’m about to show you only allow binary answers. Due to this, they don’t allow the opportunity to fully explore the complexities of the topics. Regardless, the results are super interesting and they do give an insight into the initial gut instinct of my Twitter followers (who are primarily hackers).

First of all, I asked if it is ethical to launch a ransomware attack against an organisation that primarily makes money from something unethical. I was surprised to see that 56% of voters said yes.

Another quandary. Is it ethical to launch a ransomware attack against an organisation that primarily makes money from something unethical?

— hakluke (@hakluke) June 3, 2021

Next, I asked a very similar question, but this time I changed it to a DDoS attack instead of a ransomware attack. The main difference is that the attacker would gain nothing from a DDoS attack. It is an attack designed to purely disrupt operations, unlike a ransomware attack which is more likely to be financially motivated. About 61% of voters feel that this type of attack is ethical, provided that the organisation they are attacking is (subjectively) unethical.

Got another one for y'all:

Is it ethical to launch a DDoS attack against an organisation that primarily makes money from something unethical?

Unlike a ransomware attack, the attacker gains nothing from it, they are purely disrupting unethical operations.

— hakluke (@hakluke) June 3, 2021

Relating this back to the JBS Meatworks attack, I asked my followers whether killing thousands of animals per day for human consumption is ethical:

I'm super interested to see the results of this one too.

Killing thousands of animals per day for human consumption is…

— hakluke (@hakluke) June 3, 2021

About 53% of respondents said that it is ethical, leaving 47% of respondents believing that killing animals for human consumption is unethical.

Then I asked whether the respondent would actively attack an organisation that consistently partakes in actions that they feel are unethical.

Okay one more ethical question:

Would you actively attack an organisation that consistently partakes in actions that you feel are unethical?

— hakluke (@hakluke) June 3, 2021

In this poll, I also added a “see results” button, because I only wanted people to respond if they had a particularly strong opinion one way or the other. The results are staggering.

31% of respondents felt strongly enough about this question to respond “yes”. In other words, almost one third of respondents would actively attack an organisation that consistently partakes in actions that they feel are unethical.

When you combine these two outcomes…

• ~31% or more of the respondents would personally, actively attack an organisation that they feel is unethical
• ~47% of the respondents feel that killing animals for human consumption is unethical

It is easy to see that organisations who supply meat are likely to be attacked because there is quite a large cross-section of hackers who would be willing to disrupt resources of these plants, whether there is money to be gained or not.

This doesn’t stop at animal agriculture though, nearly a third of these hackers are willing to attack any organisation that they deem to be unethical. That’s a pretty crazy thought, and it begs the question:

If there was no financial motivation to attack JBS Meatworks, would it still have happened eventually, simply because their primary business is something that many feel is unethical?

And the answer is…. maybe? The polls seem to suggest that this is the case, but It’s hard to say. There’s a big difference between answering a couple of polls on Twitter and actually attacking an organisation. And just to make things even more grey – JBS meats recently released a plant-based meat alternative range, and also bought Vivera, a company that sells plant-based protein. So yeah… I dunno… *confused stare* It’s interesting to think about though.

Hacktivism revival?

For a while now – the whole “hacktivism” scene seems to have been pretty stagnant. The “Anonymous” movement has mostly fizzled out, although it did pop its head up briefly in support of the BLM movement. Other than that, there really has not been much going on.

The responses to these polls tell me that there is still an underlying thirst within hackers to drive (subjectively) positive change in the world, and they certainly have the power to do so. It seems that it is only a matter of time before a new group of vigilante hackers join forces again to wreak havoc against organisations that they feel are unethical.

In these cases, the behaviour of the attackers is far less predictable than your run-of-the-mill ransomware attack because the motivation runs deeper than money, and is far more complex.

Whether you’re for or against it – it’s something worth thinking about, especially if you are involved with an organisation that partakes in activities that are ethically questionable.

For all you redditors out there, I’ve compiled a list of Cybersecurity subreddits, enjoy!

https://www.reddit.com/r/redteamsec
https://www.reddit.com/r/exploitdev
https://www.reddit.com/r/reverseengineering
https://www.reddit.com/r/regames
https://www.reddit.com/r/AccessCyber/
https://www.reddit.com/r/datarecovery/
https://www.reddit.com/r/Aggregat0r/
https://www.reddit.com/r/ISO27001/
https://www.reddit.com/r/fulldisclosure/
https://www.reddit.com/r/infosecurity/
https://www.reddit.com/r/BadApps/
https://www.reddit.com/r/hackersec/
https://www.reddit.com/r/websecurity/
https://www.reddit.com/r/techsnap/
https://www.reddit.com/r/NetworkSecurity/
https://www.reddit.com/r/CyberSecurityJobs/
https://www.reddit.com/r/ethicalhacking/
https://www.reddit.com/r/Infosec/
https://www.reddit.com/r/Information_Security/
https://www.reddit.com/r/i2p/
https://www.reddit.com/r/HackBloc/
https://www.reddit.com/r/ComputerSecurity/
https://www.reddit.com/r/securityCTF/
https://www.reddit.com/r/pwned/
https://www.reddit.com/r/computerforensics/
https://www.reddit.com/r/Malware/
https://www.reddit.com/r/blackhat/
https://www.reddit.com/r/netsecstudents/
https://www.reddit.com/r/CompTIA/
https://www.reddit.com/r/Hacking_Tutorials/
https://www.reddit.com/r/AskNetsec/
https://www.reddit.com/r/security/
https://www.reddit.com/r/opendirectories/
https://www.reddit.com/r/cybersecurity/
https://www.reddit.com/r/HowToHack/
https://www.reddit.com/r/netsec/
https://www.reddit.com/r/hacking/

Don’t.

Yep! I did it. I resigned from Bugcrowd.

Something about titling the blog “Why I Quit My Job at Bugcrowd” might have you thinking that I’m about to explode into a dramatic display of anger and resentment towards Bugcrowd, scaaaalding them with mighty words.

I’m not.

In fact, I absolutely loved working there. I’d recommend it to anyone. It’s a great organisation. My pay was great, the people were great and I got to work on a lot of purposeful projects. This isn’t so much a blog about why I left Bugcrowd as it is about leaving a job in general. Many would say I am crazy for leaving. Maybe I am! At this stage, I’m not even sure I have made the right decision myself. In this blog I want to explain why I left, and what I’m doing next.

Reasons for leaving

Wealth 💰

For me, true wealth is the ability to earn enough money to live comfortably without having to work. I don’t want to achieve this when I’m 65, I want to achieve it as soon as possible.

Why do I want wealth?

Sometime around late 2019 my wife and I were looking to buy our first home. It quickly became apparent that we would not be able to afford the house of our dreams. At this point I realised that I needed to start paying more attention to money. I’d been working for a decade, why couldn’t I buy the house that I wanted?

How can one obtain wealth?

I started reading books about how to become wealthy. I devoured all the classics, “Rich Dad Poor Dad”, “Think and Grow Rich”, “Secrets of the Millionaire Mind”, etc. They all basically say the same thing. Don’t trade time for money.

Robert Kiyosaki puts it well in his books, he segments income types into four different categories that he calls the “cashflow quadrant”. The four main types of income are:

• Employee – you are employed by someone else and paid for your time.
• Self employed – you are employed by yourself, but still paid for your time.
• Business Owner – you own a system that makes you money.
• Investor – your money makes you money.

In order to be “wealthy”, Robert Kiyosaki says that you should prioritise earning money from income streams as far down that list as possible. Notice that the further down the list you go the more scalable the income streams become and the more opportunity you have to free up your time.

The plan…

At Bugcrowd, I was 100% employee. My plan is to get further down that list by starting a business. I found it hard to do this when I spent the better part of my time/brainpower working as an employee. Now I’ll be refocusing all of that brainpower and time into generating income as a business owner. Most money that I earn above my living expenses will be invested.

Freedom 🦅

The other reason that I quit my job is for personal freedom.

What is freedom? 🤷‍♀️

Personal freedom comes in many forms.

To name a few:

• Freedom of time
• Freedom of location
• Financial freedom
• Freedom of expression
• Freedom of choice

The disconnect between freedom and employment 💔

No matter how good the culture at your company is or how much you love your job, you will still be required to forgo some amount of freedom when you are an employee. That’s why you get paid.

For example:

• You must work during specific times (sacrifice time freedom).
• You can’t say anything on social media that would negatively affect your employer (freedom of expression).
• If your boss asks you to do something, you have to do it (freedom of choice).
• If an employer decides that they don’t want to pay you money anymore, they can sack you (financial freedom).

This isn’t a dig at any company, it’s just how employment works. Employees get paid to forgo their freedom. This thought has been eating away at me for a long time, and it has contributed greatly to my decision to take this risk.

The alternative

I am trying to reconfigure my life to look more like this:

• I decide when I work.
• I decide how hard I work.
• I decide what I work on.
• I decide where I work from.
• I decide who I work with.
• I express myself freely.

What am I doing next? 🚀

There are a few ways that I’m planning to make money.

Starting My Own Cybersecurity Consultancy 👨‍💼

I’ve started my own cybersecurity consultancy, Haksec. This is my first public mention of it! Haksec provides virtual CISO (vCISO) and penetration testing services. I want to focus more on the vCISO side of things, because my experience as a penetration tester has taught me that a lot of businesses need general guidance more than a pentest.

If you know anyone who may be interested please send them my way, it would mean the world.

Bug Bounties 👾

I cut back on bug bounty hunting a lot since I started at Bugcrowd back in March 2020. I just haven’t felt overly motivated to do it because after a full day working full-time at Bugcrowd I was all bugged out. I am really looking forward to having more time to sink into this again – I can feel my motivation bubbling back already and I’ve landed a few good bugs in the last couple of weeks!

Content Creation 👨‍🎨

I’m going to be creating a lot more content.

Firstly, I’ll be creating content on my personal channels (YouTube, Twitter, Instagram, TikTok and my blog). I will be fully transparent about my bug bounty hunting journey including what bugs I find and how much I’m earning. I also want to make general life videos.

I will also be creating cyber-security related content on behalf of other organisations. I’ve already started doing a bit more of this. If you want any type of cybersecurity-related content created for you, feel free to get in touch.

I am scared 😬

This is one of the biggest decisions I’ve ever made and it’s a huge risk. Even more so with a family to provide for. The truth is, I don’t know if it will work out and if it doesn’t I hope that I will come back to the workforce in 6+ months with a whole new appreciation for the safety and security of employment.

Support 💪

If you’d like to support me on my journey, there are a bunch of things you can do:

• Refer people to Haksec if they are looking for cybersecurity services or advice.
• Sponsor me on GitHub
• Sponsor my upcoming content (get in touch via any of my socials)
• Hire me to create content for your organisation
• Share my content 🙂