Two factor authentication available

All information in ShadowTrackr is found on or derived from things found on the public internet. No special internal access, firewall rules or agents on endpoints are needed. Still, the convenient overview of your attack surface and all your weak spots in one place can be quite sensitive as a whole.

Also, you can have ShadowTrackr scan for sensitive keywords on the internet. Think of specific non-public emails addresses for VIPs, or literal texts from documents that you think might end up published on Pastebin and the like. These will be visible in Shadowtrackr after login.

The above prompted some clients to ask for two factor authentication. The good news is that it has been silently added a few weeks ago and is working properly. Time-based One-time Password (TOTP, see RFC6238) are the thing now, and I choose for the ubiquitous and easy to use Google Authenticator app.

To enable it, go to the Account tab in Settings and set Authentication to “2fa with Google Authenticator”. You’ll be presented a QR code that you have to scan in the Google Authenticator app on your smartphone. If you don’t have the app you should install it first from the Google Play or Apple App Store. Note that all other users you have will be forced to enable Google Authenticator too on their next login.

If you ever have to reinstall Google Authenticator one day (new phone? different brand?) you will have a bad day. Unless of course you have saved the initial QR code in a safe place and just rescan it in the app. I recommend printing it on unhackable paper and putting it in your safe.

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.