Create custom push notifications

Though I love ShadowTrackr push notifications on my phone for keyword hits on pastebin or security problems on important servers, I was not happy with late night push messages for no so relevant trouble on not so relevant machines. The obvious solution was more granular control over push messages and email alerts and I just released it to production.

You can set general event traps for bad ports opening, certificates that expire, website security headers that are removed. If you are a small business with a few host, the best option is likely to set them on “all” your hosts and websites. This also is the default settings for new accounts.

When you have hundreds or thousands of host, the messages can get annoying and you likely better of sending the security events to your SIEM (you do have on don’t you?). In this case, event traps are very handy for follow up or incident response.

Say one day you learn that one of your servers is under attack, or even already pwnd. I’d want to know anything that changes on that specific host the moment it happens. I’ve had some occasions where I really could have used this but had no way to quickly set it up. Now I just set an event trap on that host or website that fires for any change that is detected and have a push message send to my iPhone. Immediate alerts, finally. I can now switch to instant panic mode wherever I am.

Hopefully your boxes are never pwnd and you just use it for follow up. Every now and then you’ll find things that shouldn’t be: admin opens Elastic search on internet facing box, SSL certificate got a lower grade, etc. You notify the person responsible and are then doomed to regularly checking if they fixed it. With the new event traps, you can just set an event on port 9200 closing on that specific ip and receive a push message or alert when it happens. No more boring periodic checks.

If you have any specific events that you like to have in ShadowTrackr, please let me know and I’ll see what I can do.

Housekeeping and a lesson in SPF

Besides fixing quite a few bugs, I’ve been working on the timeline in recent weeks. The thing is, for larger organisations there are a lot of events and it can get messy real quick. ShadowTrackr is supposed to provide you with situational awareness and messy just doesn’t cut it.

Two things have changed that should improve the timeline. The first is that similar events are now grouped. If for instance 10 ports open on a machine simultaneously they are grouped in to one event 10 ports opened on X. You can click show details to find out which ports exactly. Other messy changes like changing public key pins or certificate fingerprints are also hidden behind show details .

The second change is that the events that should worry you now jump out because of a red warning sign. Think of bad ports like SMB ports opening on an internet facing machine, certificates that just got a protocol or encryption downgrade and website security headers that are removed. Note that the bad events will never be grouped and can’t accidentally disappear behind a show details.

I also got a lesson in SPF this week and it was a bit of humbling moment. We’re currently testing a SIEM use case that has something to do with mailservers, and the new API endpoint supporting it is supposed to list all emails servers. At some point I got the question why the endpoint showed a mailserver with the ip 14. Yes, just 14.

I looked into it and found this SPF record for the Dutch ncsc.nl:


I thought this was a mistake and joked that someone at the NCSC must be really fond of quotes. Well, the NCSC reacted swiftly and told me this was intended and quite normal for long SPF records. I checked RFC1305 and they are right.

The maximum string length for SPF is 255 and if you want a longer SPF record you can add several of these strings (separated by spaces) in a DNS TXT record. The SPF parser in ShadowTrackr is now fixed and concatenates these strings before parsing the record. Thank you NCSC.

Brand new API and SIEM feed

The number of clients is steadily growing, but the first one will always remain special. They’ve been supportive from the start, provided valuable feedback and even put up with me when their timeline was full of crap again because the bots triggered the flood detection on the corporate firewall. So when they ask for a feed for their SIEM, they get a feed for their SIEM.

The SIEM in question, ArcSight, normally ingests messages in Common Event Format (CEF) and this format is supported on quite a few security products. Their SIEM guy said that JSON would also be fine. JSON is used a lot for APIs and goes well with the Elastic Stack. That last one is popular with security people for a reason, and if you’re not familiar with it yet it should be your next stop after this. I decided to support both formats.

There are several options (see API documentation) available to tweak your feed, but I figure the most common one will be to periodically pull all new events. This is as simple as hitting the endpoint url. The feed endpoint can remember what you already have pulled before and will only send you the difference since then.

I’m sure the API will expand over time, but if you have a cool idea and need something right now, just contact me.