Kiwicon 10 Day 2 Morning

A friendly reminder New Zealand is part of the Five Eyes team. And a montage of the ridiculousness of, well, everything about the Five Eyes nations. Trump. Colin Craig. Farage. Gumboot throwing.

Opening Matters


Not metl. Fobski. “The CEO of FailCrowd One, a startup.” Fobski will be presenting the first corporate keynote of Kiwicon’s history.

“Pause for booing.”

A Monster of an Attribution Problem


Aaaaaaaand Failymonster, the CTO!

“Hackers, Hackers, Hackers!”

(OK, so I can’t type quick enough over the laughing to really do justice to this.)

“ITYSaaS - I Told You So as a Service.” And with that, the skit sums up the state of the Cyber industry in an acronym.

“Become an SSL Certificate issuer, because that’s a market for failure we can really get into.”

“YOU ALL GET FREE COOKIES!” And we did. No, really. There were free cookies outside.

Hacking AWS end to end

Daniel Grzelak

“We’re going to roll AWS accounts manager-style, with spreadsheets.”

“This talk came about because most talks about hacking Amazon focused on finding keys, then mining bitcoin with them. Which is pretty boring. Let’s think about what people might actually do.”

  • The core AWS cloud is solid. It’s hard to break. The things people run on it, on the other hand…


  • Target selection: use Amazon’s Partner Network page to find targets.
    • Partner documentation may reveal information like account keys.
  • The signin URL for Amazon will effectively tell you if an account ID exists.
    • Also, the ID may be passed in via a DNS CNAMEs. So you’ll see them in a DNS DB.
    • The marketplace leaks the Owner ID, which is the account ID.
    • The iam create-role call will also effectively verify if roles exist against a given ID.
  • Enumerating resources can be per-account or global.
    • Queues are regional.
    • S3 resources are global.
    • All of them are accesible via https URLs without using the resource-specific API.
    • Some will have misconfigured permissions.
    • A common problem is that S3 buckets default to “Authenticated users” - but that’s “all authed users in Amazon”, not “all users in my account.” Whoops.


  • Pre-owned accounts: there’s a secondary market in accounts with credit left on them. You can backdoor them.
  • You can easily use S3 buckets for phishing. You can serve AWS-branded login pages, with AWS certs.
  • Every instance has the security credentials available to it over a special network interface.
  • Trust relationships are easy to write incorrectly, such that you can inadvertantly trust every account in the other side of the trust relationship. Compromise the integration, and any low-level account can pivot to attack the trusting customers.
  • When roles are specified regionally, they still work in other regions, they just aren’t logged. So an Australian-scoped role accessed from India will work, but it won’t be monitored.
  • The “confused deputy attack”; if you have credentials, you can attach as a third party service and get copies of all the data the real third party receives. Lots of third party services have well-known credentials.

Log Disruption

  • You can enumerate the cloudtrails that are logging. Just disabling them is a bad idea - prople notice that.
  • Instead, attach an encrypt-only key to the cloudtrail account. Now the logs exist, but they can never be read!
  • You can use the lamda service to write logs on delivery.
  • aws directconnect describe-locations will tell you a lot about the connectivity back to the mothership.
  • aws support describe-cases --include-resolved-cases will tell you everything that’s ever been raised by an account.


  • How do we escalate our crappy account?
  • People put sensitive data in cloudformation scripts. So dumping them all will often give you the secrets you need.
  • Integrations often end up containing information they shouldn’t. Look for the CreateRole in CloudTrails configurations.
  • aws ec2 describe-instance-attribute contains all the startup scripts. Which will almost certainly contain privileged information.
  • You can use the #cloud-bookhook parameter to cause startup activities to execute every time a resource is started.


  • aws sts get-session-token --duration-seconds 129600 will give you a temporary token. Which cannot be discovered by any means.
  • Rather than create new roles, create trust policies to another compromised role. It’s harder to notice.
  • Lamba is the best persistence tool there is. It’s lightweight, the first million are free and don’t show up in billing. It’s easy to write.
    • e.g. a simple script that creates two accounts every time one is deleted.


  • S3 is a great way of pulling data. Just copy from one place to another!
  • Create new RDS replicas to copy data into one controlled by you, with no visibility.
  • AWS Snowball: exfiltraion as a service. Give them an address, a bucket, and AWS will deliver!

It’s in Dan’s github repo.

Luring developers with candy and other evil tricks

Eleanor Saitta @dymaxion

  • It’s been a bad year for human rights. Eleanor has spent a lot of time working for human rights organisations to help them against crooked cops, political threats, and so on.

    • But everything is fucked in the security industry.
    • We’re focused on the computers, but the adversary is focused on the people.
    • “We made a terrible mistake when we thought our job was about computers, not people”
  • One of the problems in security is that no-one likes us.

  • “Maybe free candy would help?” - but it’s more complicated than that.

  • Security is just another property of an organisation. “We’re not special. Learn to act like janitors.”

  • How do we change that? The answer is culture.

    • Every team has a dedicated hacker who shows up to meetings.
    • And acts like their best friend. Because you want developers to come talk to you.
    • Enable projects. That means you have to be prepared to fix things, not just point them out.
    • Keep the big stick well-hidden. Don’t bring it out often, and when you do, be caseful how you explain why you’re taking it out.
    • Be careful assessing humans.
    • Say no when you have to, but build trust first.
    • Also free candy.
  • What would security engineering look like?

    • Outcome focused.
    • That you measure.
    • And they need to be human-focused, not machine outcomes.
  • “How many people think Twitter understand what there products do?”

    • Do you know what your humans are trying to do? Your designers probably do. If they don’t know this, you have a much bigger problem.
    • Designers don’t understand security. You don’t understand design.
    • So how do you design to encourage people to do the right thing? (Which has nothing to do with technical things, by the way)
    • Why do users click on links? How do you help them “accomplish a thing” safely.
    • Observe, Orient, Decide, Act.
    • Operational Planning is applying this idea to the everything you need to do.
  • One thing we tend to think is “build tools! Give them more tools!”

    • But people aren’t trying to do security.
    • If you follow all our advice, you’re no longer a reporter, you’re a security engineer.
    • People need to be able to accomplish a task in the face of adversaries. This doesn’t mean they need perfect security.
    • When people have to think about technical security, they aren’t thinking about the thing they’re actually trying to do.
    • Attention is a zero-sum game.
  • Adversaries are Human Too.

    • If you can shape their reward structure, you can affect their behaviour and protect yourself.
    • In many cases your adversary has a business model, and you can disript it with your design.

“The only thing that matters is what you enable the humans you care about to do in the world and what they learn along the way.”

Your team and product do not matter.

  • Most security modelling is terrible and is basically sitting around a table with beer.
    • We need to think about product security design, outcome modelling.
    • The intent needs to be consistent throughout the process.
    • Everything needs to stay focused on what the user is trying to accomplish.

Consider an example: a group of activists stopped carrying their phones, figuring that the local regime would stop being able to track them. Instead, the regime started using goons to follow the activists. Oh, and occasionally beating them up because “goons gonna goon”. So instead it turned out keeping the phone on you and occasionally giving it to a friend is much more important. Which means you want a guest mode for the phone so the friend doesn’t see everything on it.

Three Takeways

  1. Enable collaboration internally between security and everyone else. If you’ve been a bunch of jackbooted thugs, expect this to take 5 years.
  2. Build holistic security and get design in the security loop.
  3. Kill your ego.

Prince of Persia

Simon Conant

Works for Unit 42 in Palo Alto Networks. They try to analyse who are behind technical threats, rather than the threats themselves.

  • Started with a targeted attack on Israeli industry.
  • Started as a set of phishing attacks.
  • The same source was also attacking US government agencies.
  • Launched from legitimate, but compromised, gmail accounts.
  • The payload is a keylogger and cookie theif than exfiltrates the data.
  • Mainly uses 1st party exfil servers, which then leads to other samples using the same servers.
    • The samples were all encrypted with the same keys, which suggests the same org is responsible.
    • The samples suggest the attacks had been running for more than a decade.
  • Very targetted attacks, regionalised by language.
  • Good versioning practises made the history easy to track the spread and features.
    • A new version had appeared in 2013, used only against high-value targets.
    • Features like camera and microphone capture, remote shells.
  • WHOIS data for the C2 network was initially very strong, but over times got sloppy and started leaking names and addresses.
    • Addresses in Iran, names with Iranian email addresses and so on.
    • Could be false flag, though.
  • “Tomer from Israel” managed to seize control of the domains.
    • This allowed full access to the telemetry.
    • 326 victims across 35 countries.
    • Mostly Western nations industry and government, Middle Eastern countries.
    • But also a huge number of Iranian individuals.
  • The attacker started updating bots where they could and directing them to a C2 server by IP address.
    • Which was in Germany.
    • German police seized the server.

So remind me again - what were the security agencies doing for those ten years? Not much, apparently. Raiding German movie pirates?