Download RCS Demonstration Summary

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Infection wikipedia , lookup

Human cytomegalovirus wikipedia , lookup

Hepatitis B wikipedia , lookup

Neonatal infection wikipedia , lookup

Hospital-acquired infection wikipedia , lookup

Infection control wikipedia , lookup

Transcript
RCS Demonstration Summary
Attendants:
- Alberto Pelliccione
- Fabrizio Cornelli
- Adam Weinberg
- Zohar Weizinger
- From 8 to 12 people, Customer
Summary
RCS presentation has been held in customer’s HQ in two different sessions, after
an introduction from NICE the HT Team started a presentation, followed by a full
demonstration with a brief hands-on, together with customer’s technical team
followed by an extensive Q&A session the first day. The second day only tests on
customer’s hardware have been performed.
Presentation
Customer has been given an introduction to the system by HT, the presentation
shown system’s capabilities, functionalities and supported platforms. An
overview of the architecture has been shown, together with several types of
infection vectors and appliances available for the product in the upcoming
version 8. After answering a quick round of questions the live demonstration has
been performed.
Demonstration
Demonstration begun by introducing the demo environment and the devices that
were going to be used to show system’s capabilities: Windows Computer,
Android Phone, BlackBerry Device and an iPhone. Also the RMI tool was included
to perform remote attacks on mobile devices. The demonstration started by
showing the new interface from RCS v8, a brief tour of the console has been
given to the customer, including the steps necessary to create an agent, configure
and build it.
For this purpose the chosen infection vector has been a common executable
(putty.exe) merged with the agent, as shown in the picture below:
After showing that the antivirus was updated and running, the agent has been
launched, noting that the antivirus and the protection system (Kaspersky
Internet Security 2012) didn’t issue any warning. The infection took place on the
target machine and, as expected, the background changed to give customers
feedback about the infection process, and to show that the machine wasn’t
already infected beforehand.
A series of actions have been performed, like making a Skype Call to a mobile
phone, accessing documents from an encrypted USB pen drive, browsing the web
for Google search and even a login on a banking website, to show how to
overcome virtual keyboards. Once terminated the activities on the target
machine the view has been switched to the investigator’s Console.
The system had already received the first data coming from the client, connected
to the internet via a wired connection. The customer has been shown how to do
real-time monitoring on the target and how to extract interesting evidence from
Console’s dashboard.
Several types of evidence have been shown: screen snapshots, Skype call, stored
passwords, keystrokes, documents accessed from the encrypted resource, visited
URLs, Position via WiFi triangulation (that proved to be particularly accurate)
and finally the target’s file system. After showing data, there’s been quite a lot of
interest from customer’s side, thus after answering some questions more
advanced topics have been introduced in the discussion. It’s been shown how to
fine-tune the agent’s configuration by using the advanced configurator:
The team immediately grasped the logic behind the control of the agent.
Following that, a more in-depth description of the Network Injector and Network
Injector Appliance has been given, together with a deeper explanation of the
infection vectors, especially regarding the exploits. After another quick round of
questions the demonstration moved to the mobile part. The RMI tool has been
used to send a binary WAP-Push sms:
This message was used to infect a BlackBerry 9900 running the latest version of
RIM’s Operating System. After showing the customer how the infection appeared
on the target device, normal activities have been carried on, including a brief
chat using the BlackBerry Messenger and Google Talk system, that are both well
known to be hard to intercept due to applied encryption.
Following customer’s interest the same procedure has been used to infect an
Android device (via remote Installation Package) and the iPhone, this time with
physical access. Several features have been shown: SMS and Email capture,
screen snapshots, device information, positioning via WiFi and GSM, microphone
capture, phone’s webcam and finally logged keystrokes.
Hands On
After the demonstration the technical team joined us into a hands-on training on
the system. More information has been given to let them configure, create and
use agents, then they have used the advanced configurator to take confidence
with the interface. Following this brief phase they were interested into the
product visibility, especially on the desktop platform. For this purpose the test
system has been cleaned and the customer re-infected it, while checking for new
system’s processes or for any unusual behavior. Nothing strange was found,
being the infection completely a transparent process. Then they tried to raise the
security level of Kaspersky Antivirus, and they were surprised to see that the
antivirus settings were already at the maximum, but still there was no warning
from the protection system. After checking the CPU and used memory to spot
any unusual activity, they seemed satisfied and we moved to the final Q&A
session.
Q&A
The team immediately proved to be highly skilled and every question was
detailed and pertinent. They were interested to the exploits usage, firewall
bypass capabilities, types of injection performed by the desktop backdoor and
how persistence is achieved. They asked how to disguise the backdoor’s network
traffic, how to avoid turning on camera’s LED and if it was possible to access the
target’s LAN resources. Following they asked about RMI compatibility, Tactical
Network Injector, possible solutions to avoid charging the connection costs to
the target, requirements for Symbian Certificates, possibility to exploit the
iPhone, info about PIN and BBM messages for BlackBerry, evidence size in case
of microphone recording and used codecs. They where interested in the
possibility to modify the snapshot rate in order to monitor more frequently some
specific activities, and possibility to install and retrieve data from a computer
disconnected from the internet. The customer asked about the possibility to add
new modules to the system. They proposed, as a matter of example, a sniffer
module. We explained that we could discuss about this, technically and
commercially. On the other side we’ve shown that a custom application can be
uploaded and executed silently in a hidden environment into the target. Another
interesting point that emerged in the discussion is the opportunity to gather
intelligence about software used by the target by means of passive interception.
This is a feature that could be provided by NICE and that could be an important
complement to the RCS System. After asking about the licensing the Q&A session,
that lasted for quite some time, was closed.
Conclusion
The overall feedback was extremely positive, the customer seemed to like the
interface and the ease of use of the whole system, we had no feedback about
particular lacks or procedures that they don’t like. They also seemed satisfied
with the amount of information that RCS is able to retrieve and with the tools
provided to ease the infection task.
Second Day
Attendants:
- Alberto Pelliccione
- Fabrizio Cornelli
- Zohar Weizinger
- From 6 to 8 people, Customer
Summary
During the second day customer brought three different laptop computers with
different configurations, the intent was to test the RCS hiding capabilities with
several protection systems and the possibility to exploit target’s machine.
Test A
First test was conducted on a Windows 7 64-bits computer, equipped with
Comodo Internet Security (Personal Firewall, IDS, Antivirus). Two accounts were
setup, one with Administrator privileges, and the second one with Standard
privileges. The infection was carried out using Windows’ regedit.exe melted with
the backdoor. After running the executable on the Administration account the
agent started working normally with no popups, the backdoor correctly sent
every data-type requested by the customer. Second test was conducted on a
normal account to test the capabilities of the backdoor to run without special
privileges. Even in this case the backdoor behaved correctly and no popups were
issued. Backdoor persistence was also tested and confirmed to work after reboot
on both accounts.
Test B
Second test was conducted on a computer running Windows XP 32-bits
equipped with: BitDefender Internet Suite and McAfee Antivirus. The agent was
melted with the Putty executable and ran on the machine. McAfee didn’t report
any issue while BitDefender ran the backdoor inside the sandbox, thus blocking
its functionalities. We later apprehended that the Security Suite’s settings were
all set to Aggressive, so the default behavior was to run into the sandbox every
unsigned executable. It should be noted that BitDefender with default settings is
supported by RCS and doesn’t trigger any warning, so the behavior observed was
expected. By allowing the backdoor to run outside the sandbox, while still in
Aggressive mode, the infection was carried out successfully as expected.
Test C
Third test was conducted on a computer running Windows 7 64-bits equipped
with Avast Pro!, Outpost Firewall and HP Security Suite. This is kind of unusual; in
total there were three firewalls and two IDS running on the system at the same
time. The infection was carried out with the same vector used in Test B, after
running the executable Outpost blocked the process injection and Avast! flagged
the executable as possible malware, even though it issued a popup saying “We
didn’t gather enough information to mark this process as malware”, after that
the backdoor entered in “protection mode” and disabled its own infection
routines. We weren’t able to complete the infection with the configuration
illustrated above. It should be noted that Outpost is currently unsupported, while
the Avast! issue is already under investigation and will be solved promptly. As a
side note it should be highlighted that running multiple protection systems is not
a realistic scenario because it prevents many system components to work
correctly (other than making the whole system unbearably slow). To emphasize
it we showed that during Test C the regular Windows’ component svchost.exe
was flagged as malware, thus indicating a bad interaction among the various
IDSs that were monitoring the system. Also after running the agent, a dangling
Comodo Firewall incomplete installation was found that might have also caused
problems on the system, since the backdoor reacts differently depending on the
protection system installed.
Test D
Test D was conducted on the same computer used for Test C but this time the
infection vector was an exploit provided by HT for Microsoft Office. As expected
the behavior was the same, even though the antivirus didn’t detect the exploit.
Q&A
After the testing phase some more questions were raised regarding the
BlackBerry and iOS web installation. In order to answer the question a new
infection of the BlackBerry device has been performed, showing the installation
process in more detail.
Conclusions
Customer was extremely satisfied for the result of Test A, regarding Test B they
were provided with techniques to evade the sandbox (melting the backdoor with
an installer or signing the package after creating it) to bypass the Aggressive
settings and again they again were satisfied about that. Regarding Test C/D they
agreed that support for those systems is not essential, nevertheless the team
ensured that the incident would have been promptly investigated. Should further
evaluation be required in the future, we suggest proceeding with one protection
system at a time, in order to identify possible issues one by one. Also using one
single protection system would avoid creating false-positives due to the
presence of two or more interacting monitoring systems.