This post was originally published on this site

When you need to analyze some suspicious pieces of code, it's interesting to detonate them in a sandbox. If you don't have a complete sandbox environment available or you just want to avoid generatin noise on your network, why not route the traffic to a sinkhole or NULL-route (read: packets won't be sent across the normal network and default gateway).

When you inspect a process using the /proc[1] virtual filesystem, there is a "route" file:

remnux@remnux:~$ cat /proc/1180/net/route
Iface    Destination    Gateway     Flags    RefCnt    Use    Metric    Mask        MTU    Window    IRTT                                                       
ens19    00000000    01FEA8C0    0003    0    0    100    00000000    0    0    0                                                                            
ens18    004A10AC    00000000    0001    0    0    0    00FFFFFF    0    0    0                                                                              
ens19    00FEA8C0    00000000    0001    0    0    0    00FFFFFF    0    0    0                                                                              
ens19    01FEA8C0    00000000    0005    0    0    100    FFFFFFFF    0    0    0

It displays the IP routing table assigned to this process. Typically, IP addresses are encoded in little-endian hexadecimal values. They can be easily decoded using a few lines of Python:

gw = "01FEA8C0"
octets = [gw[i:i+2] for i in range(0, len(gw), 2)]
ip = '.'.join(str(int(o, 16)) for o in octets)
print(ip)  # Will return: 1.254.168.192

Does it mean that we could apply a specific routing table to a process? Yes and no… In /proc, the "route" file is read-only.

But, Linux is full of features that many people aren't aware of. One of them are namespaces[2]. It's a kernel feature (introduced around 2016 if I remember well) that provides isolation of system resources between processes (a bit like containers). Each namespace type—such as PID, mount, UTS, network, IPC, and user—isolates a specific aspect of the operating system environment. For example, the network namespace gives processes their own network stack, including interfaces and routing tables. Very interesting!

Let's try this and run our suscipious script in a dedicated namespace. My suspicious script will be super simple:

remnux@remnux:~$ cat sample.sh 
#!/bin/bash
echo "Am I bad?"
curl https://isc.sans.edu

First example, no network connectivity at all!

remnux@remnux:~$ sudo unshare --net bash
root@remnux:/home/remnux# ./sample.sh 
Am I bad?
curl: (6) Could not resolve host: isc.sans.edu
root@remnux:/home/remnux# ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
root@remnux:/home/remnux# ip r
Error: ipv4: FIB table does not exist.
Dump terminated
root@remnux:/home/remnux# exit
remnux@remnux:~$ 

The unshare command (executed as root) will create a new shell in a new namespace with dropped network settings. When curl is executed, it can't resolve isc.sans.edu nor connect to it. We have a complete network isolation.

Second example, let's build a dedicated IP stack that will route packets to another IP address, our synchole. A pair of virtial Ethernet interfaces must be added. In this case, 10.0.0.1 will be the new namespace and 10.0.0.2 the main one.

(Note: I'll change the bash prompt to make it clearer)

remnux@remnux:~$ sudo unshare --net bash
root@remnux:/home/remnux# export PS1="namespace> "
namespace> ip link set lo up
namespace> ip link add veth0 type veth peer name veth1
namespace> ip link set veth0 up
namespace> ip addr add 10.0.0.1/24 dev veth0
namespace> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: veth1@veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b6:5c:6e:ed:c3:62 brd ff:ff:ff:ff:ff:ff
3: veth0@veth1: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether 66:72:35:1f:9f:9e brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 scope global veth0
       valid_lft forever preferred_lft forever
namespace> ip link set veth1 netns 1

On the main namespace (your original shell), create the virtual NIC:

root@remnux:/home/remnux# ip addr add 10.0.0.2/24 dev veth1
root@remnux:/home/remnux# ip link set veth1 up

Back in the new namespace:

namespace> ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.034 ms
^C
--- 10.0.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1023ms
rtt min/avg/max/mdev = 0.020/0.027/0.034/0.007 ms

Let's add a default route to the IP in the main namespace:

namespace> ip route add default via 10.0.0.2
namespace> ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12293ms

If we run a tcpdump on veth1, we can now capture all the network connection attempts from the namespace:

root@remnux:/home/remnux# tcpdump -i veth1 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:02:32.122380 ARP, Request who-has 10.0.0.2 tell 10.0.0.1, length 28
11:02:32.122408 ARP, Reply 10.0.0.2 is-at b6:5c:6e:ed:c3:62, length 28
11:02:32.154271 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 6, length 64
11:02:33.178401 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 7, length 64
11:02:34.202411 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 8, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

Finally, let's verify the routing table of the shell running in the new namespace:

namespace> echo $$
149522

On the main namespace:

root@remnux:/home/remnux# cat /proc/149522/net/route 
Iface    Destination    Gateway     Flags    RefCnt    Use    Metric    Mask        MTU    Window    IRTT                                                       
veth0    00000000    0200000A    0003    0    0    0    00000000    0    0    0                                                                              
veth0    0000000A    00000000    0001    0    0    0    00FFFFFF    0    0    0  

(0x0200000A = 10.0.0.2)

Done! The current configuration is very basic and does not provide, amongst others, a DNS. Your sinkholed sample won't be able to resolve FQDN. Also, you could really route the packets by enabling ip_forward and NAT the traffic. 

WARNING: This is not a bullet-proof solution to perform malware analysis: Only the network traffic was isolated!

[1] https://docs.kernel.org/filesystems/proc.html
[2] https://en.wikipedia.org/wiki/Linux_namespaces

Xavier Mertens (@xme)
Xameco
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Since WinRAR 7.10, not all Mark-of-The-Web data (stored in the Zone.Identifier Alternate Data Stream) is propagated when you extract a file from an archive.

Take my DidierStevensSuite.zip file that I downloaded with a browser in normal mode. It has the following Zone.Identifier ADS:

Not only does it have a ZoneId field that indicates the origin of the file (3 = Internet), but it also has ReferredUrl and HostUrl fields that tell use from where the file was downloaded.

If we now open this zip file with WinRAR (version 7.10 or later) and extract one or more files (I extract file AnalyzePESig-crt-x64.exe):

Many archive utilities like WinRAR will propagate the MoTW information: it means that they copy the Zone.Identifier ADS from the downloaded archive to the extracted files.

But if we take a look at the Zone.Identifier ADS from extracted file AnalyzePESig-crt-x64.exe, we see that the ReferredUrl and HostUrl fields have disappeared:

That's because since version 7.10, WinRAR has a privacy feature that redacts the Zone.Identifier information: only the ZoneId field is propagated, not the other fields.

This is a default setting that can be disabled (Zone value only):

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Since the ongoing “ToolShell” exploitation campaign, in which threat actors attack on-premise Sharpoint servers using a chain of two recently published vulnerabilities[1,2,3], is still on top of the cyber security news[4,5,6,7], I thought it might be a good time to look at the question of how quickly do we – as a global society – actually patch actively-exploited vulnerabilities when it comes to our internet-facing systems.

While this is admittedly a very complex topic, and in order to arrive at any detailed conclusions, an in-depth, long-term study would be needed, I believe that even a quick look at available data may show us some general (and hopefully interesting) trends.

Since I – on my own – lack the ability to periodically scan the entire internet and identify how many systems are affected and/or patched when it comes to specific vulnerability, I decided to use data gathered from Shodan using my TriOp tool[8] over the past 30 months. Specifically, I looked at the number of systems that Shodan detected as “vulnerable” to any vulnerability listed in the CISA KEV catalog[9] each day during that timeframe.

It should be mentioned at this point that Shodan is not capable of detecting all of the KEV vulnerabilities (of the approximately 1380 vulnerabilities currently listed in the KEV, it seems to be able to identify only between 200 and 250) and that even for those vulnerabilities it detects, the mechanisms it uses to identify whether a specific system is vulnerable are passive in nature. Therefore, the resulting numbers are – by necessity – not exact, since there is a significant potential for false-positive (or false-negative) identification. Nevertheless, this data still provides a good starting point.

From all the data, I removed CVEs for which Shodan detected less than 50 vulnerable systems (or – to be more exact – 50 public IP addresses) and then generated time charts for all of the rest.

Based on a quick visual analysis, it appears that (if we gloss over the sharp sudden decreases/increases that Shodan is prone to – see e.g. [10] – and omit other Shodan-introduced artifacts, such as sharp increases in detections most likely associated with new detection analytics) for most vulnerabilities, the number of affected systems decreases over time in more or less linear fashion, with a tendency to slowly level out… As you may see below, in some cases, the rate of decrease is slower than in others, which may be due to slower patching or due to Shodan (at least partially) not being able to recognize backported patches.

Data for CVE-2019-0211 

 

Data for CVE-2022-0028

 

Data for CVE-2023-20109

Although for some vulnerabilities, there were occasions when a sharper short-term decrease was visible in the number of vulnerable systems, these were always explainable not by increased patching but by removal of systems that reached their “end of life” from production environments.

This effect can be clearly seen in chart for an Exchange vulnerability CVE-2021-31207 (and in charts for two other Exchange vulnerabilities – CVE-2021-34523 and CVE-2021-34473), where we may observe a significant decrease of vulnerable IP addresses detected by Shodan starting at the end of April 2023 and ending in the early May 2023. This decrease is almost certainly related to the fact that Microsoft ended support for Exchange 2013 (which was affected by the vulnerability/vulnerabilities)  on April 11, 2023[11].

Data for CVE-2021-31207

To sum up, although we need to take the Shodan numbers with a grain of salt, and although vulnerabilities in CISA KEV may not necessarily be the most important ones from everyone’s perspective, from what we’ve shown, it seems that even in July of 2025, the answer to the question of “How quickly do we patch?” is still “Not nearly quickly enough!”.

And while we’ve historically seen cases of vulnerabilities, where patching was relatively fast and the remaining “vulnerable population” was nearly insignificant (such as CVE-2019-19781 AKA “Shitrix”)[12], these – sadly – still seem to be the exception, rather than the rule…

 

[1] https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
[2] https://www.cisa.gov/news-events/alerts/2025/07/20/microsoft-releases-guidance-exploitation-sharepoint-vulnerability-cve-2025-53770
[3] https://research.eye.security/sharepoint-under-siege/
[4] https://www.bleepingcomputer.com/news/microsoft/microsoft-sharepoint-zero-day-exploited-in-rce-attacks-no-patch-available/
[5] https://thehackernews.com/2025/07/critical-microsoft-sharepoint-flaw.html
[6] https://www.securityweek.com/sharepoint-under-attack-microsoft-warns-of-zero-day-exploited-in-the-wild-no-patch-available/
[7] https://www.helpnetsecurity.com/2025/07/20/microsoft-sharepoint-servers-under-attack-via-zero-day-vulnerability-with-no-patch-cve-2025-53770/
[8] https://isc.sans.edu/diary/27034
[9] https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[10] https://isc.sans.edu/diary/SSL+20+turns+30+this+Sunday+Perhaps+the+time+has+come+to+let+it+die/31664
[11] https://learn.microsoft.com/en-us/troubleshoot/exchange/administration/exchange-2013-end-of-support
[12] https://isc.sans.edu/diary/26900

———–
Jan Kopriva
LinkedIn
Nettles Consulting

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.