Thinkst Blog

(Guest Post by  @marasawr ) Author’s note : international law is hard, and these remarks are extremely simplified. Thinkst recently published a thought piece on the theme of ' A Geneva Convention, for software. '[1] Haroon correctly anticipated that I'd be a wee bit crunchy about this particular 'X for Y' anti-pattern, but probably did not anticipate a serialised account of diplomatic derpitude around information and communications technologies (ICT) in international law over the past twenty years. Apparently there is a need for this, however, because this anti-pattern is getting out of hand. Microsoft President and Chief Legal Officer Brad Smith published early in 2017 on ' The need for a digital Geneva Convention ,' and again in late October on ' What the founding of the Red Cross can teach us about cyber warfare. '[2] In both cases, equivalences are drawn between perturbations in the integrity or availability of digital services, and the circumsta...

The anti-pattern “ X for Y ” is a sketchy way to start any tech think piece, and with “ cyber ” stories guaranteeing eyeballs, you’re already tired of the many horrible articles predicting a “ Digital Pearl Harbour ” or “ cyber Armageddon ”. In this case however, we believe this article’s title fits and are going to run with it. (Ed’s note: So did all the other authors!) The past 10 years have made it clear that the internet, (both the software that both powers it and the software that runs on top of it) are fair game for attackers. The past 5 years have made it clear that nobody has internalized this message as well as the global Intelligence Community. The Snowden leaks pulled back the curtains on massive Five Eyes efforts in this regard, from muted deals with Internet behemoths, to amusing grab-all efforts like grabbing still images from Yahoo webcam chats ( 1 ) . In response to these revelations, a bunch of us predicted a creeping Balkanization of the Internet, as more people becam...

This is the fourth post in a series highlighting bits from our recent BlackHat USA 2017 talk. An index of all the posts in the series is  here . Introduction In this blog post, we will introduce you to the newest member of our Canarytoken’s family, the Amazon Web Services API key token. This new Canarytoken allows you to sprinkle AWS API keys around and then notifies you when they are used . (If you stick around to the end, we will also share some of the details behind how we built it). Background Amazon Web Services offers a massive range of services that are easily integratable with each other. This encourages companies to build entire products and product pipelines using the AWS suite. In order to automate and manipulate AWS services using their API, we are given access keys which can be restricted by AWS policies. Access keys are defined on a per user basis which means there are a few moving parts in order to lock down an AWS account securely. Take it for a spin - using an AWS ...

This is the third post in a series highlighting bits from our recent BlackHat USA 2017 talk. An index of all the posts in the series is here . Introduction In our BlackHat talk, " Fighting the Previous War ", we showed how attacks against cloud services and cloud-native companies are still in their nascent stages of evolution. The number of known attacks against AWS is small, which is at odds with the huge number (and complexity) of services available. It's not a deep insight to argue that the number of classes of cloud specific attacks will rise. However, the "previous war" doesn't just refer to cloud stuff. While our talk primarily dealt with cloud services, we also spent some time on another recent development, Google's BeyondCorp. In the end, the results weren't exciting enough to include fully in the talk and so we cut slides from the presentation, but the original slides are in the PDF linked above. In this post we'll provide our view on wh...

This post continues the series of highlights from our recent BlackHat USA 2017 talk. An index of all the posts in the series is here . Introduction Before today's public clouds, best practice was to store logs separately from the host that generated them. If the host was compromised, the logs stored off it would have a better chance of being preserved. At a cloud provider like AWS, a storage service within an account holds your activity logs. A sufficiently thorough compromise of an account could very well lead to disrupted logging and heightened pain for IR teams. It's analogous to logs stored on a single compromised machine: once access restrictions to the logs are overcome, logs can be tampered with and removed. In AWS, however, removing and editing logs looks different to wiping logs with  rm -rf . In AWS jargon, the logs originate from a service called CloudTrail. A Trail is created which delivers the current batch of activity logs in a file to a pre-defined S3 bucket at v...