blue tangle

  After the last two blog entries about winPEAS.bat related detections I figured we'd take a look at the pre-compiled binary version. Oh and we get this last pea related punny blog title, for now. First of all we have winPEAS retrieving local Wi-Fi profile details, potentially a pre-cursor to retrieving network security keys. We can hunt for this behaviour: index=winlogs EventCode=4688 (Process_Command_Line=*powershell.exe* OR Process_Command_Line="*wlan show profiles*") | stats min(_time) AS earliest max(_time) AS latest count(Process_Command_Line) AS Count values(Process_Command_Line) AS Process_Command_Line BY Creator_Process_Name | convert ctime(earliest) ctime(latest) | where Count > 1 | table earliest latest Count Creator_Process_Name Process_Command_Line     This is what it looks like in Splunk:      Other reconnaissance tools and legitimate user behaviour may introduce false positives here, though checking for Wi-Fi profiles on say a Windows server or des

  Last post we looked at winPEAS traces left in logs using Splunk and Windows security event logging and guess what we are doing this time? More of the same, these are potential security alerts or a jumping off point for some threat hunting.    What prompted me looking at PEAS-ng, Watson and dazzleUP is that they are all featured in one of the rounds of Conti ransomware gang leaks.    I'll be trying to cover all three red team tools in some depth, with some SPL. If you are using a different SIEM you can use what I have here to inspire your own detections, just go with your heart. winPEAS performs extensive reconnaissance on Windows endpoints to provide some guidance on potential privilege escalation paths for adversaries, as before we are looking at the batchfile implementation of winPEAS, though it also comes in pre-compiled binaries and there is a Powershell version floating around as well.   Part of this discovery/recon process involves using Windows native tool findstr.exe t

  Been a while since I've updated this, figured I might as well post some of my findings looking at logs generated by Windows privilege escalation discovery frameworks, in this case winPEAS (Windows Privilege Escalation Awesome Script). So far I've only looked at the resulting logs generated by running the .bat file implementation, I'll chuck up another couple of blogs as I work my way through the pre-compiled executable version, then dazzleUP and Watson. winPEAS is really comprehensive, it provides a lot of information about the host it is run on, patching and security updates, potential avenues for exploitation, existing services, file and directory permissions, etc. As a result of this though, it is very noisy in logs. To retrieve service information winPEAS makes use of the windows executable sc.exe with the " qc " command. A full run of winPEAS.bat resulted in around 250 sc qc queries on my test VM, we can hunt for this: Obviously replace the index

  Today we're looking at "vanilla" Microsoft Defender and some SPL to find "severe" or "high" categories of detected threat severity that have subsequently been "ignored" by a user. EventID 1117 gives us our detection, categorization and severity of the threat found and EventID 5007 gives us a log of user changes made, including ignored threats. EventID 5007 logs changes enacted by users to how threats are handled with a field called "New_value", it will look something like this: New value: HKLM\SOFTWARE\Microsoft\Windows Defender\Threats\ThreatIDDefaultAction\2147742972 = 0x6 It is a registry value, the string of numbers at the end is the same ID assigned recorded in EventID 1117, the "0x6" at the end signifies that this is an ignored threat. A little bit of regex retrieves our 5007 newly created "ThreatID" field and we can then compare this to our 1117 ID value to see if they match. We achieve this without reco

For those following along with ATT&CK this entry is about  Server Software Component: Web Shell  which is now a sub-technique of T1505, specifically it is T1505.003. We can also look at T1090, which is the Command & Control technique Proxy . Today we're taking a look at the traces that ReGeorg leaves in web server access logs. ReGeorg is a "thick client" webshell that enables an adversary to create a SOCKS proxy via a .php, .aspx or .jsp script running on the compromised webserver, this can be used to pivot to internal networks. Pictured above is the client side, it establishes the connection to the shell on a compromised server. After this connection is established an adversary can use something like proxychains to SOCKSify tools on their local machine that they want to use to access networks connected to the webserver but inaccessible from the net. Above you can see nmap run via proxychains through ReGeorg, on the left ReGeorg reports on connections, in the r

For those following along with ATT&CK this entry is about Server Software Component: Web Shell which is now a sub-technique of  T1505, specifically it is  T1505.003.   If I can avoid combing through web access logs to find stuff like webshells I'll happily dodge it, having looked at the log artefacts left by a number of popular public domain webshells I've found a couple of easy detections based around Windows Event Log (WinEventLog). We're looking at webshells like "Con7ext", variants of "WSO" and "Alfa Shell": Specifically we are looking at the parts of the webshell that provide basic reconnaissance as to server components and functionality: How is the webshell checking if perl, python or wget are installed? In a rather noisy way that we can definitely hunt for: For IIS and a PHP shell the Splunk SPL to search for this looks something like: index=win10 sourcetype="WinEventLog:Security" EventCode=4688 Account_Name=IUSR Creator_P

For those following along with ATT&CK this entry is about  Application Layer Protocol: DNS , Command And Control technique T1071 and PowerShell , Execution technique T1086. Having written a bit about DNSCat2 previously I wanted to check out PowerShell implementations like  dnscat2-powershell  an d see what I could turn up in logs. I tried running various commands through the shell from the server side and discovered the following: PowerShell calls nslookup.exe to communicate with the server side of DNScat2 and executes commands issued through that shell, we can hunt for this: index=win10 sourcetype="wineventlog:security" EventCode=4688 Creator_Process_Name=C:\\Windows\\*\\WindowsPowerShell\\*\\powershell.exe | stats count(New_Process_Name) AS Count values(New_Process_Name) AS Processes BY Account_Name Creator_Process_Name Our results will look like this: We can look specifically for calls to nslookup by PowerShell and count the events with this SPL: index=win10 sourcetype