Obfuscation classification via Machine Learning
This allows us to extract several families of features. Some of them require careful feature engineering, while others are more general and follow well-known NLP techniques. Next, we survey prior art from the literature and discuss several natural approaches to this problem.
Finally, we suggest obfuscator-agnostic methods to build state-of-the-art machine learning classifier for this problem.
Public, verifiable, and unbiasable randomness: wassat?
Randomness is infamously known for biting developers whenever cryptography is involved. Now that distributed systems are becoming a thing and also have to deal with it, let's explore what's what.
In this talk, we will walk through what's randomness, and why it matters. We will discover the different "flavours" of randomness, from the "private" to the "public" one, including the "verifiable", the "distributed" and the infamous "lack of" randomness.
We will discover a few use-cases for each of these, discuss the problems lurking behind each, and existing solutions to avoid them.
Finally we will (re)discover "drand", a distributed randomness open-source software that allows you to run your own, join an existing network or just query good quality public, verifiable, distributed randomness. We will briefly cover the existing League of Entropy behind the main existing drand network, what it's being used for and why public randomness should be treated as a public service.
MuddyWater: From Canaries to Turkeys
In January 2022, US Cyber command attributed Muddywater to the Iranian Ministry of Information and Security, which caught some attention by the cyber security community. The reason being the fact that
Since late 2021 through 2022, Iranian based threat actor Muddywater has been conducting several operations using different methods of operation targeting victims in different geographies including Europe, the Middle East and Asia- culminating into the attribution by the U.S. Cyber Command of the group to Iran’s Ministry of Intelligence Services (MOIS) instead of the IRGC like it was previously believed.These campaigns show the flexibility and capability of this group when it comes to employing different methods of operation to achieve their goals. We will start by describing three very distinct MuddyWater campaigns which are linked together by methods of operation and tools. The campaigns consisted of highly targeted attacks on Turkish governmental organizations. This was the first campaign that we saw using Canarytokens to signal payload activation. Our analysis of this method led us to create different hypotheses for the usage of this novel method. * Bypass URL analyses - If the Canary token is not activated then the C2 would not deliver the payload. This thwarts an isolated analysis of the C2 payload url. * Determination of the C2 URL blocking. - Several requests to the token without any requests to the C2 indicate blocking of the C2 by a victim’s organization. * Anti-Analysis checks - Canary token requests followed immediately by a request for the payload within a reasonable timeframe may also be used to determine automated analysis such as a sandbox based analysis - This is essentially a timing check or sorts.
This campaign also had a mixed stage payload delivery - on one side it uses the common malicious VBA macros via Office documents; on the other it used double extension executables that seem to have been created with a builder. This builder was also used in other campaigns, targeting Armenia and Pakistan. This builder seems to be a recent addition - first seen in the wild around mid 2021 - to MuddyWater’s arsenal and can expedite the creation of new campaigns with little to no effort. Interestingly, the Pakistani wave was the first observed instance of the group’s use of the token system. In this attack instance, the group used their own servers/remote-locations to record infection tokens. This technique was then migrated into Canary tokens - observed in the previous campaign targeting Turkey.
In the meanwhile a third campaign using yet another method of infection has been also uncovered by us. This time Muddywater used a WSF based RAT to execute remote commands, which usually culminates with the installation of a commercial remote administration tool such as remote viewers. This seems to be the method of operation preferred to target countries in the Arabian peninsula. Finally, our presentation will end with a review of the timeline of the campaigns and tool capabilities, describing their evolution over the course of 2021, covering the three different campaigns that MuddyWater has carried out. We will demonstrate that the group tested some techniques in some campaigns and adopted them in later campaigns as a definitive modus operandi. The mix and match of some campaigns raises the possibility that Muddywater is in fact a collective of groups working together and sharing tools, where each group focuses on specific regions of the world, while sharing techniques and procedures across the teams. With this presentation the audience will have a better understanding of the Muddywater APT group, their methods of operation and the tools, all put into their evolution context and usage.
Formalizing the right to be forgotten: law meets crypto
How does the "right to be forgotten" translate into operational requirements? Regulations list requirements, but natural language is ambiguous. We explore how cryptography can help in this regard.
The “right to be forgotten” is a concept that confers individuals more control over their digital data. This right has been codified as regulations or case law in a few famous examples. However, laws are by their very nature vague and open to interpretation. To address this ambiguity, researchers began to frame privacy laws in the formal language of cryptography to facilitate compliance. In this talk, we will review recent results in this young line of research. We will introduce the concept of deletion-compliance of Garg, Goldwasser and Vasudevan (Eurocrypt 2020). We will highlight some issues with this concept that were later addressed by Godin & Lamontagne (PST 2022) and independently by Gao, Garg, Mahmoody & Vasudevan (PETS 2022) using a different approach. We will highlight some of the difficulties that arise when formalizing broadly-defined notions of privacy.
10 Things I wish I knew before my first incident
Incidents are a bad time to try to figure out what you don't know. This talk will highlight the most important things IT, Security and IR teams should know before an incident happens.
The first major incident response I was involved in was a nightmare. Why? Because I didn’t know what we didn’t know. Sixteen years and too many incidents to count later, I’ve come up with a list of 10 (or more) things that I wished I had known then. In this talk, we’ll cover what those 10 things are, some adjacent questions to those, and some war stories to show you why you should care.
This isn't your dad's IR plan....
I thought writing a technical book was supposed to be fun?!!
In this talk, I dive into my experience writing and publishing a security book. What goes into writing one of these 400-page technical textbooks? Let’s dive into the realities: from idea to book.
We all love technical blogs and books. Many people dream about writing one too.
I had no idea what I was getting myself into security blogging, and before I wrote my web application hacking book “Bug Bounty Bootcamp”. A lot of the work that goes into writing and publishing a technical book goes beyond coming up with technical information and code samples.
In this talk, I am going to dive into my experience writing and publishing a security book and writing technical content. How does one write good technical content like security writeups and blog posts? What goes into writing one of these 400-page technical textbooks? How does one make sure that everything in the book is technically correct? What are the pros and cons of working with a publisher?
In this talk, we dive into the realities from idea to tech blog / book and discuss how you can write one too.
The Risks of RDP and How to Mitigate Them
We have been studying and reimplementing parts of RDP for the last three years. This talk is about how to attack and defend against RDP attacks. From MITM and credential capture to secure deployment.
Remote Desktop Protocol (RDP) is the de facto standard for remoting in Windows environments. It grew in popularity over the last couple of years due to the pandemic. Many remote workers are now relying on it to perform duties on remote systems. RDP is secure when well deployed but, unfortunately, that’s rarely the case and thus clicking through warnings is common. We have spent the last 3 years working on and reimplementing parts of RDP in PyRDP, our open-source RDP library. This presentation is about what we have learned and can be applied to attack and defend against RDP attacks.
From an attacker’s perspective, we will cover conventional RDP attacks such as Monster-in-the-Middle (MITM) of RDP connections, capture of NetNTLMv2 hashes and techniques to bypass conventional defense mechanisms such as Network Level Authentication (NLA). Case in point: Did you know that by default all clients allow server-side NLA downgrades right now? This will enable us to understand and identify the risks with RDP.
From the Blue Team’s perspective, we will provide techniques and tools to detect attacks showcased previously. Finally, we will provide step-by-step instructions to deploy an accessible RDP server that is both secure and functional.
In this talk, we will share a deep dive on some of the reverse engineering challenges we faced and how we were able to overcome them and release an open-source Ghidra plugin to disassemble V8 snapshots.
Jumping the air gap: 15 years of nation-state efforts
Learn from the best. Nation-state actors have been breaching air-gapped networks for over a decade and a half: discover how they are doing it, so you can better protect yours.
Air-gapping is used to protect the most sensitive of networks: ICSes running pipelines and power grids, voting systems, or SCADA systems operating nuclear centrifuges just to name a few. In the last 24 months, four malicious frameworks devised to breach air-gapped networks emerged, bringing the total to 17, by our count. This prompted us to step back and reanalyze all those frameworks from the vantage point of having discovered and analyzed three of these in the past six years. We put the frameworks in perspective to see what history could teach us in order to improve air-gapped network security and our abilities to detect and mitigate future attacks.
This exhaustive analysis allowed us to isolate several major similarities in all of them, even those 15 years apart. We pinpoint the specific areas of air-gapped networks that are consistently leveraged by malware in order to operate, and provide objective advice on how best to prioritize the deployment of resources to increase security.
Specifically, this presentation covers the similarities in execution vectors used on the connected and air-gapped sides of targeted networks, the air-gap-crossing mechanisms and communication protocols used to control the components running on the isolated networks, the information stealing techniques, and, finally, the propagation and lateral movement capabilities.
Our analysis shows how most frameworks differ only from an implementation perspective in so many aspects, mostly due to the severe constraints imposed in air-gapped environments. Armed with this information, we cover techniques that can be implemented to harden specific areas that have been repeatedly abused by air-gap-aware frameworks and strategies to detect their presence, such as how to prevent removable drive abuse and detect host- and network-based reconnaissance activity often observable within the isolated network under attack.
Our aim is to convince the audience of the importance of having all the proper defense mechanisms to mitigate the techniques used by virtually all of these frameworks observed in the wild, before starting to look into the many theoretical air-gap bypass techniques that have gotten most of the spotlight in recent years despite none of them ever being used in a real attack.
This is a must-see session for anyone responsible for the security of an air-gapped network, but also for anyone interested in the history and evolution of these fascinating attacks.
The road to BeyondCorp is paved with good intentions
BeyondCorp is Google’s initial implementation of a zero trust architecture, which grants application access based on the user, device, and application. Despite all the excitement about zero trust architecture, there’s little concrete guidance (and a lot of vendor noise) on how to successfully implement one. In this talk, Maya and Eric will provide insight into BeyondCorp fundamentals, common misconceptions, and a roadmap for your organization to get to a zero trust architecture.
The Zero Trust mandate is nigh and with it, debates of industry readiness, product pitches, and the question as old as time: what is a BeyondCorp? Is it time to re-architect our infrastructure from the ground up or start buying the latest security tools?
BeyondCorp is Google’s initial implementation of a zero trust architecture, and is still the guiding star for many organizations. In a zero trust architecture, every request to access an application is a policy decision, based on the user, device, and application. The BeyondCorp whitepapers explain what Google built, and some of the organizational challenges, but don’t lay out a step by step guide to getting there, or how you know you’re on the right track.
In this talk, Maya and Eric will fill in the gaps. They will provide insight into BeyondCorp fundamentals, including requirements for user identities, controls and measurements for devices across platforms, and how to construct access policies. Then, they’ll get into common misconceptions and what you might need to tackle as you continue your journey. You’ll come away with a roadmap for your organization to get to a mature zero trust architecture, and what the industry can do better to support zero trust principles.
Passive recon & intelligence collection using cyber-squatted domains
The DNS system was not designed with security in mind, and domain Squatting techniques are most commonly identified and known by their use in phishing attacks. In this talk we will demonstrate a less-often considered use for these domain names as reconnaissance and intelligence gathering tools.
Domain squatting presents the creative attacker with low cost, and extremely effective ways to passively gather large amounts of useful data & intelligence. These techniques can be highly targeted, or they can be used by cyber criminals to cast a wide net, taking advantage of victims as the opportunities present themselves.
For our research, we are using "catch-all" email inboxes on squatted variants of a very popular public email service. Our intention for this data is to analyse & demonstrate the diversity of information obtainable using this technique. A single typo or bitflip in the domain name of an email address will result in our inboxes receiving email intended for someone else! Using roughly a dozen domain names, we are currently capturing thousands of emails each week. Are you curious to know what we've found, and how you can defend your organisation about this type of attack? See you at the talk!
Hook, Line and Sinker - Pillaging API Webhooks
Webhooks are an important part of modern web services. The techniques showcased here will highlight unique attack vectors that can be used to perform SSRF attacks that can lead to cloud compromise
Webhooks are an important part of modern web services and event-driven applications. They are defined as “user-defined HTTP callbacks”, and are triggered by some events, such as pushing code to a repo or adding a new customer entry in a CRM tool. Webhooks are ubiquitous and gaining in popularity owing to their asynchronous nature and the integration possibilities that they engender.
Webhooks are seen as “harmless”, owing to their “one-way” orientation. They are perceived as such, because they typically post some event information to a URL and they are done once they receive an HTTP response.
In this talk, I will demonstrate a series of attacks that we dub “Webhook Boomerang flaws”. These flaws allow attackers to leverage webhooks to create a boomerang effect that ends up attacking the originating web service itself. The techniques showcased in this talk will highlight a unique set of attack vectors that piggyback on nothing more than the standard HTTP and DNS protocols, which allow us to to perform Server-side Request Forgery style attacks that can lead to cloud-metadata compromise even with security protections like Metadata Headers. In our research, we’ve discovered this across multiple cloud providers and found that these attacks can be used in more conventional SSRF compromises of internal web-services.
The talk starts with a detailing of webhooks and typical webhook functionality that are provided by popular CI, CRM, Project Management, Payment Gateways and other applications. Subsequently, I'll be showcasing demos of multiple techniques that can be used in this attack approach, with special emphasis on evasive payloads as well.
Next, I will showcase the success of this attack against several popular bug-bounty targets to highlight the impact of these attacks at scale.
Finally, I will present multiple approaches to defending against these vulnerabilities and developer best practices that should be applied when defining webhook functionality.
From the cluster to the cloud and back to the cluster: Lateral movements in Kubernetes
Lateral movement is usually the point where a cyber-attack becomes interesting. After gaining initial access, attackers might try to move laterally in the IT environment to reach other, more sensitive, resources. This is not different in Kubernetes: attackers won’t stop in a single compromised container: they would try to move laterally inside the cluster and more importantly, also outside the cluster. As Kubernetes clusters usually reside in the cloud, access to a container can be a foothold to the entire cloud workload. This can allow attackers to reach various cloud services, such as VMs, storages, secret stores, and also other Kubernetes clusters. We will go over various techniques attackers use for lateral movement in Kubernetes and explain how we, as defenders, can prevent them.
In this session we will take a deep dive into Kubernetes lateral movements. We will elaborate about the different identity types used by Kubernetes and how attackers use those identities to escalate their privileges in the cluster and move laterally to external cloud resources. We will explain the various cluster-to-cloud authentication methods in the various cloud providers (AKS, EKS and GKE) and the risks that each one poses. We will show real-world examples of misconfigurations that led to cluster takeovers and explain how they could be prevented.
Privacy-friendly QR codes for identity
Presenting personal information in the form of a QR code has become a daily reality for many during the Covid pandemic: in Quebec, people showed their immunization information using the government-issued VaxiCode, a SMART Health Card (SHC) credential that follows a medical standard adopted in Canada and in many other countries. The paradigm of presenting information about oneself can easily be generalized beyond this health scenario. In this presentation, I’ll first give an overview of the SHC framework, focusing on its security features and describing its deployment in Canada. I’ll then present a generic framework to issue QR codes that can encode attributes of any type. I’ll introduce a strong privacy feature allowing users to only disclose a subset of the encoded attributes, addressing one of the main privacy critiques of SHCs. Finally, I’ll give a demonstration and describe the open-source specification and reference implementation for this generic framework.
Outline of the presentation:
- SMART Health Card (SHC)
- Overview of the SHC framework, and of its overseeing organization VCI
- Security analysis of SHC, including: key management, cryptographic signatures, revocation of issuers and SHCs, and trust establishment (trusted issuer directory and auditing)
- Claims QR
- Presentation of the Claim QR framework for generic attributes
- Hash-based mechanism for selective disclosure of attributes
- Overview of the open-source specification and reference implementation
- Demo (issuance and validation of generic attributes)
Tell me where you live and I will tell your P@ssw0rd: Understanding the macrosocial factors influencing password’s strength
There are many ways to attack organizations, and credential stuffing is one of these. Depending on the strength of users’ passwords, crackers can decrypt passwords in a matter of seconds, hours or they may never succeed. Even if there was a significant advancement in attackers' abilities to perform password cracking, passwords remain the dominant authentication method not replaced but merely augmented by multi-factor authentication (MFA). The knowledge about passwords’ use must be deepened in order to respond to the protection needs of cybersecurity clients and adapting to specific aspect of their reality. Adopting a macrosocial approach, the present study explores different factors influencing passwords’ quality. We combined NorthPass’s list of the 200 most common passwords in 49 different countries to several other databases of country’s social and economic indicators like GDP, mean education level, amount of data breaches experienced in the country, etc.
The results reveal that a higher literacy level is associated with higher passwords’ quality. Also, the number of Internet users is inversely associated with password quality which indicates that living in a highly connected country is not a factor that increase information’s protection. The study participates in the understanding of macrosocial protection’s factors in order to adapt password lists.
I am become loadbalancer, owner of your network
In the last few years, a slew of remote code execution vulnerabilities have been found, disclosed and then promptly exploited en-masse against networking hardware known as load balancers. These devices primarily serve to distribute traffic across server farms & offload SSL processing are largely viewed as black box systems due to restrictive licensing, proprietary hardware, and a lack of transparency from the vendors into the guts of the systems. They run at the borders and cores of most cell carriers, banks, Fortune 500 companies, ISPs and some cloud providers. Since many of these devices function not only to balance traffic, but as VPN concentrators, WAFs and SSL proxies, they are generally installed in high-access parts of the network. Due to their mission criticality, they also frequently run outdated vendor code and, even worse, the Linux/BSD based operating systems they use are generally numerous versions behind current and due to the proprietary nature of their code, one does not simply 'apt get upgrade -y'. Since most run Linux/BSD as the management OS, the environment is ripe for lateral movement, persistence and further exploitation using commonly available open source tools.
In the last few years, a slew of high-profile, critical remote code execution vulnerabilities have been found, disclosed and then promptly exploited en-masse against the category of networking hardware known as load balancers. These devices primarily serve to distribute traffic across server farms & offload SSL processing; they cost between $40k-$250k per device and are largely viewed as black box systems due to restrictive licensing, proprietary hardware and a lack of transparency from the vendors into the guts of the systems. They run at the borders and cores of most cell carriers, banks, Fortune 500 companies, ISPs and some cloud providers.
Since many of these devices function not only to balance traffic, but as VPN concentrators, WAFs and SSL proxies, they are generally installed in high-access parts of the network. Due to their mission criticality, they also frequently run outdated vendor code and, even worse, the Linux/BSD based operating systems they use are generally numerous versions behind current and due to the proprietary nature of their code, one does not simply 'apt get upgrade -y'. Since they all run Linux/BSD as the management OS, once you've breached one with an 'exploit that fits in a tweet' the environment is ripe for lateral movement, persistence and further exploitation using commonly available open source tools.
In this talk, I will lean on a decade of experience working for one of the most prominent load balancing vendors and teach you the architecture, how the devices operate, how they're deployed, what their management plane looks like and the access it affords you post-breach. You will also learn how to avoid common mistakes which can interrupt traffic processing, trigger device failures and otherwise give away your presence on the system. While this talk will focus on a specific architecture, all vendors use essentially the same design concepts so the information is applicable across most platforms. Additionally, armed with an understanding of the designs you'll be able to use freely available vendor documentation to hone & tune your post-exploitation shenanigans across other load balancing products.
While this talk is primary aimed at offensive operations, the information provided can also be leveraged by defenders to harden their environments and provide guidance on DFIR operations post-breach.