Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

A CoPilot Studio Customer Support Management service by McKinsey sparked some interest in hacking. The system contains a service inbox that listens for inquiries, looks up previous engagements, and then responds via email to the request. To test this out, they created their own version of the bot using Microsoft CoPilot Studio with a custom knowledge source with the customer information and a "get records" tool to access the company's CRM.

Using a prompt injection, they were able to confuse the bot to send an email to the attacker's email address instead of the proper one. The new prompt includes disclosing the knowledge sources and tools as well. With this information, they are ready to tackle the service further. This serves more as a recon step. It appears that this is somewhat of an access control issue letting all email contact the bot.

In the next article, they simply ask it to leak the entire file for the customer information using prompt injection. The same thing can be done via a prompt injection on the CRM as well.

Sadly, there is no complete "fix" for all of this besides restricting the email from which this can be received. Where a bot can access sensitive data, a user can also steal it through prompt injection. The tone of the article is a little condescending, which I don't appreciate though. The goal is to make the world more secure and have folks be more interested in getting security help; tones like this create a gap between developers and security imo.

GitHub Actions are actually pretty hard to secure against all of the threats. In particular, insider threats. This article goes over some GitHub protections that can help a repository be better.

Branch Protections prevent modifications to specific named branches. This prevents straight pushes to main from compromised developers. This can also be used to require signed commits or request pull requests before merging.

Another good feature is Dismiss Stale pull request approvals. This prevents a PR from being approved and then having a major change being made from underneath it. Again, insider threats are very hard to protect against.

GitHub Actions can have Secrets as well. One annoying component about this is that a user with push permissions on the repository can create a branch with a new GitHub action and just leak the secrets. To prevent this, I have required PRs from users only and not allowed branches except for admins.

Environments are a collection of variables and secrets in GitHub. They can be created with specific names, like prod and dev. Secrets within an environment take place over those in the secrets directly.

The environment feature has several helpful features. First, you can have required reviewers for using a particular environment. Second, you can only allow the environment to be used within a branch, such as a protected branch. This prevents the stealing of sensitive secrets as a result.

There are also Tag-based protections. Restricting deletions, blocking force pushes, and requiring deployments to succeed are all somewhat helpful.

When WebOS has a USB thumb drive plugged into it, it opens a port on the TV. This allows peer devices to call the API /getFile?path=xxxxxx to get files from the mounted USB.

The device doesn't have any filtering on the path for directory traversal vulnerabilities. By using a classic directory traversal, you can read arbitrary files from the system.

This by itself is bad but what can we do with it? There's a database that contains peer authentication keys. By stealing these keys, it's possible to bypass authentication on the secondscreen service. With this, they can enable developer mode to install arbitrary apps and gain control of the device.

The vulnerability is simple yet the impact derived from this is terrible. Good find! I was also surprised to find that the PoC includes a Docker image for the TV, making it easy to run.

A tool for bypassing TLS verification on Linux. This makes intercepting clients much easier.

Electron packages are signed in order to prevent tampering. Many applications, such as Signal and 1Password, use this.

Electron is based on the Chrome browser. V8 heap snapshots occur from a user-writable directory in Chrome. These are used for rendering various browser components from disk instead of doing it over and over again.

The bypass for the code integrity is simply done by modifying the V8 snapshots on the system. By clobbering Array.isArray() in JavaScript, the author can easily trigger a crash. Naturally, this hijacking of functions and be used to add arbitrary code and circumvent all integrity checks.

This vulnerability is super simple but requires a deep knowledge of Chrome. Understanding something popular very well can lead to seemingly simple security issues with devastating consequences, such as this one.

OAuth is a fickle monster. This post dives into a website that was automatically redirecting to the Referer header when coming back from the OAuth flow. Likely, this was a multi-website system where they had a global OAuth page and needed to get back to the original page. Of note, the Referer header survives redirects.

An arbitrary redirect in OAuth is usually an automatic game over. This is because the auth information itself is stored within the fragment or parameters in a URL. So, the goal of the attack was to trigger a redirect to steal the token information of the user.

Upon trying to abuse this functionality, they learned that client-side redirects will remove the fragment but server-side will not. In the standard flow for OAuth, a client-side redirect was used. However, by changing the type to be id_token instead, this triggered a server-side redirect to keep the code around.

They tried reviewing the OAuth providers used by the application: Facebook, GitHub and Google. Facebook had a confirmation step that changed the referer, and GitHub doesn't use the response_type parameter. Gmail had a selection screen if users had more than one account. By adding the parameter prompt=none, this prompt was bypassed though.

The final flow of the attack tricked a victim into visiting their website and used window.open() to trigger the OAuth flow. Since they were the referrer of this interaction, it would eventually redirect to their website, where they could steal the token information.

This blog post was a good example of seeing bad functionality and finding the primitives to trigger it properly. This contained numerous small tricks and required considerable perseverance. Great write-up!

This is a Cross-Site (XS) Leaks CTF challenge with a couple of nifty tricks. The user creates a page with HTML injection that the admin then clicks on using a tool like Selenium. The goal is to leak the user's session cookie using this with a known token format. This uses a PHP server that is behind Caddy.

The limitations are also interesting. The content for the HTML injection is limited to 1024 characters. The characters can be 0x20-0x7E and newlines, but block several things like astriks, backslashes, and a few keywords. There's a CSP that prevents outbound loading of scripts, inline JavaScript, or web requests.

The browser has what is called Quirks Mode that relaxes some MIME checks. If the document loads a page with the wrong content type, it will treat it as text/css anyway. This challenge was set up to NOT use quirks mode because of the <!DOCTYPE html> at the beginning of the page. Can this be forced into Quirks mode?

If the beginning part of the page were to change in some way before loading, then this would be possible. In PHP, there are multiple ways to trigger errors that will be put at the top of the file instead. In previous research, this was done to drop CSP headers. In this case, if you added a large number of variables (more than a thousand), PHP gives a warning that ends up disabling quirks mode! Neat!

The HTML injection occurs. However, there is no practical way to exfiltrate the data due to the CSP. So, the only way is to use CSS data exfiltration. This is why the issue pointed out above with the Quirks mode is so helpful! With a simple payload, it's possible to change the color of the page.

Because of some character limitations, we need to find a way to load more data for our stylesheet. Luckily, the PHP 404 page will reflect input and can be used for this. Using /not-found.txt?{}body{background:limegreen} is a good sink for this.

Finally, in the CSS selectors, use the input:valid flag to decide whether to render the data or not based on the input from the previous step. Why does this matter? Frame counting! By viewing the page and counting the frames, we can figure out if the code was correct or not.

Overall, a pretty neat set of tricks! CTFs are sometimes on the cutting edge and niche; this is a perfect example of that.

FreePBX is a web-based GUI for managing the Asterisk VoIP phone system. The application is easily set up on a local network and is built on PHP. The ability to access this would result in the interception/stealing of phone calls, voicemails, etc.

In August 2025, a FreePBX user started getting strange error messages in their access logs. A day later, a user found a file called .clean.sh on their box that was cleaning up after an exploit. This is a serious problem! This clearly indicated a remote code execution vulnerability. The WatchTower team had previously reported a post-auth RCE bug to the developers, who didn't care. This time they did. Why?

This appeared to be an unauthenticated RCE vulnerability. Upon reviewing the vulnerability summary, it had to do with bad input validation. Command injection? SQL injection? Still not sure. But, they had a clue to go off of - the issue was in the Endpoint module. This was a plugin for FreePBX that simplified many aspects of the provisioning and management process.

At first, they were looking for SSRFs because requests made from localhost bypassed authentication, but this did not work. After trying to call various modules with a single quote in the parameter, they were greeted with a nice SQL error! This led to a SQL injection that was obviously quite bad. This was still post auth though.

Out of curiosity for the attacker, they set up a honeypot. After waiting for a little bit, a shiny new backdoor appeared on the system! This was calling /admin/ajax.php without authentication. But how?

FreePBX contains a module/extension system to add to your PBX instance. To do this, the module parameter alongside the command is used for routing. Using reflection logic, it will determine if a class exists via class_exists in PHP. This will attempt to load a custom class from risk, in the case of a local system like this.

In the custom PHP autoloader implementation, the function fpbx_framework_autoloader attempts to load the code. This will do some black magic to find the proper file to execute. In practice, this code allows for the execution of any PHP file with the appropriate part of an install. Specifying the module as FreePBX\\modules\\Endpoint\\install results in the install command to run, for instance.

With the authentication bypass, it's not possible to exploit the SQL injection to gain access to the device! This results in a complete authentication bypass for some modules. In the patch, it was only the SQL injection that was fixed and not the authentication issue. This is a design-level issue that likely requires significant effort to resolve.

In the middle of 2025, Sean Heelan made a post describing the usage of an LLM to find a use-after-free vulnerability in the Linux Kernel that was similar to an existing bug. In the post, Sean explains how the LLM found the bug and the limitations of LLMs on security reviews at the moment.

The goal of the author was to rediscover this vulnerability consistently using LLM tools without prior knowledge of the codebase. They wanted to reach the code without needing to build/compile anything. Luckily for them, CodeQL had just launched a system that could analyze code without the need for building the code. Additionally, they didn't want to use an agenetic framework.

Initially, they used a simple cross-function UAF detector in CodeQL that generated 1700 possible UAFs. With this, they used the tree sitter tool to improve the information as a plugin to CodeQL. Additionally, this allowed for a maximum call depth that limited the findings to 217. They pointed their code at the entire /fs/smb/server/ implementation of the Linux kernel. This is 26.4K lines of code, for context.

With these 217 findings, they came up with a plan. First, triage with a smaller model. This would define the "use" from the downstream free() to avoid the larger model token burning. The second step, analyze would ask more profound questions about how the free memory might be accessed, exploitability, and potential fixes for the code. To do this, they created a tool called Slice that can take SAST input and feed it to an LLM for usage.

Between both of the run types, it costs $1.75 for triage and $1.64 for analysis in a total of 7 minutes. By running this on GPT-5, it found the vulnerability 10 out of 10 times! They found the bug they were looking for but don't mention the amount of false positives that came along with it. From reading the JSON output, it may have been zero!

The usage of LLMs is going to revolutionize many things. By providing the LLM with the proper data and a specific task (finding UAFs in SMB Linux server code), it performed pretty well. In the context of bug bounty, where you want to find a bug and don't need to find every bug, this seems very useful to me. This tool appears fantastic, and it's something I'll likely use in the future for my own needs.

The Docker internal HTTP API is used to control most of Docker. Exposing this is an automatic game over in terms of container security. This is because you can start a privileged container that has access to the full host.

The author of this post was internally mapping the localhost interface on the VM out of paranoia on Docker Desktop for Windows. While doing this, they found that they could access the Docker API from the container.

This exploit is so bad that it works from an SSRF vulnerability. It's fascinating that this issue has existed for so long without being noticed before. According to the author, Docker doesn't have a security program, which may be part of the reason this is the case. Regardless, fantastic impact on this bug!