Malware Analysis Report: NETRYX RAT Developmental LLM Integration

Executive Summary

DeviceSync.exe is a malicious remote-access trojan consistent with NETRYX RAT, with remote-command functionality and observed persistence setup attempts. Its emerging LLM integration contains an operator-invoked assistant workflow, including prompt handling, API-key lookup, model selection, request construction, and response reporting. Successful LLM execution is not established, and the supplied absence of credentials explains why API activity is not expected; the recovered response-processing path also suggests an unfinished implementation.

Assessment

The severity assessment reflects the RAT functionality and observed persistence commands, not the use of an LLM service. Confidence is high in the malicious classification and compiled LLM capability, but does not extend to successful queries or LLM-directed actions.

Sample Identification

NETRYX attribution is supported by multiple sample-specific identifiers, including NETRYX_DEBUG, NETRYX archive/overlay markers, Netryx-labelled strings, and /root/netryx-build/proto/src/lib.rs.

Evidence Limitations

• Original source was not recovered. src/ai.rs is a compiled source-location marker, not an extracted Rust source file. Request structures below are distinguished from verbatim literals.
• Full-binary Ghidra analysis failed with “file too large or complex.” Reduced analytical PE projections supported limited decompilation, particularly the result wrapper and string decoder. Original-binary disassembly and extracted bytes remain the primary evidence; incomplete projection decompilation was not treated as authoritative.
• Sandbox unpacked-file retrieval failed. Existing memory dumps were obtained, but they did not provide original source or establish an additional unpacking stage.
• No captured LLM request, concrete operator prompt, model response, or successful query was recovered. Matching LLM strings in memory corroborate resident code/data, not execution of the query handler.
• Credential absence is supplied execution context. The investigation did not independently inventory the sandbox environment. Static code establishes the missing-key behavior under that condition.
• The HTTP response-handling concern is a static inference, not a tested API failure. No sample code was executed or emulated, and no sample domains or URLs were visited.
• The full PE-startup-to-command-dispatch chain was not reconstructed. Graphs therefore begin at verified handler/function entrypoints.
• Further shell inspection stopped when the session’s 30-command limit was reached.

Malware and LLM Analysis

1. Reachable ai_query command

The dispatcher compares the incoming command with ai_query, reads its payload, and prepares an asynchronous query operation.

Key locations in the original image:

The environment-variable name is also encoded at 0x140372f27. The decoder at 0x1400953bb XORs byte i with (0xe4 + 7*i) & 0xff, recovering:

OPENAI_API_KEY

For a nonempty prompt without either credential source, the handler returns the following error before API request construction and transmission:

no api_key provided and OPENAI_API_KEY not found in env

Consequently, the supplied no-key/no-environment-variable condition does not undermine the static evidence of LLM integration.

Evidence: shell_results/ai_dispatch_disassembly.txt, shell_results/ai_core_compact.asm, and shell_results/NETRYX_LLM_verbatim_evidence.json.

2. Recovered prompts, instructions, and model identifiers

The recovered prompt inventory contains one fixed system instruction and an operator-supplied user message.

The system instruction is stored at VA 0x140372f6a, file offset 0x37196a, length 28 bytes:

You are a helpful assistant.

The default model is stored at VA 0x140354485, file offset 0x352e85:

gpt-4o-mini

No additional LLM model IDs or fixed command-generation, attack-planning, evasion, or autonomous-action prompts were recovered. The traced request builder contains no conversation history, tool/function-call declaration, or automatic insertion of host data into the prompt.

3. API request structure

The endpoint literal is:

https://api.openai.com/v1/chat/completions

Location: VA 0x140372f9b, file offset 0x37199b.

The following JSON is a reconstruction from object-building instructions, not recovered source text or a captured request. Angle-bracket values identify runtime inputs; fixed strings and numeric constants are recovered values.

{
  "model": "<model argument; defaults to gpt-4o-mini>",
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant."
    },
    {
      "role": "user",
      "content": "<operator-supplied prompt>"
    }
  ],
  "temperature": 0.7,
  "max_tokens": 1024
}

The two-message construction occurs around 0x1400f0d55–0x1400f1064. The temperature is a double constant at 0x140349508; the token limit is assigned at 0x1400f111c.

Recovered HTTP template

Compiled Rust formatting data at VA 0x140372658, file offset 0x371058 reconstructs losslessly to:

POST {} HTTP/1.1\r\nHost: {}\r\nUser-Agent: Mozilla/5.0\r\nAuthorization: Bearer {}\r\nContent-Type: application/json\r\nContent-Length: {}\r\nConnection: close\r\n\r\n{}

All literal fragments are verbatim. Each {} represents a compiled format-argument slot, receiving the request path, host, API key, body length, and serialized JSON body, respectively.

The transport path includes DNS resolution, TCP/TLS establishment, write/flush/read operations, and a 60-second timeout.

Evidence: shell_results/NETRYX_HTTP_request_template.txt, shell_results/NETRYX_LLM_verbatim_evidence.json, and shell_results/ai_rdata_hex.txt.

4. Response handling and relationship to RAT execution

The handler parses response JSON, checks for an error member, and otherwise attempts to extract:

choices[0].message.content

The extraction instructions are at approximately 0x1400f216f–0x1400f2233.

The wrapper at 0x1400f0754 packages returned content into the RAT result channel:

• Successful content: status 0, success flag true.
• Failure: status -1, success flag false, with an ai_query: prefix.

Recovered diagnostics and format templates include:

empty prompt
no api_key provided and OPENAI_API_KEY not found in env
timeout
no content in response
ai_query: {}
openai error: {}
json parse: {}
json serialize: {}

The {} notation represents recovered formatting slots, not a claim that original Rust source was obtained.

Command-generation and execution boundary

A separate shell path reads the payload field cmd and constructs execution through cmd.exe /c, with relevant instructions beginning around 0x1400104fe.

No automatic connection from returned LLM content to that execution path was established. In the traced LLM wrapper, the response is reported as text; it is not parsed into RAT commands or submitted to a shell.

An operator could request command-like text and later submit a separate shell command, but neither a concrete command-generation prompt nor such an operator sequence was recovered. Specialized LLM-assisted attack execution therefore remains unverified.

Evidence: shell_results/DeviceSync_disassembly.txt, shell_results/ai_response_disassembly.txt, and decompiled_c_functions/DeviceSync_ai_projection_v2.exe/0x1400f0754.c.

5. Apparent developmental response-processing gap

The recovered transport path reads TLS-stream bytes, converts them into an owned lossy UTF-8 string, and passes that string to the JSON parser at 0x1400f1f9d.

No HTTP header/body separation was found in this traced path. A conventional HTTP/1.1 response includes a status line and headers before its JSON body, so this appears likely to cause parsing failure even if credentials are later supplied.

This finding supports the developmental framing, but remains an untested static implementation concern.

6. Functionality classification

Verified Control-Flow Outlines

These outlines cover the relevant command-handler and wrapper entrypoints, not an invented PE-startup chain.

ai_query dispatcher branch: 0x140012dd2
  ├─ Read payload.prompt
  ├─ Read optional payload.api_key
  ├─ Read payload.model
  │   └─ Default: gpt-4o-mini
  └─ Prepare asynchronous query operation

LLM result wrapper: 0x1400f0754
  ├─ Call query operation: 0x1400f0aa8
  │   ├─ Reject empty prompt
  │   ├─ Resolve api_key or OPENAI_API_KEY
  │   │   └─ Return missing-key error if unavailable
  │   ├─ Construct messages, model, temperature, and max_tokens
  │   ├─ notable sink: intended HTTPS POST to OpenAI chat-completions endpoint
  │   └─ Parse error or choices[0].message.content
  └─ Package result and send through RAT result channel
      ├─ Content: status 0, success true
      └─ Error: status -1, success false

Independent shell-command branch: approximately 0x1400104fe
  ├─ Read payload.cmd
  ├─ Construct cmd.exe with /c and supplied command
  └─ notable sink: Windows command execution

No LLM-response-to-shell edge is included because that control flow was not established. No unpacking-stage graph is warranted: no sample unpacking chain was recovered, and the analytical PE projections were investigator-created derivatives rather than payload stages.

Sandbox Corroboration

The existing analysis matched the submitted file’s SHA-256 exactly. Memory inspection recovered matching LLM literals in mapped image data and other executable copies, but did not establish that ai_query ran.

A representative validated artifact is:

memdumps/0/00000000.00000000.1282101801.00007FF69C487000.00000002.00000001.01000000.00000003.sdmp

The process tree recorded execution from:

C:\Users\user\AppData\Local\DeviceSync\DeviceSync.exe

It also recorded reg.exe commands targeting the current-user Run key and schtasks.exe commands creating an on-logon task named DeviceSync with the highest run level. These establish persistence setup attempts, not LLM-generated behavior.

Local evidence: shell_results/NETRYX_sandbox_provenance.json, shell_results/sandbox_ai_memory_summary.json, and shell_results/NETRYX_memory_literal_validation.json.

Key Suspicious Indicators and False Positive Analysis

The malicious assessment rests on the combination of a RAT command-dispatch framework, an implemented Windows command-execution path, sample-specific NETRYX identifiers, and sandbox-recorded persistence commands.

OpenAI API strings, Rust libraries, and generic assistant instructions are not independently malicious indicators. The provider endpoint is not classified as attacker-controlled infrastructure. Likewise, embedded public blockchain RPC URLs do not establish active C2 use without additional evidence.

The sandbox returned an automated EtherHiding label and an OlympicDestroyer-related YARA hit. Those labels were not adopted as family attribution; NETRYX identification is supported by the sample’s own identifiers and build paths. Missing LLM traffic was not used as evidence against the presence of LLM functionality.

Indicators and Reference Artifacts

Public service endpoints below are included for completeness and contextual correlation, not as confirmed malicious infrastructure.

No IP-address IOC was established in the inspected evidence.

Analysis Workflow

DeviceSync.exe investigation
  ├─ Identify PE architecture, entrypoint, size, and hashes
  ├─ Verify exact-hash Joe Sandbox analysis 2001275, run 0
  │   ├─ Unpacked-file retrieval failed
  │   └─ Retrieve 2,252 memory dumps
  ├─ Extract original strings and targeted disassembly
  │   ├─ Trace ai_query arguments and request construction
  │   ├─ Decode OPENAI_API_KEY literal
  │   └─ Trace response reporting and independent shell execution
  ├─ Use analytical PE projections for limited decompilation
  └─ Correlate memory constants and sandbox process evidence
      └─ Preserve verbatim literals, templates, and provenance

Conclusion

The evidence establishes developmental LLM integration within NETRYX RAT: an operator can supply a prompt, credentials, and a model choice to a compiled assistant workflow intended to return model text through the RAT’s result channel. It does not establish successful LLM execution, autonomous action selection, or automatic execution of generated commands. The missing credentials and apparent HTTP-response parsing gap are consistent with an integration that is present in code but not operationally demonstrated.