Leaderboard

Challengeul cu isadmin nu este chiar scos din burta. In cel putin 2 situatii se putea descoperi acel parametru: 1. content fuzzing - intr-un pentest/bug bounty nu faci content discovery doar pe fisiere si foldere cu dirbuster ca acum 15 ani. Faci content discovery si pe parametri GET, POST, cookies, headers si altele. Nu sunt rare situatiile in care gasesti ceva interesant, un parametru care se reflecta si scoti un XSS, un header care iti permite cache poisoning sau un cookie care iti ofera ceva permisiuni suplimentare. Da, poate nu mai gasesti "isadmin=true" ca acum 10 ani prin minunatele "Insecure Cookie Handling", dar poate ajungi intr-o interfata de development, endpoint-uri interne plus alte surprize. 2. mass assignment - desi nu e _exact_ cazul aici, challenge-ul simuleaza indeaproape vulnerabilitatile de tip mass assignment, unde "nimerirea" unui astfel de parametru te poate duce la privilege escalation (ca in cazul de fata), account takeover (manipulare user ID). Vezi aici mai multe detalii: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html Edit: Exercitiile astea, chiar daca nu sunt la ordinea zilei in rapoartele de pentest, sunt derivate din lucruri intalnite. "Chinuiala" sa le descoperi iti ofera rezilienta, sentimentul de "ce nu am verificat", mindsetul de "try harder", care sunt folositoare in viata de zi cu zi.

Crypto - Biletul criptat https://github.com/RSTCon/ctf-rst-crypto/tree/main/Biletul criptat - Strabunicul lui Cezar https://github.com/RSTCon/ctf-rst-crypto/tree/main/Strabunicul lui Cezar - Asteroidul https://github.com/RSTCon/ctf-rst-crypto/tree/main/Asteroidul - Steagnul corupt https://github.com/RSTCon/ctf-rst-crypto/tree/main/Steagul corupt Diverse - Animalul https://github.com/RSTCon/ctf-rst-diverse/tree/main/Animalul - Poza https://github.com/RSTCon/ctf-rst-diverse/tree/main/Poza Forensics - Traficant https://github.com/RSTCon/ctf-rst-forensics/tree/main/Traficant - RST https://github.com/RSTCon/ctf-rst-forensics/tree/main/RST Networking - Reteaua https://github.com/RSTCon/ctf-rst-networking/tree/main/Reteaua - Server https://github.com/RSTCon/ctf-rst-networking/tree/main/Server Reversing - Crackpass https://github.com/RSTCon/ctf-rst-reversing-crackpass - NoFlag https://github.com/RSTCon/ctf-rst-reversing-noflag Stegano - Hecsagon https://github.com/RSTCon/ctf-rst-stegano/tree/main/Hecsagon - Sigla https://github.com/RSTCon/ctf-rst-stegano/tree/main/Sigla - Valuri https://github.com/RSTCon/ctf-rst-stegano/tree/main/Valuri - Stegano II https://github.com/RSTCon/ctf-rst-stegano/tree/main/Stegano II Web - API https://github.com/RSTCon/ctf-rst-web-api - Elevi https://github.com/RSTCon/ctf-rst-web-elevi - Admin https://github.com/RSTCon/ctf-rst-web-admin - SMS-uri https://github.com/RSTCon/ctf-rst-web-sms-uri - Onboarding https://github.com/RSTCon/ctf-rst-web-onboarding Challenge-urile au fost create de membrii forumului @YKelyan, @Nytro si @Dragos.

Facebook-owned WhatsApp recently addressed two security vulnerabilities in its messaging app for Android that could have been exploited to execute malicious code remotely on the device and even exfiltrate sensitive information. The flaws take aim at devices running Android versions up to and including Android 9 by carrying out what's known as a "man-in-the-disk" attack that makes it possible for adversaries to compromise an app by manipulating certain data being exchanged between it and the external storage. "The two aforementioned WhatsApp vulnerabilities would have made it possible for attackers to remotely collect TLS cryptographic material for TLS 1.3 and TLS 1.2 sessions," researchers from Census Labs said today. "With the TLS secrets at hand, we will demonstrate how a man-in-the-middle (MitM) attack can lead to the compromise of WhatsApp communications, to remote code execution on the victim device and to the extraction of Noise protocol keys used for end-to-end encryption in user communications." In particular, the flaw (CVE-2021-24027) leverages Chrome's support for content providers in Android (via the "content://" URL scheme) and a same-origin policy bypass in the browser (CVE-2020-6516), thereby allowing an attacker to send a specially-crafted HTML file to a victim over WhatsApp, which, when opened on the browser, executes the code contained in the HTML file. Worse, the malicious code can be used to access any resource stored in the unprotected external storage area, including those from WhatsApp, which was found to save TLS session key details in a sub-directory, among others, and as a result, expose sensitive information to any app that's provisioned to read or write from the external storage. "All an attacker has to do is lure the victim into opening an HTML document attachment," Census Labs researcher Chariton Karamitas said. "WhatsApp will render this attachment in Chrome, over a content provider, and the attacker's Javascript code will be able to steal the stored TLS session keys." Armed with the keys, a bad actor can then stage a man-in-the-middle attack to achieve remote code execution or even exfiltrate the Noise protocol key pairs — which are used to operate an encrypted channel between the client and server for transport layer security (and not the messages themselves, which are encrypted using the Signal protocol) — gathered by the app for diagnostic purposes by deliberately triggering an out of memory error remotely on the victim's device. When this error is thrown, WhatsApp's debugging mechanism kicks in and uploads the encoded key pairs along with the application logs, system information, and other memory content to a dedicated crash logs server ("crashlogs.whatsapp.net"). But it's worth noting that this only occurs on devices that run a new version of the app, and "less than 10 days have elapsed since the current version's release date." Although the debugging process is designed to be invoked to catch fatal errors in the app, the idea behind the MitM exploit is to programmatically cause an exception that will force the data collection and set off the upload, only to intercept the connection and "disclose all the sensitive information that was intended to be sent to WhatsApp's internal infrastructure." To defend against such attacks, Google introduced a feature called "scoped storage" in Android 10, which gives each app an isolated storage area on the device in a way that no other app installed on the same device can directly access data saved by other apps. The cybersecurity firm said it has no knowledge on whether the attacks have been exploited in the wild, although in the past, flaws in WhatsApp have been abused to inject spyware onto target devices and snoop on journalists and human rights activists. WhatsApp users are recommended to update to version 2.21.4.18 to mitigate the risk associated with the flaws. When reached for a response, the company reiterated that the "keys" that are used to protect people's messages are not being uploaded to the servers and that the crash log information does not allow it to access the message contents. "There are many more subsystems in WhatsApp which might be of great interest to an attacker," Karamitas said. "The communication with upstream servers and the E2E encryption implementation are two notable ones. Additionally, despite the fact that this work focused on WhatsApp, other popular Android messaging applications (e.g. Viber, Facebook Messenger), or even mobile games might be unwillingly exposing a similar attack surface to remote adversaries." Sursă: https://thehackernews.com/2021/04/new-whatsapp-bug-couldve-let-attackers.html

Prominent Apple supplier Quanta on Wednesday said it suffered a ransomware attack from the REvil ransomware group, which is now demanding the iPhone maker pay a ransom of $50 million to prevent leaking sensitive files on the dark web. In a post shared on its deep web "Happy Blog" portal, the threat actor said it came into possession of schematics of the U.S. company's products such as MacBooks and Apple Watch by infiltrating the network of the Taiwanese manufacturer, claiming it's making a ransom demand to Apple after Quanta expressed no interest in paying to recover the stolen blueprints. "Our team is negotiating the sale of large quantities of confidential drawings and gigabytes of personal data with several major brands," the REvil operators said. "We recommend that Apple buy back the available data by May 1." Since first detected in June 2019, REvil (aka Sodinokibi or Sodin) has emerged as one of the most prolific ransomware-as-a-service (RaaS) groups, with the gang being the first to adopt the so-called technique of "double extortion" that has since been emulated by other groups to maximize their chances of making a profit. The strategy seeks to pressure victim companies into paying up mainly by publishing a handful of files stolen from their extortion targets prior to encrypting them and threatening to release more data unless and until the ransom demand is met. The main actor associated with advertising and promoting REvil on Russian-language cybercrime forums is called Unknown, aka UNKN. The ransomware is also operated as an affiliate service, wherein threat actors are recruited to spread the malware by breaching corporate network victims, while the core developers take charge of maintaining the malware and payment infrastructure. Affiliates typically receive 60% to 70% of the ransom payment. Ransomware operators have netted more than $350m in 2020, a 311% jump from the previous year, according to blockchain analysis company Chainalysis. The latest development also marks a new twist in the double extortion game, in which a ransomware cartel has gone after a victim's customer following an unsuccessful attempt to negotiate ransom with the primary victim. We have reached out to Quanta for comment, and we will update the story if we hear back. However, in a statement shared with Bloomberg, the company said it worked with external IT experts in response to "cyber attacks on a small number of Quanta servers," adding "there's no material impact on the company's business operation." Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post. Sursă: https://thehackernews.com/2021/04/hackers-threaten-to-leak-stolen-apple.html

Named Pipe Pass-the-Hash April 19, 2021 This post will cover a little project I did last week and is about Named pipe Impersonation in combination with Pass-the-Hash (PTH) to execute binaries as another user. Both techniques used are not new and often used, the only thing I did here is combination and modification of existing tools. The current public tools all use PTH for network authentication only. The difference to this “new” technique is therefore, that you can also spawn a new shell or C2-Stager as the PTH user for local actions and network authentication. Introduction - why another PTH tool? I faced certain Offensive Security project situations in the past, where I already had the NTLM-Hash of a low privileged user account and needed a shell for that user on the current compromised system - but that was not possible with the current public tools. Imagine two more facts for a situation like that - the NTLM Hash could not be cracked and there is no process of the victim user to execute shellcode in it or to migrate into that process. This may sound like an absurd edge-case for some of you. I still experienced that multiple times. Not only in one engagement I spend a lot of time searching for the right tool/technique in that specific situation. Last week, @n00py1 tweeted exactly the question I had in mind in those projects: So I thought: Other people in the field obviously have the same limitations in existing tools. My personal goals for a tool/technique were: Fully featured shell or C2-connection as the victim user-account It must to able to also Impersonate low privileged accounts - depending on engagement goals it might be needed to access a system with a specific user such as the CEO, HR-accounts, SAP-administrators or others The tool has to be used on a fully compromised system without another for example linux box under control in the network, so that it can be used as C2-module for example The Tweet above therefore inspired me, to again search for existing tools/techniques. There are plenty of tools for network authentication via Pass-the-Hash. Most of them have the primary goal of code execution on remote systems - which needs a privileged users Hash. Some of those are: SMB (CrackMapExec, smbexec.py, Invoke-SMBExec.ps1) WMI (Invoke-WMIExec.ps1, wmiexec.py) DCOM (dcomexec.py) WinRM (evil-winrm) If we want to have access to an administrative account and a shell for that account, we can easily use the WMI, DCOM and WinRM PTH-tools, as commands are executed in the users context. The python tools could be executed over a SOCKS tunnel via C2 for example, the Powershell scripts work out-of-the-box locally. SMB PTH tools execute commands as nt-authority\system, so user impersonation is not possible here. One of my personal goals was not fulfilled - the impersonation of low privileged accounts. So I had to search for more possibilities. The best results for local PTH actions are in my opinion indeed Mimikatz’s sekurlsa::pth and Rubeus’s PTT features. I tested them again to start software via PTH or inject a Kerberos ticket into existing processes and realized, that they only provide network authentication for the PTH-user. Network authentication Only? Ok, I have to admit, in the most cases network authentication is enough. You can read/write the Active Directory via LDAP, access network shares via SMB, execute code on remote systems with a privileged user (SMB, WMI, DCOM, WinRM) and so on. But still - the edge case to start an application as the other user via Pass-the-Hash is not possible. I thought to myself, that it might be possible to modify one of those tools to archieve the specific goal of an interactive shell. To do that, I had to first dig into the code to understand it. Modifying Rubeus was no opion for me, because PTT uses a Kerberos ticket, which is as far as I know only used for network authentication. That won’t help us authenticating on the localhost for a shell. So I took a look at the Mimikatz feature in the next step. Mimikatz’s sekurlsa::pth feature This part will only give some background information to the sekurlsa::pth Mimikatz module. If you already know about it feel free to skip. Searching for sekurlsa::pth internals resulted in two good blog posts for me, which I recommend reading for a deeper look into the topic, as I will only explain the high-level process: https://www.praetorian.com/blog/inside-mimikatz-part1/ https://www.praetorian.com/blog/inside-mimikatz-part2/ A really short high-level overview of the process is as follows: MSV1_0 and Kerberos are Windows two Authentication providers, which handle authentication using provided credential material The LSASS process on a Windows Operating System contains a structure with MSV1_0 and Kerberos credential material Mimikatz sekurlsa::pth creates a new process with a dummy password for the PTH user. The process is first created in the SUSPENDED state Afterwards it creates a new MSV and Kerberos structure with the user provided NTLM hash and overwrites the original structure for the given user The newly created process is RESUMED, so that the specified binary like for example cmd.exe is executed This part is copy & paste from the part II blog: Overwriting these structures does not change the security information or user information for the local user account. The credentials stored in LSASS are associated with the logon session used for network authentication and not for identifying the local user account associated with a process. Those of you, who read my other blog posts know, that C/C++ is not my favorite language. Therefore I decided to work with @b4rtik’s SharpKatz code, which is a C# port of the in my opinion most important and most used Mimikatz functions. Normally, I don’t like blog posts explaining a topic with code. Don’t ask me why, but this time I did it myself here. The PTH module first creates a structure for the credential material called data from the class SEKURLSA_PTH_DATA: The NtlmHash of this new structure is filled with our given Hash: if (!string.IsNullOrEmpty(rc4)) ntlmHashbytes = Utility.StringToByteArray(rc4); if (!string.IsNullOrEmpty(ntlmHash)) ntlmHashbytes = Utility.StringToByteArray(ntlmHash); if (ntlmHashbytes.Length != Msv1.LM_NTLM_HASH_LENGTH) throw new System.ArgumentException(); data.NtlmHash = ntlmHashbytes; A new process in the SUSPENDED state is opened. Note, that our PTH username is chosen with an empty password: PROCESS_INFORMATION pi = new PROCESS_INFORMATION(); if(CreateProcessWithLogonW(user, "", domain, @"C:\Windows\System32\", binary, arguments, CreationFlags.CREATE_SUSPENDED, ref pi)) In the next step, the process is opened and the LogonID of the new process is copied into our credential material object, which is related to our PTH username. Afterwards, the function Pth_luid is called. This function first searches for and afterwards overwrites the MSV1.0 and Kerberos credential material with our newly created structure: If that resulted in success, the process is resumed via NtResumeProcess. Named Pipe Impersonation Thinking about alternative ways for PTH user Impersonation I asked @EthicalChaos about my approach/ideas and the use-case. Brainstorming with you is always a pleasure, thanks for that! Some ideas for the use-case were: NTLM challenge response locally via InitializeSecurityContext / AcceptSecurityContext Impersonation via process token Impersonation via named pipe identity Impersonation via RPC Identity I excluded the first one, because I simply had no idea about that and never worked with it before. Impersonation via process token or RPC Identity required an existing process for the target user to steal the token from. A process for the target user doesn’t exist in my szenario, so only Named Pipe Impersonation was left. And I thought cool, I already worked with that to build a script to get a SYSTEM shell - NamedPipeSystem.ps1. So I’m not completely lost in the topic and know what it is about. For everyone out there, who doesn’t know about Named Pipe Impersonation I can recommend the following blog post by @decoder_it: https://decoder.cloud/2019/03/06/windows-named-pipes-impersonation/ Again, I will give a short high-level overview for it. Named Pipes are ment to be used for asynchronous or synchronous communication between processes. It’s possible to send or receive data via Named Pipes locally or over the network. Named Pipes on a Windows Operating System are accessible over the IPC$ network share. One Windows API call, namely ImpersonateNamedPipeClient() allows the server to impersonate any client connecting to it. The only thing you need for that is the SeImpersonatePrivilege privilege. Local administrators and many service-accounts have this privilege by default. So opening up a Named Pipe with this privileges enables us to Impersonate any user connecting to that Pipe via ImpersonateNamedPipeClient() and open a new process with the token of that user-account. My first thought about Named Pipe Impersonation in combination with PTH was, that I could spawn a new cmd.exe process via Mimikatz or SharpKatz Pass-the-Hash and connect to the Named Pipe over IPC$ in the new process. If the network credentials are used for that, we would be able to fulfill all our goals for a new tool. So I opened up a new Powershell process via PTH and SharpKatz with the following command: .\SharpKatz.exe --Command pth --User testing --Domain iPad --NtlmHash 7C53CFA5EA7D0F9B3B968AA0FB51A3F5 --Binary "\WindowsPowerShell\v1.0\powershell.exe" What happens in the background? That is explained above. To test, that we are really using the credentials for the user testing we can connect to a linux boxes SMBServer: smbserver.py -ip 192.168.126.131 -smb2support testshare /mnt/share After opening up the server we can connect to it via simply echoing into the share: And voila, the authentication as testing came in, so this definitely works: @decoder_it’s wrote a Powershell script - pipeserverimpersonate.ps1 - which let’s us easily open up a Named Pipe Server for user Impersonation and to open cmd.exe afterwards with the token of the connecting user. The next step for me was to test, if connections from this new process connect to the Named Pipe Server with the network credentials. It turned out, that this unfortunately is not the case: I tried to access the Pipe via 127.0.0.1, Hostname, External IP, but the same result in every case: I also tried using a NamedPipeClient via Powershell - maybe this would result in network authentication with the user testing - still no success: At this point I had no clue on how I could trigger network authentication to localhost for the Named Pipe access. So I gave up on Mimikatz and SharpKatz - but still learned something by doing that. And maybe some of you also learned something in this section. This was a dead end for me. But what happens exactly when network authentication is triggered? To check that, I monitored the network interface for SMB access from one Windows System to another one: The TCP/IP Three-way-handshake is done (SYN,SYN/ACK,ACK) Two Negotiate Protocol Requests and Responses Session Setup Request, NTLMSSP_NEGOTIATE + NTLMSSP_AUTH Tree Connect Request to IPC$ Create Request File testpipe During my tool research I took a look at @kevin_robertson’s Invoke-SMBExec.ps1 code and found, that this script contains exactly the same packets and sends them manually. So by modifying this script, it could be possible to skip the Windows default behaviour and just send exactly those packets manually. This would simulate a remote system authenticating to our Pipe with the user testing. I went through the SMB documentation for some hours, but that did not help me much to be honest. But than I had the idea to just monitor the default Invoke-SMBExec.ps1 traffic for the testing user. Here is the result: Comparing those two packet captures results in only one very small difference. Invoke-SMBExec.ps1 tries to access the Named Pipe svcctl. We can easily change that in line 1562 and 2248 for the CreateRequest and CreateAndXRequest stage, by using different hex values for another Pipe name. So if we only change those bytes to the following, a CreateRequest request is send to our attacker controlled Named Pipe: $SMB_named_pipe_bytes = 0x74,0x00,0x65,0x00,0x73,0x00,0x74,0x00,0x70,0x00,0x69,0x00,0x70,0x00,0x65,0x00 # \testpipe The result is an local authentication to the Named Pipe as the user testing: To get rid of the error message and the resulting timeout we have to do some further changes to the Invoke-SMBExec code. I therefore modified the script, so that after the CreateRequest a CloseRequest, TreeDisconnect and Logoff packet is send instead of the default code execution stuff for Service creation and so on. I also removed all Inveigh Session stuff, parameters and so on. But there still was one more thing to fix. I got the following error from cmd.exe when impersonating the user testing via network authentication: This error didn’t pop up, when a cmd.exe was opened with the password, accessing the Pipe afterwards. Googling this error results in many many crap answers ranging from corrupted filesystem, try to repair it to install DirectX 11 or Disable Antivirus. I decided to ask the community via Twitter and got a fast response from @tiraniddo, that the error code is likely due to not being able to open the Window Station. A solution for that is changing the WinSta/Desktop DACL to grant everyone access. I would have never figured this out, so thank you for that! @decoder_it also send a link to RoguePotato, especially the code for setting correct WinSta/Desktop permissions is included there. Modifying RoguePotato & building one script as PoC Taking a look at the Desktop.cpp code from RoguePotato I decided pretty fast, that porting this code to Powershell or C# is no good idea for me as I would need way too much time for that. So my idea was, to modify the RoguePotato code to get a PipeServer which sets correct permissions for WinSta/Desktop. Doing this was straight forward as I mostly had to remove code. So I removed the RogueOxidResolver components, the IStorageTrigger and so on. The result is the PipeServerImpersonate code. Testing the server in combination with our modified Invoke-SMBExec script resulted in no shell at first. The CreateProcessAsUserW function did not open up the desired binary even though the token had SE_ASSIGN_PRIMARY_NAME privileges. I ended up using CreateProcessWithTokenW with CREATE_NEW_CONSOLE as dwCreationFlags, which worked perfectly fine. Opening up the Named Pipe via modified RoguePotato and connecting to it via Invoke-NamedPipePTH.ps1 resulted in successfull Pass-the-Hash to a Named Pipe for Impersonation and binary execution with the new token: Still - this is not a perfect solution. Dropping PipeServerImpersonate to disk and executing the script in another session is one option, but a single script doing everything is much better in my opinion. Therefore I build a single script, which leverages Invoke-ReflectivePEInjection.ps1 to execute PipeServerImpersonate from memory. This is done in the background via Start-Job, so that Invoke-NamedPipePTH can connect to the Pipe afterwards. It’s possible to specify a custom Pipe Name and binary for execution: This enables us to use it from a C2-Server as module. You could also specify a C2-Stager as binary, so that you will get a new agent with the credentials of the PTH user. Further ideas & improvements I see my code still as PoC, because it is far away from being OPSEC safe and I didn’t test that much possible use-cases. Using Syscalls for PipeServerImpersonate and PE-Injection instead of Windows API functions would further improve this for example. For those of you looking for a C# solution: Sharp-SMBExec is a C# port of Invoke-SMBExec which can be modified the same way I did here to get a C# version for the PTH to the Named Pipe part. However, the PipeServerImpersonate part should also be ported, which in my opinion is more work todo. The whole project gave me the idea, that it would be really cool to also add an option to impacket’s ntlmrelayx.py to relay connections to a Named Pipe. Imagine you compromised a single host in a customer environment and this single host didn’t gave any valuable credentials but has SMB Signing disabled. Modifying PipeServerImpersonate, so that the Named Pipe is not closed but re-opened again after executing a binary would make it possible to get a C2-Stager for every single incoming NetNTLMV2 connection. This means raining shells. The connections only need to be relayed to \\targetserver\IPC$\pipename to get a shell or C2-connection. Conclusion This is the first time, that I created somehow a new technique. At least I didn’t see anyone else using a combination of PTH and Named Pipe Impersonation with the same goal. For me, this was a pretty exciting experience and I learned a lot again. I hope, that you also learned something from that or at least can use the resulting tool in some engagements whenever you are stuck in a situation described above. The script/tool is released with this post, and feedback is as always very welcome! https://github.com/S3cur3Th1sSh1t/NamedPipePTH 20.04.2021: Update I’m pretty sure, that I before publication of the tool tested the content of Start-Job Scriptblocks for AMSI scans/blocks. And it was not scanned neither blocked. After the publication, Microsoft obviously decided to activate this feature, because the standalone script didn’t work anymore with Defender enabled even after patching AMSI.dll in memory for the process: Therefore, I decided to switch from the native Start-Job function to the Start-ThreadJob function, which again bypasses Defender because its executed in the same process: If this description is true, Start-Job should have scanned and blocked scripts before because it’s another process. But here we stay in the same process, therefore a bypass works: Links & Resources Crackmapexec - https://github.com/byt3bl33d3r/CrackMapExec Impacket - https://github.com/SecureAuthCorp/impacket/ Invoke-TheHash - https://github.com/Kevin-Robertson/Invoke-TheHash/ evil-winrm - https://github.com/Hackplayers/evil-winrm mimikatz - https://github.com/gentilkiwi/mimikatz Rubeus - https://github.com/GhostPack/Rubeus Inside Mimikatz part I - https://www.praetorian.com/blog/inside-mimikatz-part1/ Inside Mimikatz part II - https://www.praetorian.com/blog/inside-mimikatz-part2/ SharpKatz - https://github.com/b4rtik/SharpKatz/ NamedPipeSystem - https://github.com/S3cur3Th1sSh1t/Get-System-Techniques/blob/master/NamedPipe/NamedPipeSystem.ps1 Windows Named Pipes Impersonation - https://decoder.cloud/2019/03/06/windows-named-pipes-impersonation/ PipeServerImpersonate.ps1 - https://github.com/decoder-it/pipeserverimpersonate/blob/master/pipeserverimpersonate.ps1 SMB Documentation - https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962 RoguePotato - https://github.com/antonioCoco/RoguePotato Invoke-ReflectivePEInjection - https://github.com/PowerShellMafia/PowerSploit/blob/master/CodeExecution/Invoke-ReflectivePEInjection.ps1 Sharp-SMBExec - https://github.com/checkymander/Sharp-SMBExec NamedPipePTH - https://github.com/S3cur3Th1sSh1t/NamedPipePTH PSThreadJob - https://github.com/PaulHigin/PSThreadJob Sursa: https://s3cur3th1ssh1t.github.io/Named-Pipe-PTH/

Nu stiu daca se poate, doar ei (teoretic) se pot conecta sa faca modificari administrative.