[BreachExchange] xDedic: What to Do If Your RDP Server Was Pwned

Inga Goddijn inga at riskbasedsecurity.com
Tue Jun 28 16:59:27 EDT 2016


http://www.databreachtoday.com/xdedic-what-to-do-if-your-rdp-server-was-pwned-a-9228

As many as 250,000 credentials for Remote Desktop Protocol servers around
the world may have been offered for sale on the now-shuttered xDedic
<http://www.inforisktoday.in/compromised-rdp-server-tally-from-xdedic-may-be-higher-a-9218>
cybercrime marketplace. If an organization suspects credentials to servers
may have been traded by cybercriminals, what can they do to mitigate
related risks and avoid a major network intrusion?

Security experts advise information security professionals to take several
important steps that go far beyond simply changing credentials. For
example, it's urgent that they scan all public listed IPs for any open RDP
or SSH ports and block them, in addition to carefully monitoring for
unusual behavior on their networks.

Kaspersky Lab
<https://securelist.com/blog/research/75027/xdedic-the-shady-world-of-hacked-servers-for-sale/>
described the credential exposure in a June 15 blog. In a followup June 20
blog
<https://securelist.com/blog/research/75120/the-tip-of-the-iceberg-an-unexpected-turn-in-the-xdedic-story/>,
the security firm explained why the amount of credentials exposed could be
higher than originally estimated (see: *Compromised RDP Server Tally From
xDedic May Be Higher*
<http://www.inforisktoday.in/compromised-rdp-server-tally-from-xdedic-may-be-higher-a-9218>
).

Kaspersky is advising organizations to check with their local CERT for
information on whether their credentials were exposed on xDedic.

Even though the xDedic marketplace has been shut down, many criminals could
still have access to the credentials that were offered for sale for as
little as $6 each, says Vitaly Kamluk, Kaspersky Lab's principal security
researcher for APAC. And that means thousands of organizations could be
vulnerable to hacker attacks.
Implications of Stolen Credentials

If attackers have access to an RDP server credential, they could try to use
it to quickly establish a foothold in the network and compromise additional
servers, establishing a "beachhead" before these credentials get revoked.

Even if credentials for just one server from an organization were listed on
xDedic, it's likely that nearly every server in that organization's DMZ
network could be compromised by hackers using those credentials, says K.K.
Mookhey
<http://www.inforisktoday.in/interviews/mookhey-on-indian-infosec-trends-i-2896>,
founder and principal consultant at NII Consulting in India. That's because
in typical setups, security controls exist between network segments and not
within each segment.

Deeper penetration is also likely where the DMZ barrier can be crossed
through the traffic allowed between the DMZ and the internal server
segment, Mookhey says. "There is really no practical purpose to allow an
RDP port to be accessible on a public IP address, and my first step would
be to scan for and close public facing RDP & SSH ports," he says.

Sahir Hidayatullah, CEO of the Mumbai-based security firm Smokescreen, says
such lateral movement is indeed, a major concern. "The attackers will move
laterally off the compromised system extremely quickly and try to establish
multiple command-and-control channels as they know they will likely lose
the initial access," he says.

Detecting this lateral movement is difficult if the attackers don't move
between network segments because the IDS/IPS
<http://www.inforisktoday.in/network-perimeter-c-213> sensors that are
located between segments won't get triggered, Hidayatullah explains.

Attackers also may make attempts to escalate privileges, which means any
other accounts that logged into the system should also be considered at
risk, he adds.

Even worse, just de-authorizing the compromised credentials or cutting off
access could signal to the attackers that they've been discovered. Then
they might attempt to operate in stealth mode, making them harder to
detect. Or they might even avoid the environment for a time, returning
after the security team believes the breach has been resolved, Hidayatullah
says.

In the meantime, the attackers may try to sniff out other credentials that
will enable them to return via a legitimate channel and ditch the RDP route
altogether - VPN for instance - and the organization then has very little
hope of pin pointing them, Hidayatullah says.

RDP & SSH brute force attacks have been prevalent for the last 18 months,
largely due to poor passwords and failure to restrict RDP services, says
Shomiron Das Gupta, founder at Indian security services firm Netmonastery.
Such attacks can permit the intruders to install backdoors and complete
code drops for APT-style attacks, he says.
Remediating RDP-driven Compromises

Experts say organizations can take several steps to remediate the risk
stemming from stolen RDP credentials. In addition to closing RDP and SSH
ports, organizations should:

   - *Monitor for unusual behavior.* Attacker movement can be difficult to
   pinpoint, even with the right tools. Look for unusual behavior and strange
   access patterns - out of office hours use, for instance, Hidayatullah
   advises. Also, look for newly created accounts on other systems on the same
   network segment and any other areas the attackers may have accessed
(see: *Role
   Based Behavior Analytics - Patterns and Anomalies in User Behavior as
   Indicators of Attack*
   <http://www.inforisktoday.in/webinars/role-based-behavior-analytics-patterns-anomalies-in-user-behavior-as-w-915>
   ).
   - *Mandate two-factor authentication.* Remote access should be via VPN
   and require two-factor authentication
   <http://www.inforisktoday.in/authentication-c-206>. If organizations
   complying with PCI DSS, this is mandatory in any case, Mookhey notes.
   - *Adopt strong password policies.* Monitor for weak passwords and
   password reuse. This is one of the major causes for these kinds of attacks
   today, Das Gupta says.
   - *Implement privileged ID management.*This can help prevent one server
   compromise from leading to other compromises through the shared
   administrator/root account credentials.
   - *Use deception and decoys.* Deception technology and commercial
   honeypot systems are effective in picking up intruders' activities,
   Hidayatullah says. "The attacker hits the decoy systems both during the
   brute force process and in the lateral movement phase. Deploying decoys in
   DMZ networks have shown so much value that it's pretty much the first thing
   we recommend now," he says. Decoy credentials, which can be left on systems
   around the network to be discovered by attackers, are also helpful. "This
   way, when an attacker compromises a system and then tries to escalate
   privileges, they encounter the decoy credentials that trigger when used,"
   Hidayatullah explains.

Pinpointing attacker movement in the initial phases of such attacks is
essential, and honeypots and other sensors are becoming an increasingly
valuable source of intel, experts says. Mookhey also recommends the use of
open-source big data setups such as ELK <https://www.elastic.co/products>
(Elasticsearch, Logstash, Kibana) to visualize and analyze raw data and
mine it for security intelligence. And he suggests that organizations run
red team attacks on their environments at least annually to help determine
if they can detect when a privileged ID is being misused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160628/1ed5347f/attachment.html>


More information about the BreachExchange mailing list