Introduction
IoT devices rarely operate in isolation - they rely on cloud platforms for data storage, processing, and synchronization. Understanding cloud and API forensics is essential for comprehensive IoT investigations, as the cloud often contains more complete and historical data than the devices themselves.
By the end of this part, you will understand IoT cloud platform architecture, learn to analyze API logs and requests, master data synchronization forensics, and know how to acquire evidence from major cloud providers.
IoT Cloud Platforms
IoT cloud platforms provide the infrastructure for device management, data storage, analytics, and application development. Understanding these platforms is crucial for forensic investigators.
Major IoT Cloud Platforms
AWS IoT
Amazon Web Services IoT Core, IoT Analytics, IoT Events. Used by many commercial IoT products. Data stored in AWS infrastructure.
Azure IoT
Microsoft Azure IoT Hub, IoT Central. Common in enterprise and industrial IoT. Integration with Microsoft ecosystem.
Google Cloud IoT
Google Cloud IoT Core (deprecated), Pub/Sub, BigQuery. Used by Nest and partner devices. Strong analytics capabilities.
Vendor-Specific Clouds
Samsung SmartThings, Tuya Smart, Philips Hue, iRobot cloud. Each has unique APIs and data formats.
Cloud Evidence Sources
| Evidence Type | Description | Forensic Value |
|---|---|---|
| Device Telemetry | Sensor data, state changes, metrics | Historical device activity, environmental conditions |
| Connection Logs | Device connect/disconnect events | Device online periods, network issues |
| Command History | Commands sent to devices | User actions, automation triggers |
| User Activity | Account actions, settings changes | Configuration modifications, access patterns |
| API Access Logs | API calls, authentication events | Third-party access, unauthorized attempts |
| Audit Trails | Administrative actions, policy changes | Security events, compliance records |
API Log Analysis
Application Programming Interfaces (APIs) are the communication backbone of IoT systems. API logs provide detailed records of interactions between devices, applications, and cloud services.
Most IoT platforms use REST APIs with HTTP methods (GET, POST, PUT, DELETE). Each API call generates logs including: endpoint URL, HTTP method, request/response bodies, timestamps, authentication tokens, source IP addresses, and response codes.
Common IoT API Patterns
# Device State Query
GET /devices/{deviceId}/state
Authorization: Bearer {token}
# Send Command to Device
POST /devices/{deviceId}/commands
Content-Type: application/json
{"command": "turn_on", "parameters": {"brightness": 100}}
# Get Historical Data
GET /devices/{deviceId}/telemetry?start=2025-01-01&end=2025-01-31
# Webhook Notification
POST /webhooks/events
{"deviceId": "abc123", "event": "motion_detected", "timestamp": "2025-01-15T14:30:00Z"}
API Log Analysis Techniques
- Timeline Reconstruction: Sequence API calls by timestamp to understand event order
- User Attribution: Link API calls to specific users via authentication tokens
- Anomaly Detection: Identify unusual patterns like excessive requests or off-hours activity
- Command Analysis: Extract commands sent to devices and their effects
- Error Analysis: Review failed requests for unauthorized access attempts
- Third-Party Access: Identify OAuth tokens and integrations
{
"timestamp": "2025-01-15T14:32:47.123Z",
"requestId": "req-abc123-def456",
"method": "POST",
"endpoint": "/devices/smart-lock-001/commands",
"userId": "user@example.com",
"clientIp": "103.152.xxx.xxx",
"userAgent": "SmartHome-App/3.2.1 (Android)",
"requestBody": {"command": "unlock"},
"responseCode": 200,
"responseTime": 245,
"deviceResponse": {"status": "unlocked", "method": "app"}
}
API rate limiting responses (HTTP 429) can indicate automated attacks, scraping attempts, or compromised accounts being used for bulk operations. Review rate limit violations as potential indicators of malicious activity.
Data Synchronization Analysis
IoT devices continuously synchronize data between local storage, mobile apps, and cloud services. Understanding synchronization patterns is crucial for identifying what data exists where and when it was updated.
Synchronization Forensic Artifacts
| Artifact | Location | Information |
|---|---|---|
| Sync Timestamps | Device, App, Cloud | Last sync time, sync frequency, sync delays |
| Conflict Records | Cloud | Multiple simultaneous updates, resolution decisions |
| Delta Updates | App databases | Incremental changes, what was modified when |
| Offline Queues | App local storage | Commands queued when device/network unavailable |
| Sync Errors | App logs, Cloud logs | Failed syncs, authentication issues, data conflicts |
Device Shadow / Digital Twin
Many IoT platforms use "device shadows" or "digital twins" - cloud representations of device state that persist even when devices are offline.
{
"state": {
"desired": {
"temperature": 22,
"mode": "auto"
},
"reported": {
"temperature": 24,
"mode": "cooling",
"humidity": 45
}
},
"metadata": {
"desired": {
"temperature": {"timestamp": 1705329600}
},
"reported": {
"temperature": {"timestamp": 1705329650}
}
},
"version": 42
}
Device shadows show both "desired" state (what users/apps requested) and "reported" state (what device actually did). Comparing these reveals commands that were not executed, delayed execution, and discrepancies that may indicate tampering or malfunction.
Cloud Data Acquisition
Acquiring data from IoT cloud platforms requires understanding legal processes, available methods, and data retention policies of each provider.
Acquisition Methods
User Data Export
Use account owner's access to export data via platform settings or data portability features (GDPR compliance tools).
API-Based Extraction
Use platform APIs with authenticated access to programmatically extract historical data and logs.
Legal Process
Submit formal legal requests (subpoenas, court orders, MLATs) to cloud providers for preserved data.
Admin Console Access
For enterprise IoT, access administrative dashboards to export audit logs and device data.
Legal Requests to Cloud Providers
| Provider | Legal Portal | Data Available |
|---|---|---|
| Amazon (Alexa, Ring, AWS) | Amazon Law Enforcement Portal | Account info, voice recordings, device logs, content |
| Google (Nest, Home) | Google LERS (Law Enforcement Request System) | Account data, activity logs, stored content |
| Microsoft (Azure IoT) | Microsoft Law Enforcement Portal | Account info, service logs, stored data |
| Apple (HomeKit) | Apple Law Enforcement Support | Limited due to E2E encryption - account info, purchase history |
Most IoT cloud platforms store data in servers outside India. Acquiring this data requires Mutual Legal Assistance Treaties (MLATs), direct legal requests under local laws (like US SCA), or cooperation agreements. Processing can take months. For urgent matters, emergency disclosure requests may be possible for imminent threats to life.
MQTT Protocol Forensics
MQTT (Message Queuing Telemetry Transport) is the most common protocol for IoT communication. Understanding MQTT is essential for analyzing IoT network traffic.
MQTT Basics
- Publish/Subscribe Model: Devices publish messages to topics; subscribers receive messages on subscribed topics
- Broker: Central server that routes messages between publishers and subscribers
- Topics: Hierarchical naming (e.g., home/livingroom/temperature)
- QoS Levels: 0 (at most once), 1 (at least once), 2 (exactly once)
- Retained Messages: Last message on topic stored by broker
# Smart Home Topic Hierarchy
home/+/temperature # Wildcard for any room
home/livingroom/lights/1 # Specific light control
home/security/motion/# # All motion sensors
# Message Payload Examples
Topic: home/livingroom/temperature
Payload: {"value": 24.5, "unit": "celsius", "timestamp": 1705329600}
Topic: home/security/motion/frontdoor
Payload: {"detected": true, "confidence": 0.95}
MQTT Forensic Evidence
- Connection Logs: Client IDs, connection times, authentication status
- Subscription Records: What topics each client subscribes to
- Message Logs: Published messages with timestamps and topics
- Retained Messages: Current state messages stored by broker
- Last Will Messages: Messages sent when client disconnects unexpectedly
While MQTT can use TLS encryption, many IoT implementations use unencrypted MQTT (port 1883) or have weak authentication. Network captures may reveal plaintext device communications. Always check for MQTT over TLS (port 8883) which encrypts the transport layer.
Section 63 BSA for Cloud Evidence
Preparing Section 63 BSA certificates for cloud-based IoT evidence requires special considerations due to the distributed nature of the data and involvement of third-party service providers.
Certificate Requirements for Cloud Evidence
- Identify the Computer System: Describe the cloud platform, data centers, and any local devices involved in data processing
- Establish Regular Use: Document how the IoT system was used regularly for its intended purpose
- Information Feed Process: Explain how data flows from devices to cloud, including any transformations
- System Functionality: Certify that cloud systems were operating properly during relevant period
- Data Integrity: Include hash values for acquired data, describe acquisition method
IoT forensics may require multiple Section 63 certificates: one from the device owner/operator for local device data, one from the mobile app developer for app data, and potentially correspondence from the cloud provider about their system reliability. Courts may accept provider documentation in lieu of direct certification when access is limited.
- IoT cloud platforms (AWS IoT, Azure IoT, Google Cloud) store comprehensive device data, telemetry, and user activity
- API logs provide detailed records of commands, user actions, and system interactions with timestamps
- Device shadows/digital twins maintain cloud representation of device state even when offline
- Data synchronization creates artifacts across device, app, and cloud that can reveal timing and sequence of events
- Cloud data acquisition requires user exports, API extraction, or formal legal requests to providers
- Cross-border data storage complicates acquisition - MLATs may be required for foreign-stored data
- MQTT is the dominant IoT protocol - understanding topics, messages, and broker logs is essential
- Section 63 BSA certificates for cloud evidence require addressing distributed systems and third-party involvement