ਇੱਕ ਵਾਰ ਪੈਨਟੈਸਟ 'ਤੇ, ਜਾਂ ਯੂਰੋਲੋਜਿਸਟ ਅਤੇ ਰੋਸਕੋਮਨਾਡਜ਼ੋਰ ਦੀ ਮਦਦ ਨਾਲ ਸਭ ਕੁਝ ਕਿਵੇਂ ਤੋੜਨਾ ਹੈ

ਇਹ ਲੇਖ ਇੱਕ ਬਹੁਤ ਹੀ ਸਫਲ ਪੈਂਟਸਟ ਦੇ ਅਧਾਰ ਤੇ ਲਿਖਿਆ ਗਿਆ ਸੀ ਜੋ ਕਿ ਗਰੁੱਪ-ਆਈਬੀ ਦੇ ਮਾਹਰਾਂ ਨੇ ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ ਕੀਤਾ ਸੀ: ਇੱਕ ਕਹਾਣੀ ਵਾਪਰੀ ਹੈ ਜੋ ਬਾਲੀਵੁੱਡ ਵਿੱਚ ਫਿਲਮ ਲਈ ਅਨੁਕੂਲਿਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਹੁਣ, ਸ਼ਾਇਦ, ਪਾਠਕ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਆ ਇਸ ਦੀ ਪਾਲਣਾ ਕਰੇਗੀ: "ਓ, ਇੱਕ ਹੋਰ PR ਲੇਖ, ਇਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਦਰਸਾਇਆ ਜਾ ਰਿਹਾ ਹੈ, ਉਹ ਕਿੰਨੇ ਵਧੀਆ ਹਨ, ਇੱਕ ਪੈਂਟਸਟ ਖਰੀਦਣਾ ਨਾ ਭੁੱਲੋ." ਖੈਰ, ਇੱਕ ਪਾਸੇ, ਇਹ ਹੈ. ਹਾਲਾਂਕਿ, ਇਸ ਲੇਖ ਦੇ ਪ੍ਰਗਟ ਹੋਣ ਦੇ ਕਈ ਹੋਰ ਕਾਰਨ ਹਨ। ਮੈਂ ਇਹ ਦਿਖਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਪੈਨਟੇਸਟਰ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ, ਇਹ ਕੰਮ ਕਿੰਨਾ ਦਿਲਚਸਪ ਅਤੇ ਗੈਰ-ਮਾਮੂਲੀ ਹੋ ਸਕਦਾ ਹੈ, ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੀ ਮਜ਼ਾਕੀਆ ਹਾਲਾਤ ਪੈਦਾ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਅਸਲ ਉਦਾਹਰਣਾਂ ਦੇ ਨਾਲ ਲਾਈਵ ਸਮੱਗਰੀ ਦਿਖਾਓ।

ਸੰਸਾਰ ਵਿੱਚ ਨਿਮਰਤਾ ਦੇ ਸੰਤੁਲਨ ਨੂੰ ਬਹਾਲ ਕਰਨ ਲਈ, ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਅਸੀਂ ਇੱਕ ਪੈਂਟਸਟ ਬਾਰੇ ਲਿਖਾਂਗੇ ਜੋ ਠੀਕ ਨਹੀਂ ਹੋਇਆ. ਅਸੀਂ ਇਹ ਦਿਖਾਵਾਂਗੇ ਕਿ ਇੱਕ ਕੰਪਨੀ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਮਲਿਆਂ ਦੀ ਇੱਕ ਪੂਰੀ ਸ਼੍ਰੇਣੀ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ, ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਇਹ ਪ੍ਰਕਿਰਿਆਵਾਂ ਮੌਜੂਦ ਹਨ ਅਤੇ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਤੋਂ ਬਚਾਅ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਇਸ ਲੇਖ ਵਿਚ ਗਾਹਕ ਲਈ, ਸਭ ਕੁਝ ਵੀ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਨਦਾਰ ਸੀ, ਸਾਡੀਆਂ ਭਾਵਨਾਵਾਂ ਦੇ ਅਨੁਸਾਰ, ਰਸ਼ੀਅਨ ਫੈਡਰੇਸ਼ਨ ਵਿਚ ਘੱਟੋ-ਘੱਟ 95% ਮਾਰਕੀਟ ਨਾਲੋਂ ਬਿਹਤਰ ਸੀ, ਪਰ ਇੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਬਾਰੀਕੀਆਂ ਸਨ ਜਿਨ੍ਹਾਂ ਨੇ ਘਟਨਾਵਾਂ ਦੀ ਇੱਕ ਲੰਮੀ ਲੜੀ ਬਣਾਈ, ਜੋ ਪਹਿਲਾਂ ਕੰਮ 'ਤੇ ਇੱਕ ਲੰਬੀ ਰਿਪੋਰਟ ਕਰਨ ਲਈ ਅਗਵਾਈ ਕੀਤੀ, ਅਤੇ ਫਿਰ ਇਸ ਲੇਖ ਨੂੰ.

ਇਸ ਲਈ, ਆਓ ਪੌਪਕਾਰਨ 'ਤੇ ਸਟਾਕ ਕਰੀਏ, ਅਤੇ ਜਾਸੂਸੀ ਕਹਾਣੀ ਵਿੱਚ ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ। ਸ਼ਬਦ - ਪਾਵੇਲ ਸੁਪ੍ਰੂਨਯੁਕ, ਗਰੁੱਪ-ਆਈਬੀ ਦੇ "ਆਡਿਟ ਅਤੇ ਕੰਸਲਟਿੰਗ" ਵਿਭਾਗ ਦੇ ਤਕਨੀਕੀ ਪ੍ਰਬੰਧਕ।

ਭਾਗ 1. ਪੋਚਕਿਨ ਡਾਕਟਰ

2018 ਇੱਕ ਗਾਹਕ ਹੈ - ਇੱਕ ਉੱਚ-ਤਕਨੀਕੀ ਆਈਟੀ ਕੰਪਨੀ, ਜੋ ਖੁਦ ਬਹੁਤ ਸਾਰੇ ਗਾਹਕਾਂ ਦੀ ਸੇਵਾ ਕਰਦੀ ਹੈ. ਸਵਾਲ ਦਾ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ: ਕੀ ਇੰਟਰਨੈਟ ਰਾਹੀਂ ਕੰਮ ਕਰਦੇ ਹੋਏ ਬਿਨਾਂ ਕਿਸੇ ਸ਼ੁਰੂਆਤੀ ਜਾਣਕਾਰੀ ਅਤੇ ਪਹੁੰਚ ਦੇ ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ ਡੋਮੇਨ ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸੰਭਵ ਹੈ? ਮੈਨੂੰ ਕਿਸੇ ਵੀ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਦਿਲਚਸਪੀ ਨਹੀਂ ਹੈ (ਓਹ, ਪਰ ਵਿਅਰਥ), ਉਹ ਮਕਸਦ ਨਾਲ ਕੰਮ ਵਿੱਚ ਦਖਲ ਦੇਣ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਰੱਖਦੇ, ਪਰ ਉਹ ਗਲਤੀ ਨਾਲ - ਇੱਕ ਅਜੀਬ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਰਵਰ ਨੂੰ ਰੀਲੋਡ ਕਰ ਸਕਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ। ਇੱਕ ਵਾਧੂ ਟੀਚਾ ਬਾਹਰੀ ਘੇਰੇ ਦੇ ਵਿਰੁੱਧ ਵੱਧ ਤੋਂ ਵੱਧ ਹੋਰ ਹਮਲਾਵਰ ਵੈਕਟਰਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਹੈ। ਕੰਪਨੀ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਅਜਿਹੇ ਟੈਸਟ ਕਰਵਾਉਂਦੀ ਹੈ, ਅਤੇ ਹੁਣ ਨਵੇਂ ਟੈਸਟ ਦੀ ਸਮਾਂ ਸੀਮਾ ਆ ਗਈ ਹੈ। ਹਾਲਾਤ ਲਗਭਗ ਆਮ, ਕਾਫ਼ੀ, ਸਮਝਣ ਯੋਗ ਹਨ. ਆਓ ਸ਼ੁਰੂ ਕਰੀਏ।

ਗਾਹਕ ਦਾ ਇੱਕ ਨਾਮ ਹੈ - ਇਸਨੂੰ "ਕੰਪਨੀ" ਹੋਣ ਦਿਓ, ਮੁੱਖ ਵੈਬਸਾਈਟ ਦੇ ਨਾਲ www.company.ru. ਬੇਸ਼ੱਕ, ਗਾਹਕ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਸ ਲੇਖ ਵਿਚ ਹਰ ਚੀਜ਼ ਵਿਅਕਤੀਗਤ ਹੋਵੇਗੀ.
ਮੈਂ ਨੈੱਟਵਰਕ ਖੋਜ ਦਾ ਸੰਚਾਲਨ ਕਰਦਾ ਹਾਂ - ਇਹ ਪਤਾ ਲਗਾਓ ਕਿ ਗਾਹਕ ਨਾਲ ਕਿਹੜੇ ਪਤੇ ਅਤੇ ਡੋਮੇਨ ਰਜਿਸਟਰ ਕੀਤੇ ਗਏ ਹਨ, ਇੱਕ ਨੈੱਟਵਰਕ ਚਿੱਤਰ ਬਣਾਓ, ਇਹਨਾਂ ਪਤਿਆਂ 'ਤੇ ਸੇਵਾਵਾਂ ਕਿਵੇਂ ਵੰਡੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਮੈਨੂੰ ਨਤੀਜਾ ਮਿਲਦਾ ਹੈ: 4000 ਤੋਂ ਵੱਧ ਲਾਈਵ IP ਪਤੇ। ਮੈਂ ਇਹਨਾਂ ਨੈਟਵਰਕਾਂ ਵਿੱਚ ਡੋਮੇਨਾਂ ਨੂੰ ਵੇਖਦਾ ਹਾਂ: ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਜ਼ਿਆਦਾਤਰ ਗਾਹਕਾਂ ਦੇ ਗਾਹਕਾਂ ਲਈ ਬਣਾਏ ਗਏ ਨੈਟਵਰਕ ਹਨ, ਅਤੇ ਅਸੀਂ ਉਹਨਾਂ ਵਿੱਚ ਰਸਮੀ ਤੌਰ 'ਤੇ ਦਿਲਚਸਪੀ ਨਹੀਂ ਰੱਖਦੇ. ਗਾਹਕ ਵੀ ਇਹੀ ਸੋਚਦਾ ਹੈ।

256 ਪਤਿਆਂ ਦੇ ਨਾਲ ਇੱਕ ਨੈਟਵਰਕ ਰਹਿੰਦਾ ਹੈ, ਜਿਸ ਲਈ ਇਸ ਸਮੇਂ ਤੱਕ IP ਪਤਿਆਂ ਦੁਆਰਾ ਡੋਮੇਨਾਂ ਅਤੇ ਉਪ-ਡੋਮੇਨਾਂ ਦੀ ਵੰਡ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਸਮਝ ਹੈ, ਸਕੈਨ ਕੀਤੀਆਂ ਪੋਰਟਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਦਿਲਚਸਪ ਲੋਕਾਂ ਲਈ ਸੇਵਾਵਾਂ ਦੇਖ ਸਕਦੇ ਹੋ. ਸਮਾਨਾਂਤਰ ਤੌਰ 'ਤੇ, ਹਰ ਕਿਸਮ ਦੇ ਸਕੈਨਰ ਉਪਲਬਧ IP ਪਤਿਆਂ 'ਤੇ ਅਤੇ ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲਾਂਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਬਹੁਤ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਪੈਂਟੇਸਟਰ ਲਈ ਖੁਸ਼ੀ ਅਤੇ ਇੱਕ ਤੇਜ਼ ਜਿੱਤ ਦੀ ਉਮੀਦ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਜਿੰਨੀਆਂ ਜ਼ਿਆਦਾ ਸੇਵਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਹਮਲੇ ਲਈ ਖੇਤਰ ਓਨਾ ਹੀ ਵੱਡਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਆਰਟੀਫੈਕਟ ਲੱਭਣਾ ਓਨਾ ਹੀ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਇੱਕ ਝਾਤ ਮਾਰਨ ਤੋਂ ਪਤਾ ਚੱਲਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਵੱਡੀਆਂ ਗਲੋਬਲ ਕੰਪਨੀਆਂ ਦੇ ਮਸ਼ਹੂਰ ਉਤਪਾਦਾਂ ਦੇ ਵੈੱਬ ਇੰਟਰਫੇਸ ਹਨ, ਜੋ ਕਿ ਸਾਰੇ ਦਿੱਖ ਦੁਆਰਾ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਦਾ ਸਵਾਗਤ ਨਹੀਂ ਹੈ। ਉਹ ਇੱਕ ਉਪਭੋਗਤਾ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ, ਦੂਜਾ ਕਾਰਕ ਦਾਖਲ ਕਰਨ ਲਈ ਖੇਤਰ ਨੂੰ ਹਿਲਾ ਦਿੰਦੇ ਹਨ, ਇੱਕ TLS ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ, ਜਾਂ ਇਸਨੂੰ Microsoft ADFS ਨੂੰ ਭੇਜਦੇ ਹਨ। ਕੁਝ ਇੰਟਰਨੈੱਟ ਤੋਂ ਸਿਰਫ਼ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹਨ। ਕੁਝ ਲਈ, ਤੁਹਾਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਤਿੰਨ ਤਨਖ਼ਾਹਾਂ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਅਦਾਇਗੀ ਗਾਹਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਾਂ ਦਾਖਲ ਕਰਨ ਲਈ ਸਹੀ URL ਨੂੰ ਜਾਣਨਾ ਹੁੰਦਾ ਹੈ. ਚਲੋ, ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਲਈ ਸੌਫਟਵੇਅਰ ਸੰਸਕਰਣਾਂ ਨੂੰ "ਤੋੜਨ" ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ, ਵੈਬ ਪਾਥਾਂ ਵਿੱਚ ਲੁਕੀ ਹੋਈ ਸਮੱਗਰੀ ਦੀ ਖੋਜ ਕਰਨ ਅਤੇ ਲਿੰਕਡਇਨ ਵਰਗੀਆਂ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਤੋਂ ਲੀਕ ਕੀਤੇ ਖਾਤਿਆਂ, ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪਾਸਵਰਡਾਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹੌਲੀ ਹੌਲੀ ਨਿਰਾਸ਼ਾ ਦੇ ਇੱਕ ਹੋਰ ਹਫ਼ਤੇ ਨੂੰ ਛੱਡ ਦੇਈਏ। ਸਵੈ-ਲਿਖਤ ਵੈਬਸਾਈਟਾਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਖੁਦਾਈ ਕਰਨ ਦੇ ਰੂਪ ਵਿੱਚ — ਵੈਸੇ, ਅੰਕੜਿਆਂ ਦੇ ਅਨੁਸਾਰ, ਇਹ ਅੱਜ ਬਾਹਰੀ ਹਮਲੇ ਦਾ ਸਭ ਤੋਂ ਵੱਧ ਹੋਨਹਾਰ ਵੈਕਟਰ ਹੈ। ਮੈਂ ਤੁਰੰਤ ਮੂਵੀ ਬੰਦੂਕ ਨੂੰ ਨੋਟ ਕਰਾਂਗਾ ਜੋ ਬਾਅਦ ਵਿੱਚ ਫਾਇਰ ਕੀਤੀ ਗਈ ਸੀ।

ਇਸ ਲਈ, ਸਾਨੂੰ ਦੋ ਸਾਈਟਾਂ ਮਿਲੀਆਂ ਜੋ ਸੈਂਕੜੇ ਸੇਵਾਵਾਂ ਤੋਂ ਵੱਖਰੀਆਂ ਸਨ। ਇਹਨਾਂ ਸਾਈਟਾਂ ਵਿੱਚ ਇੱਕ ਚੀਜ਼ ਸਾਂਝੀ ਸੀ: ਜੇਕਰ ਤੁਸੀਂ ਡੋਮੇਨ ਦੁਆਰਾ ਸੂਝ-ਬੂਝ ਨਾਲ ਨੈਟਵਰਕ ਖੋਜ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੇ, ਪਰ ਖੁੱਲੇ ਪੋਰਟਾਂ ਲਈ ਸਿਰ-ਆਨ ਦੇਖਦੇ ਹੋ ਜਾਂ ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ ਆਈਪੀ ਰੇਂਜ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਕਮਜ਼ੋਰੀ ਸਕੈਨਰ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਾਈਟਾਂ ਸਕੈਨਿੰਗ ਤੋਂ ਬਚ ਜਾਣਗੀਆਂ ਅਤੇ ਬਸ ਨਹੀਂ ਹੋਣਗੀਆਂ। DNS ਨਾਮ ਜਾਣੇ ਬਿਨਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਸ਼ਾਇਦ ਉਹ ਪਹਿਲਾਂ ਖੁੰਝ ਗਏ ਸਨ, ਘੱਟੋ-ਘੱਟ, ਅਤੇ ਸਾਡੇ ਆਟੋਮੈਟਿਕ ਟੂਲਸ ਨੇ ਉਹਨਾਂ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਲੱਭੀ, ਭਾਵੇਂ ਉਹਨਾਂ ਨੂੰ ਸਿੱਧੇ ਸਰੋਤ ਤੇ ਭੇਜਿਆ ਗਿਆ ਹੋਵੇ.

ਤਰੀਕੇ ਨਾਲ, ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਲਾਂਚ ਕੀਤੇ ਗਏ ਸਕੈਨਰਾਂ ਬਾਰੇ ਕੀ ਪਤਾ ਲੱਗਾ। ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ: ਕੁਝ ਲੋਕਾਂ ਲਈ, "ਪੈਂਟਸਟ" "ਆਟੋਮੇਟਿਡ ਸਕੈਨ" ਦੇ ਬਰਾਬਰ ਹੈ। ਪਰ ਇਸ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਸਕੈਨਰਾਂ ਨੇ ਕੁਝ ਨਹੀਂ ਕਿਹਾ. ਖੈਰ, ਵੱਧ ਤੋਂ ਵੱਧ ਮੱਧਮ ਕਮਜ਼ੋਰੀਆਂ (ਗੰਭੀਰਤਾ ਦੇ ਰੂਪ ਵਿੱਚ 3 ਵਿੱਚੋਂ 5) ਦੁਆਰਾ ਦਿਖਾਇਆ ਗਿਆ ਸੀ: ਕੁਝ ਸੇਵਾ 'ਤੇ ਇੱਕ ਖਰਾਬ TLS ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਪੁਰਾਣਾ ਐਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਸਾਈਟਾਂ 'ਤੇ ਕਲਿੱਕਜੈਕਿੰਗ। ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਆਪਣੇ ਟੀਚੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਾ ਸਕੇਗਾ। ਸ਼ਾਇਦ ਸਕੈਨਰ ਇੱਥੇ ਵਧੇਰੇ ਲਾਭਦਾਇਕ ਹੋਣਗੇ, ਪਰ ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ: ਗਾਹਕ ਖੁਦ ਅਜਿਹੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਖਰੀਦਣ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਆਪਣੇ ਆਪ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦਾ ਹੈ, ਅਤੇ, ਨਿਰਾਸ਼ਾਜਨਕ ਨਤੀਜਿਆਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਉਸਨੇ ਪਹਿਲਾਂ ਹੀ ਜਾਂਚ ਕੀਤੀ ਹੈ.

ਚਲੋ "ਅਸਵਿਧਾਜਨਕ" ਸਾਈਟਾਂ 'ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ। ਪਹਿਲਾ ਇੱਕ ਗੈਰ-ਮਿਆਰੀ ਪਤੇ 'ਤੇ ਇੱਕ ਸਥਾਨਕ ਵਿਕੀ ਵਰਗਾ ਹੈ, ਪਰ ਇਸ ਲੇਖ ਵਿੱਚ ਇਸਨੂੰ wiki.company[.]ru ਹੋਣ ਦਿਓ। ਉਸਨੇ ਤੁਰੰਤ ਇੱਕ ਲੌਗਇਨ ਅਤੇ ਪਾਸਵਰਡ ਵੀ ਮੰਗਿਆ, ਪਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ NTLM ਰਾਹੀਂ। ਉਪਭੋਗਤਾ ਲਈ, ਇਹ ਇੱਕ ਸੰਨਿਆਸੀ ਵਿੰਡੋ ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਉਪਭੋਗਤਾ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਦਰਜ ਕਰਨ ਲਈ ਪੁੱਛ ਰਹੀ ਹੈ। ਅਤੇ ਇਹ ਬੁਰਾ ਅਭਿਆਸ ਹੈ.

ਇੱਕ ਛੋਟਾ ਨੋਟ. ਘੇਰੇ ਦੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਵਿੱਚ NTLM ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ ਖਰਾਬ ਹੈ। ਪਹਿਲਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ ਡੋਮੇਨ ਨਾਮ ਦਾ ਖੁਲਾਸਾ ਹੋਇਆ ਹੈ। ਸਾਡੇ ਉਦਾਹਰਨ ਵਿੱਚ, ਇਹ "ਬਾਹਰੀ" DNS ਨਾਮ ਵਾਂਗ, company.ru ਵੀ ਨਿਕਲਿਆ। ਇਸ ਨੂੰ ਜਾਣਦੇ ਹੋਏ, ਤੁਸੀਂ ਧਿਆਨ ਨਾਲ ਕੁਝ ਖਤਰਨਾਕ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਇਹ ਸਿਰਫ ਸੰਗਠਨ ਦੀ ਡੋਮੇਨ ਮਸ਼ੀਨ 'ਤੇ ਚਲਾਇਆ ਜਾ ਸਕੇ, ਨਾ ਕਿ ਕੁਝ ਸੈਂਡਬੌਕਸ ਵਿੱਚ। ਦੂਜਾ, ਪ੍ਰਮਾਣੀਕਰਨ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਦੁਆਰਾ NTLM (ਸਰਪ੍ਰਾਈਜ਼, ਸੱਜਾ?) ਦੁਆਰਾ ਸਿੱਧਾ ਜਾਂਦਾ ਹੈ, "ਅੰਦਰੂਨੀ" ਨੈਟਵਰਕ ਨੀਤੀਆਂ ਦੀਆਂ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ, ਖਾਤੇ ਨੂੰ ਪਾਸਵਰਡ ਐਂਟਰੀ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਗਿਣਤੀ ਤੋਂ ਵੱਧ ਕਰਨ ਤੋਂ ਰੋਕਣ ਸਮੇਤ। ਜੇਕਰ ਕਿਸੇ ਹਮਲਾਵਰ ਨੂੰ ਲਾਗਇਨ ਪਤਾ ਲੱਗ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਉਹਨਾਂ ਲਈ ਪਾਸਵਰਡ ਅਜ਼ਮਾਏਗਾ। ਜੇਕਰ ਤੁਸੀਂ ਖਾਤਿਆਂ ਨੂੰ ਗਲਤ ਪਾਸਵਰਡ ਦਾਖਲ ਕਰਨ ਤੋਂ ਰੋਕਣ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ, ਤਾਂ ਇਹ ਕੰਮ ਕਰੇਗਾ ਅਤੇ ਖਾਤਾ ਬਲੌਕ ਕੀਤਾ ਜਾਵੇਗਾ। ਤੀਜਾ, ਅਜਿਹੀ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿੱਚ ਦੂਜਾ ਕਾਰਕ ਜੋੜਨਾ ਅਸੰਭਵ ਹੈ। ਜੇ ਕੋਈ ਪਾਠਕ ਅਜੇ ਵੀ ਜਾਣਦਾ ਹੈ ਕਿ ਕਿਵੇਂ, ਕਿਰਪਾ ਕਰਕੇ ਮੈਨੂੰ ਦੱਸੋ, ਇਹ ਅਸਲ ਵਿੱਚ ਦਿਲਚਸਪ ਹੈ. ਚੌਥਾ, ਪਾਸ-ਦ-ਹੈਸ਼ ਹਮਲਿਆਂ ਦੀ ਕਮਜ਼ੋਰੀ। ADFS ਦੀ ਖੋਜ, ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਇਸ ਸਭ ਤੋਂ ਬਚਾਅ ਲਈ ਕੀਤੀ ਗਈ ਸੀ।

Microsoft ਉਤਪਾਦਾਂ ਦੀ ਇੱਕ ਮਾੜੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ: ਭਾਵੇਂ ਤੁਸੀਂ ਅਜਿਹੇ NTLM ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਇਹ ਘੱਟੋ-ਘੱਟ OWA ਅਤੇ Lync ਵਿੱਚ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਥਾਪਤ ਹੋਵੇਗਾ।

ਵੈਸੇ, ਇਸ ਲੇਖ ਦੇ ਲੇਖਕ ਨੇ ਇੱਕ ਵਾਰ ਗਲਤੀ ਨਾਲ ਇੱਕ ਵੱਡੇ ਬੈਂਕ ਦੇ ਕਰਮਚਾਰੀਆਂ ਦੇ ਲਗਭਗ 1000 ਖਾਤਿਆਂ ਨੂੰ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਸਿਰਫ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਬਲੌਕ ਕਰ ਦਿੱਤਾ ਅਤੇ ਫਿਰ ਕੁਝ ਫਿੱਕਾ ਦਿਖਾਈ ਦਿੱਤਾ। ਬੈਂਕ ਦੀਆਂ IT ਸੇਵਾਵਾਂ ਵੀ ਫਿੱਕੀਆਂ ਸਨ, ਪਰ ਸਭ ਕੁਝ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਤੇ ਢੁਕਵੇਂ ਢੰਗ ਨਾਲ ਖਤਮ ਹੋ ਗਿਆ, ਸਾਨੂੰ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਲੱਭਣ ਅਤੇ ਇੱਕ ਤੇਜ਼ ਅਤੇ ਨਿਰਣਾਇਕ ਹੱਲ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣ ਲਈ ਪ੍ਰਸ਼ੰਸਾ ਵੀ ਕੀਤੀ ਗਈ।

ਦੂਜੀ ਸਾਈਟ ਦਾ ਪਤਾ "ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਿਸੇ ਕਿਸਮ ਦਾ ਆਖਰੀ ਨਾਮ.company.ru" ਸੀ। ਇਸਨੂੰ Google ਦੁਆਰਾ ਲੱਭਿਆ, ਪੰਨਾ 10 'ਤੇ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਹੈ। ਇਹ ਡਿਜ਼ਾਈਨ XNUMX ਦੇ ਦਹਾਕੇ ਦੇ ਅਰੰਭ ਤੋਂ ਸੀ, ਅਤੇ ਇੱਕ ਸਤਿਕਾਰਯੋਗ ਵਿਅਕਤੀ ਇਸ ਨੂੰ ਮੁੱਖ ਪੰਨੇ ਤੋਂ ਦੇਖ ਰਿਹਾ ਸੀ, ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ:

ਇੱਥੇ ਮੈਂ "ਹਾਰਟ ਆਫ਼ ਏ ਡੌਗ" ਤੋਂ ਇੱਕ ਸਟਿਲ ਲਿਆ, ਪਰ ਮੇਰੇ ਤੇ ਵਿਸ਼ਵਾਸ ਕਰੋ, ਇਹ ਅਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਾਨ ਸੀ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਰੰਗ ਦਾ ਡਿਜ਼ਾਈਨ ਵੀ ਸਮਾਨ ਟੋਨਾਂ ਵਿੱਚ ਸੀ। ਸਾਈਟ ਨੂੰ ਬੁਲਾਇਆ ਜਾਵੇ preobrazhensky.company.ru.

ਇਹ ਇੱਕ ਯੂਰੋਲੋਜਿਸਟ ਲਈ ਇੱਕ ਨਿੱਜੀ ਵੈੱਬਸਾਈਟ ਸੀ। ਮੈਂ ਹੈਰਾਨ ਸੀ ਕਿ ਇੱਕ ਯੂਰੋਲੋਜਿਸਟ ਦੀ ਵੈੱਬਸਾਈਟ ਇੱਕ ਉੱਚ-ਤਕਨੀਕੀ ਕੰਪਨੀ ਦੇ ਸਬਡੋਮੇਨ 'ਤੇ ਕੀ ਕਰ ਰਹੀ ਸੀ। Google ਵਿੱਚ ਇੱਕ ਤੇਜ਼ ਖੋਜ ਨੇ ਦਿਖਾਇਆ ਕਿ ਇਹ ਡਾਕਟਰ ਸਾਡੇ ਗਾਹਕ ਦੀਆਂ ਕਨੂੰਨੀ ਸੰਸਥਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਸਹਿ-ਸੰਸਥਾਪਕ ਸੀ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਅਧਿਕਾਰਤ ਪੂੰਜੀ ਵਿੱਚ ਲਗਭਗ 1000 ਰੂਬਲ ਦਾ ਯੋਗਦਾਨ ਪਾਇਆ। ਸਾਈਟ ਸ਼ਾਇਦ ਕਈ ਸਾਲ ਪਹਿਲਾਂ ਬਣਾਈ ਗਈ ਸੀ, ਅਤੇ ਗਾਹਕ ਦੇ ਸਰਵਰ ਸਰੋਤਾਂ ਨੂੰ ਹੋਸਟਿੰਗ ਵਜੋਂ ਵਰਤਿਆ ਗਿਆ ਸੀ. ਸਾਈਟ ਨੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਆਪਣੀ ਸਾਰਥਕਤਾ ਗੁਆ ਦਿੱਤੀ ਹੈ, ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਇਹ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕੰਮ ਕਰਨਾ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਸੀ.

ਕਮਜ਼ੋਰੀਆਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਵੈੱਬਸਾਈਟ ਆਪਣੇ ਆਪ ਸੁਰੱਖਿਅਤ ਸੀ। ਅੱਗੇ ਦੇਖਦੇ ਹੋਏ, ਮੈਂ ਕਹਾਂਗਾ ਕਿ ਇਹ ਸਥਿਰ ਜਾਣਕਾਰੀ ਦਾ ਇੱਕ ਸਮੂਹ ਸੀ - ਗੁਰਦੇ ਅਤੇ ਬਲੈਡਰ ਦੇ ਰੂਪ ਵਿੱਚ ਸੰਮਿਲਿਤ ਚਿੱਤਰਾਂ ਦੇ ਨਾਲ ਸਧਾਰਨ html ਪੰਨੇ. ਅਜਿਹੀ ਸਾਈਟ ਨੂੰ "ਤੋੜਨਾ" ਬੇਕਾਰ ਹੈ।

ਪਰ ਹੇਠਾਂ ਵੈੱਬ ਸਰਵਰ ਵਧੇਰੇ ਦਿਲਚਸਪ ਸੀ. HTTP ਸਰਵਰ ਸਿਰਲੇਖ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਇਸ ਵਿੱਚ IIS 6.0 ਸੀ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ ਨੇ ਵਿੰਡੋਜ਼ 2003 ਨੂੰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਜੋਂ ਵਰਤਿਆ ਹੈ। ਸਕੈਨਰ ਨੇ ਪਹਿਲਾਂ ਪਛਾਣ ਕੀਤੀ ਸੀ ਕਿ ਇਹ ਖਾਸ ਯੂਰੋਲੋਜਿਸਟ ਵੈੱਬਸਾਈਟ, ਉਸੇ ਵੈਬ ਸਰਵਰ 'ਤੇ ਦੂਜੇ ਵਰਚੁਅਲ ਹੋਸਟਾਂ ਦੇ ਉਲਟ, PROPFIND ਕਮਾਂਡ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਮਤਲਬ ਕਿ ਇਹ WebDAV ਚਲਾ ਰਹੀ ਸੀ। ਤਰੀਕੇ ਨਾਲ, ਸਕੈਨਰ ਨੇ ਇਹ ਜਾਣਕਾਰੀ ਮਾਰਕ ਜਾਣਕਾਰੀ ਨਾਲ ਵਾਪਸ ਕੀਤੀ (ਸਕੈਨਰ ਰਿਪੋਰਟਾਂ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ, ਇਹ ਸਭ ਤੋਂ ਘੱਟ ਖ਼ਤਰਾ ਹੈ) - ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਸੁਮੇਲ ਵਿੱਚ, ਇਸ ਨੇ ਇੱਕ ਦਿਲਚਸਪ ਪ੍ਰਭਾਵ ਦਿੱਤਾ, ਜੋ ਕਿ ਗੂਗਲ 'ਤੇ ਇੱਕ ਹੋਰ ਖੋਜ ਤੋਂ ਬਾਅਦ ਹੀ ਪ੍ਰਗਟ ਹੋਇਆ ਸੀ: ਸ਼ੈਡੋ ਬ੍ਰੋਕਰ ਸੈੱਟ ਨਾਲ ਜੁੜੀ ਇੱਕ ਦੁਰਲੱਭ ਬਫਰ ਓਵਰਫਲੋ ਕਮਜ਼ੋਰੀ, ਅਰਥਾਤ CVE-2017-7269, ਜਿਸਦਾ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਤਿਆਰ-ਬਣਾਇਆ ਸ਼ੋਸ਼ਣ ਸੀ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ Windows 2003 ਹੈ ਅਤੇ WebDAV IIS 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ ਤਾਂ ਸਮੱਸਿਆ ਹੋਵੇਗੀ। ਹਾਲਾਂਕਿ ਵਿੰਡੋਜ਼ 2003 ਨੂੰ 2018 ਵਿੱਚ ਉਤਪਾਦਨ ਵਿੱਚ ਚਲਾਉਣਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ।

ਸ਼ੋਸ਼ਣ ਮੇਟਾਸਪਲੋਇਟ ਵਿੱਚ ਖਤਮ ਹੋਇਆ ਅਤੇ ਤੁਰੰਤ ਇੱਕ ਲੋਡ ਨਾਲ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਜਿਸਨੇ ਇੱਕ ਨਿਯੰਤਰਿਤ ਸੇਵਾ ਨੂੰ ਇੱਕ DNS ਬੇਨਤੀ ਭੇਜੀ - ਬਰਪ ਸਹਿਯੋਗੀ ਨੂੰ ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ DNS ਬੇਨਤੀਆਂ ਨੂੰ ਫੜਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਮੇਰੇ ਹੈਰਾਨੀ ਲਈ, ਇਸਨੇ ਪਹਿਲੀ ਵਾਰ ਕੰਮ ਕੀਤਾ: ਇੱਕ DNS ਨਾਕਆਊਟ ਪ੍ਰਾਪਤ ਹੋਇਆ ਸੀ. ਅੱਗੇ, ਪੋਰਟ 80 ਦੁਆਰਾ ਇੱਕ ਬੈਕਕਨੈਕਟ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਸੀ (ਭਾਵ, ਸਰਵਰ ਤੋਂ ਹਮਲਾਵਰ ਤੱਕ ਇੱਕ ਨੈਟਵਰਕ ਕਨੈਕਸ਼ਨ, ਪੀੜਤ ਹੋਸਟ 'ਤੇ cmd.exe ਤੱਕ ਪਹੁੰਚ ਦੇ ਨਾਲ), ਪਰ ਫਿਰ ਇੱਕ ਅਸਫਲਤਾ ਵਾਪਰੀ। ਕੁਨੈਕਸ਼ਨ ਦੁਆਰਾ ਨਹੀਂ ਆਇਆ, ਅਤੇ ਸਾਈਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਤੀਜੀ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਬਾਅਦ, ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਤਸਵੀਰਾਂ ਦੇ ਨਾਲ, ਹਮੇਸ਼ਾ ਲਈ ਗਾਇਬ ਹੋ ਗਿਆ.

ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤੋਂ ਬਾਅਦ "ਗਾਹਕ, ਜਾਗੋ, ਅਸੀਂ ਸਭ ਕੁਝ ਛੱਡ ਦਿੱਤਾ" ਦੀ ਸ਼ੈਲੀ ਵਿੱਚ ਇੱਕ ਪੱਤਰ ਆਉਂਦਾ ਹੈ। ਪਰ ਸਾਨੂੰ ਦੱਸਿਆ ਗਿਆ ਸੀ ਕਿ ਸਾਈਟ ਦਾ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੈ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਕਾਰਨ ਦੇ ਉੱਥੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਪੂਰੇ ਸਰਵਰ, ਅਤੇ ਇਹ ਕਿ ਅਸੀਂ ਇਸ ਸਰੋਤ ਨੂੰ ਆਪਣੀ ਮਰਜ਼ੀ ਅਨੁਸਾਰ ਵਰਤ ਸਕਦੇ ਹਾਂ।
ਲਗਭਗ ਇੱਕ ਦਿਨ ਬਾਅਦ ਸਾਈਟ ਨੇ ਅਚਾਨਕ ਆਪਣੇ ਆਪ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। IIS 6.0 'ਤੇ WebDAV ਤੋਂ ਇੱਕ ਬੈਂਚ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਦੇਖਿਆ ਕਿ ਡਿਫੌਲਟ ਸੈਟਿੰਗ ਹਰ 30 ਘੰਟਿਆਂ ਬਾਅਦ IIS ਵਰਕਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਹੈ। ਭਾਵ, ਜਦੋਂ ਕੰਟਰੋਲ ਸ਼ੈੱਲਕੋਡ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ, ਤਾਂ IIS ਵਰਕਰ ਪ੍ਰਕਿਰਿਆ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਫਿਰ ਇਹ ਆਪਣੇ ਆਪ ਨੂੰ ਦੋ ਵਾਰ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ 30 ਘੰਟਿਆਂ ਲਈ ਆਰਾਮ ਕਰਨ ਲਈ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਕਿਉਂਕਿ ਟੀਸੀਪੀ ਨਾਲ ਬੈਕਕਨੈਕਟ ਪਹਿਲੀ ਵਾਰ ਅਸਫਲ ਹੋ ਗਿਆ ਸੀ, ਮੈਂ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਬੰਦ ਪੋਰਟ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਠਹਿਰਾਇਆ ਹੈ। ਭਾਵ, ਉਸਨੇ ਕਿਸੇ ਕਿਸਮ ਦੀ ਫਾਇਰਵਾਲ ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ ਮੰਨਿਆ ਜੋ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਬਾਹਰੋਂ ਲੰਘਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ ਸੀ। ਮੈਂ ਸ਼ੈੱਲਕੋਡਾਂ ਨੂੰ ਚਲਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਜੋ ਬਹੁਤ ਸਾਰੇ tcp ਅਤੇ udp ਪੋਰਟਾਂ ਰਾਹੀਂ ਖੋਜ ਕਰਦੇ ਹਨ, ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਸੀ. Metasploit ਤੋਂ http(s) ਰਾਹੀਂ ਰਿਵਰਸ ਕਨੈਕਸ਼ਨ ਲੋਡ ਕੰਮ ਨਹੀਂ ਕੀਤਾ - meterpreter/reverse_http(s)। ਅਚਾਨਕ, ਉਸੇ ਪੋਰਟ 80 ਨਾਲ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਤੁਰੰਤ ਬੰਦ ਹੋ ਗਿਆ. ਮੈਂ ਇਸਨੂੰ ਅਜੇ ਵੀ ਕਾਲਪਨਿਕ ਆਈਪੀਐਸ ਦੀ ਕਾਰਵਾਈ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਠਹਿਰਾਇਆ, ਜੋ ਮੀਟਰਪ੍ਰੇਟਰ ਟ੍ਰੈਫਿਕ ਨੂੰ ਪਸੰਦ ਨਹੀਂ ਕਰਦਾ ਸੀ। ਇਸ ਤੱਥ ਦੇ ਮੱਦੇਨਜ਼ਰ ਕਿ ਪੋਰਟ 80 ਨਾਲ ਇੱਕ ਸ਼ੁੱਧ tcp ਕੁਨੈਕਸ਼ਨ ਨਹੀਂ ਲੰਘਿਆ, ਪਰ ਇੱਕ http ਕੁਨੈਕਸ਼ਨ ਹੋਇਆ, ਮੈਂ ਸਿੱਟਾ ਕੱਢਿਆ ਕਿ ਇੱਕ http ਪ੍ਰੌਕਸੀ ਕਿਸੇ ਤਰ੍ਹਾਂ ਸਿਸਟਮ ਵਿੱਚ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਸੀ।

ਮੈਂ DNS ਦੁਆਰਾ ਮੀਟਰਪ੍ਰੀਟਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਕੀਤੀ (ਧੰਨਵਾਦ d00kie ਤੁਹਾਡੇ ਯਤਨਾਂ ਲਈ, ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਬਚਾਇਆ), ਪਹਿਲੀ ਸਫਲਤਾ ਨੂੰ ਯਾਦ ਕਰਦੇ ਹੋਏ, ਪਰ ਇਹ ਸਟੈਂਡ 'ਤੇ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਸੀ - ਸ਼ੈੱਲਕੋਡ ਇਸ ਕਮਜ਼ੋਰੀ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੀ।

ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ: 3 ਮਿੰਟ ਦੇ ਅੰਦਰ ਹਮਲਿਆਂ 'ਤੇ 4-5 ਕੋਸ਼ਿਸ਼ਾਂ, ਫਿਰ 30 ਘੰਟਿਆਂ ਦੀ ਉਡੀਕ. ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਲਗਾਤਾਰ ਤਿੰਨ ਹਫ਼ਤਿਆਂ ਲਈ. ਮੈਂ ਇੱਕ ਰੀਮਾਈਂਡਰ ਵੀ ਸੈਟ ਕੀਤਾ ਤਾਂ ਜੋ ਸਮਾਂ ਬਰਬਾਦ ਨਾ ਹੋਵੇ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਟੈਸਟ ਅਤੇ ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਦੇ ਵਿਵਹਾਰ ਵਿੱਚ ਇੱਕ ਅੰਤਰ ਸੀ: ਇਸ ਕਮਜ਼ੋਰੀ ਲਈ ਦੋ ਸਮਾਨ ਕਾਰਨਾਮੇ ਸਨ, ਇੱਕ ਮੇਟਾਸਪਲੋਇਟ ਤੋਂ, ਦੂਜਾ ਇੰਟਰਨੈਟ ਤੋਂ, ਸ਼ੈਡੋ ਬ੍ਰੋਕਰਜ਼ ਸੰਸਕਰਣ ਤੋਂ ਬਦਲਿਆ ਗਿਆ। ਇਸ ਲਈ, ਲੜਾਈ ਵਿੱਚ ਸਿਰਫ ਮੈਟਾਸਪਲੋਇਟ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਬੈਂਚ 'ਤੇ ਸਿਰਫ ਦੂਜਾ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਨੇ ਡੀਬੱਗਿੰਗ ਨੂੰ ਹੋਰ ਵੀ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੱਤਾ ਸੀ ਅਤੇ ਦਿਮਾਗੀ ਤੌਰ 'ਤੇ ਪਰੇਸ਼ਾਨ ਕੀਤਾ ਗਿਆ ਸੀ।

ਅੰਤ ਵਿੱਚ, ਇੱਕ ਸ਼ੈੱਲਕੋਡ ਜਿਸ ਨੇ ਇੱਕ ਦਿੱਤੇ ਸਰਵਰ ਤੋਂ HTTP ਦੁਆਰਾ ਇੱਕ exe ਫਾਈਲ ਨੂੰ ਡਾਉਨਲੋਡ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ ਟਾਰਗੇਟ ਸਿਸਟਮ ਤੇ ਲਾਂਚ ਕੀਤਾ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਾਬਤ ਹੋਇਆ। ਸ਼ੈੱਲਕੋਡ ਫਿੱਟ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਛੋਟਾ ਸੀ, ਪਰ ਘੱਟੋ ਘੱਟ ਇਸ ਨੇ ਕੰਮ ਕੀਤਾ. ਕਿਉਂਕਿ ਸਰਵਰ ਨੂੰ TCP ਟ੍ਰੈਫਿਕ ਬਿਲਕੁਲ ਪਸੰਦ ਨਹੀਂ ਸੀ ਅਤੇ ਮੀਟਰਪ੍ਰੀਟਰ ਦੀ ਮੌਜੂਦਗੀ ਲਈ http(s) ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੀ, ਮੈਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਇਸ ਸ਼ੈੱਲਕੋਡ ਰਾਹੀਂ DNS-meterpreter ਵਾਲੀ exe ਫਾਈਲ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਸੀ।

ਇੱਥੇ ਦੁਬਾਰਾ ਇੱਕ ਸਮੱਸਿਆ ਪੈਦਾ ਹੋਈ: ਜਦੋਂ ਇੱਕ exe ਫਾਈਲ ਨੂੰ ਡਾਉਨਲੋਡ ਕਰਦੇ ਹੋਏ ਅਤੇ, ਜਿਵੇਂ ਕਿ ਕੋਸ਼ਿਸ਼ਾਂ ਨੇ ਦਿਖਾਇਆ, ਭਾਵੇਂ ਕੋਈ ਵੀ ਹੋਵੇ, ਡਾਊਨਲੋਡ ਵਿੱਚ ਰੁਕਾਵਟ ਆਈ ਸੀ. ਦੁਬਾਰਾ ਫਿਰ, ਮੇਰੇ ਸਰਵਰ ਅਤੇ ਯੂਰੋਲੋਜਿਸਟ ਦੇ ਵਿਚਕਾਰ ਕੁਝ ਸੁਰੱਖਿਆ ਯੰਤਰ ਇੱਕ exe ਅੰਦਰ ਦੇ ਨਾਲ http ਟ੍ਰੈਫਿਕ ਨੂੰ ਪਸੰਦ ਨਹੀਂ ਕਰਦੇ ਸਨ. "ਤੇਜ਼" ਹੱਲ ਸ਼ੈੱਲਕੋਡ ਨੂੰ ਬਦਲਣਾ ਜਾਪਦਾ ਸੀ ਤਾਂ ਜੋ ਇਹ ਫਲਾਈ 'ਤੇ http ਟ੍ਰੈਫਿਕ ਨੂੰ ਅਸਪਸ਼ਟ ਕਰ ਦੇਵੇ, ਤਾਂ ਜੋ ਐਬਸਟਰੈਕਟ ਬਾਈਨਰੀ ਡੇਟਾ ਨੂੰ exe ਦੀ ਬਜਾਏ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾ ਸਕੇ. ਅੰਤ ਵਿੱਚ, ਹਮਲਾ ਸਫਲ ਰਿਹਾ, ਪਤਲੇ DNS ਚੈਨਲ ਦੁਆਰਾ ਨਿਯੰਤਰਣ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ:

ਇਹ ਤੁਰੰਤ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਮੇਰੇ ਕੋਲ ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ IIS ਵਰਕਫਲੋ ਅਧਿਕਾਰ ਹਨ, ਜੋ ਮੈਨੂੰ ਕੁਝ ਨਹੀਂ ਕਰਨ ਦਿੰਦੇ ਹਨ। ਇਹ ਮੇਟਾਸਪਲੋਇਟ ਕੰਸੋਲ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

ਸਾਰੀਆਂ ਪੈਂਟਸਟ ਵਿਧੀਆਂ ਜ਼ੋਰਦਾਰ ਢੰਗ ਨਾਲ ਸੁਝਾਅ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨ ਵੇਲੇ ਤੁਹਾਨੂੰ ਅਧਿਕਾਰਾਂ ਨੂੰ ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਮੈਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਪਹਿਲੀ ਪਹੁੰਚ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਨੈੱਟਵਰਕ ਐਂਟਰੀ ਪੁਆਇੰਟ ਵਜੋਂ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਨੈੱਟਵਰਕ 'ਤੇ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ਨਾਲ ਸਮਝੌਤਾ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਮੌਜੂਦਾ ਹੋਸਟ 'ਤੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਨੂੰ ਵਧਾਉਣ ਨਾਲੋਂ ਸੌਖਾ ਅਤੇ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ। ਪਰ ਇੱਥੇ ਇਹ ਮਾਮਲਾ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ DNS ਚੈਨਲ ਬਹੁਤ ਤੰਗ ਹੈ ਅਤੇ ਇਹ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਹੋਣ ਦੇਵੇਗਾ।

ਇਹ ਮੰਨਦੇ ਹੋਏ ਕਿ ਇਸ ਵਿੰਡੋਜ਼ 2003 ਸਰਵਰ ਦੀ ਮਸ਼ਹੂਰ MS17-010 ਕਮਜ਼ੋਰੀ ਲਈ ਮੁਰੰਮਤ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ, ਮੈਂ ਲੋਕਲਹੋਸਟ (ਹਾਂ, ਇਹ ਵੀ ਸੰਭਵ ਹੈ) 'ਤੇ ਮੀਟਰਪ੍ਰੇਟਰ DNS ਸੁਰੰਗ ਰਾਹੀਂ ਪੋਰਟ 445/TCP ਤੱਕ ਟਰੈਫਿਕ ਨੂੰ ਸੁਰੰਗ ਕਰਦਾ ਹਾਂ (ਹਾਂ, ਇਹ ਵੀ ਸੰਭਵ ਹੈ) ਅਤੇ ਇਸ ਰਾਹੀਂ ਪਹਿਲਾਂ ਡਾਊਨਲੋਡ ਕੀਤੇ ਐਕਸੀ ਨੂੰ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਕਮਜ਼ੋਰੀ. ਹਮਲਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਮੈਨੂੰ ਦੂਜਾ ਕੁਨੈਕਸ਼ਨ ਮਿਲਦਾ ਹੈ, ਪਰ ਸਿਸਟਮ ਅਧਿਕਾਰਾਂ ਨਾਲ।

ਇਹ ਦਿਲਚਸਪ ਹੈ ਕਿ ਉਹਨਾਂ ਨੇ ਅਜੇ ਵੀ ਸਰਵਰ ਨੂੰ MS17-010 ਤੋਂ ਬਚਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ - ਇਸ ਵਿੱਚ ਬਾਹਰੀ ਇੰਟਰਫੇਸ 'ਤੇ ਕਮਜ਼ੋਰ ਨੈੱਟਵਰਕ ਸੇਵਾਵਾਂ ਨੂੰ ਅਸਮਰੱਥ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਨੈੱਟਵਰਕ 'ਤੇ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਪਰ ਲੋਕਲਹੋਸਟ 'ਤੇ ਅੰਦਰੋਂ ਹਮਲਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਲੋਕਲਹੋਸਟ 'ਤੇ SMB ਨੂੰ ਤੁਰੰਤ ਬੰਦ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ।

ਅੱਗੇ, ਨਵੇਂ ਦਿਲਚਸਪ ਵੇਰਵੇ ਪ੍ਰਗਟ ਕੀਤੇ ਗਏ ਹਨ:

1. ਸਿਸਟਮ ਅਧਿਕਾਰ ਹੋਣ ਕਰਕੇ, ਤੁਸੀਂ TCP ਰਾਹੀਂ ਆਸਾਨੀ ਨਾਲ ਬੈਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਸਿੱਧੇ TCP ਨੂੰ ਅਯੋਗ ਕਰਨਾ ਸੀਮਤ IIS ਉਪਭੋਗਤਾ ਲਈ ਸਖਤੀ ਨਾਲ ਇੱਕ ਸਮੱਸਿਆ ਹੈ। ਸਪੋਇਲਰ: IIS ਉਪਭੋਗਤਾ ਟ੍ਰੈਫਿਕ ਕਿਸੇ ਤਰ੍ਹਾਂ ਸਥਾਨਕ ISA ਪ੍ਰੌਕਸੀ ਵਿੱਚ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਲਪੇਟਿਆ ਗਿਆ ਸੀ। ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਮੈਂ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾਇਆ ਹੈ.
2. ਮੈਂ ਇੱਕ ਖਾਸ "DMZ" ਵਿੱਚ ਹਾਂ (ਅਤੇ ਇਹ ਇੱਕ ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ ਡੋਮੇਨ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕ ਵਰਕਗਰੁੱਪ ਹੈ) - ਇਹ ਤਰਕਪੂਰਨ ਲੱਗਦਾ ਹੈ। ਪਰ ਸੰਭਾਵਿਤ ਨਿਜੀ ("ਸਲੇਟੀ") IP ਪਤੇ ਦੀ ਬਜਾਏ, ਮੇਰੇ ਕੋਲ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ "ਚਿੱਟਾ" IP ਪਤਾ ਹੈ, ਬਿਲਕੁਲ ਉਹੀ ਜਿਵੇਂ ਮੈਂ ਪਹਿਲਾਂ ਹਮਲਾ ਕੀਤਾ ਸੀ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੰਪਨੀ IPv4 ਐਡਰੈਸਿੰਗ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਇੰਨੀ ਪੁਰਾਣੀ ਹੈ ਕਿ ਇਹ ਸਕੀਮ ਦੇ ਅਨੁਸਾਰ NAT ਦੇ ਬਿਨਾਂ 128 “ਚਿੱਟੇ” ਪਤਿਆਂ ਲਈ ਇੱਕ DMZ ਜ਼ੋਨ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ 2005 ਤੋਂ ਸਿਸਕੋ ਮੈਨੂਅਲ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

ਕਿਉਂਕਿ ਸਰਵਰ ਪੁਰਾਣਾ ਹੈ, ਮਿਮੀਕਾਟਜ਼ ਨੂੰ ਮੈਮੋਰੀ ਤੋਂ ਸਿੱਧੇ ਕੰਮ ਕਰਨ ਦੀ ਗਰੰਟੀ ਹੈ:

ਮੈਨੂੰ ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ ਪਾਸਵਰਡ ਮਿਲਦਾ ਹੈ, TCP ਉੱਤੇ RDP ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੁਰੰਗ ਕਰੋ ਅਤੇ ਇੱਕ ਆਰਾਮਦਾਇਕ ਡੈਸਕਟਾਪ ਵਿੱਚ ਲੌਗਇਨ ਕਰੋ। ਕਿਉਂਕਿ ਮੈਂ ਸਰਵਰ ਨਾਲ ਜੋ ਵੀ ਚਾਹੁੰਦਾ ਸੀ ਕਰ ਸਕਦਾ ਸੀ, ਮੈਂ ਐਂਟੀਵਾਇਰਸ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਅਤੇ ਪਾਇਆ ਕਿ ਸਰਵਰ ਸਿਰਫ ਟੀਸੀਪੀ ਪੋਰਟਾਂ 80 ਅਤੇ 443 ਦੁਆਰਾ ਇੰਟਰਨੈਟ ਤੋਂ ਪਹੁੰਚਯੋਗ ਸੀ, ਅਤੇ 443 ਵਿਅਸਤ ਨਹੀਂ ਸੀ। ਮੈਂ 443 'ਤੇ ਇੱਕ OpenVPN ਸਰਵਰ ਸੈਟ ਅਪ ਕੀਤਾ, ਮੇਰੇ VPN ਟ੍ਰੈਫਿਕ ਲਈ NAT ਫੰਕਸ਼ਨ ਜੋੜਿਆ ਅਤੇ ਮੇਰੇ OpenVPN ਦੁਆਰਾ ਅਸੀਮਤ ਰੂਪ ਵਿੱਚ DMZ ਨੈੱਟਵਰਕ ਤੱਕ ਸਿੱਧੀ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕੀਤੀ। ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ISA, ਕੁਝ ਗੈਰ-ਅਯੋਗ IPS ਫੰਕਸ਼ਨਾਂ ਦੇ ਨਾਲ, ਪੋਰਟ ਸਕੈਨਿੰਗ ਨਾਲ ਮੇਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬਲੌਕ ਕੀਤਾ, ਜਿਸ ਲਈ ਇਸਨੂੰ ਇੱਕ ਸਰਲ ਅਤੇ ਵਧੇਰੇ ਅਨੁਕੂਲ RRAS ਨਾਲ ਬਦਲਣਾ ਪਿਆ। ਇਸ ਲਈ ਪੈਨਟੇਸਟਰਾਂ ਨੂੰ ਕਈ ਵਾਰ ਅਜੇ ਵੀ ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਚੀਜ਼ਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਇੱਕ ਧਿਆਨ ਦੇਣ ਵਾਲਾ ਪਾਠਕ ਪੁੱਛੇਗਾ: "ਦੂਜੀ ਸਾਈਟ ਬਾਰੇ ਕੀ - NTLM ਪ੍ਰਮਾਣਿਕਤਾ ਵਾਲਾ ਇੱਕ ਵਿਕੀ, ਜਿਸ ਬਾਰੇ ਬਹੁਤ ਕੁਝ ਲਿਖਿਆ ਗਿਆ ਹੈ?" ਇਸ ਬਾਰੇ ਹੋਰ ਬਾਅਦ ਵਿੱਚ.

ਭਾਗ 2. ਅਜੇ ਵੀ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਹੋ ਰਿਹਾ? ਫਿਰ ਅਸੀਂ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਥੇ ਆ ਰਹੇ ਹਾਂ

ਇਸ ਲਈ, DMZ ਨੈੱਟਵਰਕ ਹਿੱਸੇ ਤੱਕ ਪਹੁੰਚ ਹੈ. ਤੁਹਾਨੂੰ ਡੋਮੇਨ ਪ੍ਰਸ਼ਾਸਕ ਕੋਲ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਦਿਮਾਗ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਉਹ ਹੈ DMZ ਹਿੱਸੇ ਦੇ ਅੰਦਰ ਸੇਵਾਵਾਂ ਦੀ ਸੁਰੱਖਿਆ ਦੀ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕਰਨਾ, ਖਾਸ ਕਰਕੇ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਹੁਣ ਖੋਜ ਲਈ ਖੁੱਲ੍ਹੇ ਹਨ। ਇੱਕ ਪ੍ਰਵੇਸ਼ ਟੈਸਟ ਦੇ ਦੌਰਾਨ ਇੱਕ ਆਮ ਤਸਵੀਰ: ਬਾਹਰੀ ਘੇਰਾ ਅੰਦਰੂਨੀ ਸੇਵਾਵਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਸੁਰੱਖਿਅਤ ਹੈ, ਅਤੇ ਜਦੋਂ ਇੱਕ ਵੱਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਕੋਈ ਵੀ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਡੋਮੇਨ ਵਿੱਚ ਵਿਸਤ੍ਰਿਤ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਡੋਮੇਨ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ. ਟੂਲਸ ਤੱਕ ਪਹੁੰਚਯੋਗ, ਅਤੇ ਦੂਜਾ, ਕਈ ਹਜ਼ਾਰ ਮੇਜ਼ਬਾਨਾਂ ਵਾਲੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ, ਹਮੇਸ਼ਾ ਕੁਝ ਨਾਜ਼ੁਕ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ।

ਮੈਂ ਇੱਕ OpenVPN ਸੁਰੰਗ ਰਾਹੀਂ DMZ ਰਾਹੀਂ ਸਕੈਨਰਾਂ ਨੂੰ ਚਾਰਜ ਕਰਦਾ ਹਾਂ ਅਤੇ ਉਡੀਕ ਕਰਦਾ ਹਾਂ। ਮੈਂ ਰਿਪੋਰਟ ਖੋਲ੍ਹਦਾ ਹਾਂ - ਦੁਬਾਰਾ ਕੁਝ ਵੀ ਗੰਭੀਰ ਨਹੀਂ, ਜ਼ਾਹਰ ਹੈ ਕਿ ਕੋਈ ਮੇਰੇ ਤੋਂ ਪਹਿਲਾਂ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਗਿਆ ਸੀ. ਅਗਲਾ ਕਦਮ ਇਹ ਜਾਂਚਣਾ ਹੈ ਕਿ DMZ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਹੋਸਟ ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਦੇ ਹਨ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਪਹਿਲਾਂ ਆਮ ਵਾਇਰਸ਼ਾਰਕ ਲਾਂਚ ਕਰੋ ਅਤੇ ਪ੍ਰਸਾਰਣ ਬੇਨਤੀਆਂ ਨੂੰ ਸੁਣੋ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਏ.ਆਰ.ਪੀ. ਸਾਰਾ ਦਿਨ ਏਆਰਪੀ ਦੇ ਪੈਕੇਟ ਇਕੱਠੇ ਕੀਤੇ ਗਏ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਇਸ ਹਿੱਸੇ ਵਿੱਚ ਕਈ ਗੇਟਵੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ. ਇਹ ਬਾਅਦ ਵਿੱਚ ਕੰਮ ਆਵੇਗਾ। ARP ਬੇਨਤੀਆਂ ਅਤੇ ਜਵਾਬਾਂ ਅਤੇ ਪੋਰਟ ਸਕੈਨਿੰਗ ਡੇਟਾ ਦੇ ਡੇਟਾ ਨੂੰ ਜੋੜ ਕੇ, ਮੈਂ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਤੋਂ ਇਲਾਵਾ ਸਥਾਨਕ ਨੈਟਵਰਕ ਦੇ ਅੰਦਰ ਤੋਂ ਉਪਭੋਗਤਾ ਟ੍ਰੈਫਿਕ ਦੇ ਨਿਕਾਸ ਪੁਆਇੰਟ ਲੱਭੇ ਜੋ ਪਹਿਲਾਂ ਜਾਣੀਆਂ ਜਾਂਦੀਆਂ ਸਨ, ਜਿਵੇਂ ਕਿ ਵੈਬ ਅਤੇ ਮੇਲ।

ਕਿਉਂਕਿ ਇਸ ਸਮੇਂ ਮੇਰੇ ਕੋਲ ਹੋਰ ਪ੍ਰਣਾਲੀਆਂ ਤੱਕ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ ਸੀ ਅਤੇ ਕਾਰਪੋਰੇਟ ਸੇਵਾਵਾਂ ਲਈ ਇੱਕ ਵੀ ਖਾਤਾ ਨਹੀਂ ਸੀ, ਇਸ ਲਈ ਇਹ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ ਕਿ ARP ਸਪੂਫਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟ੍ਰੈਫਿਕ ਤੋਂ ਘੱਟੋ-ਘੱਟ ਕੁਝ ਖਾਤੇ ਨੂੰ ਬਾਹਰ ਕੱਢਿਆ ਜਾਵੇ।

Cain&Abel ਨੂੰ ਯੂਰੋਲੋਜਿਸਟ ਦੇ ਸਰਵਰ 'ਤੇ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ। ਪਛਾਣੇ ਗਏ ਟ੍ਰੈਫਿਕ ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ ਹਮਲੇ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਜੋੜੇ ਚੁਣੇ ਗਏ ਸਨ, ਅਤੇ ਫਿਰ ਸਰਵਰ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਲਈ ਟਾਈਮਰ ਦੇ ਨਾਲ, 5-10 ਮਿੰਟਾਂ ਲਈ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਲਾਂਚ ਦੁਆਰਾ ਕੁਝ ਨੈਟਵਰਕ ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਠੰਢ ਦੇ ਮਾਮਲੇ ਵਿੱਚ. ਜਿਵੇਂ ਕਿ ਮਜ਼ਾਕ ਵਿਚ, ਦੋ ਖ਼ਬਰਾਂ ਸਨ:

1. ਚੰਗਾ: ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਫੜੇ ਗਏ ਅਤੇ ਹਮਲੇ ਨੇ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕੀਤਾ।
2. ਬੁਰਾ: ਸਾਰੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਗਾਹਕ ਦੇ ਆਪਣੇ ਗਾਹਕਾਂ ਦੇ ਸਨ। ਸਹਾਇਤਾ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਸਮੇਂ, ਗਾਹਕਾਂ ਦੀਆਂ ਸੇਵਾਵਾਂ ਨਾਲ ਜੁੜੇ ਗਾਹਕ ਮਾਹਰ ਜਿਨ੍ਹਾਂ ਕੋਲ ਹਮੇਸ਼ਾ ਟ੍ਰੈਫਿਕ ਏਨਕ੍ਰਿਪਸ਼ਨ ਕੌਂਫਿਗਰ ਨਹੀਂ ਹੁੰਦੀ ਸੀ।

ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਹਾਸਲ ਕੀਤੇ ਜੋ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਬੇਕਾਰ ਸਨ, ਪਰ ਹਮਲੇ ਦੇ ਖ਼ਤਰੇ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਦਿਲਚਸਪ ਸਨ। ਟੈਲਨੈੱਟ ਵਾਲੀਆਂ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਦੇ ਬਾਰਡਰ ਰਾਊਟਰ, ਸਾਰੇ ਡੇਟਾ ਦੇ ਨਾਲ ਡੀਬੱਗ HTTP ਪੋਰਟਾਂ ਨੂੰ ਅੰਦਰੂਨੀ CRM 'ਤੇ ਫਾਰਵਰਡ, ਸਥਾਨਕ ਨੈੱਟਵਰਕ 'ਤੇ Windows XP ਤੋਂ RDP ਤੱਕ ਸਿੱਧੀ ਪਹੁੰਚ ਅਤੇ ਹੋਰ ਅਸਪਸ਼ਟਤਾ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਨਿਕਲਿਆ MITER ਮੈਟ੍ਰਿਕਸ ਦੇ ਅਨੁਸਾਰ ਸਪਲਾਈ ਚੇਨ ਸਮਝੌਤਾ.

ਮੈਨੂੰ ਟ੍ਰੈਫਿਕ ਤੋਂ ਚਿੱਠੀਆਂ ਇਕੱਠੀਆਂ ਕਰਨ ਦਾ ਇੱਕ ਮਜ਼ਾਕੀਆ ਮੌਕਾ ਵੀ ਮਿਲਿਆ, ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ. ਇਹ ਇੱਕ ਤਿਆਰ-ਕੀਤੀ ਚਿੱਠੀ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜੋ ਸਾਡੇ ਗਾਹਕ ਤੋਂ ਉਸਦੇ ਗਾਹਕ ਦੇ SMTP ਪੋਰਟ 'ਤੇ, ਦੁਬਾਰਾ, ਬਿਨਾਂ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਚਲਾ ਗਿਆ। ਇੱਕ ਨਿਸ਼ਚਿਤ ਆਂਦਰੇ ਨੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜਣ ਲਈ ਆਪਣਾ ਨਾਮ ਪੁੱਛਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਜਵਾਬ ਪੱਤਰ ਵਿੱਚ ਇੱਕ ਲੌਗਇਨ, ਪਾਸਵਰਡ ਅਤੇ ਲਿੰਕ ਦੇ ਨਾਲ ਇੱਕ ਕਲਾਉਡ ਡਿਸਕ ਤੇ ਅਪਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

ਇਹ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਨ ਲਈ ਇੱਕ ਹੋਰ ਰੀਮਾਈਂਡਰ ਹੈ। ਇਹ ਅਣਜਾਣ ਹੈ ਕਿ ਕੌਣ ਅਤੇ ਕਦੋਂ ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਪੜ੍ਹੇਗਾ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕਰੇਗਾ - ਪ੍ਰਦਾਤਾ, ਕਿਸੇ ਹੋਰ ਕੰਪਨੀ ਦਾ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ, ਜਾਂ ਅਜਿਹਾ ਪੈਂਟੇਸਟਰ। ਮੈਂ ਇਸ ਤੱਥ ਬਾਰੇ ਚੁੱਪ ਹਾਂ ਕਿ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਸਿਰਫ਼ ਅਣਏਨਕ੍ਰਿਪਟਡ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ.

ਸਪੱਸ਼ਟ ਸਫਲਤਾ ਦੇ ਬਾਵਜੂਦ, ਇਹ ਸਾਨੂੰ ਟੀਚੇ ਦੇ ਨੇੜੇ ਨਹੀਂ ਲਿਆਇਆ. ਬੇਸ਼ੱਕ, ਲੰਬੇ ਸਮੇਂ ਲਈ ਬੈਠਣਾ ਅਤੇ ਕੀਮਤੀ ਜਾਣਕਾਰੀ ਨੂੰ ਫੜਨਾ ਸੰਭਵ ਸੀ, ਪਰ ਇਹ ਇੱਕ ਤੱਥ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਉੱਥੇ ਦਿਖਾਈ ਦੇਵੇਗਾ, ਅਤੇ ਇਹ ਹਮਲਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਨੈਟਵਰਕ ਦੀ ਅਖੰਡਤਾ ਦੇ ਰੂਪ ਵਿੱਚ ਬਹੁਤ ਖਤਰਨਾਕ ਹੈ.

ਸੇਵਾਵਾਂ ਵਿੱਚ ਇੱਕ ਹੋਰ ਖੋਦਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਦਿਲਚਸਪ ਵਿਚਾਰ ਮਨ ਵਿੱਚ ਆਇਆ. ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਅਜਿਹੀ ਉਪਯੋਗਤਾ ਹੈ (ਇਸ ਨਾਮ ਦੁਆਰਾ ਵਰਤੋਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਲੱਭਣਾ ਆਸਾਨ ਹੈ), ਜੋ, "ਜ਼ਹਿਰ" ਪ੍ਰਸਾਰਣ ਬੇਨਤੀਆਂ ਦੁਆਰਾ, SMB, HTTP, LDAP, ਆਦਿ ਵਰਗੇ ਕਈ ਪ੍ਰੋਟੋਕੋਲਾਂ ਦੁਆਰਾ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਭੜਕਾਉਂਦਾ ਹੈ। ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ, ਫਿਰ ਹਰੇਕ ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਜੋ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ ਜੁੜਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ NTLM ਦੁਆਰਾ ਅਤੇ ਪੀੜਤ ਲਈ ਪਾਰਦਰਸ਼ੀ ਮੋਡ ਵਿੱਚ ਹੋਵੇ। ਬਹੁਤੀ ਵਾਰ, ਇੱਕ ਹਮਲਾਵਰ ਇਸ ਤਰੀਕੇ ਨਾਲ NetNTLMv2 ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਤੋਂ, ਇੱਕ ਸ਼ਬਦਕੋਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਉਪਭੋਗਤਾ ਡੋਮੇਨ ਪਾਸਵਰਡਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਮੈਂ ਕੁਝ ਅਜਿਹਾ ਹੀ ਚਾਹੁੰਦਾ ਸੀ, ਪਰ ਉਪਭੋਗਤਾ "ਇੱਕ ਕੰਧ ਦੇ ਪਿੱਛੇ" ਬੈਠੇ ਸਨ, ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਫਾਇਰਵਾਲ ਦੁਆਰਾ ਵੱਖ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਬਲੂ ਕੋਟ ਪ੍ਰੌਕਸੀ ਕਲੱਸਟਰ ਦੁਆਰਾ WEB ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ ਗਈ ਸੀ।

ਯਾਦ ਰੱਖੋ, ਮੈਂ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਸੀ ਕਿ ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ ਡੋਮੇਨ ਨਾਮ "ਬਾਹਰੀ" ਡੋਮੇਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਯਾਨੀ ਕਿ ਇਹ company.ru ਸੀ? ਇਸ ਲਈ, ਵਿੰਡੋਜ਼, ਵਧੇਰੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇੰਟਰਨੈਟ ਐਕਸਪਲੋਰਰ (ਅਤੇ ਐਜ ਅਤੇ ਕਰੋਮ), ਉਪਭੋਗਤਾ ਨੂੰ NTLM ਦੁਆਰਾ HTTP ਵਿੱਚ ਪਾਰਦਰਸ਼ੀ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੇਕਰ ਉਹ ਸਮਝਦੇ ਹਨ ਕਿ ਸਾਈਟ ਕਿਸੇ "ਇੰਟਰਾਨੈੱਟ ਜ਼ੋਨ" ਵਿੱਚ ਸਥਿਤ ਹੈ। ਇੱਕ "ਇੰਟਰਾਨੈੱਟ" ਦੇ ਸੰਕੇਤਾਂ ਵਿੱਚੋਂ ਇੱਕ "ਸਲੇਟੀ" IP ਪਤੇ ਜਾਂ ਇੱਕ ਛੋਟੇ DNS ਨਾਮ ਤੱਕ ਪਹੁੰਚ ਹੈ, ਭਾਵ, ਬਿੰਦੀਆਂ ਤੋਂ ਬਿਨਾਂ। ਕਿਉਂਕਿ ਉਹਨਾਂ ਕੋਲ ਇੱਕ "ਵਾਈਟ" IP ਅਤੇ DNS ਨਾਮ preobrazhensky.company.ru ਵਾਲਾ ਸਰਵਰ ਸੀ, ਅਤੇ ਡੋਮੇਨ ਮਸ਼ੀਨਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸਰਲ ਨਾਮ ਐਂਟਰੀ ਲਈ DHCP ਰਾਹੀਂ ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ ਡੋਮੇਨ ਪਿਛੇਤਰ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਐਡਰੈੱਸ ਬਾਰ ਵਿੱਚ URL ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ। preobrazhensky, ਤਾਂ ਜੋ ਉਹ ਸਮਝੌਤਾ ਕੀਤੇ ਯੂਰੋਲੋਜਿਸਟ ਦੇ ਸਰਵਰ ਲਈ ਸਹੀ ਮਾਰਗ ਲੱਭ ਸਕਣ, ਇਹ ਨਾ ਭੁੱਲੋ ਕਿ ਇਸਨੂੰ ਹੁਣ "ਇੰਟਰਾਨੈੱਟ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਭਾਵ, ਉਸੇ ਸਮੇਂ ਮੈਨੂੰ ਉਪਭੋਗਤਾ ਦਾ NTLM-ਹੈਂਡਸ਼ੇਕ ਉਸਦੀ ਜਾਣਕਾਰੀ ਤੋਂ ਬਿਨਾਂ ਦੇਣਾ। ਜੋ ਬਚਿਆ ਹੈ ਉਹ ਹੈ ਕਲਾਇੰਟ ਬ੍ਰਾਊਜ਼ਰਾਂ ਨੂੰ ਇਸ ਸਰਵਰ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਦੀ ਤੁਰੰਤ ਲੋੜ ਬਾਰੇ ਸੋਚਣ ਲਈ ਮਜਬੂਰ ਕਰਨਾ।

ਸ਼ਾਨਦਾਰ ਇੰਟਰਸੈਪਟਰ-ਐਨਜੀ ਉਪਯੋਗਤਾ ਬਚਾਅ ਲਈ ਆਈ (ਧੰਨਵਾਦ ਇੰਟਰਸੈਪਟਰ). ਇਸ ਨੇ ਤੁਹਾਨੂੰ ਫਲਾਈ 'ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਅਤੇ ਵਿੰਡੋਜ਼ 2003 'ਤੇ ਵਧੀਆ ਕੰਮ ਕੀਤਾ। ਇਸ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਪ੍ਰਵਾਹ ਵਿੱਚ ਸਿਰਫ਼ JavaScript ਫਾਈਲਾਂ ਨੂੰ ਸੋਧਣ ਲਈ ਵੱਖਰੀ ਕਾਰਜਸ਼ੀਲਤਾ ਵੀ ਸੀ। ਇੱਕ ਕਿਸਮ ਦੀ ਵਿਸ਼ਾਲ ਕਰਾਸ-ਸਾਈਟ ਸਕ੍ਰਿਪਟਿੰਗ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਗਈ ਸੀ।

ਬਲੂ ਕੋਟ ਪ੍ਰੌਕਸੀਜ਼, ਜਿਸ ਰਾਹੀਂ ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਗਲੋਬਲ WEB ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ, ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸਥਿਰ ਸਮੱਗਰੀ ਨੂੰ ਕੈਸ਼ ਕੀਤਾ। ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕ ਕੇ, ਇਹ ਸਪੱਸ਼ਟ ਸੀ ਕਿ ਉਹ ਘੜੀ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੰਮ ਕਰ ਰਹੇ ਸਨ, ਪੀਕ ਘੰਟਿਆਂ ਦੌਰਾਨ ਸਮਗਰੀ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਅਕਸਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਥਿਰਾਂ ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹੋਏ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਬਲੂਕੋਟ ਦਾ ਇੱਕ ਖਾਸ ਉਪਭੋਗਤਾ-ਏਜੰਟ ਸੀ, ਜੋ ਇਸਨੂੰ ਅਸਲ ਉਪਭੋਗਤਾ ਤੋਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਕਰਦਾ ਸੀ।

ਜਾਵਾਸਕ੍ਰਿਪਟ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸੀ, ਜੋ, ਇੰਟਰਸੈਪਟਰ-ਐਨਜੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਬਲੂ ਕੋਟ ਲਈ ਜੇਐਸ ਫਾਈਲਾਂ ਦੇ ਨਾਲ ਹਰੇਕ ਜਵਾਬ ਲਈ ਰਾਤ ਨੂੰ ਇੱਕ ਘੰਟੇ ਲਈ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ. ਸਕ੍ਰਿਪਟ ਨੇ ਇਹ ਕੀਤਾ:

• ਵਰਤਮਾਨ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਯੂਜ਼ਰ-ਏਜੰਟ ਦੁਆਰਾ ਨਿਰਧਾਰਿਤ ਕੀਤਾ ਗਿਆ। ਜੇਕਰ ਇਹ ਇੰਟਰਨੈੱਟ ਐਕਸਪਲੋਰਰ, ਐਜ ਜਾਂ ਕ੍ਰੋਮ ਸੀ, ਤਾਂ ਇਹ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ।
• ਮੈਂ ਉਦੋਂ ਤੱਕ ਇੰਤਜ਼ਾਰ ਕੀਤਾ ਜਦੋਂ ਤੱਕ ਪੰਨੇ ਦਾ DOM ਨਹੀਂ ਬਣਦਾ.
• ਫਾਰਮ ਦੀ ਇੱਕ src ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਨਾਲ DOM ਵਿੱਚ ਇੱਕ ਅਦਿੱਖ ਚਿੱਤਰ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ preobrazhensky:8080/NNNNNNN.png, ਜਿੱਥੇ NNN ਆਰਬਿਟਰੇਰੀ ਨੰਬਰ ਹੁੰਦੇ ਹਨ ਤਾਂ ਕਿ ਬਲੂਕੋਟ ਇਸਨੂੰ ਕੈਸ਼ ਨਾ ਕਰੇ।
• ਇਹ ਦਰਸਾਉਣ ਲਈ ਇੱਕ ਗਲੋਬਲ ਫਲੈਗ ਵੇਰੀਏਬਲ ਸੈੱਟ ਕਰੋ ਕਿ ਟੀਕਾ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਹੁਣ ਚਿੱਤਰਾਂ ਨੂੰ ਪਾਉਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਇਸ ਚਿੱਤਰ ਨੂੰ ਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ; ਸਮਝੌਤਾ ਕੀਤੇ ਸਰਵਰ ਦੇ ਪੋਰਟ 8080 'ਤੇ, ਇੱਕ TCP ਸੁਰੰਗ ਮੇਰੇ ਲੈਪਟਾਪ ਲਈ ਇਸਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਸੀ, ਜਿੱਥੇ ਉਹੀ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਚੱਲ ਰਿਹਾ ਸੀ, ਜਿਸ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ NTLM ਰਾਹੀਂ ਲੌਗਇਨ ਕਰਨ ਦੀ ਲੋੜ ਸੀ।

ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਲੌਗਸ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਲੋਕ ਸਵੇਰੇ ਕੰਮ 'ਤੇ ਆਏ, ਆਪਣੇ ਵਰਕਸਟੇਸ਼ਨਾਂ ਨੂੰ ਚਾਲੂ ਕਰ ਦਿੱਤਾ, ਫਿਰ ਸਮੂਹਿਕ ਅਤੇ ਅਣਦੇਖਿਆਂ ਨੇ ਯੂਰੋਲੋਜਿਸਟ ਦੇ ਸਰਵਰ 'ਤੇ ਜਾਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, NTLM ਹੈਂਡਸ਼ੇਕ ਨੂੰ "ਨਿਕਾਸ" ਕਰਨਾ ਨਹੀਂ ਭੁੱਲਿਆ। ਸਾਰਾ ਦਿਨ ਹੱਥ ਮਿਲਾਉਣ ਦੀ ਬਾਰਿਸ਼ ਹੋਈ ਅਤੇ ਪਾਸਵਰਡ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਫਲ ਹਮਲੇ ਲਈ ਸਮੱਗਰੀ ਇਕੱਠੀ ਕੀਤੀ ਗਈ। ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਲੌਗ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ:

ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਯੂਰੋਲੋਜਿਸਟ ਸਰਵਰ ਲਈ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਗੁਪਤ ਮੁਲਾਕਾਤਾਂ

ਤੁਸੀਂ ਸ਼ਾਇਦ ਪਹਿਲਾਂ ਹੀ ਦੇਖਿਆ ਹੋਵੇਗਾ ਕਿ ਇਹ ਸਾਰੀ ਕਹਾਣੀ ਇਸ ਸਿਧਾਂਤ 'ਤੇ ਬਣੀ ਹੋਈ ਹੈ "ਸਭ ਕੁਝ ਠੀਕ ਸੀ, ਪਰ ਫਿਰ ਇੱਕ ਉਲਝਣ ਸੀ, ਫਿਰ ਇੱਕ ਕਾਬੂ ਆਇਆ, ਅਤੇ ਫਿਰ ਸਭ ਕੁਝ ਸਫਲ ਹੋ ਗਿਆ।" ਇਸ ਲਈ, ਇੱਥੇ ਇੱਕ ਹਫੜਾ-ਦਫੜੀ ਸੀ. ਪੰਜਾਹ ਵਿਲੱਖਣ ਹੱਥ ਮਿਲਾਉਣ ਵਿੱਚੋਂ, ਇੱਕ ਵੀ ਪ੍ਰਗਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਤੇ ਇਹ ਇਸ ਤੱਥ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਕਿ ਇੱਕ ਡੈੱਡ ਪ੍ਰੋਸੈਸਰ ਵਾਲੇ ਲੈਪਟਾਪ 'ਤੇ ਵੀ, ਇਹ NTLMv2 ਹੈਂਡਸ਼ੇਕ ਪ੍ਰਤੀ ਸਕਿੰਟ ਕਈ ਸੌ ਮਿਲੀਅਨ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਗਤੀ ਨਾਲ ਸੰਸਾਧਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਮੈਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਪਾਸਵਰਡ ਪਰਿਵਰਤਨ ਤਕਨੀਕਾਂ, ਇੱਕ ਵੀਡੀਓ ਕਾਰਡ, ਇੱਕ ਮੋਟਾ ਸ਼ਬਦਕੋਸ਼ ਅਤੇ ਇੰਤਜ਼ਾਰ ਕਰਨਾ ਪਿਆ। ਲੰਬੇ ਸਮੇਂ ਬਾਅਦ, "Q11111111....1111111q" ਫਾਰਮ ਦੇ ਪਾਸਵਰਡ ਵਾਲੇ ਕਈ ਖਾਤਿਆਂ ਦਾ ਖੁਲਾਸਾ ਹੋਇਆ, ਜੋ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਅੱਖਰਾਂ ਦੇ ਵੱਖੋ-ਵੱਖਰੇ ਕੇਸਾਂ ਵਾਲੇ ਇੱਕ ਬਹੁਤ ਲੰਬੇ ਪਾਸਵਰਡ ਨਾਲ ਆਉਣ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੋ ਕਿ ਇਹ ਵੀ ਮੰਨਿਆ ਜਾਂਦਾ ਸੀ ਗੁੰਝਲਦਾਰ ਹੋਣਾ. ਪਰ ਤੁਸੀਂ ਇੱਕ ਤਜਰਬੇਕਾਰ ਉਪਭੋਗਤਾ ਨੂੰ ਮੂਰਖ ਨਹੀਂ ਬਣਾ ਸਕਦੇ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਉਸਨੇ ਆਪਣੇ ਲਈ ਯਾਦ ਰੱਖਣਾ ਆਸਾਨ ਬਣਾ ਦਿੱਤਾ. ਕੁੱਲ ਮਿਲਾ ਕੇ, ਲਗਭਗ 5 ਖਾਤਿਆਂ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਕੋਲ ਸੇਵਾਵਾਂ ਲਈ ਕੋਈ ਕੀਮਤੀ ਅਧਿਕਾਰ ਸੀ।

ਭਾਗ 3. Roskomnadzor ਵਾਪਸ ਹਮਲਾ

ਇਸ ਲਈ, ਪਹਿਲੇ ਡੋਮੇਨ ਖਾਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਸਨ. ਜੇਕਰ ਤੁਸੀਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਪੜ੍ਹ ਕੇ ਇਸ ਬਿੰਦੂ ਤੱਕ ਸੌਂ ਨਹੀਂ ਗਏ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸ਼ਾਇਦ ਯਾਦ ਹੋਵੇਗਾ ਕਿ ਮੈਂ ਇੱਕ ਅਜਿਹੀ ਸੇਵਾ ਦਾ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ ਜਿਸ ਲਈ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਦੂਜੇ ਕਾਰਕ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ: ਇਹ NTLM ਪ੍ਰਮਾਣੀਕਰਨ ਵਾਲਾ ਇੱਕ ਵਿਕੀ ਹੈ। ਬੇਸ਼ੱਕ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉੱਥੇ ਦਾਖਲ ਹੋਣਾ ਸੀ. ਅੰਦਰੂਨੀ ਗਿਆਨ ਅਧਾਰ ਵਿੱਚ ਖੁਦਾਈ ਕਰਨ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਨਤੀਜੇ ਆਏ:

• ਕੰਪਨੀ ਕੋਲ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਵਾਲੇ ਡੋਮੇਨ ਖਾਤਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਮਾਣਿਕਤਾ ਵਾਲਾ ਇੱਕ WiFi ਨੈੱਟਵਰਕ ਹੈ। ਡੇਟਾ ਦੇ ਮੌਜੂਦਾ ਸੈੱਟ ਦੇ ਨਾਲ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਹਮਲਾ ਵੈਕਟਰ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਆਪਣੇ ਪੈਰਾਂ ਨਾਲ ਦਫਤਰ ਜਾਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਅਤੇ ਗਾਹਕ ਦੇ ਦਫਤਰ ਦੇ ਖੇਤਰ ਵਿੱਚ ਕਿਤੇ ਸਥਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਮੈਨੂੰ ਇੱਕ ਹਦਾਇਤ ਮਿਲੀ ਜਿਸ ਦੇ ਅਨੁਸਾਰ ਇੱਕ ਸੇਵਾ ਸੀ ਜੋ ... ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਇੱਕ "ਦੂਜਾ ਕਾਰਕ" ਪ੍ਰਮਾਣਿਕਤਾ ਉਪਕਰਣ ਰਜਿਸਟਰ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ ਜੇਕਰ ਉਪਭੋਗਤਾ ਇੱਕ ਸਥਾਨਕ ਨੈਟਵਰਕ ਦੇ ਅੰਦਰ ਹੈ ਅਤੇ ਭਰੋਸੇ ਨਾਲ ਉਸਦਾ ਡੋਮੇਨ ਲੌਗਇਨ ਅਤੇ ਪਾਸਵਰਡ ਯਾਦ ਰੱਖਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, "ਅੰਦਰ" ਅਤੇ "ਬਾਹਰ" ਉਪਭੋਗਤਾ ਲਈ ਇਸ ਸੇਵਾ ਦੇ ਪੋਰਟ ਦੀ ਪਹੁੰਚਯੋਗਤਾ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਸਨ। ਪੋਰਟ ਇੰਟਰਨੈਟ ਤੋਂ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਸੀ, ਪਰ DMZ ਦੁਆਰਾ ਕਾਫ਼ੀ ਪਹੁੰਚਯੋਗ ਸੀ।

ਬੇਸ਼ੱਕ, ਮੇਰੇ ਫ਼ੋਨ 'ਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਝੌਤਾ ਕੀਤੇ ਖਾਤੇ ਵਿੱਚ ਇੱਕ "ਦੂਜਾ ਕਾਰਕ" ਤੁਰੰਤ ਜੋੜਿਆ ਗਿਆ ਸੀ। ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਸੀ ਜੋ ਜਾਂ ਤਾਂ ਕਾਰਵਾਈ ਲਈ "ਮਨਜ਼ੂਰ"/"ਅਸਵੀਕਾਰ" ਬਟਨਾਂ ਨਾਲ ਫ਼ੋਨ 'ਤੇ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਪੁਸ਼ ਬੇਨਤੀ ਭੇਜ ਸਕਦਾ ਸੀ, ਜਾਂ ਹੋਰ ਸੁਤੰਤਰ ਦਾਖਲੇ ਲਈ ਸਕ੍ਰੀਨ 'ਤੇ ਚੁੱਪਚਾਪ OTP ਕੋਡ ਦਿਖਾ ਸਕਦਾ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਪਹਿਲੀ ਵਿਧੀ ਨੂੰ ਨਿਰਦੇਸ਼ਾਂ ਦੁਆਰਾ ਸਿਰਫ ਸਹੀ ਮੰਨਿਆ ਜਾਂਦਾ ਸੀ, ਪਰ ਇਹ OTP ਵਿਧੀ ਦੇ ਉਲਟ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਸੀ।

ਟੁੱਟੇ ਹੋਏ “ਦੂਜੇ ਕਾਰਕ” ਦੇ ਨਾਲ, ਮੈਂ ਆਉਟਲੁੱਕ ਵੈੱਬ ਐਕਸੈਸ ਮੇਲ ਅਤੇ ਸਿਟਰਿਕਸ ਨੈਟਸਕੇਲਰ ਗੇਟਵੇ ਵਿੱਚ ਰਿਮੋਟ ਐਕਸੈਸ ਕਰਨ ਦੇ ਯੋਗ ਸੀ। ਆਉਟਲੁੱਕ ਵਿੱਚ ਮੇਲ ਵਿੱਚ ਇੱਕ ਹੈਰਾਨੀ ਸੀ:

ਇਸ ਦੁਰਲੱਭ ਸ਼ਾਟ ਵਿੱਚ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਰੋਸਕੋਮਨਾਡਜ਼ੋਰ ਪੈਨਟੇਸਟਰਾਂ ਦੀ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ

ਇਹ ਟੈਲੀਗ੍ਰਾਮ ਦੇ ਮਸ਼ਹੂਰ "ਪ੍ਰਸ਼ੰਸਕ" ਬਲਾਕਿੰਗ ਤੋਂ ਬਾਅਦ ਦੇ ਪਹਿਲੇ ਮਹੀਨੇ ਸਨ, ਜਦੋਂ ਹਜ਼ਾਰਾਂ ਪਤਿਆਂ ਵਾਲੇ ਪੂਰੇ ਨੈਟਵਰਕ ਐਕਸੈਸ ਤੋਂ ਅਣਜਾਣ ਤੌਰ 'ਤੇ ਗਾਇਬ ਹੋ ਗਏ ਸਨ। ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਧੱਕਾ ਤੁਰੰਤ ਕੰਮ ਕਿਉਂ ਨਹੀਂ ਕਰਦਾ ਸੀ ਅਤੇ ਮੇਰੇ "ਪੀੜਤ" ਨੇ ਅਲਾਰਮ ਕਿਉਂ ਨਹੀਂ ਵਜਾਇਆ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੇ ਖੁੱਲ੍ਹੇ ਸਮੇਂ ਦੌਰਾਨ ਉਸਦੇ ਖਾਤੇ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਸੀ।

Citrix Netscaler ਨਾਲ ਜਾਣੂ ਕੋਈ ਵੀ ਕਲਪਨਾ ਕਰਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਨੂੰ ਸਿਰਫ ਇੱਕ ਤਸਵੀਰ ਇੰਟਰਫੇਸ ਹੀ ਪਹੁੰਚਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਉਸਨੂੰ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਂਚ ਕਰਨ ਅਤੇ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਲਈ ਸੰਦ ਨਾ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋਏ, ਹਰ ਸੰਭਵ ਤਰੀਕੇ ਨਾਲ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸੀਮਿਤ ਕਰਦੇ ਹੋਏ. ਮਿਆਰੀ ਕੰਟਰੋਲ ਸ਼ੈੱਲ ਦੁਆਰਾ. ਮੇਰੇ "ਪੀੜਤ", ਉਸਦੇ ਕਿੱਤੇ ਦੇ ਕਾਰਨ, ਸਿਰਫ 1C ਪ੍ਰਾਪਤ ਕੀਤਾ:

1C ਇੰਟਰਫੇਸ ਦੇ ਦੁਆਲੇ ਥੋੜਾ ਜਿਹਾ ਘੁੰਮਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਪਾਇਆ ਕਿ ਉੱਥੇ ਬਾਹਰੀ ਪ੍ਰੋਸੈਸਿੰਗ ਮੋਡੀਊਲ ਹਨ. ਉਹਨਾਂ ਨੂੰ ਇੰਟਰਫੇਸ ਤੋਂ ਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਲਾਇੰਟ ਜਾਂ ਸਰਵਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਧਿਕਾਰਾਂ ਅਤੇ ਸੈਟਿੰਗਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਮੈਂ ਆਪਣੇ 1C ਪ੍ਰੋਗਰਾਮਰ ਦੋਸਤਾਂ ਨੂੰ ਇੱਕ ਪ੍ਰੋਸੈਸਿੰਗ ਬਣਾਉਣ ਲਈ ਕਿਹਾ ਜੋ ਇੱਕ ਸਤਰ ਨੂੰ ਸਵੀਕਾਰ ਕਰੇ ਅਤੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰੇ। 1C ਭਾਸ਼ਾ ਵਿੱਚ, ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਨਾ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (ਇੰਟਰਨੈਟ ਤੋਂ ਲਿਆ ਗਿਆ)। ਕੀ ਤੁਸੀਂ ਇਸ ਗੱਲ ਨਾਲ ਸਹਿਮਤ ਹੋ ਕਿ 1C ਭਾਸ਼ਾ ਦਾ ਸੰਟੈਕਸ ਰੂਸੀ ਬੋਲਣ ਵਾਲੇ ਲੋਕਾਂ ਨੂੰ ਆਪਣੀ ਸਹਿਜਤਾ ਨਾਲ ਹੈਰਾਨ ਕਰਦਾ ਹੈ?

ਪ੍ਰੋਸੈਸਿੰਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਚਲਾਈ ਗਈ ਸੀ; ਇਹ ਉਹ ਨਿਕਲਿਆ ਜਿਸ ਨੂੰ ਪੈਨਟੇਸਟਰ "ਸ਼ੈਲ" ਕਹਿੰਦੇ ਹਨ - ਇੰਟਰਨੈਟ ਐਕਸਪਲੋਰਰ ਇਸ ਦੁਆਰਾ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ।

ਪਹਿਲਾਂ, ਇੱਕ ਸਿਸਟਮ ਦਾ ਪਤਾ ਜੋ ਤੁਹਾਨੂੰ ਖੇਤਰ ਵਿੱਚ ਪਾਸ ਆਰਡਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਡਾਕ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਸੀ। ਜੇਕਰ ਮੈਨੂੰ ਇੱਕ WiFi ਅਟੈਕ ਵੈਕਟਰ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਵੇ ਤਾਂ ਮੈਂ ਇੱਕ ਪਾਸ ਆਰਡਰ ਕੀਤਾ ਹੈ।

ਇੰਟਰਨੈੱਟ 'ਤੇ ਚਰਚਾ ਹੈ ਕਿ ਗਾਹਕ ਦੇ ਦਫਤਰ ਵਿਚ ਅਜੇ ਵੀ ਸੁਆਦੀ ਮੁਫਤ ਕੇਟਰਿੰਗ ਸੀ, ਪਰ ਮੈਂ ਫਿਰ ਵੀ ਹਮਲੇ ਨੂੰ ਰਿਮੋਟ ਤੋਂ ਵਿਕਸਤ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ, ਇਹ ਸ਼ਾਂਤ ਹੈ।

ਐਪਲੌਕਰ ਨੂੰ Citrix ਚਲਾ ਰਹੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ 'ਤੇ ਕਿਰਿਆਸ਼ੀਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਇਸਨੂੰ ਬਾਈਪਾਸ ਕੀਤਾ ਗਿਆ ਸੀ। ਉਹੀ ਮੀਟਰਪ੍ਰੀਟਰ ਲੋਡ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ DNS ਰਾਹੀਂ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ, ਕਿਉਂਕਿ http(s) ਸੰਸਕਰਣ ਕਨੈਕਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸਨ, ਅਤੇ ਮੈਨੂੰ ਉਸ ਸਮੇਂ ਅੰਦਰੂਨੀ ਪ੍ਰੌਕਸੀ ਪਤਾ ਨਹੀਂ ਪਤਾ ਸੀ। ਤਰੀਕੇ ਨਾਲ, ਇਸ ਪਲ ਤੋਂ, ਬਾਹਰੀ ਪੈਂਟਸਟ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅੰਦਰੂਨੀ ਇੱਕ ਵਿੱਚ ਬਦਲ ਗਿਆ.

ਭਾਗ 4. ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਐਡਮਿਨ ਅਧਿਕਾਰ ਮਾੜੇ ਹਨ, ਠੀਕ ਹੈ?

ਇੱਕ ਡੋਮੇਨ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ ਦਾ ਨਿਯੰਤਰਣ ਪ੍ਰਾਪਤ ਕਰਨ ਵੇਲੇ ਪੈਨਟੇਸਟਰ ਦਾ ਪਹਿਲਾ ਕੰਮ ਡੋਮੇਨ ਵਿੱਚ ਅਧਿਕਾਰਾਂ ਬਾਰੇ ਸਾਰੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨਾ ਹੈ। ਇੱਥੇ ਇੱਕ BloodHound ਉਪਯੋਗਤਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਤੋਂ LDAP ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਉਪਭੋਗਤਾਵਾਂ, ਕੰਪਿਊਟਰਾਂ, ਸੁਰੱਖਿਆ ਸਮੂਹਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਅਤੇ SMB ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ - ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਕਿ ਕਿਸ ਉਪਭੋਗਤਾ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਲੌਗਇਨ ਕੀਤਾ ਹੈ ਕਿੱਥੇ ਅਤੇ ਕੌਣ ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ ਹੈ।

ਡੋਮੇਨ ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਅਧਿਕਾਰਾਂ ਨੂੰ ਜ਼ਬਤ ਕਰਨ ਲਈ ਇੱਕ ਆਮ ਤਕਨੀਕ ਇਕਸਾਰ ਕਾਰਵਾਈਆਂ ਦੇ ਚੱਕਰ ਵਜੋਂ ਸਰਲ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

• ਅਸੀਂ ਡੋਮੇਨ ਕੰਪਿਊਟਰਾਂ 'ਤੇ ਜਾਂਦੇ ਹਾਂ ਜਿੱਥੇ ਪਹਿਲਾਂ ਹੀ ਕੈਪਚਰ ਕੀਤੇ ਡੋਮੇਨ ਖਾਤਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਸਥਾਨਕ ਪ੍ਰਬੰਧਕ ਅਧਿਕਾਰ ਹੁੰਦੇ ਹਨ।
• ਅਸੀਂ Mimikatz ਲਾਂਚ ਕਰਦੇ ਹਾਂ ਅਤੇ ਕੈਸ਼ ਕੀਤੇ ਪਾਸਵਰਡ, Kerberos ਟਿਕਟਾਂ ਅਤੇ ਡੋਮੇਨ ਖਾਤਿਆਂ ਦੇ NTLM ਹੈਸ਼ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਜੋ ਹਾਲ ਹੀ ਵਿੱਚ ਇਸ ਸਿਸਟਮ ਵਿੱਚ ਲੌਗਇਨ ਹੋਏ ਹਨ। ਜਾਂ ਅਸੀਂ lsass.exe ਪ੍ਰਕਿਰਿਆ ਦੀ ਮੈਮੋਰੀ ਚਿੱਤਰ ਨੂੰ ਹਟਾਉਂਦੇ ਹਾਂ ਅਤੇ ਸਾਡੇ ਪਾਸੇ ਵੀ ਅਜਿਹਾ ਕਰਦੇ ਹਾਂ। ਇਹ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ 2012R2/Windows 8.1 ਤੋਂ ਛੋਟੇ ਵਿੰਡੋਜ਼ ਨਾਲ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।
• ਅਸੀਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਕਿ ਸਮਝੌਤਾ ਕੀਤੇ ਖਾਤਿਆਂ ਕੋਲ ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਅਧਿਕਾਰ ਕਿੱਥੇ ਹਨ। ਅਸੀਂ ਪਹਿਲੇ ਬਿੰਦੂ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਾਂ. ਕੁਝ ਪੜਾਅ 'ਤੇ ਅਸੀਂ ਪੂਰੇ ਡੋਮੇਨ ਲਈ ਪ੍ਰਸ਼ਾਸਕ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।

"ਚੱਕਰ ਦਾ ਅੰਤ;", ਜਿਵੇਂ ਕਿ 1C ਪ੍ਰੋਗਰਾਮਰ ਇੱਥੇ ਲਿਖਣਗੇ।

ਇਸ ਲਈ, ਸਾਡਾ ਉਪਭੋਗਤਾ ਵਿੰਡੋਜ਼ 7 ਦੇ ਨਾਲ ਸਿਰਫ ਇੱਕ ਹੋਸਟ 'ਤੇ ਇੱਕ ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ ਬਣ ਗਿਆ, ਜਿਸ ਦੇ ਨਾਮ ਵਿੱਚ "VDI", ਜਾਂ "ਵਰਚੁਅਲ ਡੈਸਕਟਾਪ ਬੁਨਿਆਦੀ ਢਾਂਚਾ", ਨਿੱਜੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਸ਼ਾਮਲ ਹਨ। ਸੰਭਵ ਤੌਰ 'ਤੇ, VDI ਸੇਵਾ ਦੇ ਡਿਜ਼ਾਈਨਰ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਿਉਂਕਿ VDI ਉਪਭੋਗਤਾ ਦਾ ਨਿੱਜੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਹੈ, ਭਾਵੇਂ ਉਪਭੋਗਤਾ ਸਾਫਟਵੇਅਰ ਵਾਤਾਵਰਣ ਨੂੰ ਆਪਣੀ ਮਰਜ਼ੀ ਅਨੁਸਾਰ ਬਦਲਦਾ ਹੈ, ਹੋਸਟ ਨੂੰ ਫਿਰ ਵੀ "ਰੀਲੋਡ" ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਮੈਂ ਇਹ ਵੀ ਸੋਚਿਆ ਕਿ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਵਿਚਾਰ ਚੰਗਾ ਸੀ, ਮੈਂ ਇਸ ਨਿੱਜੀ VDI ਹੋਸਟ ਕੋਲ ਗਿਆ ਅਤੇ ਉੱਥੇ ਆਲ੍ਹਣਾ ਬਣਾਇਆ:

• ਮੈਂ ਉੱਥੇ ਇੱਕ ਓਪਨਵੀਪੀਐਨ ਕਲਾਇੰਟ ਸਥਾਪਿਤ ਕੀਤਾ, ਜਿਸ ਨੇ ਮੇਰੇ ਸਰਵਰ ਲਈ ਇੰਟਰਨੈਟ ਰਾਹੀਂ ਇੱਕ ਸੁਰੰਗ ਬਣਾਈ. ਕਲਾਇੰਟ ਨੂੰ ਡੋਮੇਨ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਨਾਲ ਉਸੇ ਬਲੂ ਕੋਟ ਵਿੱਚੋਂ ਲੰਘਣ ਲਈ ਮਜਬੂਰ ਹੋਣਾ ਪਿਆ, ਪਰ ਓਪਨਵੀਪੀਐਨ ਨੇ ਅਜਿਹਾ ਕੀਤਾ, ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ, "ਬਾਕਸ ਤੋਂ ਬਾਹਰ।"
• VDI 'ਤੇ OpenSSH ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ। ਖੈਰ, ਅਸਲ ਵਿੱਚ, SSH ਤੋਂ ਬਿਨਾਂ ਵਿੰਡੋਜ਼ 7 ਕੀ ਹੈ?

ਇਹ ਉਹੀ ਹੈ ਜੋ ਲਾਈਵ ਵਰਗਾ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ। ਮੈਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹਾਂ ਕਿ ਇਹ ਸਭ Citrix ਅਤੇ 1C ਦੁਆਰਾ ਕੀਤਾ ਜਾਣਾ ਹੈ:

ਗੁਆਂਢੀ ਕੰਪਿਊਟਰਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਨ ਲਈ ਇੱਕ ਤਕਨੀਕ ਇੱਕ ਮੈਚ ਲਈ ਸਥਾਨਕ ਪ੍ਰਬੰਧਕ ਪਾਸਵਰਡਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਹੈ। ਇੱਥੇ ਕਿਸਮਤ ਤੁਰੰਤ ਉਡੀਕ ਕਰ ਰਹੀ ਸੀ: ਡਿਫੌਲਟ ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ (ਜਿਸ ਨੂੰ ਅਚਾਨਕ ਪ੍ਰਸ਼ਾਸਕ ਕਿਹਾ ਗਿਆ ਸੀ) ਦੇ NTLM ਹੈਸ਼ ਨੂੰ ਗੁਆਂਢੀ VDI ਮੇਜ਼ਬਾਨਾਂ ਤੱਕ ਇੱਕ ਪਾਸ-ਦ-ਹੈਸ਼ ਹਮਲੇ ਦੁਆਰਾ ਸੰਪਰਕ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਕਈ ਸੌ ਸਨ। ਬੇਸ਼ੱਕ, ਹਮਲੇ ਨੇ ਤੁਰੰਤ ਉਨ੍ਹਾਂ ਨੂੰ ਮਾਰਿਆ.

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਵੀਡੀਆਈ ਪ੍ਰਬੰਧਕਾਂ ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਦੋ ਵਾਰ ਪੈਰ ਵਿੱਚ ਗੋਲੀ ਮਾਰੀ:

• ਪਹਿਲੀ ਵਾਰ ਸੀ ਜਦੋਂ VDI ਮਸ਼ੀਨਾਂ ਨੂੰ LAPS ਦੇ ਅਧੀਨ ਨਹੀਂ ਲਿਆਂਦਾ ਗਿਆ ਸੀ, ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਚਿੱਤਰ ਤੋਂ ਉਸੇ ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ ਪਾਸਵਰਡ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ ਜੋ VDI ਲਈ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਸੀ।
• ਪੂਰਵ-ਨਿਰਧਾਰਤ ਪ੍ਰਸ਼ਾਸਕ ਇੱਕੋ ਇੱਕ ਸਥਾਨਕ ਖਾਤਾ ਹੈ ਜੋ ਪਾਸ-ਦ-ਹੈਸ਼ ਹਮਲਿਆਂ ਲਈ ਕਮਜ਼ੋਰ ਹੈ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕੋ ਪਾਸਵਰਡ ਨਾਲ, ਇੱਕ ਗੁੰਝਲਦਾਰ ਬੇਤਰਤੀਬ ਪਾਸਵਰਡ ਵਾਲਾ ਦੂਜਾ ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ ਖਾਤਾ ਬਣਾ ਕੇ ਅਤੇ ਡਿਫੌਲਟ ਇੱਕ ਨੂੰ ਬਲੌਕ ਕਰਕੇ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸਮਝੌਤਾ ਕਰਨ ਤੋਂ ਬਚਣਾ ਸੰਭਵ ਹੋਵੇਗਾ।

ਉਸ ਵਿੰਡੋਜ਼ 'ਤੇ ਇੱਕ SSH ਸੇਵਾ ਕਿਉਂ ਹੈ? ਬਹੁਤ ਸਧਾਰਨ: ਹੁਣ OpenSSH ਸਰਵਰ ਨੇ ਉਪਭੋਗਤਾ ਦੇ ਕੰਮ ਵਿੱਚ ਦਖਲ ਦਿੱਤੇ ਬਿਨਾਂ ਨਾ ਸਿਰਫ਼ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਇੰਟਰਐਕਟਿਵ ਕਮਾਂਡ ਸ਼ੈੱਲ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹੈ, ਸਗੋਂ VDI 'ਤੇ ਇੱਕ socks5 ਪ੍ਰੌਕਸੀ ਵੀ ਪ੍ਰਦਾਨ ਕੀਤੀ ਹੈ। ਇਸ ਜੁਰਾਬਾਂ ਦੁਆਰਾ, ਮੈਂ SMB ਦੁਆਰਾ ਜੁੜਿਆ ਅਤੇ ਇਹਨਾਂ ਸਾਰੀਆਂ ਸੈਂਕੜੇ VDI ਮਸ਼ੀਨਾਂ ਤੋਂ ਕੈਸ਼ ਕੀਤੇ ਖਾਤੇ ਇਕੱਠੇ ਕੀਤੇ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ BloodHound ਗ੍ਰਾਫਾਂ ਵਿੱਚ ਵਰਤਦੇ ਹੋਏ ਡੋਮੇਨ ਪ੍ਰਸ਼ਾਸਕ ਦਾ ਮਾਰਗ ਲੱਭਿਆ। ਮੇਰੇ ਨਿਪਟਾਰੇ 'ਤੇ ਸੈਂਕੜੇ ਮੇਜ਼ਬਾਨਾਂ ਦੇ ਨਾਲ, ਮੈਂ ਇਹ ਤਰੀਕਾ ਬਹੁਤ ਜਲਦੀ ਲੱਭ ਲਿਆ। ਡੋਮੇਨ ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਹਨ।

ਇੱਥੇ ਇੱਕ ਸਮਾਨ ਖੋਜ ਨੂੰ ਦਰਸਾਉਂਦੀ ਇੰਟਰਨੈਟ ਤੋਂ ਇੱਕ ਤਸਵੀਰ ਹੈ. ਕਨੈਕਸ਼ਨ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਪ੍ਰਬੰਧਕ ਕਿੱਥੇ ਹੈ ਅਤੇ ਕੌਣ ਕਿੱਥੇ ਲੌਗਇਨ ਹੈ।

ਤਰੀਕੇ ਨਾਲ, ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਸ਼ਰਤ ਨੂੰ ਯਾਦ ਰੱਖੋ - "ਸੋਸ਼ਲ ਇੰਜਨੀਅਰਿੰਗ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ।" ਇਸ ਲਈ, ਮੈਂ ਇਹ ਸੋਚਣ ਦੀ ਤਜਵੀਜ਼ ਕਰਦਾ ਹਾਂ ਕਿ ਜੇ ਇਹ ਅਜੇ ਵੀ ਬੈਨਲ ਫਿਸ਼ਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੁੰਦਾ ਤਾਂ ਵਿਸ਼ੇਸ਼ ਪ੍ਰਭਾਵਾਂ ਵਾਲਾ ਇਹ ਸਾਰਾ ਬਾਲੀਵੁੱਡ ਕਿੰਨਾ ਕੁ ਕੱਟਿਆ ਜਾਵੇਗਾ। ਪਰ ਨਿੱਜੀ ਤੌਰ 'ਤੇ, ਮੇਰੇ ਲਈ ਇਹ ਸਭ ਕਰਨਾ ਬਹੁਤ ਦਿਲਚਸਪ ਸੀ. ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਨੂੰ ਪੜ੍ਹ ਕੇ ਆਨੰਦ ਲਿਆ ਹੈ। ਬੇਸ਼ੱਕ, ਹਰ ਪ੍ਰੋਜੈਕਟ ਇੰਨਾ ਦਿਲਚਸਪ ਨਹੀਂ ਲੱਗਦਾ, ਪਰ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਕੰਮ ਬਹੁਤ ਚੁਣੌਤੀਪੂਰਨ ਹੈ ਅਤੇ ਇਸਨੂੰ ਖੜੋਤ ਨਹੀਂ ਹੋਣ ਦਿੰਦਾ।

ਸ਼ਾਇਦ ਕਿਸੇ ਕੋਲ ਇੱਕ ਸਵਾਲ ਹੋਵੇਗਾ: ਆਪਣੀ ਰੱਖਿਆ ਕਿਵੇਂ ਕਰਨੀ ਹੈ? ਇੱਥੋਂ ਤੱਕ ਕਿ ਇਹ ਲੇਖ ਬਹੁਤ ਸਾਰੀਆਂ ਤਕਨੀਕਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਵਿੰਡੋਜ਼ ਪ੍ਰਸ਼ਾਸਕਾਂ ਬਾਰੇ ਵੀ ਨਹੀਂ ਜਾਣਦੇ ਹਨ. ਹਾਲਾਂਕਿ, ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਹੈਕਨੀਡ ਸਿਧਾਂਤਾਂ ਅਤੇ ਜਾਣਕਾਰੀ ਸੁਰੱਖਿਆ ਉਪਾਵਾਂ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਦੇਖਣ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹਾਂ:

• ਪੁਰਾਣੇ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ (ਸ਼ੁਰੂ ਵਿੱਚ ਵਿੰਡੋਜ਼ 2003 ਨੂੰ ਯਾਦ ਰੱਖੋ?)
• ਬੇਲੋੜੇ ਸਿਸਟਮਾਂ ਨੂੰ ਚਾਲੂ ਨਾ ਰੱਖੋ (ਯੂਰੋਲੋਜਿਸਟ ਦੀ ਵੈੱਬਸਾਈਟ ਕਿਉਂ ਸੀ?)
• ਤਾਕਤ ਲਈ ਖੁਦ ਯੂਜ਼ਰ ਪਾਸਵਰਡ ਚੈੱਕ ਕਰੋ (ਨਹੀਂ ਤਾਂ ਸਿਪਾਹੀ... ਪੈਨਟੇਸਟਰ ਅਜਿਹਾ ਕਰਨਗੇ)
• ਵੱਖ-ਵੱਖ ਖਾਤਿਆਂ ਲਈ ਇੱਕੋ ਜਿਹੇ ਪਾਸਵਰਡ ਨਾ ਹੋਣ (VDI ਸਮਝੌਤਾ)
• ਅਤੇ ਹੋਰ

ਬੇਸ਼ੱਕ, ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ, ਪਰ ਅਗਲੇ ਲੇਖ ਵਿੱਚ ਅਸੀਂ ਅਭਿਆਸ ਵਿੱਚ ਦਿਖਾਵਾਂਗੇ ਕਿ ਇਹ ਕਾਫ਼ੀ ਸੰਭਵ ਹੈ.

ਸਰੋਤ: www.habr.com