Azure App registration vs Enterprise Application

 

Difference between Azure App Registration vs Service Principal 

An App Registration is the application’s definition.
A Service Principal is the application’s identity inside a tenant.

Think of it like this:

App Registration = blueprint
Service Principal = actual instance created from that blueprint

Microsoft describes the application object as the app definition, while the service principal is the local representation of that app in a specific tenant. (Microsoft Learn)

What is an App Registration?

An App Registration is created when you register an application in Microsoft Entra ID.

It contains the app’s core configuration, such as:

• Application/client ID

• Redirect URIs

• Client secrets or certificates

• Supported account types

• API permissions the app requests

• App roles

• Authentication settings

Use App registrations when you want to configure how the app authenticates or what permissions it requests. Microsoft Entra app registrations are managed under Entra ID > App registrations. (Microsoft Learn)

What is a Service Principal?

A Service Principal is the app’s actual security identity in a tenant.

It controls what the app can do in that tenant, such as:

• What permissions were actually granted

• Whether users can access the app

• Whether the app is enabled

• Sign-in activity

• Azure RBAC role assignments

• Tenant-specific access controls

In the Entra admin center, service principals are shown under Enterprise applications. (Microsoft Learn)

Key difference

App Registration	Service Principal
Defines the application	Represents the app in a tenant
Found under App registrations	Found under Enterprise applications
Used to configure app settings	Used to manage access and permissions
Contains requested permissions	Contains granted permissions
Used by developers/app owners	Used by admins/security/IAM teams

Simple example

A developer creates an app registration called:

Finance Reporting App

That app registration defines the app’s login settings, secrets, certificates, and requested API permissions.

When the app is used in a tenant, Entra creates a service principal for it. That service principal is what receives actual access, consented permissions, sign-in logs, and Azure role assignments.

So:

App Registration = what the app is
Service Principal = what the app can access

Single-tenant vs multitenant

For a single-tenant app, the app usually has one app registration and one service principal in the same tenant.

For a multitenant app, there is one app registration in the app owner’s tenant, but a separate service principal is created in every tenant where the app is used. (Microsoft Learn)

Example:

Vendor tenant:
  App Registration

Customer tenant A:
  Service Principal

Customer tenant B:
  Service Principal

Customer tenant C:
  Service Principal

This is why third-party SaaS apps often appear in your tenant under Enterprise applications, even though you do not own their app registration.

Which one should you use?

Use App registrations when you need to:

• Add or rotate a secret/certificate

• Change redirect URIs

• Configure authentication

• Add requested API permissions

• Expose an API

• Manage app roles

Use Enterprise applications / Service Principals when you need to:

• Review granted permissions

• Check sign-in activity

• Disable an app

• Assign users or groups

• Review admin consent

• Assign Azure RBAC access

• Investigate third-party app access

Summary:

The simplest rule is:

App Registration = configuration of the app
Service Principal = identity and access of the app in a tenant

For developers, most setup work happens in App registrations.
For security, IAM, and operations teams, most access review happens in Enterprise applications.

SANS FOR508 Home Lab Setup

 

I recently started preparing for SANS FOR508 (Advanced Incident Response, Threat Hunting, and Digital Forensics). One of the first things I wanted was a proper home lab where I could safely practice the labs, analyze artifacts, and get hands-on with DFIR tooling at will.

Below are the exact steps I used to build the lab environment at home using:

• VMware Workstation Pro
• SANS SIFT Workstation
• Windows 11
• Kali Linux

The setup is simple, isolated, and works well for practicing:

• Memory forensics
• Malware analysis
• PCAP analysis
• Windows event log investigations
• Threat hunting
• Incident response workflows

Everything runs isolated inside VMware Workstation Pro so you can safely practice investigations, packet analysis, memory forensics, log analysis, and incident response workflows.

I have a machine with 100 GB RAM, a 32-core CPU, and a 1 TB SSD. I’ll be using VMware Workstation Pro to build and run the lab environment on this system.

Recommended Hardware

Minimum workable setup:

• 32 GB RAM

• 4 CPU cores

• 500 GB SSD

Recommended if you can afford it:

• 64 GB RAM

• 8+ cores

• 1 TB SSD

Also make sure virtualization is enabled in BIOS:

• Intel VT-x

• AMD-V

Downloads

VMware Workstation Pro

VMware made Workstation Pro free for personal use.

Download here:

VMware Workstation Pro

---

SANS SIFT Workstation

Official SANS forensic VM.

Download:

SANS SIFT Workstation

OVA downloads:

SIFT Downloads

SIFT already includes tools like:

• Volatility

• Autopsy

• Sleuth Kit

• Plaso

• Rekall

Kali Linux VMware Image

Use the prebuilt VMware image instead of installing manually.

Download:

Kali VMware Images

Grab the VMware 64-bit image.

Windows 11 ISO

Official Microsoft ISO:

Windows 11 ISO

Step 1 — Install VMware Workstation Pro

Pretty straightforward:

1. Download installer

2. Run as Administrator

3. Next → Next → Finish

4. Reboot

Once installed, open VMware and make sure virtualization is detected properly.

Step 2: Create an Isolated Lab Network

This part matters.

Do NOT bridge these VMs directly to your home network if you're planning malware analysis or offensive testing.

Inside VMware:

Edit → Virtual Network Editor

Create:

VMnet2

Settings:

• Host-only

• DHCP disabled

• Subnet:

  • 192.168.50.0/24

You'll use this as the internal lab network.

Keep VMnet8 (NAT) enabled for internet access when needed.

Step 3: Import SIFT VM

Inside VMware:

File → Open

Select the SIFT OVA file.

Recommended specs:

Resource	Value
RAM	8–12 GB
CPU	4 vCPU
Disk	100 GB+

Network adapters:

Adapter	Network
Adapter 1	VMnet8 (NAT)
Adapter 2	VMnet2

Boot it up and update everything:

sudo apt update && sudo apt upgrade -y

Step 4: Import Kali Linux

Extract the Kali archive first.

Then open the .vmx file directly in VMware.

Recommended specs:

Resource	Value
RAM	6–8 GB
CPU	2–4 vCPU
Disk	80 GB+

Network:

Adapter	Network
Adapter 1	VMnet8
Adapter 2	VMnet2

Update Kali:

sudo apt update && sudo apt full-upgrade -y

Install a few useful tools:

sudo apt install -y \
wireshark \
docker.io \
bloodhound \
neo4j \
remmina

Step 5: Create Windows 11 VM

Create a new VM using the Windows 11 ISO.

Enable:

• UEFI

• TPM

Recommended specs:

Resource	Value
RAM	8–12 GB
CPU	4 vCPU
Disk	100 GB+

Important:

Only connect Windows to VMnet2 initially.

That keeps the victim machine isolated.

Step 6: Install Basic Windows Tooling

Inside Windows 11 install:

• VMware Tools

• Sysmon

• 7-Zip

• Windows Terminal

• Chrome or Firefox

Sysmon download:

Sysmon Download

Good Sysmon config:

SwiftOnSecurity Sysmon Config

Install Sysmon:

sysmon64.exe -accepteula -i sysmonconfig.xml

This gives you much better forensic logging.

Step 7: Assign Static IPs

Makes the lab easier to manage.

SIFT

192.168.50.10

Kali

192.168.50.20

Windows 11

192.168.50.30

No gateway needed for the isolated network.

Step 8: Take Snapshots

Do this early. You'll thank yourself later.

Good checkpoints:

• Fresh install

• Tools installed

• Clean baseline

• Before malware testing

Typical snapshot names:

CLEAN_INSTALL
DFIR_READY
MALWARE_TESTING

Step 9: Shared Folder Setup

Create a shared folder on the host:

C:\LabShare

Use it for:

• PCAPs

• Memory dumps

• Malware samples

• EVTX logs

• Disk images

Inside VMware:

VM Settings → Options → Shared Folders

Step 10: Lock Down the Lab

Inside VMware settings disable:

• Drag and drop

• Copy/paste

Go to:

VM Settings → Isolation

Uncheck both options.

Small thing, but worth doing.

Optional Additions

REMnux

Excellent Linux malware analysis VM.

Download:

REMnux

Flare VM

Windows malware analysis toolkit.

Download:

Flare VM

How to Handle a Security Incident: A Step-by-Step Guide

 

In today’s evolving threat landscape, security incidents are inevitable. How you respond to them determines the extent of damage and your organization’s resilience. Whether you’re dealing with a phishing attack, malware, a data breach, or a misconfiguration, a well-defined incident response process is crucial.

In this post, we’ll walk through a practical, structured approach to handling security incidents, based on best practices from the NIST Cybersecurity Framework and ISO/IEC 27035.

 

What is a Security Incident?

NIST SP 800-61 Rev. 2 defines an incident as:

"A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices."

 

A security incident is any event or series of events that indicate a potential breach or violation of an organization’s information security policies, acceptable use policies, or standard security practices. It often involves unauthorized access, use, disclosure, modification, or destruction of information or systems, and may impact confidentiality, integrity, or availability (CIA triad).

 

The Three Pillars:

• Confidentiality: Preventing unauthorized disclosure of information, like using encryption or access controls to keep sensitive data secret.
• Integrity: Maintaining the accuracy, consistency, and trustworthiness of data, protecting it from unauthorized changes or destruction (e.g., backups, checksums).
• Availability: Ensuring authorized users can reliably access information and systems when needed, through measures like redundancy, disaster recovery, and DoS protection. 

Key Characteristics of a Security Incident:

1. Unauthorized Activity
   An attempt to access or modify data or systems without authorization.
2. Policy Violation
   Activity that goes against internal security controls or procedures.
3. Threat Indicators
   Evidence of malware, phishing, data exfiltration, or insider misuse.
4. Potential Harm
   May result in data loss, service disruption, regulatory fines, or reputational damage.

Common Types of Security Incidents:

• Phishing attacks – where attackers trick users into giving up credentials or downloading malware.
• Malware infections – including ransomware or trojans on endpoints or servers.
• Data breaches – unauthorized access and/or theft of sensitive data.
• Insider threats – malicious or negligent actions by employees or contractors.
• Denial-of-Service (DoS/DDoS) attacks – aimed at making a system or service unavailable.
• Cloud misconfigurations – such as publicly exposed storage buckets or permissive IAM roles.

Incident Response: Cloud Provider Security Response Teams (Azure, AWS, GCP)

When operating in Azure, AWS, or GCP, your cloud provider has dedicated internal security teams that can assist during high-severity security incidents, such as:

• Suspected breaches of cloud infrastructure
• Data exfiltration concerns
• Compromised credentials with cloud-wide impact
• Abuse or misuse of cloud services
• Suspected platform-level vulnerabilities or service compromise

 What is MSRC?

The Microsoft Security Response Center (MSRC) is responsible for investigating and responding to security incidents affecting Microsoft services and infrastructure.

 What is AWS Security?

AWS Security is responsible for responding to issues affecting AWS’s own infrastructure or abuse of their services. For incidents in your own environment, you are the primary responder, but AWS can assist in platform-level issues or abuse cases.

 What is GCAT?

Google Cloud’s Cybersecurity Action Team (GCAT) provides strategic and technical incident support to enterprise customers. Google also has Security Command Center (SCC) and Chronicle for threat detection.

Step 1: Preparation

Before an incident even occurs, preparation is essential. Without it, your team will be reactive and either slow or don’t know how to respond.

Key Activities:

• Develop an Incident Response Plan (IRP) that outlines roles, responsibilities, communication protocols, and escalation procedures.
• Train your team on common attack vectors and run regular simulations or tabletop exercises.
• Implement monitoring tools:
• Security Information and Event Management (SIEM) tools like Splunk, Microsoft Sentinel, Cortex XSIAM is SIEM+XDR+SOAR, QRadar.
• Endpoint Detection and Response (EDR) platforms like CrowdStrike, Cortex XDR, Microsoft Defender for Endpoint, Prisma, Threat Locker
• Network monitoring tools like Zeek or Suricata
• Ensure all systems are logging security-relevant events and that logs are stored securely and centrally.

Preparation includes securing cloud resources as well. Tools like AWS GuardDuty, Azure Security Center, and Google Cloud’s Security Command Center can provide native visibility into cloud workloads.

 

Step 2: Detection and Analysis

Once a potential incident is suspected, the next step is detecting and verifying the event.

How to Detect an Incident:

• Monitor alerts from:
• SIEM dashboards
• Email security gateways
• Cloud security platforms
• IDS/IPS systems like Perimeter Firewalls
• Encourage users to report suspicious behavior such as phishing emails or system slowdowns.

How to Analyze the Incident:

• Identify affected systems and users.
• Correlate logs to determine the source and scope of the incident.
• Check for Indicators of Compromise (IOCs), such as:
• Unusual login times or locations
• Unexpected network traffic
• File integrity changes
• Unknown processes or binaries

Tools to Use:

• Use SIEM to create timelines and identify patterns.
• Use endpoint tools to capture forensic data (processes, registry changes, file hashes).

Forensic Tool	Type	Key Use Case
Velociraptor	Open-source	Enterprise live forensics
KAPE	Free	Fast artifact collection
FTK Imager	Free	Full disk/image acquisition
Magnet RAM Capture	Free	RAM dump
Redline	Free	In-depth memory/process analysis
GRR	Open-source	Scalable remote collection
Sysinternals	Free	Manual triage
Cortex XDR	Commercial	Integrated Palo Alto forensic collection
CrowdStrike RTR	Commercial	Remote forensics with scripting

 

• For web or API attacks, analyze WAF logs and application logs.
• In cloud environments, examine audit trails such as AWS CloudTrail, Azure Activity Logs, or GCP Audit Logs.

 

Example:
If you receive an alert for suspicious login from a foreign country, verify it against sign-in logs and determine whether MFA was bypassed.

 

Step 3: Containment

After confirming the incident, immediately take steps to contain the damage and stop the attack from spreading.

Short-Term Containment:

• Isolate and/or Disconnect affected machines from the network.
• Revoke access tokens or API keys.
• Disable compromised accounts or Force change passwords.
• Block malicious IPs or domains in firewalls or cloud security groups.

Long-Term Containment:

• Patch any vulnerabilities that were exploited.
• Update firewall rules or WAF policies to prevent further exploitation.
• Segregate sensitive data and services from the rest of the network.

Cloud:
If a compromised IAM user in Azure/AWS is discovered:

• Disable or delete their access keys.
• Attach a deny-all policy to the user or role.
• Rotate credentials immediately.

 

Step 4: Eradication

Once contained, the next goal is to eliminate the root cause and ensure the threat is removed.

Key Steps:

• Remove malware or malicious code.
• Delete backdoors or persistence mechanisms.
• Clean registry or service entries added by attackers.
• Restore altered files from clean backups.
• Identify and patch vulnerable applications or services.

Tools and Techniques:

• Use antivirus or EDR solutions to scan and remove malicious payloads.
• Review and clean crontabs, startup scripts, scheduled tasks, or registry keys.
• In the cloud, check for modified security groups, IAM roles, or resource policies.

 

Always validate that eradication was successful. Perform a full scan and re-check logs for lingering activity.

 

Step 5: Recovery

After the environment is clean, begin restoring systems to operational status.

Best Practices:

• Rebuild compromised systems from clean images.
• Restore data from backups and verify integrity.
• Monitor systems closely after bringing them back online.
• Re-enable access with secure credentials and enforce MFA.

 

Cloud Recovery:
In AWS or Azure, use infrastructure-as-code (Terraform, CloudFormation, ARM templates) to redeploy services consistently and securely.

Keep impacted users or customers informed, especially if there are regulatory obligations under GDPR, HIPAA, or other data protection laws.

 

Step 6: Post-Incident Activity

After recovery, take time to learn from the incident and improve defenses.

Activities to Perform:

• Conduct a Root Cause Analysis (RCA) to determine how the incident happened and what can prevent it next time.
• Review what worked and what didn’t in your IR process.
• Update documentation and playbooks.
• Share IOCs with threat intelligence platforms or industry partners.
• Conduct a debriefing with all stakeholders.

 

Example of Lessons Learned:

• The phishing email bypassed security filters - update email rules and user training.
• MFA wasn’t enforced – mandate MFA for all accounts.
• A known vulnerability wasn’t patched – improve vulnerability management program.

 

Final Thoughts

Security incidents will happen, but their impact can be greatly reduced with the right processes, tools, and discipline. By following a structured approach like the one outlined above, you can protect your organization, maintain trust, and continuously improve your security posture.

Stay proactive. Stay prepared. Incident response is not just a technical task it's a business-critical capability.

How to schedule Palo Alto Firewall config backups

 How to schedule daily config backups for Palo Alto Firewall

Login to the Palo Alto Firewall Web UI.

Navigate to Device > Setup > Operations.

Under the Configuration Management section:

 Click on Export named configuration snapshot to export a saved config.

    Or click on Export running configuration to export the current running config.

Method 2: Export Config Backup via CLI

sameer@mypanoramalin01> scp export configuration from running-config.xml to fwsftpuser@10.0.0.1:backup/
fwsftpuser@10.0.0.1's password:

running-config.xml      

[root@mypanoramalin01]# ls -lrt

total 224
-rw-r--r--. 1 fwsftpuser sftpusers 228436 Jul 22 12:52 running-config.xml

Use ingress to route web traffic to your Pods via services

 Basics:

The Purpose of a Service in Kubernetes and How It Differs from Ingress

In Kubernetes, a Service is used as an abstraction layer (load balancer) that has a set of pods in the backend and provides a stable endpoint for accessing them. The primary purpose of a service is to enable communication between different components within a Kubernetes cluster. A service allows other pods or external applications to interact with the pods in the backend, regardless of the pod’s individual IP addresses, which can change over time. By defining a service, you ensure that users or other services can consistently access a set of pods, providing load balancing and service discovery capabilities.

A Service in Kubernetes usually takes one of several forms, including ClusterIP (for internal access within the cluster), NodePort (exposes the service on a specific port on each node), and LoadBalancer (exposes the service externally via a load balancer). Services are essentially network resources that allow you to abstract the complexity of individual pods and ensure reliable communication.

Now an Ingress is a higher-level abstraction for managing external access to services in the cluster. While services help direct traffic within the cluster, Ingress defines how external HTTP(S) traffic should reach the right service based on defined rules. For example, an Ingress can direct traffic based on the URL or host, such as routing `shaiksameer.com/onlinecart` to one service and `shaiksameer.com/video` to another, making it a powerful tool for routing external traffic to internal services.

So services will route internal/Node traffic to Pods and Ingress will route external http/https traffic to services

Now, imagine we have two services that are each pointing to two different running pods. For instance, one service could point to an online shopping cart application running in one pod, while another service points to a video streaming application running in another pod. These services make it possible for traffic to be sent to the right application, with each service forwarding requests to its respective pods. However, the challenge comes when we want to expose these services to the outside world and manage how traffic is directed to them based on specific paths in the URL.

controlplane ~ ➜  k get svc -n web-app 
NAME                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
default-http-backend   ClusterIP   10.109.20.37     <none>        80/TCP     20m
video-service          ClusterIP   10.107.56.221    <none>        8080/TCP   20m
onlinecart-service     ClusterIP   10.102.149.138   <none>        8080/TCP   20m

In this scenario, we can use an Ingress Controller to manage external traffic routing. Instead of directly exposing the services via NodePorts or LoadBalancers, we can configure an Ingress resource to route traffic based on URL paths. For example, requests coming to `shaiksameer.com/onlinecart` could be routed to the service that handles the online shopping cart pod, while requests to `shaiksameer.com/video` would be directed to the service serving the video pod.

controlplane ~ ➜  k describe svc onlinecart-service -n web-app 
Name:                     onlinecart-service
Namespace:                web-app
Labels:                   <none>
Annotations:              <none>
Selector:                 app=webapp-onlinecart
Type:                     ClusterIP
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.102.149.138
IPs:                      10.102.149.138
Port:                     <unset>  8080/TCP
TargetPort:               8080/TCP
Endpoints:                10.244.0.4:8080
Session Affinity:         None
Internal Traffic Policy:  Cluster
Events:                   <none>

To achieve this, we’ll first create an Ingress Controller, which will act as the entry point for incoming HTTP(S) traffic. The Ingress Controller will inspect the incoming request and, based on predefined rules, forward it to the correct service. These rules will use the URL path to make decisions, ensuring that traffic for `/onlinecart` goes to one service and traffic for `/video` goes to another. Once the traffic reaches the correct service, that service will then forward the request to the appropriate pod, ensuring the right application handles the request.

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: test-ingress

  annotations:

    nginx.ingress.kubernetes.io/rewrite-target: /

spec:

  ingressClassName: nginx-example

  rules:

  - http:

      paths:

      - path: /onlinecart

        pathType: Prefix

        backend:

          service:

            name: onlinecart-service

            port:

              number: 8080

      - path: /watch

        pathType: Prefix

        backend:

          service:

            name: video-service

            port:

              number: 8080

By using an Ingress, you can manage multiple services with a single external endpoint, making it easier to scale and maintain your Kubernetes applications. This setup also allows you to implement advanced routing logic, such as load balancing, SSL termination, and path-based routing, all of which are essential for managing complex, distributed applications efficiently in Kubernetes.

controlplane ~  k replace -f ingress.yml -n web-app 
ingress.networking.k8s.io/test-ingress replaced