In this blog post we'll deploy the honeypot we made in the previous post (How to build an SSH honeypot in Python and Docker - Part 2) to Amazon Web Services (AWS) Lightsail VPS.
We'll start off by creating a new Lightsail instance. Then we'll configure the instance so it's ready to run our honeypot. We'll install Docker, and Docker Compose, then finally install and test our SSH honeypot.
In this blog post I'll be extending the SSH honeypot we built in Part 1 (see How to build an SSH honeypot in Python and Docker - Part 1) to download any files the honeypot receives. A great way to collect malware samples to analyse.
The main features we'll be adding to the new honeypot are:
In today's blog post I'll explain how to build a low-interaction SSH honeypot in Python and containerise it in Docker. In part 2, we'll add functionality to collect malware samples -- ideal for malware analysis.
One of the key design goals of this honeypot is efficiency. Why? Well, if the honeypot has low resource requirements (RAM, CPU, etc), it means we can deploy it to a global infrastructure -- such as multiple virtual private servers (VPS) -- without incurring large costs.
Existing honeypot solutions are available. However, some of them can be quite resource intensive. I've curated a list of popular honeypots here: A Curated List of Awesome Honeypots.
In today's blog post we'll explore what cryptojacking is, why cybercriminals are motivated by cryptocurrency mining attacks, and we'll look at real-world attacks.
Why? Well, cryptojacking was big business for cybercriminals in 2017 and 2018. But died down in 2019 after Coinhive shut down. Now, in 2021, Cryptojacking attacks are on the rise again (see report by Kaspersky).
I've noticed this trend of cryptojacking attacks targetting my honeypots (see my last 2 blog posts: Cryptojacking Attacks Continue To Target SSH Servers and Sneaky Malware Reconfigures Hive OS Wallet for Profit). I want to understand more about cryptojacking and why it's on the rise.
So, grab yourself a coffee (or a hot chocolate), find yourself a comfy spot, and I'll put on my best John Hurt storytelling voice...
Coming up in today's blog post: I'll be exploring recent cyber attacks targeting my SSH honeypots. Since 2018/19, we've known that SSH servers around the world have been targeted by cryptocurrency mining operations. So I'm curious to analyse my honeypot's logs to understand A) if threat actors are still motivated by cryptocurrency, and B) what techniques are used by threat actors.
Just over 1 month ago I deployed my new SSH honeypots (built in Python, containerised in Docker, see: Secure Honey v2.0 has been launched!). Since then, my honeypots have received 129,122 unauthorised logins (username:password credentials) from 3,780 unique IP addresses. 132,479 (77,214 unique) shell commands have been executed, and 91,927 (64,156 unique) files have been uploaded to the honeypot -- of which 23,874 (53 unique) were malicious.
So let's crack on and explore the data!
I was sifting through my SSH honeypot logs recently and noticed a suspicious file drop. The file's payload is on trend with other popular cryptomining malware attacks. However, this particular attack goes after miners running Hive OS: a popular management and monitoring tool for mining rigs.
The attack's modus operandi changes Hive OS's wallet configuration to ensure the attacker receives all mined coins. The malware also regularly updates the Hive OS wallet configuration -- so changing the wallet config back won't stop the attack. At the time of writing this blog post, the attack file isn't marked as malicious by VirusTotal.
Blimey, how times flies! It's been a while since I wrote a blog post for Secure Honey. This is just a quick update to explain the new honeypot and why I've re-launched.
Back in 2016, I took my original honeypot offline. The main reason was because the data that was being sent from the honeypot to the website hosting account was triggering IDS (intrusion detection system) warnings. At the time, I couldn't think of a way around the problem so I decided to leave the honeypot offline.
However, fast forward to 2021, and I'm curious to know if SSH attacker methodology has changed. Plus, I found a way around the IDS triggering problem. So, I've launched a brand new version of Secure Honey!
Wow, what an amazing way to end the final year project: SecureHoney.net went viral, the project won an award (left) from the British Computer Society and I've been offered a scholarship to study a cyber security PhD.
It's been nearly three months since the last blog post in which we looked at the Android Simplocker Ransomware.
I decided it would be a good idea to take some time off over the summer so I'm ready and energised for the next adventure which starts later this month.
So what's been happening since the last blog post? Quite a lot as it turns out...
In yesterday's blog post (How To Dissect Android Simplelocker Ransomware) we dissected the new Android Simplelocker ransomware.
In this blog post we'll be creating an antidote for the ransomware to decrypt any files it encrypts.
The process of creating the antidote is actually very simple because the ransomware comes with a built-in decrypt method and cipher password. This means we're able to create our own Java class and copy the decryption code from the ransomware into our antidote class.
So let's jump right in and start creating our antidote for Simplelocker!
In this blog post we'll be looking at a new type of malware for Android phones that encrypts important files and demands the user pay a ransom to regain access to their phone.
This is the first reported case of ransomware being used on smartphones so I'm keen to find out more about this new malicious app.
I want to understand what this ransomware does and how it restricts the phone user from accessing files on their SD card. I'll be providing a step-by-step dissection of the malware to provide a clear explanation of how this app carries out its malicious activities.
So before we start the dissection let's look at exactly what Simplelocker is and where it came from.
Coming up in this blog post: dissecting malicious version of Flappy Bird reveals premium rate SMS message sent without user being aware.
I'm at a point with the project where I'm diverging away from the honeypot for a moment to look at other sources of malware.
I'm keen to see how Android malware is put together and how to reverse engineer it to see what's going on under the hood.
So in this blog post I'll be focusing on how to dissect one of the malicious versions of Flappy Bird.
Coming up in this blog post: trojan horse receives commands from a Chinese C&C server and sends DDoS attacks to a Malaysian online casino website.
I'll be analysing the malware to determine what it does and also update you on the rest of the project as it's been a while since my last blog post.
My last post was back on the 14th December 2013 and since then I've been buried in revision for exams in January, along with post-graduate applications and graduate scheme applications.
This means there's not been a huge amount of progress on the project, but I'm aiming to get straight back into focusing on it now. I'm also eager to share some insights into the "disknyp" malware which came to light back in December.
I recently finished reading Jon Erickson's book Hacking: The art of Exploitation. Since the book relates to my project; building an SSH honeypot in C to research cyber-attack techniques, I thought writing a review of the book and how it relates to this project would be helpful.
Erickson opens with an explanation of what the term hacking actually means, where the term came from and who a hacker is. Erickson also discusses the mainstream media's use of the word "hacker", how it's often portrayed in a negative light, and how the terms original meaning can be somewhat lost in modern references.
This week's blog post will be fairly brief as I've not had a lot of time to work on the project due to other commitments (mostly end of university term and run-up to Christmas).
Last week I set up a pure honeypot running under Ubuntu. I was hoping to discuss details of attacks that took place on the pure honeypot in this week's post - but I've not had a chance to run the honeypot for long this week.
I want to ensure I can be near my computer for pretty much a whole day so I can run the honeypot and monitor its logs. The only free day I had was yesterday and, frustratingly, there were zero attacks on the honeypot yesterday.
In last week's blog post I discussed an ongoing language engineered brute-force attack on the honeypot and I also discussed duplicate attacks on an identical honeypot under a different IP address.
This week the language engineered brute-force attack has fizzled out; with Saturday 30th November 2013 seeing a total of 663 brute-force attempts - there have been no further attacks from the attacking IP. The total number of attempts from the attacking IP was 4,341.
This week has been fairly quiet on the project because the end of term is fast approaching at university so I've been working on other modules. However, there have been some developments on the project.
There has been an interesting "trickle" brute-force attack happening over the past few days. To date, the attacking IP address has made 4,128 brute-force attempts using password variations such as:
These attacks seem to be using some sort of language engineering based brute-force attack to create various misspellings on common password attempts such as, in the above example, the word "password".
Last week I implemented a basic shell CLI (command-line interface) emulator to the honeypot. The emulator isn't interactive since it doesn't respond to any commands. However, it does log all entered commands.
This week the honeypot has seen its first attack on the shell CLI emulator. As expected, once authorised (with the password "123456" and username "root"), the attacker tried to upload a trojan horse to the honeypot using the wget command.
The challenge for the upcoming weeks is to analyse the uploaded code to see what it actually does. More on that later.
The honeypot's been active for 26 days and it's received 15,680 login attempts. The most common password is "123456" which has been used 323 times and the top username is "root" which has been used 11,703 times.
Some interesting media coverage appeared in the news last week: a list of Adobe usernames and passwords was leaked and then analysed by security researchers (Analysis reveals popular Adobe passwords). The top password, used by 1.9 million Adobe users was "123456" which is also the top password being used by attackers on my honeypot.
I've also setup a Facebook and Twitter script which posts the days most commonly attempted usernames and passwords. You can like the project's Facebook page or follow the project on Twitter for daily attack stats.
This week I've implemented a basic version of the SSH honeypot. After putting the honeypot live on Sunday (20th Oct) evening there have been a total of 2,897 login attempts.
The password "123456" has been used 48 times and the username "root" has been used 1992 times.
What's most interesting about these attacks on the honeypot is that I've not advertised, promoted or otherwise told anyone the honeypot's IP address. How is this possible?
Also this week I've added a mini stats box to this website which will show a breakdown of recent attacks.
Last week I ended by saying I needed to adjust my server.c code to use a secure socket in order to create an SSH session
However, having researched how to create a secure socket in C (Stack overflow: Turn a simple Socket into an SSL Socket), and then spending an entire afternoon implementing the code, it didn't work.
Running a server on a secure socket isn't enough to initiate an SSH session. With the server running I tried using an SSH client to connect - nothing happened.
This website will be used to document the progress of my final year project; building an SSH honeypot in C. For more details see the about page.
I'm currently learning the programming language C as I progress with this project, so the code might not be perfect. I've previously programmed in Java and PHP - which inherit a lot of their syntax from C.
My aim is to document all the challenges I'm presented with as the project unfolds and eventually I'd like to log and analyse attacks on the honeypot.
