diff --git a/SWE-681-001-CaseStudyies/Sarvagod-Case Study-CVE-2024-47575.md b/SWE-681-001-CaseStudyies/Sarvagod-Case Study-CVE-2024-47575.md
new file mode 100644
index 0000000..ba92dbd
--- /dev/null
+++ b/SWE-681-001-CaseStudyies/Sarvagod-Case Study-CVE-2024-47575.md	
@@ -0,0 +1,548 @@
+# MISSING AUTHENTICATION IN FORTIMANAGER - CVE-2024-47575
+
+### Introduction
+
+Centralized network management platforms serve as critical infrastructure in enterprise environments, providing unified control over distributed security devices. The compromise of such platforms can cascade across entire network architectures, affecting hundreds or thousands of managed endpoints. Authentication failures at this level represent a fundamental breakdown in security architecture that can expose organizations to severe risk.
+
+Missing authentication for critical functions is classified as CWE-306 and consistently appears among the most impactful software vulnerabilities. This weakness enables unauthorized actors to execute privileged operations without establishing their identity, effectively bypassing the most basic security control. In 2024, this vulnerability class manifested in Fortinet FortiManager, a widely deployed centralized management solution for FortiGate security appliances. Beginning in June 2024, threat actors exploited CVE-2024-47575 as a zero-day vulnerability, compromising over 50 organizations before public disclosure in October 2024.
+
+This case study examines the technical implementation flaw in FortiManager's device registration mechanism, analyzes the exploitation methodology employed by the UNC5820 threat group, evaluates the implemented remediation, and establishes systematic prevention strategies applicable to network management systems and privileged access controls more broadly.
+
+### Software
+
+**Name**: Fortinet FortiManager
+
+**Language**: C
+
+**URL**: https://www.fortinet.com/products/management/fortimanager
+
+*Note: FortiManager is proprietary commercial software. While source code is not publicly available, the vulnerability has been thoroughly analyzed through binary reverse engineering, vendor advisories, and peer-reviewed security research. The architectural patterns and remediation strategies discussed apply broadly to network management platforms regardless of implementation language.*
+
+### Weakness
+
+**CWE-306: Missing Authentication for Critical Function**
+
+This weakness occurs when code performs privileged operations without first verifying the requester's identity. It's the digital equivalent of a secure building that checks IDs at the front desk but leaves the server room door unlocked.
+
+Critical functions that require authentication include device registration, administrative commands, configuration changes, and access to sensitive data. When authentication is missing, attackers don't need to crack passwords or exploit complex bugs—they simply connect and issue commands.
+
+In management systems, critical functions typically include:
+- Device registration and enrollment
+- Administrative command execution
+- Configuration modification
+- Credential and secret access
+- System-level operations
+
+### Vulnerability
+
+**CVE-2024-47575**
+
+FortiManager centralizes the management of FortiGate firewalls across enterprise networks. Rather than configuring each firewall individually, administrators manage everything from one console. This efficiency creates risk, compromise the manager, potentially compromise everything it controls.
+
+The vulnerability exists in fgfmsd, the daemon handling communication between FortiManager and FortiGate devices. This service listens on TCP port 541 using Fortinet's proprietary FGFM protocol. When a FortiGate wants to register or send management traffic, it connects to this port.
+
+The problem: fgfmsd accepted device registrations without verifying those devices were authorized. It checked that devices had valid Fortinet certificates but not whether those specific devices should be connecting to this specific FortiManager.
+
+Researchers reverse-engineering the binary compared vulnerable version 7.6.0 against patched version 7.6.1. They found the vulnerable version missing a critical authorization check. When a device sent a registration request like this:
+
+The registration request structure follows this format:
+
+```
+request=auth
+serialno=FGT-XXXXXXXXXXXX
+user=
+passwd=
+mgmtport=443
+keepalive_interval=120
+chan_window_sz=32768
+sock_timeout=360
+mgmtid=[UUID]
+```
+
+Analysis of this request structure reveals empty authentication fields (`user=` and `passwd=`). In the vulnerable implementation, the fgfmsd daemon would accept and process this request despite the absence of credentials. The daemon verified the TLS certificate presented during the connection handshake but did not verify whether the specific device identified by the certificate was authorized to register with this particular FortiManager instance.
+
+The vulnerable execution flow operated as follows:
+
+1. Accept incoming TLS connection on TCP port 541
+2. Verify TLS certificate chain is valid (cryptographically)
+3. Parse device registration request parameters
+4. Extract serial number and identifying information
+5. Insert device record into management database
+6. Grant management interface access privileges
+7. Enable configuration synchronization
+
+The critical omission occurs between steps 3 and 4. No authorization verification step exists to confirm whether this specific device, identified by its serial number, has been approved for management by an administrator. The system defaulted to permissive behavior, automatically accepting any device that could complete the TLS handshake with a valid certificate.
+
+Consider a conceptual example demonstrating this weakness pattern written in Python:
+
+```
+class DeviceManagementService:
+    def register_new_device(self, device_info):
+        """Register a new device into the system"""
+        # Extract information about device
+        device_serial_number = device_info['serial']
+        ip_address = device_info['ip']
+        certificate = device_info['certificate']
+        
+        # VULNERABILITY: No data verification, authentication or authorization check
+        # Function proceeds to perform critical operation
+        device_id = self.database.insert_device(device_serial_number, ip_address)
+        self.grant_management_privileges(device_id)
+        self.enable_configuration_access(device_id)
+        
+        return {"status": "registered", "device_id": device_id}
+```
+
+The vulnerability in the above code is the absence of any verification step. The function accepts input parameters and immediately performs critical operations such as database modification and privilege assignment, without establishing whether the request originates from an authorized source.
+
+
+### Exploit
+
+UNC5820 exploited this as a zero-day starting June 27, 2024. They compromised at least 50 FortiManager systems before Fortinet's October disclosure, a four-month window.
+
+The exploitation methodology proceeded through the following stages:
+
+**Phase 1: Certificate Acquisition**
+
+FGFM uses TLS certificates for device identification. Every FortiGate ships with a certificate in its firmware. Attackers obtained one—possibly from old hardware, publicly available firmware, or a compromised device. Since certificates weren't unique per device, one worked for multiple attacks.
+
+- Extraction from publicly available firmware images
+- Purchase of end-of-life or decommissioned hardware
+- Compromise of existing FortiGate deployments
+- Analysis of publicly exposed devices
+
+Once obtained, a single certificate could be reused across multiple exploitation attempts, as the vulnerable implementation did not verify certificate uniqueness or revocation status.
+
+**Phase 2: Network Reconnaissance and Targeting**
+
+UNC5820 identified vulnerable FortiManager instances through internet-wide scanning for services listening on TCP port 541. The threat actors likely prioritized targets based on:
+
+- Geographic location
+- Network ownership (MSPs managing multiple clients represented high-value targets)
+- Organizational sector
+- Exposure configuration
+
+**Phase 3: Unauthorized Registration**
+
+With valid certificates and identified targets, UNC5820 initiated FGFM connections to vulnerable FortiManager instances. The attack leveraged the missing authentication control to register a threat-actor-controlled device without administrative approval.
+
+The registration request transmitted by the attacker:
+
+```
+request=auth
+serialno=FMG-VM0000000000
+user=
+passwd=
+mgmtport=443
+keepalive_interval=120
+chan_window_sz=32768
+sock_timeout=360
+```
+
+The vulnerable fgfmsd daemon processed this request without verifying the serial number appeared in the authorized device list. The empty credential fields were not validated as authentication failures. The system automatically granted management privileges to the newly registered device.
+
+**Phase 4: Command Execution and Privilege Escalation**
+
+Following successful registration, UNC5820 leveraged privileged management commands available to registered devices. Binary analysis identified several command handlers of particular interest to attackers:
+
+The `put_json_cmd` handler accepted JSON-formatted command structures and parsed them for execution without verifying the requesting device's authorization for the specific command. This created an opportunity for command injection attacks.
+
+The `get_connect_tcp` handler enabled registered devices to establish TCP connections through the FortiManager, potentially including shell access with elevated privileges.
+
+**Phase 5: Steal Data**
+
+UNC5820's primary objective appeared to be intelligence collection rather than disruptive effects. The threat actors deployed an automated script that:
+
+1. Authenticated as a registered device
+2. Executed commands to enumerate managed FortiGate configurations
+3. Staged sensitive data in compressed archives (typically at `/tmp/.tm`)
+4. Exfiltrated data to threat-actor-controlled infrastructure
+
+The exfiltrated data included:
+- Complete configuration files for all managed FortiGate devices
+- Network topology and IP addressing schemes
+- Administrative credentials (FortiOS256-hashed passwords)
+- VPN pre-shared keys and certificates
+- Authentication server secrets (RADIUS, TACACS+)
+- SNMP community strings
+- Routing protocol authentication credentials
+- Wireless network encryption keys
+
+Investigators identified these attacker IP addresses:
+
+```
+Primary Command and Control IPs:
+45.32.41.202
+104.238.141.143
+158.247.199.37
+45.32.63.2
+80.66.196.199
+195.85.114.78
+172.232.167.68
+```
+
+Temporal analysis established two distinct waves of exploitation activity:
+
+**Wave 1**: June 27, 2024 - Initial reconnaissance and data collection operations  
+**Wave 2**: September 23, 2024 - Follow-on collection with similar tactics
+
+Both showed the same pattern, archive creation followed by outbound data transfer. Investigators found no evidence of persistence mechanisms, database tampering, or lateral movement to managed devices. UNC5820 appears focused on intelligence collection.
+
+### Fix
+
+Fortinet's remediation for CVE-2024-47575 implemented the authentication and authorization controls that were absent in the vulnerable implementation. The fix operates at multiple levels: code-level permission checks, configuration-level security controls, and architectural defense-in-depth measures.
+
+
+A secure implementation requires explicit authentication and authorization gates:
+
+```
+class DeviceManagementService:
+    def register_new_device(self, device_info, request_context):
+        """Register a new device with authentication and authorization"""
+        device_serial_number = device_info['serial']
+        ip_address = device_info['ip']
+        certificate = device_info['certificate']
+        
+        # Step 1: Authenticate the request source
+        if not self.authenticate_certificate(certificate):
+            self.log_security_event("INVALID_CERT", device_serial_number, ip_address)
+            raise AuthenticationError("Certificate validation failed")
+        
+        # Step 2: Verify certificate matches claimed identity
+        cert_serial = self.extract_serial_from_cert(certificate)
+        if cert_serial != device_serial_number:
+            self.log_security_event("SERIAL_MISMATCH", device_serial_number, cert_serial)
+            raise AuthenticationError("Serial number does not match certificate")
+        
+        # Step 3: Check authorization - is this device approved?
+        if not self.is_authorized_device(device_serial_number):
+            self.log_security_event("UNAUTHORIZED_DEVICE", device_serial_number, ip_address)
+            raise AuthorizationError("Device not in authorized list")
+        
+        # Step 4: Validate source network location
+        if not self.validate_source_network(device_serial_number, ip_address):
+            self.log_security_event("INVALID_SOURCE", device_serial_number, ip_address)
+            raise AuthorizationError("Request from unexpected network location")
+        
+        # Only after all checks pass do we execute privileged operations
+        device_id = self.database.insert_device(device_serial_number, ip_address)
+        self.grant_management_privileges(device_id)
+        self.enable_configuration_access(device_id)
+        self.log_audit_event("DEVICE_REGISTERED", device_serial_number, request_context)
+        
+        return {"status": "registered", "device_id": device_id}
+```
+
+The major difference is the enforcement of authentication and authorization as mandatory preconditions. Each security check acts as a gate that must be successfully passed before proceeding to the next step, and failure at any stage immediately halts execution.
+
+
+### Prevention
+
+CVE-2024-47575 demonstrates that missing authentication controls represent a fundamental architectural failure with severe security implications. Developers can prevent this class of vulnerability through systematic approaches that make authentication enforcement mandatory, visible, and testable. 
+
+**Implement Mandatory Authentication**
+
+Every privileged function must enforce authentication as a mandatory precondition. This requirement should be architecturally enforced, not left to developer discretion. Rather than requiring each function to implement authentication checks, establish middleware or decorator patterns that enforce authentication automatically:
+
+```python
+from functools import wraps
+
+def require_authentication(func):
+    """Decorator enforcing authentication for privileged functions"""
+    @wraps(func)
+    def wrapper(self, request, *args, **kwargs):
+        # Authentication check is mandatory - function cannot execute without it
+        if not request.session.is_authenticated():
+            self.security_log.warning(
+                "Authentication required",
+                function=func.__name__,
+                source=request.source_ip
+            )
+            raise AuthenticationError("Authentication required for this operation")
+        
+        return func(self, request, *args, **kwargs)
+    return wrapper
+
+class DeviceManagementAPI:
+    @require_authentication
+    def register_device(self, request):
+        """Device registration requires authentication"""
+        # By the time execution reaches here, authentication is verified
+        return self._process_registration(request.device_info)
+```
+
+This pattern makes authentication enforcement visible in the code signature. Removing the decorator creates an obvious code review finding.
+
+**Separate Authentication from Authorization**
+
+Authentication (verifying identity) is distinct from authorization (verifying permissions). Both checks are required for secure access control. Implement a dual-gate pattern that enforces both authentication and specific permission requirements:
+
+```python
+def require_permission(permission_name):
+    """Decorator enforcing specific permission requirements"""
+    def decorator(func):
+        @wraps(func)
+        def wrapper(self, request, *args, **kwargs):
+            # First gate: Authentication
+            if not request.session.is_authenticated():
+                raise AuthenticationError("Not authenticated")
+            
+            # Second gate: Authorization for specific operation
+            if not request.session.has_permission(permission_name):
+                self.security_log.warning(
+                    "Authorization denied",
+                    user=request.session.user_id,
+                    permission=permission_name,
+                    function=func.__name__
+                )
+                raise AuthorizationError(
+                    f"Permission '{permission_name}' required for this operation"
+                )
+            
+            return func(self, request, *args, **kwargs)
+        return wrapper
+    return decorator
+
+class DeviceManagementAPI:
+    @require_authentication
+    @require_permission("device:register")
+    def register_device(self, request):
+        """Registration requires both authentication and specific permission"""
+        return self._process_registration(request.device_info)
+```
+
+This dual-gate pattern ensures that even authenticated users can only perform operations they are explicitly authorized for.
+
+**Default to Deny**
+
+Security-critical systems should default to denying access, only granting it when explicit authorization is verified. The FortiManager vulnerability stemmed from defaulting to permissive behavior—automatically accepting device registrations without explicit approval:
+
+```python
+class DeviceAuthorizationService:
+    def __init__(self, database):
+        self.db = database
+        
+    def is_device_authorized(self, device_serial_number):
+        """Check if device is in explicit authorization list"""
+        # Query returns None if device not found
+        authorized_device = self.db.query(
+            "SELECT * FROM authorized_devices WHERE device_serial_number = %s",
+            (device_serial_number,)
+        )
+        
+        # Default to deny - only return True if explicitly authorized
+        if authorized_device is None:
+            self.log_authorization_check(device_serial_number, authorized=False)
+            return False
+        
+        # Verify authorization is still active (not expired)
+        if authorized_device.expiration_date < datetime.now():
+            self.log_authorization_check(device_serial_number, authorized=False, reason="expired")
+            return False
+        
+        self.log_authorization_check(device_serial_number, authorized=True)
+        return True
+```
+
+This implementation returns False (deny) unless positive authorization is found. Authorization is never implied or assumed.
+
+**Implement Defense in Depth**
+
+Authentication should occur at multiple layers. Fortinet's fix demonstrates this by combining application-layer permission checks with network-layer access controls and certificate-based authentication:
+
+**Implementation Strategy: Multi-Layer Verification**
+
+```python
+class SecureDeviceRegistrationService:
+    def register_device(self, request):
+        """Multi-layer authentication and authorization"""
+        
+        # Layer 1: Network-layer validation
+        if not self.network_policy.is_source_allowed(request.source_ip):
+            raise SecurityError("Connection from unauthorized network")
+        
+        # Layer 2: Certificate authentication
+        if not self.verify_certificate_chain(request.certificate):
+            raise AuthenticationError("Invalid certificate chain")
+        
+        cert_serial = self.extract_serial_from_certificate(request.certificate)
+        
+        # Layer 3: Certificate-to-identity binding
+        if cert_serial != request.device_serial:
+            raise AuthenticationError("Certificate does not match claimed identity")
+        
+        # Layer 4: Explicit authorization check
+        if not self.authorization_service.is_device_authorized(request.device_serial):
+            raise AuthorizationError("Device not in authorized list")
+        
+        # Layer 5: Pre-shared secret verification
+        if not self.verify_psk(request.device_serial, request.psk):
+            raise AuthenticationError("Invalid pre-shared key")
+        
+        # All layers passed - proceed with registration
+        return self._execute_registration(request)
+```
+
+An attacker must bypass all five layers to succeed. Failure at any layer immediately halts execution.
+
+**Design Authentication Before Implementation**
+
+Authentication requirements should be specified during design phase, not added during implementation or after deployment. This prevents authentication from being overlooked or deferred.
+
+Before implementing any privileged functionality, document:
+
+1. **Identity Requirements**: What information establishes identity?
+2. **Authentication Mechanism**: How is identity verified?
+3. **Authorization Model**: What permissions are required?
+4. **Failure Handling**: What occurs when authentication fails?
+5. **Audit Requirements**: What events are logged?
+
+Example security requirements document:
+
+```
+Feature: Device Registration API
+Security Classification: Critical
+
+Authentication Requirements:
+- Device identity established via X.509 certificate
+- Certificate must chain to organization CA
+- Certificate serial number must match device serial number
+- Device serial must exist in authorized device database
+- Source IP must match authorized network ranges
+
+Authorization Requirements:
+- Device must have "device:register" permission
+- Registration requires administrator pre-approval
+- Temporary registrations expire after 24 hours
+
+Failure Handling:
+- Authentication failures return 401 Unauthorized
+- Authorization failures return 403 Forbidden
+- All failures logged as security events
+- Failed attempts increment rate limit counter
+
+Audit Requirements:
+- Log all registration attempts (success and failure)
+- Include: timestamp, device serial, source IP, outcome
+- Alert on multiple failures from same source
+```
+
+These requirements drive test case development and code review criteria.
+
+**Implement Comprehensive Testing**
+
+Testing must verify that authentication failures correctly prevent access. This requires negative test cases that attempt operations without credentials.
+
+```python
+class TestDeviceRegistration:
+    def test_registration_requires_authentication(self):
+        """Verify registration fails without authentication"""
+        request = RegistrationRequest(
+            device_serial="TEST-123456",
+            certificate=None,  # No certificate provided
+            psk=None
+        )
+        
+        with pytest.raises(AuthenticationError):
+            self.service.register_device(request)
+    
+    def test_registration_requires_authorization(self):
+        """Verify registration fails without authorization"""
+        request = RegistrationRequest(
+            device_serial="UNAUTHORIZED-DEVICE",
+            certificate=self.valid_test_certificate,
+            psk=self.valid_test_psk
+        )
+        
+        # Device has valid credentials but is not authorized
+        with pytest.raises(AuthorizationError):
+            self.service.register_device(request)
+    
+    def test_certificate_serial_must_match_claimed_serial(self):
+        """Verify registration fails if certificate doesn't match identity"""
+        # Certificate is for device A, but claiming to be device B
+        request = RegistrationRequest(
+            device_serial="DEVICE-B",
+            certificate=self.device_a_certificate,
+            psk=self.valid_test_psk
+        )
+        
+        with pytest.raises(AuthenticationError):
+            self.service.register_device(request)
+```
+
+These tests verify that authentication controls function correctly by confirming unauthorized attempts fail.
+
+**Monitor and Alert on Authentication Anomalies**
+
+Even with correct authentication implementation, monitoring provides detection of exploitation attempts and system misuse.
+
+```python
+class SecurityMonitoringService:
+    def monitor_authentication_events(self):
+        """Monitor for suspicious authentication patterns"""
+        
+        # Pattern 1: Multiple failures from same source
+        failed_attempts = self.get_recent_failures(
+            time_window=timedelta(minutes=15)
+        )
+        for source_ip, count in failed_attempts.items():
+            if count > 5:
+                self.alert("Multiple authentication failures", 
+                          source_ip=source_ip, 
+                          count=count)
+        
+        # Pattern 2: Authentication from unexpected location
+        auth_events = self.get_recent_authentications(
+            time_window=timedelta(hours=1)
+        )
+        for event in auth_events:
+            if not self.is_expected_location(event.device_id, event.source_ip):
+                self.alert("Authentication from unexpected location",
+                          device_id=event.device_id,
+                          source_ip=event.source_ip)
+        
+        # Pattern 3: New device authentication attempts
+        new_device_attempts = self.get_new_device_attempts(
+            time_window=timedelta(hours=24)
+        )
+        for attempt in new_device_attempts:
+            if not attempt.is_authorized:
+                self.alert("Unauthorized device attempted registration",
+                          device_serial=attempt.device_serial,
+                          source_ip=attempt.source_ip)
+```
+
+These monitoring patterns would have detected the UNC5820 exploitation attempts during the four-month window before disclosure.
+
+**Use Static Analysis and Code Review**
+Static analysis tools that can trace authentication requirements through code paths are effective in identifying places where authentication may be missing. Code review processes should explicitly verify that all privileged operations have authentication checks. Security architecture reviews during the design phase ensure authentication is planned before implementation begins.
+
+### Conclusion
+
+CVE-2024-47575 shows what happens when authentication is missing from critical code. FortiManager's device registration accepted any connection with a valid certificate, never checking if that device was authorized. UNC5820 exploited this to compromise 50+ organizations over four months, stealing credentials and configurations for thousands of managed firewalls.
+
+The technical root cause, absent authorization verification in the device registration workflow, represents a fundamental architectural failure rather than a subtle implementation error. The fgfmsd daemon processed registration requests from any source presenting valid certificates without verifying those devices were authorized to join the management domain. This permissive-by-default behavior violated core security principles and enabled trivial exploitation.
+
+The fix added what should have been there from the start: permission checks, deny-by-default configuration, network access controls, and custom certificate support. For developers, the lesson is clear: design authentication first, use enforcement patterns that make its absence obvious, test that unauthorized access fails, and monitor for suspicious patterns. Authentication isn't an implementation detail, it's a foundational requirement.
+
+### References
+
+Fortinet PSIRT Advisory FG-IR-24-423: https://www.fortiguard.com/psirt/FG-IR-24-423  
+CVE-2024-47575 Entry: https://www.cve.org/CVERecord?id=CVE-2024-47575  
+CWE-306 Entry: https://cwe.mitre.org/data/definitions/306.html  
+NVD Vulnerability Report: https://nvd.nist.gov/vuln/detail/CVE-2024-47575  
+CISA Known Exploited Vulnerabilities: https://www.cisa.gov/known-exploited-vulnerabilities-catalog  
+Mandiant: Investigating FortiManager Zero-Day Exploitation: https://cloud.google.com/blog/topics/threat-intelligence/fortimanager-zero-day-exploitation-cve-2024-47575  
+Rapid7: FortiManager CVE-2024-47575 Zero-Day Attacks: https://www.rapid7.com/blog/post/2024/10/23/etr-fortinet-fortimanager-cve-2024-47575-exploited-in-zero-day-attacks/  
+watchTowr Labs: FortiJump Technical Analysis: https://labs.watchtowr.com/hop-skip-fortijump-fortijumphigher-cve-2024-23113-cve-2024-47575/  
+OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
+
+### Contributions
+
+This case study was developed as part of academic research on secure coding practices and authentication architecture in network management systems.
+
+Originally created by Vivek Sarvagod
+
+(C) 2025 The MITRE Corporation. All rights reserved.<br>
+This work is openly licensed under <a href="https://creativecommons.org/licenses/by/4.0/">CC-BY-4.0</a>