Main Page

🔐 Welcome to Security Manadhey

Step into the world of real-world cybercrime investigations!

🕵️‍♀️ What We Offer:

• Access to simulated cybercrime case files
• Investigate, analyze, and submit your findings
• Compete with others and climb the leaderboard

🧾 How It Works:

1. Go to Join Challenge page and pay ₹50
2. Get access to this week's cyber case file
3. Submit your solution via form
4. Your name appears on the leaderboard if you solve it right!

HIT CASE FILES

Story

Logs

Townhall city

Townhall city logs

Aws Guard duty | Persistence

Persistence:

Adversaries/attackers are trying to remain inside your system even after you remove them.

After the attacker gains access, they may try to keep their access alive for a long time  adding access keys, backdoor users, or modifying startup scripts. then try to find or exfiltrate sensitive data

Attack :

Guard duty detected a finding in AWS and triggered an alert.

Persistence: IAMUser/AnomalousBehavior

The IAM user is behaving more suspiciously than usual—maybe trying to stay logged in longer, access services not used before, or use unusual regions.

If guard duty detects a finding, it generates an alert in the AWS GuardDuty console as a finding ID.

Defense:

Generally, an attacker is trying to maintain long-term access to a compromised AWS environment. That means user credentials were logged in without the actual user's knowledge.

Attackers keep sessions longer; hence, to find this, check the start and end times of the activity. 

If the same user activity, deviating from the general baseline activity, is observed repeatedly or unusual activity with an updated end time is seen, we can suspect persistence. 

Kindly check for any threat or alert detections on the user account.

These could also be benign true positive, or false positive alerts.

Hence, check the logs of the user's previous activities. If no threat indication or alerts are present, the user can be treated as risk-less. Check the historical logs; if the same API access is observed from the user, the alert can be closed.

It is important to investigate the AWS logs for the reason why GuardDuty detected a threat.

Need to check with the team managing AWS for access information, or with the user, to easily classify and triage this activity.

If compromise identified or its not user activity

We need to revoke sessions, reset access keys, and rotate passwords for the user

We also need to strengthen security rules for initial access, such as implementing MFA or a 2FA mechanism.

Payload Explanation:

{"schemaVersion":"2.0","accountId":"123456789012","region":"us-east-1","partition":"aws","id":"abcd1234-5678-90ab-cdef-EXAMPLE11111","arn":"arn:aws:guardduty:us-east-1:123456789012:detector/12abc34d567e8f9012g3h456789i012j/finding/abcd1234-5678-90ab-cdef-EXAMPLE11111","type":"Persistence:IAMUser/AnomalousBehavior","resource":{"resourceType":"AccessKey","accessKeyDetails":{"accessKeyId":"AKIAEXAMPLE","principalId":"AIDAEXAMPLE","userType":"IAMUser","userName":"example-user"},"instanceDetails":null},"service":{"serviceName":"guardduty","detectorId":"12abc34d567e8f9012g3h456789i012j","action":{"actionType":"AWS_API_CALL","awsApiCallAction":{"api":"ListBuckets","serviceName":"s3.amazonaws.com","callerType":"remote IP","remoteIpDetails":{"ipAddressV4":"203.0.113.42","organization":{"asn":"64512","asnOrg":"EXAMPLE ISP","isp":"EXAMPLE ISP","org":"EXAMPLE ORG"},"country":{"countryName":"Russia"},"city":{"cityName":"Moscow"},"geoLocation":{"lat":55.7558,"lon":37.6173}},"userAgent":"aws-sdk-java/1.11.100","domainDetails":{"domain":"s3.amazonaws.com"},"additionalInfo":{"anomalousApi":"ListBuckets","apiCount":37,""apiUsedByUser":"GetObject,PutObject,CreateBucket,DeleteBucket","unusualServiceAccess":"S3","userAccessPatterns":"This user typically accesses EC2, but is now accessing S3","unusualCountryAccess":"true"}}},"eventFirstSeen":"2025-06-07T00:00:00Z","eventLastSeen":"2025-06-07T00:05:00Z","archived":false,"count":1},"severity":5,"title":"IAM user is exhibiting anomalous behavior","description":"An IAM user has accessed services in an unexpected way, including API calls not normally used and from a geolocation not previously associated with this user. This could indicate credential compromise or attacker persistence."}

Lets discuss on payload

Some other findings on AWS GuardDuty are mentioned below.

Persistence: ResourcePermission/ Bitcoin Tool.B

Persistence: EC2/SSHBruteForceSuccess

AWS Guard duty | Execution

Execution : 

Adversaries/ Attacker run malicious code on target system, this is one of the most important tactic.

It's a calm Tuesday evening. Asritha is sipping her tea due to a headache caused by the alerts.she  received a call from another analyst that critical alerts were triggered. She ran, leaving her tea aside, and assigned the incident.

Finding : Execution: EC2 Instance - Tor client / Backdoor:EC2/TorClient

These findings are in the execution phase because they are occurring from the instance.

This finding shows that guard duty detected a Tor client running on an EC2 instance. 

Attack:

Someone might launch code, or an adversary compromised the instance during delivery

Delivery of malicious payloads can be through various means, such as phishing emails opened immediately, drive-by download attacks, and PUPs, which are accessed inside the EC2 instances.

hence the delivery got sucessful and that lead to tor client execution on instance

Or some user want to conduct scanning, red team activity, or simulations to test the guard duty's detection capabilities on the instance.

This basically identified when the Tor client was running on the instance.

Defense:

kindly check with the user whether the user is having privileges to do this activity and whether this is begnin activitiy or not

kindly recommend to isolate the instance or stop the instance on immediate affect 

identify the process or tor client remove from the instance 

Kindly terminate the machine  if this is not a legitimate activity. If a remote or public IP address is found, then block the remote IP address.

If any backup snapshots can be restored to avoid service disruption.

Kindly recommend to temporarily disable the IAM account

Payload explanation:

{"schemaVersion":"2.0","accountId":"123456789012","region":"ap-south-1","partition":"aws","id":"abcd1234efgh5678ijkl9012mnop3456","arn":"arn:aws:guardduty:ap-south-1:123456789012:detector/12ab34cd5678e9012fgh34ij56kl78mn/finding/abcd1234efgh5678ijkl9012mnop3456","type":"Execution:EC2/TorClient","resource":{"resourceType":"Instance","instanceDetails":{"instanceId":"i-0ab12cd3456ef7890","instanceType":"t3.medium","platform":"Linux","launchTime":"2025-06-03T08:24:16Z","networkInterfaces":[{"networkInterfaceId":"eni-abc123def456","privateIpAddress":"10.0.1.5","subnetId":"subnet-xyz890123","vpcId":"vpc-11223344"}]}},"severity":7.5,"createdAt":"2025-06-03T10:45:12Z","updatedAt":"2025-06-03T10:45:12Z","title":"EC2 Instance is running a Tor client","description":"EC2 instance i-0ab12cd3456ef7890 in region ap-south-1 is running a Tor client, which can be used for anonymized command and control communications.","service":{"serviceName":"guardduty","detectorId":"12ab34cd5678e9012fgh34ij56kl78mn","action":{"actionType":"EXECUTION","runtimeDetails":{"processName":"tor","processId":4321,"filePath":"/usr/bin/tor"}},"resourceRole":"TARGET"},"confidence":95,"findingProviderFields":{"threatPurpose":"EXECUTION","name":"Execution:EC2/TorClient","description":"The EC2 instance is running a Tor client executable, often used by attackers to mask command and control traffic.","severityLabel":"HIGH"}}

The above activity was detected as a finding by AWS GuardDuty because EC2 instance i-0ab12cd3456ef7890 in AWS account 123456789012 is running a Tor client. This client connects to the Tor network. The process name is "tor," and its location is /usr/bin/tor. Please follow the defense steps mentioned above.

Like wise we get several execution finding ID's 

Some of them are mentioned below for reference :

Execution:EC2/Backdoor:EC2/SSHBruteForce :

If multiple SSH connection attempts are detected from any EC2 instance, indicating a possible malicious brute-force attack on any resource or IP network, then GuardDuty detects this or similar findings.

Execution: EC2/BitcoinTool.B! DNS:

If any application or process detected on EC2 attempting DNS queries related to Bitcoin mining, then GuardDuty detects this or similar findings.

Execution:EC2/CommandAndControl:EC2/Beacon: 

If any EC2 instance  is beaconing or  communicates with to an external server, usually a result of command execution (also C2). then GuardDuty detects this or similar findings.

similar kind of activites which initiates from the instances fall under execution phase

AWS Guard duty | Initial access

Initial access:

This basically means how an attacker gets into your environment.

its the first step where an attacker tries to gain entry into a system, network, or cloud environment.

Imagine you are part of a company's SOC team. One morning, you receive an alert from AWS GuardDuty. It says:

"UnauthorizedAccess:IAMUser/ BruteForce"

Attack:

This means someone, or a hacker, is sitting somewhere outside your company maybe in another country. They don't know accounts password or secret keys, but they're trying to get into the AWS console.

So they try multiple login attempts using guessed passwords or leaked credentials.

Or user tries to authenticate and fails, they might have forgotten their password.

Multiple password failures could lead to this finding in GuardDuty. 

Defense:

Check the logs and find out the remote IP address.

check with the user whether these are legit failures or not

If these are not genuine failures reset the credentials.. 

check whether all mfa controls are in place for the user 

Need to block the remote IP address on the AWS NACL if it is malicious.

Kindly check with the team managing AWS and ask for confirmation whether the user has privileges to access the resource or console, and if it is benign activity.

monitor the user account vigilantly

Note:

if the failures are from any generic or service account the failures can be because of scripts. 

this has to be checked by aws team to find out the RCA of these failures

Guard duty identified below some of the findings. These are access-related and hence classified as an initial access technique.

Like wise other findings mentioned below:

UnauthorizedAccess:EC2/SSHBruteForce

If the attacker performed Brute-force attempt to gain access EC2 instances over SSH( port 22) then guard duty detects this finding.

UnauthorizedAccess:EC2/RDPBruteForce

If the attecker performed Brute-force attempt to  RDP (for Windows EC2 instances) then guard duty detects this finding.

UnauthorizedAccess:IAMUser/BruteForce

If a large number of failed attempts to access resources from an IAM user account occur, then GuardDuty detects this finding as a brute-force attack on IAM user credentials.

UnauthorizedAccess:IAMUser/TorIPCaller

if the Access has been made using a source IP which is TOR exit node IP (suspicious access origin)

then guard duty detects this finding.

UnauthorizedAccess:IAMUser/ConsoleLogin

If the Console login attempt from IAM user account from the suspicious source IP having scanning, spam, malware categorizations or unusual geo, TOR.

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration

Generally When an EC2 instance has a role, AWS assigns temporary credentials via the Instance Metadata Service (IMDS). These credentials should be used only by that EC2 instance, inside AWS.

But let's say an attacker who has gained access can query the metadata, obtain temporary credentials, and send this metadata externally from their laptop and copy the credentials to his own laptop.

If this is identified by the guard duty, it will be detected as a finding.

One of the Payload explanation:

{

  "schemaVersion": "2.0", "accountId": "123456789012", "region": "us-east-1", "partition": "aws",

  "id": "abcd1234-5678-efgh-ijkl-9012mnopqrst", "arn": "arn:aws:guardduty:us-east-1:123456789012:detector/abc123/finding/abcd1234", "type": "UnauthorizedAccess:IAMUser/BruteForce", "resource": { "resourceType": "AccessKey", "accessKeyDetails": { "accessKeyId": "AKIAEXAMPLEKEY", "principalId": "AIDEXAMPLEUSER", "userType": "IAMUser", "userName": "suspicious-user" } }, 

  "service": { "serviceName": "guardduty", "action": { "actionType": "AWS_API_CALL", "awsApiCallAction": { "api": "ConsoleLogin", "serviceName": "signin.amazonaws.com", "remoteIpDetails": { "ipAddressV4": "198.51.100.45", "organization": { "asn": "13335", "isp": "ExampleISP", "org": "ExampleOrg" }, "country": { "countryName": "Unknown" } }, "userAgent": "signin.amazonaws.com" } }, "detectorId": "abc123", "eventFirstSeen": "2025-06-02T12:40:00Z", "eventLastSeen": "2025-06-02T12:45:33Z", "count": 42 }, 

  "severity": 7.0, "title": "Brute Force Attempt Using IAM User Credentials", "description": "Multiple failed sign-in attempts detected for IAM user suspicious-user from IP 198.51.100.45", "createdAt": "2025-06-02T12:45:40Z", "updatedAt": "2025-06-02T12:46:00Z"

}

Fields of AWS GuardDuty will be the same.

Finding ID you can find it out on Guardduty console)

ID:    arn:aws:guardduty:us-east-1:123456789012:detector/abc123/finding/abcd1234

Payload explanation:

Here, brute-force attempts, i.e., a large number of failures from an IAM user (Principal ID), detected by GuardDuty are created as findings with severity 7.

these attempts are signins for aws console coming from remote IP 198.51.100.45 and firstly seen from

2025-06-02T12:40:00Z till 2025-06-02T12:45:33Z

Account ID : The resources could be located in that account, which has an ID.

Remote IP analysis:(How to perform) : Reference

These attempts are signins for aws console from the user

Validate the same principal ID in AWS CloudTrail logs for more information on error codes and the reason for failure.

Kindly follow the defense to mitigate these failures, as mentioned in the defense section.

AWS Guard Duty | Reconnaissance | Log Analysis

 

Reconnaissance

Some guard duty findings types related to reconnaissance are below.

AWS GuardDuty detects a wide range of suspicious or malicious activity in your AWS environment using threat intelligence. Generally, it monitors CloudTrail and VPC logs and detects suspicious activities as findings. The findings will be as mentioned below.

Finding types:

Recon:EC2/PortProbeUnprotectedPort
Recon:EC2/PortScan
Recon:EC2/PortProbeUnprotectedPort
Recon:EC2/PortProbeEC2Instance
Recon:EC2/NetworkReachability
Recon:S3/MaliciousIPCaller
Recon:IAMUser/MaliciousIPCaller
Recon:EC2/HostDiscovery
Recon:EC2/TorConnection
Recon:EC2/UnusualTrafficPattern

Findings:

On the AWS GuardDuty console, all findings listed are security alerts or detected threats.. 

Each finding includes:

Title :(e.g.,Recon:EC2/PortProbeUnprotectedPort")

Description :  Finding Descriptions.

Severity (Low, Medium, High)

Resource affected (EC2, IAM user, S3, etc.)

Threat type (like UnauthorizedAccess, Recon, Trojan, etc.)

Time detected

Recommendation

Lets discuss on one of the finding.

1.Recon:EC2/PortProbeUnprotectedPort

This finding indicates that an external source is probing an Amazon EC2 instance for open and unprotected ports. Attackers often conduct reconnaissance by scanning for vulnerabilities before launching an attack, such as exploiting misconfigured security groups or outdated services.

This event is detected by guard duty when there are multiple connection attempts to an EC2 instance from remote IP addresses over multiple ports.

An external entity is scanning an EC2 instance for open ports that are unprotected, potentially identifying vulnerabilities for exploitation.

Attack:

An external entity is scanning an EC2 instance for open ports that are unprotected potentially identifying vulnerabilities for exploitation.

Defense:

As guard duty generates its findings, they will be visible on SIEM and as well as Guard duty console.

or AWS management consoles.

SOC analysts should act on these finding IDs and escalate or raise incidents to the incident response team. This will be handled by the infrastructure team, which manages the AWS cloud..

Restrict:

Restrict security group rules on aws cloud trail, enable AWS WAF.

Block the remote IP address on the AWS NACL

If a port is open that should not be, modify the security groups and close the port.

For this finding, type the events you will observe as below.

Sample log and explanation:

Event Payload( this is Json format)

{ "schemaVersion": "2.0", "accountld": "123456789012", "region": "us- east-1", "id": "abcdef1234567890", "arn": "arn:aws:guardduty:us- east-1:123456789012:detector/abcdef1234567890/finding/abcdef".

"type": "Recon:EC2/PortProbeUnprotectedPort", "service": {

"serviceName": "guardduty", "eventFirstSeen": "2022-12-

13T17:47:40Z", "eventLastSeen": "2022-12-13T17:47:40Z", "count": 4.

"action": {"action Type": "PORT_PROBE", "portProbeAction": {

"portProbeDetails": [("localPortDetails": ("port": 22345. "protocol":

"TCP"}, "remotelp Details": { "ipAddressV4": "223.252.36.77" }}. (

"localPortDetails": ("port": 23231, "protocol": "TCP"}.

"remotelp Details": ("ipAddressV4": "223.252.36.77")). (

"localPortDetails": {"port": 24500, "protocol": "TCP"}.

"remotelp Details": {"ipAddressV4": "223.252.36.77"}). (

"localPortDetails": ("port": 24500, "protocol": "TCP").

"remotelp Details": {"ipAddressV4": "223.252.36.77"}}]}}}.

"resource": ("instanceDetails": {"instanceld": "i-

Oabc1234de56789fg", "instanceType": "t2.micro", "privatelpAddress"

"10.10.15.32", "securityGroups": [{ "groupld": "sg-

abcdef1234567890", "group Name": "default"}]}}. "severity": 5.0,

"createdAt": "2022-12-13T17:47:40Z", "updatedAt": "2022-12-

13T17:47:40Z", "title": "EC2 Instance Port Scanning Detected". "description": "An external IP address (223.252.36.77) has attempted to scan multiple ports (22345, 23231, 24500) on an EC2 instance (10.10.15.32) in your AWS account.", "remediation": "Restrict access to the exposed ports using security groups or Network ACLs."

Payload Explanation:

This finding was detected when port scanning occurred on EC2 instances. The description highlights that an external IP address attempted a port scan on the EC2 instance over ports 22345, 23231, 24500, and multiple others.

Please check the resource details, including instance details and the allocated IP address for that instance. Attackers targeted that instance.

This particular finding indicates that scans occurred on resource "instanceId": "i-0abc1234de56789fg".

You can also find the security group associated with an EC2 instance. Security groups act like virtual firewalls and control inbound and outbound traffic to and from the instance based on rules which are defined by  team who manages AWS 

These rules specify what kind of traffic is allowed, based on protocols, ports, and source/destination IP addresses

AWS Guardduty also detects threat severity and include in payload 

"severity": 5

Severity is usually a value between 0 to 8, categorized as:

Low (1–3)

Medium (4–6)

High (7–8)

As the severity is 5.0, which falls in medium.

First seen :

The first time GuardDuty detected this specific behavior or pattern related to the finding.

Helps indicate when the suspicious activity started.

Last seen :

The most recent time GuardDuty observed this behaviour and tells that how recent the activity is and whether it's still ongoing.

These timestamps help to determine whether it is a one-time activity or a persistent activity.

if the gap of first seen and last seen is large

then it may be persistence or recurring threat.

other findings mentioned above also appear to have the similar payload.

Linux | Multiple Login failures

For Linux Systems:

SSH Failed Logins: 

This gets triggered when someone tries to log into a Linux server via SSH (for 

example, using PuTTY).

Privilege Escalation Failures: This happens when a user or local account tries to run a command with elevated privileges (using sudo)

Analysis:

Check the account activity over the last day to see if there were any password change events.

If you find a successful password change followed by login failures, it might be due to a syncing or 

credential issue, not necessarily a security problem.

If everything lines up and there's no suspicious activity, you can wrap up the investigation and close 

the case.

Mitigation:

Reach out to the user or service account owner to confirm if the failed login attempts are expected. If 

they recognize these attempts as legitimate, you can close the incident. However, if the logins seem 

unfamiliar, the password should be reset. Here’s how to proceed:

• For administrative accounts, send the incident to the Windows team.

• For regular user accounts, direct the incident to the Service Desk team for a password reset.

Its all based on organization scope

Tshark

 Tshark -  TShark is the command-line version of Wireshark

It performs similar network packet capture and analysis functions but without a graphical user interface. It is widely used for network monitoring, troubleshooting, and security analysis, especially in environments where a GUI is not available.

 

Examples :

 

Capture packets on an interface: 

tshark -i eth0

Capture and display only HTTP traffic: 

tshark -i eth0 -f "tcp port 80"

Capture packets and save to a file:

tshark -i eth0 -w capture.pcap

Display DNS queries:

tshark -i eth0 -Y "dns"

Output capture to JSON format:

tshark -i eth0 -T json

Key Options:

-i -> interface selection : Specifies the network interface to capture packets

 Example: tshark -i eth0

-D -> Get list of interfaces : we get output , that you get all list of interfaces

 Example: tshark -D

-f -> capture filter : Specifies a filter for the packets captured at the interface level.

 Example : tshark -i eth0 -f "tcp port 80"

-Y -> display filter :  Filters the packets after capture (similar to Wireshark's display filters).

 Example : tshark -i eth0 -Y "http"

-w -> write output to the file: Writes the captured packets to a file in PCAP format, which can be opened later in Wireshark.

 Example : tshark -i eth0 -w capture.pcap

For More Info: https://www.securitymanadhey.com/p/tshark-tshark-is-command-line-version.html

Querying DNS Records

In the Windows operating system, the nslookup command is used to query DNS records.

For example, to query the DNS A record for a domain, use the following command:

nslookup -type=A domainname

nslookup -type=A securitymanadhey.com

This command produces output:

Server: reliance.reliance (this is ISP connection)

Address: 2405:201:c00b:3a31::c0a8:1d01(the IP address of the Reliance DNS resolver)

Non-authoritative answer:

Name: securitymanadhey.com(domain)

Addresses:  

15.197.225.128 (IPV4 of the domain)

3.33.251.168(IPV4 of the domain)

Details:

Server: Displays the name and IP address of the DNS resolver used for the query.( this DNS resolver provided by your Internet Service Provider(ISP))

Non-authoritative answer: Indicates that the response came from a DNS server that is not the authoritative server for the domain.

Name: Shows the queried domain name.

Addresses: Lists the IP addresses associated with the domain (IPv4 in this example).

By default, your device uses the DNS resolver provided by your Internet Service Provider (ISP) unless you configure it to use a custom DNS server.

If you configure your device to use custom DNS servers (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1), the output would display those instead in the Server and Address fields.

DNS Zones

Zone files are plain text files that store information about a specific domain's DNS configuration. They are part of the Domain Name System (DNS) and are maintained by authoritative DNS servers. Each zone file contains DNS records that define the mappings and properties for a domain and its subdomains.

Key Components of zone file are A ,AAAA,NS,CNAME,MX,TXT,SOA and other records.

DNS Server basics, types, record types, query types

 

The Basics of DNS: The Internet's Address Book

Imagine if every time you wanted to call a friend, you had to remember their exact 10-digit phone number. The internet would be similarly frustrating if we had to remember IP addresses for every website we wanted to visit! This is where the Domain Name System (DNS) comes in, acting as the "phone book" of the internet. DNS lets us use friendly domain names (like “www.miusecurity.blogspot.com”) instead of remembering a long string of numbers.

When you type a website address in your browser, DNS resolves the IP address for that domain. Think of DNS as the bridge between people and computers, translating easy-to-remember names into IP addresses that computers need to communicate.

Here's how DNS works,

• User Query: Imagine you entered “www.miusecurity.blogspot.com” into your web browser
• Recursive /DNS Resolver: First, your computer sends the request to a DNS resolver. This DNS resolver converts the domain name into an IP address, and this DNS resolver will be offered by your internet service provider (ISP). If not, we can use a public Google DNS server to resolve the DNS request.
• Root Server Query: If the resolver doesn't know the IP address (because it's not cached), it reaches out to one of the 13 root DNS servers to get the information. These servers don't hold specific addresses but know where to find the servers that manage top-level domains (like .com, .org, etc.).
• TLD Server Query: The root server then directs the resolver to the TLD server for .com (since we're looking for miusecurity.blogspot.com).
• Authoritative DNS Server Query: The TLD server tells the resolver which authoritative DNS server handles “www.miusecurity.blogspot.com”.
• Final Resolution: The authoritative DNS server, for “www.miusecurity.blogspot.com”, finally returns the IP address for “www.miusecurity.blogspot.com” to the resolver.
• Connection Established: Now that the resolver has the IP address and sends it back to your browser, the browser can use that address to connect to the website

  

Types of DNS Servers

1. Root Name Servers: These are the first step in the DNS lookup process. When a query is made, they direct the request to the appropriate Top-Level Domain (TLD) servers.
2. TLD Name Servers: These servers manage domains within specific top-level domains like .com, .org, or .net. They help identify which authoritative DNS server should handle the request for a particular domain.
3. Authoritative DNS Servers: These servers are responsible for storing the actual DNS records (A, MX, TXT, etc.) for your domain. These servers provide the definitive answers to DNS queries about your domain.
4. Recursive DNS Servers (such as Google DNS, Cloudflare DNS, etc.): These servers are responsible for helping users (clients) resolve DNS queries by contacting authoritative servers to get the correct information.

DNS Record Types

DNS records are the data that DNS servers return when a query is made. Here are some common record types:

• A (Address) Record: This record maps a domain name to an IPv4 address.
• AAAA (IPv6 Address) Record: It is like an A record, but it maps a domain to an IPv6 address.
• CNAME (Canonical Name) Record: This record allows one domain name to refer to another domain. It's commonly used for domain aliases.
• MX (Mail Exchange) Record: This record directs email to the correct mail server of the domain.
• TXT (Text) Record: Stores arbitrary text, often used for verification, such as SPF records for email security.
• NS (Name Server) Record: Identifies the authoritative DNS servers for a domain.

DNS Query Types

• Recursive Query: In this type of query, the DNS resolver fully resolves the domain name by interacting with multiple servers until it gets the final IP address, and then it sends that back to the user.
•  Iterative Query: When a resolver (client) asks a DNS server for an IP address, and the server doesn't have the exact answer, it will point the resolver in the direction of another DNS server that might know more. This process continues, with the resolver querying multiple DNS servers, each one getting closer to the final answer until the correct IP address is found.

DNS Caching

• DNS responses are cached basically to speed up lookups and reduce the load on DNS servers. Responses cache on the User's Device, by the internet service provider(ISP) recursive resolver, and by the Browsers .

DNS Security Concerns:

DNS is vulnerable to various attacks:

• DNS Spoofing (Cache Poisoning): This is when attackers inject false information into a DNS cache, redirecting users to malicious websites.
• DNS Tunneling: Malicious data can be hidden in DNS queries, which can bypass security measures and used for exfiltrating sensitive information.
• DDoS Attacks on DNS Infrastructure: Distributed Denial-of-Service (DDoS) attacks can overwhelm DNS servers, making websites unreachable.
• DNS Hijacking: Malicious actors can take control of DNS queries, redirecting users to fraudulent servers, which is often for phishing.