CSAM Some more unusual scans

Published: 2013-10-10
Last Updated: 2013-10-15 18:20:02 UTC
by Mark Hofman (Version: 1)
3 comment(s)

Most of us who regularly look at firewall and other logs get to know the usual targets, 22, 5900, 5060, etc.  Most of the time these are fairly obvious and self explanetory.  However on occasion you do see some that are a bit more unusual.  For example this morning a scan was detected along these lines: 

src                             Dest IP                       dport   -->   2xx.xxx.xxx.67         1723 (pptp)   -->   2xx.xxx.xxx.83         1723 (pptp)   -->   2xx.xxx.xxx.96         1723 (pptp)   -->   2xx.xxx.xxx.23         1723 (pptp)   -->   2xx.xxx.xxx.114       1723 (pptp)   -->   2xx.xxx.xxx.200       1723 (pptp)

A port scan looking for PPTP VPN connections, not something you see every day. The next step when a connection is made? not sure,  if you have any packets or logs you can share relating to this that would be much appreciated.  

Another scan picked up was a brute force password guessing attempt with a small change:

Sep 17 13:38:32 zprd sshd[83594]: Invalid user ant from
Sep 17 13:38:36 zprd sshd[83598]: Invalid user office from
Sep 17 13:38:39 zprd sshd[83601]: Invalid user pc from
Sep 17 13:38:43 zprd sshd[83604]: Invalid user bureau from
Sep 17 13:38:46 zprd sshd[83607]: Invalid user jasmin from
Sep 17 13:38:50 zprd sshd[83612]: Invalid user laura from
Sep 17 13:38:53 zprd sshd[83615]: Invalid user david from
Sep 17 13:38:57 zprd sshd[83618]: Invalid user david from
Sep 17 13:39:00 zprd sshd[83621]: Invalid user scanner from
Sep 17 13:39:04 zprd sshd[83624]: Invalid user webmaster from

Instead of guessing the same userid with many passwords, they are guessing one password with many different userids.  Works more often than you would think and also stays below the lockout threshold.   We saw this about April-May last year, but it looks like it is still going strong. 

Enjoy digging. 



Keywords: csam 2013 logs pptp ssh
3 comment(s)

google.com.my DNS hijack

Published: 2013-10-10
Last Updated: 2013-10-10 19:44:20 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

DNS for the Malaysian copy of Google (Google.com.my) got appearanty hijacked. Right now, the hostnames google.com.my and www.google.com.my point to a host in Canada ( 

(thx Alex for capturing the screen shot. My system would not allow me to connect to the IP address anymore). The NS records point to servers that do not appear to be "genuine" as well. Before, the NS records pointed to ns1.google.com and ns2.google.com, which are also authoritative for google.com. Now they point to  sdns1.ovh.ca and ks4003824.ip-142-4-211.net .

The whois information does not reflect that this is a google domain, but it didn't change recently and the site used to host a copy of Google's homepage according to archive.org. It is very much possible that Google uses a third party to operate part of its Malaysia site.

Update (via Twitter from @TheBackpackr): " We're the official co managing the domain for google.com.my @GoogleMsia. We are liaising with MYNIC on the DNS change."

The same group behind this attack also claims to have been successful against other Google country level sites (Burundi and Kenia) recently.


If you haven't yet: start monitoring your DNS data! A quick minimum script to do so in 5 minutes (just cron it... )



ADMIN='your email';

ns=`dig +short NS $TLD  | tail -1`
dig  NS $DOMAIN @$ns  | grep 'IN\tNS' | grep -v '^;' | sort > .$DOMAIN.new
if [ -f .$DOMAIN.old ]; then
   if ! cmp -s .$DOMAIN.old .$DOMAIN.new; then
       cat .$DOMAIN.new | mail -s "Possible $DOMAIN hijack" $ADMIN
       echo possible $DOMAIN hijack

mv .$DOMAIN.new .$DOMAIN.old


(and please change the variable at the top ;-) )

------ Johannes B. Ullrich, Ph.D. SANS Technology Institute Twitter

Keywords: dns google hijack
5 comment(s)
ISC StormCast for Thursday, October 10th 2013 http://isc.sans.edu/podcastdetail.html?id=3593


Diary Archives