Embrace The Red

This post is part of a series about machine learning and artificial intelligence. In the previous post we walked through the steps required to gather training data, build and test a model. In this post we dive into “Operationalizing” the model. The scenario is the creation of Husky AI and my experiences and learnings from that. Part 3 - Operationalizing the Husky AI model This actually took much longer than planned.

This post is part of a series about machine learning and artificial intelligence. In the previous post we described the overall machine learning pipeline. In this post we dive into the technical details on how I built and trained the machine learning model for Husky AI. After reading this you should have a good understanding around the technical steps involved in building a machine learning system, and also some thoughts around what can be attacked.

This post is part of a series about machine learning and artificial intelligence. In the previous post I talked about good resources for learning more about artificial intelligence and machine learning in general, and how I started my journey in this space. The next few posts will be about Husky AI. What is Husky AI? Husky AI allows a user to upload an image, and get an answer back if the image contains a husky or not.

This year I have spent a lot of time studying machine learning and artificial intelligence. To come up with good and useful attacks during operations, I figured it is time to learn the fundamentals and start using software, tools and algorithms. My goal was to build a couple of end to end machine learning systems from scratch, and then attack them. This post describes my studying approach, materials, courses, and learnings.

Excited to announce that I will be presenting at BSides Singapore this year. The topic is adversarial usage of virtual machines during lateral movement. And we will also cover threat hunting and detection ideas. I have been referring to this technique as the Shadowbunny over the years. :) The conferences is on September 24th-25th, it will be all virtual and free to attend. Check out the BSidesSG 2020 website and schedule for other talks and details.

Today I’m gonna talk about a class of application security issues I ran across a few times over the years. In particular, let’s discuss race conditions when it comes to files with sensitive content and permissions. Race conditions can allow an adversary to gain access to sensitive information on machines. Assume a system creates a file that contains sensitive information and afterwards applies permissions to lockdown that file. Understanding the race condition Let’s look at a practical example seen in the wild a few times.

These days business decisions and feature development often is influenced heavily by telemetry information. Telemetry is baked into the programs, services and applications we use. Companies are hungry for telemetry because with machine learning and Deep Neural Networks “data is the new oil”. Telemetry provides insights into how users use a particular system, what features they exercise, how they configure the system, what errors they trigger and what buttons they like clicking on.

Throughout my career I have been fascinated with quality assurance and testing, especially security testing and red teaming. One discussion that comes up frequently is how to measure the maturity of such programs and processes. My answer is straight forward as there are already existing frameworks that can be leveraged, adjusted and borrowed from to fit the needs of offensive security programs. You are likely familiar or have at least heard of the Capability Maturity Model Integration from Carnegie Mellon University.

In this post I will discuss some testing techniques for internal red teams to identify privacy issues in services and infrastructure, most importantly a simple three step approach that might uncover interesting results. Background story First, let me share a story from the past. When I did my master’s I built an app that performs end to end encryption of Facebook posts. This means that only the intended audience for which your posts were encrypted for can decipher the posts.

Finally I got to writing some basic tooling for invoking the Firefox debugging API to send commands to the browser and read the responses. This can be useful for grabbing cookies in the post-exploitation phase. It works for Windows and macOS, should also work on Linux. This technique is probably most useful when we don’t have root or the user’s credentials to decrypt cookies or can’t attach a regular debugger to the browser process.

Previously I talked about remotely debugging Chrome, and we also covered the latest Microsoft Edge browser along the way. These features allow an adversary to gain access to authentication tokens and cookies. See MITRE ATT&CK Technique T1539: Steal Web Session Cookie as well for this. What about Firefox? For a while I was wondering if (my favorite) browser Firefox has such debugging features as well, and how one could detect malware trying to exploit it.

A technique on Windows that is less known is how to do basic port-proxying. Proxying ports is useful when a process binds on one (maybe only the local) interface and you want to expose that endpoint on another network interface. Let’s say you have an existing process that listens only on the loopback interface, and you want to expose it remotely. Or there are two network interfaces and you want expose traffic from one to the other (maybe some evil persistence for port 3389) - or think of basic pivoting.

Amazon Bug Bounty! Great news: Amazon is now offering bounties via a security vulnerabiltiy research program Bad news: AWS is out of scope! When I read this I remembered that a few years ago I found persistent Cross-Site-Scripting on the AWS Console. This post is a write up on how I found the XSS back then, techniques I used and how they evolved over the years and Amazon’s response. AWS Console and Cross Site Scripting The story is that I had just created an AWS account and started using the service.

I’m excited that Feedspot ranked this blog (Embrace the Red) the number #10 pentest blog out there. Subscribe and check-in regularly for new content related to offensive security engineering, penetration testing and red teaming. You can also follow me on Twitter @wunderwuzzi23. Cheers.

A few months ago we discussed the importance of performing active credential hunting for your organization. This is to ensure clear text credentials in widely accessible locations and source code are identified before an adversary gets a hold of them. In this post we will explore using built-in operating system indexing features to search for information on machines quickly. Many of us use the indexing features (like Windows Search and Spotlight) daily via the UI.

The Shadowbunny TTP in the PenTest Magazine The latest edition of the PenTest Magazine features an article of mine about using virtual machines (VMs) during lateral movement to establish persistence and evade detections. A few years back when I came up with the idea of using VMs for lateral movement during red teaming, I called it the Shadowbunny TTP and that name stuck around in my head. There is more info in the article around the origin of the name also.

Some organization have this interesting concept of a bug jail to prevent new feature development when there are too many existing flaws in the system. For instance, if an engineer has 5 or more bugs assigned they aren’t allowed to work on anything else but fixing their bugs. What is the Security Bug Jail? A security bug jail goes along the same lines. The owner of a system can never have more than a certain upper limit of active security bugs.

Monte Carlo simulations can be a useful tool to uplevel your red teaming skills and provide a different and fresh perspective for highlighting, discussing and presenting findings. Red teaming is about challenging an organization. This includes analyzing business processes and methodologies, including our own. Obviously, using Monte Carlo simulations in the security realm is not my idea. I first ran across the idea in Hubbard’s book about measuring cybersecurity risk. Since then I have been thinking and playing around with applying these methods to security program’s, especially red teaming and threat modeling.

The results of phishing campaigns are often not comparable with each other over time. Various security vendors and red teams use different tooling and techniques - which is totally fine. However, I recommend requiring tracking a minimum set of metrics to be able to compare results over time. Funny side facts: At times employees are messing with the red team, entering invalid creds for CISO or CEO and things along those lines.

Last month I did some research on Firefox, specifically I was learning more about it’s remote debugging features. As part of that I was reading Bugzilla bug information and learned more about Mozilla’s infrastructure. One thing I noticed reading up on details was that Mozilla uses Phabricator. What is Phabricator? Phabricator is a collaborative web-based toolset for code reviews, checkins, bugs, work items, wiki, pastes, credentials and many other useful things.