]HackingTeam[ KnowledgeBase Product
Search:     Advanced search

Leaked Address Procedure

Article ID: 163
Last updated: 16 Apr, 2015

Details

This is the procedure to follow in case of crisis.

Requirements/Conditions/Restraints

  • This procedure involves three groups: vt@hackingteam.com, rcs-support@hackingteam.com and fae@hackingteam.com.

Instructions

Please, follow these steps:

1. [VT] analyze the sample and extract the following information:

  • client name;
  • sync address;
  • factory.

2. [VT] send the information via email to SUPPORT with subject "<client name> Leaked address";

3. [SUPPORT] check if the address is provided by us, and if so shutdown and disable the anonymizer services on the vps;

4. [SUPPORT] send a ticket (department: Security) to client using the "Leaked address (provided by us)" or "Leaked address (not provided by us)" macro, filling in the address parameter accordingly;

5. [SUPPORT] upon client confirmation, forward the email received by VT to FAE including the ticket ID and if the address are provided by us or not;

6. [FAE] contact the client in order to plan a remote session or an assisted session;

7. [FAE] follow these steps one by one, ensuring it is done properly:

a. close (do not delete) the factory received via email;

b. analyze any instance of that factory in order to understand if it is a real target or not;

c. close any instance that seems suspect (if unsure, it's better to close);

d. export the latest DEVICE evidence from each suspect instance and send them to SUPPORT;

e. check if some legit instance of any factory uses the compromised address and must be recovered (if not, skip to point i);

f. turn on the collector (and possibly the vps) and check that the anonymizers are running correctly;

g. for each instance, change the configuration in order to use another anonymizer for synchronization;

h. wait until new configurations are activated and the instances can send data through the other anonymizer;

i. delete the compromised anonymizer from the chain;

j. add a new anonymizer into the chain (ask to SUPPORT if you need a new vps);

k. download and install the anonymizer proxy on the new vps;

l. if still down, turn on the collector and check that the anonymizers are running correctly;

m. apply the network topology;

n. if needed, change the configuration of the instances in order to use the new anonymizer;

o. check that everything is working correctly.

8. [FAE] update the KBC marking as "compromised/removed" the old vps and adding the new vps information, along with any other client's related data;

9. [FAE] send an email to SUPPORT with a status update;

10. [SUPPORT] if vps is provided by us, reinstall the operating system, ask the provider to dismiss the vps and update internal documentation;

11. [SUPPORT] update the client via ticket confirming that the procedure has completed correctly.


!!! ⇒  Remember that this procedure follows two main flows: the first one, via email, is for internal purpose; the second one, via ticket, is for the client.

Article ID: 163
Last updated: 16 Apr, 2015
Revision: 6
document Public
Views: 25
Comments: 0
This article was:   Helpful | Not helpful
Tags
crisis

Prev   Next
Procedures     USB memory bootable for Offline Installation Vector