Not finding the argus payload of a flow inside the pcap
el draco
eldraco at gmail.com
Wed Jun 3 05:48:26 EDT 2015
Hi Carter and thanks for the explanation!
Occam's razor told me that I was probably not understanding argus
correctly, but I swear I tried!
I will be aware now that I should think about what argus is showing
like "the concatenation of the payloads of all the packets in that
flow up to ARGUS_CAPTURE_DATA_LEN"
thanks again
sebas
On Wed, Jun 3, 2015 at 5:44 AM, Carter Bullard <carter at qosient.com> wrote:
> Hey Sebas,
> I’ve checked out the pcap that you sent, and Argus appears to be doing
> the right thing. Argus assembles its user data from as many packets as
> are needed to fill up the ARGUS_CAPTURE_DATA_LEN.
>
> The example TCP that you showed that has all the “0.0.0.0.” in the user
> data buffers is actually correct. For this TCP, starting on packet #1988
> in your pcap file, there are many hundreds of packets, back to back,
> that contain only 2 bytes in the data payload, hex value 0x3000.
> 0x3000 is coded as "0.” since you are printing in ascii. 0x30 is a ‘0' and
> 0x00 doesn’t have an ascii value, so it will be printed as a ‘.’
>
> So there is a very long stream of 0x3000’s in the payloads of the TCP
> packets, and argus concatenates these tiny payloads to generate a
> 300 byte buffers full of 0x300030003000300030003000…. This is
> correct behavior.
>
> To see the actual hex values of the user data payloads, you need to use
> ra -M printer=hex
>
> which will give you a traditional hex dump output for the user data buffers.
> Or you can use this:
> ra -M printer=encode32
>
> which will printout the hex values in a single line.
>
> So, you can’t find these payload values in the packet capture, because the
> individual packets have very tiny payloads. Nothing in tcpdump or wireshark
> will assemble the payload stream and show what is actually being transported.
>
> Sorry for the confusion,
>
> Carter
>
>> On Jun 2, 2015, at 2:53 PM, el draco <eldraco at gmail.com> wrote:
>>
>> Hi list
>>
>> We have a malware capture that we are analyzing with argus, but we
>> came across some issue that we can not explain: argus is showing some
>> payload that we can not find in the pcap file.
>>
>> The file is : https://mcfp.felk.cvut.cz/publicDatasets/CTU-Malware-Capture-Botnet-120-1/2015-04-22_capture-win4.pcap
>>
>> If we extract the argus flows with some amount of payload data and we
>> print the flows with ra:
>>
>> argus -F argus_bi.long.conf -r 2015-04-22_capture-win4.pcap -w - |ra
>> -n -r - -F ra.conf.realtime |less
>>
>> After 160 flows we can see some lines like these (notice that ra is
>> printing the suser and duser fields:
>>
>> 03:21:39.147159 tcp 147.32.83.57 5552 <?> 10.0.2.104 49227 CON 192
>> 10624 s[120]=0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
>> d[120]=0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
>>
>> Argus is reporting almost 60 flows like this (each one is a flow that
>> timeouted according to our ARGUS_FLOW_STATUS_INTERVAL=3600
>> configuration)
>>
>> The flows indicate that the payload content of some flows have the
>> data: "0.0.0.0.0.0.0.0.0.0.0.".
>>
>> However, if we try to search for this data inside the pcap file by
>> hand, I'm not able to find it. Which is weird:
>>
>> grep "0.0.0.0.0.0.0.0.0.0.0." 2015-04-22_capture-win4.pcap
>> Gives us nothing.
>>
>> Finding inside the traffic with tcpdump gives us nothing:
>> tcpdump -n -s0 -r 2015-04-22_capture-win4.pcap -A|less
>>
>> Strings give us nothing:
>> strings 2015-04-22_capture-win4.pcap |grep "0.0.0.0.0.0.0.0.0.0.0."
>>
>> So my question is, what I'm doing wrong? where is the text being
>> reported by argus coming from?
>>
>> Thanks!
>> Sebas
>>
>>
>>
>> --
>> https://pgp.mit.edu/pks/lookup?op=get&search=0x9D9A358CA10F1601
>> <ra.conf.realtime><argus_bi.long.conf>
>
--
https://pgp.mit.edu/pks/lookup?op=get&search=0x9D9A358CA10F1601
More information about the argus
mailing list