Netwitness RT - Don’t scratch that patch.pptx
Melden
Teilen
•0 gefällt mir•120 views
Netwitness RT - Don’t scratch that patch.pptx
•0 gefällt mir•120 views
Melden
Teilen
Downloaden Sie, um offline zu lesen
With "Patch Tuesday" Microsoft usually addresses various security vulnerabilities and issues by providing patches and updates for their software products. However, for malicious actors, Patch Tuesday can be a valuable resource for identifying new exploits. In time, noticing this mechanism in the cybercriminal ecosystem, we decided to adopt a similar approach to support our Red Team and our investigations. In a nutshell we industrialized a process where our Threat Intel team harvest exploits linked with the Patch Tuesday from the dark web, while our team reverse engineer the updates looking for code we can use during our Red team activities. The result is an extended set of potential exploits we can reliably integrate in our arsenal when we carry out the simulated attacks. This improves the effectiveness of our Test and allow us to extend the options we have against the defense mechanisms of our customers. By using the newly acquired knowledge about the vulnerabilities, the Red Team can test whether these systems can detect or prevent exploitation attempts. In our session, we will present our process and some examples where our newly acquired knowledge and exploit allowed our team to better test our Customers cybersecurity posture.
Recomendados
![[Haechi Audit] Pancake Bunny Smart Contract Audit Report](https://cdn.slidesharecdn.com/ss_thumbnails/haechiauditpancakebunnysmartcontractauditreportver2-210120072352-thumbnail.jpg?width=384&fit=bounds)
Más contenido relacionado
Similar a Netwitness RT - Don’t scratch that patch.pptx
Similar a Netwitness RT - Don’t scratch that patch.pptx(20)
Más de Stefano Maccaglia
Más de Stefano Maccaglia(9)
Último
Último(20)
Netwitness RT - Don’t scratch that patch.pptx
- 1. 1 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 2. 2 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 3. 3 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 4. 4 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 5. 5 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 6. 6 ©2021 RSA Security LLC or its affiliates. All rights reserved. MITRE ATT&ck We use MITRE framework to definethe techniques to adopt. In addition,MITRE ATT&ck Frameworksupportthe Customerreadingour final report.
- 7. 7 ©2021 RSA Security LLC or its affiliates. All rights reserved. Mapping Tactics & Techniques By mappingthe real used techniques, the Team can build the scenario and can decide what tool to adopt to emulate the outcome of the attacker tools.
- 8. 8 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 9. 9 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 10. 10 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 11. 11 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 12. 12 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 13. 13 ©2021 RSA Security LLC or its affiliates. All rights reserved. Our tools for the trade are: IDA Pro BinDiff Diaphora How to find exploits… Diaphora is a plugin to IDA and it exports all necessary metadata into a sqlite-database. To work with Diaphora you should proceed with the following steps: BinDiff is a comparison tool for binary files that helps to quickly find differences and similarities in disassembled code. It is used by security researchers and engineers across the globe to identify and isolate fixes for vulnerabilities in vendor-supplied patches and to analyze multiple versions of the same binary. Another common use case is to transfer analysis results from one binary to another, helping to prevent duplicate analyses of, for example, malware binaries. First, we export the databases (the binaries) that we want to compare. Then, we diff both generated databases to find matches between them. Optionally, we can import matches from one binary to another.
- 14. 14 ©2021 RSA Security LLC or its affiliates. All rights reserved. How to find exploits… With BinDiff you can identify and isolate fixes for vulnerabilitiesin vendor-suppliedpatches, port symbolsand comments between disassemblies of multiple versions of the same binary. In a typical comparison,as the results are presented, we get a number of tabs with statistics. The Primary Unmatched tab shows functions that exist in the currently opened IDB that were not found in the other file, while the Secondary Unmatched and Matched Functions tabs should be self-explanatory.
- 15. 15 ©2021 RSA Security LLC or its affiliates. All rights reserved. We first open a file in IDA and export all the necessary metadata into a sqlite-database before then opening the second file and comparing the sqlite files: Diaphora The UI after the comparison finishes is pretty much the same as BinDiff. However when comparing functions side-by-side it’s all done in IDA with the option to get an assembly,a pseudo- code and a patch-style comparison.
- 16. 16 ©2021 RSA Security LLC or its affiliates. All rights reserved. The Microsoft patch, solved a privilege escalation vulnerabilitywithin win32k. Search for an exploit: CVE-2023-29336 v15 code implementation focused solely on locking the window object called in the routine, but it missed to lock the menu object nested within the window object. It means that menu within the object can be left behind, paving the way for the privilege escalation. In fact, xxxEnableMenuItem function, connected with v15 object is not properly locked when exiting is main flow: This object (v15) is locked properly… but, why in v17 is different? Let’s “BinDiff” between win32kunpatched and win32kpatched: This results in an exploitable condition to work with, allowing us to develop a PoC and to go forward with testing.
- 17. 17 ©2021 RSA Security LLC or its affiliates. All rights reserved. If you found the instructions that are addressedby the patch, it’s time to move forward… If you unearthed an API that could be invoked: − Craft the API call’s arguments carefully in order to trigger the vulnerable condition − If no callable API is found: • Look up the chain of calls, looking for hints − as to how to reach the vulnerable condition • Make a proof of concept file, network packet, API call, etc. Find samples online − Run through all the samples to see which ones (if any) come near or actually hit the vulnerable function − Modify the successful samples to focus in on and trigger the vulnerable code. − Have fun… Practical exploit creation
- 18. 18 ©2021 RSA Security LLC or its affiliates. All rights reserved. Demo: Example of weaponization of a Patch Tuesday
- 19. 19 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 20. 20 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 21. 21 ©2021 RSA Security LLC or its affiliates. All rights reserved. Video 1# • We start with a local access with a standard user (“test”) in an unpatched Windows 11 system • we launch the exploit code • Thanks to the exploit we can add an administrative user or execute arbitrary command with SYSTEM level. In our case we created the “admin” user. Video 2# • This video demonstrate how the exploit can be used by a Red Teamer or a real attacker • Using Runas from the C2 the attacker started a new implant with a middle integrity privilege level (administrator) Video 3# • From the new implant created with admin user the attacker use aBypassUAC technique (fodhelper.exe) to gain high integrity level. • At this point we can execute almost any program or command on the target machine. Demo explained
- 22. 22 ©2021 RSA Security LLC or its affiliates. All rights reserved.
- 23. 23 ©2021 RSA Security LLC or its affiliates. All rights reserved.
Hinweis der Redaktion
- Threat Modeling: Red Teams analyze an organization's systems and networks to identify potential threats, vulnerabilities, and risks. They help organizations prioritize their security efforts by assessing the likelihood and impact of various attack scenarios. Security Architecture Review: Red Teams evaluate an organization's security architecture, including network designs, access controls, and segmentation. They assess the effectiveness of the existing architecture in mitigating risks and provide recommendations for improvements. Zero-day Exploit Testing: Red Teams assess an organization's resilience to zero-day exploits, which are vulnerabilities unknown to software vendors. They test if the organization's systems can withstand unknown attacks, helping identify areas for patch management and incident response improvements. Adversarial Simulation: Red Teams simulate the tactics, techniques, and procedures (TTPs) of real-world threat actors, such as advanced persistent threats (APTs). This involves replicating the attack methodologies and TTPs to assess an organization's ability to detect, respond, and recover from such attacks.
- Initial Compromise: The red team will employ spear-phishing or other social engineering techniques to gain an initial foothold in the organization's network, mimicking APT28's attack vectors. This may involve crafting convincing phishing emails or exploiting vulnerabilities in publicly accessible systems. Lateral Movement and Privilege Escalation: Once inside the network, the red team will simulate APT28's tactics for lateral movement and privilege escalation. They will attempt to move laterally within the organization's systems, escalate privileges, and access critical assets or sensitive information. Techniques such as pass-the-hash, credential theft, or exploiting misconfigurations may be employed. Persistence and Evasion: The red team will strive to maintain persistence within the network and evade detection by security controls. They will employ APT28's techniques for hiding their activities, such as leveraging rootkits, backdoors, or anti-forensic tools to evade detection by antivirus or intrusion detection systems. Data Exfiltration: The red team will attempt to exfiltrate sensitive data or intellectual property from the organization's network, mimicking APT28's exfiltration methods. This may involve using covert channels, encryption, or disguising the data within seemingly innocuous network traffic.
- Adversarial Emulation requires study, time and tons of patience… Typically our IR Team and our Threat Intel teams are engaged to collect and share tools and details about techniques that could be connected with a specific actor. That is extremely helpful because could ensure we are aligned with the real actors and more importantly we can review their arsenal looking for malcode that we could reliably adopt without much reversing. However, when we discuss about initial exploitation or privilege escalations, these activity need a dedicated resources, and more importantly a ton of tests. Lots of different types of vulnerability research (the following is just a start):
- Patch Tuesday, also known as Update Tuesday, is a Microsoft-coined term that refers to the second Tuesday of every month when Microsoft releases security patches and updates for its software products, including Windows operating systems and various Microsoft applications. ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. In fact, while the primary purpose of Patch Tuesday is to enhance the security of these software products by addressing known vulnerabilities, it can inadvertently provide opportunities for Red Team operations. In this presentation we will elucidate how Patch Tuesday can be exploited by Red Teams to acquire additional exploits and compromise techniques for their security assessments.
- Research and Preparation: a. Tracking Patch Tuesday: Red Teamers should actively monitor Patch Tuesday announcements from Microsoft. They can subscribe to Microsoft's security bulletin or use other sources like security blogs and forums to stay informed about the latest updates. b. CVE Identification: As patches are released, Red Teamers must identify the Common Vulnerabilities and Exposures (CVE) associated with the fixed vulnerabilities. Microsoft typically provides detailed information about the vulnerabilities in their security advisories. CVE Analysis: a. CVE Details Examination: Red Teamers should carefully examine the details of each CVE, including the affected software, the nature of the vulnerability, and the potential impact. b. Ranking: Determine the potential severity and exploitability of the identified vulnerabilities. Some CVEs may have a high likelihood of being exploited, while others may be more challenging. Exploit Development: a. Vulnerability Exploitation: If a Red Team identifies a CVE with a high exploitability potential, they can initiate exploit development. This involves creating proof-of-concept (PoC) exploits or leveraging existing ones, especially if the vulnerability is in a widely used software component. b. Payload Crafting: Red Teamers should create malicious payloads that can be delivered to target systems once the vulnerability is successfully exploited. These payloads can be used for various purposes, including gaining remote access or escalating privileges. Testing and Validation: a. Internal Testing: Before using the developed exploits in real-world scenarios, Red Teamers should extensively test them in controlled environments to ensure they work as intended and do not raise suspicions. b. Scenario Simulation: Simulate various attack scenarios to understand the potential impact of the exploits and ensure they align with Red Team objectives. Compromise Techniques: a. Leveraging Exploits: Once exploits are ready, Red Teamers can incorporate them into their attack methodologies. These exploits can be used as initial access points into target systems. b. Post-Exploitation: Red Teams can employ various post-exploitation techniques to maintain access, move laterally, and escalate privileges within the compromised systems. Techniques like privilege escalation, credential theft, and lateral movement can be employed. Reporting and Documentation: a. Comprehensive Reporting: Document all findings, including the CVEs targeted, the exploits developed or used, and the compromise techniques employed during the Red Team engagement. b. Recommendations: Provide recommendations to the organization on how to mitigate the vulnerabilities and improve their security posture.
- What options do you think? (Q) Doing a byte by byte analysis of the code? Byte-by-byte comparison is not useful as a generic approach. On the x86 architecture (and others), there are variable-length instructions • X86: 1 instruction can be up to 14 bytes • Swapping sequential, semantically separate instructions can cause up to 28 bytes of change (Q) Disassemble all the code from the before/after files and do a source code comparison of the disassembled code? Possible, but not always practical • Generates lots of noise, due to structural changes • This becomes a search for a needle in a haystack. In fact, noise is usually introduced in a patch.
- Release the COM interfaces and clean up the resources: pIWerReport->Release() pIWerStore->Release() pIWerStoreFactory->Release() pIErcLuaSupport->Release() Uninitialize COM by calling CoUninitialize().