Update latest docs

Author: tradebot-elastic

docs/detections/prebuilt-rules/downloadable-packages/8-16-13/prebuilt-rule-8-16-13-attempt-to-establish-vscode-remote-tunnel.asciidoc

@@ -0,0 +1,127 @@
+[[prebuilt-rule-8-16-13-attempt-to-establish-vscode-remote-tunnel]]
+=== Attempt to Establish VScode Remote Tunnel
+
+Detects the execution of the VScode portable binary with the tunnel command line option indicating an attempt to establish a remote tunnel session to Github or a remote VScode instance.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* endgame-*
+* logs-crowdstrike.fdr*
+* logs-endpoint.events.process-*
+* logs-m365_defender.event-*
+* logs-sentinel_one_cloud_funnel.*
+* logs-system.security*
+* logs-windows.sysmon_operational-*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://badoption.eu/blog/2023/01/31/code_c2.html
+* https://code.visualstudio.com/docs/remote/tunnels
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Command and Control
+* Data Source: Elastic Endgame
+* Data Source: Elastic Defend
+* Data Source: Sysmon
+* Data Source: SentinelOne
+* Data Source: Microsoft Defender for Endpoint
+* Data Source: Windows Security Event Logs
+* Data Source: Crowdstrike
+* Resources: Investigation Guide
+
+*Version*: 109
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Attempt to Establish VScode Remote Tunnel*
+
+
+Visual Studio Code (VScode) offers a remote tunnel feature enabling developers to connect to remote environments seamlessly. While beneficial for legitimate remote development, adversaries can exploit this to establish unauthorized access or control over systems. The detection rule identifies suspicious use of VScode's tunnel command, focusing on specific command-line arguments and process behaviors, to flag potential misuse indicative of command and control activities.
+
+
+*Possible investigation steps*
+
+
+- Review the process details to confirm the presence of the "tunnel" argument in the command line, which indicates an attempt to establish a remote tunnel session.
+- Check the parent process name to ensure it is not "Code.exe" when the process name is "code-tunnel.exe" with the "status" argument, as this is an exception in the rule.
+- Investigate the origin of the process by examining the user account and machine from which the process was initiated to determine if it aligns with expected usage patterns.
+- Analyze network logs to identify any unusual or unauthorized connections to GitHub or remote VScode instances that may suggest malicious activity.
+- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context on the activity.
+- Assess the risk and impact by determining if the system or user account has been involved in previous suspicious activities or if there are any indicators of compromise.
+
+
+*False positive analysis*
+
+
+- Legitimate remote development activities using VScode's tunnel feature may trigger the rule. Users can create exceptions for known developer machines or specific user accounts frequently using this feature for authorized purposes.
+- Automated scripts or deployment tools that utilize VScode's remote tunnel for legitimate operations might be flagged. Consider excluding these processes by identifying their unique command-line arguments or parent processes.
+- Scheduled tasks or system maintenance activities that involve VScode's remote capabilities could be misidentified as threats. Review and whitelist these tasks by their specific execution times or associated service accounts.
+- Development environments that frequently update or test VScode extensions might inadvertently match the rule's criteria. Exclude these environments by setting up exceptions based on their network segments or IP addresses.
+- Training or demonstration sessions using VScode's remote features for educational purposes can be mistaken for suspicious activity. Implement exclusions for these sessions by tagging them with specific event identifiers or user roles.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious VScode processes identified by the detection rule to halt potential command and control activities.
+- Conduct a thorough review of system logs and process histories to identify any additional indicators of compromise or lateral movement attempts.
+- Reset credentials and access tokens associated with the affected system and any connected services to mitigate unauthorized access.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Implement network segmentation to limit the ability of similar threats to spread across the environment.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+process where host.os.type == "windows" and event.type == "start" and
+  process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and
+  not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Command and Control
+** ID: TA0011
+** Reference URL: https://attack.mitre.org/tactics/TA0011/
+* Technique:
+** Name: Remote Access Tools
+** ID: T1219
+** Reference URL: https://attack.mitre.org/techniques/T1219/

docs/detections/prebuilt-rules/downloadable-packages/8-16-13/prebuilt-rule-8-16-13-aws-s3-static-site-javascript-file-uploaded.asciidoc

@@ -0,0 +1,148 @@
+[[prebuilt-rule-8-16-13-aws-s3-static-site-javascript-file-uploaded]]
+=== AWS S3 Static Site JavaScript File Uploaded
+
+This rule detects when a JavaScript file is uploaded or accessed in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend.
+
+*Rule type*: esql
+
+*Rule indices*: None
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/
+* https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html
+* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html
+
+*Tags*: 
+
+* Domain: Cloud
+* Data Source: AWS
+* Data Source: Amazon Web Services
+* Data Source: AWS S3
+* Tactic: Impact
+* Use Case: Web Application Compromise
+* Use Case: Cloud Threat Detection
+* Resources: Investigation Guide
+
+*Version*: 1
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and Analysis*
+
+
+
+*Investigating AWS S3 Static Site JavaScript File Uploaded*
+
+
+An S3 `PutObject` action that targets a path like `static/js/` and uploads a `.js` file is a potential signal for web content modification. If done by an unexpected IAM user or outside of CI/CD workflows, it may indicate a compromise.
+
+
+*Possible Investigation Steps*
+
+
+- **Identify the Source User**: Check `aws.cloudtrail.user_identity.arn`, access key ID, and session type (`IAMUser`, `AssumedRole`, etc).
+- **Review File Content**: Use the S3 `GetObject` or CloudTrail `requestParameters` to inspect the uploaded file for signs of obfuscation or injection.
+- **Correlate to Other Events**: Review events from the same IAM user before and after the upload (e.g., `ListBuckets`, `GetCallerIdentity`, IAM activity).
+- **Look for Multiple Uploads**: Attackers may attempt to upload several files or modify multiple directories.
+
+
+*False Positive Analysis*
+
+
+- This behavior may be expected during app deployments. Look at:
+  - The `user_agent.original` to detect legitimate CI tools (like Terraform or GitHub Actions).
+  - Timing patterns—does this match a regular release window?
+  - The origin IP and device identity.
+
+
+*Response and Remediation*
+
+
+- **Revert Malicious Code**: Replace the uploaded JS file with a clean version and invalidate CloudFront cache if applicable.
+- **Revoke Access**: If compromise is confirmed, revoke the IAM credentials and disable the user.
+- **Audit IAM Policies**: Ensure that only deployment users can modify static site buckets.
+- **Enable Bucket Versioning**: This can allow for quick rollback and historical review.
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+from logs-aws.cloudtrail* metadata _id, _version, _index
+| where
+
+    // filter on CloudTrail logs for S3 PutObject actions
+    event.dataset == "aws.cloudtrail"
+    and event.provider == "s3.amazonaws.com"
+    and event.action in ("GetObject","PutObject")
+
+    // filter for IAM users, not federated identities
+    and aws.cloudtrail.user_identity.type in ("IAMUser", "AssumedRole")
+
+    // filter for S3 static site bucket paths from webpack or similar
+    and aws.cloudtrail.request_parameters LIKE "*static/js/*.js*"
+
+    // exclude common IaC tools and automation scripts
+    and not (
+        user_agent.original LIKE "*Terraform*"
+        or user_agent.original LIKE "*Ansible*"
+        or user_agent.original LIKE "*Pulumni*"
+    )
+
+// extract bucket and object details from request parameters
+| dissect aws.cloudtrail.request_parameters "%{{?bucket.name.key}=%{bucket.name}, %{?host.key}=%{bucket.host}, %{?bucket.object.location.key}=%{bucket.object.location}}"
+
+// filter for specific bucket and object structure
+| dissect bucket.object.location "%{}static/js/%{bucket.object}"
+
+// filter for JavaScript files
+| where ENDS_WITH(bucket.object, ".js")
+| keep
+    aws.cloudtrail.user_identity.arn,
+    aws.cloudtrail.user_identity.access_key_id,
+    aws.cloudtrail.user_identity.type,
+    aws.cloudtrail.request_parameters,
+    bucket.name,
+    bucket.object,
+    user_agent.original,
+    source.ip,
+    event.action,
+    @timestamp
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Impact
+** ID: TA0040
+** Reference URL: https://attack.mitre.org/tactics/TA0040/
+* Technique:
+** Name: Data Manipulation
+** ID: T1565
+** Reference URL: https://attack.mitre.org/techniques/T1565/
+* Sub-technique:
+** Name: Stored Data Manipulation
+** ID: T1565.001
+** Reference URL: https://attack.mitre.org/techniques/T1565/001/