I originally posted this entry on our family’s Wordpress blog, back in 2013. I decided to repost here, since it’s still relevant and fits better here anyway… Recently, the NSA declassified 136 issues of their monthly internal publication, “Cryptolog”, and released them in PDF versions for public consumption. (alternate Cryptome archive) As a geek this was/is very exciting for me. Without a great deal of time to read through them, I decided to briefly peruse the edition published the month I was born (Volume V, No 3 – Yes I’m a young whippersnapper) and quickly moved to the article entitled “I had ‘Animal Crackers in my soup,’ but you’ve got a donkey in your WHAT?”. ...

We’ve already seen the usefulness of ncat, including ncat SSL sessions and running chat servers. Now we address the potential issue of unintended users of our listening ncat sessions. Why would you want to limit access to an ncat listener? If you’re competing in a Capture the Flag event and you’ve managed to establish an ncat listener, it would be no good to take a host you worked so hard to gain and gice it away to the other competitors. ...

Sometimes a quick and easy channel for communication can come in handy. ncat has a nice option for just such a chat server. Start it up Start the server using the -l and --chat flags: ubahmapk@laptop:~ > ncat --chat -l -p 8888 Note that you will not see any of the chat traffic in this window, but if you add the -v flag, you will at least see the connections as they are established: ...

ncat is a full rewrite from the nmap team of the traditional netcat (nc) network “Swiss Army Knife”. ncat is full of really slick new features, but the one I will cover here is the ability to do all the wonderful things nc could do, but over an SSL connection. (Yes, yes, yes: I should call it a TLS connection instead, but since the ncat documentation still refers to it as “SSL”, I will do the same here.) ...

Just a reminder to keep calm even when it feels like every system around you is crashing down to the ground. Keep a level head and calmly review the log data available, only ruling an event out when the evidence backs it up. If you don’t have the necessary logs available, use the incident to gain management approval to invest in the necessary logging infrastructure. It probably doesn’t even have to be expensive. Just the cost of some decent hardware and a good networked installation of SecurityOnion. (A Snort Talos subscription would also help, and they aren’t expensive, either…) ...