Magic IP — ‘169.254.169.254'

While creating an instance on AWS with an Ubuntu image, AWS gives the VM a way to get information about itself using this IP.
169.254.169.254 is a special IP address used by cloud providers like Amazon Web Services for the Instance Metadata Service (IMDS).

What is Metadata?

Metadata means:
“Data about the instance itself.

An EC2 instance may need to know:

• Its instance ID
• Public/private IP
• Security groups
• IAM role credentials
• Region
• AMI ID
• Hostname

Instead of hardcoding all this, AWS stores it in a metadata service.

Why only 169.254.169.254?

This IP belongs to the link-local address range (169.254.x.x).

Link-local addresses:

• Work only inside the local network/device
• Are not routable on the internet
• Cannot be accessed from outside the instance

So AWS uses it safely for internal communication between:

• EC2 instance
• AWS hypervisor/metadata service

When your instance sends an request through terminal

curl http://169.254.169.254/latest/meta-data/

It responses by metadata.
Suppose you want to search for id of instance you can use

curl http://169.254.169.254/latest/meta-data/instance-id

Output may look like this

i-0abcd1234efgh5678

Elastic IP

Whenever you create an instance on AWS it provides you with mainly two IP’s. One is private IP which permanent for your instance and other is public IP which is temporary.

In what way is it temporary?
So whenever you restart your instance your public IP changes.

Why Public IP changes?

When an EC2 instance starts:

1. AWS picks a free public IP from its pool
2. Assigns it temporarily to your instance
3. When you stop the instance:

• That IP is released back to AWS

When you start again:

• AWS may assign a completely different IP

So the public IP is dynamic by default.

Why?
Because public IPv4 addresses are limited.

AWS manages millions of instances, so instead of permanently reserving one IP for every stopped VM, it:

• reuses IPs efficiently
• gives them only while instance is running

This saves IPv4 space.

What is Elastic IP?

Elastic IP (EIP) is a static public IPv4 address reserved for your AWS account.

Instead of AWS randomly assigning IPs,
you reserve one permanent IP.

Suppose you are hosting an public website and for some reason you have to restart your instance. Now the problem is that the next time anyone tries to connect to your old public they won’t be able to. Because after restarting your public IP changed. To cure this problem we use Elastic IP.

How Elastic IP Works

AWS separates:

• EC2 instance
• Public IP

Elastic IP acts like an attachable public address.
You can:

• attach
• detach
• move

the IP between instances.

You have to pay extra for it while using AWS.

How AWS Handles Load Distribution at Massive Scale?

Imagine there is a festive season or new year shopping and everybody around the world just starts clicking, searching, ordering and making payments on that website. But the website still works smoothly without crashing, buffering. How?
The answer is the way the website is distributing its load.

In cloud computing, load distribution means spreading incoming traffic across multiple servers so that no single server gets overloaded. In the world of cloud computing, this is one of the most important concepts because modern applications handle users from all around the globe simultaneously.

Advantages of load distribution

• High availability
• Better performance
• Improved scalability
• Fault tolerance
• Efficient resource utilization

This is why companies like Netflix, Amazon, and Spotify rely heavily on distributed cloud infrastructure.

Services

Now talking about which services AWS provides for load distribution-

• Elastic Load Balancer (ELB)
• Auto Scaling
• Amazon CloudFront
• Multiple Availability Zones
• Route 53

Elastic Load Balancer (ELB)

The core service responsible for load distribution in AWS is the Elastic Load Balancing.

An Elastic Load Balancer automatically distributes incoming traffic across multiple EC2 instances.

Instead of users directly connecting to a single server, they connect to the load balancer first. The load balancer then decides which server should handle the request.

This prevents one instance from becoming overloaded.

Types of Load Balancers in AWS

AWS provides different types of load balancers for different workloads.

1. Application Load Balancer (ALB)

The Application Load Balancer works at Layer 7 of the OSI model.

It is mainly used for:

• HTTP and HTTPS traffic
• Web applications
• Microservices
• Container-based applications

It can route traffic based on:

• URL paths
• Hostnames
• Headers
• Query strings

For example:

• /images traffic can go to one server
• /payments traffic can go to another server

This makes ALB highly intelligent.

2. Network Load Balancer (NLB)

The Network Load Balancer operates at Layer 4.

It is designed for:

• Extremely high performance
• Low latency applications
• Millions of requests per second

It is commonly used in:

• Gaming applications
• Real-time systems
• Financial platforms

3. Gateway Load Balancer

The Gateway Load Balancer is used for managing virtual appliances like:

• Firewalls
• Security systems
• Network monitoring tools

It helps distribute and inspect network traffic securely.

Auto Scaling and Load Distribution

Load balancing becomes even more powerful when combined with Amazon EC2 Auto Scaling.

Auto Scaling automatically increases or decreases the number of EC2 instances based on traffic.
This provides two major advantages:

1. Better performance
2. Reduced cost

Multi Availability Zone Architecture

Suppose you are working on AWS but suddenly one data centre in your zone fails or may feel some error. Now does it mean you have to wait for some period of time or you lost your data?
The answer is no and this is one of the biggest positive about AWS.
An Availability Zone is an isolated data center inside an AWS Region.

Suppose:

• One data center fails due to hardware issues
• Traffic is automatically redirected to another Availability Zone

This ensures applications remain online even during failures.

Amazon CloudFront

For global applications, AWS uses Amazon CloudFront.

CloudFront is a Content Delivery Network (CDN) that stores cached copies of content at edge locations around the world.

When a user accesses a website:

• Data is served from the nearest edge location
• Latency decreases
• Speed improves dramatically

For example:
A user in India can access data from a nearby edge server instead of waiting for requests to travel to the United States.

This significantly improves user experience.

YARA stands for “Yet Another Recursive Acronym” is a pattern-matching tool used in cybersecurity to identify and classify malware by defining rules based on text strings, byte sequences, and other file characteristics.

Purpose: Help in threat hunting ,malware analysis and incident responses by detecting behavioral patterns.

Use Cases:
1.Detecting ransomware, trojans and obfuscated malware.
2. Identifying command and control traffic.

Structure: A basic YARA rule consists of four primary components: the rule declaration, meta section, strings section, and condition section.

1. Rule section primarily contains the keyword Rule, optional tags and unique rule name.
2.Meta section consist of key-value pairs and descriptive information about the rule and author.
3.String section consist of identifiers, pattern to search for and modifiers.
4.Condition section is one of the most important section and consist of logical expressions, Boolean operators, string references and built in variables.

Installation:
You can install yara on Linux by just doing apt install yara but just make sure you are in root or if you are not just do sudo apt install yara.

For installation on windows just visit — yara.win

How to verify whether it is working or not?
Step 1: Verify YARA is Installed

Step 2: Create a Simple YARA Rule

Type sample test rules

Step 3 :Create a sample text file

and then type write this

Step 4: Run YARA

If it works you will see

If there was no word like malware in the text we wrote, it would not have detected it. Our YARA rule string section searches for word “malware” so we got the output otherwise we would not have got anything.

Now we are moving to an important section which is YARA modules-

YARA Modules: YARA modules extend YARA’s capabilities by allowing deeper inspection of specific file formats, hashes, mathematical properties, and sandbox data.
Instead of only matching strings, modules allow context-aware detection.

Modules are imported using:

1. PE Module(Portable Executable)

The PE module is used to analyze Windows executable files (.exe, .dll).
It allows inspection of:
1.Number of sections
2.Section names
3.Import and exports
4.Entry Points
5.Compile timestamp
6.Digital Signatures

Example 1: Detect Suspicious Section Count

• Malware often adds extra sections for obfuscation.
• This rule flags executables with more than 6 sections.

Example 2: Detect Suspicious API Imports

• VirtualAlloc and WriteProcessMemory are commonly used in process injection.
• This rule detects executables importing both APIs.

Example 3: Detect Packed Executable

Large .text sections may indicate packing.

2. ELF Module
Used for analyzing Linux binaries (ELF files).

Allows inspection of:
1.Section
2.Entry Point
3.Architecture
4.Imports

3. Hash Module

Used to compute file hashes inside YARA rules.
Supports:
1.MD5
2.SHA1
3.SHA256

• Calculates MD5 from offset 0 to end of file.
• Matches known malicious hash.

4. Math Module

Used for entropy detection and numeric analysis.
Very useful for detecting packed or encrypted files.

• High entropy (>7.5) suggests encryption or packing.
• Useful for detecting obfuscated malware.

5. Cuckoo Module

Used when scanning Cuckoo Sandbox reports (JSON files).
Allows matching:
1.Mutex names
2.Network activity
3.Registry keys
4.Process names

This rule detects sandbox reports where malware contacted a malicious domain.

6. Magic Module

Identifies file type based on file signature.

Detects files pretending to be something else.

7. Dotnet Module

Used to analyze .NET executables.
Can inspect:
1.Assembly names
2.Class names
3.Methods

Module Workflow:

SIGMA:

It is an open-standard rule format used in cybersecurity to detect suspicious activity in log data across different SIEM platforms.

Purpose:
Help in threat detection, log analysis, SOC monitoring, and incident response by identifying suspicious patterns in system and network logs.

Sigma provides a standardized detection format that can be converted into different SIEM query languages.

Use Cases:

1. Detecting suspicious PowerShell execution.
2. Detecting privilege escalation attempts.
3. Identifying lateral movement in a network.
4. Monitoring failed login attempts.
5. Detecting command and control communication patterns.
6. Detecting suspicious account creation or admin privilege changes.

Structure:

A basic Sigma rule consists of the following primary components:

1. Title
2. ID
3. Status
4. Description
5. Author & Date
6. Logsource section
7. Detection section
8. Falsepositives
9. Level

1. Title Section

Contains the name of the detection rule.

2. ID Section

Contains a unique identifier (UUID format).

3. Status Section

Defines the maturity of the rule.

Common values:

• experimental
• test
• stable
• deprecated

4. Description Section

Provides explanation about what the rule detects.

5. Logsource Section

Defines:

• Product (Windows, Linux, Firewall, etc.)
• Category (process_creation, network_connection, authentication, etc.)

Example:

6. Detection Section (Most Important Section)

This section contains:

• Selection criteria
• Logical expressions
• Boolean operators (AND, OR, NOT)
• Field references
• Conditions

Example:

This means:
If PowerShell is executed with Invoke-Expression → trigger alert.

7. Falsepositives Section

Lists legitimate scenarios that might trigger the rule.

Example:

8. Level Section

Defines severity of the detection.

Common levels:

• low
• medium
• high
• critical

title: Suspicious PowerShell Download and Execution
id: 9f3c8a21-6b12-4e7d-8f52-1a2b3c4d5e6f
status: experimental
description: >
  Detects suspicious PowerShell execution where a script is downloaded
  from the internet using Invoke-WebRequest or DownloadString,
  which may indicate malware delivery or command and control activity.
author: Abhik Kumawat
date: 2026/03/03
references:
  - https://attack.mitre.org/techniques/T1059/001/
  - https://attack.mitre.org/techniques/T1105/
tags:
  - attack.execution
  - attack.t1059.001
  - attack.command_and_control
  - attack.t1105

logsource:
  product: windows
  category: process_creation
  service: sysmon

detection:
  selection_image:
    Image|endswith: '\powershell.exe'

  selection_download:
    CommandLine|contains:
      - 'Invoke-WebRequest'
      - 'DownloadString'
      - 'New-Object Net.WebClient'

  selection_encoded:
    CommandLine|contains:
      - '-enc'
      - '-encodedcommand'

  condition: selection_image and (selection_download or selection_encoded)

falsepositives:
  - Legitimate administrative scripts downloading updates
  - IT automation scripts
  - Configuration management tools

level: high

Installation:

Sigma itself is a rule format, not a scanning engine.

To use Sigma:

1. Install Sigma CLI tool.
2. Write Sigma rules in YAML format.
3. Convert them to your SIEM query language.

Installation on Linux:

Then convert rule:

Why Do We Convert Sigma Into Splunk?

Because Sigma is not a detection engine.

Sigma is just a generic rule format (YAML-based template).

It cannot:

• Collect logs
• Search logs
• Generate alerts
• Monitor systems

It only describes detection logic.

Then What Does Splunk Do?

Splunk is a SIEM platform that:

• Collects logs
• Indexes logs
• Searches logs using SPL (Search Processing Language)
• Generates alerts
• Creates dashboards

Splunk is the engine.
Sigma is the blueprint.

How to Verify Whether It Is Working or Not?

Step 1: Install Sigma CLI
Step 2: Create a simple Sigma rule
Step 3: Convert the rule to your SIEM query
Step 4: Run the query in your SIEM (Splunk / Elastic etc.)

If logs match the defined condition → an alert will be generated.

If there is no matching log event → no alert is generated.

Major Difference Between YARA and Sigma

Although both YARA and Sigma are used in cybersecurity for detection purposes, they operate in completely different domains and solve different problems.

YARA is primarily a file and memory scanning tool, while Sigma is a log-based detection rule format used in Security Operations Centers (SOC).

Where They Operate

YARA operates on:

• Malware samples
• Suspicious files
• Memory dumps
• Endpoints

Sigma operates on:

• Windows Event Logs
• Sysmon logs
• Firewall logs
• Authentication logs
• SIEM environments