20 Jun
2016
20 Jun
'16
8:14 p.m.
Johnny Billquist <bqt at softjar.se> writes:
On 2016-06-20 19:30, Brian Schenkenberger, VAXman-
wrote:
Well, for one, trying brute force attacks agains services. Here are some of
the FTP attempts from 108.31.82.9.
admin
support
guest
vizxv
123
1234
12345
123456
cisco
admin
service
1234
root
support
vizxv
123
12345
123456
xc3511
7ujMko0admin
root
root
support
123
12345
123456
xc3511
smcadmin
1234
xc3511
meinsm
vizxv
admin
admin
service
service
root
root
xc3511
12345
meinsm
dreambox
user
changeme
12345
pass
vizxv
user
changeme
root
I'm guessing that, due to the repeated nature of the usernames attempted, the
system has been logged into by a great many different twits.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se>
writes:
Ah. Sorry for being dense. Thanks.
So what kind of intrusion attempts are we talking about? Essentially
your issue is that someone have a machine on the internet. Getting
access on the machine is easy, and something/someone on that machine is
trying to do something to your machine? On 2016-06-20 18:19, Brian Schenkenberger,
VAXman- wrote:
Well, since I have not yet put any of my systems on HECnet, it should have
been obvious that it's via the internet. ___ _ _ _ __ __ _ _ _
_ ___ _____
/ __| /_\ | \| | \ \ / / /_\ | | | \| | | __| |_ _|
\__ \ / _ \ | .` | \ V / / _ \ | |__ | .` | | _| | |
|___/ /_/_\_\_|_|\_| |_| /_/ \_\ |____| |_|\_| |___|_ |_|
You've allowed this node on HECnet, so I assume somebody on this list knows
who runs it.
Who runs it can always easily be found by http://mim.update.uu.se/nodedb
Please have it secured! It has been used in the
past several
days to try and break into my system(s). It is highly irresponsible to put
access credentials into its SYS$ANNOUNCE allowing ANYBODY access to DCL and
other utilities that can affect systems on the internet. A reasonable way
to allow access would be to have a guest account (restricted/captive) that
can be used to create other login accounts. Validate such accounts with a
valid email address and other schemes that will insure that whomever is on
this system can be vetted in some fashion.
THANK YOU!
I'm curious about what kind of intrusions we're talking about, and over
which network.
In general, I want to keep HECnet more open than what you are suggesting
above, but this also requires that people act responsibly. If there is
abuse, I'd like to know. 
22 Jun
22 Jun
1:02 p.m.
El 20 juny 2016, a les 20:14, Brian Schenkenberger,
VAXman- <system at TMESIS.COM> va escriure:
108.31.82.9.
Uh, I?d bet the simulated 3900 is not the real origin of the attack you are getting. It is
probably behind a home DSL/cable router, whith port 23 redirected to the 3900?, which has
probably a private IP address masqueraded using NAT? So probably the node owner has been
hacked and zombified, regadrless of he having a pet 3900 open to the net.
Anyway, it would be good to send a heads up to the operator. I can?t see any QCOCAL node
in HECNET, so I don?t know ho he is.
J.
3:41 p.m.
Hello!
My thoughts exactly.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Jun 22, 2016 at 7:02 AM, Jordi Guillaumes i Pons
<jg at jordi.guillaumes.name> wrote:
El 20 juny 2016, a les 20:14, Brian
Schenkenberger, VAXman- <system at TMESIS.COM> va escriure:
108.31.82.9.
Uh, I?d bet the simulated 3900 is not the real origin of the attack you are getting. It
is probably behind a home DSL/cable router, whith port 23 redirected to the 3900?, which
has probably a private IP address masqueraded using NAT? So probably the node owner has
been hacked and zombified, regadrless of he having a pet 3900 open to the net.
Anyway, it would be good to send a heads up to the operator. I can?t see any QCOCAL node
in HECNET, so I don?t know ho he is.
J.
5:46 p.m.
On 2016-06-22 13:02, Jordi Guillaumes i Pons wrote:
Thanks. I actually forgot to bring this up. I would be surprised if the
script kiddies of today would have the first clue on how to automate any
penetration attack actually from VMS... So it would be interesting to
actually find out a bit more on what actually happened on the
originating side...
El 20 juny 2016, a les 20:14, Brian
Schenkenberger, VAXman- <system at TMESIS.COM> va escriure:
108.31.82.9.
Uh, I?d bet the simulated 3900 is not the real origin of the attack you are getting. It
is probably behind a home DSL/cable router, whith port 23 redirected to the 3900?, which
has probably a private IP address masqueraded using NAT? So probably the node owner has
been hacked and zombified, regadrless of he having a pet 3900 open to the net. Anyway, it would be good to send a heads up to the
operator. I can?t see any QCOCAL node in HECNET, so I don?t know ho he is.
Haven't updated your database in a while? :-)
http://mim.update.uu.se/nodedb?search=qcocal&field=0&sort=0
Johnny
6:08 p.m.
Thanks. I actually forgot to bring this up. I would be surprised if the script kiddies of
today would have the first clue on how to automate any penetration attack actually from
VMS... So it would be interesting to actually find out a bit more on what actually
happened on the originating side?
At this precise moment, that IP address does not answer PING. Some hours ago, it had an
active FTP server which identified itself as SunOS. I didn?t catch the version. So there
is potentially exploitable stuff there.
> Anyway, it would be good to send a heads up to the
operator. I can?t see any QCOCAL node in HECNET, so I don?t know ho he is.
Haven't updated your database in a while? :-)
http://mim.update.uu.se/nodedb?search=qcocal&field=0&sort=0
I copied the HECNET.idx file you have in the FAL default directory in MIM:: Isn?t that the
good one?
DTR> ready hecnet
DTR> find hecnet with node_name = "QCOCAL"
[0 records found]
23 Jun
23 Jun
1:33 a.m.
On 2016-06-22 18:08, Jordi Guillaumes i Pons wrote:
Well, I assume at the time it was the machine where QCOCAL was, but I
still would not expect that the attack actually happened from VMS. But I
would like to find out for sure.
Either you have an old copy, or something else on your side is broken.
On MIM::
DTR> show dictionary
The current dictionary is DU1:[DECNET]DECNET.DIC;1
DTR> show hecnet
DOMAIN HECNET
USING NODE_REC
ON US:[DECNET]HECNET.IDX;
DTR> find hecnet with node_name="QCOCAL"
[1 Record found]
DTR> print
No record selected, printing whole collection
NODE NODE
NAME AREA NUMBER OWN OWNER ARCHITECTURE CPU
QCOCAL 1 550 susa Supratim Sanyal
?
Unknown 6-Jun-2016
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Thanks. I actually forgot to bring this up. I would be surprised if the script kiddies of
today would have the first clue on how to automate any penetration attack actually from
VMS... So it would be interesting to actually find out a bit more on what actually
happened on the originating side?
At this precise moment, that IP address does not answer PING. Some hours ago, it had an
active FTP server which identified itself as SunOS. I didn?t catch the version. So there
is potentially exploitable stuff there. > Anyway, it
would be good to send a heads up to the operator. I can?t see any QCOCAL node in HECNET,
so I don?t know ho he is.
Haven't updated your database in a while?
:-)
http://mim.update.uu.se/nodedb?search=qcocal&field=0&sort=0
I copied the HECNET.idx file you have in the FAL default directory in MIM:: Isn?t that
the good one?
DTR> ready hecnet
DTR> find hecnet with node_name = "QCOCAL"
[0 records found]
2:05 a.m.
Well, I assume at the time it was the machine where QCOCAL was, but I still would not
expect that the attack actually happened from VMS. But I would like to find out for sure.
Either you have an old copy, or something else on your side is broken.
I had a good copy. I?ve copied the current HECNET.IDX and now QCOCAL appears. I?ll have to
get the users table somehow, but that will be another day :)
>
Anyway, it would be good to send a heads up to the operator. I can?t see any QCOCAL node
in HECNET, so I don?t know ho he is.
Haven't updated your database in a while?
:-)
http://mim.update.uu.se/nodedb?search=qcocal&field=0&sort=0
I copied the HECNET.idx file you have in the FAL default directory in MIM:: Isn?t that
the good one?
DTR> ready hecnet
DTR> find hecnet with node_name = "QCOCAL"
[0 records found]
3073
days inactive
3076
days old
7 comments
4 participants
participants (4)
-
bqt＠softjar.se -
gregg.drwho8＠gmail.com -
jg＠jordi.guillaumes.name -
system＠TMESIS.COM