Tyrannosaurus reproduced fast and died young: A malicious host/IP/C&C from China, 2016 to present

maderas · May 15, 2018, 2:28pm

A portion of the title of this post refers to an idea put forth by Gregory S. Paul in the book “Tyrannosaurus: Tyrant King”; as both a (probable) scavenger and predator living during dangerous times, the T.Rex does not seemed to have had an exceptionally long life span.

I find this a fitting metaphor for the host machines (and its IP) utilized for offensive/malicious purposes by many types of actors: I have the feeling many reproduce relatively quickly (through RATs, backdoor shells, created slave nodes, creds created and/or harvested by bruteforcing/spidering/dorking/scraping, etc.) and have short lives in the wilds of the Internet (when utilized for pure offense purposes/illegal commerce) relative to the uptime of similar, less aggressive machines/IP: whether hunted down by researchers, shutdown by authorities or hosting providers, abandoned by those who established them, etc…

Many of the host/IP utilized in this way will be both scavenger and predator: constant port scanning looking for instances of default/hardcoded credentials to exploit looks like a digital buzzard circling the sky to my mind’s eye…

In my work as a Penetration Tester/Red Teamer, it has been important for me to follow the goings on of Black Hats in the wild first hand.

In general, during most engagements I believe it is important to realistically create the methodology/tactics currently utilized by real world actors.

At the very least, being as close as possible to this bleeding edge
helps me to`better analyze/relate/put into context the results of an engagement and/or best assess the client’s security posture in relation to the results of an engagement.

In doing this, there are many “resources” I seek out and keep an eye on in their native environments; think more watching the wildlife of the African Sahara in real time rather than waiting for a documentary to complete production after 6 months of post production (many of those metaphorical zebras will be eaten by the metaphorical lions by the time you watch it).

One of my views on the predatory wildlife of the Internet has been my watching and charting a host/IP from China that has been active from 2016 to present day, and has been pretty noisy/blatant during that time.

This post will look at periods in the existence of a host machine/IP that has continually been utilized in offensive/malicious activity from at least June of 2016 to present day.

The IP/host in question is 183.129.160.229, a China based host/IP active in malicious/offensive activities from at least 6/2016 to present day (references will be cited during or at the end of this post).

PLEASE NOTE: Well into my watching this IP (which started with my investigating the IP for a client), the host machine had a completely different configuration on Shodan (an SSH port on standard 22, the remainder of ports being a dozen or so instances of NTP); this has since changed to a single SSH port while the NTP ports have been closed or (tunneling through or Denial of Service by) use of NTP/UDP services/protocols through these ports suspended.

Also, a great number of paleontologists now theorize the Tyrannosaurus looked like this (protofeathers provide Chicken-tarrasque with AC 2 and force a saving throw vs. fear or player suffers the effects of Tasha’s Hideous Laughter for 1d4 rounds):

trex

183.129.160.229: Basic Data, Rise and Stabilization

Who is Data of 183.129.160.229 (from https://whois.domaintools.com):

229

Geographical location of host/IP location (from https://whatismyipaddress.com and OpenStreetMap):

map

Month by Month Activity Graphs and accompanying data for 183.129.160.229 from X-Force Exchange IBM with Server Logs Reporting Abuse (Multiple Sources):

ibmdata

X-Force IBM begins to detect/chart the activity of the IP in June2016, this represents the full graph to present (directly below):

IBMFUllgraph

X-Force IBM data of 183.129.160.229 for July 2016 ); further commentary picks up in August 2016:

X-Force IBM data of 183.129.160.229 for August 2016:

In August 2016 the wider internet begins to notice the activity:

awslogs8_16

PLEASE NOTICE THE USER AGENT MAKING THE REQUESTS IN THE IMAGE ABOVE!!!
Even though this IP is acting through the Great Firewall to reach foreign sites, and even though China’s officials have shown great skill/use of resources in defeating/exploiting multiple means of encapsulation/encryption utilized by its citizens in attempting to circumvent the Great Firewall, the user agent associated with this IP (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0) rarely ever shows any variation during the almost two years covered in this post.

In 8/2016, reports of abuse start to be reported to the Black Hat Directory (https://blackhat.directory/ip/183.129.160.229/31#comments):

Anonymous Port scan 2016-08-29 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-08-30 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-08-29 Nmap (Nmap -sT or -sS scan): port scan detected

Similar Activity throughout September and October 2016:

As illustrated through the X-Force IBM generated activity graphs above, throughout the later quarter of 2016, the host/IP established an intensive port scanning (or perhaps periods of a denial of service campaign utilizing port scanning/port scanning like traffic, those this seems less likely) campaign that continues to this day:

Corresponding data found in Black Hat Directory Abuse logs:

Anonymous Port scan 2016-09-30 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-09-29 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-09-03 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-09-02 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-09-01 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-04 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-03 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-02 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-01 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-05 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-15 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-14 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-13 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-12 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-11 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-10 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-09 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-07 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-06 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-27 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-26 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-2 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-24 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-22 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-21 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-20 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-19 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-18 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-10-28 Nmap (Nmap -sT or -sS scan): port scan detected

And the IP caught in other logs with the same user agent:

webappslog

November 2016 sees port scanning activity recover from the Dive at the end of October 2016 while Bot activity remains erratic and not yet stabilized:

Anonymous Port scan 2016-11-23 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-22 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-20 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-19 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-18 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-17 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-16 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-15 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-13 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-12 Nmap (Nmap -sT or -sS scan): port scan detected

At this point, 183.129.160.229 is like a new born predator: it is just getting used to its predatory senses (port scanning is shaky but shows periods of stability), it is beginning to stand and maneuver but occasionally falls (short periods of activity spiking/outage of port scanning/bot activity)…

However, it actively picks up the tempo of its predation in late November into December 2016 and onward.

We have a couple of gentleman at https://amcrest.com/forum/technical-discussion-f3/weird-alarm-event-illegal-access-local-storage-fro-t1887.html communicating about the IP/host in question exploiting residential cams:

Hackedwebcam1
Hackedwebcam2

By December 2016, it appears that 183.129.160.229 was scanning for and targeting HP printer JetAdmin vulnerabilities (such as HP Web 6.5 Server Arbitrary Command Execution) though it does not appear to have been targeting the SNMP HP JetAdmin Password variation of the vulnerability yet (logs detailing Nmap/port scans have been TCP based Syn and Connect scans so far).

Examples from logs from Black Hat Database https://blackhat.directory/ip/183.129.160.229/26#comments):

Anonymous Port scan 2016-11-30 src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2016-11-30 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-29 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-27 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-26 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-11-25 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-04 src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2016-12-04 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-03 src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2016-12-03 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-09 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-07 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-06 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-05 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-12 src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2016-12-12 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-09 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-14 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-13 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2016-12-16 Nmap (Nmap -sT or -sS scan): port scan detected

X-Force IBM then reports a nose dive in activity at the end of December 2016/beginning of January 2017, and the logs at Black Hat Directory also do not report abuse until 1/11/2017; this could be due to factors in relation to countries that celebtate a holiday season in late December/early January.

However, before the second week of January 2017 183.129.160.229 is back in action(may be inline with the commencement of business in countries that celebrate late December/early January holidays. as abuse reports at Black Hat Directory begin again on January 11th 2017, https://blackhat.directory/ip/183.129.160.229/25#comments. inline with X-Force IBM detected activity)

183.129.160.229 appears to have evolved in order detect opportunities for SNMP based JetAdmin password vulns (NMap -sU/UDP scan abuse begins to be reported to Black Hat Directory, https://blackhat.directory/ip/183.129.160.229/24#comments) and abuse against SNMP will begin to be reported to Black Hat Directory.

Anonymous Port scan 2017-01-11 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-01-11 Nmap ( -sU scan): port scan detected

Anonymous Port scan 2017-01-16 src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2017-01-16 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-01-18 Nmap (Nmap -sT or -sS scan): port scan detected

AnonymousPort scan 2017-01-17 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-01-16 Nmap ( -sU scan): port scan detected

Anonymous Port scan 2017-01-21 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-01-22 src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2017-01-20 Nmap (Nmap -sT or -sS scan): port scan detected

____________________________________________________

183.129.160.229 opens its eyes, studies its environment and than attacks new prey

We skip looking at Black Hat Directory’s logs until mid February thru March of 2017. Though the host/IP was detected scanning/attacking the targets covered earlier, mid February 2017 and onward shows evidence of 183.129.160.229 beginning to attack (and presumably scan for) multiple other vulnerabilities, including what was likely to have been instances of SQL Databases with default creds or versions with known vulnerabilities (as reported to Black Hat Directory, https://blackhat.directory/ip/183.129.160.229/22#comments).

As the attacks on the MySQL Servers are being reported as a port scan, it is possible the host/IP is attacking through a means such as NMap NSE scripts which may detect and attack a target through means such as bruteforcing.

Anonymous Port scan 2017-02-17Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-02-18 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-02-21 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-02-21 src: 183.129.160.229 signature match: “MISC Microsoft SQL Server communication attempt” (sid: 100205) tcp port: 1433

Anonymous Port scan 2017-02-22 src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2017-02-22 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-02-23 src: 183.129.160.229 signature match: “MISC Microsoft SQL Server communication attempt” (sid: 100205) tcp port: 1433

Anonymous Port scan 2017-02-23 Nmap (Nmap -sT or -sS scan): port scan detected

Anonymous Port scan 2017-03-01 Port scan detected by psad: Nmap (Nmap -sT or -sS scan):

Anonymous Port scan 2017-03-01 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC Microsoft SQL Server communication attempt” (sid: 100205) tcp port: 1433

Perhaps the attacks were successful thanks to the widening target variation, as X-Force IBM detects a unstable resurgence in Bot activity soon after.

Anonymous Port scan 2017-04-18 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC Microsoft SQL Server communication attempt” (sid: 100205) tcp port: 1433

Below, this sample of Black Hat Directory abuse logs show that 183.129.160.229 is also scanning for/attacking a new target in “POLICY HP JetDirect LCD communication attempt” (sid: 510) tcp port: 9000"

This may be an attempt at the Raw/App Sock protocol of this printer which sometimes also resides at Port 9100.

Anonymous Port scan 2017-04-18 Port scan detected by psad: src: 183.129.160.229 signature match: “POLICY HP JetDirect LCD communication attempt” (sid: 510) tcp port: 9000

Anonymous Port scan 2017-04-18 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2017-04-18 Port scan detected by psad: Nmap (Nmap -sT or -sS scan):

Anonymous Port scan 2017-04-09 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2017-04-09 Port scan detected by psad: Nmap (Nmap -sT or -sS scan):

Anonymous Port scan 2017-04-08 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC Microsoft SQL Server communication attempt” (sid: 100205) tcp port: 1433

Anonymous Port scan 2017-04-07 Port scan detected by psad: src: 183.129.160.229 signature match: “POLICY HP JetDirect LCD communication attempt” (sid: 510) tcp port: 9000

Anonymous Port scan 2017-04-06 Port scan detected by psad: Nmap ( -sU scan):

Anonymous Port scan 2017-04-18 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC Microsoft SQL Server communication attempt” (sid: 100205) tcp port: 1433

Anonymous Port scan 2017-04-18 Port scan detected by psad: src: 183.129.160.229 signature match: “POLICY HP JetDirect LCD communication attempt” (sid: 510) tcp port: 9000

Anonymous Port scan 2017-04-18 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2017-04-18 Port scan detected by psad: Nmap (Nmap -sT or -sS scan):

Anonymous Port scan 2017-04-09 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

Anonymous Port scan 2017-04-09 Port scan detected by psad: Nmap (Nmap -sT or -sS scan):

Anonymous Port scan 2017-04-08 Port scan detected by psad: src: 183.129.160.229 signature match: “MISC Microsoft SQL Server communication attempt” (sid: 100205) tcp port: 1433

Anonymous Port scan 2017-04-07 Port scan detected by psad: src: 183.129.160.229 signature match: “POLICY HP JetDirect LCD communication attempt” (sid: 510) tcp port: 9000

Anonymous Port scan 2017-04-06 Port scan detected by psad: Nmap ( -sU scan)

**183.129.160.229 During the Height of the ShadowBroker’s and Wannacry Period/Petya/NotPetya/Why the hell is SMB/Samba still facing the outside world? Period **

As later logs will show, DoublePulsar/EternalBlue/Eternal Romance (and the other NSA exploits/exploit kits released by ShadowBrokers in mid April 2017) use has persisted from 183.129.160.229 well into 2018.

This is not surprising, as the exploits still seem to serve me well as a valuable option for exploitation while within a LAN post ingress during penetration testing/Red Team engagements (reminiscent to how NetAPI exploitation of WIndows XP/Server 2003 served me well within LANs a bit short of a decade or so ago).

While many networks may have hardened their perimeter machines against these tools, the hosts within target intranets tend to be (at least) a bit more vulnerable to these tools (though there is always the noise of surrounding defensive technologies to consider).

For these purposes we will date this period from mid April 2017 thru until July 1st 2017,and since similar topics have been dropkicked to death elsewhere, we will only briefly look at the X-Force IBM based logs for this section.

Interesting entries from the Abuse IPDB for 183.129.160.229 from 2017 to Present:

Beginning from earliest report on https://www.abuseipdb.com/check/183.129.160.229?page=132#report:

“This IP was reported 1337 times. Confidence of Abuse is 67%”

By December 2017, the quantity of attacks/targets originating from this IP/Host have truly diversified, while user-agents caught from 183.129.160.229 only seem to utilize 1 of 2 user-agents:

02 Dec 2017 [portscan] tcp/1433 [MsSQL]
02 Dec 2017 [portscan] tcp/1433 [MsSQL]
02 Dec 2017 [portscan] tcp/1433 [MsSQL]

02 Dec 2017 [SMTPD] RECEIVED: EHLO [183.129.160.229] in blocklist.de:“listed [mail]” in DroneBL:“listed [SOCKS Proxy]”
Email Spam JCB 02 Dec 2017 183.129.160.229 - - [10/Nov/2017:02:33:20 +0200] “GET /ws_utc HTTP/1.1” 404 204 “-” “Mozilla/5.0 (WET /ws_utc HTTP/1.1” 404 204 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0” 183.129.160.229 - - [10/Nov/2017:02:33:21 +0200] “\x16\x03\x01” 400 226 “-” “-”

Notice in the entry above from https://www.abuseipdb.com/check/183.129.160.229?page=131#report we have a similar user agent making the HTTP request as mentioned earlier, except we have a Windows 7 machine making the request.

This machine likely serves as a SOCKS proxy for some manner or type of the offensive/malicious traffic leaving the host.

02 Dec 2017 [portscan] tcp/21 [FTP]
02 Dec 2017 FTP fake admin login

Entries below mark the beginning of reports of attacks against web applications, usually through GET or curl requests that target sensitive files/directories.

02 Dec 2017 [httpReq only by ip - not DomainName] [multiweb: req 2 domains(hosts/ip)] “GET /ws_utc” [random UserAgent: 2]:
UA:empty. UA:"Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0"in blocklist.de:“listed [sasl]”
in DroneBL:“listed [SOCKS Proxy]”

02 Dec 2017
] [!] [Thu Nov 09 2017 22:26:49] (183.129.160.229) (/ws_utc) - ({“host”:“host.ip:80”,“user-agent”:“Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8”,“accept-language”:“zh,en-US;q=0.7,en;q=0.3”,“dht”:“1”,“upgrade-insecure-requests”:“1”,“accept-encoding”:“gzip”})
] [!] [Thu Nov 09 2017 22:58:41] (183.129.160.229) (/ws_utc) - ({“host”:“host.ip:443”,“user-agent”:“Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8”,“accept-language”:“zh,en-US;q=0.7,en;q=0.3”,“dht”:“1”,“upgrade-insecure-requests”:“1”,“accept-encoding”:“gzip”})

Below, we are back to the same user agent as we first mentioned utilizing a a OSX 10.11 OS for what looks like a SOCKS proxy request to the victim machine:

02 Dec 2017
[httpReq only by ip - not DomainName]
UA:“Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0”
in DroneBL:“listed [SOCKS Proxy]”

02 Dec 2017 Trusted domain error. 183.129.160.229 tried to access

Below, still targeting HP Printers over a year later:

02 Dec 2017 Nov 3 08:21:51 psad: src: 183.129.160.229 signature match: “POLICY HP JetDirect LCD communication attempt” (sid: 510) tcp port: 9001

02 Dec 2017 Attempt to access invalid virtual host name (###.###.###.###:80). Typically used to access “internal” resources improperly exposed externally and “protected” only by a lack of external DNS resolution.183.129.160.229 - - [02/Nov/2017:05:40:54 +0000] “GET /wls_utc HTTP/1.1” 403 169 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0” “-”

02 Dec 2017 [ThuNov0208:24:51.2896232017][:error][pid8058][client183.129.160.229]ModSecurity:Accessdeniedwithcode403(phase1).RBLlookupof229.160.129.183.xbl.spamhaus.orgsucceededatREMOTE_ADDR(Illegal3rdpartyexploits).[file"/usr/local/apache/conf/modsec_rules/00_asl_rbl.conf"][line"51"][id"350000"][rev"2"][msg"GlobalRBLMatch:IPisonthexbl.spamhaus.orgBlacklist(ReportFalsePositivestowww.spamhaus.org)"][severity"ERROR"][hostname"creativedigital.ch"][uri"/"][unique_id"WfrIQ1ERGeYAAB96XeQAAAAB"][ThuNov0208:24:52.9081182017][:error][pid5410 [client183.129.160.229]ModSecurity:Accessdeniedwithcode403(phase1).RBLlookupof229.160.129.183.xbl.spamhaus.orgsucceededatREMOTE_ADDR(Illegal3rdpartyexploits).[file"/usr/local/apache/conf/modsec_rules/00_asl_rbl.conf"][line"51"][id"350000"][rev"2"][msg"GlobalRBLMatch:IPisonthexbl.spamhaus.orgBlacklist(ReportFalsePositivestowww.spamhaus.org)"][severity"ERROR"][hostname"81.17.25.236"][uri"/wls_utc"][unique_id"WfrIRFERGeYAABUi54wAAAAQ"][ThuNov0208:2

02 Dec 2017 TCP src-port=50757 abuseat-org zen-spamhaus eatingmonkey 184

02 Dec 2017 [portscan] tcp/1433 [MsSQL] [portscan] tcp/22 [SSH]
[scan/connect: 2 time(s)]

02 Dec 2017 Sep 19 04:17:46 psad: src: 183.129.160.229 signature match: “MISC MS Terminal Server communication attempt” (sid: 100077) tcp port: 3389

02 Dec 2017 FTP/21 MH Probe, Scan, BF, Hack -
02 Dec 2017 [portscan] tcp/1433 [MsSQL]

02 Dec 2017 Sep 17 22:43:41 psad: src: 183.129.160.229 signature match: “MISC Microsoft SQL Server communication attempt” (sid: 100205) tcp port: 1433

02 Dec 2017 Sep 18 00:16:30 psad: src: 183.129.160.229 signature match: “MISC Microsoft PPTP communication attempt” (sid: 100082) tcp port: 1723

Below, we have our promised attacks against SNMP, which has remained and grown in importance as a target for recon and exploitation given the rise of SCADA/PLC and IoT facing internet devices.

It is possible the SNMP bruteforcing in question is against such targets as default community strings or HP Printer JetAdmin Password vulns:

02 Dec 2017 SNMP/161 MH Probe, BF -Brute-Force
smel

02 Dec 2017 SNMP/161 MH Probe, BF -

02 Dec 2017 SNMP/161 Probe, BF, Hack -

02 Dec 2017 Sep1807:35:43server2sshd[30423]:refusedconnectfrom183.129.160.229(183.129.160.229)Sep1807:39:52server2sshd[30617]:refusedconnectfrom183.129.160.229(183.129.160.229)Sep1807:44:07server2sshd[31259]:refusedconnectfrom183.129.160.229(183.129.160.229)Sep1807:44:18server2sshd[31275]:refusedconnectfrom183.129.160.229(183.129.160.229)Sep1807:44:57server2sshd[31342]:refusedconnectfrom183.129.160.229(183.129.160.229)

02 Dec 2017 unauthorized ssh connection attempt

02 Dec 2017 Firewall-block on port: 1701

02 Dec 2017 SNMP/161 MH Probe, BF -

02 Dec 2017 port scan and connect, tcp 4899 (radmin)

03 Dec 2017 MH/MP Probe, Scan -

03 Dec 2017 [portscan] tcp/102 [TSAP]

03 Dec 2017 Firewall-block on port: 502

03 Dec 2017 Sep 14 07:50:31 psad: src: 183.129.160.229 signature match: “MISC VNC communication attempt” (sid: 100202) tcp port: 5900

03 Dec 2017 Sep 13 06:36:59 psad: src: 183.129.160.229 signature match: “MISC HP Web JetAdmin communication attempt” (sid: 100084) tcp port: 8000

03 Dec 2017 SNMP/161 Probe, BF, Hack -

As I mentioned before, around mid to late December 2017 this hosts ports as shown in SHodan consisted of one SSH port and just short of a dozen NTP/UDP ports; below is a logged unauthorize attempt at port scanning NTP:

03 Dec 2017 port scan and connect, tcp 25 (smtp)

03 Dec 2017 [portscan] udp/123 [NTP]

03 Dec 2017 port scan and connect, tcp 4899 (radmin)

Now I will only list more unique examples taken from these logs:

Dec 2017 Attempted to connect 3 times to port 1433 TCP

03 Dec 2017 UA:“Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0” in DroneBL:“listed [SOCKS Proxy]”

03 Dec 2017 [portscan] tcp/1433 [MsSQL] [scan/connect: 5 time(s)]

03 Dec 2017 Jul 5 11:47:21 h2177944 sshd[28021]: Invalid user admin from 183.129.160.229
Jul 5 11:47:23 h2177944 sshd[28021]: Failed password for invalid user admin from 183.129.160.229 port 57304 ssh2
Jul 5 11:47:27 h2177944 sshd[28023]: Failed password for root from 183.129.160.229 port 40700 ssh2
Jul 5 11:47:28 h2177944 sshd[28025]: Invalid user admin from 183.129.160.229

03 Dec 2017 [portscan] udp/123 [NTP]

03 Dec 2017 port scan and connect, tcp 8080 (http-proxy)

When I first became aware of this IP on behalf of a client, the MAC address associated to it was 00:a0:c5:67:71:ca with the user-agent UA:“Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0” for all of the many, many, many instances in the client’s logs.

This user-agent is connected to maybe 98% of the activity for 183.129.160.229 when a user-agent is logged/provided.

If you search the MAC in 00:a0:c5:67:71:ca ond many instances of abuse reported similar to what is logged below solely for 183.129.160.229:

03 Dec 2017
Jun 13 13:49:24 MikroTik htcd.gov.by RDC/VNC input: in:BelPak out:(none), src-mac 00:a0:c5:67:71:ca, proto TCP (SYN), 183.129.160.229*15134->192.168.226.1:3389, len 40
Jun 14 03:05:53 MikroTik RDC/VNC connection input: in:pByFly out:(none), proto TCP (SYN), 183.129.160.229:36617->93.84.93.101:3389, len 40
Jun 14 03:08:03 MikroTik RDC/VNC connection input: in:pByFly out:(none), proto TCP (SYN), 183.129.160.229:36617->93.84.93.101:3389, len 40

03 Dec 2017 Jun 8 18:02:10 psad: src: 183.129.160.229 signature match: “MISC MS Terminal Server communication attempt” (sid: 100077) tcp port: 3389

I think you get the idea; in less than one year our Tyrannosaurus has matured and is dining upon all types of carrion and prey on the Internet.

183.129.160.229 and RATs in the present

In May of 2018, 183.129.160.229 is alive and well. As well as keeping on with all of the attack/scanning variations it enjoyed before, it has become quite the dispensory for RATs, especially Gh0stRAT and Win32/Win64 trojans (likely Meterpreter or Empire variations).

More contemporary X-Force IBM graphed activity from March 2018 onward:

And some current RAT related logs from IPDB starting from https://www.abuseipdb.com/check/183.129.160.229?page=1#report

03 May 2018
TCP_IN 2018-05-02 14:09:08 ["02"]
TCP_IN 2018-04-09 18:51:13 ["**4"]
TCP_IN 2018-04-07 13:47:56 ["02","*00"]
TCP_IN 2018-03-24 16:57:31 {“0”:"8",“2”:"**4"}
TCP_IN 2018-03-23 20:47:40 {“0”:“4",“2”:"8"}
TCP_IN 2018-03-14 10:51:59 [“8080”]
TCP_IN 2018-03-12 19:01:25 [“8080”]
TCP_IN 2018-03-10 18:52:29 {“0”:“6666”,“2”:“8088”}
TCP_IN 2018-03-09 09:38:32 ["24”,“604"]
TCP_IN 2018-03-08 04:19:46 ["8”,“8000”]
TCP_IN 2018-03-07 07:41:32 [“460","24”]
TCP_IN 2018-03-07 04:05:14 * pckt to tcp(24*)
TCP_IN 2018-03-07 00:40:29 ["0"]
TCP_IN 2018-03-06 23:53:21 * pckt to tcp(*2)
TCP_IN 2018-03-06 22:08:59 * pckt to tcp(24)
TCP_IN 2018-03-06 22:03:06 * pckt to tcp(2000)
TCP_IN 2018-03-06 14:54:21 * pckt to tcp(24*)
TCP_IN 2018-03-06 14:28:42 * pckt to tcp(24*)
TCP_IN 2018-03-06 14:23:12 * pckt to tcp(24*)
TCP_IN 2018-03-06 14:18:26 * pckt to tcp(24*)

Notice that the user-agent used in the huge majority of abuse reports hasn’t changed from June 2016 to now:

19 Apr 2018 [httpReq only by ip - not DomainName]
UA:“Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0”

09 Apr 2018 [Aegis] @ 2018-04-10 01:31:01 0100 -> Attempted Administrator Privilege Gain: ET SCAN LibSSH Based Frequent SSH Connections Likely BruteForce Attack

21 Mar 2018 seeing malware CNC

20 Mar 2018 UTM reports 3 instances of Backdoor.Win32.Zegost.L

17 Mar 2018 [DoS Attack: SYN/ACK Scan] from source: 183.129.160.229, port 2323, Friday, March 16, 2018 22:57:50

15 Mar 2018 [DoS Attack: SYN/ACK Scan] from source: 183.129.160.229, port 2323, Thursday, March 15, 2018 12:51:49

15 Mar 2018 Gh0stRAT infection source

13 Mar 2018 Malicious brute force vulnerability hacking attacks

13 Mar 2018 botnet

12 Mar 2018 Attempt to access invalid virtual host name (###.###.###.###:80). Typically used to access “internal” resources improperly exposed externally and “protected” only by a lack of external DNS resolution.

12 Mar 2018 Feb 28 23:09:33 xxx 1,2018/02/28 23:09:32,010401000781,THREAT,spyware,1,2018/02/28 23:09:32,183.129.160.229,xxx,0.0.0.0,0.0.0.0,xxx,unknown-tcp,vsys1,Untrust,DMZ,ethernet1/1,ethernet1/4,xxx,2018/02/28 23:09:32,186916,1,48280,443,0,0,0x80002000,tcp,alert,"",Gh0st.Gen Command and Control Traffic(13264),any,critical,client-to-server,692726,0x8000000000000000,China,United States,0,1203833382790760460,0,0,16,0,0,0,xxx,0,0,N/A,spyware,AppThreat-785-4551,0x0

11 Mar 2018 [infected host:Gh0stRat]in DroneBL:“listed [SOCKS Proxy]”

10 Mar 2018 83.129.160.229 - - [10/Mar/2018:11:49:15 +0200] “Gh0st\xAD\x00\x00\x00\xE0\x00\x00\x00x\x9CKS``\x98\xC3\xC0\xC0\xC0\x06\xC4\x8C@\xBCQ\x182\x94\xF6\xB000\xAC\xA8rc\x00\x01\x11\xA0\x82\x1F\x5C&\x83\xC7K7\x86\x19\xE5n\x0C9\x95n\x0C;\x84\x0F3\xAC\xE8sch\xA8^\xCF4'J\x97\xA9\x82\xE30\xC3\x91h]&\x90\xF8\xCE\x97S\xCBA4L?2=\xE1\xC4\x92\x86\x0B@\xF5\x0CT\x1F\xAE\xAF]” 400 166 “-” “-” “-”

09 Mar 2018 [infected host:Gh0stRat] in DroneBL:“listed [SOCKS Proxy]”

08 Mar 2018 Gh0st.Gen Command and Control traffic from (Attacker) 183.129.160.229

08 Mar 2018 Gh0st.Gen Command and Control Traffic 08 Mar 2018
[SID: 25912] System Infected: Ghostnet Backdoor Activity detected.

08 Mar 2018 Date: 2018-03-07 11:20:19
Affected host:
Detection name: APT - GHOSTRAT - TCP
Protocol: TCP
Traffic direction: Inbound
Related host name:
Source
IP address: 183.129.160.229(183.129.160.229)
Port: 55014
MAC address: 38-10-D5-22-51-55

07 Mar 2018 Bad Request: “Gh0st\xAD\x00\x00\x00\xE0\x00\x00\x00x\x9CKS\x98\xC3\xC0\xC0\xC0\x06\xC4\x8C@\xBCQ\x96\x81\x81\x09H\x07\xA7\x16\x95e<amp>\xA7*\x04$<amp>g \x182\x94\xF6\xB000\xAC\xA8rc\x00\x01\x11\xA0\x82\x1F\x5C`<amp>\x83\xC7K7\x86\x19\xE5n\x0C9\x95n\x0C;\x84\x0F3\xAC\xE8sch\xA8^\xCF4'J\x97\xA9\x82\xE30\xC3\x91h]<amp>\x90\xF8\xCE\x97S\xCBA4L?2=\xE1\xC4\x92\x86\x0B@\xF5`\x0CT\x1F\xAE\xAF]" Bad Request: "Gh0st\xAD\x00\x00\x00\xE0\x00\x00\x00x\x9CKS\x98\xC3\xC0\xC0\xC7K\x80B\xF6\xD4V\x9E\xB3A\xA3 \x96|x0\xC8\xDC\x19%\xDA\x5C\x8B\x1B\xA6H\x15\xA29\xE8M~\xBF9\x98\xB5\xCD\xC2O\x9D\xF2@\x80\xAF\xC2$\x95e\x970\x10\x89~\xB8\xD5\xCA5\xCE\xB1\xEE\xDAI\xC7\x02*\xCF\xCF\xEE\xB1\x17XP\x9E\xE7x\xDC`\xD1\xE7\xA5\x22?\xC3\xE3o\x89\x946=\xE4\x1F(=\x1Db” Bad Request: "Gh0st\xAD\x00\x00\x00\xE0\x00\x00\x00x\x9CKS``\x98\xC3\xC0\xC0\xC7K\x80B\xF6\xD4V\x9E\xB3A\xA3 \x96|x0\xC8\xDC\x19%\xDA\x5C\x8B\x1B\xA6H\x15\xA29\xE8M~\xBF9\x98\xB5\xCD\xC2O\x9D\xF2@\x80\xAF\xC2$\x95e\x970\x10\x89~\xB8\xD5\xCA5\xCE\xB1\xEE\xDAI\xC7\x02
06 Mar 2018 Win.Trojan.ZeroAccess inbound connection

06 Mar 2018 183.129.160.229
Found bot activity
Critical
Backdoor.Win32.Zegost.L
March 6th, 2018

06 Mar 2018 This IP tries to install the gh0st RAT multiple times per day"Gh0st\xAD\x00\x00\x00\xE0\x00\x00\x00x\x9CKS

06 Mar 2018 Bad Request: “\x16\x00\x00\x00AZWAZ\x01\x00\x00\x00x\x9CK\x05\x00\x00f\x00f”

05 Mar 2018 183.129.160.229 - - [05/Mar/2018:12:00:02 +0100] “Gh0st\xad” 400 311

05 Mar 2018 This signature detects Gh0st.Gen Command and Control Traffic

03 Mar 2018 Bad Request: “Gh0st\xAD\x00\x00\x00\xE0\x00\x00\x00x\x9CKS\x98\xC3\xC0\xC0\xC7K\x80B\xF6\xD4V\x9E\xB3A\xA3 \x96|<amp>x0\xC8\xDC\x19%\xDA\x5C\x8B\x1B\xA6H\x15\xA29\xE8M~\xBF9\x98\xB5\xCD\xC2O\x9D\xF2@\x80\xAF\xC2$\x95e\x970\x10\x89~\xB8\xD5\xCA5\xCE\xB1\xEE\xDAI\xC7\x02*\xCF\xCF\xEE\xB1\x17XP\x9E\xE7x\xDC`\xD1\xE7\xA5\x22?\xC3\xE3o\x89\x946=\xE4\x1F(=\x1Db" Bad Request: "Gh0st\xAD\x00\x00\x00\xE0\x00\x00\x00x\x9CKS\x98\xC3\xC0\xC0\xC0\x06\xC4\x8C@\xBCQ\x96\x81\x81\x09H\x07\xA7\x16\x95e\xA7*\x04$g \x182\x94\xF6\xB000\xAC\xA8rc\x00\x01\x11\xA0\x82\x1F\x5C<amp>\x83\xC7K7\x86\x19\xE5n\x0C9\x95n\x0C;\x84\x0F3\xAC\xE8sch\xA8^\xCF4'J\x97\xA9\x82\xE30\xC3\x91h]<amp>\x90\xF8\xCE\x97S\xCBA4L?2=\xE1\xC4\x92\x86\x0B@\xF5\x0CT\x1F\xAE\xAF]” Bad Request: "Gh0st\xAD\x00\x00\x00\xE0\x00\x00\x00x\x9CKS``\x98\xC3\xC0\xC0\xC7K\x80B\xF6\xD4V\x9E\xB3A\xA3 \x96|x0\xC8\xDC\x19%\xDA\x5C\x8B\x1B\xA6H\x15\xA29\xE8M~\xBF9\x98\xB5\xCD\xC2O\x9D\xF2@\x80\xAF\xC2$\x95e\x970\x10\x89~\xB8\xD5\xCA5\xCE\xB1\xEE\xDAI\xC7\x02

02 Mar 2018 MALWARE-CNC Win.Trojan.ZeroAccess inbound connection

01 Mar 2018 cs1=Backdoor.APT.Gh0stRat rt=Mar 01 2018 06:05:38 UTC src=183.129.160.229 cn3Label=cncPort cn3=443 cn2Label=sid cn2=33337710 proto=tcp spt=56716 cs5Label=cncHost cn1Label=vlan cn1=0 dpt=443 cs4Label=link cs6Label=channel cs6=Gh0st

I think you get the idea…

Conclusion:

I do not like to offer conclusions or definitive ideas; in this art anything goes and crazy things happen. I personally like to draw my own conclusions and use similar data that is presented for what I may.

However:

The user-agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0 appears in 99.99999% of the User-agents logged for this IP except a couple of instances where a similar User-agent is logged/reported using a similar agent but with Windows 7 OS; I think this and other factors eliminates the activity just being created through the host being utilized as a SOCKS proxy.

I imagine skiddies doing so would slip up occasionally and have other identifying data logged.

For clients and customers of yours: Security through obscurity is dead; if your systems face the internet they will be tested…there are no ifs and or buts about it…there are hosts scanning the internet constantly looking for a multitude of vulns at once.

One log stated this host exploited a Heartbleed Bug in 2018; they are hitting everything and anything not tied down.

Adversaries are just a difference in circumstance and perspective. I do not consider Black Hats “the bad guys”.

As someone who has competed as a professional fighter, I consider Black Hats just another opponent I may face. I will learn from them and admire their work, taking from it whatever is useful without any Satyrday morning cartoon Good Guy vs. Bad Guy mentality.

I state this as an idea to younger folks starting out in this field…I try to be a hacker with ethics, not an ethical hacker or any other type of figment of marketing or hubris.

Learn what you can from any source without preconceived notions or snap judgements.

“State Actor” tends to be the call made by organizations with shit security who need a scapegoat; yes, they developed custom firmware exploits, but why was their a VNC server with default creds facing the internet to let them in?

I do not understand the business or political makeup of China, though I have been studying the difficulties citizens have with circumventing the Great Firewall.

The lack of user-agent/IP variation over two years and the amount of traffic reaching out to foreign targets directly makes me feel something is up here…there was reports of a gang of hackers operating from this telecoms servers who were arrested in China, but the traffic from here has not ceased in the wake of that arrest in late 2017, early 2018.

And thanks to RickSanchez for the help this morning.

There are no sacred cows here…only cows and BBQ if I’m wrong in any instance…thank you.

-maderas

pry0cc · May 19, 2018, 9:54pm

Wow, this just seems to be pwning everything.

What if it is the chinese secret service?

maderas · May 28, 2018, 3:09am

Sorry for the later reply brother; I just started a new job.

I don’t like to cry state actor, because it seems to many entities in this space use that term to justify poor security practices.

“Our interior IT was exploited by state actors: unlimited funds and resources!”

Yes, but why did you have internet facing RDP/VNC with weak passwords?

But lets face facts: this host has been operating from a teleom in China for 2+ years with poor to zero obfuscation and does not seem hindered by the GFW…

I plan on sharing this with the wider security community to generate some more opinions.

However, I share your opinion brother.

maderas

SEP · May 28, 2018, 7:14am

It makes sense, foreign intelligence is all the rage, and as the NSA showed us, all that really means is collecting as much frivolous information as possible. What was their excuse again? Stop terrorists or some bullcrap like that.
in this example “foreign” is used in the vaguest way humanly possible

Also it’s China we’re talking about, they have a great track record of not only abusing their people, human rights violations, and in general just being dicks to every other nation in the process.

I would not put it past them, the only thing that lands odd about this is that it is so brazen, anyone with two brain cells to rub together can see that this is malicious, no attempt to hide what they are doing. Which furthers this assumption as the government has to know about it and allows it.

pry0cc · May 28, 2018, 7:22am

Oh yeah.

I noticed a few Chinese IPs hit my SSH honeypot a few times. Although they never did anything once they gained access. Is this because they detected it was a honeypot?

maderas · May 28, 2018, 9:08pm

SEP-

We live in interesting times my friend.

CHina has risen to a big 5 superpower.

In the 20th century, they utilize their the potential of their massive workforce to enact a relatively rapid shift that leads them toward becoming the world’s leading manufcaturer.

In order to do this, they also needed the intellectual property toi create the logistical resources necessary to fulfill this aim…I have heard more then one lecture state that a sizeable portion of this intellectual property was gained through industrial espionage.

Growing right beside this rise in manufacturing capacity, you have a state educational/training apparatus that is developing digital operatives.

On the black hat side, I have heard rumors that China has the same sort of dealings with their home grown talent has Russia does: we know who you are, if you do not hit your homeland’s interests we will turn a blind eye, but when we need you, we own you.

This provides countries like China and Russia a tactical advantage countries like the US and UK have failed to capatilize on: a homegrown army of experienced operators who can be brought to the digital battlefield and made effective with minimal investment.

I am a patriot, but I believe this is where many western countries (like the USA) have failed: they believe they can outspend the enemy, but this isn’t true here…like in most conflicts, if you have 10,000 A- grade soldiers and I have 100,000 or 1,000,000 B+ grade soldiers, the B+ army is very likely to win by a massacre.

Like the Grugq and others have said in recent talks, countries like the USA spend more in simplified deployment, potent exploits and pretty much given up on developing/recruiting many high level operators…this is a mistake in my estimation.

Even when DoublePulsar/EternalBlue were largely unpatched, I faced plenty of penetration tests/Red Team engagements where those exploits would only get so you so far…now, what if your teams have their McExploits, but run into a critical target full of patched machines or any number of other situations that depend on at least mid-level manual exploitation knowledges/skills.

And you always have to be worry about one of your button pusshers losing an exploit to the enemy, which must happen quite often, since leaks state the NSA and other state agencies have lost this exploits then found them resold or used by their targets…leaks claim that for the most part, they doi not like to target hackers with these exploits for these reasons.

So now you have China ravaging your homeland infrastructure, they will likley gain your exploits eventually, they are getting better at developing their own or repackaging others, and they have 100x the number of operators who are now A- operators compared to your countries B level operators…

Plus, they do not play by the same political rules as you and neither do the majority of their allies (arguably North Korea, maybe Russia to some extent if even by past intellectual exchanges) and they do not extridite or alienate their home gown talent…

I see China grabbing up as much real estate on the web/Internet as possible, and as we have seen with malware utilize IoT/residential devices for VPN obfuscation and DDOS attacks, all real estate matters now.

And all this power in the hands of a country who is using a social media app for behavior modification of its citizens…cyberpunk is now.

maderas · May 28, 2018, 9:30pm

pry0cc-

I have watched these operators pretty closely; the article itself is a living article and will be added to and edited, with new editions released.

They seem to be playing a smart game: the server scans perpetually for vulnerabilities and seems to change up to attack newer vulns much quicker…these are largely automated attacks…for instance, they still scan for Heartbleed and exploit those machines.

However, I have collected quite a few logs from clients that I cannot utilize due to NDA…what I can tell you is that there are human actors manually exploited machines as well.

Logs willsee the machine attack, and this will be normally automated attacks: bruteforce, now that someone released that automated Metasploit release, I bet it did or does something similar: san, detct, fire off some exploits, move on.

But then my clients logs showed something else: more acute attacks against these hosts sometime later on…so we are talking attacks with a bit more finesse, like LFI/RFI, Curl orother manual bash/terminal commands utilized for offensive action, but with much more thought and precision, and much slower.

When these attacks succeded, the attacker would immediately wget or git Masscan onto the machine, and then tunnel those scans through other hosts.

When I checked public abuse reports for the IP of the machines serving as the tunneling hosts, I almost always found earlier attacks against it or the others and reports of succesful exploitation.

Most of the attacks that appeared to be human targeted high value targets such as .gov sites (which are excellent for carding) where they didn’t want to risk being loud.

What I can also tell you was that I tracked one of these actors a=for about the same length of time as I have watched this hist: they never changed their user-agent or OS and they had a solid work ethic…they were grinding 6 to sometimes 12 hours a day and they had a solid grasp of Linux/Unix/Windows administration (most of their work occured from common terminal utilities rather than using some garbage Kitploit toy to target RPC, HTTP methods/requests, interrogate Windows shares, etc…

I will tell you what everyone, this is why I will always release my research here first (and I have some projects I am excited to release llater this year)…no where else can I conversate with folks like this.

maderas

system · June 14, 2018, 2:30pm

This topic was automatically closed after 30 days. New replies are no longer allowed.