Configured endpoint appears in sandbox POST, beyond Azorult label

A sandbox report for a Windows executable records an HTTP POST to http://ANYIOBA.INFO/index.php—the exact URL identified in the file’s extracted configuration. That match answers a consequential question: was the endpoint merely present in configuration, or did it also appear in recorded network activity? In this case, it appeared in both.

CTX Threat Intelligence’s evidence links the configured destination to a request recorded by Rising MOVES, which also logged a DNS lookup for anyioba.info. Separate sandbox reports recorded lookups for the same hostname. Together, these observations make the domain more than an indicator associated with a malware label: it is a configured destination with a matching request in the sample’s behavioral record.

The important boundary is between evidence that a request occurred and evidence of what it accomplished. The supplied record does not contain the POST body, a server response or a process-level correlation for the request. It supports the endpoint’s operational relevance to the sample, but not a finding that stolen information reached a server. Understanding that distinction also changes how the accompanying DNS, registry and browser-cache artifacts should be read.

The endpoint match is stronger than a family label

The file, identified by SHA-256 prefix #a1fc44bbe7ef, is a 115,200-byte Windows executable. A MANDIANT_TCR configuration extraction identifies an Azorult configuration containing the HTTP endpoint, port 80 and a C2 category. The extraction method is not specified, so the evidence is an extracted configuration—not necessarily a static string discovery or a memory extraction.

By itself, that configuration would establish a destination the extraction tool associated with the sample. It would not establish that the destination was used. Configuration can describe intended behavior without showing whether execution reached the relevant code, whether a hostname resolved or whether a request was issued. Here, the Rising MOVES report supplies the additional observation: an HTTP conversation entry with the same URL and the request method POST.

The agreement extends beyond the domain name. The scheme, host and /index.php path match the extracted endpoint. That specificity matters because a lookup for a hostname alone would leave the requested service and resource unknown. The POST entry connects the configuration to a particular HTTP destination, while the lookup places the hostname in the same sandbox report’s DNS observations. These are mutually reinforcing records, although the report does not provide the timing and correlation fields needed to reconstruct their exact order.

Other evidence supports the Azorult identification. Elastic Security and CAPEv2 YARA rules bearing that family name matched the file, and sandbox verdicts also named Azorult. The supplied antivirus analysis classified the file as malicious in 67 of 76 results, but that count is not a vote by 67 engines for the same family. The family assessment rests on the more specific configuration, rule and sandbox evidence rather than on treating all malicious verdicts as equivalent labels.

Even so, the endpoint finding does not depend on importing a family’s presumed behavior into this execution. The configuration and request agree directly. A reporting or command endpoint is therefore a plausible role for the URL, consistent with the extractor’s C2 classification. The strongest alternative is narrower: the recorded POST may have carried test, routine or otherwise non-sensitive data, and the server may not have returned anything useful. Without the body and response, the request cannot distinguish those possibilities from an attempted transfer of collected information.

This leaves a strong but bounded finding. The sample’s configured endpoint appears in its sandbox request record. That is more informative than a family verdict, yet less than a demonstrated command exchange or successful theft.

Repeated lookups do not complete the server path

Once the request is established, the next question is where it went. The source offers several network observations, but they play different roles.

VMRay and VirusTotal Jujubox each recorded a lookup for anyioba.info in their own reports for the file. Those observations reinforce the hostname’s relevance across different analysis environments. They do not extend the Rising MOVES POST into those environments: neither supplied report contains a corresponding HTTP conversation. The consistent feature is interest in the hostname, not a demonstrated identical exchange in every run.

This distinction prevents the reports from becoming a synthetic attack timeline. The VMRay process tree, the Jujubox network entry and the Rising MOVES POST are not fragments that can automatically be joined into one process-to-server sequence. Their report boundaries remain meaningful. The executable appears under different names in the process records, but those names do not supply the missing correlation between a specific process and the HTTP event in another report.

The domain profile adds an A record for 173.212.234.246. This is a useful resolution lead, but it is not a recorded destination address for the POST. The supplied material contains no sandbox-time DNS answer that binds that address to the request. Assigning the POST to the A-record address would require a link the evidence does not provide.

The A record’s TTL of 119 seconds does not fill that gap. It describes the record’s caching lifetime, not observed address rotation, server availability or the address returned during a particular sandbox execution. Likewise, the Cloudflare nameservers in the domain profile describe DNS infrastructure. They do not identify the operator of the configured HTTP service or establish where the application itself was hosted.

There is also an IP traffic entry for 8.8.8.8, using UDP destination port 53, in the Jujubox report. Its transport and port are consistent with DNS traffic; it should not be promoted to the role of the configured HTTP server. The same report lists the domain lookup, but the supplied fields do not bind that lookup to a particular packet. An aggregated “contacted IP” relationship also lists the address, without adding a process, session or successful exchange.

The practical difference is that the source supports three distinct network relationships: a configured URL matched by a recorded POST, hostname lookups in multiple reports, and a domain-to-address resolution record. The first establishes the endpoint’s behavioral relevance. The second corroborates recurring hostname use. The third supplies an infrastructure pivot. Keeping those roles separate preserves the useful evidence without attributing traffic to an unverified server address.

Internet Settings artifacts describe context, not the POST’s contents

The host-side records initially seem to promise a fuller explanation. Rising MOVES logged writes involving Internet Settings, browsing-history locations, temporary Internet files and cookies. Jujubox recorded cache-related registry values and a ProxyEnable value of 0. A Sigma rule also matched changes under Windows’ WPAD registry area.

These observations are relevant because they sit close to the networking question. But their meaning depends on the operation recorded, not just on words such as “cookies,” “proxy” or “history.”

In the Rising MOVES report, the registry entries include Internet Settings\Connections\DefaultConnectionSettings and SavedLegacySettings. The supplied entries identify settings that were written but do not give their full values. They therefore do not show which connection properties changed. The same report lists writes to locations ending in History.IE5, Content.IE5 and Cookies. Those are write observations, not records of reading credentials or collecting existing browser data.

That direction of activity is important. A cookies-related pathname can attract attention in a sample associated with a stealer family, but the pathname alone does not reveal whether information was collected. Nor does its presence in the same report identify it as the source of the POST body. Linking those artifacts to exfiltration would require evidence of collection and payload construction that is not supplied.

The Jujubox report offers more explicit registry values. It records Cookie: and Visited: as cache prefixes and ProxyEnable set to 0. The latter establishes a recorded setting, but the entry has no prior value and no demonstrated effect on the request. It cannot by itself establish that the sample disabled an enterprise proxy, bypassed a control or caused direct communication. Crucially, it belongs to the Jujubox report, not the Rising MOVES report containing the POST.

The Sigma match is similarly narrower than its title, “Modification of IE Registry Settings,” might suggest. Its two supplied Event ID 13 records are SetValue events involving WpadNetworkName and WpadLastNetwork. The network identifier in one entry corresponds to the identifier in the other entry’s registry path, connecting the two values to the same WPAD network context. That explains why they belong together as settings observations. It does not establish a malicious proxy configuration.

The strongest competing explanation is that at least some of these cache and settings effects arose from ordinary Windows networking components operating during sandbox execution. The supplied events do not distinguish that explanation from deliberate manipulation by the sample. CTX Team therefore treats these artifacts as context for the analysis environment’s networking activity, rather than as proof of an evasion or credential-theft sequence.

That judgment does not weaken the URL match. It prevents nearby, less specific artifacts from being used to claim more than the direct network evidence shows.

A precise destination, not a reconstructed theft sequence

The case’s most useful result is a change in the evidential role of anyioba.info. It is not merely a suspicious domain attached to a file profile. Its exact HTTP endpoint appears both in extracted configuration and in a request recorded during sandbox analysis. Separate DNS observations strengthen the hostname connection without supplying additional HTTP exchanges.

For a security reader, this makes the URL and sample a more precise basis for investigation than either the family label or the domain’s A record alone. A matching request to the configured path would speak directly to the behavior demonstrated here. A lookup would establish a narrower kind of activity, while a connection to the listed IP would need its own evidence tying it to this endpoint.

The remaining decisive evidence would be the request and response content, along with process correlation and a contemporaneous DNS answer—not a longer inventory of cache files or generic settings changes. Those records would resolve different questions: what the request carried, whether the service answered, which process issued it and which server address was involved.

For now, the supported understanding is specific: a destination extracted from the executable was also used in a recorded HTTP request. That moves the case beyond configuration-only suspicion while keeping infrastructure attribution and impact assessment anchored to what was actually observed.