{"id":504,"date":"2025-07-06T19:32:55","date_gmt":"2025-07-06T19:32:55","guid":{"rendered":"https:\/\/epbrtcybersecurityportfolio.xyz\/?p=504"},"modified":"2025-07-06T19:32:55","modified_gmt":"2025-07-06T19:32:55","slug":"ids-ips-evasion","status":"publish","type":"post","link":"https:\/\/epbrtcybersecurityportfolio.xyz\/?p=504","title":{"rendered":"IDS\/IPS Evasion"},"content":{"rendered":"\n

Exercise 1<\/strong><\/h3>\n\n\n\n

Description:<\/strong>
Examine the TCP session between hosts 192.168.1.103 and 192.168.1.104. There is something that is nonstandard about this session. What is it, and why might it cause an IDS evasion?<\/strong><\/p>\n\n\n\n

    \n
  1. Does the session get established?<\/strong><\/li>\n<\/ol>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    In Packet 64, the client at 192.168.1.104<\/strong> tried to establish a connection with the server at 192.168.1.103<\/strong>. Instead of acknowledging the connection, host 192.168.1.103<\/strong> sent a TCP packet with an SYN flag to the host at 192.168.1.104<\/strong>. In Packet 66, the client responded with a Syn Ack packet. This packet is flagged as a retransmission as there was a time lapse of 30 seconds between pack 65 and 66. What seems to have happened is that since he did not receive a response to his Syn packet, the client retransmitted it while at the same time acknowledging the Syn packet sent by host 192.168.1.103<\/strong>. The server sent an Ack package in packet 67 to complete the handshake and the session was established. This is what is called a “four-way handshake” and it might lead to IDS\/IPS evasion as this session will not be tracked since it is not a conventional three-way handshake. <\/p>\n\n\n\n

    2. Can Snort find the malicious content?<\/strong><\/p>\n\n\n\n

    One of the connections that is present in the evade.pcap<\/code> file has content that looks like this:<\/strong><\/p>\n\n\n\n

    21:56:47.400000 IP 184.168.221.65.52342 > 10.1.15.80: Flags [P.], seq 143:463, ack 1, win 8192, length 421
    HTTP: GET \/EVILSTUFF HTTP\/1.1..Host: example.com..User-Agent: curl\/7.35.0..Accept: \/<\/em>\u2026.<\/p>\n\n\n\n

    We can clearly see GET \/EVILSTUFF HTTP\/1.1<\/code> in the packet. Let\u2019s see if we can alert on that using this alert:<\/strong><\/p>\n\n\n\n

    alert http (msg: “Evil 1 in URI”; content: “EVIL”; sid:10000005; rev:1;)<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Let\u2019s run Snort and see how it does.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The alert was not triggered. <\/p>\n\n\n\n

    3. Can Zeek find it?<\/strong><\/p>\n\n\n\n

    Let\u2019s create a Zeek signature specifically designed to find that EVIL URL request. Please create a file named evil.sig<\/code> that contains:<\/strong><\/p>\n\n\n\n

    signature Evil {
    ip-proto == tcp
    dst-port == 80
    payload \/EVIL\/
    event “EVIL URL!”
    }<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Let\u2019s run Zeek against the evade.pcap<\/code> file and see if Zeek finds the known signature:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Zeek also fails to find the malicious content. <\/p>\n\n\n\n

    Exercise 2<\/strong><\/p>\n\n\n\n

    Description: Look at the HTTP traffic between hosts 10.246.50.2 and 10.246.50.6.<\/strong><\/p>\n\n\n\n

    Examine the HTTP headers on the GET request. What type of attack is this, and what does the code instruct the HTTP server to do? Was the attack successful? How do you know?<\/strong><\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The User Agent looks abnormal. Normally it indicates the browser version used by the client, but in this case, it looks like an empty function followed by a ping command:<\/p>\n\n\n\n

    User-Agent: () { :;}; \/bin\/ping -c1 10.246.50.2<\/p>\n\n\n\n

    Searching for this kind of exploit online, I found out that this is a Shellshock vulnerability that is delivered via the User-Agent HTTP header value because the User-Agent is an environment variable.<\/p>\n\n\n\n

    If the attack was successful, I should be able to find a ping request sent from the server (10.246.50.6) to the client (10.246.50.2):<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The attack was successful.<\/p>\n\n\n\n

    Exercise 3:<\/strong><\/h3>\n\n\n\n

    Description:<\/strong>
    Look at the traffic between hosts 192.168.1.105 and 192.168.1.103. The fourth record in the exchange between the hosts is a RST from the client 192.168.1.105 to the server 192.168.1.103. However, as you can observe, 192.168.1.105 continues to send traffic and 192.168.1.103 acknowledges it. Explain the reason why traffic is sent and acknowledged after the RST and why it might cause an IDS evasion.<\/strong><\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The fourth packet has a bad TCP checksum, meaning that receiving host 192.168.1.103 will drop it, permitting the subsequent sent and acknowledged packets. Some IDS\/IPS systems do not validate the TCP checksum and therefore may stop tracking the session because it sees the RST. This would cause an evasion because the session continues and the destination host receives the malicious traffic without the IDS\/IPS being aware of it.<\/p>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    Exercise 1 Description:Examine the TCP session between hosts 192.168.1.103 and 192.168.1.104. There is something that is nonstandard about this session. What is it, and why might it cause an IDS evasion? In Packet 64, the client at 192.168.1.104 tried to establish a connection with the server at 192.168.1.103. Instead of acknowledging the connection, host 192.168.1.103 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-504","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/504","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=504"}],"version-history":[{"count":5,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/504\/revisions"}],"predecessor-version":[{"id":545,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/504\/revisions\/545"}],"wp:attachment":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=504"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=504"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=504"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}