I would like to implement a sniffer for incident response and forensic investigations, to sniff the traffic and identifying malicious packets and C2 (C&C -Command and Control) IP.
In incident response i can't install npcap/winpcap or other librairies detected by antivirus softwares and i should use the faster way to sniff the local traffic. So i would like to develop a simple CLI sniffer (it must be launched on Windows core servers) in a simple executable file to copy/paste it on the server and launch it with admin privileges.
Context example: a ransomware is running on a server and exfiltrate data, there are some NAT (Network Address Translation) between firewalls and the server (so it's difficult to identifying the the malicious traffic).
I write a POC in python on my github.
How i use my raw socket:
from socket import socket, AF_INET6, SOCK_RAW, IPPROTO_IP, IPPROTO_IPV6, IPV6_PKTINFO, SIO_RCVALL, RCVALL_ON, RCVALL_OFF
sock = socket(AF_INET6, SOCK_RAW, IPPROTO_IP)
sock.bind(("<IPv6 address>", 0))
sock.setsockopt(IPPROTO_IPV6, IPV6_PKTINFO, 0)
sock.ioctl(SIO_RCVALL, RCVALL_ON)
while True:
data, source_address = sock.recvfrom(65535)
sock.ioctl(SIO_RCVALL, RCVALL_ON)
sock.close()
What i get when i sniff a ICMPV6 packet:
0000 80 00 68 62 00 01 42 dc 61 62 63 64 65 66 67 68 ..hb..B.abcdefgh
0010 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 ijklmnopqrstuvwa
0020 62 63 64 65 66 67 68 69 bcdefghi
It's just the data section without any IPv6 headers so i can't see IPv6 address and protocol type (so i can't parse data).
What i want:
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 00 ..............`.
0010 00 00 00 28 3a 80 fe 80 00 00 00 00 00 00 12 23 ...(:.*........Z
0020 34 45 56 65 67 78 fe 80 00 00 00 00 00 00 00 00 :(B.#.*..P#.....
0030 00 00 00 00 12 23 80 00 68 6a 00 01 42 d4 61 62 .... ...hj..B.ab
0040 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 cdefghijklmnopqr
0050 73 74 75 76 77 61 62 63 64 65 66 67 68 69 stuvwabcdefghi
Here i have the Ethernet frame, i would like it but for if you can help me to get only the IPv6 headers, it's okay. If you know how i can get the full ethernet frame, packet and segment it's better for me.
I see IPV6_HDRINCL but it's only to send IPV6 headers not to receive it and i see this RFC, i don't find what i search.
Related
Short Version
Is there any documentation on the Outlook RenPrivateAppointment clipboard format used to transfer appointments?
Long version
As a reminder, for anything on the clipboard, the source application can present you the data in a number of different formats. The receiver can go through the list, in order, and decide which format it understands the best.
In the case of my Outlook appointment, the formats are:
0: "RenPrivateSourceFolder" (IStream)
1: "RenPrivateMessages" (IStream)
2: "RenPrivateItem" (HGlobal)
3: "FileGroupDescriptor" (HGlobal)
4: CFSTR_FILEDESCRIPTOR (HGlobal)
5: CFSTR_FILENAME (File)
6: CFSTR_FILECONTENTS (IStream, IStorage)
7: "Object Descriptor" (HGlobal)
8: "RenPrivateAppointment" (IStream)
9: CF_TEXT (HGlobal)
10: CF_UNICODETEXT (HGlobal)
Looking at the content of the various formats, the most promising looks like the RenPrivateAppointment format:
01 00 00 00 C0 C8 1E 0D 60 CE 1E 0D 01 00 00 00 ....ÀÈ.`Î......
6A CB 1E 0D 79 CB 1E 0D 41 00 00 00 41 73 6B 20 jË..yË..A...Ask
71 75 65 73 74 69 6F 6E 20 61 62 6F 75 74 20 61 question about a
70 70 6F 69 6E 74 6D 65 6E 74 20 63 6C 69 70 62 ppointment clipb
6F 61 72 64 20 66 6F 72 6D 61 74 20 6F 6E 20 53 oard format on S
74 61 63 6B 6F 76 65 72 66 6C 6F 77 00 02 00 00 tackoverflow...
00 02 00 00 00 18 00 00 00 00 00 00 00 BC B9 6E ............¼¹n
9C 12 F8 D3 43 AC B7 74 81 5E F0 3D FC 04 D2 97 œ.øÓC¬·t.^ð=ü.Ò—
00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 ...............
00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 FF 92 81 02 41 00 73 00 6B 00 20 00 71 00 75 .ÿ’.A.s.k. .q.u
00 65 00 73 00 74 00 69 00 6F 00 6E 00 20 00 61 .e.s.t.i.o.n. .a
00 62 00 6F 00 75 00 74 00 20 00 61 00 70 00 70 .b.o.u.t. .a.p.p
00 6F 00 69 00 6E 00 74 00 6D 00 65 00 6E 00 74 .o.i.n.t.m.e.n.t
00 20 00 63 00 6C 00 69 00 70 00 62 00 6F 00 61 . .c.l.i.p.b.o.a
00 72 00 64 00 20 00 66 00 6F 00 72 00 6D 00 61 .r.d. .f.o.r.m.a
00 74 00 20 00 6F 00 6E 00 20 00 53 00 74 00 61 .t. .o.n. .S.t.a
00 63 00 6B 00 6F 00 76 00 65 00 72 00 66 00 6C .c.k.o.v.e.r.f.l
00 6F 00 77 00 00 00 01 00 00 00 00 00 FF FF FF .o.w.........ÿÿÿ
FF ÿ
Some of this can be interpreted:
Clipboard format "RenPrivateAppointment"
01 00 00 00 ; always 0x00000001 (Version 1?)
C0 C8 1E 0D ; Start day of appt. minutes from 1/1/1601 0x0D1EC8C0 = 220,121,280 minutes = 7/11/2019 12:00 am
60 CE 1E 0D ; End day of appt. minutes from 1/1/1601 0x0D1ECE60 = 220,122,720 minutes = 7/12/2019 12:00 am
01 00 00 00 ; 0x00000001 (fixed)
6A CB 1E 0D ; Start of appt. minutes from 1/1/1601 0x0D1ECB6A = 220,121,962 minutes = 7/11/2019 11:22 am
79 CB 1E 0D ; End of appt. minutes from 1/1/1601 0x0D1ECB79 = 220,121,977 minutes = 7/11/2019 11:37 am
; "Ask question about appointment clipboard format on Stackoverflow.\0"
41 00 00 00 ; String length prefix, including null terminator (0x00000041 = 65 characters)
41 73 6B 20 71 75 65 73 Ask ques
74 69 6F 6E 20 61 62 6F tion abo
75 74 20 61 70 70 6F 69 ut appoi
6E 74 6D 65 6E 74 20 63 ntment c
6C 69 70 62 6F 61 72 64 lipboard
20 66 6F 72 6D 61 74 20 format
6F 6E 20 53 74 61 63 6B on Stack
6F 76 65 72 66 6C 6F 77 overflow
00 .
02 00 00 00 ; 0x0000002 = 2
02 00 00 00 ; 0x0000002 = 2
18 00 00 00 ; 0x00000018 = 24
00 00 00 00 ; 0x00000000 = 0
BC B9 6E 9C 12 F8 D3 43 ; always
AC B7 74 81 5E F0 3D FC ; always
04 D2 97 00 ; varies (~32 ticks per day) 0x0097D204 = 9,949,700
00 00 00 00
00 00 00 00
02 00 00 00 ; 0x00000002 = 2
00 00 00 00
01 00 00 00 ; 0x00000001 = 1
00 00 00 00
00 00 00 00
00 00 00 00
FF 92 81 02 ; always 0x028192FF
; N"Ask question about appointment clipboard format on Stackoverflow\0"
41 00 73 00 6B 00 20 00 71 00 75 00 65 00 73 00 A.s.k. .q.u.e.s.
74 00 69 00 6F 00 6E 00 20 00 61 00 62 00 6F 00 t.i.o.n. .a.b.o.
75 00 74 00 20 00 61 00 70 00 70 00 6F 00 69 00 u.t. .a.p.p.o.i.
6E 00 74 00 6D 00 65 00 6E 00 74 00 20 00 63 00 n.t.m.e.n.t. .c.
6C 00 69 00 70 00 62 00 6F 00 61 00 72 00 64 00 l.i.p.b.o.a.r.d.
20 00 66 00 6F 00 72 00 6D 00 61 00 74 00 20 00 .f.o.r.m.a.t. .
6F 00 6E 00 20 00 53 00 74 00 61 00 63 00 6B 00 o.n. .S.t.a.c.k.
6F 00 76 00 65 00 72 00 66 00 6C 00 6F 00 77 00 o.v.e.r.f.l.o.w.
00 00 ..
01 00 ; padding to DWORD
00 00 00 00
FF FF FF FF ; footer
Is there any documentation on RenPrivateAppointment, or any other the other formats that would allow rich interactions by the user?
Note: This is not automating Outlook. This is handling the IDataObject placed on the clipboard by Outlook. I want to retrieve:
start time
end time
description
See also
C# parse outlook calendar item (i'm not in C#)
microsoft.public.win32.programmer.ole: Identify correctly outlook items in Drag and Drop.
There is a project on GitHub that parses the RenPrivateAppointment clipboard format: https://github.com/yasoonOfficial/outlook-dndprotocol
The RenPrivateAppointment format isn't documented. You may read about that on the DragDrop Event in Outlook Calendar thread which has an official comment from a VSTO team member. Also, you may take a look at the Drag and Drop with Outlook page.
Application is reading the message from MQ but showing null. Queue is empty after starting the application. When I stop the application it is going back to the queue and showing as an uncommitted message
protected final XaTransactedJmsMessageReceiver.ThreadContextLocal context = new XaTransactedJmsMessageReceiver.ThreadContextLocal();
JmsThreadContext ctx = context.getContext();
message = ctx.consumer.receive(timeout);
logger.debug("Message : " + message); // showing as a null here
Update :
When I open message on MQ Explorer, Message data bytes shows like below
00000 3C 00 3F 00 78 00 6D 00--6C 00 20 00 76 00 65 00 |����������������|
00010 72 00 73 00 69 00 6F 00--6E 00 3D 00 22 00 31 00 |����������������|
Messages are reading if message like this, then is it reading
00000 3C 3F 78 6D 6C 20 76 65--72 73 69 6F 6E 3D 22 31 |<?xml version="1|
00010 2E 30 22 20 65 6E 63 6F--64 69 6E 67 3D 22 75 74 |.0" encoding="ut|
This looks like MQ related issue, Can some help how the message formatting get changed?
Added Image:
I am a Windows user and my application accepts zip files.
I realized that when the user compresses files with the built in zip compressor in Mac OSX, it results in an extra folder titled "__MACOSX" created in the extracted zip.
I need to handle this folder(__MACOSX) in my application. I just want to know what is in the hidden __MACOSX directory. Is it empty or does it contain some files? And if it contains files, then how many files does it contain? If there are files, is the number of files fixed? What kind of files are there (empty/non-empty etc.)? Need full info.
It's simple to check in Mac OS but I don't have a Mac so I can't figure out what is there in this folder. I searched but couldn't find the answer.
I zipped a folder "Pack" containing the following:
Readme.txt
Image.jpg
Script.sh
Sound.m4a
What's inside "__MACOSX":
Pack (folder)
Pack/.Readme.txt (file)
Pack/.Image.jpg (file)
Pack/.Script.sh (file)
So it seems "__MACOSX" contains a replication of the folder structure being zipped, with hidden files starting with a dot, instead of the real files. However, not all files are there, so it might be difficult to predict how many files (in my test, the real file Sound.m4a don't have a .Sound.m4a equivalent.)
Those "hidden" files are not empty, they are binary files holding metadata.
Why don't you just ignore this "__MACOSX" folder, and delete it, instead of processing it?
Just to add to #Yoric's answer, the hidden files are written in the AppleDouble format, which is originally used to store additional metadata on Unix systems.
Example (GraCoL 2013 ICC):
unzip -d swop SWOP2013_and_GRACoL2013_ICC_Profiles.zip
file swop/__MACOSX/._GRACoL2013_CRPC6.icc
# swop/__MACOSX/._GRACoL2013_CRPC6.icc: AppleDouble encoded Macintosh file
Even without knowing the file format (documented in RFC 1740), you can more or less figure out what is saying. In our case:
$ hexdump -C swop/__MACOSX/._GRACoL2013_CRPC6.icc
00000000 00 05 16 07 00 02 00 00 4d 61 63 20 4f 53 20 58 |........Mac OS X|
00000010 20 20 20 20 20 20 20 20 00 02 00 00 00 09 00 00 | ........|
00000020 00 32 00 00 00 c2 00 00 00 02 00 00 00 f4 00 00 |.2..............|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 00 00 00 00 41 54 54 52 00 00 00 00 00 00 00 f4 |....ATTR........|
00000060 00 00 00 98 00 00 00 5c 00 00 00 00 00 00 00 00 |.......\........|
00000070 00 00 00 00 00 00 00 01 00 00 00 98 00 00 00 5c |...............\|
00000080 00 00 15 63 6f 6d 2e 61 70 70 6c 65 2e 71 75 61 |...com.apple.qua|
00000090 72 61 6e 74 69 6e 65 00 71 2f 30 30 30 31 3b 35 |rantine.q/0001;5|
000000a0 32 33 39 64 33 32 37 3b 47 6f 6f 67 6c 65 5c 78 |239d327;Google\x|
000000b0 32 30 43 68 72 6f 6d 65 2e 61 70 70 3b 31 33 41 |20Chrome.app;13A|
000000c0 39 30 46 46 32 2d 34 43 45 41 2d 34 35 37 33 2d |90FF2-4CEA-4573-|
000000d0 38 37 45 32 2d 32 35 33 41 37 30 35 38 30 34 39 |87E2-253A7058049|
000000e0 44 7c 63 6f 6d 2e 67 6f 6f 67 6c 65 2e 43 68 72 |D|com.google.Chr|
000000f0 6f 6d 65 00 |ome.|
000000f4
We are looking at an instance of the com.apple.quarantine extended attribute, which in this case says the file was downloaded with Chrome. Well, at least it was the case for whoever packed this zip file.
I have a Macbook Pro and am getting contradictory answers when I try to determine its endian-ness.
Method 1
python -c "import sys;print sys.byteorder" tells me I am on a little endian system
Method 2
I have a text file. I used iconv to convert it into UTF16. Its supposed to detect the endianness of the computer and convert it into that format. So here I go:
iconv -f utf-8 -t utf-16 file.txt > utf16.txt
file utf16.txt
utf16.txt: Big-endian UTF-16 Unicode English text
vi utf16.txt works and hexdump -C utf16.txt shows:
00000000 fe ff 00 33 00 39 00 38 00 31 00 36 00 30 00 38 |...3.9.8.1.6.0.8|
00000010 00 09 00 54 00 69 00 61 00 20 00 4a 00 75 00 61 |...T.i.a. .J.u.a|
00000020 00 6e 00 61 00 20 00 52 00 69 00 76 00 65 00 72 |.n.a. .R.i.v.e.r|
00000030 00 09 00 54 00 69 00 61 00 20 00 4a 00 75 00 61 |...T.i.a. .J.u.a|
00000040 00 6e 00 61 00 20 00 52 00 69 00 76 00 65 00 72 |.n.a. .R.i.v.e.r|
00000050 00 09 00 52 00 69 00 6f 00 20 00 54 00 69 00 61 |...R.i.o. .T.i.a|
00000060 00 6a 00 75 00 61 00 6e 00 61 00 2c 00 52 00 69 |.j.u.a.n.a.,.R.i|
00000070 00 6f 00 20 00 54 00 69 00 6a 00 75 00 61 00 6e |.o. .T.i.j.u.a.n|
00000080 00 61 00 2c 00 52 00 ed 00 6f 00 20 00 54 00 69 |.a.,.R...o. .T.i|
00000090 00 6a 00 75 00 61 00 6e 00 61 00 2c 00 54 00 69 |.j.u.a.n.a.,.T.i|
if I convert it to little-endian and manually insert a BOM like this:
( printf "\xff\xfe" ; iconv -f utf-8 -t utf-16le file.txt ) > UTF16LEBOM.txt
file UTF16LEBOM.txt
UTF16LEBOM.txt: Little-endian UTF-16 Unicode English text
vi UTF16LEBOM.txt works
and hexdump -C UTF16LEBOM.txt shows
00000000 ff fe 33 00 39 00 38 00 31 00 36 00 30 00 38 00 |..3.9.8.1.6.0.8.|
00000010 09 00 54 00 69 00 61 00 20 00 4a 00 75 00 61 00 |..T.i.a. .J.u.a.|
00000020 6e 00 61 00 20 00 52 00 69 00 76 00 65 00 72 00 |n.a. .R.i.v.e.r.|
00000030 09 00 54 00 69 00 61 00 20 00 4a 00 75 00 61 00 |..T.i.a. .J.u.a.|
00000040 6e 00 61 00 20 00 52 00 69 00 76 00 65 00 72 00 |n.a. .R.i.v.e.r.|
00000050 09 00 52 00 69 00 6f 00 20 00 54 00 69 00 61 00 |..R.i.o. .T.i.a.|
00000060 6a 00 75 00 61 00 6e 00 61 00 2c 00 52 00 69 00 |j.u.a.n.a.,.R.i.|
00000070 6f 00 20 00 54 00 69 00 6a 00 75 00 61 00 6e 00 |o. .T.i.j.u.a.n.|
00000080 61 00 2c 00 52 00 ed 00 6f 00 20 00 54 00 69 00 |a.,.R...o. .T.i.|
00000090 6a 00 75 00 61 00 6e 00 61 00 2c 00 54 00 69 00 |j.u.a.n.a.,.T.i.|
From this link:
The other approach is to include a magic number, such as 0xFEFF,
before every piece of data. If you read the magic number and it is
0xFEFF, it means the data is in the same format as your machine, and
all is well.
If you read the magic number and it is 0xFFFE (it is backwards), it
means the data was written in a format different from your own. You'll
have to translate it.
Who is right and why am I getting contradictory answers?
"Endian-ness of my Macbook Pro" means nothing. You need to be more specific; different applications will have different impressions. As you've just seen, you can arbitrarily encode bytes in a file. In the end, a series of bytes is just that, and files are ultimately just a series of bytes that can be read in either fashion. In the context of programming (Stack Overflow) what's important is knowing a) Whether the input you are getting is in Big Endian or Little Endian, and b) Whether the output you send should be in Big Endian or Little Endian.
If your question is the conventional reading of files, the answer is usually Little Endian. But, for example, network data tends to be Big Endian.
I'm trying to write a script to extract the original download URL from disk images downloaded with Safari on OS X using xattr, so that I can rename them but still easily obtain their original names for reference.
This command prints the hex representation of the URL that the given file was downloaded from, as an example:
xattr -p com.apple.metadata:kMDItemWhereFroms *.dmg
gives
62 70 6C 69 73 74 30 30 A1 01 5F 10 4F 68 74 74
70 3A 2F 2F 61 64 63 64 6F 77 6E 6C 6F 61 64 2E
61 70 70 6C 65 2E 63 6F 6D 2F 4D 61 63 5F 4F 53
5F 58 2F 6D 61 63 5F 6F 73 5F 78 5F 31 30 2E 36
2E 31 5F 62 75 69 6C 64 5F 31 30 62 35 30 34 2F
30 34 31 35 30 37 33 61 2E 64 6D 67 08 0A 00 00
00 00 00 00 01 01 00 00 00 00 00 00 00 02 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 5C
The URL starts at the 14th byte (if I counted correctly) and is NULL terminated. How can I format this string so that I get a string output as follows:
http://adcdownload.apple.com/Mac_OS_X/mac_os_x_10.6.1_build_10b504/0415073a.dmg
(don't worry, this link doesn't work unless you're logged in to ADC)
...essentially, the same thing Finder will display in Get Info. I tried piping xattr's output to xxd but I'm not sure how to specify the offset so the string starts at the right place.
So, after looking at the binary data returned by xattr -p, I realized that it was actually a binary plist... hence "bplist" at the front of the data. For some reason I didn't notice this before, but in light of this, here's a proper solution that should work on every OS X from 10.5 to 10.8.
To avoid duplication, I'll link to the source instead of pasting it: https://github.com/jakepetroules/wherefrom