Using the Windows Remote Procedure Call (RPC) interface is an interesting concept when conssidering the fact that it allows you to call functions, over the network in a remote process. I wanted to better understand how RPC worked, and decided to build my own RPC interface to help with that. As a result, I wrote an RPC interface that will spawn a reverse shell given an IP address and a port. In this post I’ll show you how to do just that and what I learnt in a few sections:
Phew! This year’s hacker summer camp is packed with presentations from several hackers across the globe at Orange Cyberdefense. I can’t possibly go into all of the many details, but hope to give a somewhat compressed view of the highlights!
This year we have a total of 10 representations. Four of those are DEF CON 29 talks, where two are main stage talks, one a demo labs talk and one a radio frequency village talk. On the training side of things, we’re delivering five courses at BlackHat USA 21, and one course at Ringzer0. I’ve been fortunate enough to see the behind the scenes preparation that goes into these and can’t wait for the world to see and experience them too!
Wi-Fi is everywhere and having a better understanding of it can fair you well! Over the years we have made various tools such as hostapd-mana to enable attacks against Wi-Fi, and then tools such as berate_ap for those people who don’t want to, or have to, learn how to use hostapd-mana. In our Unplugged: Modern Wi-Fi Hacking course you will be forced to shun the convenience of automated tools such as berate_ap and get dirty with setting up Access Points and Client configurations in a terminal window to ensure you have a good understanding of what is happening under the hood.
We are excited to be presenting our Hands-on-Hacking Fundamentals (HHF) course at this year’s BlackHat USA 2021 conference. In our HHF course we explore the fundamentals required to grow your hacking skills where you can utilise your newly learned skills with practical, real world hacks in our custom lab environment. This blog aims to demonstrate the fundamentals of networking and scanning using the defacto Network Mapper “Nmap” which is one of the many tools utilised in our course.
Here at Orange Cyberdefense, clients often ask us to test and help secure their infrastructure. We do this a lot. We test clients, we test ourselves, and we set up labs to test new ideas and tools. We’ve become quite good at this, if we say so ourselves, and would love to share some of the lessons we’ve learned along the way with anyone that would be interested. That’s what our Enterprise Infrastructure Hacking course is all about: it’s our way of sharing what we’ve learned with you.
A few months ago I was exploring the write-ups and video solutions for the retired HackTheBox machine – Quick. It’s during this exploration that I came across HTTP/3. For those that are not aware, HTTP/3 is the upcoming third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, succeeding HTTP/2.
Now, to be honest, my knowledge of the Hypertext Transfer Protocol (HTTP) has mainly been restricted to the HTTP/1.0 and HTTP/1.1 specifications. In particular, as that is the main specifications of the protocol we (security pentesters) observe in Burp (our intercepting proxy) when assessing web applications. We are familiar and comfortable seeing HTTP GET/POST requests and the myriad of responses that can be received (e.g., 400, 503…)
Introduction What seemed like a regular Cross-site Scripting (XSS) vulnerability on an HTTP 500 “Internal Server Error”-page, I managed to turn into a one-click account takeover on an assessment. In this blog post I want to describe the path I took to achieve this leveraging a known Cloudflare WAF bypass and Google analytics to extract session tokens serving as a CSP bypass.
Reconnaissance At the beginning of the assessment, it quickly came to my attention that the web application stored the Session ID as part of some kind of error reporting JavaScript function in a message variable. This function would be executed if window.error was triggered:
I just got off a call with a client, and realised we need to think about how we report binary protections a bit more. More specifically the ios info binary command in objection. They can be a pain to explain if not well understood, and even harder to remediate! Binary protections make exploitation attempts much harder so, naturally we want all of them on. However, as you’d see in this article, not everything can always be enabled and sometimes it’s hard to understand why.
Years ago I learnt docker basics because I just couldn’t get that $ruby_tool to install. The bits of progress I’d make usually left my host’s ruby install in shambles. With docker though, I had quick reproducible build & run environments I could clean up easily without leaving a mess behind. The more I used docker, the more I’ve come to love it, and today it’s become a natural part of my daily workflow. It’s not without its flaws though, so in this post I want to show you an experiment of mine where I tried to write a docker pwn tool manager. A “docker-compose for hackers” if you will, called dwn (/don/). You can find it here: https://github.com/sensepost/dwn.
In this post I want to share two things. First, a quick primer on how you would you go about navigating the source code when contributing to objection, and secondly an application specific proxy feature I added to it. Introduction While on holiday I wanted to look into a certain mobile application that dealt with medical information. I was mostly interested in the data that was sent and received by the application so this meant proxying the traffic into Burp. I did not have a test device with me, so I had to use my personal device. This being my personal device meant that once I had the proxy set, certain applications would cease to function normally (especially those with SSL pinning) as Burp was in the middle.