Before the Gold Rush

Back in 2009 when I made the jump from shoddy game hacking to - ahem - hacktivism (no, I will not elaborate further), the only well known certification of ability was the Certified Ethical Hacker (CEH) from EC-Council. They claimed the honor of creating the “first performance based ethical hacker certification”.

Whether that was accurate or not will have to be verified by truer veterans, but it certainly wouldn’t stay “performance based” for very long. The exam eventually got shorter and there was nothing practical about it, at least not when I took it in 2016.

CEH existed but was irrelevant to me. As a broke middle-schooler discovering computer hacking, one meager year after the release of the infamous Hacking: The Art of Exploitation, 2nd Edition, any money I had to my name was going to Lego sets and airsoft. All my learning took place in forums and IRC channels, the logical successors of the post-BBS online hacking scene.

I learned how to use Nmap by reading the documentation.

I learned SQL injection after learning SQL first, how to use Linux by setting up file shares and web servers for my friends, and how to write malware by convincing the right people that I was worth sharing source code with.

Then came the OSCP. The certification that proved you knew your shit.

24 hours in a lab with machines to hack, points to earn, and a report to write with what little energy you had left. It was a badge of honor that demanded respect, and few people had it. But enshittification comes for all, and once the OSCP landed in a job posting under “preferred qualifications” for the first time, our journey as an industry to where we are now officially began.

The OSCP became a nigh-invincible staple for recruiters in the 2010s. Offensive Security, the company who designed the course and proctored the exam, realized they could make it a revenue engine — and so began what would eventually become a certification “ecosystem.”

Soon came other certifications like the original OSCE, a more advanced version of the OSCP that placed heavy emphasis on binary exploitation, as well as web and Wi-Fi oriented courses, all of which became household names for security professionals across the world.

OffSec had struck a gold mine, but they weren’t going to get away with keeping it to themselves.

The Disruptions That Learned Nothing

See, the value of the certification itself had gone up. Now there was demand for it in the job market. When you purchased Penetration Testing with Kali Linux, the companion course for the OSCP, it came with an exam voucher. The certification itself was the value holder, not the course content, since it was what proved you knew what you were doing.

With the demand increase came rising costs, and the price hikes made room for disrupters. HackTheBox and TryHackMe undercut the education piece for a fraction of the cost by removing the credential from the equation — with a far more accessible format than OffSec’s do-it-yourself PDF and lab approach.

In a single, polished web platform where much of the content was completely free, the early chapters of the penetration testing methodological corpus had been effectively democratized. However, though they had decoupled the credentials from the coursework and made education more accessible, the signal was starting to get lost in the noise.

The inevitable convergence of democratized training and credentials that boosted hirability was not far off: PNPT, eJPT, and others, where previously only CEH had any sway against the OSCP (not much, for obvious reasons).

The skill set that had previously derived its value from context and pre-existing technical background was now modularized, packaged, and sold in shiny bundles built on publicly available resources. Credentials attached, resume parsers happy.

The VC Deal That Always Ends the Same Way

Running training platforms costs money. You can’t just have hundreds of thousands of aspiring hackers spinning up little virtual machines to run Nmap against 24/7 without bleeding money. Luckily, there’s a whole industry that has made capital hemorrhaging their modus operandi: venture capital.

Taking on external funding meant adopting the same primary directive as every Silicon Valley unicorn that came before that always ends the same way: make more money so we can all exit handsomely.

Investors need recurring revenue more than life itself. And it has to go up, of course, so training platforms and companies turned to creating their own certification ecosystems, leaderboards, all while keeping the dream of employment alive, hoping to ride on the success of OSCP with HR reps reviewing job applications.

HackTheBox introduced “VIP” that allowed you to hack on your own target machine instead of the public ones that were getting reset all the time. TryHackMe added premium learning paths that you could access with a subscription.

One by one, they switched to recurring “all access” models — one easy platform, a stack of acronyms, and a promise that it’s all you need to land your dream hacking job.

The AI Pivot Is Just the Latest Version of This

TryHackMe founder Ben Spring has a new company. NoScope sells an AI-powered pentesting platform — not to practitioners, but to the companies that hire them.

I’ve seen many reactions, the gist of which seems to be that a company that made its name educating people to do actual work has potentially used training data from people to build NoScope.

I get it - to an extent. There are approaches to practitioner augmentation that are like Praetorian’s, releasing what I imagine are open-source versions of internal tooling. Then, there are profit-seeking approaches like NoScope, which sell their AI augmentation tooling to companies for a fee.

This dichotomy has always existed. Sliver and Cobalt Strike, Nuclei and Nessus - the open-source vs. paid divide has always been with us. What’s different now is who is doing the buying and what they’re being told it replaces.

AI “autonomous pentesting” — and even worse, “autonomous red team” — is poised to be the next thing companies, not practitioners, want to see. The race to a profitable exit is blatant, and it’s not going to change.

Those two things are being sold to people who buy tools, not use them. I’ll give you one guess which group is most upset by it.

What To Do About It

The goal is money. It is almost always money.

If you learn genuinely useful tradecraft and grab a cert along the way, great. But your professional development is not the primary purpose of any flashy training platform — especially one backed by venture capital or private equity.

So it’s up to you. Instead of outsourcing your education to companies that don’t actually care about it, take it upon yourself to explore.

Set up a home lab. Augment your own workflow (you do have a documented methodology, don’t you?) with open-source agentic tooling. Use it to make yourself a force multiplier that can stand up one day in the future and show a customer exactly why buying an expensive AI pentesting tool was a risk calculation error.

Or, you know, don’t. Just don’t be surprised when you’re staring at the back of the industry’s head as it flies away on this rocket ship.

A while back, a red team friend asked in a group chat how to handle management pushing agile on their offensive security team. My answer got really long really quickly.

Since red team management and practice leadership is my bread and butter, I have a lot of experience with fielding the sort of misguided idealism about KPIs and “stories” that comes from disconnected executives who mistake familiarity for wisdom, assuming that because one thing works somewhere, it must work everywhere.

What follows is a refined reproduction of my reply.

The first thing every project manager has to understand is that your app/platform/tool/whatever isn’t what gets the work done.

It isn’t the reason work doesn’t get done, deadlines get missed, or anyone misunderstood the requirements.

So changing the tooling every six months isn’t going to do anything except keep upper management off your ass because they usually don’t know better and annoy your team with more meaningless changes.

No end state, no solution.

It is the job of the project manager to define this and test whether it’s feasible with the people who will be executing the work.

Most of the time, especially in security consulting, the end result is outlined in a contract as a report or deliverable of some kind. For freeform projects like research efforts or tool development, replace the end result with an end state.

To do this well, you have to ask the right questions. What is the actual problem? How are we currently working and how do we want to be? Where are the bottlenecks?

Here are a few real-world examples from my career and the solutions my team came up with all on their own that were better than anything I could have come up with myself:

END STATE: We need a way to quickly and painlessly deploy access to client environments from which to conduct pentests.

SOLUTION: Vagrant VM templates that could be automatically uploaded to S3 for downloading by the client and, on boot, connected up to a Tailscale server and provided us remote access without the client having to punch holes in their firewall.

END STATE: $projectmanagementtool doesn’t support natural language due date setting, which is crucial to our project structures, so we need a way to deploy projects that saves us from manually selecting a bunch of dates from shitty dropdown menus.

SOLUTION: A custom Python script that builds projects entirely through $projectmanagementtool’s API.

END STATE: Our standard operating procedures for pentests (i.e., the bare minimum actions to take against a target) aren’t getting updated and therefore aren’t getting used.

SOLUTION: Make the SOP checklists the backbone for connected wiki articles so that new articles about vulnerabilities or exploit methods can’t be added without creating a reference in the SOP first.

If you can’t come up with a desired end state, your limitations become their constraints.

Bonus thought exercise: How many of the problems above have you seen “fixed” with a new product or piece of software?

Make your project templates freeing, not restrictive.

The most common types of projects your team works on should be templated and purely logistical.

Start date, end date, status update cadence, and that’s it. Everything else should be filled in by the practitioner. How they research, what they try, how they try it, etc. is all up to them. In a project management tool, that looks like this:

• Fieldwork Start + date
• Client Status Call + date
• Fieldwork End + date
• Report Draft to QA + date
• Report Draft Delivered + date

Quality isn’t a field in the template. It shows up in the work, or it doesn’t, and the status call is where that becomes everyone’s problem. This works really well for things like 5-day web app pentests that sales sends your way.

The less common, less rigid, and more freeform projects can still be templated as long as the template is purely logistical. Track what matters for the sake of billing milestones and contract terms. Leave the rest up to the experts doing the work.

A good attacker doesn’t need a script — they need a target and a scope. The rest is tradecraft. Give them enough constraints to ensure the delivery is to spec without suffocating them.

Pick a tool. Any tool. Stick to it.

Calendar events with notes, a project management tool, dedicated Slack threads, whatever. Just make sure everyone can go to the same place and see what the expectations are. Project management tools are references, not crutches. If you think a project management tool is going to make work easier, you’re delusional and avoiding the real problems.

Project managers should leave doers alone.

If you’re going to check in, build the check-in into the template upfront so it’s expected. Otherwise you’re just going to annoy everyone.

The person executing the work, or leading the project if there’s a team, is most likely going to come up with a better route or product than you could’ve come up with on your own.

Practitioners, especially hackers, tend to thrive with autonomy and room to experiment. Ask me how I know.

Learn to tell upper management to back off, politely.

Get desired end states from them, not dumb shit like “number of projects completed” or “number of tools integrated into methodology”. Ask them what they want to be able to say was accomplished.

What tangible improvements are they looking for? What gaps in the current product offering/security posture/etc. do they see that they want rectified? What are their true concerns?

This will help you cut through all the bullshit they heard on some podcast or from the board about “agile” and “story points” and get to the root of the problem, which is why the work needs to be done. Do not let them turn you against our boy Goodhart by making good measures into targets and, therefore, into bad measures.

Fix the communication problem, fix the project management problem.

People treat project management as some kind of equation to solve when it’s really just about communication.

The trouble is that communicating effectively is hard and requires more time spent on actually knowing, training, and trusting people than most companies have the time or energy for.

The irony is that it produces better outcomes than the alternative, just not the kind that light up a quarterly report.

Over time, taking this approach will make your team happier, give them more time to do what they’re actually good at, and outperform any version of this story where management got exactly what they asked for.

But be ready for upper management to see that and ask you to do 5-10% better year-over-year, killing the soul of your team for the shareholders.

My friend Jordan Mussman found a novel way of abusing regular functionality in the less binary to maintain persistence as a regular user OR root. Go read his research, and maybe give your environment variables a look while you’re at it.

By breaking, I mean any of the following:

1. Truncating the XML entries to only be the first chunk of the body content.
2. Only publishing the title and summary of the body content.
3. Killing the feed altogether (likely because you didn’t know you had one).

If you set up your site yourself with a static generator like Hugo or something more comprehensively painful like Wordpress, you may not even know that your site has an RSS feed built in by default. Anyone can point a piece of software known as a feed reader at the URL your RSS feed lives at and read what you write wthout having to visit your site to check for new content.

This is because the reader routinely checks the feed URL for new posts in the form of XML entries that should contain the title of the post and the full content.

Plaintext is not that heavy, and it is certainly not as heavy as all the third-party plugins and JavaScript abominations behind your frontend.

I have a list of blogs and channels I like to follow in the bar up top. I’ve updated it to reflect feeds that, at this time, do not adhere to RSS feed best practices of publishing, at a bare minimum, the title of the post and the full body content, as well as the feeds that used to work but have stopped.

For the sake of the open web - and especially for the sake of not hating your audience - stop breaking your feeds.

# Microsoft Sharepoint
    
## C2 Projects:
  https://github.com/looCiprian/GC2-sheet
  https://github.com/RedSiege/GraphStrike
    
## Detection:
  url: https://graph.microsoft.com/v1.0/sites/*/lists/*/items/
  url: https://graph.microsoft.com/v1.0/sites/*/lists/*

One of the biggest barriers to me writing anything at all is usually feeling like I need to say something long and profound, when in reality I more often have short commentary to make on what I’ve read (which I do a lot):

I decided to follow simon’s approach to creating a link blog, where I can share interesting links I find on the internet along with my own comments and thoughts about them.

I am deciding to follow Xuanwo’s approach to Simon’s approach for some of the early content here so I can fill it up without the pressure of changing the world with an essay.

• Codemadness
• computers are bad
• Julia Evans
• Ludicity
• Nyxt Browser
• Own Your Web
• Reform
• Secluded.Site
• (videos) Dreams of Autonomy
• (videos) Dreams of Code
• (videos) Fireship
• (videos) Vimjoyer
• (summary only) out there in space
• (summary only) Solene
• (summary only) fasterthanli.me

Hacking

• 0xRick’s Blog
• Adversary Fan Fiction Writers Guild
• Isosceles Blog
• SpecterOps Blog
• Tevora
• TrustedSec
• dirkjan
• hausec
• mubix
• (videos) webpwnized
• (videos) IppSec
• (summary only) 0ut3r Space
• (summary only) Black Hills Information Security
• (summary only) Graham Helton
• (summary only) Rants of a deranged squirrel.
• (title only) chompie at the bits
• (broken) Hacking Articles
• (broken) Make My Day [IO])
• (broken) eXploit

Security and Privacy

• Bad Sector Labs Blog
• coreboot
• Internet Archive Blogs
• News for libreboot.org
• Schneier on Security
• Sec Team Blog
• String Literal
• The New Oil

It’s been about two years since I wrote all of this for the first time.

The reception of the talk version at BSides Atlanta last year was good enough that I figured publishing these ideas and lessons for everyone to access would be beneficial.

But in trying to make it all perfect and complete, I’ve procrastinated publishing anything at all.

So, to remedy this, I’m going to publish in parts.

This is Part 0. Based on my massive list (mess) of talking points, here’s what’s coming up:

• Part 1: Where To Start
• Part 2: Improving Your Personal Health
• Part 3: Setting Professional Boundaries
• Part 4: Smash In Case Of Emergency

Recovery First, Prevention After

I will talk about burnout and how to prevent it, but more importantly, I want to talk about recovery.

Why?

Because most people have already experienced burnout, and I suspect a lot are still in it. I have to suspect because, though I have tried, I cannot find any data on how many people have recovered.

There are plenty of data sources for how many people have been or are currently burnt out, and prevention only matters if you’re not burnt out already.

Why even talk about this?

Because the working world has a burnout problem, and to make matters worse. Infosec as an industry also has a talent problem.

According to plenty of sources, there were 2.72 million job openings in 2021. That number is going down, but it’s not one to laugh at.

Meanwhile, 75% of employees said they’ve experienced burnout, and 56% of employers admitted to have retention issues, 36% of those surveyed by Eagle Consulting said their organization isn’t doing anything to help them NOT be burnt out, Gallup found that burned-out employees are 2.6 times as likely to be actively seeking a different job, AND that only 60% of workers can strongly agree that they know what is expected of them at work.

The bottom line is that people are burning out, a lot of them aren’t getting help, and almost as many have no idea what standard they’re even supposed to be meeting.

Maybe you can see why I’m not confident about that number going down reliably. What are we missing out on because the talented people we already have are at or near the end of their rope?

Crime pays a lot, actually

Adversaries are making more money, their jobs are easier, and they work remotely. I’ve talked to people I know who were in ransomware gangs or are currently in them, and most of them say their work lives are easier.

What they told me boils down to a few simple points:

• No one is asking them to return to the office and commute through traffic hell
• The pay is better than what they might make legitimately
• The work is generally easier (since many targets aren’t as mature)

How are salaried, commuting, underfunded infosec professionals supposed to keep up?

There is a greater mission and much of the industry is not prepared to accomplish it.

Disclaimer

Before I go any further, I need to get some things out of the way:

• I am not an expert, a medical professional, or a psychiatrist
• I cannot diagnose or account for existing mental illnesses, personal situations, or other variables

But rest assured, I have had my fair share of hard times. I am no stranger to mental illness nor trauma. I know that life can be hard and there are a lot of factors at play.

I get it. I’m not here to sell you a cure-all, or even a cure-most. I’m here to share what worked for me and maybe impart something useful to you.

How I Got Here

Like many, I spent the majority of 2020 working too hard, burning too hot, and not getting the things I needed to be happy.

The company I worked at was in a period of intense growth where we had plenty of new pentesting work to do, but some of us still needed to make audits happen to pay the bills.

During that time, I started to study for my OSCP, and after seven months, it had knocked me out. I would study for 3-4 hours per night and all weekend in the labs, grabbing flags and honing my methodology.

I failed my first exam attempt in late September but came back with a vengeance by the end of October. Then I descended into one of the deepest ruts of my life.

Collecting debt from yourself

What confounded me is that I was just doing something I loved: learning and improving my pentesting skill set.

But the price I ended up paying was steep, and it took a lot longer to cover my debt to my passion than it did to destroy my passion.

The year after (2021) was filled with attempts to pursue my passion without the energy I needed, leaving me feeling unfulfilled and frustrated at my sudden lack of progress in my career, but even more disappointingly, lack of appreciation for something I was once fascinated by.

I would listen to my favorite security podcasts and roll my eyes when people would talk about how energized they were and could spend hours just learning. My cynicism was through the roof, and the problem wasn’t them - it was me. I needed to feel better. My new state was not sustainable, and I needed a solution. That’s how I came up with what’s in this blog.

It took me a long time, but I made it, and I want to share that with anyone who’s in that same place.

Look out for “Part 1: Where To Start”, coming soon.

This has sent my typical corner of Twitter into somewhat of a debate.

Dubbed “Infosec Twitter”, exploit researchers, red teams, SOC analysts, CISOs, DFIR teams, and more can reliably be found commenting on the news of the day, sharing research, discussing breaches, and more.

When I joined Twitter in early 2020, I did it primarily because I was starting to present at conferences and knew that it would benefit me to have some kind of network, and LinkedIn still grossed me out.

What I found there was a mixture of enlightenment and confusion, of insight and of disappointment.

Amid my newfound source of threat intel, tradecraft, and (of course), memes, was something I didn’t expect: the hacker culture I grew up in was surprisingly absent.

Instead of discussing information freedom, privacy, or technology that helped people, I found arguments about whether offensive tooling was okay to publish, whether EDR is good, and whether infosec is an entry-level field (to list only a few).

The kinds of topics I used to see regularly on forums and IRC were rare to see.

Luckily, curating who you follow helps a lot with this. A muted word here, a muted account there, and you can end up with a feed of topics you mostly care about.

This has changed even in the short time I’ve had an account, though, in that Twitter has been serving more and more advertisements and struggling to be profitable.

As Elon Musk has taken over Twitter and cleaned most of the house out, it’s become evident that a platform up for purchase by any individual is not a platform conducive to user freedom and control.

This is not a blog about ideological statements for or against Musk. It does not matter to me who is able to take over Twitter for $44B, only that someone can, and only as long as there are alternatives.

However, in disappointingly predictable fashion, certain sections of Infosec Twitter have been outspoken about the most popular platform, Mastodon, being unrealistic and a non-answer to the problem of unitary platform control.

This would be entirely reasonable if many accounts with large audiences were not stating inaccurate information about it as insurmountable downsides of the federated alternative.

Federation Mythbusting

The purpose of this blog is to address as many of these myths as possible with accurate information. So here we go.

You have to host your own server

Though it would solve a lot of problems outlined in sections after this one, no you do not have to host your own.

You can join any instance you want and see content from users on any instance that is federating with yours. Conversely, any instances not federating with yours (for any reason), will be invisible to you by default.

You can’t verify yourself and can be impersonated

Again, not a problem if you host your own, but let’s assume you’re not able to or don’t want to. That’s fine.

You can verify yourself via a relative link in a different place, such as Keybase or your own website. By simply creating a link like this on the homepage of your website:

<a rel="me" href="https://infosec.exchange/@rybaz">mastodon</a>

…a Mastodon instance will show a green checkmark in my profile, verifying me as the owner of that domain, which I use as my primary source of identity on the internet.

The blue check on Twitter is only a luxury for certain high-profile people anyway. If anything, those most at-risk for impersonation are those who Twitter doesn’t deem worth verifying, rendering them helpless to stop it.

Content moderation is a problem

Aside from this being a problem on every social media platform, Twitter included, Mastodon instances can block entire other instances themed around content they want nothing to do with.

If you join a mainstream instance with lots of people, you’re likely to run into content you’d rather not see, but that’s why:

1. There are so many instances to potentially join, often centered around interests or subcultures.
2. You can host your own.

DMs can be read by admins of instances

Also a problem on Twitter and most any other platform owned or operated by someone else.

Have sensitive conversations over channels you trust, like XMPP, Matrix, Signal, Session, whatever.

It’s confusing

Of the people I interact with on a daily basis, including on Twitter, I am on the lower end of the intelligence scale, and that’s a good thing.

If I can spend 10 minutes Googling how Mastodon works, so can everyone else.

This goes without saying that, in my short time on a Mastodon instance, people have been more than willing to help new users figure out how things work. All anyone has to do is ask.

We should just start a forum

I love forums. I miss forums. I learned a ton from them.

Luckily, there are federated forum platforms like Lemmy that accomplish that goal of asynchronous, topic-based discussion, while being interoperable with other ActivityPub-based implementations.

We don’t need ANOTHER social media site

I agree. Completely.

I hate social media, but it’s the way of the world, and I want a professional network. But apart from LinkedIn and Twitter, I don’t have any other social media accounts, so the “too many platforms” exhaustion isn’t very strong for me.

Federated platforms and protocols are meant to clean up and change the noise, not add to it. It must be viewed as a different way of interacting with digital communities in order for value to be extracted.

The Ethos of Federation

Switching to Mastodon or any other federated technology shouldn’t be driven by the volume of content there is to consume there, but a desire to invest in systems that are controlled by users instead of corporations, investors, or executives.

Or where content isn’t force-fed to you by an algorithm to make you angry, sad, happy, entertained, and lonely all in a single session of scrolling.

Or where your dopamine levels aren’t corporate growth metrics, measured by variance of spiking and sinking and correlated to profit.

Federated services aren’t meant to be Twitter or Facebook competitors. If you’re looking for one to replace the other, you’re going to be disappointed, especially if you have a large audience on one of them.

But large audiences and maximum reach is not what federation is about.

It’s about taking back platform control and using open protocols.

It is about quality over quantity.

It’s about fostering the free and open exchange of information, interoperability, and highly censorship resistant content. The same arguments for Signal relays or Tor nodes in oppressive countries can be made for Mastodon, Matrix, or any other federated tech.

If sufficient amounts of content is the #1 value driver for you to use a platform, that’s fine, and centralized media may be what you actually want, as it’s more conducive to quantity.

You’ll ultimately be disappointed with platforms that emphasize user freedom over how long they can entertain you.

For better or for worse, that is the current dichotomy.

Federated platforms won’t get there overnight, but the dynamic of “where everyone else is” only changes based on the decisions of individuals, something the Twitter algorithm would rather you not do.

If everyone waits for everyone else to go first, nothing will change.

There is nothing to stop someone else from taking control of Twitter or whatever comes next, be it a competitor or clone-like alternative.

There are several reasons for this, the first being that I don’t want to deal with the bugs and resulting mishaps of an implementation in beta (not right now, at least).

Though I’ve read that this has been fixed recently, as soon as I spun up my Conduit server, I couldn’t communicate with most of the rooms created on existing Synapse servers due to later versions of rooms not being supported yet.

The second reason is that I’ve been evaluating some other options, mainly Session. Though it’s not perfect, there are some things I like about it that are impactful enough for me to put the Matrix ecosystem on pause for now. To be clear, I still love what Matrix is doing, but running my own instance is just a little more than I want to deal with at the moment, and federation is the only way to truly realize the full range of benefits offered by the protocol.

Session Messenger Breakdown: Pros and Cons

Pros

• Uses Tor by default
• Decentralized by default via volunteer-run nodes
• APK is available via F-Droid
• Doesn’t require any personal information on account creation

Cons

• Uses Google for notification services*
• Desktop client is Electron-based

*There is an option to not use Google’s notification servers, but it’s a lot slower and you can’t set the check interval. From their FAQ:

If you choose slow mode, the Session application runs in the background and periodically polls its swarm (see What is a swarm) for new messages. If a new message is found, it is presented to you as a local notification on your device.

If you choose fast mode, Session will use Google’s FCM push notification service to deliver push notifications to your device. This requires that your device IP address and unique push notification token are exposed to a Google operated push notification server. Additionally, you will expose your Session ID and unique push notification token to an OPTF operated push notification server, for the purpose of providing the actual notifications to the Google FCM server.

Session vs Signal, and Why I Will Use Both

I see Signal and Session as complimentary layers. Session is arguably more privacy-friendly than Signal for a few big reasons:

• Signal servers are centralizedconduit
• Signal APK is not available on F-Droid
• Phone number required for account creation

Despite this, Signal has an advantage where Session does not: the ability to replace SMS apps. Signal has basically become a catch-all for anyone who might be using it with their phone number. This only applies to around 3% of my contacts, but that’s better than 0%.

For anyone else who I communicate with on a regular basis, most of them care about communications privacy and security enough to use a separate app to achieve it.

The Ideal Future Setup

More recently, Rocket.chat announced it’s building federation capability via the Matrix protocol, which is a refreshing move. Matrix has only ever wanted to be a protocol in the same way that XMPP is a protocol, leaving the frontend messenger client responsibility to others if you don’t want to use the one they provide.

A single protocol that can be audited by the community is the best case we can hope for outside of complete decentralization. There’s a reason why e-mail with PGP is still considered one of the best ways to communicate securely and privately: you at least control the keys.

If the answer to the problem of walled messenger gardens is Matrix, it’s Matrix. I would love to see more of these platforms begin to adopt interoperability so that people can finally stop juggling digital communication channels based on contexts and pros/cons lists.

While studying for CEH (hold the judgment, please, I was young and naive), I had to resort to far more than just the EC-Council curriculum. If you’ve ever tried for one of their certifications, you’ll know why: the material isn’t good enough.

For the OSCP, I had the same experience. The PWK lab was not diverse enough to make me feel truly prepared, and looking back, I’m glad I resorted to sites like HackTheBox, Vulnerable Hacking Labs, and Vulnhub for extra practice. Luckily, many outstanding individuals like TJNull had compiled lists of practice machines for me to reference.

After spending time learning advanced pentesting and red team tactics in a useful-but-never-too-deep manner, I’ve landed on exploit development as my next deeper learning path. I’ve built a roadmap for myself entirely made up of free resources and compiled it here.

I may edit this as I go, and I will post reviews as separate blogs if warranted. If I do make a meaningful update, I’ll be sure to mention that.

(Prerequisite) x86 Assembly and C

NASM and C are more important than I realized at first. A strong understanding of both will help you tremendously as you get into the actual exploit development and research parts of this.

Resources will be mostly focused around Linux to ensure that the barrier to entry is as low as possible. Once I get into Windows, I’ll add resources around that OS, but I’ll stick with what I know best for now.

• OpenSecurityTraining2 - Debuggers 1012: Introductory GDB
• OpenSecurityTraining2 - Architecture 1001: x86-64 Assembly
• OpenSecurityTraining2 - Architecture 2001: x86-64 OS Internals
• Learn-C.org

Books:

• The C Programming Language 2e

Linux Exploit Development

This list contains a healthy mix of challenges, guides, course material, and books. These resources are invaluable and I cannot believe they are free.

• Exploit.Education - Phoenix
• Exploit.Education - Nebula
• OpenSecurityTraining - Intro to Software Exploits & Course Textbook: The Shellcoder’s Handbook
• pwn.college
• Exploit.Education - Fusion

Books

• The Art of Exploitation 2e

But first, what is paranoid realism, and what makes someone a paranoid realist?

Healthy Doses of Paranoia

Having worked in security for so long, it’s difficult to not see most technology as fundamentally broken. Web apps are built on APIs without any access control, EDR can’t keep up with some of the most basic bypass techniques, and on and on we go.

Test turning your own webcam on via Meterpreter and you’ll understand what I’m getting at: this shit is easy, and you may not know when you’re being watched.

There are three ways of approaching this new, substantiated feeling of paranoia: ignorance, fatalism, and realism.

The first is the easiest and just involves sticking your head in the sand. The second is deciding that because there are things you can’t control, you might as well not do anything about anything.

Finally, realism (or pragmatism, if you prefer it) involves doing the best with what you have. Technology will never be hack-proof, but it’s also never been easier to take some meaningful steps to improve your resiliency against the inevitable.

All three can be characterized by their response to the idealism of perfect security:

• Ignorance is simply unaware of it or refuses to be aware of it.
• Fatalism is aware of it but sees it as unattainable and therefore worthless wholesale.
• Realism is aware of it and knows that something is better than nothing at all.

One of my favorite books, “Absolute OpenBSD, 2nd Edition: Unix for the Practical Paranoid”, was written for this mindset. From the book’s introduction:

It’s not that everyone on the Internet is trying to attack you, but there’s always someone who wants to break into your system. Even if you think you have nothing of value, someone wants to own your computer. And you won’t realize the value of what you have until someone else has it. That’s just human nature.

If you’re not paranoid on the Internet, you’re in trouble.

Michael W. Lucas, “Absolute OpenBSD, 2nd Edition: Unix for the Practical Paranoid”

Dispelling Fatalist Mythology and Threat-model-ism

Choosing to remain ignorant is the choice of each individual. I can do nothing about this, and I wish you luck if that’s your path.

Fatalism, on the other hand, I have a refutation for. Additionally, fatalism’s close cousin, threat-model-ism, this is for you, too.

The argument that you should only care about encryption if your personal threat model requires it, whether for messaging only or for as much internet traffic as possible, is made by many seemingly knowledgable people, much to my concern.

For example, a VPN will not make you anonymous on the internet. Sure, it can hide your source IP from the destination and it keeps your ISP from snooping on a good portion of your traffic, but it doesn’t do much more than that.

Keeping my ISP out of my data in transit is a good enough reason for me to use one, even if it’s just to keep them from throttling certain services, as Comcast did with Netflix not long ago.

I also would rather them not sell my browsing habits to advertisers or tell me what proper use of the internet constitutes. Even if these practices are not predatory to an Orwellian level yet, they could get there in the future.

And even if they don’t, caring about privacy as a principle is the only reason you need to run a VPN, encrypt your messages, et cetera.

Lastly, threat models evolve. Many small businesses probably wouldn’t have considered themselves very interesting to multi-million-dollar ransomware gangs 10 years ago, but they’ve been such easy targets recently that they’re now one of the most common victim types.

I could go on for much longer about this, and I may do so in future posts, but that’s not the goal of this one.

What is the EARN IT Act?

The EARN IT Act is yet another government attempt at breaking encryption in order to protect children online. While protecting children is a noble and worthy enterprise, like any other effort, there are methods that work and methods that don’t.

According to Stanford, not only does EARN IT not work, but it will actually do the opposite of what it intends to do:

…the EARN IT Act would do little to protect child sex abuse victims – to the contrary, it risks making it even harder to track down and convict offenders.

I encourage to read the entire article linked above. In the end, true to form for over a decade, this is a case of people with power exercising said power in areas they fundamentally misunderstand. What is unclear is how long this phenomenon will continue to plague us.

While we have no answer to that question, we can at the very least take steps to reduce the impact of weaponized ignorance of this sort by utilizing systems that are the opposite of fragile, or as Nassim Taleb puts it, “anti-fragile”.

Communication channels that are not fragile are the true resilience to legislation like this, so we need a way to evaluate them and choose the ones that really work.

Evaluating Anti-fragility (AAA)

In order to objectively evaluate communication platforms and protocols for anti-fragility, we have to establish criteria. The information security industry has been using confidentiality, integrity, and availability (CIA) for a long time and it’s a good measurement set, but it doesn’t really cover enough for me.

Instead, I’ve come up with the three As to evaluate a platform or protocol: availability, anonymity, and autonomy.

• Availability: it does not have to suffer impact of external events.

Something that is completely out of my control, such as downtime of a server I don’t own or maintain, should not inhibit my ability to communicate. Whether it’s the Signal servers, a CDN, or the entirety of us-east-1, my communications should be unaffected.

• Anonymity: the ultimate privacy is pure anonymity, and this must be possible.

I should be able to completely control the details of my identity, from source IP to registration details. No phone numbers, email addresses, physical addresses, or anything that sits outside the function of the platform/protocol.

• Autonomy: it can be used without third-party permission or interference.

I should be able to use it without anyone else’s input. No one, including my ISP, VPS provider, domain name registrar, smartphone app store, federal government, et al should be in control of how I communicate, nor should they be able to easily place an injunction on my use.

Note: These metrics operate on the idea of perfection, so nothing will likely ever fully meet them. This is on purpose so that we can remain objective and honest as we are realists here, and we prefer better over stagnant.

Case Studies of Popular Platforms

Below are some examples of how common messaging platforms and protocols match up to AAA. Let’s use a 1-5 scale.

Note: This is not a comprehensive or systematic list, nor are each of the platforms I mention in the list comprehensively or systematically scored. I am trying to make a point with some fuzzy numbers, though I may soon catalog these by metrics and score them more consistently.

SMS

Availability: 0 Anonymity: 0 Autonomy: 0

Not much to say here. It’s horribly insecure, out of our control, and dependent on cell towers we don’t own.

iMessage

Availability: 3 Anonymity: 2 Autonomy: 1

This is probably my favorite one to pick on because some iPhone users see non-iMessage users (or, derogatorily, the undesirable green bubbles) as members of lower socioeconomic castes, which is profoundly cringe.

I’m not exaggerating either. I’ve spoken to people who purposely exclude Android users from group chats with friends for not having iMessage. This has happened to me personally, also, and all I can do is look at all my Signal conversations and not care.

It’s a great communication channel for iPhone-to-iPhone communication, but it is by no means anti-fragile. The servers and OS (the user gateway) are fully in Apple’s control, as is the encryption.

I’ve heard that it’s also a uniquely American thing to use iMessage universally, which brings me to my next platform.

WhatsApp/any social media chat feature

In Europe, Asia, and many other areas of the world, WhatsApp is the staple communication plaform. However, like any platform run by a giant company (Facebook), it scores fairly low on all three As.

The data is definitely being collected, the traffic runs through centralized locations…need I say more?

Availability: 3 Anonymity: 1 Autonomy: 1

Case Studies for Niche (Non-Mainstream) Platforms

Signal

Availability: 2 Anonymity: 3 Autonomy: 1

Signal is the app that actually made me write this blog because I resisted it for a very long time.

I wanted a perfect solution for all my non-SMS communication that wouldn’t add to my existing paranoia, but many of the alternatives at the time were difficult to adopt for most people or were being bought up by bigger corporations with unclear motives (Keybase and Wire, looking at you).

However, I had to realize that some encrypted chats were better than no encrypted chats. This is paranoid realism at work and is how you have to approach this stuff sometimes.

Now if they would just build an F-Droid version…

Telegram

Availability: 2 Anonymity: 3 Autonomy: 1

This is the one I really want to drive some points home about.

It’s not the only service that masquerades as an end-to-end encryption service for chat while maintaining a master encryption key and centralized servers.

Telegram’s clients are open-source, but their back-end infrastructure is not. This is where everything is stored and where all the data travels through, so this is a big red flag.

Any possibility of compromising any part of AAA is not acceptable. There has to be trust between developers, the platform, and the users, and this is not possible without completely open-source code and standards, front to back.

Matrix/XMPP

Availability: 4.5 Anonymity: 4.5 Autonomy: 5

I am well aware that these are not the same thing, but I’ve lumped them together because, in my opinion, there are the best options we currently have.

• The code is all open-source, server to client and back.
• The encryption is truly E2E, which we know because we can look at it.
• You can host your own server for yourself or anyone else.
• Communication is federated, meaning no central server controls who I talk to.

That said, I’ve only given them both 4.5 for the first two As. This is because without a central server, they are dependent on external factors such as your VPS provider and other infrastructure you have no control over.

Perhaps if you were to self-host them at home, that would change, but I haven’t thought through that one.

Between the two of them, the cons that they don’t share cancel each other out and, I think, provide the best option for secure messaging at the moment.

Honorable Mentions

These are some projects that I think have promise, mainly because they’re doing things differently. I don’t use them personally and never have, but I expect that they will eventually have niche followings of their own and am watching them with great interest.

• Briar
• DeltaChat