How Exposed is Your Cloud Infrastructure?

Photo by Micaela Parente on Unsplash

Cloud computing is one of the hottest trends in today’s IT world. Companies are racing to switch from on-premises data centers to using public clouds such as AWS, Azure and Google Cloud. Even the United States DOD has decided to move it’s infrastructure to the cloud. The contract was won by Azure who bested AWS in the last stage of the bid for a 10 billion dollar contract for 10 years. This move highlights the importance of cloud computing in providing a resilient infrastructure that can handle increasing amounts of data while keeping costs at a minimum.

However, with cloud computing comes new challenges. Hosting your enterprises’ entire digital infrastructure on a public cloud will expose you to more cyber-threats than on-premises approaches. The fact that your traffic will pass through the public internet network will mean that you are exposed to traffic analysis and sniffing attacks. Address spoofing and Man in The Middle attacks are also a possible risk. In essence, whenever an IT system is connected to a public network the security risk increases considerably.

But I am a simple student running some labs and websites to learn and test new concepts and software, what possible risks could I face? after all there is almost nothing to gain by spending resources and time to launch an attack on my “cloud infrastructure”. Or so did I think!

I have a friend who is majoring in cybersecurity and he was doing a project that aims to collect logs from an IT system and analyze them to generate IOCs also know as Indicators of compromise. He was working with OpenIOC and other opensource tools. To generate these IOCs, you need to get your hands on the logs of a compromised system or simulate attacks in a controlled environment and collect the generated logs and analyze them. However, has was running low on time and he faced a problem with his current Kali installation so I decided to use Azure and launch a penetration testing machine based on a Kali Linux image. This made sense since the target system was also running on the cloud(obviously all the needed precautions from installing a firewall to configuring strict ACLs to limit access).

All was running well and we simulated the needed attacks and collected the corresponding logs and I shut down the target and firewall VMs. But I left the Kali VM running just in case my friend needed to take some screen captures for his rapport.

The next morning, I remembered that I had this Kali machine running and I tried to SSH into it to try and test some things. Surprise! I was unable to connect, my first thought was that Azure shut down the machine or that it might have suffered a system crash. After logging into the Azure console I saw that the current metrics of the instance show that the CPU was running on full load. Network and storage were also running pretty high for a supposedly idle machine.

I decided that it was either a bug that was causing the machine to act weird or a cyber attack that was causing my system to slow down. I first took a look at the network setting and I noticed that the current ACL for TCP port 22 was accepting connections for any IP address! What a mistake! I should have never done this, usually, I would associate the ACL to my IP or the IP range of my university if I am working on campus. However, since I was giving access to someone else I just took the easy way and allowed SSH connections to be accepted from any IP address.

I made a snapshot of the current state of the VM and then shut down the instance. I then proceeded to restart the VM but making sure to only allow connections from my static IP address.

The CPU utilization dropped to a normal level and so did the networking and disk usage. Since I was only accepting connections of the SSH service I decided to check the authentification logs to see what was going on in the last hours. These logs are located at /var/log/:

Let’s open it up and take a look inside by typing:

sudo cat auth.log

And an infinite set of strings starts to flow down! This more like the matrix movie and less of a use for me. So let’s narrow down the search a bit by using the powerful grep tool. I would be looking for failed logging attempts using the keyword “failed” this would be a good start:

sudo cat auth.log | grep Failed

Bingo! we have a long list of failed login attempts from a wide range of IP addresses.

Great! now we can say for sure that we were being attacked by what seems to be a brute force attack on SSH2.

I noticed someone was using the user name “dovecot” to try and get access so I was curious to see what weird usernames were these people using to try and get in.

For that, I used the following command to extract just the usernames and write them to a new file named “usernames.txt”.

sudo cat auth.log | grep -oP ‘(?<=invalid user )[^ ]*’ |sort -u > usernames.txt

The first part will display all of the auth.log entries, the second command “grep -oP ‘(?<=invalid user )[^ ]*’ will only select lines where the “invalid user” pattern is found and will return as output the next following string which will be the username that was used by the attacker to gain access, and the last command will sort these usernames alphabetically and will remove all the repetition as the same username could be used by multiple hackers or by the same hacker multiple times.

If we examine the output of the operation we get a total of 1037 unique usernames that were used during this attack. These could be used when auditing a system for the existence of an attack attempt by cross-searching the logs of your system.

It would have been much more interesting if we cloud have collected the passwords that were used during these attempts but unfortunately, the passwords aren’t logged by the system but in the future, such a feature could be added by the administrator.

The next step for me was to extract all of the IP addresses from which these attacks originated. I manually copied a few of them to compare them against known abusers using the AbuseIPDB website:

So I extracted all the IP addresses into a single text file as a first step using this command:

sudo cat auth.log | grep -E -o “([0–9]{1,3}[\.]){3}[0–9]{1,3}” | sort > ip_addr.txt

This will output all the IP addresses that are found in the log file. This is intentional as it allows us to keep track of the frequency of the attacks executed by every single address.

The final list of attackers can be extracted by adding the “-u” parameter to the sort command to get a list of unique addresses.

This file was then uploaded to Ipheatmap which is a website that offers a heatmap visualization of the geolocation and frequency of the IP addresses after all an image is worth a thousand words!

You do learn from your mistakes, and this was a great opportunity to learn just how dangerous and how exposed is your infrastructure in the cloud. I did use strong passwords and long RSA keys to secure my machines but it’s always important to configure the network access correctly to protect yourself against these attacks that caused my VM to suffer a high load to the point where I couldn’t connect to it.

This entire article aims to show you that even a single machine that is not running any public services can be the target of multiple attacks, so you can imagine the risks that an enterprise can face against more motivated and more resourceful actors. Cloud security shouldn’t be taken for granted and should be a priority to anyone thinking of migrating to the public cloud.

The Startup

Get smarter at building your thing. Join The Startup’s +787K followers.

Sign up for Top 10 Stories

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Chalbi Mohamed Amine

Written by

An Ex-Medical student turned computer science & engineering student with a passion for all things complicated and weird !

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +787K followers.

Chalbi Mohamed Amine

Written by

An Ex-Medical student turned computer science & engineering student with a passion for all things complicated and weird !

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +787K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store