Jump to content

[Official] CursedScreech


Recommended Posts

  • Replies 100
  • Created
  • Last Reply
13 minutes ago, Sebkinne said:

As of NANO firmware 1.0.6, SSL is build into nginx.

Yeah but I'm still unsure if it can support the load of the module plus I've run into this new multicast issue and haven't found a fix yet.  So it might be a while until I'm comfortable releasing it on the NANO.

Link to comment
Share on other sites

I've figured out the issue, implemented a fix, and am now testing thoroughly on both the TETRA and NANO.

The issue was that the socket used for multicast was binding to a specific (random) interface even though it was supposed to be bound to all interfaces.  When wlan2 was present it would automatically choose that interface (I guess it was just first in the list) which would result in no multicast packets being received by sein from the br-lan interface.  Then, after wlan2 was disabled it would still try to bind to it resulting in sein crashing.  I wasn't able to get packets properly routed from one interface to the other depending on which one was bound by sein so the fix I implemented instead is a simple selection of which interface you want to use.  Select br-lan for targets on the Pineapple network (which will be your choice 99% of the time) and select any other interface that pops up in the list for their respective networks.  The list only populates with devices that have an IP address assigned so by default you won't see wlan0, wlan1, etc. populate in there.

I hope to have everything tested and an update pushed by the end of the weekend.

Link to comment
Share on other sites

  • 1 month later...

Do you mean Kuro?  Kuro is the only one that logs "Cleaning up sockets" to the activity log.  You have to have targets available in order for Kuro to connect to them otherwise the program falls straight through to "Cleaning up sockets".

Link to comment
Share on other sites

hey great module really think its Great!! 

Followed your video and got as far as the very last step. 

Kuro keeps trying to open the connection and fails any ideas what could be wrong 

Im using a Win 10 victim  vm firewall is off 

im assuming that Kuro is working correctly and its actually the victim vm which is refusing the connection 

below is the output of the activity log 




[>] Connecting to
[!] Failed to connect to
[>] Cleaning up sockets


Link to comment
Share on other sites

can't edit so adding another post tried again with win 8 vm and a win 7 vm 

its the same result with all three although i did see on one ocassion i did see that a connection was made but dropped immeadiatly


[>] Connecting to
[+] Connected to via TLSv1.2
[!] Kuro is ready
[!] Closing connection to

so my questions are now: 

do i need to configure the victim machine in any way 

Is it possible i missed something in the NetCli.exe which is supposed to hold open the connection ?

Is it possible the payload is not being generated correctly and this is whats causing it ?


Any help would be appreciated



Link to comment
Share on other sites

2 hours ago, murphk said:

My Apologies good sir 


Totally my fault i had an error in the code i misspelled "requireadministrator" in the manifest file 

so the application was not getting the correct permissions 

almost a days work to find :( 



I know the feeling.  I'm glad you got it figured out.

Link to comment
Share on other sites

Version 1.2 has been submitted to is now available on the Module Manager!  I've added a cool new feature that I've been planning on implementing for a while and finally got around to it.  You can now upload executable files to your targets to further exploit the system.  In the future I may try to add the ability to download files from your target as that may be useful.

Change Log:

September 17, 2016

- Updated C# API to support receiving and storing of files on target machines
- Updated UI
- Added file upload option to import payloads
- Added 'Send File' EZ Cmd to send payloads to target machines
- Made the module less of a resource hog when Sein and Kuro aren't running
- Fixed bug where certificate store would not properly identify a key as encrypted
- Added feature so encrypted keys can not be selected for Kuro in the certificate store 


Link to comment
Share on other sites

  • 1 month later...

I've been attempting to duplicate the excellent tutorial from Sud0Nick (https://www.youtube.com/watch?v=Bvo43JvmeW0) but I'm having trouble at the very end.  There are few things to remember that I would share just for posterity sake before I begin (that have no real reflection on the module or Nano but are important nonetheless):

1) The Nano seems to freeze or crash if the Modules and portals are not stored on the SD Card (even though it seems I have system memory and HD Space available).

2) if using VMs for testing, make sure the network cards are set to "bridging" (not shared or network-only) or the IP is not routable through the Host VM (that took some "thinkin' & figurin'")

3) If using an Enterprise Machine (as VM Host or otherwise) be sure security and additional firewalls are disabled (I'm working on this for a project at work and initially I neglected the impact of "Enterprise Security")

I've tried to keep up with posts here and followed more than 1 tutorial in this forum so apologies if I missed a critical one. PortalAuth, Papers, and EvilPortal seem to work fine.  Clients on Win7, Win8, & Win10 all bring up the EvilPortal capture and I have used the Starbucks example (which is hilarious) from the Tutorial. The NetCli.exe downloads fine and executes on the client and shows up in PortalAuth and Sein and I have validated it creates local firewall rules.

Above are Win8 and Win10 clients, for what's its worth.  I have actually had a connection established on Win10 but then it dropped and I've not been able to duplicate.  Given all that, I suspect it must be in the handshake between the NetCli and Kuros but I've not been able to find my error or logs that might give a clue.  I've noticed others have fat-fingered the App Manifest or other elements but if I have, I can't see it so I've included snapshots in case it helps.

Help is much appreciated.

Link to comment
Share on other sites

First off, this should be posted in my official CursedScreech thread (https://forums.hak5.org/index.php?/topic/37759-official-cursedscreech/&page=1) and not in it's own thread.  I get alerted by email when someone posts in one of my support threads and it allows me to get back to you when I find time.

What problem are you having?  You stated:

21 hours ago, cogtropolis said:

I have actually had a connection established on Win10 but then it dropped and I've not been able to duplicate.


Do you mean you've not been able to duplicate the connection or it being dropped?  If it's the former then you may want to check event viewer for any errors on the machine that's running the client.  If the target is just deciding to close the connection the module won't be able to report a reason why as the connection was closed normally.

Some things to try:
• Check if NetCli.exe is still running on the target.
• Check if NetCli.exe is listening on the port displayed under Socket in the module.
• Restart the target machine
• Ensure Kuro is using the proper keys

I think the Windows logs are going to be your best bet.

Link to comment
Share on other sites

Thanks - apologies for missing the right thread.  I'll know next time.

As for your question, yes, I was trying to say that one time I briefly had a connection from Kuro to the NetCli documented in the Kuro Log but it then dropped.  I felt like that must be indicative of something - like it being blocked or detected after the connection - but I wasn't sure.  Alternatively, I was trying to think what scenario might allow Sein to see the NetCli but then Kuro can't connect.  As an example, it took me a while to figure out that if my VM was not on a bridged network then Sein can see it but the VM Host won't route the request from Kuro; I'm just trying to think through theories of what could be the issue.

I appreciate your suggestions... Let me walk through them and see what you think.

  • NetCli is running. More, if I read the code correctly, I will see an error dialog in the WebForm Security Dialog "Failed to retrieve access key from..." if the initial connection fails.  Understanding the Architecture might help me here...  Sien and NetCli use the Payload keys to create a secure connection and generate a "passcode" for... (I'm actually not sure).  But Kuro has a different set of (Paper) key credentials and I'm not clear how/where they connect with the NetCli app (ie, I didn't build Kuro's keys into NetCli).  It may not be relevant to my problem but would be interesting to understand.
  • I'll check the port - I did not think to verify.
  • Definitely restarted multiple times, in multiple OS Scenarios (Win7 - Win10)
  • Ensure Kuro is using the proper keys. I've regen'd the Keys multiple times thinking this must be the issue.  Here's what I'm doing:
    • Recreate "payload" keys in papers (Double-Check Password)
    • Export "payload" keys and add PFX to SLN files (add as embedded resource)
    • Rebuild NetCli.exe
    • (Delete and) Upload Newest NetCli to download directory on Nano
    • Restart All Nano Servers via Admin Dialog

Again, thanks!


Link to comment
Share on other sites

I went back and checked the port and connection.  I have no idea what to make of this but here is what I see...  Portal Auth (Sein) detects NetCli and the assigned IP X.X.X.194. Gets port 0 as expected.  CursedScreech (Kuro) tries to connect on the Assigned port of :15434 but it fails.  I check NetCli is running and run Netstat and see there are indeed connections via X.X.X.194 but to port 443 on (BingBot)?  I dunno. I'm not getting something important here... Sorry.




Link to comment
Share on other sites

I think you really need to check the Windows logs in Event Viewer.  Try to connect with Kuro to the target and if it fails, immediately check the logs on the target.  They should give you a better idea of why it's failing.  Feel free to post the log here if you need help figuring out what it means.

I don't have time to go into all the details of the module's architecture (I'm sure I've covered it over various videos and forum posts but if not I apologize as I should have).  I will respond to your theory, though, about a networking issue causing Sein to see the target but not allowing Kuro to connect.  This would not likely be an issue because the target is on the same network as the Pineapple and there would not be any firewall rules (by default) that would allow the multicast heartbeat that Sein receives through while disallowing TLS traffic.  It doesn't appear you have any strange configurations in your lab environment so I can't pinpoint a problem without the logs.

The only time I've seen behavior like this was when I enforced TLS 1.2 only in the PineappleModules API and tried connecting on a stock Windows 7 box.  Windows 7 didn't support TLS 1.2 without an update so it would simply fail to connect.  You're obviously using Win8.1 and Win10 so I'm sure that's not the problem here.

Link to comment
Share on other sites

Thanks for hanging in there with me.  I think I figured out my last submission yesterday but I'd like to validate.  The connection to "Bingbot" was from Windows directly to MSFT services from the IP Assigned by the Nano, correct?  My confusion was that as a "Man-in-the-Middle" I expected to see all IP Connections (on the client machine) terminate with the Nano.  I get it now but it just wasn't what I was expecting.

Just so you know what I'm referring to, I think the scenario on my VMs do create the kind of issue where Sein can see the client but Kuro can't connect.  Prior to setting my VM-Host networking to "Bridged", Sien could receive the Multicast message from the NetCli app; but in "Shared" or "Host-Only" mode the VM-Host will not route incoming traffic from Kuro. 

Based on your previous suggestions, I checked the ports and listeners with Netstat and now that I understand that the Nano will still route UDP/TCP connections to external hosts (i.e., BingBot) without intercepting I can see that was normal behavior.  Looking again, I see that there is an open port to on the Client Machine, NetCli is running, and the Nano PortalAuth and CursedScreech have received the matching IP:Port combination.  But the Kuro connection still fails.  I've exported the logs for security and application but looking over them, I can't find anything that is a clue for me. 

I'll add pics and logs in a follow-on post in just a few (apologies).

Link to comment
Share on other sites

trying to make it easier for you to help me...  I completely changed the setup (Nano Host Machine and Client Machine - no VMs) and got the same results.  However, this time I deleted all the logs prior to testing and then exported.  In this session, the "logon" NetCli tests are right around 4:49:33 mark.  I left the other logs (from original Nano Host/Client VMs) as a verification test in case you see something that sticks out. 

Application Events: https://www.dropbox.com/s/oml10soklzlu551/ApplicationEvents.txt?dl=0

Security Events: https://www.dropbox.com/s/1g9hsm435nft2h9/SecurityEvents.txt?dl=0

Link to comment
Share on other sites

You bet:

In the original scenario I had the Nano connected to a Win10 Home and then used a MacBook Pro running Parallels as the VM-Host, connected the Macbook to the Nano open wireless, and then used a VM client running Win10 Education (in bridged networking mode). The Nano host was connected to my local WiFi and the Nano connected to the host machine via USB cables.


In the second scenario I used an Ubuntu Machine as the Nano host. I connected via the Nano's open wireless with the Win10 Home edition. The Nano host was connected to my network via ethernet cable and the Nano connected to the host machine via USB cables.

The results were the same.  Just as a test I ran the NetCli app as Admin in one of the tests in the second scenario.



Link to comment
Share on other sites

I think packets aren't being routed properly in your setup which is a rather strange one for this kind of test.  The target should connect directly to the Pineapple's WiFi or at least be on the same WiFi network the Pineapple is connected to as a client (not relying on a host machine to route the connection).  Obviously the multicast packets were being passed through the host adapter properly because Sein was able to pick up the target.  I think if you map an external wireless card to the VM directly and connect it to the Pineapple's network you'll be able to connect with Kuro.

Link to comment
Share on other sites

  • 1 month later...


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...