Posts in Uncategorized

Hands-on Attacking & Defending Cloud (AWS)

May 10th, 2019 Posted by Uncategorized 0 thoughts on “Hands-on Attacking & Defending Cloud (AWS)”

Hands-on Attacking & Defending Cloud (AWS)


Amazon Web Services (AWS) runs the most popular and used cloud infrastructure and suite of services. IT Security professionals, DevOps, DevSecOps, Cloud/IT admins will all benefit from learning how to test their cloud infrastructure.


This workshop is a hands-on training with guided walkthroughs, and scenario based attacks against live AWS infrastructures. Environment build scripts will be provided to help students quickly deploy the target infrastructures.


Approximately 50-60% of the training sessions will be dedicated to the coverage of tools that can be used for attacking and auditing AWS infrastructures.


Due to the attack focused nature of the training, and time constraints the training WILL NOT spend a lot of time on security architecture, defence in depth, etc.


Although mitigations for each of the attacks will be covered, the instructor will point out to the relevant security documentation provided by AWS for further self-study.


Course Outline


Module 1: AWS Fundamentals

  • EC2 (Elastic Cloud Compute)
  • S3 (Simple Storage Service)
  • EBS (Elastic Block Storage)
  • RDS (Relational Database Service)
  • ELB (Elastic Load Balancers)
  • VPC (Virtual Private Cloud)
  • Lambda


Module 2: OSINT against cloud targets

  • Techniques for Open Source Intelligence
  • Tools for finding public buckets
  • Tools for discovering, stealing keys and endpoints


Module 3: Attacking cloud compute

  • Setting up Attack Tools and VMs using automation
  • Attacking EC2 and ELBs
  • Application Misconfigurations
  • EC2 metadata abuse
  • Stealing credentials
  • Attacks against virtualization
  • Using AWS Inspector for audits and attacks


Module 4: Attacking cloud storage

  • Abusing AWS S3 misconfigurations
  • Discovering and pillaging EBS
  • Cloud forensics for discovery and attacks


Module 5: Attacking cloud databases

  • AWS RDS misconfigurations
  • Data pilferage


Module 6: Attacking serverless endpoints

  • Attacking Serverless endpoints (AWS Lambda)


Module 7: Applying AWS Security & Monitoring Technologies

  • AWS Security Groups
  • AWS VPCs
  • AWS CloudWatch
  • AWS CloudTrail
  • AWS Flowlogs
  • AWS Cloud DNS Route53
  • AWS Config


Module 8: AWS and compliance

  • PCI DSS for AWS
  • FedRamp, RMF, GovCloud


Target audience (Who should attend)

  • Penetration Testers
  • IT Security Professionals
  • IT Auditors
  • DevSecOps Professionals
  • DevOps Professionals
  • Cloud / IT Professionals


Training delivery approach (What to expect)

  • Completely live-online training
  • Completely hands-on (85% attacking live AWS infrastructure)
  • Automation scripts will be provided to bring up your AWS cloud infrastructure
  • Fast paced training
  • Using cloud control panel, CLI, AWS services and chosen security and management tools which will be provided
  • While we will be using free-tier AWS services as much as possible, you can expect some minimal account charges (less than $10USD in AWS charges should be expected).


Hardware & Software Requirements

  • Student must have their own AWS account which has been activated for payments


Training schedule

  • Saturday 1 June 2019 from 9am EST – 4pm EST
  • Lunch break from 11:30am EST to 12:30pm EST


Training cost

  • $50USD if purchased by 17 May 2019
  • $75USD if purchased between 17 May 2019 – 24 May 2019
  • $100USD if purchased between 25 May 2019 – 31 May 2019


October 12th, 2018 Posted by Uncategorized 0 thoughts on “CEHv10pq”


Low level of interaction honeypots

March 14th, 2018 Posted by Blog, Uncategorized 0 thoughts on “Low level of interaction honeypots”

Honeypots could be categorized according to the level of interaction with the system into three main categories. The categories are- low level of interaction, medium level of interaction, and high level of interaction. I will discuss the low level of interaction honeypots in this article.


When using these type of honeypots, it is not possible to receive a significant amount of data from this system. There are other systems where more and more amounts of data could be collected from them. The advantages of this type of honeypots are given neatly in the following points:

  • They have very limited interaction with the system. This implies that no high risk could arise from an attacker from dealing with this honeypot type of system. To illustrate, there is no operating system in place that an attacker can interact with.
  • The main usage of this type of honeypots is that any traffic coming into the network could be easily identified and captured by such honeypots. Also, new viruses and new worms are identifiable by such honeypots as well.
  • Getting this type of honeypot configured and installed into the network is a simple task. Understanding this type of honeypots and dealing with them from the organization’s perspective is equally easy.
  • The most used honeypot in this category of low-level interaction honeypots is what is referred to as Honeyd. This is considered as a vital honeypot when it comes to the low level of interaction honeypots. The latest and most stable version is 1.5c, which was released back in 2007. I will talk about Honeyd more in detail. This will include how to use them in practice and modern approaches to using them in another article to be published soon. So stay tuned! 😊

In a nutshell, through this type of honeypots, there are only one or more services that have to be simple and available for the attacker to interact with. All communication attempts with any particular functions such as a web or SSH server are logged and investigated afterward. These types of honeypots are considered as simple daemons that help a network administrator get to monitor any attempts of attacks on the system in a passive manner. The host operating system, in this case, is for sure free of any vulnerabilities that could be possibly exploited by an attacker. Thus, this makes such kinds of honeypots safe and secure from the organization point of view. On the other hand, this type of honeypots cannot be used for the sake of simulating a complex environment where interaction is a must, such as a Simple Mail Transfer Protocol (SMTP) server.

Security risks of using the low level of interaction honeypots?


When dealing with low interactive honeypots like Honeyd, there are some security risks. These risks mainly lie in the fact that it is straightforward to get to know that a Honeyd is a trap. A Honeyd is easy to detect even when we do not configure our honeypot with our settings. The reason for that is a honeyd drops all the connections until it becomes impossible for it to deal with them anymore. Even when SYN package is not that good, the connections get terminated.

This information could assist any attacker in finding out that the targeted system is not a real one but a honeypot trap system. When an attacker checks the connections of the system, he will be capable of discovering that he fell into a trap, not a real system. Things are obvious in this case. Dropped connections are easily detected by the monitoring tools which an attacker uses, and these dropped connections imply the fakeness of such honeypot systems.

Low interaction honeypots get services emulated by an operating system, yet they are not real services. This fundamental information becomes of valuable use for an attacker who wants to draw his conclusions about the fakeness of a website. Complicated functions cannot get handled using such low interaction honeypots as well. Hence, breaking the system with the use of this technique becomes powerful. What an attacker needs to do is to look for information throughout the network merely. This is because, in the case of low interaction honeypots, the network stack is the one which we deal with.

Another major problem of low level of interaction honeypots is that they depend on the resources of the system that they are deployed on. Removing such resources, as a result, leads to a great notable feature which is latency. This could be checked through a ping test where the response will occur much later than how it was before getting the resources of the system removed. The system will hardly reply with an answer to our ping. This could indicate that the attacker is dealing with a Honeyd or Nepenthes. We can even use these approaches to detect the type of honeypot which we just deployed.

Leaving the deployed low interaction honeypot open for several days in a row is also a great way to come up with some important conclusions. The requests that are received by our honeypot should be significantly taken care of such that any responses by our system should be believable and make sense to the attacker. The responses to the extreme should fool the attacker that they believe that it is an actual running system. Nevertheless, when it comes to low interaction honeypots, SSH server is up and running while there are no generated replies or answers when talking to port 22. This trivially indicates that the system is not a real one because its responses are not appropriate, making the system not secure in the first place.


Try Certified Ethical Hacker for FREE!!!

What are the levels of interactions in honeypots?

March 12th, 2018 Posted by Blog, Uncategorized 0 thoughts on “What are the levels of interactions in honeypots?”

Honeypots could be categorized according to their aims such as prevention, detection, and of course response. In addition to that, we can categorize them according to their level of interaction with the real systems. This level of interaction determines the intensity of the interaction between an attacker and the systems of an organization’s network. To elaborate more on this point, if a honeypot has a high level of interaction, then this implies that the attacker can interact much more critically with the system, opposed to low levels of interaction where the attacker will not interact with the real systems in a critical manner. If we need to collect much more amounts of data, then a high level of interaction is recommended. On the contrary, this aspect comes with its risks which make the high levels of interactions really dangerous parts of the network. This is, of course, an undesirable feature which we need to abolish. In general, we have three categories for the levels of interaction: low interaction, medium interaction, and high interaction.

The most common type of classification is based on the level of interaction which is provided to the malicious user by the honeypot. The more interactive an environment is presented, the closer the honeypot becomes to the actual targets of an attack. This translates to potentially gathering more accurate information. The downside is that the more realistic honeypots present greater challenges to configure and setup.


An organization should decide on which level of interaction works best for its purposes and goals out of the configured honeypots inside its network. I will explain the three levels of interactions in detail throughout the following three points; I will advise when each level of interaction is useful and when it should be avoided.

  1. Low level of interaction:

An example is Honeyd. I talked about this in another article titled “low level of interaction honeypots.”

  1. Medium level of interaction honeypots:

This is a more advanced type of honeypot where more information could be available if used. Despite the fact these type of honeypots still don’t contain an operating system which could simply get exploited, there is a bigger chance that attacks could get through the system using this sort of honeypots. The problem arises from the fact that there exist many more security holes through which an attacker could simply get into the system and exploit it. Obtaining much more information and more attacks from the hackers that are complicated is possible in this case. The following honeypot names could be used to exemplify the medium level of interaction, honeypots that are infamously in use nowadays: Mwcollect, honeytrap, and Nepenthes. I will also talk about some of these honeypots in another article and implement them in practice.

To summarize what was mentioned regarding medium interaction honeypots, they are used to get some collections of software-emulated such that an attacker could become more convinced that it is, in fact, the actual system while he just accessed a honeypot system. In this case, the host operating system is still shielded. Nevertheless, getting a collection of software-emulated through the honeypot as we desire is not, in fact, a simple task at all. The reason for that lies in the fact that the response of such emulated collection of software should be almost identical to the response of the same actual programs. Still, we, of course, do not need to raise any real security issues here for these programs; otherwise, there is a real danger. Finally, the possibility of comprising the system exists here in fact with a higher percentage. This is basically because the vulnerable points that are kept for the attackers are considerable, and he can exploit a hole in the actual system to perform his malicious activity.

  1. High level of interaction honeypots:


This type of honeypots is considered the most advanced type of honeypots in general. First of all, these types of honeypots contain an operating system. What does this imply? We can simply infer that an attacker can possibly undertake anything on such an advanced honeypot system. However, an organization, in this case, is capable of getting more and more data about the attack type, source, and nature indeed.

This type of honeypots allows the user to have no restrictions to perform whatever tasks and actions that are desired by him. From this point comes the real danger of using such honeypots inside an organization. They are also very time-consuming honeypots to configure and implement. Moreover, it is much more difficult to be able to maintain such type of honeypots for a long time.  The most common name in this category of honeypots is Honeywell. This is a very important high level of interaction honeypot. I will also come back to it in another article and see how it could be configured in practice.

So, as I just mentioned, in this type of honeypots, actual instances of programs are used, not merely the emulations of them. An administrator has to choose this type of honeypots if he needs to grant an attacker root access to the machine and analyze how he will react then, and what actions he wished to do. The risk of implementing this type of honeypots is high. It is, in fact, the riskiest type of honeypot, yet it grants an administrator the greatest potential to get data collected about the attack and the attacker as well. Supervision of such honeypots is a must since such types of honeypots could become a zombie or a jumping point to perform more attacks on the systems inside the network.

Try Certified Ethical Hacker for FREE!!!-