Introduction to Hack In Paris 2019
This presentation outlines a new twist on an existing social engineering attack. In the past, we have worked on getting users to plug in USB devices to drop malicious documents and executables. While this attack sometimes proves our point, it is the tip of the iceberg that can be done. Enter Social Forensication.
This is a two-pronged attack, consisting first of collecting a memory image for offsite offensive forensic analysis, the second being a rogue Wi-Fi access point attack. During this presentation, we will walk through the steps to perform each attack. Since defense is just as (if not more) important as the attack itself, we will also discuss mitigations (technical and procedural) and relevant windows detections for these attacks.
* The basics of Social Engineering
* General discussion about the methods of social engineering
* *ishing, Spear Phishing, Whaling, Baiting, Dumpster Diving, etc
* Goals of social engineering
* Principles of Persuasion
* Existing techniques and research
* Discussion about Jayson Street and others’ methods of introducing USB devices and the goals of such attacks.
* Attacks overview
* Introduction to Forensics Attack
* Introduction to Rogue Wi-Fi Access Point (WAP)
* Attack #1: Forensics
* Required Gear
* Building the Pretext
* Gaining Access
* Building Rapport
* Playing the Part
* Getting the Memory Image
* Basics of Volatility and Useful Commands
* Steps to Collect Memory Image (dump)
* Volatility usage
* Useful commands (examples)
* Applicability in attacking
* Ideas for future research and wiki for more modules
* Mitigations and Considerations
* Considerations for Attacking
* Windows events
* Attack #2: Rogue AP
* Required Gear
* Building the Pretext
* Standing up the infrastructure
* Gaining Access
* Planting the device
* Mitigations and Considerations
* Considerations for Attacking
* Asset Management
* Asset Management
* Routine Scanning
This talk describes opensource tooling for generating advanced payloads to be used during red team engagements. The tool has been used to bypass “next generation” endpoint protections include Cylance, Palo Alto TRAPS and Fireeye amongst others.
Obtaining initial access is often one of the most complex and time-consuming aspects of an adversary simulation. We frequently find much of our effort is spent creating and testing payloads against various OS versions/architectures and against the most commonly used EDR (Endpoint Detection and Response), anti-virus and sandboxing solutions.
Historically, PowerShell has offered a method of circumventing these solutions by providing a conduit to enter memory. However, many modern defences have become more focused and aware of PowerShell meaning it often does not provide the carte blanche access it once did. This has naturally led to research in to other techniques for getting into memory and evading endpoint defences. This principle led to the development of an in-house payload generation framework we named SharpShooter. After using this framework with great success across a number of engagements, MDSec released the tool to the community in March 2018.
This talk walks through the steps of profiling an organisation to obtain the information required to create an effective SharpShooter payload, how to circumvent static analysis both on disk, in-memory and across the network, how to key payloads to evade sandboxing and a number of novel techniques for scriptlet execution using XML stylesheets, COM and application whitelisting bypasses.
Come to the session and see our second discovery about how to decrypt SID-protected PFX files even without access to user’s password but just by generating the SID and user’s token!
CQURE Team takes DPAPI (Data Protection API) and DPAPI-NG research to the completely next level! During this session you will hear about 2 great discoveries we made, first is about how to decrypt DPAPI protected data by leveraging usage of the private key stored as a LSA Secret on a domain controller (we have called it a ‘backup key’ and it is a key corresponding to the backup public key stored in the domain user’s profile). The backup key allows decrypting literally all of the domain user’s secrets (passwords / private keys / information stored by the browser). In other words, someone having the backup key is able to take over all of the identities and their secrets in the whole enterprise. It is crucial to know how this is happening! Another variant of DPAPI is DPAPI-NG used in the SID-protected PFX All rights reserved. All content (texts, trademarks, illustrations, photos, graphics, files, designs, arrangements etc.) of CQURE agendas is protected by copyright and other protective laws. Copying, duplicating and diffusing the content without CQURE’s permission is formally forbidden and may result in the financial penalty. files and when in the previous discovery CQURE Team is able to get access to user’s secrets, here it is a bit different! Paula Januszkiewicz, CEO and security researcher, will present the unique team’s findings of how to get access to users’ secrets by possessing the backup key from the domain and how to decrypt the PFX files passwords. Both demonstrations are key DPAPI breakthrough that can also cause serious implications if not managed well. Tools included. Our research affects Windows 8, Windows 8.1, Windows 10 and related Windows Server.
On Windows systems, users can be given special privileges. Some of these, if appropriately abused can lead to elevation of privileges to become SYSTEM.
In this talk, I will explain what the privileges and tokens are, how to get them, and based on their characteristics, identify some possible paths for Privilege Escalation via "Windows Privilege abusing" & "Token manipulation" .
Particular attention will be devoted to the privileges “SeImpersonate” and “SeAssignPrimary” which, combined with the “Rotten Potato” exploit and our subsequent research, the “Juicy Potato”, have proved to be “Golden Privilege”
Introduction to firmware reverse engineering process of IoT devices. The process, described with an example on a home router, is based on Information Gathering of hardware and software, Building of an Emulation Environment to run binaries, and Techniques to analyze, hack and modify the firmware.
The introduction to firmware reverse engineering process is described with a real example, done by the author, on a recent home router with the target to load a modified firmware overcoming the router protection that doesn’t allow loading of unsigned firmware.
The process described is based on:
- identify main device components (CPU, Flash, SDRAM, main components)
- locate UART and JTAG interfaces
- hw tools: Bus Pirate, OpenOCD, Jtagulator
- get os image file or firmware file
- sw tools: strings, file, binwalk, dd, jefferson, uncramfs etc.
- identification of CPU, Flash, RAM, kernel version, C library, toolchain used etc.
- identification of Original Manufacturer and Original Firmware Manufacturer
Emulation Environment using QEMU
- select a QEMU machine and CPU reasonably similar to the IoT device (same CPU, similar kernel version, similar modules and libraries)
- select a tool to build the kernel and the root file system (brief description of Yocto Project, Buildroot and OpenWRT build system). Buildroot will be used in the example and described in more detail
- Buildroot and kernel configuration, generation of root file system with binaries and libraries with debugging information
- Overcoming obstacles created by the firmware manufacturer
- Running interesting binaries in the emulated environment
- Use tools like strace, ltrace, gdb to reverse engineer the most interesting binaries
Analyze how the device works
- the firmware upgrade process
- CLI and Web interface analisys
- main processes analisys
- finding vulnerabilities
- hacking into the system
- hack the firmware upgrade process
- replace the original firmware
Create a Firmware Modification Kit to simplify the firmware modification process
In long and complex red team operations it’s likely the blue team is analysing parts of your infra and artefacts. Knowing what to look for its feasible to get alarms when the blue team is on to you before they are done analysing. We present new techniques for this and release updates to RedELK.
When performing multi-month, multi-C2teamserver and multi-scenario red team operations, you are working with an infrastructure that becomes very large quickly. This makes it harder to keep track of what is happening on it. Coupled with the ever-increasing maturity of blue teams, this makes it more likely the blue team is somewhere analysing parts of your infra and/or artefacts.
Red Teams mostly focus on offensive capability. We found a taint of blue on our teams really helpful during our operations. But why stop there? We have built detailed monitoring in our offensive infrastructures. Furthermore, there are several online resources that leave hints of blue team activities. Smart usage of these sources allows for keeping track of the blue team’s analyses and detections. This can help the Red Team to stay in control of the exercise by adjusting or even feeding decoys to the Blue Teams detective actions
In this presentation we’ll share several techniques that we successfully use in our red team operations in order to bust blue team OPSEC and to remain one step ahead of blue teams in order to give them a maximized learning experience. We will also release and demonstrate new versions of our tools for this purpose, most notably RedELK - a red team’s SIEM.
Red teamers, come and learn the way to build an infra and play with Blue! Blue teamers, come and learn how to increase your OPSEC during investigations!
Nowadays, there are a lot of different automation systems to reduce operating costs in modern hotels, business centers, airport or skyscrapers. These automation systems (also known as BMS) are gradually transforming buildings into smart buildings, which may form smart cities. One of the technologies to build smart building is KNX (or KNX/EIB).
However, this technology has some vulnerabilities and weaknesses. I will show how an intruder may connect to KNX network in any place and create a springboard to penetrate corporate or industrial network. Moreover, the intruder may destroy all subsystem of BMS. To implement this scenario the intruder just needs to connect to any smart devices. This smart device may be placed in public areas – inside the apartment in hotel or climatic-station located in an unprotected zone. During my presentation I describe the existing methods in KNX which should protect from unauthorized access and demonstrate real situations which can happen in real life:
* The weakness in KNX allows an intruder to conduct a DoS attack on any subsystem in KNX and replay attack to manage any node inside KNX network;
* There is an opportunity to change configuration in a node (or IP router) without authorization. These actions allow destroying segmentations in KNX network and get access to the entire network;
* Finally, in KNX network the intruder may find IP router and update firmware from smart button side via KNX-TP and it will be a springboard for further attack to corporate network.
Hacker Jeopardy Comes to Paris for the First Time!
You'll attend Hack In Paris 2019 ?
You can participate to the Jeopardy that we'll host for the first time on June 19 from 5:00pm to 6:30pm.
If you don’t know how Hacker Jeopardy is played
Basically: Contestants are given the answers. They must ‘ring in’ before the other teams and provide the correct Question – IN THE FORM OF A QUESTION!
Winn’s job is to humiliate the contestants, make their lives miserable, distract them and cause much embarrassment. All in the name of Good Hacker Fun, of course!
There will be 3 Games during the 90 minutes from 5:00 - 6:30.
3 Teams of up to 3 Members
3 Teams of up to 3 Members.
The two winning teams from Game 1 and 2, compete for HJiP Champion!
1. Total & Absolute Bragging Rights: “The First Champions of Hacker Jeopardy in Paris!”
2. PLUS - free attendance to Hack in Paris 10, in 2020!
3. Automatic inclusion to Hacker Jeopardy at DefCon in August.
4. Free copies of Winn’s new book, “Analogue Network Security”.
5. All the other swag we can get together.
Want to Play?
Specific test-beds have been implemented to characterize the entry point for an attacker and the possible information that an attacker could retrieve when targeting multiple GPS-enabled trackers. The study will highlight possible ways to compromise a set of devices found in the market.
During the last decades, it has been shown a high interest to deploy GPS-enabled trackers in the professional and private sectors to have a real-time access to the location of cars, trucks and expensive/sensitive goods. Nevertheless, few studies have been performed to estimate the risks for the privacy and security of the GPS-enabled modules. We propose in this paper to analyze the implications of using these devices in a private and professional environment. Specific testbeds have been designed to characterize the entry point for an attacker and the possible information that an attacker could retrieved. The study will highlight possible ways to compromise a set of devices found in the market.
Summary of the talk
The trend in society is to deploy and use GPS-enabled tracker to have a permanent access to the location of specific equipment and individual for law enforcement or for private use. Few papers have been published dealing with the security evaluation of such devices. The depth analysis of the management consoles has been reported in  demonstrating that an attacker is able to target the management console accessing to the geolocation data of GPS trackers. Nevertheless, multiple attack vectors have not been covered like the traffic re-routing exploiting security flaws of the configuration interface based on SMS as shown in . For this purpose, several GPS-enabled trackers (the most popular ones available on the market/number of devices sold) have been bought. These send periodically or on-demand the GPS coordinates of the specific trackers through the mobile network.
Summary of tests performed against GPS-enabled devices
The following attack scenarios have been tested against available GPS-enabled trackers leading to the finding of multiple security flaws. - Traffic analysis and modification using a fake base-station - Exploitation of SMS-based configuration of the device for back-door access for detection of trackers - Reverse engineering of the communication protocol between the tracker and the management server - Security of management server and privacy impact analysis - Detection of trackers • through traffic analysis (in the vicinity of the trackers) • through captures of IMEI (in the vicinity of the trackers) • through vulnerabilities in the management (remotely) • through core network access (remotely) - GPS Signal Spoofing using against the Tracker to uncover vulnerabilities in the GPS module itself as well as the management interface with malformed GPS coordinates. Moreover, it has been observed that some of the GPS trackers enclose a microphone for eavesdropping purpose. It will be shown how we have gained access to the audio recordings either by sending the audio capture command or by accessing records from the management console.
During the talk, we will present the different test-beds implemented for uncovering critical security flaws that lead to security and privacy issues for potential users of such solutions.
Social engineering is now used in most attacks. This talk goes over both the statistics but also real world attacks that I have witnessed and performed. I show what works and why. I then show how we can protect ourselves and our business.
Robert discusses his third place finishes and experience at the Defcon 2017 and 2018 Social Engineering CTF and how his efforts clearly show how easy it is to get sensitive information from any organization. The 2017 Verizon report clearly shows the dramatic growth rate of social engineering attacks and Robert demonstrates how he collected hundreds of data points from the target organization using OSINT techniques. He then goes into the vishing strategy he implemented to maximize the points he collected in the 20 minute live contest. Without much effort Robert was able to know their VPN, OS, patch level, executive personal cell phone numbers and place of residence.
Robert lifts the curtain of the social engineering world by showing tricks of the trade such as the “incorrect confirmation” which is one of many methods to loosen the tongues of his marks. Robert then shows the pretexts he designed to attack companies and the emotional response each pretext is designed to trigger. By knowing these patters we can better educate our staff. With that much information at his fingertips, how long would it take him to convince your executive to make a bank transfer? If your organization lost a few million dollars due to social engineering, who would be to blame? Are you insured for that? Who is getting fired? Robert wraps up his talk with a series of strategies companies can take to reduce exposure and risk. He goes over current exposure, building defenses, getting on the offense and finally… a culture shift.
Mimikatz is a hacking tool made by Benjamin Delpy. The mimikatz name by itself is already giving nightmares to plenty of defenders because of its capability to extract passwords in clear text from memory. But with plenty of antivirus, SIEM, EDR you should be covered, right?
This is 2019 and you still “try” to detect mimikatz. “Try”, because after many years, this post exploitation tool continues to be successful. As a contributor to mimikatz and also a blue team guy, I was asking myself why antivirus vendors are unable to catch this program after many years. How can a tool be blocked if nobody knows what this tool is doing? Because surprisingly, it is known only for credential collection. But mimikatz is a lot more. To mitigate the lack of success of antivirus vendors, should we buy new fancy EDR tool or try a technical approach by ourselves? Apply a Framework? Rely on Compliance? Use a SIEM to collect logs and apply correlation? In summary, can we detect mimikatz? In this presentation we will try to understand why mimikatz has such power and especially some weakness related to credential gathering and active directory will be exposed.
What if I told you that everything PowerShell does can also be done with Python–while still remaining in memory? In this talk, we will be looking at my approach to solving the offensive tradecraft problem of gaining dynamic access to the .NET runtime without going through PowerShell in any way.
Over the course of the last few years, PowerShell has been the number one way of conducting essentially any type of offensive operation on Active Directory networks and Windows endpoints. It allows offensive personnel to execute implants completely in memory, stealthily conduct situational awareness, and dynamically leverage the underlying power of .NET. Due to recent protections put in place by Microsoft, PowerShell is becoming increasingly less viable to use offensively. These protections are “baked in” to the latest versions of the Windows operating systems and allow AV/EDR/Logging solutions to gain an overwhelming amount of insight into PowerShell execution, and even, in some cases, completely shut down any type of malicious PowerShell tooling/tradecraft. It’s been a good run, and PowerShell has served us well. However, the future is upon us, and it’s our job to adapt; we have to go deeper! With that in mind, what if I told you that everything PowerShell does can also be done with Python–without dropping anything to disk and bypassing every protection that Microsoft has put in place for PowerShell? Welcome to the wonderful world of IronPython, where rainbows and unicorns still gallivant as if it were 2009! In this talk, we will be looking at my approach to solving the tradecraft problem of gaining complete, unrestricted, and dynamic access to the .NET runtime without going through PowerShell in any way. I’m going to be walking through the entire process of how I discovered this possibility existed, starting from “not knowing what I’m doing” and going to a “somewhat understanding of what I’m doing”. The talk will cover the progression from creating an initial weaponization PoC all the way up to building an Implant/C2 framework around it and all the success/failures/roadblocks I encountered along the way. Finally, at the end of the talk, I will be demoing an implant/C2 framework named SILENTTRINITY which implements this research and much more!
DeviceGuard is the newest application whitelisting feature in Windows 10. I will dive into the internals of various parts of the feature, and provide various new ways of subverting in different contexts. New execution techniques, accidental AMSI bypasses and other fun bonuses will also be included!
Device Guard (or WDAC) Is an application whitelisting feature on Windows 10 systems that allows only approved executables, libraries, and scripts to run, even under administrator users. Seemingly, the only way to run unsigned code without specific RCE vulnerabilities would require an administrator to turn the feature off and restart the machine.
This talk will exhibit rarely discussed and novel techniques to bypass Device Guard, some requiring admin access, some requiring Microsoft Office (but no user interaction), and one available under low privileges and using nothing but native OS executables. All techniques presented will eventually allow an attacker to run arbitrary code without disabling Device Guard. As of now, Microsoft decided not to service most of these techniques with an update (except for one which was serviced as CVE-2018-8417).
During the the talk, we’ll dive in to the various ways the feature is implemented under different contexts, and explore the internals of Windows scripting engines and their host processes to understand how some popular techniques (and some of the ones shown in the talk) are able to bypass Device Guard
Imagine yourself looking through a myriad number of crash dumps trying to find that one exploitable bug that has escaped you for days!
We will explore ML for offensive exploration, categorize and determine the exploitability of crashes and bugs, accelerating the triage process for exploitation.
Imagine yourself looking through a myriad number of crash dumps trying to find that one exploitable bug that has escaped you for days!
And if that wasn’t difficult enough, the defenders know that they can make us chase ghosts and red herrings, making our lives waaaay more difficult (Chaff Bugs: Deterring Attackers by Making Software Buggier)
Offensive research is a great field to apply Machine Learning (ML), where pattern matching and insight are often needed at scale. We can leverage ML to accelerate the work of the offensive researcher looking for fuzzing–>crashes–>exploit chains.
Current techniques are built using sets of heuristics. We hypothesized that we can train an ML system to do as well as these heuristics, faster and more accurately.
Machine Learning is not the panacea for every problem, but an exploitable crash has multiple data points (features) that can help us determine its exploitability. The presence of certain primitives on the call stack or the output of libraries and compile-time options like libdislocator, address sanitizer among others, can be indicators of “exploitability”, offering us a path to a greater, more generalized insight.
Defenders can find a lot of value in this work as well, as we can help developers isolate and focus on crashes that will lead to exploitation instead of drudging through countless crashes and analyzing them manually.
In this talk we will explore the current state of the art in ML for offensive exploration and present our ongoing work to automatically categorize and determine the exploitability of crashes and bugs, accelerating the triage process tremendously.
A demo would be shown live on stage (and if the gods permit, a tool released)!
Outline: Fuzzing overview Dumb fuzzing Smart fuzzing ML driven fuzzing
- Machine Learning overview Basic properties of ML Generalizing from inputs Finding needles in haystacks
- What is an exploitable crash Crash analysis What are we looking for
- Scaling crash triage How we generated our data Testing our method in the real world Performance issues
- Comparing manual, heuristics and ML Manual approach Heuristic approach ML Approach
- Where can this tool be used Offense Defense
- Key takeaways
The Google Play Billing API is vulnerable by design and allows an attacker to bypass the payment process. I analyzed several android games and found that it possible to bypass the payment process. This presentation will show real vulnerable applications (Fruit Ninja, Doodle Jump, etc.)
The agenda of the presentation will be divided as follow:
1. Google Play Billing Presentation: Presentation of the workflow and how it works. In addition, a focus will be done on the local validation of the process.
2. Known vulnerabilities: Review of the vulnerabilities found by Dominik Schürmann. Demonstration of why the fixes performed by Google are not enough and how it is still possible to bypass the payment process.
3. Vulnerable applications: Example of vulnerable applications trying to protect the billing process (Doodle Jump, Snoopy Pop, Fruit Ninja, etc.) with different techniques (obfuscation, shared libraries, etc.). The presentation will focus on how the billing process is performed and how by reverse engineering the application, it is still possible to bypass the payment process.
4. Conclusion: Sum up of the numbers of vulnerable applications. Comparison with other billing libraries (Amazon and Samsung)
Conference talks often position themselves as a way to show off hacking successes. Lacking from this environment is the failures, the screw ups, or feelings of utter defeat. As such we have decided to share our numerous failures while competing in a hardware device CTF challenge.
Failure is part of growing, and often not talked about enough in the pursuit of achievement. The talk will dictate the fail filled journey of three coworker friends during the RHme3 challenge. We built a side channel rig, we created a glitching rig, we wrote our own extension to AVR code. We also ignored pinout diagrams, ordered components 2 sizes too small, almost got on a no-fly list, and listened to hours upon hours of horrendous text to speech output. This talk reminds both newcomers and veterans that when the going gets tough, the tough accumulate failures. Things we spent months on only to fail, and things we were forced to grind through with sub-optimal strategies. All will be discussed.