- Sep 5, 2017
- 1,173
this thread must be pinned (fight between security titans 
)
)
Sampei Nihira Security Config WinXP (POS Ready2009) 2020
- Thread starter Sampei Nihira
- Start date
- Status
- Dec 23, 2014
- 8,513
Test results for MBAE (current beta) on Windows 10 64-bit ver 1909.
Browsers profile
Not blocked: Null Page, Heap Spray 1, Heap Spray 2, Heap Spray 3, Heap Spray 4, Anti-VM - VMware, Anti-VM - Virtual PC, Load Library, URLMon, Lockdown 1, Lockdown 2.
Blocked: Stack Pivot, Stack Exec, ROP-Winexec(), ROP-VirtualProtect(), ROP-NtProtectVirtualMemory()
Other profile
Not blocked: Stack Pivot, Stack Exec, ROP-Winexec(), Null Page, Heap Spray 1, Heap Spray 2, Heap Spray 3, Heap Spray 4, Anti-VM - VMware, Anti-VM - Virtual PC, Load Library, URLMon, Lockdown 1, Lockdown 2.
Blocked: ROP-VirtualProtect(), ROP-NtProtectVirtualMemory
Edit
The Null Page, Load Library, and URLMon were blocked by Windows, so their results for MBAE are unknown.
The test was performed for the 64-bit version tool, so the protection for the 64-bit applications was tested.
Browsers profile
Not blocked: Null Page, Heap Spray 1, Heap Spray 2, Heap Spray 3, Heap Spray 4, Anti-VM - VMware, Anti-VM - Virtual PC, Load Library, URLMon, Lockdown 1, Lockdown 2.
Blocked: Stack Pivot, Stack Exec, ROP-Winexec(), ROP-VirtualProtect(), ROP-NtProtectVirtualMemory()
Other profile
Not blocked: Stack Pivot, Stack Exec, ROP-Winexec(), Null Page, Heap Spray 1, Heap Spray 2, Heap Spray 3, Heap Spray 4, Anti-VM - VMware, Anti-VM - Virtual PC, Load Library, URLMon, Lockdown 1, Lockdown 2.
Blocked: ROP-VirtualProtect(), ROP-NtProtectVirtualMemory
Edit
The Null Page, Load Library, and URLMon were blocked by Windows, so their results for MBAE are unknown.
The test was performed for the 64-bit version tool, so the protection for the 64-bit applications was tested.
Last edited:
- Dec 26, 2019
- 287
On that OS you should also publish the results of:
- ROP- Wow64 bypass
- ROP - Exploit Wow64
- Dec 26, 2019
- 287
Performing the same test with Windows Defender Exploit Protection is possible.
19 system overrides must be entered to give WDEP the ability to do its best.
Even if with a lower number of overrides the result does not seem to change.
If the test is passed the Exploit Test Tool closes.
If it is not passed, the calculator starts.
19 system overrides must be entered to give WDEP the ability to do its best.
Even if with a lower number of overrides the result does not seem to change.
If the test is passed the Exploit Test Tool closes.
If it is not passed, the calculator starts.
- Dec 23, 2014
- 8,513
I made the test with the tool version 1.4.0.19 - there are no such entries. I think that these two entries are for 32-bit applications - the term Wow64 is usually related to 32-bit applications on 64-bit Windows. I tested 64-bit applications. The version 1.4.0.19 includes the separate tools for 32-bit and 64-bit applications (both have different exploit entries).
I also tested the Windows protection of native Edge against that tool (MicrosoftEdge.exe, MicrosoftEdgeCP.exe, MicrosoftEdgeBCHost.exe, MicrosoftEdgeSH.exe, MicrosoftPdfReader.exe) - all exploits blocked. I think that these executables have also other mitigations because the 'Run Windows Calculator' was blocked too. Only the 'Keyboard logger (not exploit)' worked, and all these executables failed to stop keylogging.
The test for Internet Explorer gave the same results as the default test from my previous post (without MBAE), only Null Page, Load Library, and URLMon were blocked.
Last edited:
Your conversation is awesome. I did notice something:
The creator of this topic is not interested in having the most secure computer in the world, but fun with his favorite operating system, trying to make it even more secure every day.
Even if it would be better to use a more recent operating system to do the banking things, I think the author enjoys using it because he may have had the best moments of his life in times of XP.
There are many things that are fun, but have disadvantages or are dangerous, like driving fast or,... you know ( ͡° ͜ʖ ͡°).
So let the topic writer have his fun
I did notice something:The creator of this topic is not interested in having the most secure computer in the world, but fun with his favorite operating system, trying to make it even more secure every day.
Even if it would be better to use a more recent operating system to do the banking things, I think the author enjoys using it because he may have had the best moments of his life in times of XP.
There are many things that are fun, but have disadvantages or are dangerous, like driving fast or,... you know ( ͡° ͜ʖ ͡°).
So let the topic writer have his fun
Your conversation is awesome.
The creator of this topic is not interested in having the most secure computer in the world, but fun with his favorite operating system, trying to make it even more secure every day.
Even if it would be better to use a more recent operating system to do the banking things, I think the author enjoys using it because he may have had the best moments of his life in times of XP.
There are many things that are fun, but have disadvantages or are dangerous, like driving fast or,... you know ( ͡° ͜ʖ ͡°).
So let the topic writer have his fun
That's a good point!
I think another point to this is that there's a lot of people that both join and/or just read the forum for advice. So it's a balance between letting someone have fun and making sure that people don't just copy something like this blindly, without understanding all the potential negatives/consequences of such a setup/approach.
- Dec 23, 2014
- 8,513
I used only one Exploit Protection mitigation on Windows 10 to block running child processes of the testing tool - all exploits were blocked. This mitigation can be done for many vulnerable applications. The similar protection is applied via WD ASR rules for MS Office applications.
Edit.
Of course, this mitigation does not block any of the exploiting methods used by the testing tool. The exploit methods work, but in the end, the payload (calc.exe) cannot be executed. That is why one should be very cautious when using this testing tool. From the fact that it is blocked, it does not follow that the protection can fight the exploiting methods.
Edit.
Of course, this mitigation does not block any of the exploiting methods used by the testing tool. The exploit methods work, but in the end, the payload (calc.exe) cannot be executed. That is why one should be very cautious when using this testing tool. From the fact that it is blocked, it does not follow that the protection can fight the exploiting methods.
Last edited:
- Dec 26, 2019
- 287
- Dec 23, 2014
- 8,513
I already have this one, but It is for 32-bit applications.
I have played a little with the name of the tool, and there is also 64-bit version here:
Last edited:
- Dec 26, 2019
- 287
Andy there is a reason why the most updated version of the ETT is 32 bit.
As you know, some test exploits are exclusive to 32 bits.
And even in 64-bit PCs 32-bit applications can be installed.
Today of course there is no reason but at that time many applications were not available in 64 bit the most classic example is Thunderbird only recently in 64 bit.
Obviously if an application is 64-bit we must not take into account the possible failure of some tests.
Like Unpivot Stack, ROP - CALL preceded VirtualProtect (), ......
In fact, if you read the instruction manual, the missing tests that I have indicated to you can only be performed if the PC is 64 bit:
Don't write to me that all this is complicated, I remember that I spoke with the Loman brothers ...... but if I have to be honest I don't remember the conclusions.
I had a good laugh reading this thread. really.
1- this setup being tagged as ""Risky" is just common sense and logic.
2- XP is trash OS like Win7 , obsolete and insecure, and not even nice to the eyes lol. if not, the user won't need an armada of security softs to use it safely.
3- having fun with an old OS is ok, as long the user understand that it is subpar and not recommended security-wise.
4- The OP seems to ignore what are Windows Rings. If he knew, he will know that kernel exploits (Ring 0) would pass above all his security software. I don't even mention about true fileless attacks.
In XP and win7 era, security softs patched (hook) the kernel so they could intercept potential kernel attacks but at the same time they introduced instability and the possibility of surface attacks.
Since X64 OSes, Patchguard (aka Kernel Patch Protection ) was introduced and deprived security vendors to manipulate the kernel , so most of them use Hypervisor workarounds.
5- the OP seems to ignore what is session 0. if he knew, he won't like the idea that in XP, the user session runs at the same session than the services. Which is enough to be declared a HUGE security risk with today threats.
6- WinXP is used in lot of systems around the world (ATM, POS, lazy corporations, poor countries users, etc...), so kernel exploits for XP is not something that will disappears soon.
It is not because a threat isn't prevalent , that the risks to cross one are negated (see Eternal Blue kernel exploit, not so old and obviously the main reason the OP disabled SMB in his config).
so my conclusion: OK have fun with XP, after all it is your computer, but don't even try to make it sound a great OS that people should still use.
It was great when it was released, now it is just trash.
People who keep using XP/Win7 when they could use a modern and safer OS are willing victims and accomplices of the cybercriminals, they just help them fulfill their goals.
1- this setup being tagged as ""Risky" is just common sense and logic.
2- XP is trash OS like Win7 , obsolete and insecure, and not even nice to the eyes lol. if not, the user won't need an armada of security softs to use it safely.
3- having fun with an old OS is ok, as long the user understand that it is subpar and not recommended security-wise.
4- The OP seems to ignore what are Windows Rings. If he knew, he will know that kernel exploits (Ring 0) would pass above all his security software. I don't even mention about true fileless attacks.
In XP and win7 era, security softs patched (hook) the kernel so they could intercept potential kernel attacks but at the same time they introduced instability and the possibility of surface attacks.
Since X64 OSes, Patchguard (aka Kernel Patch Protection ) was introduced and deprived security vendors to manipulate the kernel , so most of them use Hypervisor workarounds.
5- the OP seems to ignore what is session 0. if he knew, he won't like the idea that in XP, the user session runs at the same session than the services. Which is enough to be declared a HUGE security risk with today threats.
6- WinXP is used in lot of systems around the world (ATM, POS, lazy corporations, poor countries users, etc...), so kernel exploits for XP is not something that will disappears soon.
It is not because a threat isn't prevalent , that the risks to cross one are negated (see Eternal Blue kernel exploit, not so old and obviously the main reason the OP disabled SMB in his config).
so my conclusion: OK have fun with XP, after all it is your computer, but don't even try to make it sound a great OS that people should still use.
It was great when it was released, now it is just trash.
People who keep using XP/Win7 when they could use a modern and safer OS are willing victims and accomplices of the cybercriminals, they just help them fulfill their goals.
Last edited by a moderator:
- Dec 26, 2019
- 287
In the meantime I went to look for the latest monthly Microsoft updates of April 2019 for my pc:
Half of these are irrelevant to a possible OS exploit because they concern Microsoft browsers (I.E.8).
I am not able to carry out an analysis on others because this is not my field, but all of them have a exploitability assessment 2:
No system bugs are exploited.
Microsoft Update Catalog
www.catalog.update.microsoft.com
Half of these are irrelevant to a possible OS exploit because they concern Microsoft browsers (I.E.8).
I am not able to carry out an analysis on others because this is not my field, but all of them have a exploitability assessment 2:
No system bugs are exploited.
- Dec 23, 2014
- 8,513
Sampei Nihira,
There is nothing complicated in hmpalert test tools. The hmpalert-test.exe can be used both on Windows 32-bit and 64-bit (some exploiting methods will work only on Windows 64-bit), but only for 32-bit applications. The hmpalert64-test.exe is for 64-bit applications (can be run only on 64-bit Windows).
I tested only 64-bit applications with hmpalert64-test.exe. In this tool there are no the below exploitation methods:
Unpivot Stack,
ROP - CALL preceded VirtualProtect (),
ROP - Wow 64 bypass,
ROP - exploit Wow 64,
ROP – system() in msvcrt,
ROP – VirtualProtect() via CALL gadget,
WinExec() via anti-detour,
IAT Filtering,
SEHOP,
Hollow Process,
URLMon 2 – Rundll32,
URLMon 3 – LoadLibraryA,
These exploitation methods are intended only for 32-bit applications.
In the manual it is clearly stated which exploits can be tested only on 32-bit applications and that ROP - Wow 64 bypass, ROP - exploit Wow 64, requires Windows 64-bit.
There is nothing complicated in hmpalert test tools. The hmpalert-test.exe can be used both on Windows 32-bit and 64-bit (some exploiting methods will work only on Windows 64-bit), but only for 32-bit applications. The hmpalert64-test.exe is for 64-bit applications (can be run only on 64-bit Windows).
I tested only 64-bit applications with hmpalert64-test.exe. In this tool there are no the below exploitation methods:
Unpivot Stack,
ROP - CALL preceded VirtualProtect (),
ROP - Wow 64 bypass,
ROP - exploit Wow 64,
ROP – system() in msvcrt,
ROP – VirtualProtect() via CALL gadget,
WinExec() via anti-detour,
IAT Filtering,
SEHOP,
Hollow Process,
URLMon 2 – Rundll32,
URLMon 3 – LoadLibraryA,
These exploitation methods are intended only for 32-bit applications.
In the manual it is clearly stated which exploits can be tested only on 32-bit applications and that ROP - Wow 64 bypass, ROP - exploit Wow 64, requires Windows 64-bit.
- Oct 1, 2019
- 1,120
There are actually people building a roll cage into a 2CV (deux cheveaux refering to the two horse power the car had when released in 1948). I wonder where they mount the roll cage in a 2CV since the whole car is (to today's standards) an absorption zone?
Last edited:
This thread is fascinating. I have a question: I looked up the Intel Celeron series and at least two lines (J and N) of that are vulnerable to Spectre/Meltdown et al. If applicable, are microcodes available for this cpu or would applying them make this device unusable? Would running the XP operating system make it more susceptible to side-channel leaks? What can you do besides patch?
- Dec 26, 2019
- 287
- Dec 23, 2014
- 8,513
Ha, ha. It is a psychological thread, so most readers should be irritated.I had a good laugh reading this thread. really.
...
It is like the thread about "Why use one leg instead of two."
There are some possible answers:
- You do not like the second leg and want to make the first as strong as possible.
- You can use twice fewer stockings and there are twice fewer stockings to launder.
- You can use twice less shoe cream and twice less time to clean the shoes.
- There is only one leg to care, heal, wash ...
- You can use much fewer neurons in the brain.
- You cannot walk far away, so there are greater chances to avoid bad people.
- You have one extra-strong leg, and this is what can baffle the attacker.
- etc.
I have a brother who uses Windows XP + Eset. I told him many times how dangerous it can be. He always has one answer: I use this setup for many years and never been infected.
Yes, it is always hard to beat the facts.
Last edited:
- Dec 26, 2019
- 287
the blonde asked why there were three pedals in her car when she only had two legs.
- Status
Similar threads
