Nytro

Bypass Instagram SSL Certificate Pinning for iOS Hassan, May 5th, 2020 · 3 min read Once again, with another iOS app, and this time we will go through the Instagram iOS app trying to bypass its SSL Certificate Pinning protection. DISCLAIMER: The articles, tutorials, and demos provided on this blog are for informational and educational purposes only, and for those who’re willing and curious to know and learn about Ethical Hacking, Cybersecurity, and Penetration Testing. You shall not misuse the information to gain unauthorized access or any other illegal use. SSL Pinning We have mentioned previously in Bypass Facebook SSL Certificate Pinning for iOS blog, the meaning of SSL Pinning, and the importance of implementing it. Now let’s download the latest version of the Instagram iOS app and step up an HTTP proxy from Wi-Fi settings. Open Burp Suite and configure your proxy options. Then, open the Instagram app and trying to login. If you are using the latest version of Burp Proxy v2020.4 now supports TLS 1.3, you will see a this message in your Dashboard -> Event log tab: Also, your Instagram app will show you a this alert: That’s because of their SSL Certificate Pinning protection which must be bypassed to be able to intercept requests and responses from their server. Reverse Engineering Let’s get the decrypted IPA for the app to reverse-engineer it. Using Frida iOS Dump you will be able to pull the app IPA from your jailbroken iPhone. After the script finish, change the app extension from .ipa to .zip then uncompress it. Copy 1$ mv Instagram.ipa Instagram.zip 2$ unzip Instagram.zip We need to locate the binary that has the SSL Pinning implementation to reverse it. A good way to locate it by using a tools like grep or ack to search for strings that indicate the validation process inside the extracted Payload folder. From the app alert message, we can use strings like OpenSSL, verify error, signed certificate, and verifier failure. Copy 1$ grep -rins "verify error" . 2Binary file ./Instagram.app/Frameworks/FBSharedFramework.framework/FBSharedFramework matches A Mach-O 64-bit shared library binary file called FBSharedFramework was found. It seems the one we found in the Facebook app but less size. We will use Hopper Disassembler to open the binary file. A good start is to search with the alert error shown on the app. So, we will try to find the branch that responsible for OpenSSL cert verify error. We found a match result for our string search. Click on it will navigate us to its location at the __cstring segment which contains all of the strings that are included in the application source code and their hexadecimal offsets. To locate where the string is used in Hopper you can double-click on the cross-reference (XREF) to move to where the string is referenced in the binary. Now we need to gain a better understanding of the code logic that responsible for SSL Pinning using the control flow graph (CFG). Our mission is to avoid reaching the OpenSSL branch so that the app can work normally without any error alerts. After analyzing the control flow graph (CFG) starting from your bottom branch, it seems very similar to the one that we found in the Facebook app. We can found the same isolated branch that doesn’t reach the OpenSSL cert verify error branch. We have to invert the b.ne (short for “Branch if Not Equal”) instruction which branches, or “jumps”, to the address specified if, and only if the zero flag is clear, to the b.eq (short for “Branch if Not Equal”) instruction which branches, or “jumps”, to the address specified if, and only if the zero flag is clear. So, instead of entering to loc_22031c branch that causing the OpenSSL cert verify error, it entering the valid branch. Binary Patching A simple way to do this is by copying the hex encoding for the instruction that we want to change, then past it in an online HEX to ARM converter to get its ARM64 instruction. Then, copy the instruction you got and change it from B.NE to B.EQ as we want it to be. Past it in an online ARM to HEX converter to get our new ARM64 HEX values, as we explained in Bypass Facebook SSL Certificate Pinning for iOS blog. Now, all we have to do is changing the instruction encoding for b.ne from 41 0C 00 54 to 40 0C 00 54 using the hex editor in hopper. Then, save and extract our new binary, from File Menu -> Choose Produce New Executable and replace the new executable with the old one in the same app directory. Now, let’s compress our new Payload folder and change to an IPA again. Copy 1$ zip -r Instagram.zip Payload 2$ mv Instagram.zip Instagram.ipa Copy the new IPA to your jailbroken iPhone using iFunbox and install it using Filza File Manager. Intercepting After a successful installation for the modified application, let’s open it and login when we intercepting the requests using Burp Suite. Now we can intercept all the requests and find interesting vulnerabilities at new endpoints then submit them to Facebook Bug Bounty Program. Sursa: https://www.cyclon3.com/bypass-instagram-ssl-certificate-pinning-for-ios

T1111: Two Factor Interception, RSA SecurID Software Tokens 06/05/2020 | Author: Admin Introduction During Red Team Operations, it is not uncommon to find systems or applications related to the engagement objectives being protected by Two Factor Authentication. One of the solutions that we frequently encounter is RSA SecurID Software Tokens. Strategies to circumvent or intercept tokens when faced with such deployments are therefore always desirable; this technique is described in MITRE ATT&CK T1111. In this blog post, we will outline several potential approaches for intercepting RSA SecurID Software Tokens, including the approach that we opted for during our own operations. During the outlined scenarios, we assume access to the victim’s endpoint has already been achieved. Extraction using Screenshots Taking a screenshot is perhaps the straightforward option for token interception and is likely the first idea that would come to anyone’s mind. However, there are a couple of downfalls. Firstly, we are assuming that the software is running and is visible on the client desktop. The second potential problem is that the user may have different configured tokens as can be seen in the image below: As such, if we need to gain access to an account that is not presently visible on the screen, we need to interactively select the token. This approach is unlikely to be viable during a Red Team scenario. Hooking Functions Another potential approach would have been hooking the SetClipboardData function or the one responsible for drawing the token value on the screen. A potential risk with this method is that we need to inject into the current process, a technique that we try to avoid as much as possible. This approach also isn’t as reliable as you might expect, with research showing that a lot of unrelated junk is present on the GUI functions and the SetClipBoardData function would only work if the user pressed the Copy button. For these reasons, we decided to perform further research on how to extract the tokens in a more OpSec friendly strategy. Analysing the Application When reversing the RSA SecureID process in IDA it quickly becomes clear that the application functionality is relatively limited and only several functions were available. After some analysis of the application, the following function was discovered: The program was performing Signature Verification on the desktopclient.dll and then loading the library using the QLibrary::Load function as can be seen on the image above: Since the main executable had limited functions, the focus switched on the desktopclient.dll library. Loading desktopclient.dll in IDA, it was noted that it was making several calls to ole32.dll APIs. At this point it was highly likely that the communication was being achieved using COM. Using OLEView .NET, we can see that two classes are available: RsaTokenService Token OLEView .Net allows you to view a COM object type library (which is a binary file that stores information about object properties and methods). The following interfaces were discovered: [Guid("13a78cfa-ff65-4157-a90d-05afdb16f3c6")] interface IRsaTokenService { /* Methods */ string getCurrentCode(string serial, string pin, [Out] Int32& timeleft); string getNextCode(string serial, string pin, [Out] Int32& timeleft); void displayHelpTopic(string topic); string getCurrentTokencode(); string getNextTokencode(); /* Properties */ string Serials { get; } } [Guid("84652502-e607-4467-a216-be093824e90d")] interface IToken { /* Methods */ void Init(string serial); bool IsPinValid(string pin); /* Properties */ string serialNumber { get; } int otpInterval { get; } bool isPinRequired { get; } string url { get; } string userId { get; } string userFirstName { get; } string userLastName { get; } string label { get; } long deathDate { get; } bool shouldPrependPin { get; } string iconData { get; } int iconType { get; } int digits { get; } string extendedAttributes { get; } } Extracting the Tokens On first glance, the methods described on this interfaces were quite promising and a test harness was created to call them to determine if they functioned as described. To use this COM object, first add a reference of the rsatokenbroker Library: After adding the reference, the following steps were followed for the token extraction: Create an Instance of the RSATokenService class Retrieve all the registered serial numbers of the tokens. Create an Instance of the Token class using the previously retrieved serial number Extract related information from the Token class properties like URL, UserId etc. Call getCurrentCode(string serial, string pin, [Out] Int32& timeleft); RSA SecurID supports protecting the token by a PIN but in our implementation we didn’t have the opportunity to test this configuration further. A simple C# program that extracts all the registered tokens and associated information can be found on GitHub. Conclusions Using the COM object provided us with an interface to extract the tokens in an OpSec safe way, avoiding injecting any process and calling any suspicious APIs. Having a software token, on the same device where the users’ credentials can be compromised is generally a bad idea and counteracts the benefits that many Multi Factor solutions provide. To mitigate against this type of “attack” we would recommend relying on hardware tokens, or using separate hardware (such as a mobile phone) for generating the software tokens. This blog post was written by Rio Sherri. Sursa: https://www.mdsec.co.uk/2020/05/t1111-two-factor-interception-rsa-securid-software-tokens/

Source Engine Memory Corruption via LUMP_PAKFILE impost0r May 5, 2020 A month or so ago I dropped a Source engine zero-day on Twitter without much explanation of what it does. After determining that it’s unfortunately not exploitable, we’ll be exploring it, and the mess that is Valve’s Source Engine. History Valve’s Source Engine was released initially on June 2004, with the first game utilizing the engine being Counter-Strike: Source, which was released itself on November 1, 2004 - 15 or so years ago. Despite being touted as a “complete rewrite” Source still inherits code from GoldSrc and it’s parent, the Quake Engine. Alongside the possibility of grandfathering in bugs from GoldSrc and Quake (GoldSrc itself a victim of this), Valve’s security model for the engine is… non-existent. Valve not yet being the powerhouse they are today, but we’re left with numerous stupid fucking mistakes, dude, including designing your own memory allocator (or rather, making a wrapper around malloc.). Of note - it’s relatively common for games to develop their own allocator, but from a security perspective it’s still not the greatest. The Bug The byte at offset A47B98 in the .bsp file I released and the following three bytes (\x90\x90\x90\x90), parsed as UInt32, controls how much memory is allocated as the .bsp is being loaded, namely in CS:GO (though also affecting CS:S, TF2, and L4D2). That’s the short of it. To understand more, we’re going to have to delve deeper. Recently the source code for CS:GO circa 2017’s Operation Hydra was released - this will be our main tool. Let’s start with WinDBG. csgo.exe loaded with the arguments -safe -novid -nosound +map exploit.bsp, we hit our first chance exception at “Host_NewGame”. ---- Host_NewGame ---- (311c.4ab0): Break instruction exception - code 80000003 (first chance) *** WARNING: Unable to verify checksum for C:\Users\triaz\Desktop\game\bin\tier0.dll eax=00000001 ebx=00000000 ecx=7b324750 edx=00000000 esi=90909090 edi=7b324750 eip=7b2dd35c esp=012fcd68 ebp=012fce6c iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 tier0!CStdMemAlloc::SetCRTAllocFailed+0x1c: 7b2dd35c cc int 3 On the register $esi we can see the four responsible bytes, and if we peek at the stack pointer – Full stack trace removed for succinctness. 00 012fce6c 7b2dac51 90909090 90909090 012fd0c0 tier0!CStdMemAlloc::SetCRTAllocFailed+0x1c [cstrike15_src\tier0\memstd.cpp @ 2880] 01 (Inline) -------- -------- -------- -------- tier0!CStdMemAlloc::InternalAlloc+0x12c [cstrike15_src\tier0\memstd.cpp @ 2043] 02 012fce84 77643546 00000000 00000000 00000000 tier0!CStdMemAlloc::Alloc+0x131 [cstrike15_src\tier0\memstd.cpp @ 2237] 03 (Inline) -------- -------- -------- -------- filesystem_stdio!IMemAlloc::IndirectAlloc+0x8 [cstrike15_src\public\tier0\memalloc.h @ 135] 04 (Inline) -------- -------- -------- -------- filesystem_stdio!MemAlloc_Alloc+0xd [cstrike15_src\public\tier0\memalloc.h @ 258] 05 (Inline) -------- -------- -------- -------- filesystem_stdio!CUtlMemory<unsigned char,int>::Init+0x44 [cstrike15_src\public\tier1\utlmemory.h @ 502] 06 012fce98 7762c6ee 00000000 90909090 00000000 filesystem_stdio!CUtlBuffer::CUtlBuffer+0x66 [cstrike15_src\tier1\utlbuffer.cpp @ 201] Or, in a more succinct form - 0:000> dds esp 012fcd68 90909090 The bytes of $esi are directly on the stack pointer (duh). A wonderful start. Keep in mind that module - filesystem_stdio — it’ll be important later. If we continue debugging — ***** OUT OF MEMORY! attempted allocation size: 2425393296 **** (311c.4ab0): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000032 ebx=03128f00 ecx=012fd0c0 edx=00000001 esi=012fd0c0 edi=00000000 eip=00000032 esp=012fce7c ebp=012fce88 iopl=0 nv up ei ng nz ac po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010292 00000032 ?? ??? And there we see it - the memory allocator has tried to allocate 0x90909090, as UInt32. Now while I simply used HxD to validate this, the following Python 2.7 one-liner should also function. print int('0x90909090', 0) (For Python 3, you’ll have to encapsulate everything from int onward in that line in another set of parentheses. RTFM.) Which will return 2425393296, the value Source’s spaghetti code tried to allocate. (It seems, internally, Python’s int handles integers much the same way as ctypes.c_uint32 - for simplicity’s sake, we used int, but you can easily import ctypes and replicate the finding. Might want to do it with 2.7, as 3 handles some things oddly with characters, bytes, etc.) So let’s delve a bit deeper, shall we? We would be using macOS for the next part, love it or hate it, as everyone who writes cross-platform code for the platform (and Darwin in general) seems to forget that stripping binaries is a thing - we don’t have symbols for NT, so macOS should be a viable substitute - but hey, we have the damn source code, so we can do this on Windows. Minimization One important thing to do before we go fully into exploitation is minimize the bug. The bug is a derivative of one found with a wrapper around zzuf, that was re-found with CERT’s BFF tool. If we look at the differences between our original map (cs_assault) and ours, we can see the differences are numerous. Minimization was done manually in this case, using BSPInfo and extracting and comparing the lumps. As expected, the key error was in lump 40 - LUMP_PAKFILE. This lump is essentially a large .zip file. We can use 010 Editor’s ZIP file template to examine it. Symbols and Source (Code) The behavior between the Steam release and the leaked source will differ significantly. No bug will function in a completely identical way across platforms. Assuming your goal is to weaponize this, or even get the maximum payout from Valve on H1, your main target should be Win32 - though other platforms are a viable substitute. Linux has some great tooling available and Valve regularly forgets strip is a thing on macOS (so do many other developers). We can look at the stack trace provided by WinDBG to ascertain what’s going on. Starting from frame 8, we’ll walk through what’s happening. The first line of each snippet will denote where WinDBG decides the problem is. if ( pf->Prepare( packfile->filelen, packfile->fileofs ) ) { int nIndex; if ( addType == PATH_ADD_TO_TAIL ) { nIndex = m_SearchPaths.AddToTail(); } else { nIndex = m_SearchPaths.AddToHead(); } CSearchPath *sp = &m_SearchPaths[ nIndex ]; sp->SetPackFile( pf ); sp->m_storeId = g_iNextSearchPathID++; sp->SetPath( g_PathIDTable.AddString( newPath ) ); sp->m_pPathIDInfo = FindOrAddPathIDInfo( g_PathIDTable.AddString( pPathID ), -1 ); if ( IsDvdDevPathString( newPath ) ) { sp->m_bIsDvdDevPath = true; } pf->SetPath( sp->GetPath() ); pf->m_lPackFileTime = GetFileTime( newPath ); Trace_FClose( pf->m_hPackFileHandleFS ); pf->m_hPackFileHandleFS = NULL; //pf->m_PackFileID = m_FileTracker2.NotePackFileOpened( pPath, pPathID, packfile->filelen ); m_ZipFiles.AddToTail( pf ); } else { delete pf; } } } It’s worth noting that you’re reading this correctly - LUMP_PAKFILE is simply an embedded ZIP file. There’s nothing too much of consequence here - just pointing out m_ZipFiles does indeed refer to the familiar archival format. Frame 7 is where we start to see what’s going on. zipDirBuff.EnsureCapacity( rec.centralDirectorySize ); zipDirBuff.ActivateByteSwapping( IsX360() || IsPS3() ); ReadFromPack( -1, zipDirBuff.Base(), -1, rec.centralDirectorySize, rec.startOfCentralDirOffset ); zipDirBuff.SeekPut( CUtlBuffer::SEEK_HEAD, rec.centralDirectorySize ); If one is to open LUMP_PAKFILE in 010 Editor and parse the file as a ZIP file, you’ll see the following. elDirectorySize is our rec.centralDirectorySize, in this case. Skipping forward a frame, we can see the following. Commented out lines highlight lines of interest. CUtlBuffer::CUtlBuffer( int growSize, int initSize, int nFlags ) : m_Error(0) { MEM_ALLOC_CREDIT(); m_Memory.Init( growSize, initSize ); m_Get = 0; m_Put = 0; m_nTab = 0; m_nOffset = 0; m_Flags = nFlags; if ( (initSize != 0) && !IsReadOnly() ) { m_nMaxPut = -1; AddNullTermination( m_Put ); } else { m_nMaxPut = 0; } ... followed by the next frame, template< class T, class I > void CUtlMemory<T,I>::Init( int nGrowSize /*= 0*/, int nInitSize /*= 0*/ ) { Purge(); m_nGrowSize = nGrowSize; m_nAllocationCount = nInitSize; ValidateGrowSize(); Assert( nGrowSize >= 0 ); if (m_nAllocationCount) { UTLMEMORY_TRACK_ALLOC(); MEM_ALLOC_CREDIT_CLASS(); m_pMemory = (T*)malloc( m_nAllocationCount * sizeof(T) ); } } and finally, inline void *MemAlloc_Alloc( size_t nSize ) { return g_pMemAlloc->IndirectAlloc( nSize ); } where nSize is the value we control, or $esi. Keep in mind, this is all before the actual segfault and $eip corruption. Skipping ahead to that – ***** OUT OF MEMORY! attempted allocation size: 2425393296 **** (311c.4ab0): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000032 ebx=03128f00 ecx=012fd0c0 edx=00000001 esi=012fd0c0 edi=00000000 eip=00000032 esp=012fce7c ebp=012fce88 iopl=0 nv up ei ng nz ac po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010292 00000032 ?? ??? We’re brought to the same familiar fault. Of note is that $eax and $eip are the same value, and consistent throughout runs. If we look at the stack trace WinDBG provides, we see much of the same. Picking apart the locals from CZipPackFile::Prepare, we can see the values on $eip and $eax repeated a few times. Namely, the tuple m_PutOverflowFunc. So we’re able to corrupt this variable and as such, control $eax and $eip - but not to any useful extent, unfortunately. These values more or less seem arbitrary based on game version and map data. What we have, essentially - is a malloc with the value of nSize (0x90909090) with full control over the variable nSize. However, it doesn’t check if it returns a valid pointer – so the game just segfaults as we’re attempting to allocate 2 GB of memory (and returning zero.) In the end, we have a novel denial of service that does result in “control” of the instruction pointer - though not to an extent that we can pop a shell, calc, or do anything fun with it. Thanks to mev for phrasing this better than I could. I’d like to thank mev, another one of our members, for assisting with this writeup, alongside paracord and vmcall. Sursa; https://secret.club/2020/05/05/source-spaghetti.html

Introducing FalconZero v1.0 - a stealthy, targeted Windows Loader for delivering second-stage payloads(shellcode) to the host machine undetected Reading Time: 10 minutes Warning Ahead! You could dominate the world if you read this post from top to bottom and follow all the instructions written here. Proceed at your own discretion, operator! TL;DR This tool is for red team operators and offensive security researchers and ergo, being made open source and free(as in free beer). It is available here: https://github.com/slaeryan/FALCONSTRIKE Demo Let’s take a quick look at a demo of the FalconZero Implant Generation Utility and then we shall get down to the technicalities. Introduction Ever since I completed my SLAE, I am completely enchanted by the power of shellcode. This feeling was only augmented when I heard a podcast by the wonderful guys at FireEye’s Mandiant Red Team where they advocated the usage of shellcode in red teaming engagements for its flexibility and its ability to evade AV/EDRs among other things. That’s when I decided to play around with various shellcode injection techniques. Along the way, I thought of a cool technique and made an implant based on it that could deliver Stage-2 payloads to the target machine in a stealthy manner. But why stop there? Why not add some neat features to it and create a framework to aid red teamers to generate these implants as quickly and cleanly as possible. That was the inception of the FALCONSTRIKE project and FalconZero is the first public release version Loader/Dropper of the FALCONSTRIKE project. It implements the BYOL(Bring Your Own Land) approach as opposed to LotL(Living off the Land). But it’s not your standard run-off-the-mill shellcode loader(more on this later). You may think of FalconZero as a loading dock for malware. In other words, FalconZero is comparable to an undetectable gun that will fire a bullet(payload) on the host machine. This is the reason it may not be classified as malware per se but rather a facilitator of sorts that helps the malware get undetected on the host. But there’s plenty of tools that already do that. So what makes FalconZero special? While there are many excellent existing projects, this is not designed to be a replacement for them. This is designed to be unique in its own way and there are quite a few of those features that separate it from the rest. So let’s discuss them one by one. Separation of the final-stage payload from the Loader As the real attackers often do, we need to separate the payload into 2 stages: Stage-1 payload - A stealthy, lightweight Loader - downloads and injects the Beacon shellcode into a benign host process. Stage-2 payload - A full-fledged interactive C2 Agent - Meterpreter/Beacon etc. Some of the ways of storing the Stage-2 payload(shellcode) in the Stage-1 payload(Dropper) are: Storing shellcode in .text section of Dropper Storing shellcode in .data section of Dropper Storing shellcode in .rsrc section of Dropper etc. While these techniques remain quite popular but keeping both the shellcode and Dropper bundled together(even if it is encrypted) is probably not a good idea from an OPSEC & risk management perspective. Why risk combining all the functionality into a single tool? Imagine if the blue-teams get a hold of an undetonated implant, not only will the Dropper get compromised but also the Stage-2 payload which can’t be any good. Instead, hosting the Stage-2 payload on a server is beneficial because you even have a kill-switch in your hands now(say you want to stop the op. simply delete the payload from the server and that’s it). This technique also helps us to evade some AV/EDRs if the Stage-1 implant is designed in such a way since Stage-2 has more chances of getting detected. So it’s best practise from an OPSEC and risk mitigation perspective to separate the Dropper and the shellcode over the network. In other words, the Dropper can connect to a remote server where the shellcode is hosted provided some conditions are met, fetch it from over there, prep it and then proceed to inject it into a host process on-the-fly which is exactly what has been implemented. Remember BYOL? Hopefully, it makes a lot more sense now. Usage of Github for fetching the Stage-2 payload Yep! You read that correctly. Github is used as the payload storage area. The implant connects to the appropriate Github repository and fetches the payload from there. Why such a choice? Simply because Github is largely considered a legitimate website and network traffic observed to Github will not be flagged as malicious by security products and will probably not even be blocked in most organisations/offices as opposed to using some attacker-owned web server hosting a payload which could be noisy as hell. Last time I checked, I could not find any publicly available tools that utilised Github as the shellcode docking station so this would be the first of it’s kind. I sincerely hope Github doesn’t ban me from their platform now As a brownie point, this would save the operator precious time and money too Sensitive string obfuscation All the sensitive strings in this implant are encrypted using the XOR algorithm with a key that is commonly found in binaries. This would make the job of extracting the URL string and other information from the binary using static analysis impossible. Feel free to test it using FLOSS. Extract it, chmod +x and test using: ./floss <binary> Implant targeting This is something that I have spoken of before. Instead of having malicious code that executes on arbritrary systems, FalconZero comes with a targeting feature which prevents its execution on non-targeted assets and ensuring deployment only happens iff host is the intended target. But we as red teams why should we care about it? This is why: To prevent the accidental breaking of the rules of engagement. This will ensure that the malcode doesn’t end being executed on any unintended host which are out of the scope. To hinder the efforts of blue teams trying to reverse engineer the implant on non-targeted assets and thwart analysis on automated malware sandboxes. Okay, but how do we implement this? Using something known as an environmental keying factor which could be any network/host specific identifier that is found out previously by reconnoitering the target. By hard-coding that value in the implant and comparing it at runtime, we can verify whether the executing host is the intended target or not. One problem that arises from this approach is that it would be trivial to extract that identifier from the binary if left in a plaintext format. So why don’t we hash it? And compare the hashes at runtime instead of the original string? FalconZero uses the hostname as the environmental keying factor, hashes it using MD5 algorithm and what’s more? It even encrypts that hash using XOR before hard-coding it to thwart all kinds of static analysis. Should the checks fail, the implant shall not execute on the host. As a result, reverse engineering this implant should be non-trivial. Killdate Think of killdates like a sort of expiry date for implants beyond which the implant will simply not execute. Obviously, this is quite an important feature as you’d want your implants to be rendered useless after the engagement ends. Address Of Entry Point Injection technique Thanks to @spotheplanet, FalconZero utilises a shellcode injection technique that goes under the radar of many AV/EDRs since we do not need to allocate RWX memory pages in the host process which is a very noisy action. Quoting from his blog, This is a shellcode injection technique that works as follows: 1. Start a target process into which the shellcode will be injected, in suspended state. 2. Get AddressOfEntryPoint of the target process 3. Write shellcode to AddressOfEntryPoint retrieved in step 2 4. Resume target process Credit goes to Mantvydas Baranauskas for describing this wonderful technique! In the current form, FalconZero injects the payload to explorer.exe. Of course, this could be modified to suit the purpose of the operator. Usage There are many hard things in life but generating an implant shouldn’t be one. This is the reason the generate_implant.py script has been created to make your life a breeze. The process is as simple as: First generate your shellcode as a hex string Upload it on Github and copy the Github raw URL For testing(MessageBox shellcode): https://raw.githubusercontent.com/slaeryan/DigitalOceanTest/master/messagebox_shellcode_hex_32.txt git clone https://github.com/slaeryan/FALCONSTRIKE.git cd FALCONSTRIKE pip3 install -r requirements.txt python3 generate_implant.py Follow the on-screen instructions and you’ll find the output in bin directory if everything goes well. AV Scan of FalconZero implant Upgrades expected in the next release This is an alpha release version and depending on the response many more upgrades to existing functionalities are coming soon. Some of them are: Integrate various Sandbox detection algorithms. Integrate support for more stealthy shellcode injection techniques. Integrate function obfuscation to make it stealthier. Include a network component to callback to a C2 when a Stage-2 payload is released or to change targets/payloads and configure other options on-the-fly etc. Inject to a remote process from where network activity is not unusual for fetching the shellcode - better OPSEC Include active hours functionality - Loader becomes active during a specified period of day etc. Feel free to communicate any further feature that you want to see in the next release. Suggestions for improving existing features are also warmly welcome Support this project If you find this project useful, consider buying me coffee or a beer(depending on the mood) as a token of appreciation. You can do it right here: OR Donate with Crypto Sursa: https://slaeryan.github.io/posts/falcon-zero-alpha.html

Trebuie sa inveti atat teoretic cat si sa lucrezi practic. Da, am vazut multe pareri bune despre acea carte asa ca ti-o recomand. Ulterior poti trece la altele, trebuie sa le iei pe rand. Gasesti documentatie legat de orice pe Internet, trebuie doar sa fii motivat.

Nu, dar arata extrem de bine, contine multe informatii utile si e foarte bine organizat!

Bine ai venit. Si RST e foarte bun la capitolul SEO. E primul rezultat la cautarea "invitatie filelist". Nu stim de ce, dar parca nu vrem sa mai fie. Daca despre SEO mai stim cate ceva, despre anti-SEO stii cate ceva? Ce am putea face?

Acel MalSec, rusnac sau ce o fi, care vinde de fapt asa ceva (probabil Gigel de mai sus nu il are, ci doar e tepar), zice ca merge pana la Office 2016. Uitati ceva mai recent, open-source: https://github.com/bhdresh/CVE-2017-0199 gasit random si fara sa vreau. Sunt si altele, publice, gratis, open source. Cat despre ceva modern, care sa functioneze pe ultimele versiuni, adica 0day... https://zerodium.com/program.html -> Oficial si legal se pot obtine 100.000 de euro pe el. Cat despre piata neagra, nici nu se pune problema. Cu alte cuvinte, hacker cu 69 in username, nimeni de aici nu e atat de dobitoc sa dea nici macar 10 euro pentru ceea ce tu pretinzi ca ai. Probabil nici nu ai. Acum serios, daca ai nevoie de niste bani, 20-30 de euro, zi-ne direct si iti trimitem, nu suntem chitrosi.

Ce cred eu, sincer, despre aceasta persoana: a cumparat si el acele mizerii de pe cine stie ce porcarie de forum si na, roman, vrea sa faca si el un ban cinstit. Probabil in cateva minute putem gasi de unde le-a luat, dar nu isi pierde nimeni timpul cu asa ceva. Cat despre noi, scriam tool-uri dinastea de "hacking" prin 2008. Uite aici un crypter facut de mine in 2009: Cu alte cuvinte stim ce vorbim. Mai ales ca au trecut peste 10 ani de atunci si noi am invatat multe alte lucruri intre timp. Si inca invatam. Cat despre tine nu stim nimic. Bine, stim, ca ai numele in adresa de mail, degeaba incerci sa te ascunzi prin Telegrame...

M-am uitat putin pe acel filmulet care incainta pustanii de 12 ani cu efecte vizuale. Cand selecteaza un document scrie in paranteze "Payload VBS". Haa Pe bune bre? Vinzi Word cu macro? Exista retardati care cumpara asa ceva pe hackforums?

Nop, e necesar sa ruleze pe masina care timite/primeste trafic. Doar la nivel de retea, daca se verifica certificatele cum trebuie, nu se poate face nimic.

Imi pare rau pentru cei care folosesc Weblogic, nu cred ca exista software cu mai multe vulnerabilitati critice decat chestia asta. Bine, poate IE.

Salut, exista firme la care se preda programarea. Nu le cunosc, DAR sunt destul de sigur ca vei invata foarte bine de acolo. Insa sunt 2 probleme: 1. Costa ceva, probabil nu foarte mult, nu am idee 2. Dureaza al dracu de mult. Adica vreo 6 luni sau chiar mai mult. Stiu ca sa inveti programare, dar in 6 ani invat sa proiectez rachete Cat despre facultate nu o sa te ajute atat de mult cat iti imaginezi. Insa da foarte bine la CV. Sugestia mea e sa inveti singur si sa practici singur. Partea cu practicatul e extrem de importanta. Si iti aduce un portofoliu pe care il ai pentru angajare. Cel mai important e sa alegi ceea ce iti place. Iti place PHP? Mergi cu el mai departe. Cred ca se cauta mai mult Java, dar orice e OK. Dupa ce inveti un limbaj bine poti trece destul de usor pe altul. Daca ai nevoie de alte sugestii, poti sa vii cu niste intrebari mai concrete. Sau sa ne spui ca iti place, ce ai vrea sa faci etc. Si sa intelegi ca noi ne dam cu parerea, nu inseamna ca orice zicem e adevarat.

Bre, ti-am mai zis si in privat, nu o sa cumpere nimeni mizeriile astea de la tine. Nu avem 15 ani ca ratatii aia de pe Hackforums. Incearca acolo. "Silent exploit" - DACA merge, este ceva pentru Office 2007 sau ceva versiuni de 10 ani pe care nu le foloseste nimeni. Si la banii aia... Adica esti penibil si te faci de ras.

Imi da 404 not found la fisier. Da, am vazut poza, link-ul catre acea poza si invitatia de join in echipa aparea la "strings" pe binar. PS: Destul de multi oameni pentru ceva atat de nisat.

Orice anticheat poate fi bypassat din moment ce local, in joc, se pot intampla lucruri care sa afecteze cumva ce se intampla pe server si mai departe la ceilalti useri. Mai exact, daca la tine in PC, in joc, ajung coordonatele celorlati jucatori (e.g. wall) atunci se poate manipula jocul incat sa ii arate, chiar prin pereti. Daca jocul tau nu ar primi aceste informatii de la server, nu ar avea de unde sa stie unde sunt. Aici depinde totul de arhitectura jocului si de ce se poate face local. Evident, nu se poate face totul pe server si desigur, apar probleme cu cheat-urile. Legat de VM, nu e nevoie de asa ceva. E destul de complicat sa rulezi cod printr-un hypervisor intr-un guest OS. In cazul de fata se poate face totul ca la orice alt joc, doar ca bypass-urile trebuie sa se faca la ring 0 in loc de ring 3 si care doar complica lucrurile pentru un anti-cheater. E un "mitigation" nu un "protection" pana la urma. Asta e scopul, sa faca cat mai dificil un cheat, ca de prevenit complet nu are cum. Asta se poate face doar la jocuri simple, minimale, unde logica completa se face pe server nu pe client, ceea ce e greu in practica.

Din punctul meu de vedere, principala preocupare a tuturor ar trebui sa fie posibilitatea de RCE. Care desi nu ofera acces NT Authority/System, e exact ceea ce au nevoie atacatorii: acces la fisiere, browsere si ce mai vor ei. Cred ca stim cu totii cu cineva putea fi exploatat doar conectandu-se la un server de CS:GO si descarcand o harta... Treaba asta cu privilege escalation e necesara in mediul Corporate in care atacatorii vor sa ajunga Domain Admin. Pe un sistem de acasa, nu au nevoie de asa ceva.

Da, ai dreptate in sensul ca mareste suprafata de atac. E un risc in plus cu care sunt de acord. Eu tind sa am "incredere" in el (desi nu ma joc) deoarece platesc foarte bine pentru probleme de securitate. Asta nu se intampla cu alte drivere. Eu ma astept sa fie mai eficient ca VAC, care nu parea sa faca mare lucru, deoarece creste complexitatea atat a unei persoane care vrea sa dezvolte un anti-cheat cat si a unei persoane care vrea sa foloseasca un cheat - nu va putea rula in mod obisnuit un driver nesemnat, va trebui sa intre in debug mode ca sa ruleze cheat-driver-ul care sa faca disable la anti-cheat. Daca e sa privim dintr-un punct de vedere asemanator lucrurile, PatchGuard-ul de pe Windows de asemenea poate fi bypassat dar se bazeaza pe multe trucuri inteligente de memory tampering. La fel ca si la Vanguard, creste vizibil nivelul de skills necesar pentru bypass. Dar nu e imposibil, evident. Daca va avea un sistem de auto-update simplu pentru useri si ar permite doar jucatul pe ultimele versiuni, asteptandu-ma ca mereu sa vina cu lucruri noi la anti-cheat, lucrurile vor sta bine. Poate fi problema celor care au facut bypass si au o versiune mai veche de joc. Cu putina cryptografie cred ca se pot face nieste verificari.

Daca are vreun privilege escalation, il poti gasi si primi pana la 100.000$ de la ei, au program bug bounty. Din punctul meu de vedere e o solutie foarte OK. Sunt tone de drivere care au astfel de probleme, direct de la OEM si lumea nu se plange atat de mult.

Ma uitam peste acel topic in care mentiona cineva ce tehnici folosesc. Una dintre tehnici e aici: https://revers.engineering/syscall-hooking-via-extended-feature-enable-register-efer/ Acest blog are 3 autori. Cel putin unul dintre ei lucreaza la Riot. Nice! Tiberiu, daca poti uploada undeva folderul cu Vanguard, care sa contina acel .sys e perfect. Pe acel forum apare un link de download: https://riot-client.secure.dyn.riotcdn.net/channels/public/rccontent/vanguard/0.3.2.2/setup.exe E posibil sa gasim alte versiuni in functie de acel version number din URL.

Poate sa comunice prin mesaje IOCTL, sau poate sa il detecteze din kernel-mode in lista de procese. Unde poate sa ii monitorizeze complet memoria si sa verifice ca nu cumva sa fie ceva modificat. Ceva ce nu ar trebui sa fie modificat.

Nu am idee cum functioneaza aceste sisteme de Ads, dar din punctul meu de vedere ar trebui sa fie treaba Google sa opreasca astfel de mizerii. Daca dai click pe o reclama, foloseste mereu acelasi link? E stupid daca e asa. Ca un atac sa fie mai real, ar trebui ca atacatorul sa faca o automatizare mai reala in care sa aiba un browser real (e.g. Seleniun, PhantomJS) si nu cred ca isi bate cineva capul cu asa ceva.

Mersi frumos, da, util ce scrie acolo si nu pare sa fie prea smart. Cel putin acel prim bypass e dumb rau Cum se asteapta toata lumea, are callback-uri pentru imaignile noi incarcate in memorie, procese si thread-uri si pare destul de logic sa nu permita nimic injectat in memoria jocului. Acum, sunt curios daca stie de alte metode de DLL injection, nu de cele clasice cu OpenProcess/WriteProcessMemory/CreateRemoteThread. E posibil sa fie unele trucuri care sa treaca de acele verificari (callback-uri). Sper sa imi fac timp sa ma uit putin prin el. Sper ca IOCTL-urile nu sunt dumb sa crape ceva. Sau nu o avea, si e cumva un "background service" care doar monitorizeaza ce se intampla pe acolo?

Il poti uploada undeva sa ni-l dai si noua? Faci o archiva cu folderul in care e instalat programul. Mi se pare util si sper sa isi faca treaba. Din cand in cand mai deschid si eu CS:GO si mai sunt wall-isti. Nu ii suport.

Hmm, nu stiu cum sa facem. Te poti uita prin folder-ul unde e instalat joc-ul sa vezi daca ai vreun fisier cu extensia .sys? Sau te poti uit ain system32 dupa fisiere de genul "anticheat.sys"? Nu am idee unde si cum ar fi implementat. Bine, nici nu m-am interesat prea mult, dar nu am vazut prea multe referitor la subiect. Iar daca gasesti ceva, sa ni-l dai si noua.