0x1

Master
  • Content Count

    706
  • Avg. Content Per Day

    0
  • Joined

  • Last visited

  • Days Won

    6

0x1 last won the day on December 3 2015

0x1 had the most liked content!

Community Reputation

5,047 Excellent

4 Followers

About 0x1

  • Rank
    Relative
  • Birthday 01/01/1980

Converted

  • Location
    Earth

Converted

  • Occupation
    Asceticism

Converted

  • Tox
    B86B9AE2FBDB1307DB767FD06FE93A6F356D645F7CFC9B239789CBFF636DE5354D6715270FF6

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 0x1

    .NET Reactor 5.9.8

    .NET Reactor [5.9.8.0] 01-Dec-2018 Added Universal Windows (UWP) protection support and added corresponding protection presets Added ASP.NET Core protection support Added .NET Core 2.2 protection support Added public type internalization exclusion editor (2. Protection Settings -> Public Types Internalization -> Exclusions) Added options to exclude compiler generated types and properties from obfuscation (Obfuscation -> Exclusions -> Compiler Generated Types) Added license generation support (LicenseGenNetStandard.dll) for the .NET Standard/Core environment Improved protection support for NET Standard and Core libraries Fixed issue where WPF applications sometimes not correctly detected as desktop application Fixed project file loading problem Fixed compiled XAML (BAML) reading issue Fixed mixed mode (C++/CLI) obfuscation issue Fixed Visual Studio 2017 Add-in issue Fixed dynamic encryption issue Fixed minor bugs Download [hide][Hidden Content]] Pass : level23hacktools.com
  2. 0x1

    TOR Browser 0day

    TOR Browser 0day : JavaScript Exploit ! Works on Firefox versions 41 - 50 The critical vulnerability is believed to affect multiple Windows versions of the open source Firefox web browser as far back as Firefox version 41, and up to Firefox version 50. When exploit opened by a Firefox or Tor Browser with Javascript enabled on a Windows computer, it leverage a memory corruption vulnerability in the background to make direct calls to kernel32.dll, which allows malicious code to be executed on computers running Windows. [Hidden Content] Download [hide][Hidden Content]] Ref : [hide][Hidden Content]]
  3. 0x1

    Flash CVE-2018-15982 UAF

    Adobe Flash last 0day Exploit Info Exploit : [Hidden Content] SWF file can be integrated into Alaovs files xls, doc, but the explanation will be on how the gap and modify them, in the windows system and IE SWF Decompile [Hidden Content] Notes Command Execution Bchgl Calculator x64 shellcode [Hidden Content] After modification [Hidden Content] Download [Hidden Content]
  4. 0x1

    SharpWeb

    SharpWeb is a .NET 2.0 CLR compliant project that can retrieve saved logins from Google Chrome, Firefox, Internet Explorer and Microsoft Edge. In the future, this project will be expanded upon to retrieve Cookies and History items from these browsers. Usage Usage: .\SharpWeb.exe arg0 [arg1 arg2 ...] Arguments: all - Retrieve all Chrome, FireFox and IE/Edge credentials. full - The same as 'all' chrome - Fetch saved Chrome logins. firefox - Fetch saved FireFox logins. edge - Fetch saved Internet Explorer/Microsoft Edge logins. Example: Retrieve Edge and Firefox Credentials .\SharpWeb.exe edge firefox Example: Retrieve All Saved Browser Credentials .\SharpWeb.exe all Standing on the Shoulders of Giants This project uses the work of @plainprogrammer and his work on a compliant .NET 2.0 CLR compliant SQLite parser, which can be found [Hidden Content]. In addition, @gourk created a wonderful ASN parser and cryptography helpers for decrypting and parsing the FireFox login files. It uses a revised version of his work (found [Hidden Content]) to parse these logins out. Without their work this project would not have come together nearly as quickly as it did. Source & Ref [hide][Hidden Content]]
  5. linux-exploit-suggester Quick download:[Hidden Content] Purpose Often during the penetration test engagement the security analyst faces the problem of identifying privilege escalation attack vectors on tested Linux machine(s). One of viable attack vectors is using publicly known Linux exploit to gain root privileges on tested machine. Of course in order to do that the analyst needs to identify the right PoC exploit, make sure that his target is affected by the associated vulnerability and finally modify the exploit to suit his target. The linux-exploit-suggester.sh tool is designed to help with these activities. Overview The tool is meant to assist the security analyst in his testing for privilege escalation opportunities on Linux machine, it provides following features: "Remote" mode (--kernel or --uname switches) In this mode the analyst simply provides kernel version (--kernel switch) or uname -a command output (--uname switch) and receives list of candidate exploits for a given kernel version. Using this mode one can also check for candidate user space exploits (with --pkglist-file switch) if he has access to installed packages listing (output of dpkg -l/rpm -qa commands) of examined system. "Direct" mode (default run) The basic idea behind this mode is the same as previously but additionally in an effort to produce more relevant list of candidate exploits, the tool also performs series of additional checks (like: kernel build settings aka CONFIG_*, sysctl entries and other custom checks defined on per-exploit basis) to rule out exploits that for sure won't be applicable due to OS customization. Obviously to take advantage of this mode the tool needs to be run directly on target machine. For example for 'af_packet' exploit which requirements looks like this: Reqs: pkg=linux-kernel,ver>=3.2,ver<=4.10.6,CONFIG_USER_NS=y,sysctl:kernel.unprivileged_userns_clone==1 the script (in addition to checking kernel version) will check if target kernel was built with CONFIG_USER_NS and if sysctl entry kernel.unprivileged_userns_clone is enabled. If desired those additional checks can by skipped by running with --skip-more-checks command line switch. By default tool also checks for applicable user space exploits when distribution is one of Debian, Ubuntu, RHEL/CentOS, Fedora. To skip user space exploits checks one can run with --kernelspace-only switch. Example of script's output in this mode: "CVE list" mode (--cvelist-file switch) In this mode the analyst already posesses partial/full list of CVEs that affects his target kernel and wants to verify if there are any publicly known exploits against this CVEs. Of course efectivness of this mode highly depends on completness of provided CVE list. Such list is usually constructed by manual study and examination of distribution's Changelog for the given kernel version. Alternatively for most popular distros [Hidden Content] could be used to speed up this proccess. For example following oneliner worked quite fine for me: $ (uname -s; uname -m; uname -r; uname -v) | curl -s [Hidden Content] -L -H "Accept: text/text" --data-binary @- | grep CVE | tr ' ' '\n' | grep -o -E 'CVE-[0-9]+-[0-9]+' | sort -r -n | uniq WARNING. By default in addition to comparing CVE IDs, this mode also performs additional checks to rule out exploits that won't be applicable due to OS customization (kernel build settings aka CONFIG_*, sysctl entries and other custom settings). So for the best possible results one should run it directly on tested machine or alternatively use --skip-more-checks command line switch if running on the target is not possible/not desired. "Check security" mode (--checksec switch) WARNING. This mode is in beta currently. This mode is meant to be a modern continuation of [Hidden Content]'s --kernel switch functionality. In this mode linux-exploit-suggester.sh enumerates target system for various kernel/hardware security features (KASLR, SMEP, etc.) and settings. It checks if given protection mechanism is available (builtin into the kernel): [ Available ] and (if applicable) it check if it can be disabled/enabled without recompiling the kernel (via sysctl entry or other means): [ Enabled/Disabled ] or shows [ N/A] if disabling/enabling is not possible/not supported. Example of script's output in this mode: Tips, limitations, caveats Remember that this script is only meant to assist the analyst in his auditing activities. It won't do the all work for him! That's the analyst job to determine whether given target at hand isn't patched against generated list of candidate exploits (the script doesn't look at distro patchlevel so obviously it won't do that for you) In addition to manual inspection [Hidden Content] could come handy with determining the previous one Selected exploit almost certainly will need some customization to suit your target (at minimum: correct commit_creds/prepare_kernel_cred pointers) so knowledge about kernel exploitation techniques is required Usage Default run on target machine (kernel version, packages versions and additional checks as described in "Overview" paragraph are performed to give the list of possible exploits: $ ./linux-exploit-suggester.sh As previously but only userspace exploits are checked: $ ./linux-exploit-suggester.sh --userspace-only Check if exploit(s) for given list of CVE IDs are available: $ ./linux-exploit-suggester.sh --cvelist-file <cve-listing-file> --skip-more-checks Generate list of CVEs for the target kernel and check if exploit(s) for it exists (also performs additional checks😞 $ (uname -s; uname -m; uname -r; uname -v) | curl -s [Hidden Content] -L -H "Accept: text/text" --data-binary @- | grep CVE | tr ' ' '\n' | grep -o -E 'CVE-[0-9]+-[0-9]+' | sort -r -n | uniq > <cve-listing-file> $ ./linux-exploit-suggester.sh --cvelist-file <cve-listing-file> List available hardware/kernel security mechanisms for target machine: $ ./linux-exploit-suggester.sh --checksec Running with -k option is handy if one wants to quickly examine which exploits could be potentially applicable for given kernel version (this is also compatibility mode with Linux_Exploit_Suggester): $ ./linux-exploit-suggester.sh -k 3.1 With --uname one provides slightly more information (uname -a output from target machine) to linux-exploit-suggester.sh and receives slightly specific list of possible exploits (for example also target arch x86|x86_64 is taken into account when generating exploits list): $ ./linux-exploit-suggester.sh --uname "Linux taris 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux" Optionally --pkglist-file <file> could be provided to -k or --uname to also check for user space exploits: (remote machine) $ dpkg -l > dpkgOutput.txt $ ./linux-exploit-suggester.sh --uname "Linux taris 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux" --pkglist-file dpkgOutput.txt In terms of generated list of exploits its identical with executing (directly on the given remote machine): (remote machine) $ ./linux-exploit-suggester.sh --skip-more-checks Sometimes it is desired to examine only package listing (in this case only check for userspace exploits is performed): (remote machine) $ dpkg -l > dpkgOutput.txt $ ./linux-exploit-suggester.sh --pkglist-file dpkgOutput.txt As previously but no package versioning is performed (handy for quick preliminary checking if any package for which user space exploit is available is installed): $ ./linux-exploit-suggester.sh --pkglist-file dpkgOutput.txt --skip-pkg-versions Kernel version number is taken from current OS, sources for possible exploits are downloaded to current directory (only kernel space exploits are examined): $ ./linux-exploit-suggester.sh --fetch-sources --kernelspace-only Kernel version number is taken from command line, full details (like: kernel version requirements, comments and URL pointing to announcement/technical details about exploit) about matched exploits are listed: $ ./linux-exploit-suggester.sh -k 4.1 --full Kernel version number is taken from current OS, binaries for applicable exploits are downloaded (if available) to current directory, additional checks are skipped: $ ./linux-exploit-suggester.sh --fetch-binaries --skip-more-checks Note however that --fetch-binaries is not recommended as it downloads binaries from generally not trusted sources and most likely these binaries weren't compiled for your target anyway. It should be used as a kind of last resort option when you're running out of time during your pen testing engagement and there is no compiler available on your target at hand. Misc The tool was inspired by the [Hidden Content] script and it contains all the exploits that are present there (for kernels 2.6+) plus all more recent Linux kernel exploits It is available in [Hidden Content] distribution I'm not responsible for how the tool is used and where it is used Source & Ref. [hide][Hidden Content]]
  6. 0x1

    SILENTTRINITY

    SILENTTRINITY An asynchronous post-exploitation agent powered by Python, IronPython, C# and .NET's DLR Requirements Server requires Python >= 3.7 SILENTTRINITY C# implant requires .NET >= 4.5 How it works Notes .NET runtime support The implant needs .NET 4.5 or greater due to the IronPython DLLs being compiled against .NET 4.0, also there is no ZipArchive .NET library prior to 4.5 which the implant relies upon to download the initial stage containing the IronPython DLLs and the main Python code. Reading the source for the [Hidden Content] it seems like we can get around the first issue by directly generating IL code through IKVM (I still don't understand why this works). However this would require modifying the compiler to generate a completely new EXE stub (definitely feasible, just time consuming to find the proper IKVM API calls). C2 Comms Currently the implant only supports C2 over HTTP 1.1, .NET 4.5 seems to have a native WebSocket library which makes implementing a WS C2 channel more than possible. HTTP/2 client support for .NET's HttpClient API is in the works, just not yet released. The implant and server design are very much "future proof" which should make implementing these C2 Channels pretty trivial when the time comes. COM Interop [Hidden Content] Python Standard Library We technically could load/use IronPython's stdlib instead of calling .NET APIs but this would require writing some "magic" dependency resolving code. Possibly could modify [Hidden Content] to do this automagically. Inject into unmanaged process [Hidden Content] If you need some help setting up your environment. Reporting issues Reporting any issue will be appreciated, but please, feel free to use this [Hidden Content]. Source & Ref. [hide][Hidden Content]]
  7. 0x1

    Payloads All The Things

    Payloads All The Things A list of useful payloads and bypasses for Web Application Security. Feel free to improve with your payloads and techniques ! [Hidden Content] Source & Ref [hide][Hidden Content]]
  8. you are on section Post Infected i remove link now this is best
  9. 0x1

    Casper Rat Windows

    Maybe see again one more time , links work good
  10. 0x1

    RedELK

    Red Team's SIEM - easy deployable tool for Red Teams used for tracking and alarming about Blue Team activities as well as better usability for the Red Team in long term operations. Initial public release at BruCON 2018: [Hidden Content] Red Team's SIEM that serves two goals: Enhanced usability and overview for the red team operators by creating a central location where all relevant operational logs from multiple teamservers are collected and enriched. This is great for historic searching within the operation as well as giving a read-only view on the operation (e.g. for the White Team). Especially useful for multi-scenario, multi-teamserver, multi-member and multi-month operations. Also, super easy ways for viewing all screenshots, IOCs, keystrokes output, etc. Spot the Blue Team by having a central location where all traffic logs from redirectors are collected and enriched. Using specific queries its now possible to detect that the Blue Team is investigating your infrastructure. Here's a conceptual overview of how RedELK works. Current state and features on todo-list This project is still in beta phase. This means that it works on our machines and our environment, but no extended testing is performed on different setups. This also means that naming and structure of the code is still subject to change. We are working (and you are invited to contribute) on many things, amongst others: Include the real external IP address of a beacon. As Cobalt Strike has no knowledge of the real external IP address of a beacon session, we need to get this form the traffic index. So far, we have not found a true 100% reliable way for doing this. Support for Apache and Nginx redirectors. Fully tested and working filebeat and logstash configuration files that support Apache and Nginx based redirectors. Solve rsyslog max log line issue. Rsyslog (default syslog service on Ubuntu) breaks long syslog lines. Depending on the CS profile you use, this can become an issue. As a result, the parsing of some of the fields are properly parsed by logstash, and thus not properly included in elasticsearch. Ingest manual IOC data. When you are uploading a document, or something else, outside of Cobalt Strike, it will not be included in the IOC list. We want an easy way to have these manual IOCs also included. One way would be to enter the data manually in the activity log of Cobalt Strike and have a logstash filter to scrape the info from there. Ingest e-mails. Create input and filter rules for IMAP mailboxes. This way, we can use the same easy ELK interface for having an overview of sent emails, and replies. User-agent checks. Tagging and alarming on suspicious user-agents. This will probably be divided in hardcoded stuff like curl, wget, etc connecting with the proper C2 URL's, but also more dynamic analysis of suspicious user-agents. DNS traffic analyses. Ingest, filter and query for suspicious activities on the DNS level. This will take considerable work due to the large amount of noise/bogus DNS queries performed by scanners and online DNS inventory services. Other alarm channels. Think Slack, Telegram, whatever other way you want for receiving alarms. Fine grained authorisation. Possibility for blocking certain views, searches, and dashboards, or masking certain details in some views. Useful for situations where you don't want to give out all information to all visitors. Supported tech and requirements RedELK currently supports: Cobalt Strike teamservers HAProxy for HTTP redirector data. Apache support is expected soon. Tested on Ubuntu 16 LTS RedELK requires a modification to the default haproxy configuration in order to log more details. Source && Download [hide][Hidden Content]]
  11. 0x1

    TunSafe

    A high performance and secure VPN client that uses the [Hidden Content]. TunSafe makes it extremely simple to setup blazingly fast and secure VPN tunnels between Windows and Linux. Cryptographically Sound TunSafe uses state-of-the-art modern proven cryptography - Curve25519, ChaCha20, Poly1305, BLAKE2 and HKDF. No need to worry that third parties will spy on your communications. High Performance TunSafe's multithreaded design gives 6x higher throughput than OpenVPN, while using minimal computing resources. The First of its Kind TunSafe is the first VPN client for Windows using the WireGuard protocol. With the continuously increased traction of WireGuard - now is a good time to switch away from legacy VPN implementations. Easy to Use No more messy key and certificate generation like with OpenVPN or IPSec. With TunSafe all you need is a simple configuration file that can be easily distributed or modified. This file is typically provided to you by the VPN provider. Download [hide][Hidden Content]] User Guides [hide][Hidden Content]] Tested on Kali Linux (apt-get install wireguard) and info to install on linux [hide][Hidden Content]]
  12. 0x1

    888-RAT v.1.0.8 Cracked by Artist

    Read Rules POST THANKS = BANNED If you want to thank a user for their contribution please use the "Thanks Button" otherwise it spams the thread. If you do this your post will be deleted. Users who continue to do this will be banned.
  13. 0x1

    beebug

    beebug - A tool for checking exploitability beebug is a tool that can be used to verify if a program crash could be exploitable. This tool was presented the first time at [Hidden Content]2018 in Barcelona. Some implemented functionality are: Stack overflow on libc Crash on Program Counter Crash on branch Crash on write memory Heap vulnerabilities Read access violation (some exploitable cases) Help to analyze a crash (graph view) Dependencies r2pipe pydot graphviz pyqtgraph Graph generation ref & more info : [hide][Hidden Content]]
  14. 0x1

    Exploit Pack Priv8

    Update Version [Hidden Content]
  15. 0x1

    Atomic Red Team

    Atomic Red Team allows every security team to test their controls by executing simple "atomic tests" that exercise the same techniques used by adversaries (all mapped to [Hidden Content]). Philosophy Atomic Red Team is a library of simple tests that every security team can execute to test their controls. Tests are focused, have few dependencies, and are defined in a structured format that be used by automation frameworks. Three key beliefs made up the Atomic Red Team charter: Teams need to be able to test everything from specific technical controls to outcomes. Our security teams do not want to operate with a “hopes and prayers” attitude toward detection. We need to know what our controls and program can detect, and what it cannot. We don’t have to detect every adversary, but we do believe in knowing our blind spots. We should be able to run a test in less than five minutes. Most security tests and automation tools take a tremendous amount of time to install, configure, and execute. We coined the term "atomic tests" because we felt there was a simple way to decompose tests so most could be run in a few minutes. The best test is the one you actually run. We need to keep learning how adversaries are operating. Most security teams don’t have the benefit of seeing a wide variety of adversary types and techniques crossing their desk every day. Even we at Red Canary only come across a fraction of the possible techniques being used, which makes the community working together essential to making us all better. See: [Hidden Content] Getting Started [Hidden Content] Ref : [hide][Hidden Content]]