Leaderboard

Black Shadow hacking team publish huge Israeli medical data leaks after $1.000.000 dollars payment declined Cyberattack hackers said they'd leak more of the company's data if it failed to pay $1 million bitcoin ransom Israel's Shirbit insurance company, which has reportedly been the victim of an extensive data breach carried out by the Black Shadow group, refused to meet a 9 a.m. Sunday deadline to prevent more of the company's information being released, Channel 13 reported and cited in The Jerusalem Post. The company has consistently refused to meet the ransom deadline and comes just a day after the group had already released more documents containing the personal information of Shirbit employees and customers over the weekend. "Included in the released documents are screenshots of WhatsApp conversations, ID cards, marriage certificates and financial documents," reported the Post. Previous negotiations held between Shirbit and Black Shadow also came to nought, as the hacker group released other information in its possession after those talks ended without resolution. On Wednesday night, the hackers demanded that Shirbit send 50 bitcoin ($961,110) to their bitcoin wallet within 24 hours or they would face a double hit; the release of further data as well as the demand rising to 100 bitcoin ($1,922,220). If a further 24 hours was allowed to elapse, the demand would rise to 200 bitcoin ($3,844, 440). The price of bitcoin recently surged to a record almost $20,000. "After that we will sell the data to others," the hackers warned, maintaining that they would leak additional data at the end of every 24-hour cycle. According to the Post, Black Shadow claimed credit for the attack in a tweet that read: "A huge cyberattack has been taken [sic] place by Black Shadow team. There has been a massive attack on the network infrastructure of Shirbit Company, which is in Israel economic sphere. https://www.gov.il/en/departments/news/news_shirbit https://www.i24news.tv/en/news/israel/1607253802-shirbit-declines-to-pay-hackers-as-it-faces-further-threats-of-leaked-documents-increased-ransom

Adunate...poate sunt de folos cuiva whathttp://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php https://netsec.ws/?p=337 https://medium.com/oscp-cheatsheet/oscp-cheatsheet-6c80b9fa8d7e https://highon.coffee/blog/penetration-testing-tools-cheat-sheet/ https://0xdf.gitlab.io/2018/12/02/pwk-notes-smb-enumeration-checklist-update1.html https://noobsec.net/oscp-cheatsheet/#Port-139-445-SMB https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/4/html/reference_guide/ch-nfs https://medium.com/@2aware2care/enumeration-1976c5d55b1b https://hausec.com/pentesting-cheatsheet/ https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/ https://oscpnotes.infosecsanyam.in/My_OSCP_Preparation_Notes.html https://rana-khalil.gitbook.io/hack-the-box-oscp-preparation/linux-boxes/friendzone-writeup-w-o-metasploit eful-links/content/https://www.bytefellow.com/oscp-ultimate-cheatsheet/ https://pentesttools.net/ https://twitter.com/JaneScott/status/1144134954353217536 https://fareedfauzi.gitbook.io/oscp-notes/ https://github.com/areyou1or0/OSCP https://cd6629.gitbook.io/oscp-notes/ https://gtfobins.github.io/ https://www.semperis.com/blog/tools-attacking-active-directory https://www.aldeid.com/wiki/TryHackMe-Attacking-Kerberos https://hashcat.net/wiki/doku.php?id=example_hashes https://www.exploit-db.com/google-hacking-database https://www.kyylee.com/oscp-notes https://portswigger.net/web-security https://github.com/Runefeather/OSCP-Cheatsheet https://liodeus.github.io/2020/09/18/OSCP-personal-cheatsheet.html search: "log.[debug/info/warn/error]" search in js uri:"document.""location.[search,path,href,hash]","erHTML" https://medium.com/swlh/hacking-json-web-tokens-jwts-9122efe91e4a https://github.com/security-prince/PWK-OSCP-Preparation-Roadmap/blob/master/README.md https://github.com/Runefeather/OSCP-Cheatsheet EDIT:

Voi nu vedeti ca asta e prajit in fiecare postare? Nu inteleg de ce nu e banat

This talk will reveal the iOS 13 exploits I showcased earlier on Twitter (@08Tc3wBB) – an exploit chain for iOS 13.7 that relies upon a different kernel vulnerability since the 13.6 update patched the old one. I’ll be talking about the root cause and techniques used during the exploit development to bypass the mitigations that are unique to iOS to ultimately get the privilege of reading and writing kernel memory. === 08Tc3wBB is a Bug Bounty Hunter and a Security Researcher.

Slipstream This is a proof of concept for the NAT slipstreaming vulnerability discussed here. Building slipstream has no external dependencies and does not depend on CGO. You can build the executable and/or cross compile for other platforms using the go compiler with the following command: go build Usage slipstream will produce a single executable that is both the server and client. You must first setup the server on a remote host that it outside of your NAT: ./slipstream -l -lp 5060 You can then use slipstream to connect to the host outside of your NAT and let it attempt to connect back to you: ./slipstream -ip <local ip> -host <remote host> -rp 5060 -lp <local port> Why another implementation? After spending many hours attempting to get the original code working with no success I was left at a point of not knowing if my router was simply not vulnerable, I had misconfigured the code, the code was broken, or there were other implementation details stopping it from working. Eventually I was shown another implementation of the attack that skipped over the web based delivery instead focusing just on exploitation of the ALGs. This code is heavily based on that implementation though provides an end to end client and server to make testing simpler and avoids using an HTTP client to send the request due to issues discovered. What about web based delivery? At time of writing the major browser vendors (Chromium and Firefox) have since provided mitigations against this through blocking outbound connections to port 5060. It's theoretically possible that this could be bypassed by switching to a different port or attempting to use a different ALG altogether. I'm assuming SIP was chosen due to it's similarity to HTTP and widespread use. In testing some of the higher end enterprise gear we discovered that due to slight differences (the / used in the HTTP path, the HTTP version, rather than SIP/2.0, and differing headers) some networking equipment fails to parse the SIP requests generated by an HTTP client and simply drops them at the router. Given that it's been blocked by browsers and delivery is unreliable by HTTP client no attempt was made to port the newer webscan technique for local ip discovery for web based delivery or identify a browser bypass. License MIT Sursa: https://github.com/jrozner/slipstream

Leaking Browser URL/Protocol Handlers By Rotem Kerner | December 03, 2020 FortiGuard Labs Threat Research Report Affected platforms: Windows, Linux Impacted parties: Chrome, Firefox and Edge Impact: Leaking sensitive data Severity level: Medium Assigned CVEs: CVE-2020-15680 An important step in any targeted attack is reconnaissance. The more information an attacker can obtain on the victim the greater the chances for a successful exploitation and infiltration. Recently, we uncovered two information disclosure vulnerabilities affecting three of the major web browsers which can be leveraged to leak out a vast range of installed applications, including the presence of security products, allowing a threat actor to gain critical insights on the target. In this post we will discuss what are protocol handlers and disclose two information disclosure vulnerabilities affecting three major browsers (namely - Firefox, Edge and Chrome). Exploiting these vulnerabilities will enable a remote attacker to identify the presence of a vast amount of applications that may be installed on a targeted system. Overview - What Are Protocol Handlers? Generally speaking when talking about Protocol Handlers we are referring to a mechanism which allows applications to register their own URI scheme. This enables the execution of processes through the use of URI formatted strings. The Windows OS manages custom URL handlers under the following key- HKEY_CURRENT_USER\SOFTWARE\Classes\* HKEY_LOCAL_MACHINE\SOFTWARE\Classes\* HKEY_CLASSES_ROOT\* When a URL Handler is invoked the OS is searching within those locations for keys containing values with the name “URL Protocol”. For instance, we can use regedit to inspect the path at HKEY_CLASSES_ROOT\msteams and see that it contains the special Value of “URL Protocol”. Figure 1 Looking further into HKEY_CLASSES_ROOT\msteams\shell\open\command\ we can see the actual command that gets invoked - Figure 2 Figure 3 In this example the browser will launch Teams.exe when a url that starts with “msteams” is clicked. Web browsers will enable their users to click on links with non-http schemes which will result in prompting the user with a message box asking them if they want to let another application handle this URL. Figure 4 Though it requires user interaction and thus poses a limited risk, it expands the attack surface beyond the browser borders. An attacker could craft a special web page which triggers another potentially vulnerable application. In some cases, such attacks may bypass protection measures such as Smart Screen and other security products. While exploring the potential of attacking the browsers through the different protocol handlers I got curious as to whether web browsers somehow disclose what protocols handlers exist on a targeted system. The short answer is yes. Leaking Protocol Handlers In this section we disclose how both Chrome, Edge and Firefox were circumvented in order to disclose which protocol handlers exist on a targeted system. It's worth mentioning that these findings are the result of manually playing with HTML/CSS components with the emphasis on finding a difference in behavior when referring (using some elements) to existing and non-existing URL handlers. The environment I’ve been testing on is Windows 10 but it is fair to assume that the same vulnerabilities exist on other platforms (such as Linux and Mac). Leaking Firefox protocol handlers (CVE-2020-15680) This vulnerability has been tested on Firefox 78.0.1 (64-bit) under Windows 10. To leak the protocol handlers in Firefox we leverage differences in the way firefox renders images sourced from existing and non-existing protocol handlers. For example, if we will try to load a web page containing the following element - And observe the elements styling using developer tools we would see that the default styling for broken images generate element with size of 24x24 as can be seen in Figure-5. Figure 5 Unlike the example above, if we try and create an image element and set source to some non-existent handler like the following. This will result with an element with different sizing of 0x0 as can be seen in Figure-6. Figure 6 This difference can be measured using a simple JS script Basing on this a malicious actor may perform a brute-force attack to disclose the different protocol handlers on a targeted system. The following example code will print whether a handlers exists or not on a targeted system. Leaking Chrome and Edge protocol handlers This vulnerability has been tested on Chrome 83.0.4103.116 under Windows 10. The exploitability of this vulnerability may be less stealthy but still yields equivalent results as the Firefox vulnerability. The mechanism here was different than the one in Firefox, here we leverage the fact that the window lose focus whenever the user is challenged with the message box as can be seen in figure-7. Figure 7 So, in order to detect if a given handler exists on the victim we take the following steps. First, we dynamically generate a link that is made of the scheme we would like to detect like such - Then we trigger the link and detect whether the document has focus: That will work for a one time check however if we would like to brute force an entire list of handlers we would have to get rid of the message box every time it pops up or else the document.hasFocus() will always return true. Figure 8 The technique we came up with was to redirect the user to an entirely different domain/ip which will eliminate any previously opened message box. Figure-8 draws the general idea of how the flow should be carried out in order to work. Protocol Handler Test page performs the actual test and saves the results to the back-end. In case the handler exists, it will redirect to “Redirect-Back Page” which exists on domain2.com. The redirection will get rid of the message box. Finally, back to the Protocol Handler Test Page for the next handler test. Vulnerabilities Impact Such information disclosure vulnerability could be exploited in several different ways. Here are some examples: Identifying communication channels: By listing the handlers an attacker can get a hint to what platforms he may use for reaching the targeted user. For instance, detecting social applications such as Slack, Skype, WhatsApp or Telegram may be used for communicating with the target. General reconnaissance: A wide range of applications nowadays uses custom URL handlers and can be detected using this vulnerability. Some examples: music players, IDE, office applications, crypto-mining, browsers, mail applications, antivirus, video conferencing, virtualizations, database clients, version control clients, chat clients, voice conference apps, shared storages Pre-exploitation detection: Exploit kits may leverage this information in order to identify if a potentially vulnerable application is present without exposing the vulnerability itself. Detecting Security solutions: Many security solutions such as AV products register protocol handlers whose presence can be exposed by leveraging the vulnerabilities because they have custom protocol handlers installed. Attackers may use this to further customize their attack to be able to circumvent any protection mechanism set by those security solutions. User Fingerprinting: reading what protocol handlers exist on a system may also be used in order to improve browser/user fingerprinting algorithms. Vendor Response Below is a table specifying the vendor responses: Vendor Vendor Response Mozilla The security team at mozilla were quick to respond and have issued a fix for the bug. - CVE-2020-15680 Microsoft The vendor decided not to fix the issue due to the following explanation - “This is by design (and not a security issue) - if we want to support registered protocol handler links from the browser, it seems like there'll be various ways to detect whether a link for a particular protocol handler worked or not” Google The vendor decided to treat this as a “user fingerprinting issue” rather than a security issue and are working on a patch. “The general consensus on the security team is that none of the concerns here relate to leaking user data, and that this is best handled as a fingerprinting bug” Summary In this post we uncovered a new type of information disclosure vulnerabilities in Chrome, Edge and Firefox and identified how attackers can leverage them to gain valuable insights which could assist them in compromising their targets. When browsers are enabling the interaction with other applications through URL handlers, they may be easing the engagement with third party software, but they also enable a wider attack surface by giving the attacker a chance to attack the user through other applications. While Microsoft and Google currently don't consider it a security issue, we believe that being able to expose the presence of other software, including security software, on targeted devices should be prevented. With that being said, we anticipate that in the near future we shall see an increase in the number of attacks which exploit the different URL handlers through the user's web browser. FortiEDR can detect and block these browser-based exploits and provide visibility into such attempts. Sursa: https://www.fortinet.com/blog/threat-research/leaking-browser-url-protocol-handlers

Poate reusesti cu qemu, dar daca nu e ceva "facut", ar putea sa iti ia ceva timp sa il face sa mearga.

Ca sa fiu mai explicit ca vad ca nu se intelege din primul post. Exista diferite arhitecturi de procesoare! Sistemele de operare lucreaza la 'cel mai' low level, direct cu instructiuni in procesor. Ca procesorul sa poata intelege codul programului(OS) trebuie ca programul sa fie compilat pentru procesorul respectiv. (Adica instructiunile programului sa fie in limbajul procesorului) Havoc OS este creeat si compilat pentru telefoane. Telefoanele NU au procesoare cu aceeasi arhitectura ca PC-ul tau! Telefoanele au de obicei un procesor arm (de arhitectura RISC) iar PC-urile au x86. Asta inseamna ca CPU-ul din PC nu poate intelege instructiunile arm din havocOS. Din exact acelasi motiv nu poti instala windows pe un telefon. Windows e compilat pentru x86. (telefoanele sunt arm) Ca sa poti rula android pe pc ai nevoie de un build x86 de android (adica o versiune tradusa pentru procesorul tau). Havoc OS nu are un build oficial pentru procesoare x86. (doar dev branch pe github) Daca vrei sa-ti instalezi HavocOS pe PC (in vm sau direct) trebuie sa-ti compilezi tu un build pt procesorul tau (un build x86).

EasyRecon is a script that do the initial reconnaissance of target automatically. To scan Google, simply run: $ ./easyRecon.sh google.com Setup To install EasyRecon, clone this repository. EasyRecon relies on a couple of tools to be installed so make sure you have them: subfinder httprobe waybackurls Please make sure that as most of these tools are written in Go, that you have Go installed and configured properly. Make sure that when you type any of the above commands in the terminal, they are recognized and work. Usage $ ./easyRecon.sh example.com Features Enumerate all the existing domains with subfinder Seperate live domains from all existing domains httprobe Spider the target and save all the URLS of target using waybackurls grep all the js files and endpoints from the target Download easyrecon-main.zip or git clone https://github.com/cspshivam/easyrecon.git Source

2012 își vrea apk urile 'anapoi'