In part 1(https://securityshenaningans.medium.com/architecture-of-a-ransomware-1-2-1b9fee757fcb) we explained key concepts necessary to understand how efficient ransomware works. In this part, we’ll illustrate a couple of these concepts with some python code. We’ll also go into basic usage of the pycryptodome python library for encryption. I won’t be publishing the full source code since I don’t want to help script kiddies on their criminal careers. The purpose of this article is only to share knowledge about ransomware malware and it shouldn’t be used for malicious activities.

General considerations

There are multiple open source ransomwares available, and when reading about ransomware development, I came across a great ransomware called GonnaCry, written by Tarcísio Marinho. The code is very clear and I highly recommend you check it out.
His ransomware contains all the code for the “management side”. He actually coded the server on the attacking side which will manage the decryption keys, and communicate with the infected client, as well as a wallpaper changer.
I didn’t want to get into this aspect since I wrote all my code to learn how ransomware works, and every strain of real-life ransomware handles this side of things differently. You might have an automated service that registers payments and sends decryption keys. You might have a Tor email address and interact with the victim directly. You might even have a system that allows the client to submit a couple of sample files to verify that you can decrypt them. Whatever you have, this varies on each campaign so coding this part wasn’t in my scope. …

Link to part 1.

Recap: In part 1 we saw general considerations you should keep in mind in order to start setting up your infrastructure, as well as technical steps to setup your domain with SPF and DKIM records. In this part we’ll get to a score of 10/10 and I’ll show you how to manage big campaigns, as well as 10 tips at the end to improve your reception percentage. We’ll also talk about SMTP relays and when you should use them.

DNS records

After you’re done setting everything up in Part 1, you should have between 6 and 9 DNS records. …

Link to part 2: https://medium.com/bugbountywriteup/recipe-for-a-successful-phishing-campaign-part-2–2–68552806dcba

Introduction

Phishing attacks are great first-entry vectors with technical details which are frequently overlooked by both white and blackhat hackers.

Having participated in multiple phishing campaigns over the years, both in offensive as well as defensive teams, I’ve learned from trial and error a lot of these things to pay attention to. This article will try to summarize them.

Technical subjects

Even if phishing campaigns are often associated with Social Engineering, they have technical components which you need to be aware of in order to be successful. Some of the topics we will cover (superficially) are:

• Difference between common phishing and spear…

Introduction

In part 1 we compromised an account with multiple permissions, but no Administrator access. We found a potential role that would allow us to escalate privileges, following one of the methods in Rhinosecuritylab’s post. Briefly explained, we’ll try to create an instance and attach to it a privileged role at creation time. After that, if we can access the instance, we’ll be able to query the metadata and extract the credentials that will allow us to use this role. If you’re not sure what this means, you can find it better explained in my previous write-up.

The potential privilege escalation we identified before used a role that we called danger-role for obvious reasons. …

Note: Here’s the link to part 2.

Introduction

This is a real case study of how to enumerate and use IAM permissions to your advantage. I strongly suggest you read my previous article on how IAM permissions work. It’s long, but necessary to understand most of the things we did here. Another thing I want to clarify, this exploitation was long and somewhat technical, so I wont go too deep on the easier vulnerabilities we found (one of them is also covered in a previous writeup). We’ll cover manually enumerating IAM policies and roles, as well as automated tools that can do it for you (and why you shouldn’t trust them 100% of the time). …

Introduction

When I started getting into AWS pentesting, one of the hardest things to fully understand was IAM. AWS documentation is usually great, but can be extensive, and IAM has a lot of similar terms. You have users, roles, groups, managed policies, inline policies, instance roles, etc…
This article will try to shine some light on the subject, as well as some ways to enumerate this information with different tools.

Warning: the post will contain only theory, I’ll publish a write up with practical examples about this next week, but you’ll need the knowledge in this one before the “fun” one.

Later Edit: Heres the link to the practical example writeup which I was talking…

This is the story of how only two insecure configurations allowed us to take down an entire cloud hosted company. It was a gray box pentest for a relatively big client, in which we were tasked with assessing the security of about 5 development endpoints, accessible only using a client certificate. After setting up our environment, we started scanning the endpoints, and Nessus quickly returned an exploitable vulnerability:

Hadoop exposes this API to allow management of it’s resources. Authentication should be in place to prevent anonymous command execution. A quick searchploit search returned an available RCE exploit.

On part 1 we briefly explained how we got administrator privileges to almost all BMC devices hosting a native Openstack cloud. In this part we’ll show how we used these to achieve complete compromise.

If you’ve read up on BMC devices, by now you’ll know that they allow you to

• Monitor
• Reboot
• Reinstall
• KVM

the attached devices. This is great and all, but they only simulate physical access to the server, you still need to get inside. Yes, you could DOS them by shutting them down, but we thought that this wasn’t enough, so we kept digging.

One of the most common ways of compromising an equipment having physical address is rebooting it and manipulating the startup in order to come up with a root shell. You can do this in Unix, Mac and Windows as well. …