<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 11/26/2010 9:26 AM, Christian Pena wrote:
    <blockquote cite="mid:4CEFC381.2070307@ststelecom.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      We have seen similar things on our network. I never setup the HMRs
      on the access side of the Acme thinking they would cause a
      substantial increase in CPU usage. Anyone have any luck in doing
      this on a production network? <br>
      <br>
      Thanks,<br>
      <br>
      Chris<br>
    </blockquote>
    <br>
    As an FYI, that is a sipvicious scan against your machine. I've seen
    something to the tune of an 1800% increase in these scans beginning
    on Halloween of this year (<a class="moz-txt-link-abbreviated" href="http://www.infiltrated.net/voipabuse/logs/">www.infiltrated.net/voipabuse/logs/</a>) and
    I try to keep track of what is going on. As long as your devices are
    on the 'net, you will see the debris. Not much you can do other than
    try blocking either entire netblocks or individual hosts.<br>
    <br>
    While I've had honeypots up tracking what it is these guys do, it is
    becoming increasingly difficult due to the mass amounts of scans. I
    have a theory that about one or two dozen groups have created a
    distributed SIP scanning method as when I see one attacker plop up
    from one netblock, about 1/2 dozen follow suit immediately after. My
    view is that they're sending multiple scans out in the event that if
    one is detected and blocked, the others will pick up and continue
    on.<br>
    <br>
    <pre><tt>Attacker1 --> scans --> 100-200</tt></pre>
    <pre><tt>Attacker2 --> scans --> 100-200</tt></pre>
    <pre><tt>
Attacker1 is detected and blocked when it reaches say extension 150</tt></pre>
    <pre><tt>Attacker3 pops up and scans 151 - 200

</tt></pre>
    I see these come through now with some pretty specific targets that
    make little sense at first, but when I parse out and analyze the
    logs, I come to what I concluded above. For those who've read about
    the VoIP Abuse Project or perhaps have heard the TUC conference I
    was on, there is a lot more sophistication going on right now. As a
    test, I changed the passwords of about 100 honeypot accounts I have
    on the net, within 2-3 hours, they had re-established connections to
    try to place calls through. From what I see, two distinct attacks:
    1st, enumeration (someone tries to find an account) 2nd, when an
    account is found a completely different host sends calls. The
    individual's IP SENDING the call NEVER (ever, ever, ever) is on any
    bruteforcing log. I truly believe the individual sending the calls
    or at least trying to is an actual person and not some script. I
    base this on the fact of the timing parameters involved with dial
    plan tinkering.<br>
    <br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT

"It takes 20 years to build a reputation and five minutes to
ruin it. If you think about that, you'll do things
differently." - Warren Buffett

227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
<a class="moz-txt-link-freetext" href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E">http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E</a></pre>
  </body>
</html>