Announcement

Collapse
No announcement yet.

Anyone a cryptologist?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Anyone a cryptologist?

    Hi folks,

    I have a "type of honeypot" that is monitoring a group that periodically sends encoded messages. The messages do not originate or terminate at the honeypot.

    The messages are infrequent; at most, 1-2 a day.
    They all contain 128 characters: [a-z] and [0-9], with numbers more frequent than letters.

    The delta index of correlation of these strings is consistently between 1.30 and 2.0. (For those unfamiliar with the Phi-test IC, a value of "1" is random, and english text falls between 1.50 and 2.00 with longer strings centered around 1.73.)

    There does not appear to be any obvious period -- it's unlikely a polyalphabetic cipher.

    Here's an example:
    dxnwa86h88h85d444lbko236356422f01048099t91218o4773 0l76xh65975cr3407932kvkr5q2qe01646b9928f2d81sz2303 yu39vt75s71npa19mi05j2u1g480

    The IC=1.46.
    (Side note: I know the 128 character sequence, but I don't know where the "beginning" is since they repeat the sequence. I think "dxn..." is the start, but that could just as easily be in the middle or at the end.)

    If I had to guess at the decoded language, I'd lean toward spanish.

    Does anyone have any ideas how to (1) determine the encoding method and (2) crack it?

  • #2
    Here are my questions:

    - Do any of the 128 character samples have similar sequences?

    - Are these messages involved in anything that is using MIME/ and/or S/MIME?

    Comment


    • #3
      To answer your questions:

      "Do any of the 128 character samples have similar sequences?"
      Yes/No.
      Numbers are ALWAYS more prevelant than letters.
      Each number appears between 5% and 10% of the time (percentage varies by number and message), and each letter is usually less than 2% of the entire string.

      I suspect that each set of 128 characters uses a different key.
      In one message "4" may appear 9% of the time and "0" appears 5%. In another message, "9" may appear 8% and "4" may appear 5%...


      "Are these messages involved in anything that is using MIME/ and/or S/MIME?"
      No.
      They are text strings embedded in HTML.
      The HTML content never changes, but the embedded strings do.
      Basically, they make it look like a web page, but they hide these strings in it. The web page is "borrowed" from some other site. It's essentially a covert channel being camaflouged by HTML.

      This group appears to:
      - Generate their string.
      - Hide it within the HTML.
      - Send the HTML to other members.
      - Pull out the string.
      - Decode and go...

      -guano

      Comment


      • #4
        could you post the html? sometimes context is helpful

        Comment


        • #5
          One thing's pretty obvious--this isn't ciphertext generated from any general-issue encryption algorithm. As you noted, it's not even in the vicinity of random. Also (and I'm assuming you have not altered the case of the text), it uses only lower-case letters and numbers. No way you get that w/ any well written block cipher or public key.

          If it is ciphertext at all, I'd guess it's only some soft of stream substitution cipher. If it's homophonic substitution (multiple replacement characters may be substituted for any given plaintext char), it's obviously going to be tougher than simple char for char substitution.

          Have you looked into the possibility that there are multiple-character substitutions for single chars in the plaintext (polygram substitution)? Might be helpful also to remember that the spaces have most likely been removed from the plaintext before encr.

          I wish I had more time to look at this. I hate letting a good challenge pass by.

          Comment


          • #6
            guano,
            My next questions are:
            -Are we sure this is not a type of session key/id, document cookie, unique identifier? Have you run any tests to rule this out entirely?

            -What are the html tags that encapsulates this 128 character string ?

            -I have seen similar pseudo-crypto like this applied on various kiddie sites. Most of the time they are using cheaply, and freely made public scripts that use the product of the length of the message, others use the ascii value of the character in. I have also built a cracker (win32 cli) for this, it would be interesting to see if any results prove positive.

            -one more thing, if they are really trying to keep their stuff ghetto-hush-hush it is possible they are using an OTP... very simple and effective, and the only way you are practically going to decrypt or analyze their crypto is if they start to get lazy and recycle thier xor tables... I am not sure how many of these 128 character samples you have but I would look around for some type of padding, perhaps something they missed in their OTP design, especially since each message is the same size block...

            Feel free to email me at blackwave@hush.com with a few more samples of these 128 character strings, and please provide the above answers to my questions.

            FYI, in lieu of DEFCON 11 I am sure most everyone as myself are busy getting ready.

            Comment


            • #7
              Originally posted by blackwave
              guano,
              My next questions are:
              -Are we sure this is not a type of session key/id, document cookie, unique identifier? Have you run any tests to rule this out entirely?
              It could be -- I haven't ruled it out.
              But, I know that multiple people have received similar strings. ("Similar" meaning ">80% identical.) I have even received similar strings that are >80% identical, without being duplicates.


              -What are the html tags that encapsulates this 128 character string ?
              I am emailing you a few samples.



              -I have seen similar pseudo-crypto like this applied on various kiddie sites. Most of the time they are using cheaply, and freely made public scripts that use the product of the length of the message, others use the ascii value of the character in. I have also built a cracker (win32 cli) for this, it would be interesting to see if any results prove positive.
              Could you give me a pointer to these tools?
              This definitely could be what they are doing.


              -one more thing, if they are really trying to keep their stuff ghetto-hush-hush it is possible they are using an OTP... very simple and effective, and the only way you are practically going to decrypt or analyze their crypto is if they start to get lazy and recycle thier xor tables... I am not sure how many of these 128 character samples you have but I would look around for some type of padding, perhaps something they missed in their OTP design, especially since each message is the same size block...
              I have 11 samples that came via my site. I know a few other people who have also received them, so I can probably get a few dozen (if not a hundred) samples.


              FYI, in lieu of DEFCON 11 I am sure most everyone as myself are busy getting ready.
              I understand.

              Thanks for the suggestions.

              Comment

              Working...
              X