It's a information security use case in which I takeover an AWS cloud account of a company. This presentation includes my views information security and the lesson I learned from this use case.

1. AWS Cloud Account Hacked!
Lesson to learn

2. Agenda
1. Introduction
2. Security Breach Levels - My View
3. Security Breach Mindset - My Recipe
4. AWS Cloud Account Hack
5. Lesson to Learn
6. Conclusion

3. Introduction
Now a days security is as import as development.
Cybercrime is on its peak. I recently takeover an AWS
cloud account of a company (I Will not reveal company due to ethical
boundaries. Reporting is in process). Motivation and purpose to
share this security breach use case is to highlight the
lesson which I learn and the serious need of cyber security
P.S: I didn’t hurt any infrastructure of company.

4. Security Breach Levels - My View
I categorize security on three levels:
1. Customer facing applications (e.g: websites, mobile apps)
2. Networks (e.g: internet communication protocols like TCP, UDP)
3. Infrastructures (e.g: machines on which application has deployed)
Security breach can be occur on any level and
consequences can vary level to level

5. Security Breach Mindset - My Recipe (1)
I always compare security research with crime case
investigation.
Broader steps of Crime investigation can be:
● Think like a criminal
● Find leads from crime spot
● Follow leads
● If you work smartly and you are bit lucky then you’ll get
culprit

6. Security Breach Mindset - My Recipe (2)
I follow same crime investigation steps and do following
things:
● Think like a nerd software engineer
● Find leads from available views like websites, mobile
apps, networks, secret keys (If I get from any source)
● Follow them and exploit every possible dimensions
● If I work smartly and I was lucky than I got vulnerability

7. AWS Cloud Account Hack : Lead
A bad day for an eCommerce website that I visit them and
inspired from their UI design. There was no intention as
well as time to breach them but I want to check framework
so that I can find that theme or template and that was the
unlucky time for them that I spotted a “GET” query string
and I just place a single inverted comma, BANG: SQL
Injection

8. AWS Cloud Account Hack : Exploit
So I take out some time and start my criminal case steps
as I already get lead and I was think like a nerd software
engineer. I use some SQL injection vectors and start
digging into it but this takes time and vulnerability was
confirmed by some SQL vectors so I decided to run my
favorite tool: SQLMAP
It gets all DB tables and I was like “Wow! It was too easy”.

9. AWS Cloud Account Hack : Curiosity
But still I’m curious to know that either It’s a framework or
custom web and HTML source code is indicating towards a
framework because resources paths are like decorated
framework (xyzwebsite.com/catalog/sites/images/xxx). So I search
the part of URL after “.com” (/catalog/sites) and google leads
me to three search results who has this path pattern and
out them one has “Open Directory”. I started digging into it
and hence find that It’s a private framework by a software
company.

10. AWS Cloud Account Hack : A final lead
After an hour of digging into folders, I found a folder
containing settings XML file, as a cache, in that “Open
Directory” vulnerable website and since it’s not my target I
get back to that culprit website and try to open that
settings and I got a real break through. Every secret key
and settings was in that file including AWS S3 Key. I
connect that AWS key with a software name S3Browser
and I got their S3 bucket access which has CRUD rights.

11. AWS Cloud Account Hack : Takeover
Since I’m unaware of AWS key management so I think S3
takeover as my success point which is actually not bad. A
nightmare for that company arrives after 1 month when I
was aware with AWS key management (thanks to Disrupt A.K.A
GADITEK, my career kickstart employer). I test that AWS S3 key of that
company with an open source tool (Nimbostratus) which I
read on this link. This tool test the AWS access key rights
on AWS resources and I got final takeover because that
AWS access key has ROOT rights. BANG!

12. Lesson to Learn (1)
I learn following lessons:
Security Dimension:
● Never trust on framework blindly.
● Don’t add credentials on any file or INI instead use
environment variables
● Don’t give extra access rights to any resource.
● Spend little bucks on security inspection at-least once
specially in case of third party framework.

13. Lesson to Learn (2)
Personal Dimension:
● Never give up until your own satisfaction
● Never take win as an END instead consider win as a
NEW BEGINNING
● Always keep learning from circumstances (I didn’t learn AWS
access key management when I got that S3 key. It was employer’s work
which made me learn that part which strikes me with embarrassment
that why I didn’t learn at that time)

14. Conclusion
Never take cyber world for-granted and take every
possible security majors on every level. You may face an
unlucky day if somebody breach your product because:
Security is not a product, but a process
-Bruce Schneier

15. Thank You![Every opinion is solely my mindset and can be differ from others - Rational correction is highly
appreciable]
(Sorry for any english grammar or spelling mistakes)