2) Our analysts fetch the file and immediately begin reverse engineering it. It’s immediately apparent this is a Stage 0 (initial malware used during an advanced attack).

3) Through their reverse engineering, they extract several components of interest that are unique to this malware. Mutexes, file names, memory strings, types of command lines, byte patterns, domains etc.

4) The analyst immediately begins feeding those characteristics back into Arc4dia’s systems and is able to identify two other completely different pieces of malware present on other systems that have a least one characteristic in common. One is a standalone executable and the other one has no other presence than in memory injected in another process.

5) With three different versions identified, the analyst disabled them by killing the processes and relevant threads.

6) The client is contacted and given the location and nature of the compromise. A list of network characteristics is also provided so that the existing security team can attempt to correlate the malicious activity across all of their assets.

Beyond the detection of a malicious program, Arc4dia has the means to look for similar and familiar malware patterns, and stop the full attack at the root.

2) The binaries referred to a very common product’s usage instrumentation mechanism, loading the legitimate API DLL found on the system used to generate and transfer the usage data.

3) The usage interface can provide arbitrary instrumentation to be sent in a standardized way to a few HTTP endpoints owned and operated by the product’s company.

4) The binaries found on the system looked in all ways possible to be legitimate and from the product itself. However, they were not signed and no references to the names or hashes could be found online.

5) Through reverse engineering of the binaries, Arc4dia analysts were able to identify the provider included keylogging information into the stream sent to the endpoints. The data stream was also configured to be sent over HTTP (not HTTPS).

6) The conclusion of the analysis was that this set of binaries were left behind after an attack that had occurred a year previously. Its goal was to provide a highly covert method of enabling future operations by the enemy in the event they lost their foothold onto the network. The key strokes were likely going to be collected either through some access in between the client and product’s company or by doing DNS manontheside attacks when necessary to redirect the data stream to an enemy controlled server.

Arc4dia analysts immediately issued a command to delete the file and contacted the client to explain the situation.

2) After each hack, the implant found had been removed from the infected machines and the admin account used had its password changed.

3) For a third time, now with Arc4dia present, they got hacked. A service started appearing on several machines.

4) While Arc4dia tracked hosts being infected and disabled the implants, we discussed having the client’s system administrator’s track down the origin of the credentials being used.

5) Through our investigation, it became clear that the attacker was coming in from inside the network, but also from a rogue device located at a field oce in Asia. When local employees working out of this oce were contacted, they denied the presence of a rogue device.

6) When local employees working out of this oce were contacted, they denied the presence of a rogue device.

7) Arc4dia, having extremely varied and specialized resources was able to provide assistance to the client since the investigation was not firmly rooted in the Human Intelligence side of things.

8) With the client, Arc4dia formulated a plan to provide experienced personnel to go to the remote oce, posing as international employees in order to investigate the nature and origin of the device.

9) A wireless router providing remote VPN access was identified and Arc4dia was able to provide Subject Matter Experts for the client’s legal case against the employee in question.

Sometimes employees can be a client’s main security problem. Arc4dia can help identify them.

1) During the baselining phase at a new client, Arc4dia analysts observed odd behaviour from what looked like an Acrobat Reader component.

2) The executable in question, located within the directory of a legitimate install, was named extremely closely to other various components in the directory. But when observed being launched sometimes contained IP addresses or Domains.

3) No other copy of this executable was anywhere else on the network, or documented on the Internet.

4) An analyst fetched the file and began reverse engineering it. It was clearly a very simple Stage 0 implant without any functionality other than very basic recon and the ability to download additional components from its command and control.

Step 2

1) Having difficulty believing this presence was alone on the network, the analyst began digging deeper, eventually finding multiple other versions of the implant, adapted to
other legitimate software throughout the network.

2) The implants had been present for over a year, but were never actually activated to download additional packages, or to execute additional recon. They were still able to communicate to their command and control.

Step 3

1) A handful of interactive sessions were detected over time, eventually providing enough data to do an analysis mapping the activity onto a time zone, days of the week and holidays of a specific country.

2) In discussion with the client, we eventually cleaned up the presence onto the network.

3) The final analysis lead us to determine that the only logical purpose for the implants were “prepositioning”, meaning waiting for the day they could be of some use, by delivering a payload yet unknown with goals unknown.

Security problems can be hidden even in files which other solutions are not able to find as malicious, Arc4dia is able to track them.